Futarchy Governance
What if stakeholders didn't just vote on proposals — they bet on whether the proposals would work?
Futarchy is a governance model where decisions are made through prediction markets. Robin Hanson proposed it in 2000: "vote on values, bet on beliefs." Instead of asking stakeholders to choose between options A and B, you ask them to stake tokens on which outcome they believe will lead to better metrics. Markets aggregate information. The proposal that produces the better predicted outcome gets implemented.
Traditional vs Futarchy
| Dimension | Token-weighted voting | Futarchy |
|---|---|---|
| Mechanism | One token = one vote | One token = one bet |
| Information | Stated preferences | Revealed beliefs |
| Gaming | Whale dominance, apathy | Must stake to influence |
| Outcome | Majority preference wins | Best-predicted outcome wins |
| Accountability | Voters face no consequence | Bettors face market resolution |
Voting aggregates preferences. Markets aggregate information. For decisions that have measurable outcomes, markets tend to outperform voting — bettors have skin in the game. Voters often don't.
The MetaDAO Model
MetaDAO (deployed on Solana) is the first live futarchy implementation. Their pattern:
- Proposal submitted with a metric definition (e.g. "30-day protocol revenue")
- Two conditional token markets created:
META-PASS(if proposal passes) andMETA-FAIL(if it fails) - Stakeholders trade in both markets for 10 days
- Market prices reveal the expected impact:
PASS-price > FAIL-price→ proposal passes - Winning market settles, losing market refunds bets
The oracle determines which market wins by measuring the metric after the decision window.
Sui Implementation
Sui's existing modules map directly to futarchy primitives:
| Futarchy requirement | Sui module | Status |
|---|---|---|
| Conditional token markets | prediction_game | Deployed testnet — rugby scoring as proof of concept |
| Oracle price feed + settlement | prediction_game hot potato pattern | Live — oracle cap controls resolution |
| Proposal lifecycle management | governance | Stub (17 lines) — upgrade needed |
| Stake accounting + reward distribution | prediction_game pool accounting | Live |
| Time-gated voting windows | sui::clock guard | Available |
| Identity verification | identity module | Deployed devnet |
The prediction_game package already implements the core market primitive. The governance module needs to be upgraded from a stub to a conditional market struct with proposal lifecycle.
Hot Potato Settlement
The prediction game's oracle settlement uses the hot potato pattern — a key safety property for futarchy:
Oracle submits result → hot potato object created (no store ability)
→ MUST be consumed in same PTB
→ by settlement function that closes market, distributes funds
→ atomic — no partial execution
This matters for futarchy: the oracle cannot observe market prices and then selectively resolve. The hot potato forces resolution in one atomic transaction. The oracle commits to the outcome, markets close, bets pay out — all in ~390ms.
The Governance Upgrade
What governance needs to become:
Current (17 lines, stub):
- Empty module declaration
Target architecture:
- ProposalObject (owned by submitter, contains metric_definition + window_end)
- MarketPair (shared: two prediction_game instances — PASS and FAIL conditional)
- OracleResolution (hot potato — measure metric, determine winner, close markets)
- ProposalLifecycle (DRAFT → ACTIVE → RESOLVING → COMPLETE state machine)
The prediction_game module's Season, Pool, and oracle settlement pattern serve as the template. Futarchy governance is prediction_game applied to organizational decisions rather than sports outcomes.
Move Prover Triggers
Futarchy has two invariants that require formal verification:
- Value conservation: total stake in PASS + FAIL markets = total tokens committed. No tokens created or destroyed in settlement.
- State machine completeness: a ProposalObject in RESOLVING state cannot revert to ACTIVE. Settlement is irreversible.
Both require Move Prover. Economic invariants and irreversible state transitions are the two strongest triggers for formal verification in the Move toolchain.
Metric Definition Problem
The hardest part of futarchy is not the markets — it's defining the metric. A metric must be:
- Measurable on-chain — or via a trusted oracle
- Manipulation-resistant — hard to game in the window
- Causally linked to the proposal — revenue 30 days post-decision, not price
Poor metric: token price (manipulable). Good metric: protocol revenue (harder to fake). Better: on-chain activity volume (fully on-chain, oracle-free).
The collision module's quality scoring applies here — spam detection for metric data prevents gaming the resolution oracle.
Context
- Sui Move Patterns — Domain patterns and module selection
- Prediction Game Pattern — Hot potato oracle settlement (deployed)
- Sui Development — Full package list + testnet deployments
- Move Prover — Formal verification for economic invariants
Links
- MetaDAO — Live futarchy implementation on Solana
- Robin Hanson — Futarchy — Original academic proposal
- Prediction Markets Research — Forecasting accuracy benchmarks
Questions
If stakeholders must bet rather than vote, what happens to participation from those who lack conviction but have legitimate stakes in the outcome?
- At what proposal complexity does the market's information advantage over expert committees disappear?
- How do you define a metric that is both measurable on-chain and genuinely causally linked to the proposal's success?
- What prevents a well-resourced actor from trading both markets to guarantee a favorable outcome regardless of resolution?