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.

Child-DAO ECFPs for Infrastructure Spending

To streamline recurring, non-optional funding (e.g., client maintenance, RPC services), the DAO 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 like Core-Geth
• Infra DAO – Funds RPC nodes, explorers, monitoring, and deployment tooling
• Security DAO – Handles audits, CVEs, bounty programs, and formal verification

Each Child-DAO:

• Submits ECFPs on a scheduled or recurring basis
• Operates under scoped authority granted by main DAO votes
• Publishes periodic progress and expenditure reports
• May be sunset or reauthorized through ECFP proposals

This structure ensures:

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

Child-DAO ECFPs MUST still follow the standard ECFP lifecycle (submission → voting → timelocked execution) and remain subject to community oversight and DAO quorum rules.

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.

Strategic Donors and Institutional Funders

The ECFP framework also enables transparent and accountable participation by centralized or institutional donors, such as:

• Centralized exchanges (CEXs)
• Mining pools and ASIC manufacturers
• Investment trusts and ETF managers (e.g., Grayscale, VanEck)
• 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.

Key features that make Olympia suitable for institutional participation:

• ✅ Legal execution: The Ethereum Classic DAO LLC provides regulatory clarity, binding vote enforcement, and reporting.
• ✅ Transparent governance: All disbursements require on-chain DAO approval and are immutably recorded.
• ✅ Auditable funding: Every donation, proposal, and execution path is traceable and reproducible.
• ✅ Optional alignment: Donors may voluntarily submit or support “Donation ECFPs” to earmark funds for specific initiatives.
• ✅ No privileged access: All participants — large or small — must follow the same governance process.

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

In addition to off-chain donations, 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, stablecoins, and token wrappers MAY opt to hardcode a small percentage of transaction fees, yield, or protocol revenue to be forwarded to the Olympia Treasury address.

This creates a sustainable feedback loop:

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

This model mirrors successful funding practices seen in the broader EVM ecosystem (e.g., Lido, Balancer, Aura, RocketPool), where smart contracts forward protocol-level value to community-governed treasuries.

By adopting this design on Ethereum Classic, Olympia encourages:

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

These contributions SHOULD be publicly disclosed and MAY use a standardized “Donation ECFP” format if alignment with a specific milestone, KPI, or proposal is desired. All funds, regardless of source, MUST pass through on-chain execution by Olympia DAO, ensuring neutrality and auditability.

This structure welcomes support from centralized entities without compromising decentralization or fairness.

Olympia provides the first compliant, on-chain, and permissionless path for long-term funders to contribute to Ethereum Classic infrastructure — ending reliance on opaque, off-chain arrangements.

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:

// --- 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);
}
// --- END PROPOSAL SUBMISSION FUNCTION ---

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.

// --- 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 ---

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
// 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 (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.