ECIP 1114: Ethereum Classic Funding Proposal Process

Simple Summary

This ECIP defines the Ethereum Classic Funding Proposal (ECFP) process — the exclusive, standardized, and permissionless mechanism for requesting and executing funding from the Olympia Treasury (ECIP-1112).
The ECFP process is enforced by the Olympia DAO (ECIP-1113), enforced by the Olympia DAO (ECIP-1113) through its governance-authorized execution contract for treasury disbursements, and governs the allocation of BASEFEE revenue redirected under ECIP-1111.

It provides a reproducible, transparent structure for:

• Submission — Any participant may submit proposals without prior permission.
• Voting — All proposals undergo on-chain governance review.
• Disbursement — Approved proposals are executed via hash-bound treasury releases.

This process ensures that protocol-level funds are accountable, equitable, and aligned with Ethereum Classic’s principles of decentralization, immutability, and sustainability.

Abstract

This ECIP formalizes the Ethereum Classic Funding Proposal (ECFP) process — the standardized, permissionless, and exclusive mechanism for submitting, voting on, and executing funding requests from the Olympia Treasury (ECIP-1112).
The Treasury is funded by the BASEFEE revenue redirected at the consensus layer under ECIP-1111 and is governed exclusively by the Olympia DAO (ECIP-1113).

The ECFP process provides a transparent, reproducible pathway for allocating protocol-level funds toward core development, infrastructure, and ecosystem growth. Each proposal MUST include:

• Problem statement and rationale
• Scope of work and deliverables
• Requested funding amount (in ETC)
• Recipient(s) and disbursement schedule (milestone-based, vesting, or lump sum)
• Success criteria and key performance indicators (KPIs)
• Immutable off-chain metadata (IPFS/Arweave) hash-bound to the execution payload

Proposals undergo public discussion, on-chain voting, and time-locked execution upon approval.
Execution of approved proposals MAY involve administrative or fiat-handling support by the Ethereum Classic DAO LLC, which operates solely under binding on-chain instructions and holds no discretionary authority.

Motivation

For most of its history, Ethereum Classic has depended on centralized foundations, corporate sponsors, and private donors to fund protocol development. These arrangements were often opaque, lacked formal community oversight, and exposed the network to:

• Gatekeeping by a small set of decision-makers
• Funding inconsistency due to donor withdrawals or organizational collapse
• Strategic misalignment between funders and the broader ETC community

As a result, critical public goods — including client maintenance, consensus upgrades, public RPC infrastructure, security audits, documentation, and educational resources — were funded ad hoc, leading to inconsistent support, limited accountability, and long-term fragility.

With the activation of:

• Olympia EVM and Protocol Upgrades (ECIP-1111) — redirecting BASEFEE to a protocol-level funding stream
• Olympia Treasury (ECIP-1112) — an immutable, governance-isolated vault for that revenue
• Olympia DAO (ECIP-1113) — the sole authorized executor of treasury disbursements

…Ethereum Classic now has a decentralized, non-inflationary, protocol-native funding source.
The final requirement is a standardized, auditable process for submitting, reviewing, voting on, and executing funding proposals — ensuring that every treasury allocation is transparent, rule-based, and resistant to capture.

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

• Defining a transparent proposal lifecycle — from submission to voting to time-locked execution
• Requiring hash-bound disbursement — binding every payout to immutable proposal metadata for replay protection
• Supporting open participation — any contributor MAY submit proposals, regardless of affiliation
• Improving accountability — all proposals, votes, and disbursements are recorded on-chain and auditable
• Streamlining governance — standardized formats reduce review complexity and decision fatigue
• Preserving institutional knowledge — all proposals remain archived on-chain and in content-addressed storage, regardless of outcome

Modeled after the ECIP process, the ECFP framework replaces opaque, discretionary funding with transparent, rules-based treasury governance — bringing accountable, permissionless public goods funding to Ethereum Classic for the first time in its history.

Specification

The Ethereum Classic Funding Proposal (ECFP) process defines the exclusive, standardized, and permissionless on-chain lifecycle for submitting, reviewing, voting on, and executing protocol-level funding proposals.
It governs the allocation of BASEFEE revenue redirected under ECIP-1111 into the immutable Olympia Treasury (ECIP-1112), and is enforced solely by the Olympia DAO (ECIP-1113).

