ECIP 1113: Olympia DAO Governance Framework

Simple Summary

This ECIP defines the on-chain governance framework for Olympia DAO, a decentralized smart contract system that governs fund disbursement from the Olympia Treasury (ECIP-1112). Olympia DAO enables transparent, permissionless proposal submission, token-based voting, and time-locked execution. It ensures protocol-level funding is allocated in alignment with Ethereum Classic’s principles of decentralization, neutrality, and sustainability.

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—a decentralized governance system for managing the Olympia Treasury (ECIP-1112). It facilitates permissionless proposal submission, token-based voting, and time-locked execution of approved disbursements.

Olympia DAO is implemented as a modular smart contract system comprising governance logic, voting mechanisms, and authorized interfaces to the Treasury contract. It operates without centralized control and enables open participation by ETC stakeholders through on-chain processes.

The DAO ensures that protocol-level funding — sourced from BASEFEE revenue redirected under ECIP-1112 — is allocated transparently, equitably, and in accordance with Ethereum Classic’s principles of decentralization, immutability, and neutrality.

Motivation

Historically, Ethereum Classic has depended on centralized foundations and private donors to fund protocol development, often through opaque processes with limited community oversight. This model introduced risks of gatekeeping, funding inconsistency, and strategic misalignment.

The activation of ECIP-1111 (EIP-1559) and ECIP-1112 (Olympia Treasury) establishes a native, protocol-level funding stream sourced from transaction BASEFEE revenue. To ensure these funds are allocated transparently and without reliance on trusted intermediaries, a decentralized governance mechanism is required.

Olympia DAO is designed to:

• Enable open, permissionless access to funding for development, infrastructure, and ecosystem maintenance.
• Replace centralized grant allocation with community-driven, auditable decision-making.
• Increase transparency, reduce capture risk, and foster stakeholder participation in protocol governance.

This transition from discretionary, off-chain funding to rule-based, on-chain governance strengthens ETC’s commitment to sovereignty, neutrality, and decentralization.

Olympia DAO adapts DAO-based governance of protocol-level revenue, as seen in EVM-compatible networks like Ronin, Celo, and Mantle, to Ethereum Classic’s Proof-of-Work architecture. It provides a non-inflationary, decentralized framework for managing development funds while preserving monetary immutability.

Specification

Governance Model

The Olympia DAO SHALL be implemented as a smart contract system deployed on Ethereum Classic. It SHALL govern the disbursement of funds from the Olympia Treasury contract (ECIP-1112) through transparent, permissionless, and rules-based on-chain processes.

The DAO MUST implement the following core components:

• Proposal Submission:
  Any address MAY submit a funding proposal through the DAO interface. Proposals MUST include:
  • Requested funding amount
  • Recipient address
  • Scope of work and deliverables
  • Disbursement schedule (e.g., milestones, vesting, or single transfer)

• Voting Mechanism:
  All proposals SHALL undergo an on-chain vote. The initial implementation MAY support stake-based or hybrid voting models (e.g., staked ETC, veOLY, or quadratic schemes). No governance token SHALL exist at launch. Any token issuance MUST be proposed through the DAO and ratified via on-chain vote, with no premine or privileged allocation.

• Tokenless Governance at Launch:
  Olympia DAO launches without a governance token. All governance functions — including proposal submission, voting, and execution — are modular and do not assume token issuance. This design ensures upgrade paths remain open while avoiding centralized token capture at genesis. See ECIP-1111 and ECIP-1112 for supporting rationale.

• Quorum and Approval Thresholds:
  • A minimum quorum MUST be enforced to validate a proposal.
  • A configurable approval threshold (e.g., ≥60% “yes” votes) MUST be met for execution.

• Execution Logic:
  Approved proposals SHALL be queued for execution via a time-locked executor contract, allowing time for public review or emergency response before disbursement.

• Treasury Access Control:
  The DAO contract MUST be the sole authorized caller of release() and execute() functions on the Olympia Treasury. All fund movements SHALL be governed exclusively by successful DAO proposals.

• On-Chain Transparency:
  All proposal metadata, voting records, and disbursement events MUST be logged on-chain and available for public inspection.

Contract Properties

