Разработка кастомных Snapshot-стратегий голосования

Разработка futarchy (governance через prediction markets)

Futarchy — радикальная альтернатива токен-голосованию. Концепция Robin Hanson (экономист, 1990-е): "голосуй за ценности, ставь на убеждения". Вместо того чтобы голосовать "за" или "против" proposal напрямую, участники торгуют на prediction market: "если proposal X принят — каким будет KPI протокола через 90 дней?". Proposal принимается если рынок предсказывает рост KPI.

Логика: торговцы имеют финансовый стимул быть правыми. Тот кто знает что proposal навредит протоколу — продаёт "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) — стандарт de facto.

При создании proposal создаются два market:

• YES market: торги токеном протокола при условии что proposal принят
• NO market: торги токеном протокола при условии что proposal отклонён

Участники депонируют коллатераль (например, USDC) и получают равное количество YES и NO conditional tokens. Они могут:

• Продать YES tokens (ставка что proposal плохой при принятии → цена YES упадёт)
• Продать NO tokens (ставка что без proposal лучше → цена NO упадёт)
• Или торговать обоими в зависимости от своей оценки

Цена YES token > Цена NO token → рынок ожидает лучший KPI при принятии
Цена YES token < Цена NO token → рынок ожидает лучший KPI без proposal

Если в конце trading period цена YES > NO — proposal принимается. Проигравшие (продавцы дорогой стороны) теряют коллатераль в пользу победителей.

Gnosis Conditional Tokens Framework

CTF — набор контрактов для создания conditional tokens. Основной контракт ConditionalTokens.sol:

// Создание condition с 2 исходами (YES/NO)
function prepareCondition(
    address oracle,        // кто определит outcome
    bytes32 questionId,    // ID вопроса
    uint256 outcomeSlotCount  // 2 для бинарного
) external;

// Разделение коллатераля на conditional tokens
function splitPosition(
    IERC20 collateralToken,
    bytes32 parentCollectionId,
    bytes32 conditionId,
    uint256[] calldata partition,  // [1, 2] для YES/NO
    uint256 amount
) external;

// Слияние (redemption) после resolution
function mergePositions(...) external;
function redeemPositions(...) external;

Каждая комбинация условий — отдельный ERC-1155 token ID. positionId = keccak256(collateralToken, collectionId).

AMM для conditional tokens

После создания conditional tokens нужна ликвидность для торговли. Стандартный вариант — LMSR (Logarithmic Market Scoring Rule) AMM, специально разработанный для prediction markets.

LMSR отличается от Uniswap-стиля: маркет-мейкер имеет ограниченные потери при любом исходе (bounded loss). Параметр b определяет ликвидность и максимально возможный убыток:

Cost(q_yes, q_no) = b * ln(e^(q_yes/b) + e^(q_no/b))
Price_yes = e^(q_yes/b) / (e^(q_yes/b) + e^(q_no/b))

При q_yes = q_no → Price_yes = 0.5 (50/50 стартовое состояние). Каждая покупка YES токенов сдвигает цену вверх, каждая продажа — вниз.

Альтернатива — Uniswap V2 пул для YES/USDC и отдельный для NO/USDC. Проще реализовать, но нет bounded loss гарантии для market maker.

Определение KPI и oracle

Выбор метрики

Выбор правильного KPI — критичен. Плохой KPI создаёт Goodhart's Law проблему: метрика перестаёт отражать реальное здоровье при оптимизации под неё.

Типичные KPI для DeFi протокола:

MetaDAO использует цену токена как KPI — просто, манипулируется сложно (для манипуляции нужны реальные деньги). Для конкретного протокола KPI выбирается по специфике.

Oracle resolution

После trading period нужно on-chain определить фактическое значение KPI и сравнить с baseline. Два подхода:

On-chain oracle. Если KPI — TVL или volume — можно считать on-chain. Chainlink Data Feeds предоставляют цену токена. Кастомный oracle читает баланс контракта для TVL. Это trustless, но ограничено on-chain измеримыми метриками.

Human oracle (Reality.eth). Для сложных метрик — Reality.eth задаёт вопрос "Был ли KPI X выше Y в момент T?". Respondents отвечают с bonds, dispute period позволяет оспорить неправильный ответ. Исторически работало надёжно для однозначных вопросов.

Committee oracle. Multisig из авторитетных участников сообщества решает outcome. Более субъективно, но гибко. Злоупотребление ограничено репутационным риском и on-chain прозрачностью решений.

Полная архитектура системы

Контракты

