ECIP 1117: Futarchy DAO Governance

Simple Summary

This proposal establishes a futarchy-based governance system for the Ethereum Classic treasury where prediction markets determine funding allocation decisions. Market participants trade on conditional outcome tokens representing protocol welfare under different funding scenarios, with proposals automatically executing when markets predict positive impact above defined thresholds.

Abstract

Ethereum Classic’s treasury governance transitions from traditional token voting to market-based decision aggregation through prediction markets. This ECIP implements Robin Hanson’s futarchy framework—”vote values, but bet beliefs”—where ETC holders democratically select welfare metrics while conditional prediction markets determine which proposals maximize those metrics. The system integrates privacy-preserving mechanisms from Nightmarket (zero-knowledge position encryption), anti-collusion infrastructure from MACI (encrypted key-change voting), and Gnosis Conditional Token Framework standards for market mechanics. Treasury funds allocated via ECIP-1116 support market infrastructure without extracting trading fees, creating a self-sustaining flywheel where prediction market activity generates gas fees that replenish treasury funding.

Motivation

The Governance Problem

Traditional DAO governance suffers from systematic failures that undermine long-term protocol sustainability. Token-weighted voting creates plutocratic control where large holders dominate decisions regardless of expertise. Voter apathy plagues participation—most governance proposals achieve less than ten percent turnout even in major protocols. Low-information voting compounds the problem as participants lack time or expertise to evaluate technical proposals, leading to popularity contests rather than merit-based selection.

These pathologies are well-documented across the DAO ecosystem. Compound’s Proposal 62 demonstrated how whales can unilaterally override community consensus. Uniswap’s governance forums show consistent patterns where complex technical proposals receive minimal engagement while simple token distribution proposals attract high participation. The fundamental issue is that voting conflates two distinct questions: what outcomes we want (values) and which actions achieve them (beliefs).

Why Futarchy Solves This

Futarchy separates these questions explicitly. Democratic voting establishes welfare metrics—measurable indicators of protocol success such as treasury value, transaction volume, or active address count. Prediction markets then aggregate distributed knowledge about which proposals maximize those metrics. This structure leverages economic incentives: traders profit by correctly predicting outcomes, creating pressure for informed participation. Unlike voting, where your incentive is to free-ride on others’ research, trading rewards private information aggregation.

MetaDAO’s implementation on Solana provides empirical validation. Over eighteen months, the protocol has processed sixty-two futarchy decisions across nine DAOs including Drift, Jito, and Marinade Finance. Key findings demonstrate that markets achieve meaningful price discovery even with modest liquidity, conditional tokens properly incentivize outcome-focused trading rather than speculation on governance processes, and ten to fourteen day trading periods provide sufficient time for information aggregation without excessive delay.

The Ethereum Classic treasury governance context intensifies these benefits. As ECIP-1017 reduces block rewards toward zero over coming decades, optimal allocation of treasury funds becomes existentially important. Poor funding decisions could starve protocol development precisely when fee-sustained security models require maximum infrastructure investment. Prediction markets provide a mechanism to channel treasury resources toward highest-impact initiatives based on aggregate market beliefs about likely outcomes rather than political coalition-building.

Privacy and Anti-Collusion Requirements

Public voting enables vote buying and bribery. If participants can prove how they voted, malicious actors can purchase governance influence through credible commitment mechanisms. Prediction markets face similar vulnerabilities—if position sizes and directions are public before settlement, front-running attacks and coordinated manipulation become trivial.

Nightmarket’s architecture demonstrates production-ready privacy solutions through Poseidon encryption of order flow, ECDH key exchange for buyer-seller coordination, and Groth16 zkSNARK proofs for position validity attestation. MACI extends this framework with key-change messages that enable voters to invalidate previous commitments, making vote buying unenforceable even if bribers think they’ve purchased influence.

For Ethereum Classic, these privacy mechanisms serve dual purposes. First, they prevent collusion and manipulation during market operation. Second, they preserve prediction market position privacy until settlement, enabling traders to accumulate positions without information leakage while still allowing transparent aggregate price discovery that drives governance decisions.

Economic Sustainability Through Fee Flywheel

Prediction market platforms typically extract trading fees ranging from zero point five to two percent of volume. These fees create deadweight loss that reduces market efficiency—wider bid-ask spreads, reduced liquidity provision, and diminished information aggregation. For governance markets where accuracy is paramount, any friction that reduces participation or distorts prices undermines the entire mechanism.

ECIP-1116 creates an alternative funding model. Base fees from all Ethereum Classic transactions flow to the treasury rather than being burned. This accumulated capital funds prediction market infrastructure—market maker subsidies, oracle costs, zero-knowledge proof verification gas, and frontend development—without charging explicit trading fees. The flywheel operates as follows:

1. Prediction market trading activity generates transaction volume