The ECFP process is:

• Transparent — All proposals, votes, and disbursements are recorded immutably on-chain.
• Reproducible — The same submission and execution rules apply to all participants.
• Hash-bound — Every disbursement is cryptographically bound to immutable proposal metadata (ecfpId, recipient, amount, metadataCID, chainid) for integrity and replay protection.

Only successful DAO proposals that meet quorum, threshold, and timelock requirements MAY trigger Treasury disbursement.
Execution is performed via the DAO’s authorized executor calling the Treasury’s release() or execute() function with matching hash parameters, as defined in ECIP-1112.

ECFP Lifecycle

1. Proposal Submission

   • Any Ethereum Classic address MAY submit an ECFP via the Olympia DAO interface.
   • Proposal submission is permissionless. Optional Sybil-resistance modules (e.g., BrightID, Gitcoin Passport, Proof of Humanity) MAY be adopted by DAO vote to verify unique participants.
   • 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), hash-bound to execution parameters (ecfpId, recipient, amount, metadataCID, chainid) as defined in ECIP-1112

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 the Olympia Treasury.
   • 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

   • All ECFPs SHALL follow the Olympia DAO governance process defined in ECIP-1113.
   • At launch, Olympia DAO operates without a governance token, using a one-address-one-vote model to maximize openness and participation.
     • This model is vulnerable to Sybil attacks; mitigation strategies (e.g., identity attestations, delegated voting, or reputation systems) MAY be proposed and adopted via future governance upgrades.
   • The DAO MAY, by on-chain proposal and approval, upgrade to other voting models — including stake-based, delegated stake, quadratic, or hybrid systems — without modifying this ECIP.
   • A minimum quorum MUST be enforced for any proposal to be valid.
   • A configurable approval threshold (e.g., ≥60% “yes” votes) MUST be met for a proposal to pass.
   • Voting delay and voting period parameters SHALL be defined by DAO configuration and MAY be modified through the standard governance process.
   • All voting records, tallies, and results MUST be recorded on-chain and be publicly auditable.

4. Execution and Disbursement

   • Upon approval, the DAO’s sole authorized executor SHALL trigger the Treasury’s release() or execute() method.
   • Disbursements MAY be immediate, time-locked, or milestone-based.
   • Treasury disbursements SHALL use deterministic proposal hashes for release validation, computed from (ecfpId, recipient, amount, metadataCID, chainid) per ECIP-1112.
   • Execution MUST emit a ProposalExecuted event with relevant metadata (e.g., ECFP ID, proposal hash, recipient, amount, timestamp).

   // 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; any substantive change requires submitting a new proposal.

6. Transparency and Indexing

   • All proposal data, state changes, and execution events MUST be recorded on-chain.
   • The DAO and Treasury contracts SHOULD emit standardized events (ProposalSubmitted, ProposalExecuted, etc.) for indexing and public transparency.
   • A public explorer MAY track proposal history, funding flow, and results.

Spam, Sybil, and Governance Capture Mitigations

To maintain resilience, openness, and resistance to manipulation, the following mitigations MAY be adopted by the Olympia DAO (ECIP-1113) via on-chain governance proposal.
All such measures MUST preserve the permissionless nature of the ECFP process.

• Participation Thresholds
  Submission MAY require:
  • Token staking or a refundable ETC deposit (e.g., returned if quorum is met)
  • Minimal ETC or governance token holding
  • Optional integration with Sybil-resistance systems such as BrightID, Gitcoin Passport, or Proof of Humanity.
    These integrations are permissionless, modular, and opt-in — enabling proposal authors or sub-DAOs to define eligibility rules based on external identity attestations.
• Submission Cooldowns
  • Rate limits MAY be applied to deter flooding or malicious proposal spamming.
• Draft Review Periods
  • Proposals MUST remain in Draft status for a minimum review period before activation, allowing for community feedback and informal discussion.
• Structured Format Requirements
  • All ECFPs MUST conform to the standardized ECFP template and embed a verifiable content hash (e.g., IPFS CID, Arweave digest) to ensure metadata immutability and auditability.
  • The embedded content hash MUST match the value used in the hash-bound disbursement model of ECIP-1112, ensuring that the metadata referenced during voting and execution is identical and immutable.

