ECIP 1113: Olympia DAO Governance Framework

Simple Summary

This ECIP defines the on-chain governance framework for Olympia DAO, the DAO-designated execution contract for disbursements from the immutable Olympia Treasury (ECIP-1112) funded by BASEFEE revenue redirected under ECIP-1111.
Olympia DAO enables transparent, permissionless proposal submission, on-chain voting, and time-locked execution of approved allocations through the standardized Ethereum Classic Funding Proposal (ECFP) process (ECIP-1114).

It ensures that protocol-level funds are allocated in accordance with Ethereum Classic’s principles of decentralization, neutrality, and sustainability, with all disbursements cryptographically bound to immutable proposal metadata.

No governance token exists at launch. Any future token issuance, supply, or distribution MUST be proposed and ratified transparently through on-chain governance, with no premine or privileged allocation.

No governance token exists at launch. Any token issuance, supply, or distribution must be proposed and approved transparently through on-chain governance.

Abstract

This ECIP specifies the architecture of Olympia DAO — the decentralized governance system that serves as the only governance-authorized execution path for releasing funds from the immutable Olympia Treasury (ECIP-1112), which accumulates BASEFEE revenue redirected at the consensus layer under ECIP-1111.

Olympia DAO operates entirely on-chain, enabling permissionless proposal submission, voting, and time-locked execution of approved disbursements through the standardized Ethereum Classic Funding Proposal (ECFP) process (ECIP-1114).

The DAO is implemented as a modular smart contract suite, with governance logic, voting mechanisms, and a restricted Treasury interface that enforces the hash-bound disbursement model defined in ECIP-1114 — cryptographically binding each release to immutable proposal metadata (proposal ID, recipient, amount, metadata CID, and chainid).

This framework ensures that protocol-level funding is allocated transparently, equitably, and without reliance on trusted intermediaries, preserving Ethereum Classic’s principles of immutability, decentralization, and neutrality.

Motivation

Historically, Ethereum Classic has depended on centralized foundations, corporate sponsors, and private donors to fund protocol development — often through opaque, off-chain processes with limited community oversight.
This model introduced risks of gatekeeping, inconsistent funding, strategic misalignment, and long-term fragility of critical infrastructure.

With ECIP-1111 activating EIP-1559 and redirecting BASEFEE to the immutable Olympia Treasury (ECIP-1112), Ethereum Classic gains a protocol-native, non-inflationary funding stream tied directly to network activity.
However, without a decentralized governance framework, these funds would remain inaccessible or require centralized control — undermining the neutrality, transparency, and security principles of the network.

Olympia DAO addresses this by:

• Serving as the sole authorized executor of Treasury disbursements (ECIP-1112), ensuring all fund movements occur only through approved on-chain governance.
• Enforcing the Ethereum Classic Funding Proposal (ECFP) process (ECIP-1114) for all allocations, with hash-bound execution that cryptographically links disbursements to immutable proposal metadata.
• Enabling open, permissionless participation in decision-making for protocol development, infrastructure maintenance, and ecosystem growth.
• Replacing discretionary, off-chain grantmaking with rule-based, on-chain governance that is auditable and reproducible.
• Reducing capture risk through quorum and threshold requirements, time-locked execution, and modular upgrade paths for voting mechanisms.

By combining the sustainable funding source established in ECIP-1111, the governance-isolated vault in ECIP-1112, and the standardized proposal lifecycle in ECIP-1114, Olympia DAO ensures that protocol-level resources are allocated in alignment with Ethereum Classic’s founding principles of immutability, decentralization, and neutrality — without introducing inflation or privileged control.

Specification

Governance Model

The Olympia DAO SHALL be implemented as a modular smart contract system deployed on Ethereum Classic.
It SHALL govern the disbursement of funds from the immutable Olympia Treasury (ECIP-1112), which accumulates BASEFEE revenue redirected at the consensus layer under ECIP-1111.
All fund movements MUST occur exclusively through successful on-chain proposals following the Ethereum Classic Funding Proposal (ECFP) process (ECIP-1114).

The DAO MUST implement the following core components:

• Proposal Submission
  • Any address MAY submit an ECFP via the DAO interface (per ECIP-1114).
  • Proposals MUST include:
    • Requested funding amount
    • Recipient address
    • Scope of work and deliverables
    • Disbursement schedule (milestones, vesting, or single transfer)
    • Immutable metadata pointer (IPFS/Arweave CID)
  • The metadata CID SHALL be bound to the proposal execution hash as defined in ECIP-1114.
