Quorum, proposal threshold и execution delay в управлении DAO

В DAO недостаточно набрать больше голосов «за», чем «против». Создателю предложения может требоваться минимальная voting power, голосованию – quorum, а успешной операции – ожидание в timelock. Эти ограничения отвечают на разные вопросы и не заменяют друг друга.

Proposal threshold решает, кто может вынести действие на голосование. Quorum определяет, достаточно ли участия, чтобы результат считался легитимным. Правило большинства сравнивает варианты. Voting delay даёт время между созданием предложения и snapshot, а execution delay оставляет окно между одобрением и исполнением кода.

Как proposal проходит через governance

Типичный onchain-процесс состоит из нескольких состояний. Пользователь формирует targets, values и calldata, описывает предложение и вызывает propose. Governor проверяет право автора, сохраняет идентификатор и назначает snapshot. После voting delay начинается голосование, а после voting period подсчитываются quorum и результат.

Успешное предложение может перейти в очередь timelock. Для операции вычисляется идентификатор, задаётся момент готовности, и только после минимальной задержки разрешается execute. Исполнение вызывает целевые контракты с теми данными, которые были одобрены. Ошибка в calldata не исправляется красивым текстом описания.

Конкретная реализация может отличаться. Некоторые DAO проводят сигнальное голосование в Snapshot, после чего multisig готовит транзакцию. Другие используют Governor полностью onchain. Поэтому интерфейс с процентами ещё не доказывает автоматическую связь между голосом и исполнением.

Proposal threshold – входной порог

proposalThreshold() задаёт минимальную voting power, необходимую для создания proposal. Порог защищает governance от спама: без него любой адрес мог бы заставлять участников разбирать бесконечные предложения и оплачивать связанную инфраструктуру.

Слишком высокий threshold превращает создание предложений в привилегию нескольких китов или делегатов. У держателей остаётся право голосовать, но нет реальной возможности вынести вопрос без поддержки крупного блока. Слишком низкий порог облегчает атаки на внимание и может перегружать queue.

Voting power часто берётся из исторических checkpoints governance token. Простого текущего баланса бывает недостаточно: токены могут требовать self-delegation, а Governor проверяет голосующую силу на прошедшем timepoint. Как ownership отделяется от голосов, объясняется в статье о делегировании в DAO.

Порог не означает, что автор может провести предложение. После создания его голос учитывается на общих основаниях. Для победы всё равно нужны quorum и достаточное соотношение вариантов.

Quorum – минимальное участие

quorum(timepoint) возвращает минимальную голосующую силу для предложения с заданным snapshot. Порог может быть фиксированным числом либо долей исторического total supply. Использование timepoint не даёт будущей эмиссии или сжиганию токенов переписать требование уже открытого голосования.

Важно понять, какие варианты входят в quorum. В распространённой модели GovernorCountingSimple голоса For и Abstain помогают достичь quorum, а Against – нет. При этом предложение считается успешным по отдельному правилу, обычно когда For больше Against. Следовательно, abstain может сделать голосование состоявшимся, не поддерживая исполнение.

Другой Governor вправе считать иначе. Где-то учитываются все поданные голоса, где-то только For, а где-то есть несколько вариантов и собственная формула. Нельзя выводить правило по словам интерфейса – нужно открыть counting module или методы контракта.

Слишком низкий quorum облегчает захват при слабой явке. Небольшая организованная группа получает непропорциональное влияние. Слишком высокий quorum создаёт governance paralysis: даже разумное предложение не проходит из-за пассивных токенов, потерянных ключей или неактивных делегатов.

Majority не равна quorum

Представим, что проголосовали 60 единиц For, 40 Against, а требуемый quorum – 150. За предложение подано большинство участвовавших голосов, но голосование не состоялось. В другой ситуации 80 For, 10 Against и 70 Abstain могут выполнить quorum 150, а результат зависит от counting rule.

Поэтому публичная фраза «большинство поддержало» неполна. Нужно знать знаменатель, snapshot supply, способы подсчёта abstain и состояние proposal после дедлайна. Интерфейс может округлять проценты, а контракт работает с целыми voting units.

Voting delay, voting period и late quorum

Voting delay – промежуток между созданием proposal и началом голосования. Он даёт участникам время прочитать calldata, организовать делегирование и заметить опасное действие. Snapshot обычно привязан к границе этого периода, поэтому покупка или переделегирование после timepoint не добавляет вес в уже открытое голосование.

