Платформы для управления DAO: вердикт по выбору

Архитектурный разлом: почему Aragon и Snapshot — это вообще разные звери

Это набор прав и полномочий, закреплённых за смарт-контрактами, плюс слой координации между держателями этих полномочий. И вот тут начинается самое интересное: когда мы выбираем между Aragon OSx и Snapshot, мы на самом деле выбираем не "инструмент голосования", а архитектурный режим — ончейн или офчейн, с жёсткой привязкой к коду или с гибкой политической прослойкой сверху. Это принципиально разные дизайн-философии, и путать их — всё равно что сравнивать базу данных с интерфейсом к этой базе.

Aragon OSx — это смарт-контрактный фреймворк для ончейн-организаций. То есть, грубо говоря, ваша DAO существует как набор контрактов в EVM-совместимой сети: там лежат активы казначейства, прописаны разрешения, и каждый approve — это транзакция, которая меняет состояние чейна. Никакой магии, никаких подписей сообщений через EIP-712 вне сети. Snapshot в классическом режиме — это совершенно другая штука: интерфейс и протокол для офчейн-голосования, где пользователь подписывает сообщение кошельком, голоса агрегируются на бэкенде, и ни одна транзакция не уходит в мемпул. Газ не сжигается, баланс кошелька не двигается, но и смарт-контракт ничего не знает о вашем волеизъявлении, пока вы явно не прикрутите execution-слой.

Здесь критически важно держать в голове одну вещь: отсутствие газа для участника голосования ≠ отсутствие расходов для DAO. Когда мы говорим про классический Snapshot, пользователь действительно не платит за клик по кнопке "За". Но сама инфраструктура исполнения решения — это либо Snapshot X, либо SafeSnap + Reality.eth, либо релей-сервис, либо вообще ручной multisig, который должен прочитать результат и подписать транзакцию. И вот эти расходы ложатся на инициатора предложения или на операторов казначейства. Так что тезис "Snapshot бесплатный" — это такая же мемная чушь, как "Ethereum слишком дорогой для DeFi": в обоих случаях затраты просто перераспределяются между участниками, а не исчезают.

Ончейн-DAO — это код, который сам себя исполняет. Офчейн-DAO — это код, который ждёт, пока кто-то его исполнит. Это разница между лицензионным соглашением и перемирием.

Прежде чем нырять в детали, зафиксируем: эти платформы решают разные задачи. Aragon закрывает вопрос "как сделать так, чтобы активы казначейства жили в смарт-контракте, доступ к которым регулируется кодом". Snapshot закрывает вопрос "как собрать волю участников дёшево и быстро, без необходимости голосовать каждый раз токеном в мемпуле". И когда вы строите реальное управление, вам, скорее всего, понадобятся оба слоя — и про это мы ещё поговорим в разделе про интеграции.

Механика Aragon OSx: плагины как конструктор Lego для полномочий

Если вы до сих пор думаете, что Aragon — это просто интерфейс для создания "DAOшки с токеном", вы безнадёжно отстали от архитектуры. Текущий Aragon OSx — это модульная система, где сама DAO-организация представляет собой минимальное ядро с базовыми правами (да, буквально permissions на уровне бит), а вся бизнес-логика — управление, членство, казначейство, делегирование, мультисиг — реализуется через плагины. Плагин — это просто смарт-контракт, который подключается к DAO через систему разрешений и получает право на определённые действия. Хотите поменять правила голосования? Установили новый плагин. Хотите поменять механизм кворума? Поставили другой governance-плагин. Хотите кастомный multisig вместо токен-голосования? Пожалуйста — есть мультисиг-плагин, и он, кстати, работает принципиально иначе, чем голый Safe.

Вот тут начинается деталь, которую пропускают почти все обзоры. В мультисиг-плагине Aragon каждый одобряющий (approver) подтверждает предложение непосредственно ончейн — то есть шлёт транзакцию через контракт плагина, а не подписывает EIP-712-сообщение и не передаёт офчейн-агрегированную подпись через релей. Это даёт принципиально другую модель безопасности: вы видите все подтверждения в блокчейн-эксплорере, у каждого approve есть свой gas (который, к слову, кто-то должен заплатить), и порог подтверждений настраивается жёстко — например, 4 из 7, или 2 из 5. Минимальный порог — от 1 до числа одобряющих, ни больше, ни меньше, потому что плагин просто отклонит транзакцию, если threshold выйдет за эти рамки. Звучит банально, но именно такая конфигурируемость делает Aragon гибче голого Safe, хотя и сложнее в эксплуатации (плагин — это ваш контракт, а значит, ваш аудит, ваша ответственность).