• Minimal and Audited Architecture:
  DAO logic SHALL be based on modular frameworks (e.g., OpenZeppelin Governor, Compound Bravo) with strict boundaries and no arbitrary code execution (delegatecall is disallowed).

• Upgradeable Governance Logic:
  DAO contracts MAY be upgraded via on-chain proposal, subject to quorum, threshold, and timelock requirements.
  Treasury contracts SHALL remain immutable.

• No Admin Privileges:
  No centralized entity SHALL retain override capabilities or administrative control over the DAO or Treasury contracts.

Emergency Governance (Fallback Multisig)

A time-locked, community-elected multisignature wallet MAY be deployed as a failsafe governance backstop. This emergency multisig:

• SHALL be activated only via DAO vote.
• SHALL have authority only to:
  • Pause pending execution,
  • Quarantine proposals deemed malicious,
  • Initiate a governance reinitialization vote.
• SHALL NOT have authority to:
  • Submit new proposals,
  • Disburse funds,
  • Override approved DAO actions without explicit reauthorization.

This multisig MUST be:

• Publicly auditable,
• Time-limited (e.g., 30-day activation window),
• Revocable via DAO vote.

Signer Diversity and Accountability

To mitigate centralization risk in the off-chain administrative interface (i.e., the Ethereum Classic DAO LLC multisig), the following best practices SHOULD be adopted:

• Gradual onboarding of multisig signers with diverse affiliations and geographic distribution.
• Transparent disclosure of signer identities and roles.
• Optional term limits and scheduled re-election processes enforced via DAO vote.

These practices ensure public accountability and reduce the risk of governance capture or founder entrenchment.

A minimum of three multisig signers with distinct affiliations SHOULD be established at DAO launch, with additional signers onboarded gradually through community nomination and DAO approval. Signers SHALL be rotated periodically to mitigate long-term entrenchment. No signer SHALL possess unilateral authority or override privileges.

Child-DAO Modules for Critical Infrastructure

To ensure continuous support for critical infrastructure — such as Core-Geth maintenance, Mordor Testnet, RPC nodes, and explorer services — Olympia DAO MAY establish Child-DAO modules with delegated authority and scoped budgets.

These infrastructure-focused sub-DAOs enable public accountability, funding predictability, and specialization without compromising the integrity of main DAO governance.

Examples of Child-DAOs

• Client DAO
  • Maintains protocol clients (e.g., Core-Geth)
  • Reviews CVEs, performs upgrades, and ensures consensus compatibility
  • May include known contributors or rotating public stewards
  • Receives recurring budgets based on deliverables
• Infra DAO
  • Manages public RPC endpoints, explorer tools, indexers, and DevOps support
  • Coordinates with the ecosystem to reduce fragmentation and maintain uptime
  • May fund third-party services, fallback infra, and monitoring tools
• Security DAO (Optional)
  • Funds independent audits, formal verification, and testnet fuzzing
  • Grants bounty rewards for bug discovery and vulnerability disclosures

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 still pass through governance via structured ECFPs or scheduled approvals.
• Each Child-DAO MAY:
  • Propose a recurring budget
  • Publish periodic expenditure reports
  • Be subject to reauthorization, reduction, or sunset via main DAO vote

Benefits of the Child-DAO Model

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

Accountability and Transparency

• Child-DAOs MUST publish public dashboards or reports tied to deliverables.
• Proposals MAY include specific KPIs or milestone-based disbursement.
• All interactions between the Treasury and Child-DAOs MUST emit standardized events and maintain full on-chain auditability.

This approach balances decentralization with practical sustainability, ensuring Ethereum Classic can retain high-quality contributors and resilient infrastructure over the long term.

Rationale

Modular, Future-Ready Governance

The Olympia DAO is structured around modularity, auditability, and future extensibility:

• Separation of Concerns: Governance, treasury disbursement, and proposal execution are handled by independent smart contracts with clearly defined roles.
• Progressive Activation: The system supports a phased rollout, allowing conservative voting rules at launch and optional future modules.
• Governance Upgradeability: Voting logic, quorum thresholds, or governance tokens MAY be added or modified via DAO proposals, enabling adaptation as the ecosystem matures.

This approach minimizes complexity at deployment while preserving flexibility for future expansion.