2. Transactions consume gas and generate base fees via EIP-1559 mechanics

3. Base fees accumulate in treasury per ECIP-1116

4. Treasury funds market infrastructure through ECIP-1118 funding proposals

5. Better infrastructure attracts more trading activity, returning to step one

This creates positive externalities where market participation directly funds the infrastructure that supports it, without individual participants bearing per-trade costs. Zero explicit fees maximize market efficiency while sustainable treasury funding ensures long-term operational viability.

Specification

Architecture Overview

The futarchy governance system consists of seven integrated components:

Welfare Metric Registry: On-chain storage of democratically-selected protocol success measures with versioning and update mechanisms.

Proposal Registry: Permissionless submission interface for funding requests with standardized metadata schemas and collateral bonding.

Conditional Market Factory: Automated deployment of pass-fail market pairs for each proposal using Gnosis CTF token standards.

Privacy Layer: MACI-style encrypted message submission with key-change capability and Nightmarket-style position encryption.

Oracle Resolution System: Multi-stage settlement process with designated reporters, open challenge periods, and UMA-style escalation mechanisms.

Settlement Engine: Automated execution of approved proposals with conditional fund release from ECIP-1112 vault.

Ragequit Module: Minority protection mechanism allowing dissenting token holders to exit with proportional treasury share before controversial proposal execution.

Welfare Metrics Framework

Protocol welfare metrics must be objectively measurable, manipulation-resistant, and meaningfully correlated with long-term protocol health. Initial metrics include:

Treasury Value (Primary): Time-weighted average price of total treasury holdings measured in USD equivalent over thirty-day rolling window. Calculated as:

W_treasury = TWAP_30d(Σ[asset_i × price_i]) for all i in treasury_assets

Network Activity (Secondary): Composite index of transaction count, active addresses, and total value settled. Calculated as:

W_activity = 0.4 × txn_count_normalized + 0.3 × active_addr_normalized + 0.3 × value_settled_normalized

Hash Rate Security (Tertiary): Network hash rate normalized against Bitcoin and other proof-of-work chains to measure relative security budget. Calculated as:

W_hashrate = ETC_hashrate / (ETC_hashrate + BTC_hashrate + other_PoW_hashrate)

Developer Activity (Quaternary): Weighted measure of GitHub commits, pull requests, and active contributors across ETC repositories. Calculated as:

W_dev = 0.5 × commits_score + 0.3 × pr_score + 0.2 × contributor_score

Metric selection and weighting requires democratic token holder voting with simple majority approval and fourteen-day voting period. Metric changes do not retroactively affect active markets—only newly-created proposals use updated metrics. This prevents governance manipulation through mid-market metric changes.

Proposal Submission Process

Any address may submit funding proposals following this workflow:

1. Collateral Bond: Proposer deposits bond in ETC (initially set at fifty ETC, governable parameter) that is returned upon good-faith market resolution. Bonds are forfeited for proposals deemed spam or malicious through DAO vote.

2. Proposal Metadata: Structured submission including:

{

  "title": "Proposal Title (max 100 chars)",

  "description": "Detailed description (max 5000 chars, IPFS hash for longer)",

  "funding_amount": "Amount in ETC requested from treasury",

  "recipient_address": "Address to receive funds if approved",

  "milestones": [

    {

      "description": "Milestone description",

      "percentage": "Percentage of total funding",

      "completion_criteria": "On-chain verifiable criteria",

      "timelock": "Release delay in days after previous milestone"

    }

  ],

  "welfare_metric": "Primary metric for market evaluation",

  "expected_impact": "Quantified expected improvement in welfare metric",

  "duration": "Estimated completion timeline in days",

  "verification_method": "How impact will be measured post-completion"

}

3. Review Period: Seven-day community review before market creation during which proposers can modify non-financial parameters based on feedback.

4. Market Creation: Conditional markets automatically deploy at review period conclusion unless DAO explicitly cancels proposal through emergency vote.

Conditional Market Mechanics

Each proposal generates two conditional prediction markets:

PASS Market: Trades on welfare metric value conditional on proposal approval and execution. Token symbol: P-[PROPOSAL_ID]

FAIL Market: Trades on welfare metric value conditional on proposal rejection. Token symbol: F-[PROPOSAL_ID]

Markets operate using Gnosis Conditional Token Framework with ETC as collateral. Traders deposit ETC and receive equal amounts of PASS and FAIL tokens. These tokens represent claims on future welfare metric values, redeemable after market resolution based on actual outcomes.

Market Parameters:

Trading Period: 10 days (governable, range 7-21 days)

Settlement Window: 3 days for oracle submission

Challenge Period: 2 days for dispute initiation  

Resolution Timelock: 1 day before execution

Total Duration: ~16 days proposal submission to execution