• Voting Mechanism
  • All proposals SHALL undergo an on-chain vote.
  • The initial deployment SHALL operate without a governance token, using a one-address-one-vote model for maximum openness.
  • Any token issuance, voting-weight change, or new voting model MUST be proposed and approved via on-chain DAO vote, with no premine or privileged allocation.
• Quorum and Approval Thresholds
  • A minimum quorum MUST be enforced for validity.
  • A configurable approval threshold (e.g., ≥60% “yes” votes) MUST be met before execution.
  • These parameters SHALL be DAO-configurable and adjustable only via on-chain proposal + timelock.
• Execution Logic
  • Approved proposals SHALL be queued for execution via a timelocked executor contract.
  • Execution MUST call the Olympia Treasury’s release() or execute() function, passing the hash-bound parameters (ecfpId, recipient, amount, metadataCID, chainid) exactly as defined in ECIP-1114.
  • The Treasury MUST reject any call from an unauthorized caller or with mismatched proposal hash (per ECIP-1112).
• Treasury Access Control
  • The DAO’s execution contract SHALL be the exclusive governance-authorized caller of the Treasury’s disbursement functions.
  • No other contract, EOA, or multisig MAY bypass this control path.
• On-Chain Transparency
  • All proposal metadata, voting records, and disbursement events MUST be logged on-chain and indexed for public inspection.
  • Events emitted SHALL match the standardized naming in ECIP-1114 for consistency across governance and Treasury layers.

Contract Properties

• Minimal, Audited Architecture
  • Governance logic SHALL be based on modular, well-audited frameworks (e.g., OpenZeppelin Governor, Compound Bravo).
  • No delegatecall, proxies, or dynamic code execution SHALL be used in the DAO contracts.
• Upgradeable Governance Logic
  • Governance modules MAY be upgraded via on-chain proposal, subject to quorum, threshold, and timelock.
  • The Treasury contract (ECIP-1112) SHALL remain permanently immutable.
• No Admin Privileges
  • No centralized entity SHALL hold override powers or be able to execute Treasury disbursements outside the DAO process.

Emergency Governance (Fallback Multisig)

• A time-locked, community-elected multisig MAY be deployed as a governance failsafe.
• Scope is strictly limited to:
  • Pausing queued execution
  • Quarantining malicious proposals
  • Triggering a DAO reset/reinitialization vote
• This multisig:
  • SHALL NOT submit proposals or disburse funds
  • SHALL NOT override DAO outcomes without reauthorization
  • MUST be publicly auditable, revocable, and time-limited

Signer Diversity and Accountability

• For any off-chain legal or administrative multisig (e.g., Ethereum Classic DAO LLC account):
  • Minimum of three distinct, unaffiliated signers at launch
  • Public disclosure of signer roles and affiliations
  • Optional term limits and periodic rotation via DAO vote

Child-DAO Modules for Critical Infrastructure

To ensure continuous, predictable support for non-optional ecosystem services — such as Core-Geth maintenance, Mordor Testnet, RPC endpoints, and explorer services — Olympia DAO MAY deploy Child-DAO modules with delegated authority and scoped budgets.

These infrastructure-focused sub-DAOs enable public accountability, funding predictability, and domain-specific governance, without compromising the main DAO’s authority or bypassing the hash-bound disbursement path enforced by the Olympia Treasury (ECIP-1112) and the ECFP process (ECIP-1114).

Examples of Child-DAOs

• Client DAO
  • Maintains protocol clients (e.g., Core-Geth)
  • Reviews CVEs, implements upgrades, and ensures consensus compatibility
  • May include known contributors or rotating public stewards
  • Operates on recurring, deliverable-based budgets
• Infra DAO
  • Manages public RPC endpoints, explorer tools, indexers, and DevOps infrastructure
  • Coordinates with ecosystem stakeholders to reduce fragmentation and maintain uptime
  • May fund third-party service providers, fallback infrastructure, and monitoring tools
• Security DAO (Optional)
  • Funds independent audits, formal verification, and testnet fuzzing
  • Issues bounty rewards for vulnerability discovery and disclosure

Child-DAO Governance Parameters

• Child-DAOs SHALL be deployed as modular contracts under the authority of the main DAO.
• All disbursements from the Olympia Treasury MUST:
  • Be authorized via a main DAO vote following the ECFP process (ECIP-1114)
  • Pass through the Treasury’s release() or execute() function with a matching proposal hash (ecfpId, recipient, amount, metadataCID, chainid) (per ECIP-1114)
• Each Child-DAO MAY:
  • Propose a recurring budget
  • Publish periodic expenditure and deliverable reports
  • Be subject to reauthorization, budget adjustment, or dissolution via main DAO vote

