Розробка системи делегування в DAO
Делегування — рішення проблеми voter apathy в on-chain governance. У більшості DAO реальна явка складає 5–15% від circulating supply. Причин кілька: технічні бар'єри (тримати токени незаблокованими + платити газ), інформаційна нагрузка (неможливо вникнути в кожен пропозал), відсутність мотивації для мелких holder-ів.
Система делегування дозволяє token holder-ам передавати своє voting power спеціалізованим делегатам — активним учасникам сообщества, які регулярно голосують та публічно обґрунтовують позицію. Це ближче до представницької демократії, ніж до прямої.
Базовий механізм: ERC-20Votes делегування
Стандарт ERC-20Votes (OpenZeppelin) надає вбудований механізм делегування через checkpoint систему.
Структура аналогічна англійській версії. Критичний момент: після покупки токенів користувач має нульовий voting power поки не викличе delegate. Це неочевидне поведінка, яке потрібно явно показувати в UI.
Частичне делегування
Базовий ERC-20Votes підтримує делегування тільки цілком одному адресу. Для продвинутих систем потрібне частичне: 40% делегату A, 30% делегату B, 30% оставити собі.
Це суттєво ускладнює checkpoint логіку: при кожному transfer потрібно пересчитувати вклади в кожного делегата. Газові витрати растуть з числом делегатів.
Делегатні профілі та репутація
Технічний механізм делегування — це одне. Інфраструктура для прийняття рішень про те, кому делегувати — інше.
On-chain делегатний реєстр
Делегат створює профіль з ім'ям, IPFS посиланням на повний профіль та тегами інтересів. IPFS метаданні містять: платформу позицію, історію голосувань з обґрунтуванням, контактні дані. Зберігання повного профілю off-chain (IPFS) знижує газові витрати.
Статистика активності делегата
Реальна цінність делегата — його track record. Субграф повинен індексувати:
- Participation rate: % пропозалів проголосованих з момента делегування
- Alignment: наскільки часто позиція делегата збігається з фінальним результатом
- Rationale rate: % голосувань з опублікованим обґрунтуванням
Gasless делегування через EIP-712
Делегування потребує on-chain транзакції. При вартості газу $2–5 це бар'єр для мелких holder-ів. Рішення — delegateBySig: holder підписує делегування off-chain, relayer відправляє транзакцію та платить газ.
Frontend flow: користувач підписує EIP-712 повідомлення (MetaMask показує читаємий текст "Делегувати [адреса] до [дати]"), підпис відправляється на backend, backend викликає delegateBySig та платить газ.
Batch gasless делегування для onboarding
При onboarding новго користувача можна запросити delegate-підпис для кількох токенів одночасно.
Відзив делегування та re-delegation
Делегування — не постійно. delegate(address(0)) або delegate(msg.sender) скасовує делегування. Зміна делегата: delegate(newDelegatee) автоматично переносить весь voting power.
Час вступу в силу: зміна ефективна з наступного блоку. Якщо пропозал уже створена та snapshot фіксований — зміна делегування не впливає на поточне голосування.
UI рекомендації: показувати користувачу поточного делегата, його participation rate за останні 30 днів та deadline ближайших активних голосувань. Це знижує відток делегаторів.
Incentive механіки для делегатів
Чиста альтруїстична модель працює тільки для крупних holder-ів. Для системної роботи потрібні стимули.
Delegate rewards. Протокол виплачує делегатам за активну участь. Розрахунок: participation rate × delegated voting power × reward rate.
Streaming payments (Sablier/SuperFluid). Делегат отримує постійний stream оплати поки його participation rate вище порогу. При падінні активності — stream автоматично приостанавлюється через keeper.
Стек і сроки
Контракти: ERC-20Votes розширення + DelegateRegistry + reward distributor. Solidity + Foundry + OpenZeppelin 5.x. Індексація: The Graph subgraph для делегатної статистики. Frontend: React + wagmi + react-query.
| Компонент | Строк |
|---|---|
| ERC-20Votes + gasless делегування | 1 тиждень |
| DelegateRegistry on-chain | 3–5 днів |
| The Graph subgraph для статистики | 1 тиждень |
| Frontend: пошук делегатів, UI делегування | 2 тижні |
| Reward механіка | 1–2 тижні |
MVP (базове делегування + gasless + UI профілів делегатів): 4–5 тижнів. Повна система з reward стрімінгом та аналітикою: 2 місяці.