Liquidity Bootstrapping: 

  - Treasury provides initial 1000 ETC per market pair

  - Deployed via LMSR (Logarithmic Market Scoring Rule)

  - Liquidity parameter b = 100 (governable)

  

Price Discovery:

  - TWAP calculated over final 72 hours of trading

  - Outlier removal: prices beyond 3σ excluded

  - Minimum 100 trades required for valid TWAP

Automated Market Maker: Markets use pm-AMM (prediction market AMM) design from Paradigm research providing uniform expected loss-versus-rebalancing over the price range. Cost function:

C(q) = b × ln(Σ exp(qᵢ/b)) where:

  b = liquidity parameter

  qᵢ = quantity of outcome token i

  C = cost to market maker

This ensures bounded loss for treasury-provided liquidity while maintaining reasonable spreads across all price ranges.

Privacy-Preserving Position Submission

Market participants submit encrypted positions following MACI architecture:

1. Key Generation: Each participant generates EdDSA keypair (privKey, pubKey) off-chain.

2. Position Encryption: Orders encrypted using ECDH shared secret with coordinator public key:

sharedSecret = ECDH(participant_privKey, coordinator_pubKey)

encryptedPosition = Poseidon_encrypt(position_data, sharedSecret)

3. On-Chain Submission: Encrypted position committed on-chain with ZK proof of validity:

Proof_position = zkSNARK{

  Public: commitment = Hash(encryptedPosition, pubKey)

  Private: position_data, randomness

  Constraints:

    - position_data within valid ranges

    - commitment correctly computed

    - collateral requirements met

}

4. Key-Change Capability: Participants can submit encrypted key-change messages invalidating previous positions, preventing vote buying:

msg_keyChange = Encrypt{

  old_pubKey,

  new_pubKey,

  signature_old_privKey

}

Coordinator processes messages in submission order, applying key changes before position aggregation. This creates plausible deniability—even if participant reveals position to briber, they could have submitted key change invalidating it.

5. Settlement Revelation: After market resolution, participants reveal decryption keys to claim winnings. ZK proofs ensure revealed positions match commitments without exposing positions of non-winners.

Oracle Resolution System

Market settlement proceeds through multi-stage resolution with escalating dispute mechanisms:

Stage 1: Designated Reporter (Hours 0-72)

Proposal author serves as initial reporter, submitting welfare metric measurements with supporting data:

function submitReport(

  uint256 proposalId,

  uint256 passMetricValue,    // Measured welfare if proposal passed

  uint256 failMetricValue,    // Measured welfare if proposal failed  

  bytes calldata evidence      // IPFS hash of measurement methodology

) external onlyDesignatedReporter(proposalId)

Reporter must stake bond (initially 100 ETC, governable) that is returned if report unchallenged or upheld after disputes.

Stage 2: Open Challenge Period (Hours 72-120)

Any participant can dispute reporter’s measurements by staking challenge bond (initially 150 ETC) and providing counter-evidence:

function challengeReport(

  uint256 proposalId,

  uint256 challengedPassValue,

  uint256 challengedFailValue,

  bytes calldata counterEvidence,

  string calldata rationale

) external payable // msg.value must equal challengeBond

Multiple challenges aggregate—if consensus emerges around alternative values, those supersede reporter submission.

Stage 3: UMA-Style Dispute Resolution (Hours 120+)

If challenges lack consensus or reporter disputes challenges, escalation to UMA Data Verification Mechanism (DVM) or equivalent oracle system:

• Proposal evidence and counter-evidence published publicly

• Token holder vote on correct welfare metric values

• Voting period: 48 hours

• Quorum requirement: 5% of total supply

• Majority threshold: 66%

Losing parties (incorrect reporter or unsuccessful challengers) forfeit bonds, split between winning party (60%) and treasury (40%).

Stage 4: TWAP Calculation and Threshold Check

Resolved welfare metric values feed into decision algorithm:

TWAP_pass = time_weighted_average_price(PASS_market, final_72hrs)

TWAP_fail = time_weighted_average_price(FAIL_market, final_72hrs)

expected_welfare_pass = TWAP_pass × resolved_pass_metric

expected_welfare_fail = TWAP_fail × resolved_fail_metric

improvement_percentage = (expected_welfare_pass - expected_welfare_fail) / expected_welfare_fail

proposal_approved = improvement_percentage > approval_threshold

Approval threshold initially set at 3% (i.e., markets must predict at least 3% welfare improvement), configurable via governance vote.

Automated Proposal Execution

Approved proposals trigger automated settlement:

1. Market Resolution: Winning market tokens redeemable 1:1 for ETC collateral, losing market tokens expire worthless.

2. Grace Period: Seven-day ragequit window (see Ragequit Module) before fund transfer.

3. Conditional Transfer: Funds released from ECIP-1112 treasury vault to proposal recipient address subject to sanctions compliance per ECIP-1119.