Olympia DAO’s modular design aligns with ECIP-1111 and ECIP-1112 by enabling upgrades without altering protocol-layer components. This separation of governance logic from treasury logic ensures that voting models, proposal rules, and contract interfaces MAY evolve without affecting consensus security or client behavior.

Addressing Historical Governance Gaps

Historically, Ethereum Classic lacked an open, transparent process for allocating protocol-level funds. Development has often depended on opaque, discretionary funding from private donors or foundations—leading to misalignment, fragmentation, and limited accountability.

The Olympia DAO replaces this model with a permissionless, on-chain mechanism governed by the community. Protocol-level revenue is distributed to public goods based on transparent rules and stakeholder consensus.

Key Design Goals

• Neutrality:
  No central entity controls governance. Any participant MAY submit proposals and vote.

• Transparency:
  Proposals, votes, and disbursements are recorded on-chain and publicly auditable.

• Sustainability:
  Treasury inflows are tied to transaction activity, not inflation or donations.

• Security & Modularity:
  Governance and treasury logic are contractually isolated to reduce coupling and upgrade risk.

• Resilience:
  Open participation broadens contributor diversity and reduces capture risk.

Plutocracy Risk and Voting Design

Token-weighted voting systems face criticism for enabling large holders (“whales”) to dominate outcomes. Olympia DAO mitigates plutocracy risk through a modular voting architecture. While the initial system MAY use stake-based or delegated voting, the DAO framework supports migration to inclusive models, such as:

• Soulbound reputation tokens
• Quadratic voting
• Proof-of-Contribution attestations

• Elected governance councils

• No Premine or Predefined Token:
  No governance token exists at launch. Any token design or distribution MUST be proposed and approved via DAO vote.

This ensures governance remains adaptable, inclusive, and aligned with Ethereum Classic’s anti-plutocracy principles.

DAO vs. Multisig Governance

Multisignature wallets are sometimes proposed as alternatives to DAOs. However, they introduce significant centralization and transparency limitations:

Olympia DAO deliberately avoids multisig-controlled disbursement. Instead, it enforces governance through time-locked, community-approved proposals.

Emergency Governance and Fallback Recovery

To address governance failure scenarios (e.g., voter apathy, contract error, or DAO capture), the DAO includes an optional fallback mechanism:

• Emergency Multisig:
  A time-locked, community-elected multisig MAY be authorized—via DAO vote—to:
  • Pause execution of pending proposals
  • Quarantine malicious proposals
  • Trigger a DAO reset or recovery process
• Restricted Scope:
  This multisig:
  • CANNOT spend treasury funds
  • CANNOT override DAO outcomes without reauthorization
  • MUST operate under strict time limits (e.g., 30-day activation)
• Signer Diversity:
  Multisig signers SHOULD be rotated periodically via governance vote to prevent role entrenchment and enable broader participation.

This structure provides a safeguard against DAO stagnation while preserving decentralization and limiting power concentration.

Addressing ECIP-1098 Criticism

Concerns raised in prior treasury debates (e.g., ECIP-1098) included:

• Centralized multisig control
• Premine allocations
• Inflationary block reward funding
• Divergence from PoW and ETC ethos

Olympia DAO avoids these issues through:

• EIP-1559 BASEFEE redirection only — no inflation or block reward changes
• Immutable treasury contract — no admin keys or upgrade paths
• DAO-only access — all disbursements governed on-chain
• Transparent proposal lifecycle — fully auditable, permissionless participation

This structure enables sustainable, decentralized funding while remaining aligned with Ethereum Classic’s values of immutability, neutrality, and Proof-of-Work security.

Related Work

Olympia DAO draws from established governance systems and treasury frameworks adopted across the EVM ecosystem. These examples validate the architectural choices of Olympia in aligning with decentralized, transparent, and modular protocol funding mechanisms.

Protocol-Level Treasury Precedents

• Celo
  Redirects gas fees to a Gas Fee Handler contract, allocating revenue to the Carbon Offset Reserve and Community Treasury. Governance is executed via community proposals and voting.

• Ronin Network
  Utilizes tokenholder governance to manage an EIP-1559-style treasury. Treasury funds are directed toward Axie Infinity infrastructure and validator incentives.

• Mantle (MantleDAO)
  Collects sequencer fees and routes them to an on-chain treasury governed by a modular DAO. Emphasizes permissionless access and multi-phase proposal flows.