Voting Model Upgradeability

• At launch, the Olympia DAO operates without a governance token, using a one-address-one-vote model as defined in ECIP-1113.
• The DAO MAY, through an on-chain governance proposal, upgrade to alternative voting systems — including token-based (e.g., stake-weighted or delegated stake), quadratic, identity-verified, soulbound token, or hybrid models.
• Any such change:
  • MUST be proposed and approved via the standard ECFP governance process
  • MUST adhere to quorum, approval threshold, and timelock requirements
  • MUST follow the no premine or privileged allocation principle defined in ECIP-1113
• Changes to the voting model SHALL NOT alter the execution requirements of the Olympia Treasury (ECIP-1112) — all disbursements remain subject to hash-bound execution and DAO-only authorization.

Child-DAO ECFPs for Infrastructure Spending

To streamline recurring, non-optional funding (e.g., client maintenance, RPC services), the Olympia DAO (ECIP-1113) MAY define Child-DAO ECFP categories with specialized workflows and delegated budgets.

These subtypes support predictable and auditable funding streams for infrastructure-critical domains, such as:

• Client DAO – Maintains protocol clients (e.g., Core-Geth), reviews CVEs, performs upgrades, and ensures consensus compatibility.
• Infra DAO – Manages public RPC endpoints, explorer tools, indexers, and DevOps support.
• Security DAO – Funds independent audits, formal verification, fuzzing, and bounty programs.

Each Child-DAO:

• Is deployed as a modular contract under the authority of the main DAO.
• Submits ECFPs on a scheduled or recurring basis for main DAO approval.
• Operates under scoped authority granted by main DAO votes.
• Publishes periodic progress and expenditure reports tied to specific deliverables.
• May be sunset, reauthorized, or have its budget adjusted through main DAO-approved ECFPs.

This structure ensures:

• Timely, depoliticized support for critical services.
• Public accountability through transparent disbursement, standardized event logging, and reporting.
• Reduced governance overhead for non-controversial infrastructure tasks.

Governance Requirements:

• All disbursements from the Olympia Treasury (ECIP-1112) MUST still pass through main DAO governance.
• All Treasury calls MUST be executed by the main DAO’s authorized executor contract, using the hash-bound disbursement model (ecfpId, recipient, amount, metadataCID, chainid) defined in ECIP-1112.
• Child-DAO ECFPs MUST follow the standard ECFP lifecycle (submission → voting → timelocked execution) and remain subject to quorum, threshold, and community oversight rules.
• Child-DAOs SHALL NOT hold independent authority to execute Treasury disbursements without main DAO approval.

Governance Scope

• The Ethereum Classic Funding Proposal (ECFP) process is the exclusive, on-chain mechanism for all Olympia Treasury (ECIP-1112) disbursements, including:
  • Core protocol development
  • Emergency funding
  • Recurring or operational budgets
  • Multi-phase or milestone-based grants
• The Olympia DAO contract, as defined in ECIP-1113, SHALL be the only governance-authorized contract permitted to call the Treasury’s release() and execute() functions.
• All fund movements from the Treasury MUST:
  • Be authorized exclusively by successful DAO proposals following the ECFP lifecycle
  • Be executed through the hash-bound disbursement model (ecfpId, recipient, amount, metadataCID, chainid) per ECIP-1112
  • Be immutably enforced in the Treasury contract logic

• Treasury access is immutable and governance-isolated, and cannot be overridden by any off-chain, multisig, or discretionary process.

• The DAO MAY define proposal subtypes (e.g., Operational ECFPs, Treasury Management ECFPs) with custom eligibility criteria and workflows, provided they adhere to quorum, threshold, and timelock rules.

• No treasury funds MAY be allocated or disbursed 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 solely as a legal execution proxy for approved on-chain ECFP proposals.
  • It SHALL perform no evaluative, filtering, or discretionary role.
  • It SHALL be fully subordinate to the on-chain governance outcome and bound by the parameters of the approved proposal.
