DAO управление: как выбрать модель голосования в DeFi проекте
DAO управление: как выбрать модель голосования в DeFi-проекте
Если вес голоса зависит от количества токенов, капитал автоматически превращается во власть; если всем выдать одинаковый вес, на первый план выходит вопрос, как отличить реальных участников сообщества от сотен кошельков, созданных ради атаки. Поэтому выбор модели голосования — не декоративная настройка управления, а часть архитектуры протокола.
Для DeFi-проекта здесь нет универсального рецепта. Одна схема лучше распределяет влияние, другая проще для исполнения, третья дает участникам время оценить предложения, но ни одна сама по себе не закрывает риски концентрации, низкой явки и захвата управления. Разберем, как устроены основные модели, где они ломаются и почему гибридные системы часто практичнее чистой формулы.
1 token = 1 vote: просто для контракта, не обязательно для сообщества
В классической модели вес участника пропорционален количеству токенов на его балансе или в стейкинге. Держишь больше governance-токенов — получаешь больше голосов. Для смарт-контракта логика прозрачная: контракт фиксирует доступный вес, принимает голоса и считает результат по заданным правилам.
Такая простота полезна, когда решения напрямую затрагивают экономический риск держателей: например, параметры протокола или распределение средств казначейства. Участник, поставивший больше капитала под риск, получает больший вес. Но это не тождественно равному участию, а слово «децентрализованный» не появляется автоматически оттого, что голосование проходит ончейн.
Если значительная доля токенов сосредоточена у небольшого числа кошельков, их владельцы могут получить решающее влияние. Голосование токенами в этом смысле ближе к голосованию долями капитала, чем к принципу «один участник — один голос». Вдобавок токены могут быть делегированы: делегирование снижает трение для держателей, которые не следят за каждым proposal, но способно сконцентрировать власть у нескольких активных делегатов.
Нужно смотреть не только на формулу подсчета, но и на момент, когда фиксируется право голоса. Если баланс учитывается в момент голосования, появляется пространство для краткосрочного перемещения токенов. Snapshot на заранее выбранном блоке помогает отсечь часть таких маневров, хотя само по себе не гарантирует честного управления. В архитектуре важны и сроки голосования, кворум, порог принятия предложения, ограничения на делегирование и задержка перед исполнением.
1 token = 1 vote — это не «голос каждого», а «голос каждой единицы капитала».
Для участника протокола модель понятна, но оценивать ее нужно по распределению власти, а не по названию DAO. Если небольшая группа кошельков способна провести решение при низкой явке, формальное голосование сообщества превращается в плутократию с красивым интерфейсом.
Квадратичное голосование: меньше награда за концентрацию, больше требований к идентичности
Квадратичное голосование меняет цену дополнительного влияния. Один голос стоит один токен или кредит, два голоса — четыре, три — девять. Чем сильнее участник хочет протолкнуть конкретное решение, тем дороже обходится каждый следующий голос.
Идея в том, чтобы дать небольшим держателям шанс выразить предпочтение, не позволяя крупному капиталу линейно наращивать власть. Но формула не знает, кто стоит за адресом. Если один человек может создать много кошельков и распределить между ними ресурсы, квадратичная модель становится задачей сибилл-атаки: ограничение работает против одного кошелька, а не обязательно против одного участника.
Поэтому квадратичное голосование нельзя считать готовым решением проблемы концентрации. Оно зависит от того, как протокол подтверждает уникальность участников, кто выдает такую репутацию и насколько дорого или сложно ее получить. Внешняя верификация личности способна уменьшить риск сибилл-атаки, но добавляет собственные вопросы: приватность, доступность и доверие к механизму удостоверения.
| Модель | Как распределяется влияние | Что дает | Основной риск |
|---|---|---|---|
| 1 token = 1 vote | Пропорционально количеству токенов | Прозрачная и простая логика, связь голоса с экономическим участием | Концентрация влияния у крупных держателей |
| Квадратичное голосование | Дополнительные голоса стоят все дороже: N голосов требуют N² токенов или кредитов | Снижает отдачу от концентрации голосов в одном аккаунте | Сибилл-атаки, если не установлена уникальность участников |
| Conviction Voting | Вес накапливается, пока токены заблокированы за предложением | Решению нужно время набрать поддержку, а не только разовый перевес | Долгое ожидание и уязвимость настроек порога |
| Двухпалатная система | Разные группы голосуют по разным правилам | Позволяет учитывать и капитал, и репутацию сообщества | Сложнее согласовать полномочия и разрешать тупиковые ситуации |
Таблица показывает различие логик, но не дает рейтинга «лучше — хуже». Система, которая подходит казначейству с ограниченным кругом ответственных участников, может оказаться неудачной для протокола, где решения затрагивают многочисленное сообщество пользователей.
Conviction Voting: голос не только считается, но и копит вес
В Conviction Voting участник блокирует токены за выбранное предложение. По мере времени сила его голоса накапливается; решение проходит, когда поддержка достигает установленного порога. Это меняет ритм управления: предложение не обязательно выигрывает из-за мгновенного всплеска голосов, а участники показывают, готовы ли они удерживать позицию.
Для протокола такая механика может быть удобна при распределении ресурсов или рассмотрении инициатив, где важна устойчивая поддержка. Но время — не бесплатная защита. Если порог настроен неудачно, решение может слишком долго зависать или, напротив, пройти при меньшей поддержке, чем ожидало сообщество. Заблокированные токены также означают, что участник теряет гибкость на период голосования.
У Conviction Voting есть еще один архитектурный нюанс: система должна ясно объяснять, как именно накапливается вес, как меняется поддержка при отзыве токенов и какие предложения конкурируют за ограниченный объем ресурсов. Если интерфейс показывает только итоговое число, но скрывает динамику и условия достижения порога, участникам трудно понять, что произойдет с proposal дальше. Прозрачность здесь — часть механизма, а не косметика для фронтенда.
Эту модель не стоит автоматически переносить на все решения. Срочные параметры безопасности, например, требуют иной скорости реакции, чем финансирование долгосрочной инициативы. Управление, где любой вопрос проходит один и тот же медленный контур, может оказаться столь же хрупким, как управление, где каждое решение проталкивается за один короткий раунд.
Две палаты: голос токена плюс голос сообщества
Двухпалатная система пытается не свести управление к одной оси. У Optimism Collective есть Token House, где голосуют держатели OP, и Citizens’ House, где используется принцип «один участник — один голос», основанный на репутации и доказательстве личности. Иными словами, токеновое влияние и участие граждан сообщества представлены отдельными палатами.
Сильная сторона подхода — явное признание того, что у разных участников разные интересы. Держатели токенов имеют экономическую экспозицию, но экосистема шире баланса в кошельке: пользователи, разработчики и другие участники могут вносить вклад, который не выражается количеством токенов. В системе с отдельной палатой этот вклад можно учитывать иначе, чем капитал.
Цена — более сложная архитектура полномочий. Нужно определить, какие вопросы решает каждая палата, где требуется согласие обеих и что происходит при конфликте. Если полномочия размыты, система получает не баланс, а дополнительный уровень политического трения. Если же одна палата фактически может отменять решения другой, формальное разделение ничего не меняет.
Для DeFi-проекта выбор гибридной схемы имеет смысл, когда разные категории участников действительно несут разные риски и создают разную ценность. Не стоит добавлять репутационное голосование только потому, что оно выглядит прогрессивно: без понятных правил членства и защиты от сибилл-атак это будет еще один вектор манипуляции.
Управление — поверхность атаки, а не только механизм голосования
Уязвимость DAO может находиться не в формуле, а в последовательности операций: кто может предложить изменение, какой баланс учитывается, сколько длится голосование и когда результат становится исполнимым. Если governance-контракт соединен с казначейством или параметрами протокола без достаточной задержки, захват голосования превращается в прямой путь к активам.
В октябре 2020 года BProtocol использовал мгновенный заем на $7 млн в токенах MKR для манипуляции голосованием в MakerDAO. Этот эпизод показывает, почему в архитектуре важно учитывать временную структуру управления: если вес можно получить на короткий срок и использовать в подходящий момент, экономический доступ становится инструментом атаки.
В мае 2023 года злоумышленник внедрил модификацию самоликвидации в код Tornado Cash и вывел токены TORN из казначейства DAO через уязвимость системы управления. Здесь риск уже не сводится к тому, кто набрал больше голосов: опасность заключалась в том, что управление позволило изменить код и добраться до сокровищницы.
Практический вывод не в том, что всякое голосование токенами небезопасно. Уязвимость создается сочетанием условий — контроля над весом, слабых временных ограничений, недостаточной проверки кода и слишком прямого пути от принятого предложения к исполнению. Поэтому проекту нужно отдельно моделировать сценарий, в котором атакующий получает временное большинство, и сценарий, в котором легитимное большинство принимает вредоносное предложение.
При проектировании стоит задать несколько конкретных вопросов:
- Можно ли приобрести или занять голосующий вес непосредственно перед фиксацией снимка?
- Есть ли задержка между принятием предложения и его исполнением, достаточная для реакции сообщества?
- Какие действия доступны governance-контракту: изменение параметров, обновление кода, перевод средств из казначейства?
- Разделены ли права на предложенные изменения и права на исполнение?
- Может ли сообщество остановить исполнение подозрительного решения, и кто контролирует этот аварийный механизм?
Ответ «у нас все ончейн» здесь не аргумент. Ончейн-логика делает правила наблюдаемыми, но не превращает их в безопасные. Если контракт дает DAO полномочия перемещать активы, именно эти полномочия и становятся частью модели угроз.
Низкая явка: токенов много, активных голосов мало
Во многих популярных DAO явка опускается ниже 5–10%. Тогда даже аккуратно выбранная модель может дать перекошенный результат: небольшая группа активных участников решает за большую массу держателей, которые не следят за предложениями или не считают участие стоящим потраченного времени.
Это особенно заметно в модели 1 token = 1 vote. Если токены делегированы, часть держателей хотя бы передает голос активному делегату. Если не делегированы, их вес может просто оставаться без использования. Квадратичная схема не исправляет низкую явку автоматически; Conviction Voting требует, чтобы участники оставались вовлеченными достаточно долго; двухпалатная структура добавляет отдельный вопрос о том, кто именно получает статус участника второй палаты.
Вовлечение начинается не с напоминаний в соцсетях, а с качества процесса. Предложение должно описывать, что меняется в контракте или экономике протокола, кто получает выгоду, какой риск появляется и как будет измеряться результат. Если голосование требует разбираться в длинном governance-пакете, а последствия предложения спрятаны за технической терминологией, молчание держателей не удивительно.
При этом попытка поднять явку любой ценой тоже опасна. Награды за голосование могут стимулировать участие, но одновременно превращают его в фарминг: участник выбирает не то, что считает лучшим для протокола, а то, за что платят. Для проектирования полезнее разделять доступность участия и мотивацию голосовать: упрощать делегирование, показывать последствия предложения и не создавать иллюзию, что число проголосовавших само по себе означает качество решения.
Низкая явка — это не отдельная проблема интерфейса: она меняет фактическое распределение власти в DAO.
Как выбрать модель для конкретного DeFi-проекта
Начинать стоит не с модной схемы, а с типов решений. Управление параметрами риска, распределение грантов, обновление контрактов и расходование казначейства не обязаны проходить по одному контуру. Чем выше последствия ошибки, тем больше значения получают задержка исполнения, ограничение полномочий и возможность независимой проверки.
Для выбора модели полезно разложить решение на несколько слоев:
1. Определить, чьи интересы должно отражать голосование. Если решающим фактором является капитал под риском, токеновая модель понятна. Если важны вклад и участие, понадобится репутационная составляющая или отдельная палата.
2. Проверить концентрацию влияния. Считать нужно не только число держателей, но и реальную способность небольшого числа голосов провести предложение при текущей явке.
3. Задать правила фиксации веса. Snapshot, блокировка токенов и период голосования влияют на то, может ли краткосрочный поток ликвидности изменить результат.
4. Описать путь от голосования до исполнения. Принятое решение не должно незаметно превращаться в мгновенный доступ к казначейству или критическим функциям протокола.
5. Продумать защиту от сибилл-атак и низкой явки. Квадратичная формула без подтверждения уникальности участника не решает проблему множества кошельков; делегирование без анализа концентрации тоже не является нейтральным.
Модели управления децентрализованными протоколами не дают гарантий сами по себе. Классическая схема проста, но привязывает голос к капиталу; квадратичная смягчает отдачу от концентрации, но требует защиты от сибилл-атак; Conviction Voting вводит накопление поддержки во времени; двухпалатная архитектура позволяет учитывать разные группы, но требует четкого разграничения полномочий.
Мой рабочий критерий прост: хорошее DAO-управление должно выдерживать не только обычное голосование, но и плохой сценарий — низкую явку, временное скопление токенов, спорное обновление и ошибку в предложении, которое уже принято. Если проект не может ясно объяснить, кто получает власть, как она ограничена и что произойдет до исполнения решения, модель еще не готова к продакшену.