Токенизированное голосование в Aragon — это тоже плагин (governance plugin), и он подключается по тому же принципу: контракт получает разрешение на чтение балансов голосующих токенов (через стратегию, по аналогии со Snapshot, но ончейн), и после достижения кворума и одобрения предложения — триггерится исполнение через тот же permissions layer. Делегирование голосов поддерживается на уровне токена (ERC20Votes или ERC20WithDelegation), казначейские операции — отдельный плагин treasury, а если вам лень писать контракты руками — есть no-code-интерфейс Aragon, где можно собрать DAOшку через визуальный конструктор, как Tinkercad для организаций (только вместо кубиков у вас — permissioned actions и upgradeable proxies).

Но есть и обратная сторона. Все эти плагины — это ваш attack surface. Каждый плагин — это потенциальная уязвимость, потому что любой апгрейд DAO (смена governance-логики, изменение списка approvers, модификация казначейских правил) идёт через вызовы, которые могут быть скомпрометированы через reentrancy, фронтран транзакций при апгрейде, или просто через банальный баг в кастомном модификаторе. И хотя документация Aragon обновляется регулярно (в 2025–2026 мы видим активную работу над OSx и плагинами), никто не назовёт Aragon безусловно безопасной платформой — уровень риска зависит от того, какие именно плагины вы поставили, как настроили разрешения, и кто контролирует ключи администратора у этих плагинов (да, в Aragon есть owner-роль, и это тоже часть дизайна, а не баг).

Плагинная архитектура Aragon — это палка о двух концах: максимальная модульность означает, что вы сами проектируете поверхность атаки своей организации.

Эволюция Snapshot: от газлесс-голосования до ончейн-протокола

Классический Snapshot появился как ответ на конкретную боль 2020–2021 года: голосование токеном ончейн стоило $50–$300 в Ethereum mainnet, и каждое DAO-решение превращалось в лотерею с комиссией. Snapshot решил проблему радикально — вынес голосование из блокчейна. Пользователь подписывает сообщение кошельком через EIP-712, бэкенд Snapshot агрегирует подписи, считает voting power по заранее заданной стратегии, и всё — предложение "принято" в том смысле, что большинство подписантов сказали "За". Никакого газа, никаких транзакций, мгновенный фидбек.

И вот тут начинается та часть, которую дегены обычно не догоняют: классический Snapshot не исполняет ничего. Это платформа записи воли, а не исполнительный механизм. Чтобы результат голосования превратился в транзакцию, вам нужен отдельный слой. И Snapshot сам это понимает — поэтому параллельно существует Snapshot X, который, по сути, является протоколом со смарт-контрактами для EVM-сетей и Starknet, где предложение, голосование и исполнение происходят ончейн с автоматическим триггером после достижения кворума и одобрения. То есть Snapshot X — это попытка приблизиться по архитектуре к Aragon, сохранив при этом гибкость настройки voting strategies.

Стратегии в Snapshot — это отдельная вселенная. Документация говорит о более чем 400 доступных стратегиях: на базе ERC-20, ERC-721, ERC-1155, делегированных токенов, белых списков (whitelisted addresses), NFT-балансов, чистого ETH-баланса, и даже внешних API. Это значит, что вы можете построить voting power практически из чего угодно — хотите голосовать по количеству выпущенных NFT определённой коллекции? Пожалуйста. Хотите дать голос только тем, кто прошёл KYC через внешний сервис? Можно, если подключите соответствующую стратегию. Причём для обычных пространств (space) можно комбинировать до 8 стратегий одновременно, а для платных Snapshot Pro — до 10. Это даёт возможности для curve-based governance, multi-token voting, и прочих извращений, которые в Aragon пришлось бы программировать руками через кастомный governance-плагин.