• The LLC SHALL perform only off-chain administrative tasks explicitly authorized by approved DAO proposals, such as:
  • Fiat currency conversion
  • Contractor onboarding and KYC
  • Tax reporting and legal compliance
• All fiat-related disbursements MUST:
  • Correspond to a hash-bound proposal (ecfpId, recipient, amount, metadataCID, chainid) as defined in ECIP-1112
  • Be traceable to the same proposal metadata used for on-chain execution
  • Be included in public financial reports
• The LLC 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
  • Initiate or authorize Treasury disbursements outside the ECFP process
  • Modify or veto approved proposals
  • Combine protocol-level Treasury funds with donor or operational funds
  • Exercise any control over Treasury funds or DAO decisions

• DAO participants (as defined by the active governance model) MAY reassign LLC roles or rotate signers via term-limited elections defined by DAO vote.

• The LLC’s scope and actions SHALL be publicly verifiable, auditable, and bound by a narrow, revocable administrative mandate.

Donation Handling and Segregation

The Ethereum Classic DAO LLC MAY receive off-chain donations in fiat or cryptocurrency.
All such donations:

• MUST be:
  • Tracked separately from protocol-level Treasury funds at both the accounting and smart contract levels
  • Routed through on-chain mechanisms when feasible, using the hash-bound execution format (ecfpId, recipient, amount, metadataCID, chainid) per ECIP-1112 for auditability
  • Disbursed only via DAO-approved proposals following the ECFP process
  • Included in public financial transparency reports
• Use of donor funds outside the ECFP process MUST be:
  • Optional — donors may choose whether to route funds through governance
  • Transparent — with all disbursements publicly disclosed
  • Subject to community oversight
  • Strictly separated from protocol-level Treasury disbursements to preserve governance neutrality
• Donor funds MUST NOT:
  • Override, preempt, or bypass DAO-approved allocations
  • Create preferential execution paths or discretionary spending authority
  • Compromise governance integrity or Treasury access controls

All donation handling SHALL be publicly verifiable and governed by a narrow, limited administrative mandate consistent with ECIP-1113.

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 and follow the same execution safeguards as protocol-level Treasury funds.

Strategic Donors and Institutional Funders

In addition to individual contributors, the Ethereum Classic Funding Proposal (ECFP) framework — in coordination with the Ethereum Classic DAO LLC — enables transparent and accountable participation by centralized or institutional donors, such as:

• Centralized exchanges
• Mining pools and ASIC manufacturers
• Investment trusts and ETF managers
• Infrastructure sponsors (e.g., RPC, explorer, hosting providers)
• Web3 venture firms and protocol builders

These stakeholders benefit from a healthy, stable Ethereum Classic network — and now have a formal mechanism to support it without compromising decentralization or governance neutrality.

Key features that make Olympia suitable for institutional participation:

• ✅ Legal execution: The Ethereum Classic DAO LLC provides regulatory clarity, binding vote enforcement, and periodic reporting.
• ✅ Transparent governance: All disbursements — including those funded by institutional donors — require on-chain DAO approval and are immutably recorded.
• ✅ Auditable funding: Every donation, proposal, and execution path is traceable and reproducible, using the hash-bound execution format (ecfpId, recipient, amount, metadataCID, chainid) from ECIP-1112 when routed through the Treasury.
• ✅ Optional alignment: Donors may voluntarily submit or support “Donation ECFPs” to earmark funds for specific initiatives, but these proposals follow the same governance lifecycle as all others.
• ✅ No privileged access or voting power: All participants — large or small — must follow the same ECFP governance process, meet the same quorum/threshold rules, and have no special rights over Treasury funds or DAO decisions.

Protocol-Level Donors and Fee Forwarding (Composable DeFi Stack)

Building on the Strategic Donors framework, Olympia also enables EVM-native protocol-level donations from composable DeFi applications and foundational infrastructure deployed on Ethereum Classic.

Protocols such as DEXs, lending markets, liquid staking services, stablecoins, and token wrappers MAY opt to hardcode a small percentage of transaction fees, yield, or protocol revenue to be forwarded automatically to the Olympia Treasury (ECIP-1112).

This model creates a sustainable feedback loop:

More DeFi usage → more protocol volume → more fee-based donations → more funding for infrastructure → more users and applications

