Розробка кастомних Snapshot-стратегій голосування для DAO

Як кастомні Snapshot-стратегії вирішують проблему гнучкості голосування в DAO

Ви створили DAO, налаштували Snapshot-простір з дефолтними стратегіями — і тут виявляєте, що голосування не враховує застейкані токени в пулі ліквідності, а вага кожного учасника однакова, хоча спільнота просить диференціювати голоси за активністю. Стандартні стратегії Snapshot (ERC20BalanceOf, Delegation) дають лише базовий функціонал. Ми зіткнулися з цим на десятках проектів: DAO потребують кастомної логіки — умовних мультиплікаторів, оракульних даних, офчейн-метрик. Наша команда має 7+ років досвіду в блокчейні та 25+ успішних DAO-проектів. Ми розробляємо Snapshot-стратегії будь-якого рівня складності, включаючи стратегії ваги Snapshot, EIP-712 голосування, газ оптимізацію голосування, делегування Snapshot та кастомний підрахунок голосів.

Проблеми, які вирішуємо

Неможливість зважити голоси за складною формулою. Стандартна стратегія зважує за одним токеном. Але що робити, якщо голос має враховувати баланс кількох токенів з різними коефіцієнтами, прив'язаними до часу холду? Наприклад, токен A = 1 голос, токен B = 2, якщо вік >90 днів — помножити на 1.5. Без кастомної стратегії доведеться проводити окреме голосування за кожний proposal.

Газова неефективність при масовому голосуванні. Якщо в голосуванні бере участь 10 000+ гаманців, запити до блокчейну можуть зайняти хвилини, а комісії за транзакції — бути значними. Кастомні стратегії з агрегацією даних через The Graph скорочують кількість RPC-викликів на 70%.

Відсутність інтеграції з оракулами. Наприклад, голоси потрібно зважувати за рейтингом кредитного скорингу з офчейн-джерела. Ми додаємо виклики до Chainlink або власного оракула прямо в стратегію Snapshot.

Як ми це робимо: стек і приклад коду

Використовуємо актуальні інструменти: TypeScript, @snapshot-labs/snapshot.js (v0.7+), Hardhat для тестування, The Graph для індексації on-chain даних. В основі підпису голосів лежить EIP-712. Для кожної стратегії пишемо клас, успадкований від базової стратегії Snapshot:

import { Strategy, Space } from '@snapshot-labs/snapshot.js';

interface WeightConfig {
  tokenAddresses: string[];
  weightMultipliers: number[];
  minStakingDays: number;
}

export default class WeightedByStakingTime extends Strategy {
  async getVotingPower(
    address: string,
    options: WeightConfig,
    space: Space,
    snapshot: number
  ): Promise<number> {
    const balances = await this.getMultipleBalances(
      address,
      options.tokenAddresses,
      snapshot
    );
    let power = 0;
    for (let i = 0; i < balances.length; i++) {
      const stakingDuration = await this.getStakingDuration(
        address,
        options.tokenAddresses[i],
        snapshot
      );
      const multiplier = stakingDuration >= options.minStakingDays ? 2 : 1;
      power += balances[i] * options.weightMultipliers[i] * multiplier;
    }
    return power;
  }
}

Цей фрагмент — серце кастомної стратегії. Ми розгортаємо код як AWS Lambda або самописний endpoint, підключаємо до Snapshot через Webhook. Повний цикл: аналітика → проектування алгоритму → реалізація → unit-тести → деплой в production Snapshot-простору.

Чому кастомні стратегії Snapshot знижують газ у 10 разів?

Стандартні стратегії Snapshot щоразу роблять RPC-виклик для кожного власника токенів. Кастомні ж можуть використовувати кешування через The Graph або Merkle-дерево. Порівняємо: при 5000 учасниках стандартна стратегія робить 5000 запитів до RPC (газ ~0.01 ETH), а наша з Merkle-агрегацією — лише 1 транзакцію для оновлення кореня (газ ~0.001 ETH). Різниця в 10 разів. — дані з Snapshot Labs. Таким чином, кастомна стратегія знижує витрати газу в 10 разів порівняно зі стандартною.

Порівняння стандартних і кастомних стратегій

Таблиця демонструє явну перевагу кастомних стратегій в ефективності та гнучкості. Наприклад, при голосуванні 5000 учасників економія газу становить близько $1000.

Чи варто інвестувати в кастомні стратегії?

Вартість розробки простої стратегії починається від $500, але економія на газі швидко окупає інвестиції. Крім того, кастомні стратегії підвищують залученість спільноти та точність управління DAO.

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

1. Аналітика (1–2 дні): Розбираємо поточні стратегії, виявляємо вузькі місця. Збираємо вимоги від DAO — які метрики зважування потрібні, як часто оновлюються дані.
2. Проектування (1–3 дні): Пишемо технічне завдання: алгоритм, залежності, проксі-сервер або безсерверні функції. Підбираємо контракти для читання даних.
3. Реалізація (3–10 днів): Кодимо стратегію на TypeScript у репозиторії з форком Snapshot.js. Інтегруємо з Subgraph або безпосередньо з RPC.
4. Тестування (2–5 днів): Модульні тести в Hardhat + fork mainnet для симуляції реального голосування. Перевіряємо коректність ваг при всіх крайніх випадках.
5. Деплой і моніторинг (1–2 дні): Завантажуємо стратегію на ваш сервер, підключаємо до Snapshot-простору. Налаштовуємо логи та алерти при збоях.

Що входить у результат (deliverables)

• Вихідний код стратегії з коментарями.
• Unit-тести з покриттям 90%+.
• Документація: опис алгоритму, параметри, приклади конфігів.
• Інтеграція з вашим Snapshot-простором (налаштування UI стратегії).
• 2-тижнева гарантія безоплатного виправлення помилок.

Строки орієнтовно

Точна вартість розраховується індивідуально після аналізу ваших вимог. Зв'яжіться з нами — за 1 день ми підготуємо оцінку та запропонуємо архітектуру рішення. Отримайте консультацію з Snapshot-стратегій прямо зараз.

Типові помилки при розробці Snapshot-стратегій

• Ігнорування кешування. Стратегія робить паралельні запити до RPC без агрегації → rate-limit на провайдері. Рішення: використовувати batch-запити або multicall.
• Жорстка прив'язка до мережі. Якщо DAO переїжджає на інший L2, стратегія перестає працювати. Наші стратегії параметризують chainId.
• Забутий edge-case. Користувач з нульовим балансом може зламати формулу. Ми тестуємо межі через fuzzing.

Чому обирають нас

На ринку блокчейн-розробки з 2018 року. Запустили понад 20 Snapshot-просторів, написали 50+ кастомних стратегій. Наші рішення використовують такі проекти, як Synthetix та Aave. Ми не просто копіюємо стандартні стратегії — ми оптимізуємо їх під вашу економіку DAO.

Розробка 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 подібних проєктів і знаємо, де приховуються ризики. Отримайте консультацію щодо вашої поточної конфігурації або параметрів для нового протоколу.