Но есть критический нюанс, который ломает романтику газлесс-голосования. Классический Snapshot не меняет состояние смарт-контрактов. Ваш голос — это подпись, не транзакция. И если вы не подключили execution layer (через Snapshot X, или через SafeSnap + Reality.eth, или через кастомный релей), то итоговое "одобрено" будет висеть в Snapshot как красивая картинка до тех пор, пока какой-нибудь multisig-кипер не соблаговолит прочитать результат и подписать соответствующую транзакцию вручную. Это, кстати, одна из самых частых причин, почему мелкие DAO "зависают" в управлении: голосование прошло, все "за", а реальное действие не происходит неделями — потому что никто не прикрутил execution.

Snapshot без исполнения — это социологический опрос, а не решение. Snapshot X и SafeSnap превращают его в решение, но добавляют ончейн-расходы и новые точки отказа.

SafeSnap как мост между мирами: как офчейн-голосование триггерит ончейн-казначейство

Если вы дочитали до этого момента, у вас в голове наверняка сложилась картина: Aragon — это ончейн всё, Snapshot — это офчейн голосование, а реальный мир — это гибрид. И вот тут на сцену выходит SafeSnap — интеграция, которая превращает классический Snapshot в исполнительный механизм для казначейства Safe (бывший Gnosis Safe). Архитектура выглядит так: вы создаёте предложение в Snapshot, участники голосуют (офчейн, без газа), после завершения голосования результат передаётся в Reality.eth — оракул, который задаёт вопрос "правда ли, что X% участников проголосовали за?". Если Reality.eth получает подтверждение (через bond-механику, где любой может ответить, заложив токены, и оспорить ответ, заложив больше), то после успешного разрешения вопроса начинается 24-часовой cooldown, и только после этого транзакция становится доступной для исполнения через казначейство Safe.

Зачем нужен этот 24-часовой лаг? Это protection layer на случай, если ваше DAO подверглось governance-атаке: злоумышленник смог провести голосование, Reality.eth подтвердил результат, но у участников есть сутки, чтобы увидеть, что происходит, поднять тревогу, и (если казначейство настроено с задержкой исполнения) — отменить или заморозить выполнение. По сути, SafeSnap превращает Snapshot в систему с soft execution: голосование быстрое, исполнение — медленное и проверяемое. Это разумный компромисс для проектов, которые хотят UX от Snapshot, но не готовы доверять классическому multisig-киперу "на слово".

Но не надо думать, что SafeSnap — серебряная пуля. Bond-механика Reality.eth подразумевает, что кто-то должен заложить токены, чтобы ответить на вопрос оракула. Если никто не мониторит, или если стоимость bond ниже потенциального ущерба, то атакующий может просто выкупить ответ и провести вредоносное предложение. Плюс — сама интеграция требует настройки: вы должны задеплоить Safe, подключить его к вашему Snapshot space, настроить execution-стратегию, указать адрес оракула и его параметры. Это не "нажал кнопку — работает", а полноценная инженерная задача. И документация SafeSnap обновлялась примерно за два месяца до момента сбора этой фактуры — то есть проект живой, но и не сказать, что статичный.

Отдельно стоит сказать про Snapshot X, потому что это, по сути, попытка объединить гибкость стратегий Snapshot с архитектурой Aragon. В Snapshot X предложение — это смарт-контракт, voting power рассчитывается ончейн через те же стратегии (только теперь в виде контрактов, а не бэкенд-скриптов), и после одобрения предложения исполнение происходит автоматически, без координирующего multisig. Поддерживаются EVM-сети и Starknet, что даёт определённую гибкость по газу — можно выбрать L2, где транзакции копеечные, и получить ончейн-управление почти по цене классического Snapshot. Но — и это важно — Snapshot X пока не вытеснил классический режим. Два режима сосуществуют, и для обычного пользователя разница между ними неочевидна, что порождает путаницу в ожиданиях: люди голосуют в Classic, думая, что что-то произойдёт автоматически, а потом удивляются, почему их "одобренное" предложение никто не исполняет.

Сравнение режимов: где каждая платформа реально работает