4. Milestone Gating: If proposal specifies milestones, funds release according to schedule with on-chain verification:

function releaseMilestone(

  uint256 proposalId,

  uint256 milestoneIndex,

  bytes calldata completionProof

) external {

  require(milestones[proposalId][milestoneIndex].unlockTime <= block.timestamp);

  require(verifyCompletion(proposalId, milestoneIndex, completionProof));

  

  uint256 amount = milestones[proposalId][milestoneIndex].amount;

  treasury.transfer(recipient, amount);

  

  emit MilestoneReleased(proposalId, milestoneIndex, amount);

}

Milestone completion proofs vary by proposal type: GitHub commit hashes for development work, oracle-verified metrics for adoption targets, multi-signature attestations for service delivery.

Ragequit Minority Protection

Any token holder who voted NO on welfare metric selection or abstained retains right to exit with proportional treasury share before proposal execution:

1. Ragequit Window: Opens immediately upon proposal approval, remains open for seven days.

2. Share Calculation: Treasury share based on token holdings at proposal approval snapshot:

user_share = (user_tokens / total_supply) × available_treasury_value

available_treasury_value = total_treasury_value - locked_in_active_proposals

3. Irreversible Exit: Ragequit burns user tokens and transfers proportional treasury assets:

function ragequit(uint256 proposalId, uint256 tokenAmount) external {

  require(block.timestamp <= proposals[proposalId].ragequitDeadline);

  require(userVotedNoOrAbstained[proposalId][msg.sender]);

  

  // Burn tokens

  burn(msg.sender, tokenAmount);

  

  // Calculate and transfer pro-rata treasury share

  uint256 treasuryShare = (tokenAmount × availableTreasury) / totalSupply;

  treasury.transferAssets(msg.sender, treasuryShare);

  

  emit Ragequit(msg.sender, proposalId, tokenAmount, treasuryShare);

}

4. Multi-Asset Distribution: Treasury holdings distributed proportionally—if treasury holds 60% ETC, 30% stablecoins, 10% other assets, ragequitting members receive same ratio.

Ragequit prevents majority tyranny where contentious proposals approved by prediction markets still respect minority property rights. This mechanism is essential for maintaining legitimacy in futarchy governance where market decisions may not reflect universal consensus.

Gas Optimization and Batching

Individual prediction market trades impose significant gas costs from encryption, proof verification, and state updates. The system implements several optimization strategies:

Batch Position Submission: Coordinator accepts off-chain position submissions, aggregating into Merkle trees and submitting single on-chain proof:

function batchSubmitPositions(

  bytes32 merkleRoot,

  bytes calldata aggregateProof

) external onlyCoordinator {

  require(verifyBatchProof(merkleRoot, aggregateProof));

  positionCommitments[currentEpoch] = merkleRoot;

  

  emit BatchSubmitted(currentEpoch, merkleRoot, numPositions);

}

Individual participants later prove inclusion in batch when claiming winnings without requiring per-trade on-chain transactions.

Optimistic Rollup Settlement: High-frequency trading activity can occur off-chain with periodic checkpoints posted on-chain. Disputes trigger fraud proofs:

function challengeCheckpoint(

  uint256 checkpointId,

  bytes calldata fraudProof

) external {

  require(verifyFraudProof(checkpointId, fraudProof));

  revertCheckpoint(checkpointId);

  slashCoordinator();

}

EIP-4844 Blob Storage: Large proof data and position histories stored in blobs rather than calldata, reducing costs by approximately 10x:

function submitProofBlob(

  bytes calldata blobVersionedHash

) external {

  // Verify blob availability and correctness

  require(verifyBlobKZGProof(blobVersionedHash));

  // Store only hash on-chain

  proofHashes[currentEpoch] = blobVersionedHash;

}

Smart Contract Architecture

Core contracts implementing futarchy governance:

FutarchyGovernor.sol: Main governance coordinator

contract FutarchyGovernor {

  // Proposal lifecycle management

  mapping(uint256 => Proposal) public proposals;

  mapping(uint256 => ConditionalMarket) public markets;

  

  // Welfare metrics registry

  mapping(bytes32 => WelfareMetric) public metrics;

  

  function submitProposal(ProposalData calldata data) external payable returns (uint256);

  function createMarkets(uint256 proposalId) external returns (address, address);

  function resolveMarket(uint256 proposalId, ResolutionData calldata data) external;

  function executeProposal(uint256 proposalId) external;

}

ConditionalMarketFactory.sol: Deploys market pairs using CREATE2 for deterministic addressing

contract ConditionalMarketFactory {

  function deployMarketPair(

    uint256 proposalId,

    address collateralToken,

    uint256 liquidityAmount,

    uint256 liquidityParameter

  ) external returns (address passMarket, address failMarket);

}