Examples from the broader EVM ecosystem (e.g., Lido, Balancer, Aura, RocketPool) demonstrate how smart contracts can forward protocol-level value to community-governed treasuries to sustainably fund public goods.

On Ethereum Classic, this design encourages:

• Composable, opt-in support from DeFi protocols
• Transparent, verifiable on-chain donation flows routed into the Treasury
• A self-reinforcing ecosystem of usage, funding, and development

Governance and Execution Requirements:

• All such contributions, once in the Treasury, MUST be disbursed only through the ECFP process governed by the Olympia DAO (ECIP-1113).
• Disbursement of these funds MUST use the hash-bound execution model (ecfpId, recipient, amount, metadataCID, chainid) defined in ECIP-1112.
• These proposals MUST follow the same quorum, threshold, timelock, and lifecycle requirements as all other Treasury allocations — no preferential treatment or bypass is permitted.
• Donation sources SHOULD be publicly disclosed by both the donating protocol and in the DAO’s public financial reports.
• Donating protocols MAY use the standardized “Donation ECFP” format to align contributions with specific milestones, KPIs, or initiatives.

This structure enables support from decentralized or centralized entities without compromising Ethereum Classic’s decentralization, neutrality, or fairness.

Rationale

The Ethereum Classic Funding Proposal (ECFP) framework is the final link in a four-part architecture that delivers sustainable, decentralized protocol funding to Ethereum Classic:

1. ECIP-1111 — Redirects BASEFEE from EIP-1559 transactions into a protocol-level revenue stream.
2. ECIP-1112 — Deploys an immutable, governance-isolated Treasury to hold that revenue.
3. ECIP-1113 — Establishes Olympia DAO as the sole authorized executor of Treasury disbursements.
4. ECIP-1114 — Defines the standardized, permissionless process (ECFP) for proposing, voting on, and executing those disbursements.

Why this is necessary
Before Olympia, Ethereum Classic relied on centralized foundations, corporate donors, or ad hoc funding — often opaque, inconsistent, and vulnerable to gatekeeping. This model could not guarantee stable support for critical infrastructure such as clients, RPC services, explorers, audits, and developer tools.

The ECFP process solves this by:

• Codifying a transparent, rules-based allocation mechanism for all Treasury funds.
• Binding execution to immutable metadata via ECIP-1112’s hash-bound disbursement model (ecfpId, recipient, amount, metadataCID, chainid) to ensure accountability and replay protection.
• Enforcing that all spending decisions pass through Olympia DAO governance, as defined in ECIP-1113, with quorum, threshold, and timelock safeguards.
• Providing a predictable, reproducible framework for contributors and voters, reducing ambiguity and governance fatigue.
• Preserving upgrade flexibility: governance parameters (voting model, thresholds, proposal templates) can evolve via DAO proposals without altering the core funding principles.

By separating concerns — consensus-layer revenue generation (ECIP-1111), immutable fund custody (ECIP-1112), governance execution (ECIP-1113), and standardized proposal processing (ECIP-1114) — the system is modular, auditable, and resilient.

This design ensures that Ethereum Classic’s protocol-level funding is:

• Decentralized — no single entity controls access to funds.
• Immutable — Treasury rules cannot be bypassed or altered off-chain.
• Transparent — all proposals, votes, and disbursements are on-chain and verifiable.
• Sustainable — funding grows in proportion to network usage, without inflation.

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, replacing these opaque processes with transparent, rules-based treasury governance.

The ECFP process is designed to integrate directly with the Olympia Treasury (ECIP-1112) and Olympia DAO (ECIP-1113), ensuring that all disbursements are enforced on-chain by immutable smart contracts. This modular structure allows parameters, templates, and workflows to be upgraded via DAO governance while preserving the core principles of decentralization, neutrality, and sustainability.

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 replaces opaque, discretionary funding decisions with transparent, on-chain governance, ensuring 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 proposal metadata, voting records, and disbursement events MUST be recorded on-chain and available for public inspection.

• Openness and Meritocracy
  Anyone MAY participate in submitting proposals and voting. 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 or voting logic do not affect the funding process itself, and future upgrades can be adopted without altering the ECFP structure.

