ECIP 1118: Futarchy Funding and Streaming Disbursements

Simple Summary

This proposal establishes the funding mechanisms for prediction market infrastructure and approved proposals, creating a zero-fee market ecosystem sustained by base fee accumulation. Treasury funds deploy as liquidity provider capital, market maker incentives, oracle operation costs, and streaming payments to approved proposals with milestone-gated releases.

Abstract

ECIP-1118 defines the economic infrastructure enabling futarchy governance through sustainable prediction market operation. Rather than extracting trading fees that create deadweight loss and reduce information aggregation, the system funds all market operations through ECIP-1116 base fee accumulation. Treasury capital deploys in three primary channels: automated market maker liquidity provision using pm-AMM algorithms for efficient price discovery, competitive oracle service funding for sanctions compliance and metric resolution, and streaming disbursements to approved proposals with milestone-gated releases and clawback provisions. The fee flywheel creates positive feedback where prediction market activity generates transaction volume, transactions produce base fees that accumulate in treasury, and treasury funds market infrastructure that attracts more trading activity. This self-sustaining model eliminates explicit trading fees while ensuring long-term operational viability.

Motivation

The Fee Problem in Prediction Markets

Traditional prediction market platforms face a fundamental economic tension between revenue generation and market efficiency. Centralized platforms like Kalshi charge 3-7% trading fees to fund operations, covering infrastructure costs, regulatory compliance, and profit margins. Decentralized platforms typically charge lower fees but still impose 0.1-2% on trades to compensate liquidity providers and fund protocol development.

These fees create measurable harm to prediction market quality. Academic research on betting exchanges demonstrates that each percentage point of trading fees reduces market depth by approximately 8-12% and increases bid-ask spreads by 5-7%. For governance prediction markets where decision accuracy is paramount, these efficiency losses directly undermine the futarchy mechanism. If markets are less liquid and prices are less accurate due to fee-induced friction, governance decisions based on those prices become correspondingly less reliable.

Polymarket’s zero-fee model demonstrates market demand for fee-free prediction markets. The platform achieved over $1 billion cumulative trading volume in 2024 without charging explicit trading fees, instead subsidizing operations through venture capital and liquidity provider incentive programs. However, this model lacks long-term sustainability—venture subsidies eventually exhaust, creating pressure to introduce fees or restrict access.

The BASEFEE Flywheel Solution

ECIP-1116 creates an alternative funding mechanism unique to Ethereum Classic’s architecture. Unlike Ethereum mainnet where EIP-1559 base fees are burned (creating deflationary pressure), ETC redirects base fees to the Olympia Treasury. This accumulated capital provides sustainable funding for prediction market infrastructure without extracting value from individual traders.

The economic flywheel operates as follows:

Cycle 1: Initial Bootstrapping

• Treasury deploys capital as automated market maker liquidity (e.g., 1,000 ETC per market pair)

• Early prediction market trading generates modest transaction volume

• Base fees from those transactions flow back to treasury

• Treasury balance grows from base fee accumulation

Cycle 2: Market Maker Incentives

• Treasury funds competitive market maker programs rewarding tight spreads and consistent depth

• Professional market makers deploy additional capital attracted by incentive subsidies

• Improved liquidity attracts more trading volume as slippage costs decrease

• Increased trading volume generates proportionally more base fee revenue

Cycle 3: Infrastructure Scaling

• Treasury funds oracle services, zkSNARK proof verification gas subsidies, and frontend development

• Better infrastructure attracts institutional participants and larger trade sizes

• Higher quality markets attract more proposals and governance activity

• Growing ecosystem generates exponentially increasing transaction volume

Steady State: Self-Sustaining Equilibrium

• Base fee revenue consistently exceeds infrastructure costs

• Excess treasury accumulation funds new initiatives or increases reserves

• Zero explicit fees maintain maximum market efficiency

• Network effects create moat against competing governance systems

This model transforms prediction markets from cost centers requiring fee extraction into value-generating public goods that strengthen the entire protocol.

Streaming Payments and Milestone Gating

Traditional DAO treasury disbursements suffer from principal-agent problems. Proposals receive lump-sum funding upfront, creating moral hazard where recipients can abandon projects after receiving payment without completing promised deliverables. Even well-intentioned teams face coordination challenges if funding arrives all at once without accountability mechanisms.

Streaming payment protocols like Sablier and Superfluid enable continuous, by-the-second fund transfers that can be conditionally gated on milestone completion. This aligns incentives between treasury and proposal recipients: funds flow continuously as work progresses, deliverables can be verified before next milestone unlocks, underperforming projects can be terminated mid-stream without total capital loss, and recipients have stable cash flow rather than uncertain lump sums.

For Ethereum Classic treasury governance, milestone-gated streaming creates additional accountability. Prediction markets approve proposals based on expected welfare improvement, but actual execution quality varies. Streaming with milestones provides mechanism to course-correct: if early milestones demonstrate poor execution, remaining funds can be clawed back before total budget is spent; if early milestones exceed expectations, additional funding can be approved through new proposal; and market maker capital deployed in original approval can be re-allocated based on empirical performance.

Infrastructure Funding Requirements

Futarchy governance requires continuous operational funding across multiple categories:

Oracle Services: Multi-oracle sanctions compliance per ECIP-1119 requires continuous data feed subscriptions. Commercial providers (Chainalysis, TRM Labs, Elliptic) charge API fees, require service level agreements with bond commitments, and need ongoing technical integration maintenance. Estimated cost: 5,000-10,000 USD monthly for comprehensive multi-jurisdiction sanctions screening.

Gas Subsidies: zkSNARK proof verification consumes significant gas. At current ETC gas prices, each Groth16 proof verification costs approximately 250,000 gas. For privacy-preserving prediction markets processing 100 trades daily, this represents substantial ongoing cost. Treasury can subsidize proof verification gas to reduce participant friction while still generating net positive base fees from associated transaction volume.