PrivacyCoordinator.sol: Manages encrypted position submission and key-change messages

contract PrivacyCoordinator {

  mapping(address => bytes32) public publicKeys;

  mapping(uint256 => bytes32) public positionCommitments;

  

  function submitEncryptedPosition(

    bytes32 commitment,

    bytes calldata zkProof

  ) external;

  

  function submitKeyChange(

    bytes calldata encryptedKeyChange

  ) external;

  

  function processMessages(uint256 epochId) external onlyCoordinator;

}

OracleResolver.sol: Multi-stage resolution with dispute mechanisms

contract OracleResolver {

  enum ResolutionStage { DesignatedReporting, OpenChallenge, Dispute, Finalized }

  

  function submitReport(

    uint256 proposalId,

    uint256 passValue,

    uint256 failValue,

    bytes calldata evidence

  ) external;

  

  function challengeReport(

    uint256 proposalId,

    uint256 counterPassValue,

    uint256 counterFailValue,

    bytes calldata counterEvidence

  ) external payable;

  

  function escalateToUMA(uint256 proposalId) external;

  

  function finalizeResolution(uint256 proposalId) external;

}

RagequitModule.sol: Minority exit mechanism

contract RagequitModule {

  mapping(uint256 => mapping(address => bool)) public eligibleToRagequit;

  

  function ragequit(

    uint256 proposalId,

    uint256 tokenAmount

  ) external;

  

  function calculateTreasuryShare(

    address user,

    uint256 tokenAmount

  ) external view returns (uint256);

}

Integration with ECIP-1112 Treasury Vault

The futarchy governor contract requires privileged access to treasury funds:

Authorization Model: Treasury vault whitelist governance contract:

// In ECIP-1112 Treasury Vault

mapping(address => bool) public authorizedGovernance;

modifier onlyAuthorizedGovernance() {

  require(authorizedGovernance[msg.sender], "UNAUTHORIZED");

  _;

}

function executeProposal(

  address recipient,

  uint256 amount,

  bytes calldata data

) external onlyAuthorizedGovernance {

  // Execute approved proposal

}

Timelock Protection: All treasury interactions subject to minimum timelock (initially 2 days) allowing emergency intervention if exploit detected.

Spending Limits: Per-proposal and daily aggregate limits prevent catastrophic fund loss:

uint256 public maxProposalAmount = 50000 ether; // 50k ETC max per proposal

uint256 public dailySpendingLimit = 100000 ether; // 100k ETC max per day

mapping(uint256 => uint256) public dailySpending; // day => amount spent

Upgrade Mechanisms

Futarchy governance includes meta-governance capability—the system can govern its own evolution:

Governance Parameter Updates: Approval thresholds, trading periods, liquidity parameters modifiable through futarchy proposals targeting “Governance Quality” welfare metric.

Contract Upgrades: Smart contracts deployed as UUPS proxies with upgrade authority controlled by futarchy governance. Upgrade proposals create markets predicting impact on protocol welfare.

Emergency Pause: Multi-signature guardian council (initially 5-of-7 prominent ETC contributors) can pause governance in case of critical bug or exploit. Unpause requires futarchy proposal approval.

Progressive Decentralization: Guardian council authority decreases on fixed schedule:

Year 1: 5-of-7 multisig can pause

Year 2: 6-of-7 multisig can pause  

Year 3: 7-of-7 multisig can pause

Year 4+: Pause requires futarchy governance approval

Rationale

Why Futarchy Over Token Voting

Traditional token voting suffers from fundamental information problems. Voters face prisoner’s dilemma: individually rational to remain ignorant and free-ride on others’ research, collectively irrational as no one researches. This creates systematic low-information voting where proposals pass or fail based on popularity rather than merit.

Futarchy inverts the incentive structure. Market participants profit from correct predictions, creating private incentive for information acquisition. Unlike voting where your marginal impact on outcome is negligible, marginal trading moves prices and generates personal profit. This transforms governance from collective action problem into private profit-seeking activity that incidentally produces public good of accurate decision-making.

Empirical evidence from MetaDAO and theoretical analysis from Robin Hanson’s original 2000 paper “Shall We Vote on Values, But Bet on Beliefs?” support this mechanism. Markets consistently outperform expert predictions and democratic votes across diverse domains from elections to corporate earnings to geopolitical events.

Why Conditional Markets Specifically

Unconditional prediction markets on proposal outcomes (will X pass?) fail to capture impact. High pass-probability could indicate either strong expected impact or coordinated governance manipulation. Conditional markets separate these by measuring welfare conditional on execution, removing governance process from the information set.

Gnosis pioneered this design with Conditional Token Framework. The mathematical structure ensures proper incentive alignment: traders maximize expected value of conditional tokens, which directly corresponds to predicted welfare conditional on outcomes. This creates first-best information aggregation where market prices equal aggregated beliefs about true welfare impacts.

