Інтеграція з OpenZeppelin Governor

Розробка оптимістичного governance (optimistic approval)

Optimistic governance — інверсія класичної моделі. Стандартний Governor: пропозал створений → сообщество голосує → при кворумі та більшості проходить. Optimistic: пропозал створений → автоматично виконується після затримки → якщо сообщество проти, вони повинні активно заблокувати.

Ідея запозичена з optimistic rollup-ів: по замовчуванню вважаємо валідним, оспарювання потребує дії. Для DAO це вирішує головну проблему більшості governance систем — voter apathy. Коли кворум не набирається місяцями через низьку явку, протокол замирає. Optimistic governance працює навіть при 90% пасивних holder-ів.

Коли оптимістичний підхід оправданий

Не кожній DAO потрібен optimistic approval. Підходить коли:

• Операційні рішення приймаються командою з делегованим мандатом (SubDAO, grants committee, security council)
• Висока частота адміністративних дій (updates параметрів ризику, whitelist нових активів)
• Сообщество довіряє execution команді, але хоче право veto
• Стандартний governance занадто повільний для реагування на market events

Не підходить для: змін tokenomics, upgrade-ів core контрактів, рішень з необоротними наслідками для treasury. Для цього — стандартний Governor з повним голосуванням.

Архітектурні паттерни

Паттерн 1: Optimistic Multisig

Найпростіша модель. Доверений мультисиг (core team, 5/9 підписей) виконує рішення. Timelock дає сообществу вікно для veto через emergency governance.

Multisig submits tx → TimelockController queues → [7 days window] → execute
                                                    ↑
                                         Community can invoke Guardian veto

Проблема: це не справжній optimistic governance, це просто multisig з затримкою. Нема механізму community veto без централізованого Guardian.

Паттерн 2: Veto-based Governor

Більш децентралізована модель. Пропозал автоматично проходить після затримки, якщо не набрав veto-quorum (наприклад, 10% токенів проголосували ПРОТИ).

Механізм: пропозал створений → votingPeriod (наприклад, 7 днів для збору veto голосів) → якщо AGAINST < vetoThreshold — проходить → queues в timelock → execute.

Хто може створювати propozals важливо для безпеки: якщо threshold низький — спамери. Рішення: тільки Security Council або SubDAO членів через окремий approval контракт.

Паттерн 3: Optimistic SubDAO (Optimism модель)

Optimism використовує двопалатну систему. Token House (всі OP holder-и) — повноцінне голосування. Citizens' House (badgeholders) — контрбаланс. Для деяких рішень: Citizens' House мають право veto проти Token House більшості.

Для менших протоколів: SubDAO модель. Core team = SubDAO з optimistic правами в межах limitів. За межами limitів — повний governance.

SubDAO Action Categories:
├── Tier 1 (< $50k, params) → Optimistic approval, 48h veto window
├── Tier 2 ($50k - $500k, integrations) → Multisig vote, 7d veto window  
└── Tier 3 (> $500k, upgrades) → Full token voting, no optimistic

Детальна реалізація veto механізму

VetoRegistry Contract

Окремий контракт реєструє veto голоси та взаємодіє з TimelockController:

Он аналогічний англійській версії. Ключові моменти: snapshot на момент queue, CANCELLER role для TimelockController, перевірка veto threshold для скасування операції.

Економіка участі у veto

Проблема veto систем: газова вартість голосування. Якщо veto голос коштує $5-50 в газі, а holder має малий stake — раціонально не голосувати. Це означає що тільки крупні holder-и реально беруть участь у veto.

Рішення:

• Gas рефанд. Протокол відшкодовує газ за veto голосування якщо пропозал був в итоге заблокований.
• Gasless voting через EIP-712 + relayer. Користувач підписує veto off-chain, relayer публікує on-chain.
• Optimism: L2 для veto. Якщо протокол на L2 — газ уже дешевий, проблема менш актуальна.

Security considerations

Критичні питання: harmful proposal через optimistic path, Timelock bypass через delegatecall, replay атаки при перезапуску.

Захисти: автоматичний мониторинг proposals, достижимий veto threshold для active сообщества, multisig як backup CANCELLER.

Real примери

Optimism Foundation. Security Council може робити emergency дії з 24-hour timelock. Стандартні propozals — повне Token House голосування.

Gnosis DAO. Використовує optimistic governance для routine рішень через спеціалізовану SubDAO.

Aragon. Aragon OSx підтримує optimistic через офіційний OptimisticTokenVotingPlugin.

Стек та процес

Сроки: базова реалізація — 3-4 тижні розробки. З gasless voting та повним frontend — 6-8 тижнів. Аудит обов'язковий — 2-4 тижні.

Вартість розраховується після архітектурного аналізу конкретного use case.