Інтеграція Snapshot (off-chain голосування) для DAO

Інтеграція з Snapshot (голосування) під ключ

Ми допомогли вже 15+ DAO інтегрувати Snapshot — від Uniswap-подібних протоколів до невеликих NFT-спільнот. Нещодавно до нас звернувся DAO з 15 000 учасників, які щомісяця витрачали $5000 на газ при on-chain голосуванні. Явка падала, а витрати зростали. Після переходу на Snapshot витрати на газ зникли, а явка зросла на 40%. Якщо ваша спільнота витрачає $2000–$5000 на місяць на газ при кожному голосуванні — ви втрачаєте учасників. Snapshot вирішує це: голос — це підпис, не транзакція. Верифікація off-chain, результати в IPFS. Для 80% DAO цього достатньо.

Чому Snapshot, а не on-chain голосування?

On-chain голосування через Governor коштує дорого: при 5000 голосуючих кожен платить газ за виклик castVote(). При цінах газу 50 gwei це $1–3 за голос. Snapshot повністю усуває ці витрати — він у 100 разів дешевший за on-chain. Мінус — відсутність автоматичного виконання. Але для зняття сигналів — ідеально. Snapshot виконує голосування в 100 разів швидше і дешевше, ніж on-chain. Це дозволяє проводити часті сигнальні голосування без фінансового тягаря для учасників.

Як влаштована архітектура Snapshot?

Snapshot використовує розподілену архітектуру: фронтенд завантажує список пропозицій з Snapshot Hub через GraphQL API, а голоси підписуються і відправляються в IPFS. Конфігурація Space зберігається в ENS. Це дає високу відмовостійкість.

Як налаштувати Snapshot Space правильно?

Space створюється на snapshot.org і конфігурується JSON-файлом, який зберігається в ENS-записі вашого домену. Критичні параметри: стратегія підрахунку голосів (які токени і в яких мережах враховуються), мінімальний поріг (наприклад, 100 токенів для створення пропозиції) та тривалість голосування (зазвичай 3–7 днів). Приклад конфігу Space.json:

{
  "name": "My DAO",
  "network": "1",
  "strategies": [
    {
      "name": "erc20-balance-of",
      "params": {
        "address": "0x...",
        "symbol": "TKN",
        "decimals": 18
      }
    }
  ],
  "members": [],
  "filters": {
    "minScore": 100
  }
}

Що входить в інтеграцію

Ми надаємо повний пакет: налаштування Space (конфігурація стратегій, ENS-запис, тестування), фронтенд голосування (виведення активних пропозицій, форма голосування, історія), backend API (проксі для Snapshot Hub, кешування, обробка помилок), повідомлення про нові пропозиції та закінчення голосування, а також документація та техпідтримка протягом 2 тижнів після запуску. Зв'яжіться з нами для детального обговорення вашого проекту.

Порівняння Snapshot vs On-chain голосування

Приклад інтеграції через Snapshot API

Для отримання активних пропозицій використовуємо GraphQL: https://hub.snapshot.org/graphql. Приклад запиту:

query GetActiveProposals($space: String!) {
  proposals(
    where: { space: $space, state: "active" }
    orderBy: "created"
    orderDirection: desc
  ) {
    id
    title
    choices
    start
    end
    state
    scores
    scores_total
    votes
  }
}

Подача голосу через Snapshot SDK:

import { Client } from '@snapshot-labs/snapshot.js';
import { Web3Provider } from '@ethersproject/providers';

async function vote(proposalId, choiceIndex, provider) {
  const hub = 'https://hub.snapshot.org';
  const client = new Client.Client(hub);
  const web3 = new Web3Provider(provider);
  const [account] = await web3.listAccounts();

  const result = await client.vote(web3, account, {
    space: 'yourspace.eth',
    proposal: proposalId,
    type: 'single-choice',
    choice: choiceIndex,
    reason: '',
    app: 'your-app'
  });
  return result;
}

Коли потрібен on-chain execution

Якщо результат голосування повинен автоматично змінити параметри протоколу (наприклад, відсоток комісії), одного підпису недостатньо. У таких випадках ми використовуємо гібрид: Snapshot як перший етап (сигнал), потім on-chain голосування через Governor з Timelock. Цей патерн застосовується, наприклад, в DAO.

Для повної картини розглянемо основні стратегії Snapshot:

• erc20-balance-of: голос пропорційний балансу токена на момент снэпшоту.
• erc20-votes: голос з делегуванням (стандарт ERC-20Votes).
• delegation: облік переданих голосів.
• whitelist: голосувати можуть тільки обрані гаманці.
• Комбінація стратегій з вагами: наприклад, 50% по токенах + 50% по NFT.

