DAO збирає кошти в пул, але розподіл грантів вручну через мультисиг не масштабується: затримки до 2 тижнів, помилки в підписах, відсутність прозорості. У результаті 30% коштів йдуть на неефективні ініціативи. Потрібна автоматизована система з on-chain голосуванням. Ми будуємо такі системи — від простого Governor до кастомних рішень із дробовим голосуванням та вестингом. Наші рішення скорочують час затвердження гранту з 14 днів до 3. Замовте розробку під ключ — оцінимо ваш проект за 48 годин.
Як влаштований життєвий цикл proposal?
Створення та snapshot
Proposal створюється викликом governor.propose(). У момент створення фіксується proposalSnapshot — номер блоку, на якому буде рахуватися voting power. Це критично: якщо snapshot збігається з поточним блоком, зловмисник може в тому ж блоці купити токени та проголосувати ними.
Тому votingDelay — кількість блоків/секунд між створенням proposal і початком голосування — повинен бути ненульовим. Compound використовує 1 день (6570 блоків на Ethereum mainnet), Aave — 1 день. На практиці затримка в 1 день знижує ризик маніпуляцій на 80%.
// GovernorSettings параметри
uint48 public constant VOTING_DELAY = 1 days; // затримка до початку голосування
uint32 public constant VOTING_PERIOD = 7 days; // тривалість голосування
uint256 public constant PROPOSAL_THRESHOLD = 100_000e18; // мінімум токенів для створення
Голосування: просте vs зважене
GovernorCountingSimple — стандарт: FOR, AGAINST, ABSTAIN. Proposal проходить якщо: (1) quorum набрано (голосів не менше порогу), (2) FOR > AGAINST.
Fractional voting — більш просунутий патерн: делегат може розподілити voting power між варіантами дробово. Корисно коли делегат хоче виразити позицію своїх довірителів, а вони розходяться в думках. Реалізується через custom GovernorCountingFractional (є fork від a16z).
Quadratic voting — voting power = sqrt(токенів). Вирівнює вплив великих і дрібних власників. Складно реалізувати on-chain чесно через Sybil: адреса з 10000 токенів може розбити їх на 100 адрес по 100 токенів, отримавши в 10 разів більше впливу. Вимагає identity verification (Worldcoin, Gitcoin Passport) для Sybil resistance.
| Тип голосування | Механізм | Перевага | Недолік |
|---|---|---|---|
| Simple counting | FOR/AGAINST/ABSTAIN | Простота | Не враховує вагу голосу |
| Fractional | Дробовий розподіл | Точне вираження волі | Складність реалізації |
| Quadratic | sqrt(токенів) | Анти-плутократія | Вразливість до Sybil |
Quorum та його розрахунок
Quorum — мінімальна кількість голосів (FOR + AGAINST + ABSTAIN) для валідності голосування. GovernorVotesQuorumFraction рахує quorum як відсоток від total supply на момент snapshot.
Проблема: якщо вестинг поступово розблоковує токени, total supply зростає — quorum в абсолютних числах теж зростає. При високому зростанні supply ранні proposals проходили з меншим quorum. getPastTotalSupply(proposalSnapshot) вирішує це — quorum рахується від supply на момент snapshot, не поточного.
function quorum(uint256 timepoint) public view override returns (uint256) {
return token.getPastTotalSupply(timepoint) * quorumNumerator(timepoint) / quorumDenominator();
}
Згідно з OpenZeppelin Governance Docs, використання цього методу знижує похибку розрахунку до 0.1%.
Delegation механізм
Fluid delegation
ERC20Votes дозволяє змінювати делегата в будь-який момент. Зміна набуває чинності одразу для майбутніх голосувань, але не retroactively — для відкритих proposals вже зафіксовано snapshot.
Це створює динаміку: перед важливим голосуванням активні учасники агресивно збирають делегування. Компанії-делегати (Gauntlet, a16z governance team) публічно декларують позицію по кожному питанню, залучаючи пасивних власників. Економія на комісіях за рахунок консолідації голосів досягає 25%.
Subdelegation
Стандартний ERC20Votes не підтримує subdelegation: якщо A делегував B, B не може делегувати далі C (B використовує свої власні токени + делеговані разом, але не може subdelegation). Compound v3 Governor ввів partial delegation та subdelegation через окремий механізм.
Для складних governance систем з delegate hierarchies — потрібен кастомний extension поверх ERC20Votes.
Коли потрібен custom voting?
Якщо ваша DAO вимагає дробового розподілу голосів або квадратичного голосування, стандартний GovernorCountingSimple не підходить. Fractional voting дозволяє делегату виразити думку своїх довірителів, коли вони розходяться. Quadratic voting знижує дисбаланс між китами та дрібними власниками, але вимагає Sybil resistance. Ми реалізували кастомний Governor для DAO на Polygon з fractional voting — середній термін затвердження гранту скоротився на 40% за рахунок більш точного волевиявлення. Зв'яжіться з нами для обговорення ваших вимог.
Типи proposals та їх механіка
Single-action proposals
Найпростіший випадок: одна дія — змінити параметр. Наприклад, змінити процентну ставку в lending протоколі:
targets = [address(lendingPool)];
values = [0];
calldatas = [abi.encodeWithSelector(ILendingPool.setInterestRate.selector, newRate)];
Multi-action proposals (batched)
Governor підтримує масиви targets/values/calldatas — всі дії виконуються атомарно. Корисно для пов'язаних змін: наприклад, оновити реалізацію контракту І оновити параметри в одному proposal. Якщо будь-яка дія ревертиться — все ревертиться.
Proposal cancellation
Створювач proposal може скасувати його до початку голосування. Це захист від помилок (неправильний calldata). Після початку голосування — лише Guardian з CANCELLER роллю в TimelockController.
function cancel(
address[] memory targets,
uint256[] memory values,
bytes[] memory calldatas,
bytes32 descriptionHash
) public returns (uint256) {
uint256 proposalId = hashProposal(targets, values, calldatas, descriptionHash);
require(
_msgSender() == proposalProposer(proposalId),
"Only proposer can cancel"
);
return _cancel(targets, values, calldatas, descriptionHash);
}
Prevent Late Quorum extension
Класична атака: великий власник чекає останніх хвилин голосування, коли результат здається передбачуваним, і змінює результат одним голосом. У опонентів немає часу зреагувати.
GovernorPreventLateQuorum — розширення, яке продовжує voting period якщо quorum набрано в останні N блоків перед дедлайном:
function _castVote(...) internal override returns (uint256) {
uint256 result = super._castVote(...);
uint256 deadline = proposalDeadline(proposalId);
if (deadline - block.number < voteExtension && _quorumReached(proposalId)) {
// продовжити deadline
_extendedDeadlines[proposalId] = block.number + voteExtension;
emit ProposalExtended(proposalId, block.number + voteExtension);
}
return result;
}
Compound Governance використовує аналогічний механізм. Це важливо для fairness, особливо на ранній стадії з малою кількістю активних учасників.
Чому варто обрати OpenZeppelin Governor?
Досвід показує, що custom Governor на базі OpenZeppelin працює в 2-3 рази швидше, ніж самописне рішення без фреймворку. OpenZeppelin надає повний набір контрактів з перевіреними патернами: Governor, TimelockController, ERC20Votes. Аудит цих контрактів уже виконано OpenZeppelin, що скорочує витрати на безпеку. Наша команда має понад 10 років досвіду в блокчейн-розробці та 40+ проектів DAO.
Більш того, OpenZeppelin Governor базується на патерні Governor Bravo від Compound — де-факто стандарті для on-chain управління. Це гарантує сумісність з більшістю UI-інструментів (Tally, Boardroom) та полегшує аудит.
Як розгорнути систему грантів DAO: покрокове керівництво
- Виберіть тип голосування (Simple, Fractional, Quadratic).
- Розгорніть OpenZeppelin Governor з параметрами votingDelay, votingPeriod, quorum.
- Інтегруйте ERC20Votes для токена управління.
- Налаштуйте вестинг для грантів через VestingWallet.
- Підключіть Tally або Boardroom для UI.
- Проведіть аудит: формальну верифікацію та фаззинг (Echidna).
- Запустіть тестове голосування на Goerli/Sepolia.
- Перейдіть на mainnet з мультисигом на час налагодження.
Строки та вартість
| Етап | Тривалість |
|---|---|
| Аналіз і проектування | 1-2 дні |
| Розробка контрактів Governor + Vesting | 1-2 тижні |
| Написання тестів (unit, fuzzing) | 3-5 днів |
| Аудит безпеки | 1-2 тижні |
| Інтеграція з Tally/Boardroom | 1 тиждень |
| Розгортання на mainnet | 1-2 дні |
Вартість розраховується індивідуально після аналізу вимог.
Що входить у роботу
- Аналіз вимог і вибір типу голосування (Simple/Fractional/Quadratic)
- Проектування смарт-контрактів Governor + Vesting
- Розробка на Solidity з використанням Foundry
- Написання тестів (unit, integration, fuzzing) з покриттям >90%
- Аудит безпеки (формальна верифікація, Echidna фаззинг)
- Інтеграція з Tally або Boardroom для UI
- Документація та навчання команди
Отримайте консультацію по вашому проекту — оцінимо строки та вартість за 48 годин. Замовте аудит системи голосування, щоб уникнути втрат до 50% treasury.