Developing futarchy (governance through prediction markets)
Futarchy is a radical alternative to token voting. Concept by Robin Hanson (economist, 1990s): "vote on values, bet on beliefs". Instead of voting directly, participants trade on prediction markets: "if proposal X passes — what will KPI of protocol be in 90 days?". Proposal passes if market predicts KPI improvement.
Logic: traders have financial incentive to be right. Someone knowing proposal harms protocol sells "YES" tokens, earns, and signals to market. Information aggregation through price is more accurate than voting with "one token — one vote", where whales push favorable decisions.
Practical futarchy is complex engineering. MetaDAO on Solana — the only mature on-chain example. But interest grows: Gnosis, 1inch, Optimism Foundation studied or experimented with elements.
Futarchy mechanism: how it works on-chain
Conditional tokens (ERC-1155 based)
Futarchy's key primitive — conditional token. Its value depends on event outcome. Gnosis Conditional Tokens Framework (CTF) is the de facto standard.
Creating proposal creates two markets:
- YES market: trading when proposal accepted
- NO market: trading when proposal rejected
Participants deposit collateral (e.g., USDC) and get equal YES and NO tokens. They can:
- Sell YES tokens (betting proposal is bad)
- Sell NO tokens (betting better without proposal)
- Trade both depending on assessment
Price YES > Price NO → market expects better KPI when accepting
Price YES < Price NO → market expects better KPI without proposal
If at end YES > NO — proposal passes. Losers lose collateral to winners.
Gnosis Conditional Tokens Framework
CTF is a set of contracts for creating conditional tokens. Main contract ConditionalTokens.sol supports creating conditions, splitting collateral into YES/NO tokens, and redeeming after resolution.
Each condition combination is a separate ERC-1155 token ID. positionId = keccak256(collateralToken, collectionId).
AMM for conditional tokens
After creating conditional tokens, you need liquidity for trading. Standard — LMSR (Logarithmic Market Scoring Rule) AMM, designed specifically for prediction markets.
LMSR differs from Uniswap: market maker has bounded losses. Parameter b determines liquidity and max loss. At q_yes = q_no → Price_yes = 0.5 (50/50 initial state).
Alternative — Uniswap V2 pool for YES/USDC and separate for NO/USDC. Simpler, but no bounded loss guarantee.
KPI definition and oracle
Metric selection
Choosing right KPI is critical. Bad KPI creates Goodhart's Law problem: metric stops reflecting reality when optimized.
Typical DeFi protocol KPIs:
| KPI | Pros | Cons |
|---|---|---|
| TVL in 90 days | Easy to measure, on-chain | Manipulated by incentive farming |
| Volume (7d avg) | User activity | Wash trading |
| Token price | Market signal | Volatile |
| Revenue (fees) | Real value | Can grow from harmful measures |
| DAU | Real growth | Sybil sensitive |
MetaDAO uses token price — simple, hard to manipulate (needs real money). For specific protocol — choose by specialty.
Oracle resolution
After trading period, determine actual KPI and compare to baseline. Two approaches:
On-chain oracle. If KPI is TVL or volume — calculate on-chain. Chainlink provides token price. Custom oracle reads contract balance for TVL. Trustless, but limited.
Human oracle (Reality.eth). For complex metrics — asks "Was KPI X above Y at time T?". Respondents answer with bonds, dispute allows contesting. Historically reliable.
Committee oracle. Multisig decides outcome. More subjective but flexible.
Full system architecture
Lifecycle:
- Submission (day 0): proposal created, MarketFactory deploys YES/NO markets, treasury seeds liquidity
- Trading period (days 1-14): participants trade, prices reflect consensus
- Snapshot (day 14): baseline KPI and prices fixed
- Resolution period (days 15-104): if YES won — proposal executes; after 90 days oracle measures KPI
- Settlement (day 104): conditional tokens redeem by outcome; winners claim loser's collateral
Manipulation protection
Thin market attack. With low liquidity, attacker can shift prices with small sum. Solution: minimum liquidity requirement.
Oracle manipulation. If KPI is token price, attacker can manipulate at moment. Solution: TWAP (harder to manipulate).
Conditional on conditional. If proposal A affects KPI of proposal B — correlates. Solution: execute sequentially, not parallel.
Informed trading advantage. Dev team knows before public. Solution: trading period 14+ days for market to digest, plus disclosure requirement.
Development timeline
| Component | Complexity | Timeline |
|---|---|---|
| CTF | High | 3-4 weeks |
| LMSR AMM | Very high | 4-6 weeks |
| KPI Oracle | Medium | 2-3 weeks |
| Governor integration | Medium | 2-3 weeks |
| Frontend | High | 4-5 weeks |
| Audit | — | 4-6 weeks |
Full futarchy governance system — 4-6 months development + audit. One of most complex DeFi mechanisms.
Extended beta is critical: deploy on testnet with real community, study trading patterns, calibrate LMSR parameters.
Recommend starting with hybrid model (partial futarchy) and expanding as signal quality data accumulates.