Benefits of the Child-DAO Model

• Ensures non-optional infrastructure (e.g., clients, RPCs) remains funded transparently
• Encourages long-term contributor retention with reduced political friction
• Enables specialized governance for technically complex or recurring tasks
• Preserves main DAO bandwidth by reducing governance fatigue

Accountability and Transparency

• Child-DAOs MUST publish public dashboards or reports tied to deliverables
• Proposals MAY include specific KPIs or milestone-based disbursement conditions
• All interactions between the Treasury and Child-DAOs MUST emit standardized events defined in ECIP-1114 and remain fully on-chain auditable

This approach balances decentralization with operational sustainability, ensuring that critical Ethereum Classic infrastructure remains resilient, well-maintained, and governed under transparent, permissionless rules.

Rationale

Modular, Future-Ready Governance

Olympia DAO is deliberately structured to align with the modular activation model of ECIP-1111 and ECIP-1112.
Governance (ECIP-1113), Treasury storage (ECIP-1112), and proposal execution (ECIP-1114) are implemented as independent smart contract layers:

• Separation of Concerns
  Governance logic, treasury vaulting, and proposal execution each reside in isolated contracts with narrowly scoped permissions.
  • The DAO cannot alter Treasury rules (ECIP-1112 immutability)
  • The Treasury cannot approve its own disbursements (DAO-only access control)
  • All proposals must follow the ECFP lifecycle (ECIP-1114)

• Progressive Activation
  The Treasury begins accumulating funds immediately after ECIP-1111 activation, even before DAO deployment. ECIP-1113 can be deployed later, after audits, testnet validation, and community onboarding.

• Governance Upgradeability
  Voting models, quorum thresholds, and proposal requirements can evolve via on-chain governance without altering the Treasury contract or consensus rules.

This modularity minimizes deployment risk, preserves flexibility, and ensures consensus-layer safety.

Addressing Historical Governance Gaps

Before Olympia, Ethereum Classic lacked an open, protocol-native mechanism to allocate sustainable funding.
Development funding was ad hoc, dependent on off-chain foundations and donors, with limited transparency and uneven accountability.

By combining:

• The non-inflationary, consensus-enforced revenue stream from ECIP-1111,
• The immutable, governance-isolated vault from ECIP-1112, and
• The standardized, auditable proposal process from ECIP-1114,

…Olympia DAO creates a permissionless, transparent, and reproducible framework for allocating protocol-level funds.

Key Design Goals

• Neutrality — No central entity controls access to funds; any address can submit proposals and participate in governance.
• Transparency — All proposals, votes, and disbursements are recorded immutably on-chain.
• Sustainability — Treasury inflows are tied to network usage (BASEFEE), not inflation or one-time grants.
• Security & Modularity — Governance logic and treasury logic are contractually isolated to reduce coupling and attack surface.
• Resilience — Broad participation and strict access controls reduce risk of capture or unilateral control.

Plutocracy Risk and Voting Design

Token-weighted governance can enable whales to dominate outcomes.
Olympia mitigates this risk with:

• Tokenless launch model
• Quorum and supermajority requirements
• Time-locked execution
• Support for migration to inclusive voting models (e.g., quadratic, reputation-based, or proof-of-contribution systems) via DAO vote

No governance token exists at launch, and any token proposal must be approved via an on-chain vote with no premine or privileged allocation.

DAO vs. Multisig Governance

Multisig-only control of protocol funds is rejected for the following reasons:

Olympia DAO enforces governance through hash-bound, time-locked proposals executed by the DAO’s authorized Treasury executor — never by a small group of signers acting alone.

Emergency Governance and Recovery

To address governance failure scenarios (e.g., voter apathy, contract error, or DAO capture), Olympia DAO supports an optional, time-limited emergency multisig:

• May be activated only by DAO vote
• Cannot spend Treasury funds or override outcomes without reauthorization
• Scope limited to pausing execution or initiating a governance reset
• Must be diverse in signer affiliation and subject to rotation

This ensures fail-safety without compromising decentralization.

Alignment with ECIP-1098 Lessons Learned

Past treasury proposals (e.g., ECIP-1098) faced criticism for:

• Centralized multisig control
• Inflationary funding via block reward changes
• Premine or privileged allocations
• Divergence from Proof-of-Work and immutability principles

Olympia DAO addresses all of these:

• No inflation — funded solely from EIP-1559 BASEFEE redirection (ECIP-1111)
• Immutable Treasury — no admin keys or upgrade paths (ECIP-1112)
• DAO-only execution — all disbursements governed on-chain
• Transparent lifecycle — standardized ECFP process (ECIP-1114) ensures every disbursement is bound to immutable metadata and publicly auditable

Related Work

Olympia DAO builds on established governance and treasury models from across the EVM ecosystem, adapting them to Ethereum Classic’s Proof-of-Work architecture, immutability principles, and the modular structure defined in ECIP-1111–ECIP-1114.

Protocol-Level Treasury Precedents

Several production EVM networks redirect endogenous protocol revenue (e.g., BASEFEE from EIP-1559 or sequencer fees) to on-chain treasuries managed by DAO governance:

• Ronin Network
  Redirects EIP-1559 BASEFEE to a DAO-controlled treasury for infrastructure, grants, and validator incentives.
  Ronin Treasury Contract

• Celo (Layer 1)
  Uses a Gas Fee Handler contract to route gas fees toward community funding and climate initiatives, with governance-managed allocation.
  Governance & Fee Handler

• Mantle (Layer 2)
  Routes sequencer fees to a MantleDAO-managed treasury, funding grants, developer tooling, and infrastructure.
  Mantle Treasury

• Polygon (Layer 2)
  Operates a Community Treasury as a protocol-funded mechanism to support long-term network growth, with governance via the Polygon Funding Proposals repository and DAO-controlled disbursements to ecosystem development, infrastructure, and community initiatives.
  Polygon Community Treasury

• OP Stack (Base, Optimism)
  Implements sequencer fee sharing with optional L2 governance control. While BASEFEE redirection is not native, the governance structures offer relevant design precedents.

• Arbitrum
  DAO-governed treasury funded by sequencer revenue; allocations decided through a standardized AIP process. Arbitrum Treasury

• Optimism (Retroactive Public Goods Funding)
  Bicameral governance with on-chain treasury allocations for public goods, funded from sequencer revenue. Optimism Atlas

Note: L2 examples (Arbitrum, Optimism, Mantle, OP Stack) primarily use sequencer revenue or token allocations rather than BASEFEE redirection, but their governance processes informed Olympia DAO’s permissionless and transparent model.

Governance Architecture References

Olympia DAO’s contract structure leverages and extends open-source, audited governance frameworks that have proven secure in high-value ecosystems:

• Aragon OSx — Modular DAO core supporting permission control, plugin execution modules, and upgradability.
• Compound Governor Bravo — Widely adopted governance model with configurable thresholds, voting delays, and quorum rules.
• OpenZeppelin Governor — Flexible governance library with pluggable voting strategies and timelock integration.
• Aave DAO Governance — Multi-layered governance with timelocks, delegated voting, and execution safeguards.
• ENS DAO Governance — Accessible governance model with delegated token voting and transparent proposal lifecycles.
• MakerDAO (MIPs Framework) — Structured improvement process with binding on-chain execution and domain expert review.
• Gitcoin DAO — Specializes in sybil-resistant, community-driven funding for open-source public goods.

Application to Ethereum Classic

Olympia DAO adapts these patterns to ETC by:

• Funding source — BASEFEE redirection at the consensus layer (ECIP-1111) into an immutable, governance-isolated vault (ECIP-1112) rather than token issuance or inflation.
• Execution path — All Treasury disbursements occur only via the standardized ECFP process (ECIP-1114), using hash-bound execution for integrity and replay protection.
• Governance isolation — The Treasury contract cannot approve or initiate spending; the DAO (ECIP-1113) cannot modify Treasury logic.
• Modular deployment — Supports staged activation, allowing Treasury accumulation before DAO governance is live.

This combination of precedent-informed architecture and ETC-specific constraints ensures Olympia DAO is technically sound, resilient, and aligned with Ethereum Classic’s principles of decentralization, immutability, and long-term sustainability.

Implementation

Olympia DAO SHALL be implemented as a modular suite of audited smart contracts deployed on Ethereum Classic.
It SHALL serve as the sole authorized executor for disbursing funds from the immutable Olympia Treasury (ECIP-1112), which accumulates BASEFEE revenue redirected at the consensus layer under ECIP-1111.
All disbursements MUST follow the Ethereum Classic Funding Proposal (ECFP) process (ECIP-1114) and use hash-bound execution for integrity and replay protection.

1. Governor Contract

The Governor contract SHALL manage the complete proposal lifecycle — submission, voting, queuing, and execution — using a modular, well-audited governance framework such as:

• OpenZeppelin Governor
• Compound Governor Bravo

Configurable parameters SHALL include:

• Proposal threshold
• Voting delay and voting period
• Quorum requirements
• Timelock duration before execution

// Example: Simple voting function (OpenZeppelin-based)
function castVote(uint256 proposalId, uint8 support) external {
    require(state(proposalId) == ProposalState.Active, "Voting closed");
    uint256 weight = getVotes(msg.sender, proposalSnapshot[proposalId]);
    require(weight > 0, "No voting power");
    _countVote(proposalId, msg.sender, support, weight);
}

2. Timelock Contract

A dedicated timelock SHALL:

• Enforce a mandatory delay between approval and execution
• Allow public review and potential mitigation before fund release
• Integrate with emergency governance modules if activated by DAO vote

3. Voting Mechanism

At launch:

• Olympia DAO operates without a governance token
• Uses a one-address-one-vote model to maximize inclusivity
• Sybil-resistance modules (e.g., BrightID, Gitcoin Passport, Proof of Humanity) MAY be added via DAO proposal
• Any tokenized or weighted model MUST be adopted via on-chain vote with no premine or privileged allocation

The following code demonstrates voting mechanics using OpenZeppelin’s GovernorVotes standard.

// --- BEGIN VOTING EXAMPLE ---
// This example uses OpenZeppelin’s GovernorVotes extension pattern.
// It demonstrates delegated voting and snapshot-based vote retrieval.
// https://docs.openzeppelin.com/contracts/4.x/governance

function delegate(address delegatee) public {
    _delegate(msg.sender, delegatee);
}

function getVotes(address account, uint256 blockNumber) public view returns (uint256) {
    return _checkpoints[account].getAtBlock(blockNumber);
}
// --- END VOTING EXAMPLE ---

4. Proposal Metadata Binding

Every proposal MUST include:

• An immutable, content-addressed metadata pointer (IPFS/Arweave CID)
• A proposal hash generated exactly per ECIP-1114’s tuple format: (ecfpId, recipient, amount, metadataCID, chainid)
• Matching hash values in both the Governor and Treasury at execution

Replay Protection:
Inclusion of block.chainid in the proposal hash serves as a domain separator, preventing replay of an approved proposal on forks, testnets, or other networks.
This is a mandatory safeguard and MUST be present in all proposal hash computations.

// Off-chain: Hash generation reference (used before proposal submission)
bytes32 proposalHash = keccak256(
    abi.encodePacked(
        ecfpId,        // Unique numeric ID
        recipient,     // Target address
        amount,        // ETC amount in wei
        metadataCID,   // IPFS or Arweave content hash for proposal docs
        block.chainid  // Replay protection
    )
);

// Example: Proposal creation with metadata hash binding
function submitProposal(
    address recipient,
    uint256 amount,
    string calldata metadataCID
) external returns (uint256) {
    uint256 proposalId = ++proposalCount;
    bytes32 hash = keccak256(abi.encodePacked(proposalId, recipient, amount, metadataCID, block.chainid));
    proposals[proposalId] = Proposal({
        recipient: recipient,
        amount: amount,
        metadataCID: metadataCID,
        hash: hash
    });
    emit ProposalSubmitted(proposalId, recipient, amount, metadataCID);
    return proposalId;
}

5. Treasury Integration

Execution of approved proposals MUST:

• Be initiated only by the DAO executor contract defined in ECIP-1112
• Call the Treasury’s release() or execute() function with the hash-bound parameters
• Revert if the Treasury detects an unauthorized caller, mismatched hash, or duplicate execution

Event Emission Standardization:
All successful disbursements MUST emit a ProposalExecuted event from both the Governor and the Treasury contracts.
This ensures full on-chain traceability for indexers, explorers, and auditors, consistent with the event schema defined in ECIP-1114.

The ProposalExecuted event SHALL use the following signature:

event ProposalExecuted(
    uint256 indexed ecfpId,
    bytes32 indexed proposalHash,
    address indexed recipient,
    uint256 amount,
    string metadataCID,
    uint256 timestamp
);

Both the Governor and Treasury MUST emit this event with identical parameter values upon execution, ensuring a complete and auditable record of every disbursement.

Validation Order:
Proposal hash validation (_isQueuedProposal and hash match checks) MUST occur before any state changes or fund transfers in the execution flow.
This prevents partial execution if validation fails and ensures atomicity of disbursements.

