ECIP 1114: Ethereum Classic Funding Proposal Process

Author	Cody Burns, Chris Mercer
Discussions-To	https://github.com/orgs/ethereumclassic/discussions/530
Status	Draft
Type	Meta
Created	2025-07-04
Requires	1111, 1112, 1113

Simple Summary

This ECIP defines the Ethereum Classic Funding Proposal (ECFP) process — a standardized, open framework for requesting protocol-level funding from the Olympia Treasury via the Olympia DAO. ECFPs enable developers, infrastructure providers, researchers, and community contributors to propose and justify their work in a transparent, permissionless, and reproducible format, ensuring treasury funds are allocated fairly and in alignment with network goals.

Abstract

This ECIP establishes the Ethereum Classic Funding Proposal (ECFP) process as the canonical submission format and lifecycle for funding requests to the Olympia Treasury, governed by the Olympia DAO. ECFPs serve as the primary interface between builders and Ethereum Classic’s protocol-level funding system, providing structure, clarity, and accountability for all requests.

An ECFP defines the problem to be solved, the scope of work, the requested funding amount, the recipient(s), milestones, and expected outcomes. The process includes public discussion, on-chain governance voting, and transparent fund disbursement upon approval.

The ECFP format is designed to be accessible, reproducible, and auditable by any member of the community, enabling sustainable funding of core development, infrastructure, ecosystem tools, and public goods that benefit Ethereum Classic’s long-term health and decentralization.

Motivation

Ethereum Classic has historically struggled to coordinate funding for public goods — including client development, infrastructure, documentation, security audits, and educational resources. Funding decisions were often made off-chain, behind closed doors, or by centralized entities with limited transparency or accountability to the broader community.

With the activation of the Olympia Treasury (ECIP-1112) and the governance system established by Olympia DAO (ECIP-1113), Ethereum Classic now possesses a decentralized, protocol-native funding mechanism. However, to ensure this system is effective, the network must adopt a standardized process for requesting, reviewing, and approving proposals.

The ECFP format solves this by:

Codifying the Proposal Lifecycle: From submission to voting to disbursement, each step is clearly defined and permissionless.
Encouraging Ecosystem Participation: Anyone can submit an ECFP — not just well-connected teams or insiders.
Increasing Transparency and Accountability: Proposals are published on-chain or via verifiable sources and tracked publicly.
Reducing Governance Overhead: Standardized formats help voters evaluate proposals more efficiently and make consistent decisions.
Creating Institutional Memory: Approved and rejected proposals are permanently archived, enabling future contributors to learn from past decisions.

The ECFP process is modeled after the successful ECIP governance framework and adapts it for funding purposes, enabling Ethereum Classic to fund itself — transparently and sustainably — for the first time in its history.

Specification

The Ethereum Classic Funding Proposal (ECFP) process is defined as a structured, standardized lifecycle for submitting, evaluating, voting on, and executing proposals for protocol-level funding from the Olympia Treasury. It SHALL be enforced at the governance layer by the Olympia DAO (ECIP-1113) and recorded on-chain for transparency.

ECFP Lifecycle

Proposal Submission
- Proposals SHALL be submitted by any Ethereum Classic account through the Olympia DAO governance interface.
- Each proposal MUST include:
  - Proposal title and ECFP number (assigned automatically or sequentially)
  - Author name(s) and contact
  - Requested funding amount (in ETC)
  - Recipient address
  - Purpose, scope of work, and expected impact
  - Disbursement schedule (e.g. milestone-based, linear vesting, lump sum)
  - Relevant deliverables and KPIs
  - Off-chain metadata link (e.g. IPFS or Arweave document for full proposal)
Proposal Statuses

Each proposal MUST pass through the following statuses:
- Draft: Submitted and open for discussion but not yet eligible for voting.
- Active: Undergoing on-chain voting during a defined voting window.
- Approved: Passed voting thresholds and eligible for execution.
- Rejected: Failed to meet quorum or approval threshold.
- Executed: Funds have been disbursed via Olympia Treasury.
- Expired: Not voted on within the proposal’s valid period.
Voting and Quorum
- Voting SHALL be conducted via Olympia DAO using a token-weighted or delegated stake mechanism.
- Proposals MUST meet a minimum quorum (e.g., 5% of eligible voting power) and approval threshold (e.g., 60% yes votes).
- Voting period and delay SHALL be configurable by DAO governance.
Execution and Disbursement
- Upon approval, the DAO contract SHALL schedule the associated disbursement to the recipient via the Olympia Treasury’s release() or execute() functions.
- Disbursement MAY be time-locked or milestone-based.
- Execution MUST emit a ProposalExecuted event with relevant metadata.
Amendments and Withdrawals
- Proposals MAY be amended or withdrawn by the original author before entering the Active state.
- Once a proposal is Active, it CANNOT be changed, only voted on.
Transparency and Indexing
- All proposals and their statuses SHALL be recorded on-chain.
- A public dashboard or explorer MAY be maintained to track proposal history, disbursements, and results.