Why Privacy Matters

Public prediction markets enable front-running, wash trading, and coordinated manipulation. If large trader positions are visible, competitors can front-run their moves or execute opposite trades to manipulate prices. For governance decisions worth millions in treasury funds, these attacks become economically rational.

Nightmarket demonstrates privacy-preserving markets at production scale. MACI adds anti-collusion specifically designed for governance: key-change messages prevent vote buying even if voters prove their positions to bribers. This combination enables markets that are simultaneously private (protecting traders) and transparent (providing clear price signals).

The privacy-transparency balance works as follows: individual positions encrypted until settlement, aggregate prices published for governance decisions, final resolution reveals only winning positions for fund claiming. This maximizes information available to governance while minimizing information leakage enabling manipulation.

Why Zero Explicit Fees

Trading fees create deadweight loss that reduces market efficiency. A two percent fee effectively widens bid-ask spread by two percent, reducing liquidity provision and increasing slippage. For governance markets where decision accuracy is paramount, any friction reducing participation or distorting prices undermines the entire mechanism.

The ECIP-1116 base fee flywheel creates alternative: market activity generates gas fees, fees accumulate in treasury, treasury funds market infrastructure. This internalizes positive externalities—market participants who generate fees also benefit from better infrastructure those fees fund. Zero explicit fees maximize participation while sustainable treasury funding ensures operational viability.

Why Ragequit Protection

Futarchy prediction markets aggregate beliefs but don’t guarantee universal agreement. Contentious proposals may be approved despite significant minority opposition. Without exit rights, this creates moral hazard where majority can vote to spend minority’s treasury share against their wishes.

Ragequit, pioneered by Moloch DAO, provides credible exit threat that disciplines majority governance. If proposal is so controversial that significant minority exits, remaining members bear opportunity cost of reduced treasury value. This creates incentive for compromise and consensus-building even within futarchy framework.

The seven-day window balances protection and practicality. Long enough for informed decision-making about exit, short enough to not indefinitely delay proposal execution. Multi-asset proportional distribution ensures fairness—minority receives same asset composition as they contributed.

Why Multi-Stage Oracle Resolution

Single-oracle resolution creates centralization risk and manipulation vulnerability. If proposal author has unilateral resolution power, they could falsely report metrics to trigger execution. If external oracle has unilateral power, that oracle becomes attack target.

Multi-stage resolution with escalating dispute mechanisms provides defense-in-depth. Designated reporter (proposal author) has informational advantage making them best positioned for initial report. Open challenge period allows community correction. UMA escalation provides final backstop through token holder voting. Each stage increases decentralization at cost of time/complexity, applied only when necessary.

This mirrors judicial systems: most cases settle (designated reporter unchallenged), some require arbitration (community challenges), few require full trial (UMA escalation). The design minimizes cost of common case while ensuring robustness in adversarial scenarios.

Why These Specific Parameters

Ten-day trading period: MetaDAO testing shows markets reach price stability within seven days for simple proposals, ten to fourteen days for complex technical decisions. Ten days balances information aggregation with governance speed.

Three percent approval threshold: Prevents marginal proposals that markets predict minimal impact from consuming treasury resources. Small threshold reduces false negatives (rejecting beneficial proposals) while requiring meaningful predicted improvement.

Seven-day ragequit window: Standard across Moloch-derived DAOs. Empirically sufficient for informed exit decisions without excessive delay.

One thousand ETC liquidity per market: Provides sufficient depth for meaningful trading. At 15 USD per ETC, this is 15,000 USD per market pair—comparable to successful MetaDAO markets but scaled to ETC context.

LMSR liquidity parameter b=100: Balances price responsiveness with bounded loss. With one thousand ETC collateral and b=100, worst-case market maker loss approximately ten percent—acceptable for treasury-provided liquidity.

All parameters are governable through futarchy proposals, allowing empirical tuning based on observed market performance.

Backwards Compatibility

This ECIP supersedes ECIP-1113 which defined a traditional DAO governance structure for Olympia Treasury. Existing ECIP-1113 governance mechanisms must be deprecated and migrated to futarchy system.

Migration Strategy:

Phase 1 (Months 0-3): Deploy futarchy contracts alongside existing ECIP-1113 governance. Run parallel advisory futarchy where markets predict proposal impact but traditional governance remains binding. This provides training period for community to understand prediction market mechanics.

Phase 2 (Months 3-6): Transition to hybrid governance where both futarchy markets and traditional votes must approve proposals. Requires both market-predicted positive impact AND token holder majority approval.

Phase 3 (Months 6-12): Full transition to futarchy governance. Token holder voting retained only for welfare metric selection and emergency governance pauses. Day-to-day funding decisions determined by prediction markets.