// --- BEGIN TIMELOCK EXECUTION EXAMPLE ---
// This function represents the final on-chain execution step after DAO approval.
// It is called by the Governor contract after the voting period and timelock delay.
//
// The function ensures:
// - Only proposals that have been successfully queued can be executed.
// - Disbursement occurs via the OlympiaTreasury contract, enforcing strict separation of concerns.
// - Both the Governor and Treasury emit a ProposalExecuted event for auditability.
//
// This pattern is derived from OpenZeppelin GovernorTimelockControl:
// https://docs.openzeppelin.com/contracts/4.x/api/governance#GovernorTimelockControl

function executeECFP(
    uint256 ecfpId,
    bytes32 proposalHash,
    address recipient,
    uint256 amount,
    string calldata metadataCID
) external {
    require(_isQueuedProposal(proposalHash), "Not queued or invalid");

    // Emit ProposalExecuted event from the Governor
    emit ProposalExecuted(
        ecfpId,
        proposalHash,
        recipient,
        amount,
        metadataCID,
        block.timestamp
    );

    // Call Treasury to release funds — Treasury will also emit ProposalExecuted
    OlympiaTreasury(treasuryAddress).release(proposalHash, recipient, amount);
}
// --- END TIMELOCK EXECUTION EXAMPLE ---

6. Child-DAO Support

The DAO MAY authorize Child-DAO modules for recurring, domain-specific budgets (e.g., Core-Geth maintenance, RPC operations).
All Child-DAO disbursements MUST:

• Pass through the main DAO governance and Treasury execution path
• Follow the ECFP lifecycle (ECIP-1114)
• Use the same hash-bound execution format

7. Audit & Testnet Rollout

Before mainnet deployment:

• All contracts SHALL undergo at least one independent third-party audit
• A complete deployment SHALL occur on Mordor Testnet to validate:
  • Proposal submission, voting, and execution flow
  • Hash-bound Treasury execution
  • Cross-client behavior verification for ECIP-1111–ECIP-1114 integration

8. Modular Deployment

Consistent with ECIP-1111’s modular activation strategy:

• The Olympia Treasury (ECIP-1112) may accumulate funds before ECIP-1113 deployment
• ECIP-1113 may be deployed after audits and community readiness
• No Treasury disbursements are possible until ECIP-1113 is active and authorized

This phased rollout ensures security, transparency, and operational readiness before governance control over protocol-level funds begins.

Legal Interface: Ethereum Classic DAO LLC

To facilitate fiat disbursements, contractor onboarding, and other off-chain administrative functions that cannot be executed purely on-chain, Olympia DAO SHALL utilize the Ethereum Classic DAO LLC — a Wyoming-registered legal entity operating under the Wyoming DAO LLC Act.

The LLC operates solely as a legal execution proxy for approved on-chain proposals and SHALL:

• Perform no evaluative, filtering, or discretionary role in funding decisions.
• Act only on binding instructions from successful Olympia DAO proposals executed via the Ethereum Classic Funding Proposal (ECFP) process (ECIP-1114).
• Remain fully subordinate to on-chain governance outcomes.

Permitted LLC activities include:

• Fiat currency conversion
• Contractor onboarding and KYC
• Tax reporting and legal compliance
• Disbursing fiat payments to service providers in accordance with DAO-approved proposals
• Issuing invoices, receipts, and administrative reports

Prohibited LLC activities include:

• Holding or controlling private keys to the Olympia Treasury (ECIP-1112)
• Modifying, vetoing, or reprioritizing approved proposals
• Mixing protocol-level Treasury funds with off-chain donor funds
• Executing payments not authorized by a successful DAO proposal

Transparency and Accountability

The LLC SHALL:

• Publish periodic public reports including:
  • Donation receipts
  • Contractor onboarding logs
  • Administrative cost summaries
  • Fiat conversion reports
• Maintain auditable records that map each off-chain action to its corresponding ECFP ID, proposal hash, and execution timestamp
• Use reporting formats compatible with on-chain event data from ECIP-1114 to ensure unified audit trails

Governance and Role Management

• LLC administrative roles (e.g., signers, officers) MAY be appointed, rotated, or removed via DAO vote.
• Any change in LLC structure or scope MUST be approved through an ECFP proposal.
• Role holders SHALL be publicly identified and subject to defined term limits where practical.

By isolating off-chain execution to a narrow, transparent, and revocable mandate, the LLC model preserves Ethereum Classic’s decentralization and credible neutrality while enabling compliance with legal and financial requirements that cannot be met entirely on-chain.

Decoupled Governance Deployment

Olympia DAO governance (ECIP-1113) MAY be deployed and activated independently of the Olympia Treasury (ECIP-1112) and the ECFP process (ECIP-1114).
This supports the modular activation strategy defined in ECIP-1111, allowing each component to be developed, audited, and deployed on its own timeline.