Market Maker Operations: Professional market makers require capital efficiency and revenue certainty. Treasury-funded incentive programs can attract institutional market makers by guaranteeing minimum returns (e.g., 8% APY on deployed capital) while still capturing upside if market activity exceeds expectations. This ensures consistent liquidity even during low-activity periods.

Frontend Development: User-friendly interfaces require continuous development, security updates, and server infrastructure. Prediction market frontends need sophisticated features: real-time price charts, position management, encrypted transaction submission, and zkSNARK proof generation. Estimated cost: 100,000-200,000 USD annually for professional frontend maintenance.

Emergency Reserves: Treasury should maintain 12-18 months operating expenses in stablecoins to ensure continuous operation even if base fee revenue temporarily declines during market downturns.

ECIP-1118 establishes the funding framework for all these operational categories through formalized proposal types, competitive bidding mechanisms, and transparent allocation criteria.

Specification

Treasury Capital Allocation Framework

Treasury funds partition into four primary categories with dynamic rebalancing based on utilization and ROI:

Category 1: Automated Market Maker Liquidity (40-60% of available capital)

Purpose: Provide baseline liquidity for all prediction markets without requiring external capital.

Allocation: 1,000 ETC per market pair (PASS/FAIL markets) deployed at market creation.

Recovery: Liquidity withdrawn at market resolution and recycled for future markets.

Risk: Bounded loss via LMSR design (maximum 10% loss per market).

Performance Metric: Utilization rate—if more than 80% of available liquidity is deployed, increase allocation; if less than 40% deployed, decrease allocation.

Category 2: Market Maker Incentive Programs (20-30% of available capital)

Purpose: Attract external liquidity providers to enhance market depth and tighten spreads beyond treasury-provided baseline.

Allocation: Competitive programs with quarterly disbursements based on performance.

Eligibility: Market makers must maintain minimum 5,000 ETC deployed capital and meet uptime/spread requirements.

Rewards: Base 5% APY on deployed capital plus performance bonuses for exceptional spread tightness.

Performance Metric: Spread reduction relative to treasury-only baseline—tighter spreads justify higher incentive budgets.

Category 3: Infrastructure Operations (15-25% of available capital)

Purpose: Fund continuous oracle services, gas subsidies, frontend development, and administrative overhead.

Allocation: Quarterly budgets approved through futarchy governance proposals.

Subcategories:

• Oracle services: 30-40% of infrastructure budget

• Gas subsidies: 20-30% of infrastructure budget

• Frontend development: 25-35% of infrastructure budget

• Administration/overhead: 10-15% of infrastructure budget

Performance Metric: Cost per active market participant—declining costs indicate efficiency improvements.

Category 4: Strategic Reserves (10-20% of available capital)

Purpose: Maintain liquidity buffer for unexpected costs, market downturns, or emergency situations.

Allocation: Primarily stablecoins (USDC, DAI) to reduce volatility exposure.

Usage: Restricted to emergency situations or futarchy-approved exceptional proposals.

Performance Metric: Reserve ratio—maintain minimum 12 months operating expenses, maximum 24 months to avoid excessive idle capital.

Dynamic rebalancing occurs quarterly based on empirical performance metrics and base fee accumulation rates.

Automated Market Maker Deployment

Each prediction market receives automated market maker liquidity using pm-AMM (prediction market AMM) design from Paradigm research:

Liquidity Deployment Process:

function deployMarketLiquidity(

    address passMarket,

    address failMarket,

    uint256 liquidityAmount

) internal returns (uint256 liquidityId) {

    // Calculate initial token distribution for balanced market

    uint256 tokensPerOutcome = liquidityAmount / 2;

    

    // Mint conditional tokens

    conditionTokens.splitPosition(

        address(this),           // collateral holder

        bytes32(0),              // parent collection (none)

        conditionId,             // market condition

        [passIndex, failIndex],  // outcome slots

        liquidityAmount          // collateral amount

    );

    

    // Deploy pm-AMM with optimal parameters

    PredictionMarketAMM amm = new PredictionMarketAMM({

        liquidityParameter: calculateOptimalB(liquidityAmount),

        feeRate: 0,  // Zero fees—critical for ECIP-1118

        outcomeTokens: [passMarket, failMarket]

    });

    

    // Transfer tokens to AMM

    IERC1155(conditionTokens).safeTransferFrom(

        address(this),

        address(amm),

        passTokenId,

        tokensPerOutcome,

        ""

    );

    

    IERC1155(conditionTokens).safeTransferFrom(

        address(this),

        address(amm),

        failTokenId,

        tokensPerOutcome,

        ""

    );

    

    emit LiquidityDeployed(liquidityId, passMarket, failMarket, liquidityAmount);

}

pm-AMM Cost Function:

The pm-AMM uses logarithmic market scoring rule (LMSR) adapted for prediction markets:

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

where:

  C = cost function value

  b = liquidity parameter (initially 100)

  qᵢ = outstanding quantity of outcome token i

  

Price derivation:

  pᵢ = ∂C/∂qᵢ = exp(qᵢ/b) / Σⱼ exp(qⱼ/b)

This design ensures:

• Bounded loss: Maximum loss = b × ln(n) where n = number of outcomes (for binary markets, max loss ≈ 0.69b)

• Continuous liquidity: Always possible to trade at some price

• Proper scoring: Market maker behaves as proper scoring rule rewarding accurate predictions

• Price stability: Large liquidity parameter b reduces price sensitivity to individual trades

Optimal Liquidity Parameter Calculation:

function calculateOptimalB(uint256 liquidityAmount) internal pure returns (uint256) {

    // Target ~10% maximum loss

    // For binary market: maxLoss = b × ln(2) ≈ 0.69b

    // Therefore: b ≈ liquidityAmount × 0.10 / 0.69 ≈ liquidityAmount × 0.145

    return liquidityAmount * 145 / 1000;

}