• 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.

Related Work

The ECFP process places Ethereum Classic on par with DAO-based funding systems used by other leading chains, demonstrating the viability and scalability of transparent, on-chain treasury governance:

• Arbitrum (AIP Framework) — Uses token-holder voting to approve treasury disbursements for ecosystem contributors through standardized improvement proposals.
• Optimism (RPGF) — Retroactive Public Goods Funding rewards projects that have already delivered impact, governed by a bicameral DAO structure.
• Celo Community Fund — Routes a portion of transaction fees to a governance-managed treasury, funding grants and ecosystem initiatives through milestone oversight.
• Ronin DAO — Redirects EIP-1559 BASEFEE to a DAO-controlled treasury for infrastructure and ecosystem support, similar to ECIP-1111’s revenue model.
• Mantle Governance — Manages a modular treasury sourced from rollup sequencer fees, with delegated authority for domain-specific funding.
• Polygon Funding Proposals — Manages a modular treasury sourced from rollup sequencer fees, with delegated authority for domain-specific funding.

In each of these systems, treasury funds are controlled by transparent, on-chain governance processes, with immutable execution rules and public accountability. Olympia applies these proven patterns to Ethereum Classic’s Proof-of-Work network — combining:

• Sustainable, consensus-layer funding from ECIP-1111
• Immutable, governance-isolated custody from ECIP-1112
• Sole-executor, permissionless governance from ECIP-1113
• Standardized, hash-bound proposal execution from ECIP-1114

Implementation

1. Proposal Submission

• Proposal submission is permissionless. Any Ethereum Classic address MAY submit an ECFP via the Olympia DAO interface, subject to the governance parameters defined in ECIP-1113 (e.g., quorum, thresholds, delays).
• Optional Sybil-resistance modules (e.g., BrightID, Gitcoin Passport, Proof of Humanity) MAY be adopted via DAO vote to verify unique participants.
• 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) — this CID MUST be identical to the value used in the hash-bound execution tuple (ecfpId, recipient, amount, metadataCID, chainid) per ECIP-1112.
• 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.

// --- BEGIN PROPOSAL SUBMISSION FUNCTION ---
// This function is called by any address wishing to submit a funding proposal.
// It records the proposal details and binds them to a unique hash derived from:
// - proposal ID
// - recipient address
// - requested amount
// - off-chain metadata content hash (IPFS/Arweave)
// - chain ID (for replay protection)
//
// Proposals should be discussed off-chain and finalized before submission.
// This contract does not validate deliverables or enforce proposal quality.

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’s voting snapshot block height to prevent vote power changes after proposal activation
  • Emit standardized ProposalSubmitted and ProposalExecuted events for indexing

3. Execution and Disbursement

• Upon successful approval, the DAO’s sole authorized executor SHALL trigger fund release by calling release() or execute() on the Olympia Treasury.
• Disbursement MAY follow one of the following formats:
  • One-time transfer
  • Scheduled vesting based on milestones
  • Programmatic stream via escrow or disbursal contract
• Treasury disbursements SHALL:
  • Use deterministic proposal hashes for release validation, computed from (ecfpId, recipient, amount, metadataCID, chainid) per ECIP-1112
  • Bind off-chain metadata (e.g., IPFS or Arweave CID) to an immutable execution payload
  • Emit a standardized ProposalExecuted event from both DAO and Treasury with identical parameters
• Each transaction MUST include the relevant ECFP ID and metadata hash to ensure auditability.

// --- BEGIN PROPOSAL EXECUTION FUNCTION ---
// This function is called by the Olympia DAO executor after a successful on-chain vote.
// It disburses funds from the Treasury by calling the `release()` function,
// using a hash-bound payload that ensures:
// - The recipient and amount match the proposal metadata
// - The proposal passed governance vote and is approved
// - The execution is recorded immutably on-chain
//
// This function MUST only be callable by the DAO executor.
// It assumes prior validation has occurred through voting + timelock logic.