Pre-Governance Accumulation Phase

• Upon ECIP-1111 activation, the BASEFEE redirection logic routes all eligible transaction fees to the immutable Olympia Treasury (ECIP-1112).
• In this phase, the Treasury functions solely as a passive, governance-isolated vault.
  No disbursements are possible without an authorized DAO executor call.

Governance Activation Phase

• Olympia DAO (ECIP-1113) is deployed after security audits, testnet validation, and community onboarding.
• Once the DAO’s executor address is set in the Treasury contract, it becomes the only governance-authorized contract permitted to call the Treasury’s disbursement functions
• At activation, the ECFP process (ECIP-1114) becomes the exclusive pathway for all fund allocations.

Benefits of Decoupling

• Security — Reduces attack surface by allowing the Treasury to accumulate funds while governance contracts undergo thorough review.
• Operational Readiness — Gives the community time to learn the ECFP process and refine governance parameters before live fund control begins.
• Audit Scope Control — Allows for focused security audits of each ECIP component in isolation, then combined system testing.

Deployment Sequence

1. ECIP-1111 activation — EIP-1559 BASEFEE redirection begins.
2. ECIP-1112 deployment — Immutable Treasury contract deployed at a deterministic address; funds start accumulating.
3. ECIP-1113 deployment — Olympia DAO governance contracts deployed and tested on Mordor.
4. ECIP-1114 adoption — Standardized proposal process enabled for mainnet disbursements.
5. Governance handover — Treasury executor address set to the DAO, enabling controlled disbursement per ECFP approvals.

By decoupling deployment, Ethereum Classic ensures that sustainable protocol funding can begin accumulating immediately while governance systems are brought online in a deliberate, secure, and community-driven manner.

Backwards Compatibility

ECIP-1113 introduces no changes to Ethereum Classic’s consensus rules, transaction formats, opcodes, or EVM behavior.
Olympia DAO governance is implemented entirely at the application layer via smart contracts.

Protocol Impact

• Nodes that implement ECIP-1111 and ECIP-1112 but not ECIP-1113 will remain in consensus with the network, but:
  • They will be unable to process governance transactions or authorize Treasury disbursements.
  • They will still validate blocks containing governance-related transactions as long as consensus rules are met.
• Nodes that fail to implement ECIP-1111 (EIP-1559 activation and BASEFEE redirection) will fork from the canonical chain at the activation block.

Application-Layer Isolation

• All Olympia DAO functionality — proposal submission, voting, timelock queuing, and execution — operates independently of core protocol logic.
• Legacy smart contracts and dApps remain unaffected unless they choose to integrate with Olympia DAO governance or Treasury events.
• Interaction with Olympia DAO governance is entirely voluntary; network participants are not required to submit or vote on proposals to remain in consensus.

Treasury Execution Requirements

• To authorize disbursements, clients must support:
  • The immutable Olympia Treasury contract (ECIP-1112)
  • The Olympia DAO executor contract (ECIP-1113)
  • The ECFP execution path (ECIP-1114) with hash-bound proposal verification
• Without ECIP-1113 and ECIP-1114 support, clients cannot generate or sign governance transactions for Treasury execution, but they will still validate them.

State and Data Integrity

• Proposal data, voting records, and execution events are stored and processed entirely within smart contract state.
• No changes to prior blockchain state are introduced.
• Governance-layer state is fully deterministic and does not alter historical consensus data.

By keeping governance logic isolated from consensus mechanics, ECIP-1113 ensures that Ethereum Classic’s base protocol stability is preserved while enabling a robust, opt-in, on-chain funding system.

Governance Participation Protections

Olympia DAO governance parameters SHALL be designed to maximize inclusivity while mitigating risks of governance capture, low participation, and rushed decision-making.

Quorum and Approval Thresholds

• 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.
• Quorum and approval thresholds SHALL be adjustable only via on-chain DAO proposal and timelock execution.
• These values SHOULD be initially conservative to safeguard Treasury funds during early operation.

Voting Delay and Voting Period

• A voting delay SHALL be enforced between proposal submission and voting start, allowing community review and discussion.
• A minimum voting period SHALL be enforced to provide sufficient time for participation across global time zones.
• Both parameters MUST be DAO-configurable and subject to the same governance process as quorum/threshold adjustments.

Proposal Submission Requirements

• The DAO MAY implement optional participation thresholds for submitting proposals, such as:
  • Minimal ETC holding or refundable staking
  • Sybil-resistance verification (e.g., BrightID, Gitcoin Passport, Proof of Humanity)