FutarchyGovernor
├── ProposalRegistry — создание и хранение proposals
├── MarketFactory — деплой YES/NO markets для каждого proposal
│   ├── ConditionalTokens (Gnosis CTF)
│   ├── LMSR_AMM — ценообразование YES/NO tokens
│   └── LiquidityPool — начальная ликвидность от treasury
├── KPIOracle — измерение baseline и post-resolution KPI
├── OutcomeResolver — финализация outcome после trading period
└── ExecutionModule — исполнение принятых proposals (через Timelock)

Lifecycle одного proposal:

1. Submission (день 0): proposal создаётся, MarketFactory деплоит YES/NO markets, treasury предоставляет seed liquidity в LMSR
2. Trading period (дни 1-14): участники торгуют conditional tokens, цены отражают consensus
3. Snapshot (день 14): фиксируется baseline KPI и рыночные цены
4. Resolution period (дни 15-104): если YES победил — proposal исполняется; через 90 дней oracle измеряет реальный KPI
5. Settlement (день 104): conditional tokens redeem по фактическому исходу; выигравшие забирают коллатераль проигравших

Защита от манипуляций

Thin market attack. При малой ликвидности LMSR, атакующий может за небольшую сумму сдвинуть цену YES выше NO и протолкнуть вредоносный proposal. Решение: minimum liquidity requirement для выполнения proposal по рыночному сигналу. Например, суммарный объём торгов должен превысить X% от treasury для того чтобы результат считался валидным.

Oracle manipulation. Если KPI — цена токена, атакующий может манипулировать ценой в момент измерения. Решение: TWAP вместо spot цены (time-weighted average price за 7-30 дней), что требует более длительной и дорогой манипуляции.

Conditional на conditional. Если proposal A влияет на KPI измерение proposal B — результаты коррелируют. Для протоколов с высокой частотой proposals — добавить изоляцию: proposals исполняются последовательно, не параллельно.

Informed trading advantage. Команда разработчиков знает о proposal раньше публики. Insider trading не запрещён on-chain. Решение: trading period должен быть достаточно длинным (14+ дней) чтобы рынок успел переварить информацию, и публичное требование disclosure от команды (прозрачность, не технический enforcement).

Bootstrapping и cold start

Пустые prediction markets бесполезны — нет ликвидности, нет торговли, нет сигнала. Cold start требует специального подхода:

Treasury seed liquidity. На старте протокол сам обеспечивает LMSR ликвидность. Это bounded loss — максимальные потери LMSR рассчитываются заранее исходя из параметра b.

Incentivized trading. Токен rewards за торговлю на futarchy markets. Аналог liquidity mining, но для prediction market activity. Риск: люди торгуют ради rewards не ради сигнала → шум в цене.

Hybrid governance. Начать с частичного futarchy: обычное токен-голосование для мажорных decisions (protocol upgrades, security params), futarchy для операционных decisions (fee parameters, incentive adjustments). Постепенно расширять scope по мере накопления исторических данных.

Интеграция с существующим Governor

Если у протокола уже есть OpenZeppelin Governor, futarchy добавляется как execution hook: стандартный Governor proposal при прохождении threshold создаёт futarchy market вместо немедленного исполнения. Исполнение происходит только если рынок "согласен".

contract FutarchyGovernorHook {
    IFutarchyMarket public immutable futarchyMarket;
    
    // Called when Governor proposal passes threshold
    function beforeExecution(uint256 proposalId, bytes memory proposalData) 
        external returns (bool shouldExecuteNow) 
    {
        // Create futarchy market for this proposal
        futarchyMarket.createMarket(proposalId, proposalData, TRADING_PERIOD);
        
        // Don't execute now — wait for market signal
        return false;
    }
    
    // Called after trading period + oracle resolution
    function afterMarketResolution(uint256 proposalId) external {
        bool yesWon = futarchyMarket.getOutcome(proposalId);
        if (yesWon) {
            governor.executeWithoutVote(proposalId);
        }
    }
}

Стек реализации

Smart contracts: Solidity + Foundry + Gnosis CTF. LMSR контракт (custom или форк augur-v2). Reality.eth для oracle. Chainlink для on-chain KPI feeds.

Backend: TypeScript + Node.js + The Graph subgraph для индексации market activity. WebSocket для real-time price updates.

Frontend: React + wagmi + recharts для визуализации market prices и KPI tracking. Tradingview-style графики для YES/NO price history.

Сроки и оговорки

Полная система futarchy governance — 4-6 месяцев разработки + аудит. Это один из наиболее сложных DeFi механизмов: комбинирует prediction markets, conditional tokens, oracle systems, и governance исполнение.

Перед запуском критически важен extended beta период: deploying на testnet с real community participation, изучение торговых паттернов, calibration LMSR параметров. Теоретически привлекательный механизм может не работать в конкретном сообществе из-за низкой участности или информационной асимметрии.

Рекомендую начать с hybrid модели (частичное futarchy) и расширять по мере накопления данных о качестве сигнала.