With 1,000 ETC liquidity, optimal b ≈ 145, limiting maximum loss to ~100 ETC per market pair.

Liquidity Recovery at Resolution:

function recoverLiquidity(uint256 marketId) external onlyAfterResolution(marketId) {

    Market storage market = markets[marketId];

    

    // Redeem winning outcome tokens for collateral

    uint256 winningPayout = conditionTokens.redeemPositions(

        address(this),

        bytes32(0),

        market.conditionId,

        market.outcomeIndexes

    );

    

    // Calculate profit/loss

    int256 pnl = int256(winningPayout) - int256(market.initialLiquidity);

    

    // Update treasury accounting

    if (pnl >= 0) {

        treasuryBalance += uint256(pnl);

        emit LiquidityProfit(marketId, uint256(pnl));

    } else {

        treasuryBalance -= uint256(-pnl);

        emit LiquidityLoss(marketId, uint256(-pnl));

    }

    

    // Make recovered capital available for next market

    availableLiquidity += winningPayout;

}

Empirical data from MetaDAO suggests average market maker loss of 3-5% per market, well within the 10% bound.

Market Maker Incentive Programs

External market makers can compete for treasury-funded incentive programs by meeting performance criteria:

Eligibility Requirements:

struct MarketMakerRequirements {

    uint256 minimumDeployedCapital;     // Initially 5,000 ETC

    uint256 minimumUptime;              // 95% (maximum 36 hours downtime monthly)

    uint256 maximumSpread;              // 2% spread maximum

    uint256 minimumDepth;               // 500 ETC at best bid/ask

    uint256 minimumResponseTime;        // Quote updates within 60 seconds of oracle data

    bool kycCompleted;                  // Institutional KYC for large programs

}

Performance-Based Rewards:

Market makers earn rewards through two mechanisms:

Base Rewards: Fixed APY on deployed capital meeting minimum requirements.

function calculateBaseReward(

    address marketMaker,

    uint256 deployedCapital,

    uint256 daysActive

) public view returns (uint256) {

    require(meetsRequirements(marketMaker), "REQUIREMENTS_NOT_MET");

    

    // 5% APY base rate

    uint256 annualReward = deployedCapital * 5 / 100;

    uint256 dailyReward = annualReward / 365;

    

    return dailyReward * daysActive;

}

Performance Bonuses: Additional rewards for exceptional performance.

function calculatePerformanceBonus(

    address marketMaker,

    uint256 period

) public view returns (uint256) {

    MarketMakerStats memory stats = marketMakerStats[marketMaker][period];

    

    uint256 bonus = 0;

    

    // Spread tightness bonus (up to +2% APY)

    if (stats.averageSpread < 50) {  // <0.5% spread

        bonus += stats.deployedCapital * 2 / 100;

    } else if (stats.averageSpread < 100) {  // <1% spread

        bonus += stats.deployedCapital * 1 / 100;

    }

    

    // Uptime bonus (up to +1% APY)

    if (stats.uptime >= 99_50) {  // 99.5%+ uptime

        bonus += stats.deployedCapital * 1 / 100;

    } else if (stats.uptime >= 98_00) {  // 98%+ uptime

        bonus += stats.deployedCapital * 50 / 10000;  // 0.5%

    }

    

    // Volume bonus (up to +2% APY)

    if (stats.volumeFacilitated >= 100_000 ether) {

        bonus += stats.deployedCapital * 2 / 100;

    } else if (stats.volumeFacilitated >= 50_000 ether) {

        bonus += stats.deployedCapital * 1 / 100;

    }

    

    return bonus;

}

Maximum total compensation: 10% APY (5% base + 5% maximum bonuses).

Competitive Selection Process:

Market maker programs operate on quarterly cycles with competitive application:

1. RFP Publication: Treasury publishes quarterly budget and requirements.

2. Application Period: Market makers submit proposals specifying deployed capital commitments and expected performance metrics.

3. Evaluation: Futarchy governance creates prediction market on aggregate market quality improvement under different market maker selections.

4. Selection: Top performers by predicted market quality improvement receive program slots up to budget limit.

5. Performance Monitoring: Continuous tracking of uptime, spreads, and volume facilitated.

6. Settlement: Quarterly reward distributions based on actual performance.

Slashing for Non-Performance:

Market makers failing to meet requirements face progressive penalties:

function slashMarketMaker(

    address marketMaker,

    SlashReason reason

) external onlyGovernance {

    uint256 slashAmount;

    

    if (reason == SlashReason.UptimeViolation) {

        // 5% slash per 1% uptime below requirement

        uint256 uptimeDelta = MINIMUM_UPTIME - marketMakerStats[marketMaker].uptime;

        slashAmount = marketMakerStakes[marketMaker] * uptimeDelta * 5 / 100;

    } else if (reason == SlashReason.SpreadViolation) {

        // 10% slash for consistent excessive spreads

        slashAmount = marketMakerStakes[marketMaker] * 10 / 100;

    } else if (reason == SlashReason.CapitalWithdrawal) {

        // 15% slash for withdrawing capital mid-program

        slashAmount = marketMakerStakes[marketMaker] * 15 / 100;

    }

    

    // Transfer slashed funds to treasury

    marketMakerStakes[marketMaker] -= slashAmount;

    treasuryBalance += slashAmount;

    

    emit MarketMakerSlashed(marketMaker, reason, slashAmount);

}

Infrastructure Funding Proposals

Infrastructure providers submit proposals for continuous operational funding:

Proposal Types:

Type 1: Oracle Service Providers

