Розробка Nouns-style DAO: аукціон, голосування, fork

Повний цикл розробки Nouns-style DAO

Ми розробляємо Nouns-style DAO з нуля. Nouns-style DAO — це щоденні аукціони, on-chain голосування та fork механіка. Кілька років тому Nouns DAO змінив уявлення про NFT та DAO: кожен день — один Noun на аукціоні, кожен Noun — один голос. Ні pre-mine, ні whitelist — тільки прозора on-chain система. Treasury перевищує 30 000 ETH, і система працює безперервно роками. Це не просто механіка, а дизайн-патерн, який ми відтворюємо для Lil Nouns, Gnars, Purple та інших проєктів.

Наша команда реалізувала понад 100 блокчейн-проєктів, включаючи кілька DAO-екосистем. Ми пропонуємо повний цикл: від проєктування до підтримки після запуску. Середня економія на газі порівняно з базовою реалізацією становить до 30%, що при поточних цінах ETH може означати тисячі доларів для активних учасників. Економія на аудиті при комплексному замовленні може сягати $5 000, а зниження газових витрат — до 30%.

Як працює щоденний аукціон?

Серце системи — контракт AuctionHouse. Кожні 24 години виставляється новий NFT. Ставки приймаються в ETH, останній bidder автоматично витісняє попереднього, отримуючи повернення. Якщо ставка зроблена ближче 15 хвилин до кінця — аукціон продовжується. Це захист від снєйпінгу. Ми використовуємо саме такий механізм з timeBuffer.

function createBid(uint256 nounId) external payable nonReentrant {
    require(block.timestamp < _auction.endTime, "Auction expired");
    require(msg.value >= reservePrice, "Below reserve");
    require(msg.value >= _auction.amount + ((_auction.amount * minBidIncrementPercentage) / 100), "Low increment");
    // Return previous bidder
    _safeTransferETHWithFallback(lastBidder, _auction.amount);
    // Update bid
    auction.amount = msg.value;
    auction.bidder = payable(msg.sender);
    // Extend if needed
    if (_auction.endTime - block.timestamp < timeBuffer) {
        auction.endTime = block.timestamp + timeBuffer;
    }
}

Чому on-chain artwork — це важливо?

Всі шари зображення зберігаються прямо в контракті — ніякого IPFS, ніякого централізованого сервера. Генерація SVG відбувається on-chain, що гарантує постійну доступність NFT, поки живий Ethereum. Ми використовуємо підхід NounsDescriptor з RLE-стисненням байт, що мінімізує газ. Reserve price зазвичай встановлюється на рівні 0.001 ETH, а timeBuffer — 15 хвилин.

Ключові компоненти системи

• NounsToken (ERC-721 + checkpoint voting) — кожен NFT є одиницею голосу. Замість стандартного ERC20Votes ми реалізуємо власну систему чекпоінтів, що зберігає історію голосування.
• AuctionHouse — механіка аукціону, описана вище.
• Governor — голосування з об'єкційним періодом: після закінчення голосування є 48 годин, коли тільки голоси «проти» приймаються. Це запобігає маніпуляціям в останню хвилину.
• Treasury (Timelock) — управління через governance.

Додатково: NounsDescriptor для on-chain SVG, NounsSeeder для випадкового seed (використовуємо Chainlink VRF для гарантії непередбачуваності).

Технічні деталі щодо газу: створення NFT з on-chain artwork витрачає близько 0.001 ETH при ціні газу 50 gwei. Аукціон споживає приблизно 100k gas на ставку. RLE-стиснення дозволяє зменшити розмір даних, що зберігаються, на 60%, що знижує вартість деплою на 40%. У наших проєктах використовується Foundry — він виконує тести в 5 разів швидше Hardhat, забезпечуючи покриття 99%.

Як fork захищає меншість?

Якщо великий holder не згоден із прийнятим proposal, він може ініціювати fork. Свої токени ескроуються, і при досягненні порогу (наприклад, 20% total supply) створюється нова DAO з пропорційною часткою treasury. Це альтернатива стандартному rage quit у Moloch-style DAO.

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

• Проєктування параметрів: тривалість аукціону, reserve price, розподіл founder allocation, quorum, поріг fork.
• Контракти NFT з on-chain або IPFS artwork.
• Інтеграція governance з fork механікою.
• Фронтенд: сторінка аукціону, галерея NFT, інтерфейс голосування.
• Повний набір тестів (Foundry) та аудит безпеки.
• Документація з розгортання та управління.
• Підтримка протягом 1 місяця після запуску.

Ми гарантуємо відсутність reentrancy, flash loan атак та інших вразливостей завдяки формальній верифікації та фазингу з Echidna.

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

1. Аналітика: узгодження параметрів та вимог.
2. Проєктування архітектури смарт-контрактів.
3. Розробка NFT контракту та artwork дескриптора.
4. Реалізація аукціонного дому.
5. Налаштування губернатора з fork механікою.
6. Тестування (unit + fork simulation + fuzzing).
7. Розгортання та фронтенд.
8. Підтримка після запуску.

Терміни та вартість

Орієнтовні терміни: від 8 до 16 тижнів залежно від складності artwork та кастомізації. Вартість розраховується індивідуально — залежить від обсягу контрактів, необхідності on-chain artwork та вимог до фронтенду. Зверніться до нас для консультації — ми оцінимо ваш проєкт за один робочий день і запропонуємо детальний план.

Порівняння з іншими підходами

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