Governance Scope

The ECFP process SHALL be binding for all disbursements from the Olympia Treasury.
Emergency withdrawals, recurring budgets, or multi-phase proposals MUST still be submitted via the ECFP process.
Olympia DAO MAY introduce additional proposal categories (e.g., Operational ECFPs, Treasury Management ECFPs) with specific criteria and review workflows.

Legal Interface: Ethereum Classic DAO LLC

While the Olympia DAO governs proposal approval and treasury disbursement on-chain, all off-chain administrative and compliance functions — including fiat conversion, tax reporting, Bank Secrecy Act (BSA) and Know Your Customer (KYC) compliance, and contractor engagement — SHALL be facilitated by Ethereum Classic DAO LLC, a Wyoming-registered DAO entity.

This legal wrapper:

Acts as a real-world interface for recipients who require legal clarity or fiat settlement
Ensures that treasury disbursements meet applicable regulatory requirements
Maintains standardized reporting and transparency to uphold the DAO’s integrity
Holds no governance authority; all disbursement decisions MUST originate from on-chain proposals and votes

The DAO LLC functions solely as a compliance conduit, enabling lawful execution of approved disbursements without custody or discretion over treasury funds or DAO governance.

Rationale

The Ethereum Classic Funding Proposal (ECFP) process formalizes a community-governed method for allocating protocol-level funds from the Olympia Treasury. This structure ensures funding decisions are transparent, inclusive, and aligned with the Ethereum Classic network’s long-term values.

Key reasons for defining the ECFP process include:

Clarity and Accountability
By standardizing how proposals are submitted, voted on, and executed, the ECFP process eliminates ambiguity and ensures all stakeholders understand how funds are allocated. Clear expectations for proposal content and deliverables enhance accountability.
Transparency and Auditability
The entire proposal lifecycle is executed on-chain. This ensures all funding decisions, disbursements, and outcomes are verifiable by any network participant, reducing the risks of favoritism, mismanagement, or opaque grants.
Openness and Neutrality
Anyone — including independent developers, infrastructure teams, researchers, or content creators — can participate in the funding process. This removes historical barriers to entry and promotes merit-based contributions to Ethereum Classic.
Governance Modularity
By defining the ECFP process independently of the DAO’s implementation, Ethereum Classic can upgrade governance mechanisms over time without altering the principles or procedures of the funding process.
Alignment with ETC Principles
The ECFP process reflects Ethereum Classic’s commitment to decentralization, sovereignty, and trust minimization. It replaces opaque, foundation-based grantmaking with a public, rules-based system that any community member can engage with.

This ECIP ensures that the Olympia Treasury — funded via ECIP-1112 and governed via ECIP-1113 — has a robust and community-driven framework for advancing the Ethereum Classic ecosystem. The ECFP framework ensures Ethereum Classic evolves with the DAO-first ethos of modern decentralized ecosystems, bringing funding structure comparable to processes like Arbitrum’s AIP framework, Optimism’s RPGF, and Celo’s Community Fund. By defining a public, reproducible, and accountable pipeline for distributing protocol-level resources, the ECFP system empowers ETC to grow sustainably while preserving its founding principles of immutability, decentralization, and user sovereignty.

Implementation

The ECFP process will be implemented as an integrated component of the Olympia DAO governance system (see ECIP-1113), which interfaces directly with the Olympia Treasury (ECIP-1112). This process combines smart contract infrastructure with off-chain discussion forums and proposal documentation standards.

Key implementation elements include:

1. Proposal Submission

A dedicated ECFP submission portal SHALL be provided at https://github.com/ethereumclassic/ECFPs.
Proposals MUST include a valid ECFP number (assigned sequentially), title, rationale, funding amount, recipient address, and milestone schedule.
Full-text proposals SHALL be stored using metadata pointers (e.g., IPFS CID or Arweave URL) to ensure permanence and auditability.
Proposals SHOULD use the ECFP Markdown template to ensure consistency and ease of review.
Off-chain proposal metadata MUST be stored in a content-addressable format (e.g., IPFS CID or Arweave URL) and referenced in the on-chain proposal via metadata hash or URL.
Proposals MAY include links to mockups, prototypes, GitHub repos, or community endorsements as part of their metadata payload.

2. On-Chain Registry and Voting

The Olympia DAO smart contracts SHALL include a proposal registry that records submission timestamps, proposers, and vote outcomes.
Governance contracts MUST enforce voting periods, quorum thresholds, and proposal execution conditions.
Voter snapshots SHALL be recorded at the proposal block height to ensure fair participation and prevent manipulation.