Давайте соберём в одну таблицу то, что мы разобрали по кусочкам, чтобы не прыгать между разделами.

Эта таблица — не "что лучше", а карта компромиссов. Aragon даёт вам максимум контроля над тем, как код DAO принимает решения, но требует, чтобы вы (или ваш аудитор) понимали каждый плагин, который вы подключили. Snapshot Classic даёт вам максимум гибкости в настройке голосования (400+ стратегий — это серьёзно), но перекладывает исполнение на внешний слой, и если этот слой не настроен — вы получите голосование без последствий. Snapshot X пытается закрыть этот разрыв, но пока остаётся менее зрелым, чем оба "родительских" режима.

Неочевидные уязвимости, о которых молчат маркетинговые страницы

Теперь — самое вкусное. Мы обсудили, как устроены платформы, но не обсудили, где они ломаются. И это, пожалуй, главное, что отличает реальное понимание DeFi-инфраструктуры от её маркетинговой презентации.

Во-первых, governance capture через распределение токенов. Ни Aragon, ни Snapshot не спасут вас, если 51% вашего governance-токена сосредоточен у трёх кошельков. Это банально, но об этом забывают постоянно. Платформа — это инструмент, а не гарантия децентрализации. В Aragon плагин токен-голосования честно посчитает балансы и проведёт предложение, даже если за ним стоит один кит. В Snapshot стратегия на базе ERC-20 баланса сделает ровно то же самое. Распределение токенов — это ваша ответственность, не платформы.

Во-вторых, фронтран апгрейдов плагинов в Aragon. Поскольку плагины — это апгрейдабельные контракты, любая транзакция по смене governance-логики может быть прочитана из мемпула и проанализирована до включения в блок. Если у вас короткий timelock (или его нет вообще), атакующий может попытаться перехватить апгрейд или запустить свой параллельный. Это не специфическая уязвимость Aragon как фреймворка — это общая проблема upgradeable-контрактов. Но именно в плагинной архитектуре, где вы регулярно добавляете и заменяете модули, поверхность атаки шире, чем в монолитном контракте.

В-третьих, слэшинг стимулов в Snapshot. Когда вы голосуете офчейн, у вас нет skin in the game на уровне блокчейна. Вы подписали сообщение — и всё. Никто не может вас наказать за то, что вы проголосовали за идиотское предложение, или, наоборот, заблокировать вас за то, что вы голосуете против большинства. Это и плюс (низкий порог входа), и минус (никакой ответственности). В ончейн-системах Aragon голосующий платит газ за каждый голос — это создаёт хотя бы минимальный экономический фильтр против спама, хотя и не является настоящим механизмом слэшинга.

В-четвёртых, оракульная зависимость SafeSnap. Как мы обсуждали, SafeSnap полагается на Reality.eth для разрешения споров о результатах голосования. Если оракул скомпрометирован, или если стоимость bond ниже стоимости атаки — злоумышленник может провести любое предложение. Это не уязвимость Safe как такового, а уязвимость связки Snapshot + оракул + казначейство. И чем длиннее цепочка между "участник нажал кнопку" и "транзакция исполнена", тем больше точек доверия.

В-пятых, админ-ключи, которые "забывают" убрать. Я видел десятки DAO, где после деплоя остаётся owner-роль у команды разработки, которая теоретически может апгрейдить плагины, менять разрешения или вообще слить казначейство. Ни Aragon, ни Snapshot не заставляют вас отказаться от admin-ключей — это ваш выбор. Но если вы оставили timelock на апгрейды короче, чем период активного мониторинга сообщества, ваша "децентрализация" — это фикция, независимо от того, на какой платформе вы построены.

Архитектура платформы определяет форму возможных атак. Но вероятность атаки зависит от распределения токенов, качества аудита плагинов, длины timelock'ов и того, насколько внимательно сообщество читает, за что голосует.

Критерии выбора: когда переходить от гибкости к жёсткому ончейн-контролю

Теперь — собственно вердикт, ради которого вы, вероятно, и открыли эту статью. Когда использовать Aragon, когда Snapshot, и когда их гибрид?

Aragon OSx имеет смысл, если:

• Активы казначейства крупные (от десятков миллионов долларов), и вам нужен код, а не договорённости.
• У вас есть инженерная команда (или аудитор), которая способна написать и проверить кастомные governance-плагины.
• Governance-логика нестандартная (например, quadratic voting, conviction voting, holographic consensus) и не покрывается стандартными шаблонами.
• Вы хотите, чтобы каждое решение оставляло ончейн-след, видимый в блокчейн-эксплорере, без необходимости сверять результаты голосования с ручным исполнением.
• Вы готовы платить газ за каждый голос, и ваше сообщество достаточно мотивировано, чтобы голосовать часто.

Snapshot Classic имеет смысл, если:

• Голосование частое, а суммы небольшие (плата за газ будет раздражать участников).
• Вам нужна тонкая настройка voting power (NFT-балансы, делегирование, white-листы, комбинации стратегий до 8 штук на space), которую проще сконфигурировать, чем кодить.
• Исполнение решений всё равно идёт через внешний multisig (Safe), и у вас есть доверенные операторы, готовые подписывать транзакции после одобрения.
• Сообщество принимает модель "голосуем, потом ждём, пока кто-то исполняет" и не требует автоматического исполнения.
• Вы хотите быстро итерировать параметры голосования (стратегии, кворум, voting period) без передеплоя контрактов.

Snapshot X имеет смысл, если:

• Вам нужна гибкость стратегий Snapshot, но с автоматическим ончейн-исполнением.
• Вы готовы экспериментировать с менее зрелой архитектурой и понимаете риски.
• Активы казначейства не настолько велики, чтобы оправдать кастомные плагины Aragon, но достаточно серьёзны, чтобы хотеть ончейн-гарантий исполнения.

SafeSnap-интеграция имеет смысл, если:

• Вы используете классический Snapshot, но хотите, чтобы одобренные предложения реально исполнялись казначейством Safe.
• У вас есть бюджет на bond-механику Reality.eth и готовность мониторить оракул.
• Вам нужен 24-часовой cooldown как последний рубеж обороны перед исполнением.

И не забывайте, что никто не запрещает гибрид. Реальные зрелые DAO часто используют Aragon (или кастомные смарт-контракты) для критичных казначейских операций и Snapshot для оперативных голосований по параметрам, сигналов настроений сообщества и неформальных решений, которые не требуют немедленного исполнения. Это не "выбрать одно" — это спроектировать стек, где каждый слой делает то, что у него получается лучше всего. В этом смысле вопрос "Aragon или Snapshot" — это примерно как вопрос "PostgreSQL или Redis": ответ почти всегда "оба, для разных задач", если только ваш проект не настолько мал, что один инструмент покрывает все потребности.

Кстати, если вас интересует более широкий контекст того, как устроены сравнения и выбор инструментов в крипто-пространстве (не только по DAO-платформам, а вообще по Web3-стеку), стоит посмотреть на разбор критериев выбора в Web3 — там объясняют, почему "сравнение" в децентрализованном мире работает иначе, чем в традиционном софте.

Финальный вердикт

Если формулировать максимально коротко: Aragon — это инфраструктура, Snapshot — это координация. Когда вы выбираете между ними, вы на самом деле отвечаете не на вопрос "какая платформа круче", а на вопрос "где в моей организации проходит граница между кодом, который исполняется автоматически, и социальным слоем, который договаривается". В серьёзных DAO эта граница проведена явно: крупные казначейские операции — ончейн через Aragon или кастомные контракты с multisig, оперативное управление параметрами — через Snapshot с исполнением через Safe. В небольших проектах часто хватает одного слоя, и тогда выбор диктуется размером казначейства и сложностью governance-логики.

Главное, чего нельзя делать — выбирать платформу по принципу "у них больше стратегий" или "у них круче интерфейс". Эти критерии важны для UX, но они не отвечают на вопрос о безопасности и устойчивости управления. Распределение токенов, качество аудита плагинов, длина timelock'ов и наличие админ-ключей — это вещи, которые значат больше, чем выбор между Aragon и Snapshot. Платформа — это инструмент. Децентрализация — это процесс. И инструмент без процесса — это просто код, который кто-то другой однажды эксплуатирует.