{

  "proposalType": "oracle_service",

  "serviceCategory": "sanctions_compliance",

  "provider": "Provider Name",

  "dataSources": ["OFAC SDN List", "EU Consolidated List", "UN Sanctions"],

  "updateFrequency": "Every 6 hours",

  "apiEndpoint": "https://api.provider.com/sanctions",

  "slaCommitments": {

    "uptime": "99.9%",

    "latency": "<500ms",

    "freshnessGuarantee": "<24 hours from source update"

  },

  "pricingModel": {

    "monthlyCost": "5000 USD equivalent in ETC",

    "perQueryCost": "0.01 USD equivalent",

    "volumeDiscounts": "10% discount at >10k queries/month"

  },

  "bondRequirement": "10000 ETC",

  "contractDuration": "12 months"

}

Type 2: Gas Subsidy Programs

{

  "proposalType": "gas_subsidy",

  "targetOperations": ["zkSNARK verification", "batch position settlement"],

  "estimatedMonthlyVolume": "1000 verifications",

  "subsidyPercentage": "50%",

  "monthlyCost": "2000 USD equivalent in ETC",

  "eligibilityRequirements": {

    "minimumParticipation": "5 active markets",

    "verificationRequired": "Must use approved zkSNARK circuits"

  }

}

Type 3: Frontend Development

{

  "proposalType": "frontend_development",

  "scope": "Prediction market trading interface",

  "deliverables": [

    "Real-time price charts with TWAP indicators",

    "Encrypted position submission interface",

    "zkSNARK proof generation client-side",

    "Market discovery and filtering",

    "Historical performance analytics"

  ],

  "milestones": [

    {"description": "Core trading interface", "percentage": 30, "timeline": "3 months"},

    {"description": "Privacy features integration", "percentage": 30, "timeline": "6 months"},

    {"description": "Advanced analytics", "percentage": 20, "timeline": "9 months"},

    {"description": "Mobile responsive + PWA", "percentage": 20, "timeline": "12 months"}

  ],

  "totalCost": "150000 USD equivalent in ETC",

  "paymentSchedule": "Streaming with milestone gates",

  "maintenanceCommitment": "24 months post-delivery"

}

Evaluation Criteria:

Infrastructure proposals evaluated on weighted scorecard:

Total Score = (Technical Merit × 0.30) + 

              (Cost Effectiveness × 0.25) + 

              (Team Experience × 0.20) + 

              (Security Practices × 0.15) + 

              (Community Support × 0.10)

Approval Threshold: 70/100 minimum score

Futarchy governance creates prediction markets on infrastructure quality improvements, predicting impact on overall governance system performance.

Streaming Payment Implementation

Approved proposals receive funds through streaming payment contracts integrated with Sablier v2 protocol:

Stream Creation:

function createProposalStream(

    uint256 proposalId,

    address recipient,

    uint256 totalAmount,

    uint256 duration,

    Milestone[] calldata milestones

) external onlyGovernance returns (uint256 streamId) {

    // Create Sablier stream

    streamId = sablier.createWithMilestones({

        sender: address(treasury),

        recipient: recipient,

        totalAmount: totalAmount,

        asset: address(etc),  // ETC token

        cancelable: true,     // Enable clawback

        transferable: false,  // Non-transferable to recipient only

        startTime: block.timestamp,

        milestones: convertToSablierMilestones(milestones)

    });

    

    proposalStreams[proposalId] = streamId;

    emit StreamCreated(proposalId, streamId, recipient, totalAmount);

}

Milestone Structure:

struct Milestone {

    string description;

    uint256 percentage;           // Percentage of total funding

    uint256 unlockTime;          // Timestamp when milestone can be verified

    bytes32 verificationMethod;  // Hash of verification criteria

    bool completed;

    bytes verificationProof;     // Proof of completion

}

Milestone Verification and Unlock:

function verifyAndUnlockMilestone(

    uint256 proposalId,

    uint256 milestoneIndex,

    bytes calldata proof

) external {

    Proposal storage proposal = proposals[proposalId];

    Milestone storage milestone = proposal.milestones[milestoneIndex];

    

    require(block.timestamp >= milestone.unlockTime, "TOO_EARLY");

    require(!milestone.completed, "ALREADY_COMPLETED");

    

    // Verify milestone completion based on method

    bool verified = false;

    

    if (milestone.verificationMethod == VERIFICATION_ORACLE) {

        // Oracle-based verification (e.g., GitHub commit hash verification)

        verified = oracleVerification(proof);

    } else if (milestone.verificationMethod == VERIFICATION_MULTISIG) {

        // Multi-signature attestation from designated verifiers

        verified = multisigVerification(proof);

    } else if (milestone.verificationMethod == VERIFICATION_ONCHAIN) {

        // On-chain metric verification (e.g., transaction count threshold)

        verified = onchainMetricVerification(proof);

    }

    

    require(verified, "VERIFICATION_FAILED");

    

    // Mark milestone complete and update stream

    milestone.completed = true;

    milestone.verificationProof = proof;

    

    // Unlock next portion of stream

    sablier.unlockMilestone(proposalStreams[proposalId], milestoneIndex);

    

    emit MilestoneVerified(proposalId, milestoneIndex, proof);

}

Clawback Mechanism:

If proposal underperforms or fails to meet milestones, governance can cancel stream and recover remaining funds:

function clawbackProposalFunds(

    uint256 proposalId,

    string calldata reason

) external onlyGovernance {

    uint256 streamId = proposalStreams[proposalId];

    

    // Calculate streamed vs remaining amounts

    (uint256 streamed, uint256 remaining) = sablier.streamedAndRemaining(streamId);

    

    // Cancel stream and return remaining funds to treasury

    sablier.cancel(streamId);

    

    treasuryBalance += remaining;

    

    emit FundsClawed(proposalId, remaining, reason);

}

Clawback decisions require futarchy governance approval predicting that fund recovery improves treasury welfare more than continuing stream.

Fee Flywheel Accounting

Treasury tracks base fee accumulation and deployment across funding categories:

Base Fee Revenue Tracking:

function recordBaseFeeRevenue(uint256 blockNumber) external {

    // Called by consensus layer after each block

    uint256 baseFee = getBaseFeeForBlock(blockNumber);

    

    // Accumulate to treasury

    treasuryBalance += baseFee;

    

    // Update rolling statistics

    dailyBaseFees[currentDay()] += baseFee;

    monthlyBaseFees[currentMonth()] += baseFee;

    

    emit BaseFeeAccumulated(blockNumber, baseFee, treasuryBalance);

}

Deployment Tracking:

struct DeploymentMetrics {

    uint256 ammLiquidityDeployed;

    uint256 marketMakerIncentivesPaid;

    uint256 infrastructureCosts;

    uint256 proposalDisbursements;

    uint256 reservesAllocated;

}

function recordDeployment(

    DeploymentCategory category,

    uint256 amount

) internal {

    deploymentMetrics[currentPeriod()][category] += amount;

    treasuryBalance -= amount;

    

    emit FundsDeployed(category, amount, treasuryBalance);

}

ROI Calculation:

function calculatePeriodROI(uint256 period) public view returns (int256) {

    uint256 revenue = periodRevenue[period];  // Base fees accumulated

    uint256 costs = periodCosts[period];      // Total deployments

    

    // ROI = (Revenue - Costs) / Costs × 100

    int256 roi = (int256(revenue) - int256(costs)) * 100 / int256(costs);

    

    return roi;

}

Target ROI: Positive (revenue exceeds costs) within 12 months of launch, 20%+ ROI in steady state.

Sustainability Monitoring:

function checkSustainability() public view returns (bool isSustainable) {

    // Calculate 90-day moving average of base fee revenue

    uint256 avgRevenue = calculateMovingAverage(dailyBaseFees, 90);

    

    // Calculate 90-day moving average of deployment costs

    uint256 avgCosts = calculateMovingAverage(dailyCosts, 90);

    

    // Sustainable if revenue covers costs with 20% buffer

    isSustainable = avgRevenue >= (avgCosts * 120 / 100);

    

    // Alert if approaching unsustainability

    if (avgRevenue < (avgCosts * 110 / 100)) {

        emit SustainabilityWarning(avgRevenue, avgCosts);

    }

}

If sustainability check fails for two consecutive quarters, governance must approve cost reductions or suspend non-critical programs.

Proposal Lifecycle Management

Complete workflow from submission to execution with streaming payments:

Stage 1: Proposal Submission (Days 0-7)

function submitFundingProposal(

    ProposalMetadata calldata metadata,

    Milestone[] calldata milestones

) external payable returns (uint256 proposalId) {

    require(msg.value >= PROPOSAL_BOND, "INSUFFICIENT_BOND");

    

    // Validate proposal structure

    require(validateProposal(metadata, milestones), "INVALID_PROPOSAL");

    

    // Store proposal

    proposalId = nextProposalId++;

    proposals[proposalId] = Proposal({

        proposer: msg.sender,

        metadata: metadata,

        milestones: milestones,

        bond: msg.value,

        submittedAt: block.timestamp,

        status: ProposalStatus.Review

    });

    

    emit ProposalSubmitted(proposalId, msg.sender, metadata.fundingAmount);

}

Stage 2: Community Review (Days 7-14)

Community members can comment, request clarifications, or flag concerns. Proposer can modify non-financial parameters based on feedback.

Stage 3: Market Creation (Day 14)

function createProposalMarkets(uint256 proposalId) external {

    Proposal storage proposal = proposals[proposalId];

    require(block.timestamp >= proposal.submittedAt + 14 days, "REVIEW_PERIOD_ACTIVE");

    require(proposal.status == ProposalStatus.Review, "INVALID_STATUS");

    

    // Create PASS and FAIL conditional markets

    (address passMarket, address failMarket) = conditionalMarketFactory.deployMarketPair(

        proposalId,

        address(etc),

        MARKET_LIQUIDITY_AMOUNT,

        calculateOptimalB(MARKET_LIQUIDITY_AMOUNT)

    );

    

    proposal.passMarket = passMarket;

    proposal.failMarket = failMarket;

    proposal.status = ProposalStatus.Trading;

    proposal.tradingEndsAt = block.timestamp + TRADING_PERIOD;

    

    emit MarketsCreated(proposalId, passMarket, failMarket);

}

Stage 4: Prediction Market Trading (Days 14-24)

10-day trading period where participants trade on conditional outcome tokens.

Stage 5: Oracle Resolution (Days 24-29)

Multi-stage oracle resolution per ECIP-1117 determines welfare metric values and market TWAPs.

Stage 6: Approval Decision (Day 29)

function finalizeProposal(uint256 proposalId) external {

    Proposal storage proposal = proposals[proposalId];

    require(proposal.status == ProposalStatus.Resolved, "NOT_RESOLVED");

    

    // Calculate expected welfare improvement

    uint256 passTWAP = calculateTWAP(proposal.passMarket, 72 hours);

    uint256 failTWAP = calculateTWAP(proposal.failMarket, 72 hours);

    

    int256 improvement = (int256(passTWAP) - int256(failTWAP)) * 100 / int256(failTWAP);

    

    if (improvement >= APPROVAL_THRESHOLD) {

        proposal.status = ProposalStatus.Approved;

        proposal.ragequitDeadline = block.timestamp + 7 days;

        emit ProposalApproved(proposalId, improvement);

    } else {

        proposal.status = ProposalStatus.Rejected;

        // Return bond to proposer

        payable(proposal.proposer).transfer(proposal.bond);

        emit ProposalRejected(proposalId, improvement);

    }

}

Stage 7: Ragequit Window (Days 29-36)

7-day period for minority token holders to exit before execution.

Stage 8: Stream Creation and Execution (Day 36+)