function executeECFP(
    uint256 ecfpId,
    bytes32 proposalHash,
    address recipient,
    uint256 amount
) external {
    require(isApproved(ecfpId), "ECFP not approved");
    OlympiaTreasury(treasuryAddress).release(proposalHash, recipient, amount);
}
// --- END PROPOSAL EXECUTION FUNCTION ---

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
  • Verifiably mirror on-chain state
  • Leverage standardized DAO and Treasury events for lifecycle and execution tracking

5. Community Review and Deliberation

• Proposals SHOULD undergo informal discussion prior to on-chain activation.
• Review MAY occur on:
  • 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 of full proposal lifecycle and hash-bound execution
  • Community validation
  • Independent 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 EVM semantics, and is therefore fully backward-compatible with all existing contracts, wallets, clients, and tooling.

Compatibility Notes

• No Protocol Changes
  The ECFP process does not modify consensus logic, block validation, or transaction structure.
  All consensus-layer rules remain unchanged.

• Voluntary Participation
  Engagement with ECFP governance is opt-in.
  Network participants are not required to submit or vote on proposals to remain in consensus.

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

• Client Compatibility
  • Clients implementing ECIP-1111 through ECIP-1114 will remain in consensus.
  • Clients that do not implement ECIP-1111 will fork from the canonical chain at the activation block.
  • Clients that support ECIP-1111 and ECIP-1112 but not ECIP-1113 or ECIP-1114 will remain in consensus but will be unable to process governance transactions or authorize Treasury disbursements.
• Treasury Execution Requirements
  To execute disbursements, clients MUST support:
  • The immutable Olympia Treasury contract (ECIP-1112)
  • The Olympia DAO executor contract (ECIP-1113)
  • The hash-bound execution path (ecfpId, recipient, amount, metadataCID, chainid) defined in ECIP-1112
    Without these, clients can still validate governance transactions but cannot generate or authorize them.
• State and Data Integrity
  Proposal data, voting records, and execution events are stored entirely within governance-layer contract state.
  No historical blockchain state is altered, and consensus-layer data remains unaffected.

By isolating governance logic from protocol consensus, the ECFP framework integrates cleanly with the Ethereum Classic stack while preserving base-layer stability and security.

Security Considerations

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

1. Metadata and Proposal Integrity

The proposal hash acts as the unique execution identifier, binding an on-chain disbursement to an immutable, off-chain metadata record stored on IPFS or Arweave.
This prevents tampering and ensures verifiability of funding intent and deliverables.

All ECFPs MUST:

• Embed a verifiable content hash (e.g., IPFS CID or Arweave digest) in on-chain metadata.
• Store proposal documents immutably in a content-addressable format.
• Use a globally unique ECFP ID to prevent collisions or replay.
• Include the chain ID and a domain separator in the hash to prevent replay attacks across forks or testnets.

// Off-chain: Generate ECFP proposal hash for on-chain binding
// This must match the exact structure used in submitECFP()
// and be calculated prior to DAO voting for proposal integrity.
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 in its on-chain metadata to ensure tamper resistance.

• Immutable References
  Off-chain documents MUST be stored immutably so voters can verify content has not been altered post-submission.

• Proposal Uniqueness
  Each ECFP MUST use a globally unique ID.

• Replay Protection
  The chain ID and domain separator MUST be included in the hash to prevent replay across networks.

2. Treasury and DAO Contract Safeguards

• Execution Logic Isolation
  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 calls from unauthorized accounts, including EOAs or non-whitelisted contracts.

• No Arbitrary Logic
  Execution paths MUST follow deterministic disbursement rules defined in ECIP-1112.

• Immutable Lifecycle States
  Once Active (under vote), an ECFP cannot be edited or withdrawn.

• Redundant Event Logging
  DAO and Treasury contracts SHOULD emit standardized events (e.g., ProposalSubmitted, ProposalExecuted) for independent indexing.

3. Governance Process Risks

• Governance Capture
  Mitigated through quorum requirements, optional delegated/reputation-based voting, and configurable thresholds subject to DAO governance.

• Replay Defense
  Governance payloads MUST include domain separation and unique IDs.

• Safe Governance Upgrades
  All DAO upgrades MUST:

  • Be proposed and approved on-chain
  • Pass independent audits
  • Be subject to timelock delays before activation

4. Execution and Client Consistency Risks