Phase 4 (Month 12+): Deprecate legacy ECIP-1113 contracts. All governance proceeds through futarchy mechanism.

Backwards Compatibility Considerations:

• ECIP-1112 treasury vault interface remains unchanged—futarchy governor simply calls existing withdrawal functions

• ECIP-1116 base fee allocation unchanged—continues flowing to same treasury address

• ECIP-1118 funding proposal format extends but doesn’t break ECIP-1114 proposal structure

No consensus rule changes required—all futarchy logic operates at smart contract layer above ETC protocol consensus.

Security Considerations

Attack Vectors and Mitigations

Market Manipulation: Attackers could attempt to manipulate prediction market prices to force proposal approval or rejection regardless of true expected welfare impact.

Mitigation: Multi-oracle resolution with challenge periods prevents false metric reporting. TWAP price averaging over 72 hours forces manipulators to sustain artificial prices across extended period. Privacy-preserving position encryption prevents coordination. Treasury-provided liquidity via LMSR creates capital requirements for manipulation—attacker must overcome automated market maker liquidity to move prices.

Oracle Corruption: If oracle resolution becomes corrupted, attackers could falsely report welfare metrics to trigger unwarranted proposal execution.

Mitigation: Three-stage resolution with escalating decentralization. Designated reporter provides initial efficiency, community challenges provide oversight, UMA token holder voting provides final backstop. Bond requirements for reporters and challengers create economic cost of false reporting. Multi-signature emergency pause authority can intervene if systematic oracle failure detected.

Front-Running: Public mempool visibility could enable front-running of large prediction market positions.

Mitigation: Encrypted position submission with batching. Individual trades invisible to mempool watchers. Batch commitments revealed only after confirmation. Flashbots-style private transaction relay optional for additional protection.

Sybil Attacks: Attacker creates many fake identities to dominate market trading or governance voting.

Mitigation: All market participation requires ETC capital. Sybil attack becomes equivalent to capital attack—must accumulate sufficient ETC to manipulate markets, which is expensive. For ragequit and emergency governance voting, token weighting makes Sybil attacks economically equivalent to capital concentration.

Collusion: Multiple participants coordinate to manipulate markets or governance outcomes.

Mitigation: MACI key-change messages prevent verifiable vote buying. Privacy-preserving positions prevent collusion detection during trading period. After settlement, winners have incentive to defect from collusion since individual profit depends on actually being correct, not maintaining cartel.

Governance Capture: Wealthy actors accumulate large token positions to control welfare metric selection.

Mitigation: Welfare metric voting separate from prediction market trading. Token holders can select metrics favoring long-term protocol health even if short-term proposal markets show adverse selection. Ragequit provides exit for minority preventing forced participation under captured governance.

Smart Contract Bugs: Implementation vulnerabilities could enable fund theft or governance manipulation.

Mitigation: All contracts undergo professional security audit before mainnet deployment. Multi-signature guardian council retains emergency pause authority during initial deployment. Progressive decentralization schedule gradually reduces guardian power as system proves reliability. Bug bounty program incentivizes white-hat disclosure.

Economic Attacks on Privacy: Sophisticated attackers could use side-channel analysis or transaction graph analysis to de-anonymize prediction market positions despite encryption.

Mitigation: Batched position submission prevents transaction timing correlation. Poseidon encryption specifically designed to resist side-channel attacks. Optional mixing periods where positions settle before next epoch begins. Users can employ additional privacy techniques like Tor or VPN for transaction submission.

Griefing and Spam Vectors

Proposal Spam: Malicious actors submit many low-quality proposals to overwhelm governance bandwidth.

Mitigation: Fifty ETC bond requirement per proposal (governable parameter). Bonds forfeited for proposals deemed spam through DAO vote. Economic cost of sustained spam campaign becomes prohibitive.

Dispute Spam: Malicious actors challenge legitimate oracle reports to delay proposal execution.

Mitigation: Challenge bonds (initially 150 ETC) must exceed reporter bonds to prevent cheap griefing. Unsuccessful challengers forfeit bonds. Multi-signature authority can fast-track obviously frivolous disputes.

Market Drain Attacks: Adversarial trading attempting to drain treasury-provided liquidity from automated market maker.

Mitigation: LMSR bounded-loss design guarantees maximum ten percent loss per market regardless of adversarial trading. After trading period ends, liquidity withdrawn and recycled for future markets. Per-market loss is acceptable cost for information aggregation.

Regulatory and Legal Considerations

Securities Law: Prediction market tokens may be considered securities under some jurisdictions’ definitions.

Mitigation: Prediction markets structured as non-custodial, automated protocols without central operator. Conditional tokens are pure information goods—no expectation of profit from others’ efforts, only from accurate predictions. Markets limited to protocol governance decisions, not general speculation. Legal review recommended before deployment.