Voting period определяет, сколько длится приём голосов. Единица измерения зависит от clock Governor: это могут быть номера блоков или timestamps по ERC-6372. Перевод количества блоков в календарное время является оценкой и меняется вместе с block time.

Атакующий способен дождаться конца и внести большой блок голосов, оставив оппонентам мало времени. Модуль late quorum может продлить голосование, если quorum достигнут слишком поздно. Наличие такой защиты, её длительность и условия нужно проверять в коде конкретного Governor.

Execution delay и роль timelock

Execution delay начинается после успешного голосования и постановки операции в очередь. TimelockController хранит минимальную задержку и не позволяет исполнить действие раньше установленного момента. За это время пользователи могут изучить окончательный вызов, закрыть позицию, отозвать разрешение или подготовиться к обновлению.

Задержка не исправляет вредоносное решение. Если операция останется в очереди и будет исполнена, timelock лишь предоставляет время реакции. Защита работает лучше, когда события мониторятся, у пользователей есть реальный выход, а критические контракты действительно подчинены timelock.

Проверьте роли. Proposer ставит операции в очередь, Executor исполняет готовые, Canceller отменяет, Admin управляет ролями. Открытая роль Executor может быть нормальной: любой адрес способен исполнить уже одобренную операцию, но не изменить её данные. Опаснее неожиданный Admin или Proposer, способный обходить Governor.

У timelock могут быть predecessor и salt. Predecessor заставляет дождаться другой операции, а salt помогает получить уникальный идентификатор при одинаковых вызовах. Для аудита нужно сопоставить proposal с operation hash и убедиться, что готовая к исполнению операция содержит ожидаемые targets и calldata.

Почему одного timelock недостаточно

Протокол может объявить execution delay, но оставить отдельному multisig право обновить proxy, поставить паузу или заменить oracle без очереди. Тогда governance контролирует только часть системы. Поиск timelock, emergency pause и обходных ролей разобран в инструкции о временных и аварийных правах.

Слишком короткая задержка не даёт отреагировать на захват голосования. Слишком длинная усложняет исправление уязвимости. Поэтому emergency pause часто отделяют от обычного governance: ограниченный guardian может временно остановить функции, но не обязан иметь право произвольно выводить активы или внедрять новую логику.

Как проверить параметры onchain

1. Найдите настоящий Governor contract через документацию, события и ownership целевых контрактов.
2. Прочитайте proposalThreshold, votingDelay, votingPeriod и clock mode.
3. Для конкретного proposal запишите snapshot, deadline и значение quorum(snapshot).
4. Определите counting module: какие варианты входят в quorum и что считается победой.
5. Проверьте governance token, делегирование, checkpoints и исторический total supply.
6. Найдите timelock, его getMinDelay и роли Proposer, Executor, Canceller и Admin.
7. Сопоставьте targets, values и calldata proposal с queued operation.
8. Проверьте proxy admin, guardian и multisig, которые могут менять систему вне Governor.
9. Посмотрите, может ли governance изменять собственные параметры и через какую задержку.

Типичные опасные сочетания

• Низкий threshold и короткое голосование. Proposal легко создать и провести до широкой реакции.
• Высокий threshold и высокая концентрация. Повестку контролируют несколько делегатов.
• Низкий quorum. Маленькая активная группа принимает решения за пассивное большинство.
• Высокий quorum без late-quorum защиты. Управление часто парализовано или уязвимо для манёвра в конце.
• Нулевой execution delay. После голосования почти нет окна для проверки и выхода.
• Скрытый admin. Governor выглядит децентрализованным, но ключ обновления находится вне timelock.
• Offchain без прозрачного исполнения. Результат Snapshot зависит от решения multisig.

Итог

Proposal threshold, quorum и majority контролируют разные этапы. Первый ограничивает создание proposal, второй требует минимального участия, третий выбирает победивший вариант. Voting delay и voting period задают календарь голосования, а execution delay через timelock оставляет окно перед изменением протокола.

Надёжная проверка проводится по Governor, governance token, counting module, timelock и правам целевых контрактов. Нужно читать не только проценты на странице голосования, но и snapshot, calldata, роли и обходные административные пути. Только вся цепочка показывает, кто действительно может изменить DAO и сколько времени остаётся на реакцию.