• Client Validation
  Clients MUST verify that disbursements match DAO-approved parameters to prevent consensus divergence or fund misallocation.

• Reentrancy and Logic Audit
  DAO and Treasury contracts MUST undergo formal verification and third-party audits.

• Proposal Manipulation
  Prevented through structured templates, minimum review periods, and metadata hash enforcement at execution.

• Funding Accountability
  Proposals SHOULD use milestone-based disbursements, vesting schedules, and clawback clauses.

5. Spam Resistance and Participation Gating

• Sybil Attack Mitigation
  The DAO MAY adopt safeguards such as:
  • Minimum stake or token holdings
  • Submission cooldown intervals
  • Optional identity attestation or permissionless whitelisting
• Such measures MUST preserve permissionless participation and be subject to governance oversight.

Summary

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

• Immutable, verifiable proposal metadata
• Restricted and audited execution paths
• Formal quorum and upgrade thresholds
• Open yet protected proposal submission
• Full on-chain transparency of the proposal lifecycle, voting records, and disbursements

The complete system MUST be deployed to Mordor Testnet for simulation, undergo public audits, and be verified for correctness before mainnet activation.

Related ECIPs in the Olympia Upgrade

ECIP-1114 is one of four coordinated proposals that together introduce sustainable, decentralized, and transparent protocol funding for Ethereum Classic:

• ECIP-1111 — Olympia EVM and Protocol Upgrades
  Activates EIP-1559 and EIP-3198 on Ethereum Classic and redirects the BASEFEE to the Olympia Treasury instead of burning it.

• ECIP-1112 — Olympia Treasury Contract
  Defines the immutable, governance-isolated smart contract that receives all redirected BASEFEE revenue and holds it until released by on-chain governance.

• ECIP-1113 — Olympia DAO Governance Framework
  Specifies the decentralized governance architecture that serves as the sole authorized executor for Treasury disbursements, including proposal submission, voting, and time-locked execution.

• ECIP-1114 — Ethereum Classic Funding Proposal Process
  Establishes the standardized, permissionless proposal format (ECFP) for requesting funds from the Treasury, ensuring transparent, hash-bound, and verifiable allocation of protocol-level funding.

Interdependency Summary

• ECIP-1111 enables protocol-level revenue generation via BASEFEE redirection.
• ECIP-1112 deploys an immutable vault to store that revenue, isolated from governance logic.
• ECIP-1113 creates the governance layer that can authorize Treasury disbursements.
• ECIP-1114 defines the standardized proposal process that ECIP-1113 enforces for all disbursements.

All four ECIPs are designed for modular activation:

• ECIP-1111 and ECIP-1112 can be deployed first, enabling revenue accumulation.
• ECIP-1113 and ECIP-1114 can be deployed later, enabling controlled, on-chain governance of Treasury funds.

Copyright

Copyright and related rights waived via
CC0

Appendix: EVM Precedents for Funding Proposal Processes

The Ethereum Classic Funding Proposal (ECFP) process (ECIP-1114) is designed to provide a standardized, permissionless, and transparent method for requesting and executing protocol-level funding.
Its structure draws on proven funding processes from other EVM-compatible networks that have successfully managed large-scale, community-governed grant and budget allocations.

Funding Process Precedents

Observations

• Structured Proposal Lifecycles — Most processes have clear stages from draft to approval to execution, mirroring the ECFP’s Draft → Active → Approved → Executed flow.
• Community Review Before Voting — Pre-vote discussion periods are common and improve decision quality; ECFP incorporates optional draft review periods for this purpose.
• On-Chain Enforcement — All listed processes end in a binding, on-chain action, just as ECFP enforces disbursement via the hash-bound execution path (ecfpId, recipient, amount, metadataCID, chainid).
• Sybil Resistance and Participation Requirements — Many systems employ stake requirements or identity verification; ECFP includes these as optional, governance-configurable modules.
• Milestone and Impact-Based Funding — Several processes disburse funds in tranches or after deliverables are met; ECFP natively supports milestone-based schedules.

By adapting these proven patterns to Ethereum Classic’s principles of decentralization, immutability, and neutrality, ECIP-1114 delivers a funding process that is both familiar to EVM users and optimized for ETC’s long-term sustainability.