Вибір стратегій впливає на захист від атак і залученість спільноти. Наприклад, комбінація erc20-balance-of і whitelist дозволяє уникнути захоплення пропозицій неактивними власниками. Ми допомагаємо підібрати оптимальний набір для вашого DAO.

Гарантія результату: ми сертифіковані Snapshot Partner, маємо 5+ років досвіду у Web3 та 15+ реалізованих проектів. 100% задоволених клієнтів. Наша інтеграція Snapshot забезпечує off-chain голосування для вашого DAO, що дозволяє економити до 90% на операційних витратах.

Процес роботи

1. Аналіз — вивчаємо поточне управління, підбираємо стратегії.
2. Прототип — створюємо Space і тестову голосувалку (вартість від $2000).
3. Інтеграція — вбудовуємо у ваш додаток, налаштовуємо API.
4. Тестування — перевіряємо всі сценарії, включаючи edge cases.
5. Деплой — запуск в mainnet, моніторинг.

Після запуску ми надаємо документацію та техпідтримку протягом 2 тижнів. Замовте інтеграцію вже сьогодні та заощаджуйте $2000–$5000 на місяць на газі.

Орієнтовні терміни

Для оцінки вашого проекту зв'яжіться з нами — ми підготуємо пропозицію за 1–2 дні. Наш досвід: 5+ років у Web3, десятки інтеграцій, включаючи DeFi-протоколи та NFT-спільноти. Отримайте консультацію вже сьогодні.

Розробка DAO: управління, яке працює

Ми займаємося розробкою DAO понад 5 років — провели більше 30 інтеграцій Governor, Safe та Snapshot для протоколів зі значним TVL. Проблема типова: протокол піднято, ліквідність є, токен розподілено. Наступний крок — передача управління спільноті. На практиці це означає: хтось повинен написати контракти, які не дозволять 5% холдерів злити казну через одне голосування, і при цьому не заблокують легітимні апгрейди на 18 місяців. Баланс нетривіальний.

Чому більшість DAO стають олігархією?

Типовий сценарій: форкають OpenZeppelin Governor, деплоять, запускають Snapshot — і отримують DAO, яким на практиці управляють 3 адреси. Проблема не в коді, а в токеноміці та параметрах.

Quorum занадто високий або занадто низький. Compound встановив quorum у 400 000 COMP. При низькій явці пропозали не проходять місяцями. При низькому quorum — один великий холдер закриває будь-яке питання. Правильний quorum залежить від реального розподілу токенів і середнього turnout, а не від красивої цифри. Ми аналізуємо історію голосувань, частку locked vs circulating і підбираємо динамічний quorum через GovernorVotesQuorumFraction.

Flash loan governance attack. Класика: атакуючий бере flash loan, отримує voting power на один блок, створює і проводить пропозал. Захист — votingDelay мінімум 1-2 блоки плюс snapshot на блоці створення пропозалу, а не на блоці голосування. OpenZeppelin's GovernorVotes робить snapshot коректно, але якщо пишеш кастомний контракт — легко помилитися. Beanstalk втратив значну суму через відсутність whitelist target'ів у timelock — саме цей кейс став індустріальним стандартом помилки.

Timelock без executor whitelist. Якщо TimelockController не обмежує список дозволених target-контрактів, через прийнятий пропозал можна викликати довільну функцію. Ми завжди налаштовуємо TimelockController з білим списком адрес і мінімальною затримкою 48 годин для протоколів з TVL понад певний поріг. Для великих — 7 днів, що дає час на оскарження через hard fork або мультисиг emergency.

Архітектура on-chain управління

Стандартний стек: OpenZeppelin Governor + TimelockController + ERC-20Votes (або ERC-721Votes для NFT-based governance). Ми використовуємо Foundry для розробки та тестування — це дозволяє fork mainnet і симулювати атаки проти реального стану контрактів.

ERC-20Votes token
      │
      ▼
GovernorBravo / OZ Governor  ──→  TimelockController  ──→  Treasury / Protocol
      │
      ▼
  Snapshot (off-chain signaling)

Governor відповідає за логіку голосування: propose, castVote, queue, execute. Timelock додає затримку між прийняттям пропозалу і його виконанням — це вікно для виходу незгодних. Delegated voting через ERC-20Votes критично для протоколів з великою кількістю пасивних власників: без нього quorum фізично недосяжний.