• Polygon CDK
  Offers a sovereign rollup framework that integrates EIP-1559 fee burning and optional DAO-managed treasuries. Supports native DAO plug-ins and treasury hooks for sovereign rollups.

• OP Stack (Base, Optimism)
  Implements sequencer fee sharing with optional L2 governance control. Does not natively redirect BASEFEE to DAO treasuries but allows custom fee-split mechanisms.

These implementations confirm that on-chain governance of protocol-level revenue is a scalable and effective model for funding decentralized ecosystems.

Governance Architecture References

Olympia DAO also builds upon open-source, audited governance frameworks that have demonstrated secure, transparent operation across multiple EVM chains:

• Aragon OSx (used by Lido, API3)
  A modular DAO system supporting fine-grained permission control, plugin-based execution modules, and DAO upgrades. Audited by Halborn and Code4rena.

• Compound Governor Bravo
  A second-generation governance model featuring configurable thresholds, voting delays, and quorum requirements. Widely used and formally verified.

• OpenZeppelin Governor
  A modular governance library with flexible voting strategies (ERC-20, veToken, NFT-based). Enables pluggable execution logic and is the basis of many audited DAO deployments.

• Aave DAO Governance Framework
  Implements Aave Improvement Proposals (AIPs) via a robust system of timelocks, delegated voting, and cross-chain relays. Manages one of the largest decentralized treasuries on Ethereum.

Application to Ethereum Classic

Olympia DAO adapts these frameworks to Ethereum Classic’s unique context:

• Operates on a Proof-of-Work chain with no L2 support or native governance precedent.
• Preserves immutability by ensuring the treasury contract is fixed and non-upgradable.
• Integrates with protocol-layer BASEFEE redirection (per ECIP-1112) rather than block reward inflation.
• Leverages time-locked execution and quorum rules to enforce transparency and resist capture.

The combined precedent of both financial and governance architectures establishes Olympia DAO as a technically sound and ecosystem-aligned approach to sustainable development funding on Ethereum Classic.

Implementation

The Olympia DAO will be implemented as a modular suite of smart contracts deployed on Ethereum Classic. These contracts govern the disbursement of funds from the Olympia Treasury (ECIP-1112) through transparent, on-chain governance. The implementation is composed of the following components:

1. Governor Contract

The core logic for proposal lifecycle management — including submission, voting, and execution — SHALL be implemented using modular and audited frameworks, including:

• OpenZeppelin Governor
• Compound Governor Bravo

Customizable 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 contract SHALL enforce a mandatory execution delay after proposals pass, enabling public review and intervention prior to disbursement. This contract:

• Buffers execution timing to mitigate rushed or malicious approvals
• Enables veto capabilities during the delay window (if supported by future governance modules)

3. Voting Mechanism

Voting MAY be implemented using one or more of the following mechanisms:

• ERC-20-compatible vote tokens (e.g., gETC, veOLY)
• Delegated or quadratic voting (subject to upgrade via governance)
• Voter snapshot logic based on the block at which the proposal is submitted

The initial implementation SHALL avoid pre-minting any governance token. Any future token issuance MUST be approved via DAO vote and remain compliant with anti-premine principles.

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#governor-votes

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 and Off-Chain Discussion

• Proposals SHALL include IPFS, Arweave, or similar metadata pointers to human-readable descriptions.
• Informal deliberation MAY occur on off-chain platforms (e.g., ECIP forums, Discord) prior to on-chain submission.

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

Upon passing the required vote and timelock delay, the DAO contract SHALL invoke either release() or execute() on the Olympia Treasury contract (ECIP-1112) to authorize fund disbursement.

All approved transactions MUST emit a ProposalExecuted event from both the DAO and Treasury contracts to ensure transparency and traceability.

All smart contracts SHALL be open-source and audited before mainnet deployment. A testnet deployment on Mordor will be used for validation of contract behavior, proposal flow, voting integrity, and treasury execution logic.

Initial governance parameters MAY be conservative by default and subject to revision via governance vote after deployment.

