ECIP 1114: Ethereum Classic Funding Proposal Process

Simple Summary

This ECIP defines the Ethereum Classic Funding Proposal (ECFP) process: a standardized, permissionless mechanism for submitting and executing funding requests from the Olympia Treasury, governed by the Olympia DAO. The ECFP format provides a reproducible structure for transparent and accountable allocation of protocol-level funds. It enables developers, infrastructure operators, researchers, and ecosystem contributors to submit auditable proposals for on-chain funding. By formalizing a reproducible structure for submission, voting, and disbursement, this process ensures treasury allocations are accountable, equitable, and aligned with Ethereum Classic’s principles of decentralization and sustainability.

Abstract

This ECIP formalizes the Ethereum Classic Funding Proposal (ECFP) process as the standard submission, voting, and execution mechanism for allocating funds from the Olympia Treasury. The ECFP mechanism provides a transparent, reproducible pathway for protocol-level funding, enabling contributors to propose work that aligns with the network’s values and strategic priorities.

Each ECFP includes a clearly scoped problem statement, deliverables, funding amount, recipient(s), disbursement schedule, and success criteria. Proposals undergo community discussion, on-chain voting, and time-locked execution upon approval.

By standardizing submission and governance workflows, the ECFP format ensures fair, accountable, and sustainable allocation of treasury funds toward core development, infrastructure, and ecosystem growth. Execution of approved proposals MAY involve administrative or fiat-handling support via the Ethereum Classic DAO LLC, which operates under on-chain instructions without discretionary authority.

Motivation

Historically, Ethereum Classic has lacked a structured, transparent process for funding public goods such as client maintenance, infrastructure, documentation, security audits, and educational resources. Funding decisions were often made off-chain by centralized entities, leading to inconsistent support, limited accountability, and community mistrust.

With the activation of the Olympia Treasury (ECIP-1112) and the governance system established by the Olympia DAO (ECIP-1113), Ethereum Classic now has a decentralized, protocol-native funding source. To ensure its effectiveness, a standardized, auditable framework is required for submitting, evaluating, and executing funding proposals.

The Ethereum Classic Funding Proposal (ECFP) process addresses this need by:

• Defining a transparent proposal lifecycle — from submission to voting to execution.
• Supporting open participation — any contributor MAY submit proposals, regardless of affiliation.
• Improving accountability — all proposal data and voting outcomes are recorded on-chain.
• Streamlining governance — standardized formats reduce review complexity and decision fatigue.
• Preserving institutional knowledge — all proposals, regardless of outcome, remain publicly archived on-chain and in content-addressed storage for long-term accessibility.

Modeled after the ECIP process, the ECFP framework brings transparent, rules-based treasury funding to Ethereum Classic for the first time in its history.

Specification

The Ethereum Classic Funding Proposal (ECFP) process defines a standardized, on-chain lifecycle for submitting, reviewing, voting on, and executing protocol-level funding proposals. The process is enforced through Olympia DAO governance (ECIP-1113) and is transparent, reproducible, and recorded immutably on-chain.

ECFP Lifecycle

1. Proposal Submission

   • Any Ethereum Classic address MAY submit an ECFP via the Olympia DAO interface.
   • Each proposal MUST include:
     • Title and ECFP number (assigned sequentially)
     • Author(s) and contact information
     • Requested funding amount (in ETC)
     • Recipient address
     • Purpose, scope of work, and intended impact
     • Disbursement schedule (e.g., milestone-based, vesting, or lump sum)
     • Deliverables and key performance indicators (KPIs)
     • Off-chain metadata pointer (e.g., IPFS or Arweave link)

2. Proposal Statuses

   All proposals MUST follow these standardized statuses:

   • Draft: Submitted and open for discussion; not yet eligible for voting.
   • Active: Undergoing governance voting.
   • Approved: Passed voting thresholds; scheduled for execution.
   • Rejected: Failed quorum or approval threshold.
   • Executed: Disbursement completed via Treasury contract.
   • Expired: Automatically marked if a proposal fails to initiate a vote within a DAO-defined validity window (e.g., 30 days).

3. Voting and Quorum

   • Voting is conducted on-chain using token-weighted or delegated stake models.
   • Each proposal MUST meet a configurable quorum (e.g., 5%) and approval threshold (e.g., ≥60% “Yes” votes).
   • Voting delay and duration parameters SHALL be defined by DAO configuration.