• These requirements MUST remain permissionless, modular, and adjustable via governance vote.

Timelock Protection

• All approved proposals MUST enter a timelock queue before execution, preventing immediate disbursement.
• Timelock duration SHALL be long enough to enable review and potential protective action (e.g., emergency pause).
• Any timelock parameter change MUST follow the standard DAO governance process.

On-Chain Auditability

• All governance parameter changes — quorum, threshold, delays, periods, timelock duration — MUST be recorded on-chain.
• Event logs MUST be emitted for every parameter change, consistent with the event schema defined in ECIP-1114.
• Parameter change proposals MUST be hash-bound and executed via the same release() or execute() Treasury call path as funding proposals.

By standardizing these protections and tying them to the same on-chain processes defined in ECIP-1114, Olympia DAO ensures transparent, auditable, and resilient governance while preserving permissionless participation.

Security Considerations

Olympia DAO governance is designed to minimize attack surfaces while preserving permissionless participation and transparent fund management.
This section outlines the core security properties and mitigations that must be implemented.

1. Contract Immutability and Access Control

• Governance contracts SHOULD be upgradeable only via on-chain DAO proposals with quorum, supermajority approval, and timelock delay.
• The Olympia Treasury (ECIP-1112) SHALL remain immutable, with no proxy patterns, upgrade hooks, or owner privileges.
• Only the DAO executor contract MAY call the Treasury’s release() or execute() functions; all other calls MUST revert.

2. Hash-Bound Disbursement Integrity

• All disbursements MUST validate a proposal hash generated exactly per ECIP-1114’s tuple format: (ecfpId, recipient, amount, metadataCID, chainid).
• Proposal hash validation MUST occur before any state changes or transfers to prevent partial execution on failure.
• Each proposal hash MUST be executed only once; re-execution attempts MUST revert.

3. Replay Protection

• Inclusion of block.chainid in the proposal hash provides domain separation to prevent replay attacks across forks or testnets.
• Replay-protection logic MUST be implemented identically in Governor and Treasury contracts.

4. Governance Process Risks

• Low Participation — Mitigated by quorum thresholds, voting delays, and extended voting periods.
• Governance Capture — Reduced via tokenless launch, one-address-one-vote model, and optional Sybil-resistance mechanisms.
• Rushed Execution — Prevented by mandatory timelock delays between approval and execution.

5. Client and Network Safety

• Clients MUST validate that executed Treasury disbursements match DAO-approved parameters; discrepancies risk consensus divergence.
• Governance-layer logic MUST not modify consensus rules or block validation behavior.
• Cross-client testing on Mordor Testnet SHALL confirm identical execution behavior prior to mainnet deployment.

6. Event Logging and Auditability

• All significant governance actions — proposal submissions, votes, executions, parameter changes — MUST emit standardized events.
• ProposalExecuted events MUST be emitted from both Governor and Treasury contracts for every disbursement, with identical parameters.
• Off-chain tools and explorers SHOULD index these events to provide public audit trails.

By enforcing immutable Treasury logic (ECIP-1112), standardized proposal and execution flows (ECIP-1114), and replay-protected, hash-bound disbursements, Olympia DAO ensures secure, transparent, and tamper-resistant governance over Ethereum Classic’s protocol-level funding.

Related ECIPs in the Olympia Upgrade

ECIP-1113 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 Treasury and Governance Design

Olympia DAO’s governance framework (ECIP-1113) builds on established, audited patterns for managing protocol-level treasuries through decentralized, permissionless decision-making.
These precedents demonstrate that high-value ecosystem resources can be allocated transparently, securely, and sustainably.

Governance Architecture Precedents

These frameworks provide proven mechanisms for:

• Permissionless proposal submission
• Configurable quorum and approval thresholds
• Transparent on-chain voting and execution
• Upgradeable yet auditable governance logic

Treasury Governance Precedents

While ECIP-1113 focuses on governance, it operates in tandem with the Olympia Treasury (ECIP-1112), which draws on patterns from other EVM networks that route endogenous network revenue to immutable, community-governed vaults.
Notable examples include Ronin, Celo, Mantle, Polygon CDK, and Arbitrum, which demonstrate the viability of DAO-managed treasuries for funding public goods and infrastructure.

For a full list of treasury design precedents, see the “Related Work” section of ECIP-1112.

Summary

By combining:

• Governance best practices from proven DAO frameworks
• Treasury custody patterns from high-value, production EVM networks

…Olympia DAO ensures that Ethereum Classic’s protocol-level funding is managed with maximum transparency, security, and decentralization, while remaining adaptable to future governance innovations.