Більшість DAO розподіляє гранти через snapshot-голосування з фіксованими періодами. Останньохвилинні маніпуляції, низька явка, неможливість перерозподілити голоси — знайомі проблеми. Ми розробляємо систему ретроактивного фінансування на основі conviction voting: механіки, де голос накопичує вагу з часом. Це виключає раптові перевороти та дає пріоритет proposals із довгостроковою підтримкою.
Наші інженери реалізували conviction voting для кількох DAO, включаючи Gardens (1Hive) і Giveth. Досвід показує: система в 2–3 рази ефективніша за класичний snapshot при розподілі постійного потоку грантів, оскільки не вимагає окремого голосування по кожному proposal. Економія на газі сягає 40%.
Як conviction voting працює в системі ретроактивного фінансування?
Conviction voting — це безперервний процес. Користувач голосує, заморожуючи токени в контракті. Вага голосу зростає з кожним блоком, поки користувач не зніме ставку. Щоб proposal пройшов, його сумарна conviction має перевищити динамічний поріг, який залежить від запитуваної суми та загального стейку. Це кардинально змінює економіку голосування:
- Last-minute manipulation неможлива: whale не може скинути всі голоси в останній блок — потрібно накопичувати conviction днями.
- Voter apathy не страшна: proposals конкурують за stake, а не за явку. Користувач просто перерозподіляє свої голоси між активними proposals.
- Пріоритизація йде за накопиченою підтримкою, а не за часом подання.
Які проблеми вирішує conviction voting у ретроактивних грантах?
Основна біль DAO — як справедливо розподіляти постійний потік коштів без бюрократії. Conviction voting вирішує три ключові завдання:
- Last-minute manipulation: голоси не скидаються в останню хвилину — захист від whales.
- Відсутність пріоритизації: донати не йдуть у порядку надходження, а вибирають найбільш підтримані proposals.
- Високі газові витрати: один контракт обробляє всі proposals, а не окреме голосування по кожному.
Як ми проєктуємо систему conviction voting?
Математична модель — розробка системи ретроактивного
Серце системи — функція накопичення переконаності:
conviction(t) = conviction(t-1) * α + votes * (1 - α) де α — коефіцієнт загасання (типово 0.9). При α = 0.9 повне накопичення займає ~22 періоди. Поріг проходження розраховується динамічно від розміру запиту та загального stake.
Математична модель порогу
Поріг проходження пропорційний квадратурі різниці між total supply та сумарним stake. Це захищає від схвалення величезних transfers при малій явці. Формула враховує maxRatio і minThreshold, що задаються governance.
Архітектура контракту
Ми використовуємо перевірені патерни OpenZeppelin: ReentrancyGuard, Math.mulDiv для захисту від overflow. Як зазначається в специфікації Conviction Voting від 1Hive, механізм усуває короткострокові маніпуляції, замінюючи їх довгостроковою переконаністю. Ключова частина — функція оновлення conviction:
function _updateConviction(uint256 proposalId) internal { Proposal storage proposal = proposals[proposalId]; uint256 blocksPassed = block.number - proposal.blockLast; if (blocksPassed == 0) return; uint256 alphaPow = _pow(alpha, blocksPassed); proposal.convictionLast = Math.mulDiv(proposal.convictionLast, alphaPow, PRECISION) + Math.mulDiv(proposal.stakedTokens, PRECISION - alphaPow, PRECISION); proposal.blockLast = block.number; } Усі числові розрахунки — з фіксованою точністю PRECISION = 1e7, що виключає переповнення для стандартних розмірів токенів (18 decimals).
Симуляція та налаштування параметрів
Перед деплоєм проводимо симуляцію на Python/TypeScript. Це дозволяє підібрати alpha та maxRatio так, щоб proposals проходили достатньо швидко, але не надто — щоб уникнути маніпуляцій.
| Параметр | Типове значення | Ефект |
|---|---|---|
| alpha | 0.9 | Швидкість накопичення conviction: чим ближче до 1, тим повільніше |
| maxRatio | 0.1 (10% treasury) | Максимальна частка treasury, доступна proposal |
| minThreshold | 0.05 (5% staked) | Мінімальна conviction для старту proposal |
Що входить у роботу
- Аналіз параметрів DAO та підбір alpha, maxRatio, minThreshold.
- Проектування архітектури смарт-контрактів (Vault, ConvictionVoting, Governor з таймлоком).
- Розробка контрактів на Solidity 0.8.x з використанням Foundry. Модульне тестування з покриттям 95%+.
- Аудит безпеки: перевірка на overflow, reentrancy, коректність threshold. Використовуємо статичні аналізатори Slither та Echidna для fuzzing.
- Деплой на Ethereum або L2 (Polygon, Arbitrum). Налаштування фронтиру (візуалізація conviction, управління стейками).
- 3 місяці підтримки після деплою: моніторинг, оновлення при необхідності.
Порівняння підходів
| Аспект | Snapshot | Conviction Voting |
|---|---|---|
| Стійкість до маніпуляцій | Низька | Висока (потрібен час) |
| Явка виборців | Критична | Не критична (stake перерозподіляється) |
| Пріоритизація proposals | За часом | За накопиченою підтримкою |
| Газові витрати | Високі | Низькі (один контракт) |
Орієнтовні терміни
Повний цикл: від 2,5 до 3 місяців. Вартість розраховується індивідуально після уточнення параметрів та обсягу робіт. Гарантія коректності контрактів та 3 місяці підтримки включені.
Зв'яжіться з нами для обговорення вашої DAO. Оцінимо проєкт та запропонуємо оптимальні параметри. Замовте розробку під ключ — від аналізу до деплою. Отримайте консультацію щодо параметрів вашої системи.