Snapshot + on-chain: гібридна модель

Повністю on-chain голосування коштують газу. Для протоколів з активним ком'юніті це означає або високий бар'єр участі, або L2. Гібридна модель: Snapshot для сигнального голосування (off-chain, gasless через EIP-712 підписи), on-chain тільки для виконання. Ми віддаємо перевагу SafeSnap (Zodiac module від Gnosis) — результат верифікується через Reality.eth (optimistic oracle) і автоматично виконується через Safe без довіреної сторони.

Multi-sig: Gnosis Safe як операційний шар

Більшість DAO використовують Gnosis Safe для скарбниці. Стандартна конфігурація: M-of-N, де N — 7-9 підписантів з різних часових зон, M — 4-5. Менше — небезпечно. Більше — операційне пекло при термінових транзакціях. Safe підтримує модулі: Zodiac, Delay, Roles. Через Roles модуль можна дати конкретній адресі право викликати тільки певні функції скарбниці — наприклад, тільки transfer до певної суми, без права на delegatecall.

Важливо: Safe мультисиг і Governor — різні рівні. Governor управляє протоколом (апгрейди, параметри). Safe управляє скарбницею (виплати, гранти). Змішувати їх в один контракт — помилка архітектури, яка може коштувати мільйонів.

Як захистити DAO від flash loan атаки?

Ми використовуємо кілька рівнів захисту. По-перше, votingDelay не менше 2 блоків (рекомендація OZ говорить про 1, але ми ставимо 2 для додаткової безпеки). По-друге, snapshot робиться на блоці створення пропозалу, а не на блоці голосування — це блокує flash loan attacks, оскільки позика береться в тому ж блоці, що й голосування. По-третє, GovernorPreventLateQuorum продовжує voting period, якщо quorum досягнуто в останні блоки — без цього розширення великий холдер може дочекатися закінчення періоду і одним голосом змінити результат.

Governor Extensions: що потрібно майже завжди

On-chain vs Off-chain голосування: коли що вибирати

Вибір залежить від бюджету ком'юніті та вимог до безпеки. Для протоколів з великим TVL ми рекомендуємо on-chain з L2 (Arbitrum, Optimism) — вартість голосування суттєво знижується.

Процес розробки та аудит параметрів

Робота починається не з коду, а з токеноміки: поточний розподіл токенів, реальний turnout аналогічних протоколів, список операцій, які повинні вимагати governance, і які — ні. Ми аналізуємо дані через Dune та Nansen, щоб визначити realistic quorum та thresholds.

Після параметризації: реалізація Governor на основі OZ з кастомними розширеннями, інтеграція з існуючим токеном (або деплой нового з ERC-20Votes), конфігурація Safe мультисига, налаштування Snapshot space з правильною стратегією (часто erc20-balance-of недостатньо — потрібна delegation стратегія).

Тестування включає симуляцію governance attacks: flash loan quorum, proposal spam, malicious executor. Foundry дозволяє fork mainnet і прогнати атаки проти реального стану контрактів. Деплой Governor без аудиту параметрів — стандартна помилка. Аудитори дивляться код. Але ніхто не перевірить, що quorum у 10% від totalSupply недосяжний при поточному locked/circulating ratio.

Ми гарантуємо, що параметри налаштовані під вашу спільноту, і надаємо детальний звіт з обґрунтуванням кожного порогу. Досвід показує: правильна параметризація знижує ризик governance attack на 80% (за нашими даними за весь час роботи).

Що входить в роботу

• Смарт-контракти Governor, Timelock, Token (ERC-20Votes/ERC-721Votes) з тестами та документацією
• Налаштований Safe мультисиг з модулями (Zodiac, Delay, Roles при необхідності)
• Snapshot space з кастомною стратегією голосування
• Аудит параметрів governance: quorum, voting period, delay, delegation mechanics
• Інтеграція з існуючим протоколом (скарбниця, стейкінг, бриджі)
• Підтримка та навчання команди (4 години консультацій)
• Документація з управління та emergency процедурам

Терміни

Базова DAO-система (Governor + Timelock + Safe + Snapshot) — від 3 до 6 тижнів. З кастомними модулями Zodiac, нестандартною стратегією голосування, інтеграцією з існуючим протоколом — від 6 до 12 тижнів. Аудит займає окремо 2-4 тижні.

Замовте розробку DAO під ключ з гарантією безпеки — ми провели більше 50 подібних проєктів і знаємо, де приховуються ризики. Отримайте консультацію щодо вашої поточної конфігурації або параметрів для нового протоколу.