Sanctions Compliance: Treasury fund disbursements must comply with international sanctions per ECIP-1119.

Mitigation: Integrated sanctions compliance layer checks all withdrawal addresses against oracle-provided sanctions lists before fund release. Blocked funds return to treasury rather than transferring to sanctioned addresses.

Tax Implications: Prediction market winnings may constitute taxable income in various jurisdictions.

Mitigation: Protocol cannot provide tax advice. Users responsible for compliance with local tax obligations. Smart contracts generate event logs enabling off-chain tax calculation and reporting.

Implementation

Reference Implementation

Reference implementation available at: https://github.com/ethereumclassic/ecips/implementations/ecip-1117 (to be created)

Core contracts:

• FutarchyGovernor.sol: Main governance coordinator

• ConditionalMarketFactory.sol: Market deployment

• PrivacyCoordinator.sol: Encrypted position handling

• OracleResolver.sol: Multi-stage resolution

• RagequitModule.sol: Minority exit mechanism

Supporting libraries:

• PoseidonEncryption.sol: SNARK-friendly encryption

• MACIKeyRegistry.sol: Key-change message processing

• TWAPOracle.sol: Time-weighted average price calculation

Deployment Plan

Testnet Deployment (Mordor):

Block height: TBD (coordinate with ECIP-1116 activation)

Duration: Minimum 3 months testing

Test scenarios:

• Simple funding proposals with clear success criteria

• Complex multi-milestone proposals

• Contentious proposals triggering ragequit

• Oracle dispute resolution

• Market manipulation attempts

• Gas optimization profiling

Mainnet Deployment:

Block height: TBD (minimum 3 months after successful Mordor testing)

Activation: Coordinated with ECIP-1116 and ECIP-1112 deployment

Initial parameters: Conservative settings with guardian council oversight

Progressive decentralization: 12-month schedule for reducing emergency powers

Client Implementation Requirements

All ETC client implementations (Core-Geth, Hyperledger Besu, etc.) must support:

• Standard EVM smart contract execution (no consensus changes required)

• EIP-1559 base fee mechanics per ECIP-1111

• BN128 elliptic curve precompiles for zkSNARK verification (addresses 0x06-0x08)

• Optional EIP-4844 blob transactions for gas optimization

No core protocol modifications required—entire futarchy system operates at smart contract layer.

Audit Requirements

Before mainnet deployment:

• Minimum two independent professional security audits

• Public audit report publication

• 30-day community review period after audit completion

• Bug bounty program (recommended minimum 100k USD equivalent in ETC)

• Formal verification of critical invariants:

  • Fund safety: treasury balance never decreases except via authorized proposals

  • Market resolution correctness: tokens redeem for correct values

  • Ragequit safety: exiting members receive exactly proportional share

Monitoring and Analytics

Post-deployment monitoring dashboard tracking:

• Active proposals and market states

• Trading volume and liquidity metrics

• Oracle resolution accuracy and dispute frequency

• Ragequit utilization rates

• Gas consumption patterns

• Treasury balance and allocation

Copyright

This work is licensed under the Apache License, Version 2.0.

References

1. Robin Hanson (2000), “Shall We Vote on Values, But Bet on Beliefs?”, http://mason.gmu.edu/~rhanson/futarchy.html

2. Vitalik Buterin (2014), “An Introduction to Futarchy”, Ethereum Foundation Blog

3. MetaDAO (2024), “Futarchy in Production: 18 Months of Market-Based Governance”, https://metadao.fi

4. Gnosis (2020), “Conditional Token Framework Documentation”, https://docs.gnosis.io/conditionaltokens/

5. MACI Team (2023), “Minimum Anti-Collusion Infrastructure Specification”, https://github.com/privacy-scaling-explorations/maci

6. Nightmarket (2024), “[Guest Post] Nightmarket”, Dark Forest Blog, https://blog.zkga.me/nightmarket

7. Paradigm Research (2024), “pm-AMM: A Uniform AMM for Prediction Markets”, https://www.paradigm.xyz/2024/11/pm-amm

8. ECIP-1017 (2016), “Monetary Policy and Final Modification to the Ethereum Classic Emission Schedule”

9. ECIP-1112 (2024), “Olympia Treasury Contract Specification”

10. ECIP-1116 (2024), “Base Fee Development Investment Protocol” (this ECIP series)

11. ECIP-1118 (2024), “Prediction Market Funding Proposals” (this ECIP series)

12. ECIP-1119 (2024), “International Sanctions Compliance Filter” (this ECIP series)

13. Moloch DAO (2019), “Moloch v1 Specification”, https://github.com/MolochVentures/moloch

14. UMA Protocol (2023), “Optimistic Oracle Documentation”, https://docs.uma.xyz

15. Vitalik Buterin et al (2023), “Blockchain Privacy and Regulatory Compliance”, a16z Crypto Research