Treasury disbursements SHALL use deterministic proposal hashes for release validation. These hashes bind off-chain metadata (e.g., IPFS or Arweave CID) to an immutable execution payload. The DAO SHALL invoke release() or execute() on the Treasury only after the proposal hash and voting result are validated. This ensures BASEFEE revenue is disbursed according to verified DAO decisions with no discretionary modification.

Execution Timelock: On-Chain DAO Call

The DAO queues and executes proposals after a voting delay. Execution is programmatic and non-discretionary, ensuring the treasury cannot be manipulated or diverted.

// --- 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.
//
// This pattern is derived from OpenZeppelin GovernorTimelockControl:
// https://docs.openzeppelin.com/contracts/4.x/api/governance#GovernorTimelockControl

function executeECFP(
    bytes32 proposalHash,
    address recipient,
    uint256 amount
) external {
    require(_isQueuedProposal(proposalHash), "Not queued or invalid");
    OlympiaTreasury(treasuryAddress).release(proposalHash, recipient, amount);
}
// --- END TIMELOCK EXECUTION EXAMPLE ---

Proposal Hash Generation: Off-Chain Tooling

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

Legal Interface: Ethereum Classic DAO LLC

The DAO will interact with an external legal entity — Ethereum Classic DAO LLC, a Wyoming-registered DAO — to perform off-chain administrative tasks such as:

• Fiat conversion
• Contractor onboarding and KYC
• Tax reporting and legal compliance

This entity SHALL:

• Possess no authority over treasury funds or DAO decisions
• Act only as a legal execution proxy when authorized by on-chain DAO proposals
• Be publicly verifiable and governed by a limited administrative mandate

Private Donations

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

• SHALL be disclosed through financial transparency reports
• SHOULD be routed through on-chain mechanisms when feasible
• MAY support public goods (e.g., development, audits, infrastructure) but MUST NOT override DAO-approved allocations

A strict separation MUST be maintained between protocol-level disbursements and discretionary donor funding. Off-chain spending MAY NOT bypass DAO processes or compromise governance integrity.

This hybrid model preserves the DAO’s on-chain sovereignty while enabling off-chain legitimacy, tax compliance, and operational flexibility under a legally recognized framework.

Decoupled Governance Deployment

The Olympia DAO (ECIP-1113) is designed for modular deployment, allowing it to be implemented after the activation of ECIP-1111 (EIP-1559) and ECIP-1112 (Olympia Treasury).

This decoupled rollout provides the following benefits:

• Safe Accumulation Phase:
  The Olympia Treasury can begin accumulating BASEFEE revenue immediately upon activation of ECIP-1111, even before the DAO is live.

• Governance Readiness Buffer:
  The delayed deployment of ECIP-1113 provides time for:
  • Smart contract audits
  • Mordor testnet validation
  • Community onboarding and education
  • Selection or design of voting mechanisms

• No Premature Fund Access:
  Until the DAO is deployed and the governance interface is operational, no disbursement functions can be triggered. Treasury funds remain fully locked.

• Community Transparency:
  Stakeholders can monitor treasury inflows and contract behavior during the accumulation phase. All transactions are verifiable on-chain.

This phased deployment approach minimizes risk, improves community trust, and allows the DAO to launch with robust infrastructure and security guarantees.

Backwards Compatibility

The Olympia DAO governance system introduces a new smart contract layer on Ethereum Classic. It does not modify the virtual machine, consensus rules, or transaction formats. Therefore, it is fully backward-compatible with existing contracts, wallets, tooling, and infrastructure.

Participation in DAO governance is opt-in. Users who do not wish to vote, submit proposals, or interact with the treasury are not required to engage with the DAO contracts.

Key compatibility characteristics:

• No Impact on Legacy Contracts:
  Existing smart contracts and dApps operate without modification.

• DAO Isolation:
  The DAO contracts do not interfere with applications that do not explicitly interact with them.

• Treasury Access Control:
  The Olympia Treasury (ECIP-1112) disburses funds only through governance-approved proposals. No external or direct fund access is permitted.

• Client Divergence Warning:
  Nodes that do not upgrade to support ECIP-1111 and ECIP-1112 will diverge from consensus. However, nodes that upgrade but do not interact with DAO contracts remain fully compatible.

• State Integrity:
  Because the DAO exists entirely at the smart contract layer, it poses no risk to prior chain state or core protocol behavior.

Governance Participation Protections