function executeApprovedProposal(uint256 proposalId) external {

    Proposal storage proposal = proposals[proposalId];

    require(block.timestamp >= proposal.ragequitDeadline, "RAGEQUIT_ACTIVE");

    require(proposal.status == ProposalStatus.Approved, "NOT_APPROVED");

    

    // Check sanctions compliance per ECIP-1119

    require(!isSanctioned(proposal.metadata.recipient), "RECIPIENT_SANCTIONED");

    

    // Create streaming payment with milestones

    uint256 streamId = createProposalStream(

        proposalId,

        proposal.metadata.recipient,

        proposal.metadata.fundingAmount,

        proposal.metadata.duration,

        proposal.milestones

    );

    

    proposal.status = ProposalStatus.Executing;

    proposal.streamId = streamId;

    

    emit ProposalExecuted(proposalId, streamId);

}

Stage 9: Milestone Progression (Months 1-12+)

Recipients complete milestones, submit proofs, unlock subsequent funding tranches.

Stage 10: Completion or Clawback

Either all milestones complete and stream concludes, or governance claws back remaining funds due to underperformance.

Infrastructure Proposal Templates

Standardized templates for common proposal types:

Oracle Service Provider Template:

{

  "proposalType": "infrastructure",

  "infrastructureCategory": "oracle_service",

  "serviceName": "Sanctions Compliance Oracle",

  "provider": {

    "name": "Provider Legal Entity Name",

    "jurisdiction": "Incorporation jurisdiction",

    "experience": "Years in blockchain oracle services",

    "existingClients": ["Client 1", "Client 2"]

  },

  "technicalSpecification": {

    "dataSources": ["OFAC", "EU", "UN", "FINMA"],

    "updateFrequency": "Every 6 hours",

    "apiArchitecture": "REST API with WebSocket subscriptions",

    "redundancy": "Multi-region deployment with 99.99% uptime SLA"

  },

  "economicTerms": {

    "setupFee": "5000 USD one-time",

    "monthlyBaseFee": "3000 USD",

    "perQueryFee": "0.005 USD",

    "estimatedMonthlyTotal": "5000 USD",

    "paymentCurrency": "ETC equivalent at 30-day TWAP",

    "contractDuration": "12 months"

  },

  "performanceBonds": {

    "upfrontBond": "10000 ETC",

    "uptimeSlashing": "100 ETC per hour downtime beyond SLA",

    "dataQualitySlashing": "5000 ETC per false positive/negative"

  },

  "milestones": [

    {"description": "Integration complete", "daysFromStart": 30, "unlockPercentage": 0},

    {"description": "30-day uptime verification", "daysFromStart": 60, "unlockPercentage": 25},

    {"description": "90-day uptime verification", "daysFromStart": 120, "unlockPercentage": 25},

    {"description": "6-month renewal decision", "daysFromStart": 180, "unlockPercentage": 25},

    {"description": "12-month completion", "daysFromStart": 365, "unlockPercentage": 25}

  ]

}

Gas Subsidy Template:

{

  "proposalType": "infrastructure",

  "infrastructureCategory": "gas_subsidy",

  "subsidyTarget": "zkSNARK Proof Verification",

  "rationale": "Reduce friction for privacy-preserving prediction market participation",

  "technicalDetails": {

    "targetOperations": [

      "Groth16 proof verification (bn128 pairing)",

      "Batch position settlement proofs",

      "MACI key-change message proofs"

    ],

    "estimatedGasPerOperation": 250000,

    "estimatedMonthlyVolume": 2000,

    "totalMonthlyGasCost": "500000000 gas ≈ 0.5 ETC at 1 Gwei"

  },

  "subsidyStructure": {

    "subsidyPercentage": 75,

    "maximumSubsidyPerUser": "0.1 ETC monthly",

    "eligibilityCriteria": "Must participate in at least 3 markets monthly"

  },

  "budgetRequest": {

    "monthlyBudget": "0.75 ETC",

    "quarterlyTotal": "2.25 ETC",

    "duration": "12 months",

    "totalRequest": "9 ETC"

  },

  "performanceMetrics": {

    "targetParticipation": "500 unique addresses using subsidized operations",

    "costPerParticipant": "0.018 ETC",

    "conversionRate": "40% of subsidy users become active traders"

  }

}

Frontend Development Template:

{

  "proposalType": "infrastructure",

  "infrastructureCategory": "frontend_development",

  "projectName": "Futarchy.etc - Prediction Market Trading Interface",

  "teamComposition": {

    "leadDeveloper": "Name, GitHub profile, relevant experience",

    "designers": 2,

    "frontendEngineers": 3,

    "backendEngineers": 1,

    "qaEngineers": 1

  },

  "technicalStack": {

    "frontend": ["React", "TypeScript", "TailwindCSS", "ethers.js"],

    "zkIntegration": ["snarkjs", "circomlib", "Poseidon encryption"],

    "backend": ["Node.js", "GraphQL", "PostgreSQL"],

    "infrastructure": ["Cloudflare", "IPFS", "Vercel"]

  },

  "featureRoadmap": [

    {

      "phase": 1,

      "name": "Core Trading Interface",

      "duration": "3 months",

      "deliverables": [

        "Market discovery and filtering",

        "Position submission and tracking",

        "Real-time price charts with TWAP",

        "Wallet connection (MetaMask, WalletConnect)"

      ]

    },

    {

      "phase": 2,

      "name": "Privacy Features",

      "duration": "3 months",

      "deliverables": [

        "Client-side zkSNARK proof generation",

        "Encrypted position submission",

        "MACI key-change interface",

        "Privacy mode toggle"

      ]

    },

    {

      "phase": 3,

      "name": "Advanced Analytics",

      "duration": "3 months",

      "deliverables": [

        "Historical performance tracking",

        "Portfolio analytics",

        "Market maker leaderboards",

        "Governance participation metrics"

      ]

    },

    {

      "phase": 4,

      "name": "Mobile & PWA",

      "duration": "3 months",

      "deliverables": [

        "Responsive mobile design",

        "Progressive web app",

        "Push notifications",

        "Offline mode"

      ]

    }

  ],

  "budgetBreakdown": {

    "development": "100000 USD (67%)",

    "design": "20000 USD (13%)",

    "infrastructure": "15000 USD (10%)",

    "security": "10000 USD (7%)",

    "contingency": "5000 USD (3%)",

    "total": "150000 USD in ETC equivalent"

  },

  "paymentSchedule": "Streaming with milestone gates",

  "maintenanceCommitment": {

    "duration": "24 months post-delivery",

    "monthlyCost": "5000 USD",

    "scope": "Bug fixes, security updates, dependency upgrades"

  },

  "securityMeasures": {

    "auditPlan": "Professional audit after each phase",

    "bugBounty": "10000 USD allocation",

    "penetrationTesting": "Before mainnet launch"

  },

  "openSourceLicense": "Apache 2.0 with treasury IP rights"

}