4. Execution and Disbursement

   • Upon approval, the DAO contract SHALL trigger the Treasury’s release() or execute() method.
   • Disbursements MAY be immediate, time-locked, or milestone-based.
   • Execution MUST emit a ProposalExecuted event with relevant metadata (e.g., ECFP ID, recipient, amount, timestamp).

   The following call pattern MUST be used to enforce DAO-only execution and maintain proposal-auditing integrity:

   // On-chain: DAO execution of approved ECFP via Treasury
   // MUST be called only by authorized governance executor
   function executeECFP(
      uint256 ecfpId,
      bytes32 proposalHash,
      address recipient,
      uint256 amount
   ) external {
      require(isApproved(ecfpId), "ECFP not approved"); // Governance approval check
      OlympiaTreasury(treasuryAddress).release(proposalHash, recipient, amount); // Funds released
   }
   

5. Amendments and Withdrawals

   • Proposals MAY be modified or withdrawn while in Draft status.
   • Once in Active, proposals are immutable and subject only to voting outcome.

6. Transparency and Indexing

   • All proposal data and status changes MUST be recorded on-chain.
   • A public explorer MAY track proposal history, funding flow, and results.

Spam and Governance Capture Mitigations

To maintain resilience and openness, the following mitigations MAY be enforced by Olympia DAO:

• Participation Thresholds
  Submission MAY require:
  • Token staking or deposit (refundable if quorum met)
  • Minimal ETC or governance token holding
• Submission Cooldowns
  • Rate limits MAY be applied to deter flooding or proposal spamming.
• Draft Review Periods
  • Proposals MUST reside in Draft state before activation to allow community feedback.
• Structured Format Requirements
  • All ECFPs MUST conform to a standardized template and embed a verifiable content hash (e.g., IPFS CID, Arweave digest) to ensure metadata immutability and auditability.
• Voting Model Upgradeability
  • The DAO MAY upgrade the voting system through governance, including adopting non-token-based models such as quadratic voting, identity-verified voting, or soulbound token schemes. These upgrades MUST follow the standard ECFP governance path.

Governance Scope

• The ECFP process is the exclusive mechanism for all Olympia Treasury disbursements, including:
  • Core protocol development
  • Emergency funding
  • Recurring or operational budgets
  • Multi-phase or milestone-based grants

• The DAO MAY define proposal subtypes (e.g., Operational ECFPs, Treasury Management ECFPs) with custom eligibility and workflows.

• No treasury funds MAY be allocated outside the ECFP process.

Additional safeguards MAY include:

• Supermajority thresholds for sensitive funding categories
• Co-signing requirements for large disbursements
• Staggered execution timelines for governance oversight

Legal Interface: Ethereum Classic DAO LLC

To facilitate fiat disbursements and administrative compliance, an external legal interface is provided through the Ethereum Classic DAO LLC — a Wyoming-registered entity operating under the Wyoming DAO LLC Act.

• The Ethereum Classic DAO LLC SHALL operate as a non-discretionary executor of approved proposals. It SHALL perform no evaluative, filtering, or discretionary role, and SHALL be fully subordinate to the on-chain governance outcome.
• It SHALL publish periodic public reports, including:
  • Donation receipts
  • Contractor onboarding logs
  • Administrative cost summaries
  • Fiat conversion reports
• The LLC MUST NOT:
  • Hold treasury private keys
  • Modify or veto approved proposals
  • Combine protocol and donor funds

DAO tokenholders MAY reassign LLC roles or rotate signers via term-limited elections defined by DAO vote.

Donation Handling and Segregation

• Off-chain donations MAY be accepted but MUST be:
  • Tracked separately from treasury funds
  • Disbursed only via DAO-approved proposals
  • Included in public reports
• Use of donor funds outside the ECFP process MUST be:
  • Optional
  • Transparent
  • Subject to community oversight

Informative Note: As a best practice, the DAO MAY define a “Donation ECFP” format, enabling donors to align earmarked contributions with specific proposals. All such disbursements MUST pass through the standard governance process.

Rationale

Minimal, Scalable, and Governance-Neutral

The Ethereum Classic Funding Proposal (ECFP) framework provides a minimal but robust set of rules to ensure transparency, accountability, and long-term viability:

• Proposals can range from one-time payments to milestone-based or recurring grants.
• The system imposes no minimum activity requirements — it remains valid even if only one ECFP is approved annually.
• The format scales naturally with network growth and does not require frequent modification.

By codifying a simple but extensible framework, ETC avoids the need for discretionary funding from private foundations or ad hoc grants.

Governance-Aligned Funding Infrastructure

The ECFP process formalizes a community-controlled mechanism for allocating protocol-level funds from the Olympia Treasury (ECIP-1112) under the governance of Olympia DAO (ECIP-1113). It ensures that public goods funding is:

• Transparent — All proposals, votes, and disbursements are recorded immutably on-chain.
• Inclusive — Any contributor MAY submit a proposal without requiring prior affiliation or political capital.
• Predictable — Proposal structure and lifecycle are standardized, reducing ambiguity for both proposers and voters.
• Upgradeable — The process is governance-agnostic and supports modular upgrades to DAO architecture, voting logic, and funding workflows.

Key Design Objectives

• Clarity and Accountability
  Structured templates, defined execution paths, and required deliverables ensure proposal intent and outcomes are clearly documented and enforceable.

• Transparency and Auditability
  All actions — from proposal submission to treasury execution — are verifiable on-chain and available for public inspection.

• Openness and Meritocracy
  Anyone MAY participate. Access is not gated by token holdings, off-chain influence, or pre-approval.

• Governance Modularity
  The ECFP format is defined independently of DAO implementation. Changes to governance architecture do not affect the funding process itself.

• Alignment with ETC Principles
  The process reflects Ethereum Classic’s core tenets: immutability, decentralization, and resistance to centralized capture. It replaces opaque, foundation-driven funding with a permissionless, rule-based mechanism.

Ecosystem Context

The ECFP process places Ethereum Classic on par with DAO-based funding systems used by other leading chains:

• Arbitrum (AIP Framework) — On-chain proposals for treasury disbursement to ecosystem contributors.
• Optimism (RPGF) — Retroactive funding for high-impact public goods.
• Celo Community Fund — DAO-managed grants with milestone oversight.

This ECIP ensures Ethereum Classic adopts a modern, decentralized approach to development funding — one that is principled, reproducible, and built to endure.

Implementation

The Ethereum Classic Funding Proposal (ECFP) process SHALL be implemented as an integral component of the Olympia DAO governance framework (see ECIP-1113), which interfaces directly with the Olympia Treasury contract (ECIP-1112). The process combines on-chain governance mechanisms with standardized proposal formats and off-chain deliberation infrastructure.

1. Proposal Submission

• A dedicated submission portal SHALL be provided at: https://github.com/ethereumclassic/ECFPs.
• Each ECFP MUST include:
  • Sequential ECFP number
  • Title and rationale
  • Requested funding amount (denominated in ETC)
  • Recipient address
  • Milestone schedule or disbursement model
  • Off-chain metadata pointer (e.g., IPFS CID or Arweave URL)
• Metadata MUST be:
  • Stored in a content-addressed format
  • Immutable and auditable
  • Referenced in the on-chain proposal via hash or URL
• Proposals SHOULD follow the official ECFP Markdown template.
• Proposals MAY include links to GitHub repositories, mockups, prototypes, or community endorsements.

Proposal metadata MUST be hashed and linked to content-addressed storage (e.g., IPFS or Arweave) using the following structure:

// On-chain: Store metadata CID and verify hash
function submitECFP(
    uint256 ecfpId,
    address recipient,
    uint256 amount,
    string calldata metadataCID
) external {
    bytes32 hash = keccak256(
        abi.encodePacked(ecfpId, recipient, amount, metadataCID, block.chainid)
    );
    proposals[ecfpId] = Proposal({
        id: ecfpId,
        recipient: recipient,
        amount: amount,
        metadataCID: metadataCID,
        hash: hash
    });
    emit ProposalSubmitted(ecfpId, recipient, amount, metadataCID, hash);
}

2. On-Chain Registry and Governance

• The Olympia DAO smart contracts SHALL include a registry recording:
  • Submission timestamp
  • Proposer address
  • Voting results
  • Final status (Approved, Rejected, Executed, etc.)
