Розробка futarchy (governance через prediction markets)
Futarchy — радикальна альтернатива токен-голосуванню. Концепція Robin Hanson (економіста, 1990-і): "голосуй за цінності, ставай на переконання". Замість голосування за proposal напрямки, учасники торгують на prediction markets: "якщо пропозал X прийнятий — яким буде KPI протоколу через 90 днів?". Пропозал проходить якщо ринок передбачає поліпшення KPI.
Логіка: торговці мають фінансовий стимул бути праві. Той, хто знає що пропозал навредить протоколу — продає "YES" токени, заробляє та сигналізує ринку. Агрегація інформації через ціну більш точна ніж голосування з "один токен — один голос", де кити можуть протискати вигідні рішення.
Практична реалізація futarchy — складна інженерна задача. MetaDAO на Solana — єдиний зрілий on-chain приклад. Але інтерес зростає: Gnosis, 1inch, Optimism Foundation вивчали або експериментували з елементами.
Механізм futarchy: як працює on-chain
Conditional tokens (ERC-1155 based)
Ключовий примітив futarchy — conditional token. Його вартість залежить від исходу события. Gnosis Conditional Tokens Framework (CTF) — стандарт де-факто.
При створенні пропозалу створюються два ринки:
- YES ринок: торгівля при прийнятті пропозалу
- NO ринок: торгівля при відхиленні пропозалу
Учасники депонують коллатераль (наприклад USDC) та отримують рівну кількість YES та NO токенів. Вони можуть:
- Продавати YES токени (ставити що пропозал поганий)
- Продавати NO токени (ставити краще без пропозалу)
- Торгувати обома залежно від оцінки
Ціна YES > Ціна NO → ринок очікує кращого KPI при прийнятті
Ціна YES < Ціна NO → ринок очікує кращого KPI без пропозалу
Якщо в кінці YES > NO — пропозал проходить. Програвші втрачають коллатераль переможцям.
Gnosis Conditional Tokens Framework
CTF — набір контрактів для створення conditional токенів. Основний контракт ConditionalTokens.sol підтримує створення умов, розділення коллатералю на YES/NO токени, та redemption після resolution.
Кожна комбінація умов — окремий ERC-1155 token ID. positionId = keccak256(collateralToken, collectionId).
AMM для conditional tokens
Після створення conditional токенів потрібна ліквідність для торгівлі. Стандарт — LMSR (Logarithmic Market Scoring Rule) AMM, спеціально розроблений для prediction markets.
LMSR відрізняється від Uniswap: market maker має обмежені втрати. Параметр b визначає ліквідність та максимальні втрати. При q_yes = q_no → Price_yes = 0.5 (50/50 початковий стан).
Альтернатива — Uniswap V2 пул для YES/USDC та окремий для NO/USDC. Простіше, але без гарантії обмежених втрат.
Визначення KPI та oracle
Вибір метрики
Вибір правильного KPI — критичний. Погана метрика створює проблему Goodhart's Law: метрика перестає відображати реальність при оптимізації.
Типові DeFi KPI:
| KPI | Плюси | Мінуси |
|---|---|---|
| TVL через 90 днів | Легко вимірити, on-chain | Маніпулюється incentive farming |
| Volume (7d avg) | Активність користувачів | Wash trading |
| Ціна токену | Ринковий сигнал | Volatile |
| Revenue (fees) | Реальна цінність | Може зростати від шкідливих мір |
| DAU | Реальне зростання | Sybil sensitive |
MetaDAO використовує ціну токену — просто, важко маніпулювати (потребує реальних грошей). Для конкретного протоколу — вибирати за спеціалізацією.
Oracle resolution
Після trading period визначити актуальний KPI та порівняти з baseline. Два підходи:
On-chain oracle. Якщо KPI — TVL або volume — можна рахувати on-chain. Chainlink надає ціну токену. Custom oracle читає баланс контракту для TVL. Trustless, але обмежено.
Human oracle (Reality.eth). Для складних метрик — питає "Було ли KPI X вище Y в момент T?". Respondents відповідають з bonds, dispute дозволяє оспорювати. Історично надійно.
Committee oracle. Multisig вирішує outcome. Більш суб'єктивно але гнучко.
Повна архітектура системи
Lifecycle:
- Submission (день 0): пропозал створений, MarketFactory деплоїх YES/NO ринки, treasury сідує ліквідність
- Trading period (дні 1-14): учасники торгують, ціни відображають консенсус
- Snapshot (день 14): baseline KPI та ціни фіксовані
- Resolution period (дні 15-104): якщо YES переміг — пропозал виконується; після 90 днів oracle вимірює KPI
- Settlement (день 104): conditional токени redeem за outcome; переможці отримують коллатераль програвших
Захист від маніпуляцій
Thin market attack. При низькій ліквідності атакуючий може сдвинути ціни малою сумою. Рішення: мінімум ліквідності.
Oracle manipulation. Якщо KPI — ціна токену, атакуючий може маніпулювати в момент вимірювання. Рішення: TWAP (важче маніпулювати).
Conditional на conditional. Якщо пропозал A впливає на KPI пропозалу B — коррелюють. Рішення: виконувати послідовно, не паралельно.
Informed trading advantage. Dev team знає раніше публіки. Рішення: trading period 14+ днів для ринку розпрацювати, плюс requirement disclosure.
Сроки розробки
| Компонент | Складність | Строк |
|---|---|---|
| CTF | Висока | 3-4 тижні |
| LMSR AMM | Дуже висока | 4-6 тижнів |
| KPI Oracle | Середня | 2-3 тижні |
| Governor інтеграція | Середня | 2-3 тижні |
| Frontend | Висока | 4-5 тижнів |
| Аудит | — | 4-6 тижнів |
Повна система futarchy governance — 4-6 місяців розробки + аудит. Один з найскладніших DeFi механізмів.
Розширений beta критичний: деплой на testnet з реальною сообществом, вивчення trading паттернів, calibration LMSR параметрів.
Рекомендую почати з hybrid моделі (частковий futarchy) та розширювати по мірі накопленння даних про якість сигналу.