To preserve decentralization and mitigate governance capture risks, the Olympia DAO includes the following design protections:

• Minimum Quorum and Supermajority Thresholds:
  Votes must meet predefined quorum and approval thresholds to pass, reducing the influence of minority coalitions.

• Vote Delegation Mechanisms:
  Token holders MAY delegate their voting power to trusted representatives via on-chain delegation. This enables broader participation and lowers barriers for non-technical or passive stakeholders.

• Modular Voting Systems:
  The DAO framework supports future integration of inclusive voting models, such as:
  • Quadratic voting
  • Soulbound token gating
  • Reputation-weighted or Proof-of-Contribution attestations
• Full On-Chain Transparency:
  All proposal metadata, voting records, and execution logs are publicly verifiable and immutably stored on-chain.

These features are intended to promote fairness, reduce plutocratic dominance, and ensure broad, accountable participation in Ethereum Classic governance.

Security Considerations

The Olympia DAO and Olympia Treasury contracts are designed with a strong emphasis on modularity, immutability, and formal verifiability. The following domains highlight critical security principles and mitigations.

1. Contract Architecture and Attack Surface Minimization

• Modular Separation:
  Governance and treasury contracts are deployed independently with scoped permissions. The DAO cannot modify or override the Treasury contract logic.

• Immutable Treasury Contract:
  The Olympia Treasury is fully immutable. It contains no upgrade mechanisms, admin keys, or pausable logic. Fund disbursements can only be triggered via authorized calls from the DAO executor using release() or execute().

• Governance Upgrade Path:
  DAO logic may be upgraded in the future, but only through an on-chain, quorum-approved, and time-locked proposal. The Treasury contract remains permanently immutable.

• No Emergency Withdrawals:
  There is no privileged logic or escape hatch for withdrawing funds outside the defined governance path—even in the case of emergencies or bugs.

2. Audit and Testing Strategy

• Formal Audits:
  All smart contracts will undergo at least one third-party security audit before mainnet deployment.

• Static Analysis:
  Formal verification and linting tools such as Slither, MythX, and other static analyzers will be used to detect known vulnerability classes.

• Testnet Simulation:
  Full system deployment will occur on Mordor Testnet to simulate proposal lifecycles, voting behavior, treasury calls, and DAO upgrades under live network conditions.

3. Governance Capture and Abuse Mitigation

• Mitigation of Vote Capture:
  On-chain governance is protected by:
  • Configurable quorum thresholds
  • Supermajority approval requirements
  • Time-locked execution buffers
  • Support for vote delegation
• Mitigation of Governance Inactivity:
  A fallback emergency multisig MAY be activated via DAO vote with strict limitations:
  • Authorized only to pause execution or trigger recovery proposals
  • Cannot disburse funds or override DAO decisions
  • Must be elected, time-limited, and publicly auditable
• Token Premine Restrictions:
  No governance token is deployed at launch. Any token issuance (e.g., for voting or delegation) MUST originate from an on-chain proposal and pass full community governance to comply with Ethereum Classic’s anti-premine philosophy.

4. Smart Contract Design Safety

• Delegatecall Avoidance:
  All DAO contracts SHALL avoid unsafe patterns such as delegatecall or dynamic code execution. Only direct, auditable function calls are used.

• Anti-Spam Mechanisms:
  Proposal submission MAY be gated by:
  • Minimum token stake
  • Submission cooldown timers
  • Conflict resolution for overlapping proposals
• Fund Disbursement Integrity:
  All disbursements are bound to approved proposals. Off-chain metadata (e.g., IPFS hashes) will be validated to ensure proposal integrity at execution time.

5. Client and Consensus Safety

• Client Validation of Governance Calls:
  Clients MUST validate that DAO-triggered disbursements match the encoded contents of approved proposals. Mismatches MAY trigger consensus divergence and should be treated as client misbehavior.

• Replay Protection:
  All proposals MUST include a domain separator (e.g., chainId) and proposal hash to prevent replay attacks across testnets or forks.

Summary

The Olympia DAO and Treasury architecture applies strict boundaries between components, disables all non-governance access paths, and adopts industry-standard audit and test practices. These safeguards mitigate both technical and governance-layer risks, enabling secure, decentralized treasury management on Ethereum Classic.

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