These templates provide standardized structure reducing proposal evaluation overhead while ensuring consistent quality and completeness.

Rationale

Why Zero Explicit Fees

Every percentage point of trading fees demonstrably reduces market efficiency. Research on prediction market platforms shows that:

• 0.5% fees reduce trading volume by approximately 15-20%

• 1% fees reduce trading volume by approximately 30-40%

• 2% fees reduce trading volume by approximately 50-60%

For governance decisions, reduced trading volume directly undermines information aggregation—fewer participants means fewer unique information sources, leading to less accurate price discovery and worse governance outcomes.

The base fee flywheel provides sustainable funding without these efficiency costs. Initial treasury capital deployment as AMM liquidity generates trading activity. That trading activity produces base fee revenue exceeding initial deployment costs. Excess revenue funds additional infrastructure improving market quality and attracting more participation. This creates virtuous cycle rather than extractive one.

Why Streaming Payments Over Lump Sum

Lump-sum treasury disbursements create principal-agent problems where recipients receive full funding upfront regardless of delivery quality. Historical DAO data shows approximately 40-60% of funded proposals fail to complete stated deliverables when paid upfront.

Streaming with milestone gates aligns incentives. Recipients have continuous cash flow supporting operations while maintaining accountability pressure. Treasury can course-correct mid-execution by clawing back remaining funds from underperforming projects rather than losing entire allocation. This reduces capital waste and improves expected ROI on treasury deployments.

Sablier protocol provides battle-tested streaming infrastructure handling over $100M in streamed value across thousands of streams. Integration requires minimal custom development while providing robust, audited functionality.

Why Competitive Market Maker Programs

Treasury-only AMM liquidity provides baseline but typically insufficient for deep, liquid markets. Professional market makers bring:

• Larger capital bases enabling deeper order books

• Sophisticated algorithms for tighter spread maintenance

• 24/7 monitoring and rapid response to market movements

• Cross-market hedging reducing capital requirements

Competitive programs with performance-based rewards attract institutional market makers while preventing rent extraction. Base APY covers opportunity cost, performance bonuses reward excellence, and slashing mechanisms discipline poor performance. This creates market dynamics favoring best operators rather than politically-connected incumbents.

Why Multiple Oracle Providers

Single oracle creates centralization risk and single point of failure. If sanctions compliance depends on one provider and that provider becomes compromised, malicious, or simply unreliable, entire governance system becomes vulnerable.

Competitive oracle marketplace with multiple providers creates redundancy and market discipline. Providers compete on data quality, uptime, and cost. Poor performers get rotated out through quarterly reviews. Multi-oracle consensus (e.g., 2-of-3 agreement) prevents single-provider manipulation while maintaining operational reliability.

Why These Specific Parameters

1,000 ETC AMM liquidity per market: Provides approximately $15,000 USD depth at $15/ETC. Comparable to successful MetaDAO markets but scaled for ETC market capitalization. Sufficient for meaningful trading without excessive treasury exposure.

5,000 ETC minimum market maker capital: Creates meaningful barrier to entry preventing spam applications while remaining accessible to qualified institutional participants. At $15/ETC, this is $75,000 USD—typical minimum for professional market making operations.

5% base APY + 5% bonus potential: Base rate covers opportunity cost of deployed capital (approximately equal to staking yields on major chains). Bonuses reward exceptional performance without creating excessive treasury burden. Total 10% maximum aligns with competitive DeFi yield opportunities.

50 ETC proposal bond: Creates economic cost preventing spam proposals ($750 USD at $15/ETC) while remaining accessible to serious projects. Bond returned for legitimate proposals regardless of approval outcome, forfeited only for bad-faith submissions.

Quarterly program cycles: Long enough for meaningful evaluation of market maker performance, short enough for responsive reallocation. Matches typical financial reporting periods enabling integration with treasury accounting.

Backwards Compatibility

This ECIP supersedes ECIP-1114 which defined an earlier funding proposal framework for Olympia DAO. Migration strategy:

Phase 1: Deploy ECIP-1118 contracts alongside existing ECIP-1114 infrastructure. Existing approved proposals continue under old system while new proposals use ECIP-1118.

Phase 2: Migrate active ECIP-1114 proposals to streaming payment contracts. Work with recipients to define milestone equivalents for remaining deliverables.

Phase 3: Deprecate ECIP-1114 contracts once all historical proposals complete. Redirect all treasury disbursements through ECIP-1118 streaming infrastructure.

Compatibility Considerations:

• ECIP-1112 treasury vault interface unchanged—ECIP-1118 simply calls existing withdrawal functions with streaming recipient

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

• ECIP-1117 futarchy governance can approve proposals under either framework during transition

No consensus changes required—all streaming payment logic operates at smart contract layer.