• Governance contracts MUST:
  • Enforce voting delays, voting periods, and quorum thresholds
  • Capture voter snapshot state at the proposal block height

3. Execution and Disbursement

• Upon successful approval, the DAO contract SHALL trigger fund release by calling release() or execute() on the Olympia Treasury contract.
• Disbursement MAY follow one of the following formats:
  • One-time transfer
  • Scheduled vesting based on milestones
  • Programmatic stream via escrow or disbursal contract
• Execution MUST emit a ProposalExecuted event, containing:
  • ECFP ID
  • Recipient address
  • Amount disbursed
  • Block number and timestamp
  • Proposal hash reference
• Treasury contract logic (per ECIP-1112) SHALL enforce that only authorized DAO proposals trigger disbursement.
• Each transaction MUST include the relevant ECFP ID and metadata hash to ensure auditability.

// Off-chain: Generate ECFP proposal hash for on-chain binding
bytes32 proposalHash = keccak256(
    abi.encodePacked(
        ecfpId,        // Unique proposal ID (e.g., 0042)
        recipient,     // Destination address
        amount,        // Funding amount in wei
        metadataCID,   // Content hash from IPFS or Arweave
        block.chainid  // Replay protection domain separator
    )
);

All disbursements MUST emit a standardized ProposalExecuted event for transparency, analytics, and auditability.

4. Transparency Dashboard

• A public-facing dashboard SHALL track:
  • Active, approved, and executed proposals
  • DAO voting outcomes and participation metrics
  • Treasury balance and disbursement history
• The dashboard MUST be open-source and verifiably mirror on-chain state.

5. Community Review and Deliberation

• Proposals SHOULD undergo informal discussion prior to on-chain activation.
• Review MAY occur on platforms such as:
  • ECIP discussion forums
  • Ethereum Classic Discord
  • Other approved governance platforms
• Community moderators MAY assist with formatting or technical reviews but SHALL NOT have authority to approve, veto, or gate proposals.

Testing and Mainnet Rollout

• All governance and treasury contracts SHALL be tested on the Mordor Testnet prior to mainnet deployment.
• Final deployment SHALL follow successful testnet simulation, community validation, and third-party audits.

Backwards Compatibility

The Ethereum Classic Funding Proposal (ECFP) process is implemented entirely at the application layer via smart contracts. It introduces no changes to consensus rules, transaction formats, opcode behavior, or virtual machine semantics. Accordingly, the ECFP framework is fully backward-compatible with all existing contracts, wallets, clients, and tooling.

Compatibility Notes:

• No Protocol Changes:
  The ECFP process does not alter the core protocol. Consensus logic, transaction verification, and block structure remain unchanged.

• Voluntary Participation:
  Interaction with ECFP governance is opt-in. Users, developers, and miners are not required to engage unless submitting or voting on proposals.

• Application-Layer Isolation:
  Legacy smart contracts and decentralized applications (dApps) will continue to function without modification. The ECFP system operates independently of unrelated contracts.

• Client Compatibility:
  Nodes that implement ECIP-1111 through ECIP-1114 will remain in consensus. Clients that do not support these ECIPs will fork from the canonical chain.

• Treasury Execution Requirements:
  To process disbursements, clients MUST support the deployed Olympia Treasury (ECIP-1112) and Olympia DAO (ECIP-1113) contracts. These contracts are required to validate ECFP-based execution flows.

• State and Data Integrity:
  Because the system is fully encapsulated within verified smart contracts, the ECFP process introduces no risk to prior blockchain state or application-level data.

This separation between governance-layer logic and protocol consensus ensures that the ECFP framework integrates cleanly with the Ethereum Classic stack while preserving stability and security.

Security Considerations

While ECIP-1114 introduces no changes to Ethereum Classic’s consensus or EVM behavior, it defines a critical application-layer funding mechanism that MUST be secure, auditable, and resilient. The following categories outline key security properties and safeguards.

1. Metadata and Proposal Integrity

This example proposal hash serves as the unique identifier for execution. It links the on-chain disbursement to an immutable, off-chain metadata record stored on IPFS or Arweave. This guards against tampering and ensures verifiability of funding intent and deliverables.

