Делегирование голосов в DAO часто выглядит как передача: после операции у другого адреса увеличивается voting power. Однако токены обычно остаются в кошельке владельца. Делегат получает право голосовать указанным весом, но не получает право продать монеты, вывести их или дать от имени владельца обычный token approval.
Это разделение позволяет пассивному держателю поручить участие специалисту, не отдавая активы на хранение. Но результат зависит от конкретного governance contract. Одни DAO используют onchain checkpoints, другие считают баланс в момент offchain snapshot, а некоторые требуют блокировки токенов. Перед подписью нужно определить, какую систему применяет проект.
Собственность и voting power – разные права
Обычный перевод токенов вызывает transfer: баланс отправителя уменьшается, баланс получателя растёт, а новый владелец может распоряжаться активом. Делегирование вызывает отдельную функцию, например delegate. Баланс токенов не меняется, но контракт записывает адрес представителя и переносит к нему учитываемые голоса.
Делегат не становится custodian. Он не может отправить токены себе, создать allowance или использовать их в DeFi только потому, что получил голос. Для движения монет нужны отдельная подпись владельца, approval или контрактное право, не связанное с governance delegation.
Владелец сохраняет возможность продать или перевести токены. После перевода соответствующие voting units обычно вычитаются из веса выбранного им делегата. У получателя монет голос может не появиться автоматически: в некоторых реализациях ему нужно делегировать силу себе или другому адресу.
Как работает делегирование в ERC20Votes
Распространённая схема основана на модуле OpenZeppelin ERC20Votes. Баланс токена задаёт voting units, а адрес владельца выбирает delegatee. Функция delegate(delegatee) переносит все текущие voting units владельца выбранному представителю. Функция не дробит токены и не перемещает их.
Самоделегирование означает, что владелец указывает собственный адрес как delegatee. В базовой модели OpenZeppelin голоса не начинают отслеживаться автоматически для каждого баланса: это экономит gas на переводах между адресами, которые не участвуют в governance. Поэтому кошелёк может хранить governance token и показывать нулевой current voting power до self-delegation.
Контракт создаёт checkpoints при изменении веса. Запись связывает timepoint – обычно номер блока или timestamp – с количеством голосов делегата. Метод исторического чтения позволяет узнать вес на уже прошедший момент. Благодаря этому поздняя покупка токенов не меняет право голоса по предложению, snapshot которого уже зафиксирован.
Схему можно увидеть в governance таких проектов, как Compound, хотя конкретные thresholds и задержки задаются его собственными контрактами. Название функции, clock mode и возможность частичного делегирования нельзя предполагать только по знакомому интерфейсу.
Зачем нужен snapshot голосов
Governor обычно определяет момент, по которому считается voting power для конкретного proposal. Если бы учитывался текущий баланс, один пакет токенов можно было бы перевести между адресами и проголосовать несколько раз. Исторический checkpoint фиксирует вес до начала или на заданном timepoint и не позволяет последующим переводам переписать прошлое.
Отсюда важное следствие: переделегирование после snapshot может не изменить голоса в уже открытом предложении, но повлияет на следующее. Точный момент зависит от параметров voting delay и clock contract. Пользователю нужно читать proposal snapshot, а не ориентироваться только на дату в интерфейсе.
Checkpoint – это учётная запись, а не блокировка актива. Владелец может перевести токены после snapshot, однако его прежний делегат всё ещё способен иметь вес в конкретном уже зафиксированном голосовании. Новому держателю тот же баланс не даст дополнительный голос в этом proposal.
Делегирование напрямую и по подписи
Прямая функция delegate отправляется владельцем как onchain-транзакция. Она расходует gas и сразу меняет текущего delegatee после включения в блок. Вариант delegateBySig позволяет подписать структурированное сообщение, которое затем отправляет relayer или другой участник.
Подпись не является обычным переводом, но всё равно меняет onchain-состояние. Безопасная реализация включает nonce, срок действия и домен EIP-712, чтобы подпись нельзя было бесконечно повторять или использовать в другом контракте. В кошельке нужно сверить chain, verifying contract, delegatee, nonce и expiry.
Фишинговый сайт может назвать запрос «входом» и предложить governance signature. Такая подпись не отдаёт токены, но способна передать голос атакующему в критический момент. Ещё опаснее пакет, где рядом скрыт Permit или approval. Нужно разбирать каждое действие отдельно и не считать любую подпись без gas безвредной.
Как отменить или изменить делегирование
В большинстве моделей владелец может вызвать delegate снова и выбрать нового представителя. Чтобы вернуть голос себе, используется self-delegation. Некоторые интерфейсы предлагают «undelegate», но на уровне контракта это может означать делегирование нулевому адресу или специальную функцию.
Перед отменой проверьте документацию токена. Отправка на zero address в неподходящей реализации может быть запрещена, а выбор собственного адреса, наоборот, активирует личный voting power. После транзакции прочитайте delegates(owner), текущие голоса нового делегата и событие DelegateChanged.
Переделегирование не отзывает уже отданный голос в proposal. Если делегат успел проголосовать, новый представитель обычно не может проголосовать тем же весом повторно. Расширенные реализации способны учитывать частичное использование веса, поэтому итог нужно проверять в Governor contract.
Частичное делегирование и другие модели
Классический Votes делегирует все voting units одного аккаунта одному адресу. Но DAO может добавить частичное делегирование, несколько delegatee, NFT-голоса, vesting positions или vote-escrow. Токен, заблокированный в отдельном контракте, иногда перестаёт голосовать через обычный ERC-20 и создаёт новый governance balance.
Offchain-системы работают иначе. Например, Snapshot рассчитывает voting power по strategy и состоянию сети в заданном блоке. Делегирование может храниться в отдельном registry, а подпись голоса – не отправляться в Governor. Результат становится исполнимым только через multisig, модуль или отдельную onchain-схему.
У NFT-DAO правило ещё сильнее зависит от контракта. В Nouns DAO voting units связаны с NFT и историческими checkpoint. В другом проекте один NFT может давать один голос, несколько голосов либо вес по редкости. Универсального стандарта для экономического веса нет.
Что делегат может и чего не может
Обычно делегат может голосовать «за», «против» или «воздержался» весом, который был ему делегирован на snapshot. В некоторых DAO voting power также помогает достичь proposal threshold и создать предложение. Возможность голосовать не означает автоматического права исполнить транзакцию: execution проходит через Governor, timelock и целевые контракты.
Делегат не обязан следовать пожеланию владельца, если между ними нет отдельного соглашения. Onchain-контракт видит адрес и голос, но не проверяет обещания в профиле кандидата. Поэтому репутация, раскрытие конфликтов интересов и история участия имеют практическое значение.
Даже крупный делегат не может изменить код протокола одним голосом, если не контролирует quorum и большинство. Но концентрация силы позволяет определять исход при низкой явке, блокировать решения или влиять на повестку. Владельцу следует оценивать не только личный выбор, но и общий расклад делегатов.
Основные риски делегирования
- Концентрация. Несколько публичных делегатов могут собрать вес, непропорциональный собственным токенам.
- Низкая активность. Делегат пропускает snapshot или не голосует, и потенциальный вес не участвует в решении.
- Конфликт интересов. Представитель связан с командой, инвестором или конкурирующим протоколом.
- Фишинговая подпись. Пользователь незаметно меняет delegatee либо подписывает дополнительный Permit.
- Компрометация ключа. Украденный ключ делегата позволяет голосовать всем собранным весом, хотя не даёт контроля над чужими токенами.
- Ошибочный snapshot. Переделегирование сделано после timepoint и не влияет на текущее предложение.
- Неочевидная реализация. Интерфейс скрывает lock, wrapping или отдельный registry, которые меняют права владельца.
- Upgrade risk. Обновляемый governance token или модуль delegation способен изменить правила учёта.
Как проверить делегирование перед подписью
- Сверьте адрес governance token и сеть.
- Узнайте, реализованы ли
Votes, checkpoints и self-delegation. - Проверьте текущий
delegates(owner)и voting power. - Найдите snapshot конкретного proposal и его clock mode.
- Для подписи прочитайте verifying contract, chain ID, delegatee, nonce и expiry.
- Убедитесь, что рядом нет token approval, Permit или перевода.
- После операции проверьте событие и новый checkpoint через explorer.
- Заранее выясните, как вернуть self-delegation или выбрать другого представителя.
Итог
Делегирование в DAO передаёт voting power, а не собственность на токены. Владелец сохраняет баланс и возможность распоряжаться активом, а делегат получает право участвовать в governance в пределах зафиксированного веса. Checkpoints и snapshots не дают одному балансу голосовать повторно после переводов.
Перед подписью важно определить реализацию: onchain Governor, offchain Snapshot, vote-escrow или собственный registry. Затем нужно сверить delegatee, snapshot, nonce и возможность отмены. Делегирование снижает операционную нагрузку на держателя, но требует доверия к решениям представителя и постоянного контроля концентрации голосов.