3. Execution and Disbursement

Upon successful approval, the DAO contract SHALL call the release() or execute() function on the Olympia Treasury contract to disburse funds.
Disbursements MAY be executed as:
- One-time lump sum transfers,
- Scheduled milestone-based vesting,
- Or programmatic streams via contract-based disbursers.
Execution MUST emit a standardized ProposalExecuted event from the DAO contract, including:
- ECFP ID
- Recipient address
- Amount disbursed
- Timestamp and block number
- Executing proposal hash or reference
All disbursements SHALL adhere to the execution rules defined in the Olympia Treasury (ECIP-1112), which rejects any transfers not authorized by a successful on-chain proposal.
The execute() or release() calls MUST include the associated ECFP ID and disbursement metadata in the transaction payload to ensure traceability and enforce auditability.

4. Transparency Dashboard

A public dashboard SHALL display proposal statuses, voting outcomes, treasury balances, and funding history.
The dashboard SHALL be open source and mirror on-chain data for public verifiability.

5. Community Review Layer

Off-chain discussion SHALL take place on the ECIP forums, Discord, or approved governance platforms prior to on-chain voting.
Moderators MAY facilitate proposal formatting and filtering but SHALL NOT possess approval or veto powers.

Initial testing and deployment will occur on the Mordor Testnet, followed by public audits and mainnet activation aligned with the rollout of ECIP-1112 and ECIP-1113.

Backwards Compatibility

The ECFP process introduces a governance framework and funding workflow at the smart contract level. It does not modify Ethereum Classic’s consensus rules, transaction formats, or EVM behavior. As such, it is fully backward-compatible with existing contracts, wallets, clients, and applications.

Key points:

Legacy smart contracts and dApps will remain unaffected.
Participation in the ECFP process is voluntary; users, miners, and developers who do not engage with governance contracts are unaffected by its operation.
The Olympia Treasury (ECIP-1112) and Olympia DAO (ECIP-1113) must be deployed and supported by clients participating in governance to ensure execution compatibility.
Node operators who choose not to upgrade to ECIP-1111–1114 will diverge from consensus, but application-layer compatibility remains intact.

Because the ECFP system operates entirely through standard smart contract interactions, its implementation poses no risk to prior state, core protocol behavior, or existing network functionality.

Security Considerations

The ECFP process introduces formal structures for requesting and disbursing protocol-level funds. Several security-related concerns must be addressed to ensure long-term safety and integrity:

Sybil Attacks: To prevent spam or malicious submissions, proposal intake should include minimum thresholds such as reputation-based gating, stake requirements, or time-based cooldowns. Care must be taken not to make these barriers so high that they discourage legitimate participation.
Proposal Manipulation: Malicious actors may attempt to submit deceptive or harmful proposals. Transparent deliberation periods, metadata requirements, and on-chain voting help mitigate these risks.
Funding Abuse: To avoid misappropriation, disbursements should be milestone-based or require accountability checks. Proposals can include vesting schedules, refund mechanisms, or revocation triggers.
Governance Capture: If a small group gains disproportionate voting power, they could dominate funding flows. Mitigations include quorum requirements, vote delegation, and periodic governance parameter reviews.
Client Implementation: All clients must enforce consistency between approved proposals and treasury execution. Mismatches could cause divergence or fund loss.
DAO Upgrade Risks: If the Olympia DAO governance system is upgradable, upgrade paths must be secure, time-locked, and publicly auditable to prevent hostile takeovers.
Treasury Integrity: Only the DAO should be able to trigger treasury disbursements. The Olympia Treasury contract must reject direct access from EOAs or unauthorized contracts.
Reentrancy or Logic Bugs: DAO and Treasury contracts must be formally verified and audited to prevent reentrancy attacks, logic errors, or unintended side effects during proposal execution.
Metadata Integrity: Off-chain proposal documents referenced in ECFPs must include their content hash in the on-chain metadata to prevent tampering or metadata spoofing. This ensures that the voted-upon proposal content cannot be altered post-submission.
Replay Safety: ECFP executions MUST be protected against replay attacks across testnet/mainnet by including a chain ID and governance domain separator in the execution hash.
Redundant Event Logging: To support full audit trails, the DAO and Treasury contracts SHOULD both emit disbursement-related events when a proposal is executed. Indexers can cross-check event logs for consistency.
Proposal Uniqueness: Each ECFP ID MUST be unique and immutable once assigned to prevent double-spend proposals or conflicting execution attempts.

Thorough testing on testnet, rigorous code review, and community participation are essential to minimize these risks prior to mainnet deployment.

ECIP 1114: Ethereum Classic Funding Proposal Process Source