Futarchy Governance

You are learning a move

No active mission. Use this page to improve one real decision; reading alone is not proof.

When should stakeholders bet on whether an eligible proposal will work?

Futarchy is a governance model where decisions are informed through prediction markets. Robin Hanson proposed it in 2000: "vote on values, bet on beliefs." The values, beneficiaries, rights, and harm constraints must therefore exist before the market. Use Value and Values Investing to form a thesis, test venture truth, and freeze an eligible outcome gauge before asking participants to stake on which proposal will improve it.

Instead of asking stakeholders only to choose between options A and B, futarchy asks them to stake tokens on which eligible proposal they believe will improve the agreed metric. Markets aggregate beliefs about consequences; they do not decide what is morally valuable or whose interests count.

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:

1. Proposal submitted with a metric definition (e.g. "30-day protocol revenue")
2. Two conditional token markets created: META-PASS (if proposal passes) and META-FAIL (if it fails)
3. Stakeholders trade in both markets for 10 days
4. Market prices reveal the expected impact: PASS-price > FAIL-price → proposal passes
5. 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:

1. Value conservation: total stake in PASS + FAIL markets = total tokens committed. No tokens created or destroyed in settlement.
2. 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.

Before Market

Do not open a conditional market until the proposal owner can complete this practice:

1. Complete a values-investor memo naming the beneficiary, eligibility constraints, evidence, and maximum acceptable loss.
2. Define the eligible proposals, including the status quo, without allowing the market to introduce an ineligible option.
3. Freeze one outcome metric, measurement window, causal assumptions, and manipulation guardrails.
4. Name who controls participation, market creation, oracle evidence, settlement, disputes, and emergency stops.
5. Dry-run settlement with adversarial cases before real capital or governance authority is committed.

Proof of readiness: a cold participant can explain what values remain outside the market, what belief the market estimates, how settlement works, and which evidence stops the proposal.

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
• Principles — decide which values and constraints govern eligible proposals.

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?

Changes my mind: Conditional markets do not improve forecast quality or accountability after values, participation rights, manipulation risk, and settlement evidence are held constant.

Next question: Can every participant explain the values boundary and write the prediction before staking?