// Off-chain: Generate ECFP proposal hash for on-chain binding
bytes32 proposalHash = keccak256(
    abi.encodePacked(
        ecfpId,        // Unique proposal ID (e.g., 0042)
        recipient,     // Destination address
        amount,        // Funding amount in wei
        metadataCID,   // Content hash from IPFS or Arweave
        block.chainid  // Replay protection domain
    )
);

• Content-Addressed Metadata:
  Every ECFP MUST embed a content hash (e.g., IPFS CID or Arweave digest) in its on-chain metadata to ensure tamper resistance.

• Immutable References:
  Off-chain proposal documents MUST be stored immutably in a content-addressable format. Voters MUST be assured that proposal content cannot be altered post-submission.

• Proposal Uniqueness:
  Each ECFP MUST use a globally unique ID to prevent collisions, duplication, or unauthorized replay.

• Replay Protection:
  All proposals MUST include a chain ID and domain separator to mitigate replay attacks across testnets or forks.

2. Treasury and DAO Contract Safeguards

• Isolation of Execution Logic:
  The Treasury contract SHALL NOT interpret proposal data. It only executes pre-approved calls (release() or execute()) from the authorized DAO executor.

• Strict Call Permissions:
  The Treasury MUST reject all unauthorized callers, including EOAs or contracts not whitelisted by DAO governance.

• No Arbitrary Logic:
  ECFP execution paths MUST follow deterministic disbursement logic as defined in ECIP-1112. Custom execution or fallback paths are prohibited.

• Immutable Lifecycle States:
  Once an ECFP enters Active state (under vote), it becomes immutable. No edits or withdrawals are permitted.

• Redundant Event Logging:
  Both DAO and Treasury contracts SHOULD emit standard events (e.g., ProposalExecuted) for independent indexing and traceability.

3. Governance Process Risks

• Governance Capture:
  Plutocratic dominance is mitigated through:
  • Quorum requirements
  • Delegated and/or reputation-based voting (future upgrade paths)
  • Configurable thresholds subject to DAO governance

• Replay Defense:
  Governance payloads MUST include domain separation and unique identifiers to prevent replay on forks or test environments.

• Safe Governance Upgrades:
  All DAO upgrades MUST follow:
  • On-chain proposal and approval
  • Audited and timelocked deployment
  • Sufficient quorum and delay before activation

4. Execution and Client Consistency Risks

• Client Validation:
  Clients MUST verify that disbursements match DAO-approved instructions. Discrepancies risk consensus divergence or fund misallocation.

• Reentrancy and Logic Audit:
  DAO and Treasury contracts MUST undergo formal verification and third-party audits to eliminate reentrancy bugs and unexpected control flows.

• Proposal Manipulation:
  Deceptive or ambiguous proposals are mitigated via:
  • Required structured templates
  • Mandatory review periods
  • Metadata hash enforcement
• Funding Accountability:
  Proposals SHOULD adopt milestone-based disbursement, vesting schedules, and clawback clauses to prevent misuse of funds.

5. Spam Resistance and Participation Gating

• Sybil Attack Mitigation:
  The DAO MAY implement participation safeguards, such as:
  • Minimum stake or token holdings
  • Submission cooldown intervals
  • Contributor identity attestation or whitelisting
• These gates MUST preserve permissionless access and be subject to governance review.

Summary

ECIP-1114 defines a secure, transparent, and upgradeable framework for treasury governance. Security best practices include:

• Immutable, verifiable proposal metadata
• Restricted and audited execution paths
• Formal quorum and upgrade thresholds
• Open yet protected proposal submission

The full system MUST be tested on Mordor Testnet, reviewed through public audits, and verified for correctness prior to mainnet deployment.

Related ECIPs in the Olympia Upgrade

• ECIP-1111: Olympia EVM and Protocol Upgrades
• ECIP-1112: Olympia Treasury Contract
• ECIP-1113: Olympia DAO Governance Framework
• ECIP-1114: Ethereum Classic Funding Proposal Process

Copyright

Copyright and related rights waived via
CC0

Appendix: EVM Precedents for Treasury Governance

Several EVM-compatible networks have successfully implemented DAO-based treasury funding mechanisms. These examples validate the viability, scalability, and security of the ECFP model adopted in ECIP-1114:

These precedents support the security and feasibility of the Ethereum Classic Funding Proposal (ECFP) system. ECIP-1114 builds on their lessons while tailoring the process to Ethereum Classic’s values of decentralization, transparency, and immutability.