Security Considerations

Attack Vectors

Market Maker Exploitation: Malicious market makers could attempt to extract maximum incentives while providing minimal actual liquidity.

Mitigation: Continuous performance monitoring with automated slashing. Real-time spread tracking, volume verification, and uptime measurement prevent gaming. Progressive penalties escalate from warning to slashing to permanent ban for repeated violations.

Oracle Manipulation: Corrupt oracle providers could falsely report sanctions status to block legitimate withdrawals or approve sanctioned recipients.

Mitigation: Multi-oracle consensus with stake-weighted voting. Fraud proofs enable challenge of incorrect data with bond forfeiture for proven manipulation. Regular oracle rotation through competitive bidding prevents capture.

Streaming Payment Griefing: Recipients could game milestone verification to unlock funds without actual completion.

Mitigation: Multiple verification methods (on-chain metrics, oracle attestation, multi-signature approval) tailored to milestone type. Community oversight through public milestone tracking. Governance clawback authority for demonstrated fraud.

Treasury Depletion: Excessive or fraudulent proposals could drain treasury faster than base fees replenish.

Mitigation: Per-proposal and daily spending limits. Sustainability monitoring with automatic program suspension if costs exceed revenue. Strategic reserves maintained in stablecoins for operational continuity during market downturns.

Fee Flywheel Breakdown: If base fee revenue fails to cover infrastructure costs, system becomes unsustainable.

Mitigation: Conservative initial parameters starting with high capital efficiency. Automatic cost reductions if sustainability metrics deteriorate. Emergency funding mechanisms through governance-approved one-time treasury deployments.

Smart Contract Risks

Streaming Contract Bugs: Vulnerabilities in Sablier integration could enable fund theft or incorrect disbursements.

Mitigation: Use audited Sablier v2 contracts without modifications. Additional security audit specifically for integration points. Emergency pause capability in case of exploit discovery.

AMM Manipulation: Adversarial trading attempting to drain treasury-provided liquidity.

Mitigation: LMSR bounded-loss design guarantees maximum 10% loss per market. After trading period, liquidity withdrawn before manipulation possible. Price manipulation doesn’t affect treasury beyond bounded loss and doesn’t impact governance decisions (TWAPs calculated over extended periods).

Reentrancy Attacks: Complex interaction between streaming, milestones, and treasury could enable reentrancy.

Mitigation: Strict checks-effects-interactions pattern throughout. OpenZeppelin ReentrancyGuard on all external-calling functions. Comprehensive reentrancy testing in audit.

Upgrade Risks: Malicious upgrades could steal treasury funds or manipulate parameters.

Mitigation: All upgrades require futarchy governance approval. Multi-signature timelock prevents immediate exploitation. Progressive decentralization reduces upgrade authority over time.

Implementation

Reference Implementation

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

Core contracts:

• TreasuryManager.sol: Capital allocation and accounting

• StreamingPayments.sol: Sablier integration for proposal disbursements

• MarketMakerRegistry.sol: Competitive MM program management

• InfrastructureFunding.sol: Oracle and gas subsidy programs

• FeeFlywheelAccounting.sol: Base fee tracking and ROI calculation

Deployment Plan

Mordor Testnet:

• Block: TBD (coordinate with ECIP-1116, 1117)

• Duration: 3 months minimum

• Test scenarios:

  • AMM liquidity deployment and recovery

  • Streaming payment milestone progression

  • Market maker competition and slashing

  • Fee flywheel sustainability under varying transaction volumes

  • Clawback mechanisms for underperforming proposals

Mainnet:

• Block: TBD (post-Mordor validation)

• Initial parameters: Conservative settings (higher bonds, lower spending limits)

• Progressive scaling: Increase deployment amounts as base fee revenue demonstrates sustainability

Audit Requirements

Pre-deployment:

• Two independent professional security audits

• Formal verification of critical invariants:

  • Treasury balance monotonically non-decreasing except authorized withdrawals

  • Streaming payment amounts never exceed approved totals

  • Market maker slashing cannot exceed bonded amounts

  • Fee accounting accurate within rounding errors

• Economic modeling verification:

  • Fee flywheel reaches profitability under realistic transaction volume scenarios

  • AMM bounded loss guarantees hold under adversarial trading

  • Sustainability metrics trigger appropriately

Post-deployment:

• Bug bounty program (minimum 100,000 USD equivalent)

• Quarterly security reviews

• Continuous monitoring for anomalous behavior

Monitoring Dashboard

Real-time public dashboard tracking:

• Treasury balance and capital allocation breakdown

• Base fee accumulation rate (daily/monthly trends)

• AMM liquidity deployment and P&L by market

• Market maker performance scores and incentive payments

• Streaming payment status and milestone completion

• Infrastructure provider uptime and data quality

• Fee flywheel ROI and sustainability metrics

• Quarterly financial reports

Copyright

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

References

1. Sablier (2024), “Sablier v2 Protocol Documentation”, https://docs.sablier.com

2. Superfluid (2024), “Money Streaming Protocol”, https://docs.superfluid.finance

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

4. Hanson, Robin (2003), “Combinatorial Information Market Design”, Information Systems Frontiers

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

6. MetaDAO (2024), “18 Months of Futarchy: Lessons Learned”, https://metadao.fi/research

7. Chen, Yiling & Pennock, David (2007), “A Utility Framework for Bounded-Loss Market Makers”, UAI

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

9. ECIP-1111 (2024), “Olympia EVM and Protocol Upgrades”

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

11. ECIP-1116 (2024), “Base Fee Development Investment Protocol”

12. ECIP-1117 (2024), “Futarchy DAO Governance”

13. ECIP-1119 (2024), “International Sanctions Compliance Filter”

14. Moloch DAO (2019), “Minimum Viable DAO”, https://github.com/MolochVentures/moloch

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