ECIP 1113: Olympia DAO Governance Framework Source

AuthorCody Burns, Chris Mercer
Discussions-Tohttps://github.com/orgs/ethereumclassic/discussions/530
StatusDraft
TypeMeta
Created2025-07-04
Requires 1112

Simple Summary

This ECIP defines the on-chain governance framework for Olympia DAO, the contract suite that authorizes and schedules the execution of approved actions affecting the Olympia Treasury (ECIP-1112).
Olympia DAO provides a modular governor, voting mechanism, and timelock executor. The DAO’s authorized execution path is the only route through which Treasury actions can be released.

Governance-layer upgrades — including voting-model selection, module replacement, and parameter adjustments — follow the Olympia Improvement Proposal (OIP) process defined in this ECIP.
Treasury disbursements are handled independently through the funding-proposal workflow specified in ECIP-1114.

Olympia launches without a governance token. Any future tokenization proposal must proceed through the OIP process and rely on the DAO’s standard approval and execution path.

Abstract

This ECIP specifies the architecture of Olympia DAO, the on-chain governance system that acts as the sole authorized executor for actions affecting the immutable Olympia Treasury (ECIP-1112). The DAO is composed of a modular Governor, a voting mechanism, and a timelock executor, together forming the exclusive path permitted to invoke the Treasury’s withdrawal interface.

Olympia DAO does not define the funding proposal lifecycle. Treasury disbursements originate from the standardized process in ECIP-1114, while governance-layer upgrades — such as voting-model changes, parameter adjustments, or module replacement — are processed through the Olympia Improvement Proposal (OIP) mechanism.

This ECIP establishes the governance-execution architecture and access-control model used to authorize Treasury actions. The system follows a modular Governor pattern functionally comparable to the audited OpenZeppelin Governor and Timelock design, while remaining fully isolated from consensus-layer logic (ECIP-1111), Treasury implementation details (ECIP-1112), and proposal-content requirements (ECIP-1114).

Motivation

ECIP-1112 defines an immutable Treasury with a restricted withdrawal interface.
To authorize any release of funds, an on-chain governance executor is required to verify approval, enforce execution delays, and perform the final call to the Treasury in a transparent and tamper-resistant manner.

A modular Governor architecture satisfies these requirements by providing:

  • a verifiable, on-chain voting mechanism,
  • a timelock that enforces delayed execution and public review, and
  • a single, authorized execution contract permitted to call the Treasury’s withdrawal function.

Using a Governor pattern functionally comparable to the audited OpenZeppelin Governor and Timelock design minimizes attack surface, ensures predictable behavior, and allows governance parameters to evolve without modifying the Treasury or consensus rules.

To maintain clear modular boundaries within the Olympia framework:

  • Treasury behavior is defined in ECIP-1112,
  • the funding-proposal lifecycle and metadata rules are defined in ECIP-1114, and
  • governance-layer upgrades — including voting-model changes, parameter updates, module replacement, or the creation of Child-DAO governance pipelines — proceed through the Olympia Improvement Proposal (OIP) process defined in this ECIP.

This separation enables Olympia DAO to evolve safely over time while preserving strict, auditable isolation between consensus logic, Treasury storage, proposal processing, and governance execution.

Specification

1. Governance Architecture

Olympia DAO SHALL be implemented as a modular, on-chain governance system deployed on Ethereum Classic.
Its sole protocol-level responsibility is to authorize withdrawals from the immutable Olympia Treasury (ECIP-1112) through a designated governance executor contract.

The governance system MUST include:

  • Governor Module — proposal lifecycle and vote tallying
  • Voting Module — computation of voting power
  • Timelock Module — mandatory execution delay
  • Executor Module — the only contract permitted to call Treasury withdrawal functions
  • Upgrade Module (OIP) — governance-layer evolution
  • Optional Modules — formally audited extensions (e.g., Child-DAOs, execution guards)

All modules MUST follow deterministic, auditable, non-privileged execution semantics.

1.1 Governor Module

The Governor module SHALL implement governance behavior functionally equivalent to the audited OpenZeppelin Governor model, including:

  • proposal lifecycle validation,
  • immutable snapshot-block voting,
  • one-vote-per-identity tallying,
  • enforcement of quorum and approval thresholds,
  • non-zero voting delay and voting period,
  • queueing approved proposals into the timelock, and
  • dispatching execution exclusively to the executor.

The Governor MAY be implemented in any language and MAY be customized, but MUST uphold all behavioral invariants of the OpenZeppelin Governor and SHALL NOT:

  • bypass the timelock,
  • permit execution without queueing, or
  • allow a proposal to execute more than once.

Voting delay and voting period MUST be strictly greater than zero and MAY only be modified through the OIP process.

1.2 Voting Module

The Voting Module SHALL define how voting power is computed and exposed to the Governor.

At launch, Olympia DAO SHALL implement a Sybil-resistant, ETC-domain-restricted, one-address-one-vote model where:

  • each voter is represented by a unique eligible address,
  • uniqueness and eligibility are provided by modular Sybil-resistance mechanisms (e.g., identity proofs or uniqueness attestations), and
  • eligibility MUST require ETC-domain participation, preventing cross-ecosystem governance capture.

Sybil-resistance and domain-restriction layers SHALL be external modules.
The Governor MUST treat these layers as pure interfaces, embedding no identity logic internally.

The Voting Module MAY be replaced only via OIP.
Any future token-based or stake-weighted model introduced via OIP MUST NOT include:

  • a premine,
  • privileged allocation, or
  • retroactive assignment outside OIP-approved parameters.

Any new voting-weight model MUST:

  • integrate without modifying Treasury logic,
  • preserve the Governor → Timelock → Executor → Treasury execution path,
  • maintain ETC-domain restriction, and
  • remain compliant with all invariants in this ECIP.

To prevent governance capture, the Sybil-resistance and domain-restriction modules SHALL enforce:

  • minimum eligibility/identity-aging periods,
  • ETC-specific contextual binding,
  • non-transferable voting rights,
  • participation-based activity requirements,
  • decentralized attestation pipelines, and
  • sustained ETC-ecosystem involvement.

No entity — including Child-DAOs, attestation providers, or external committees — MAY have unilateral authority over voter eligibility or OIP outcomes.

Child-DAO delegation MUST follow the same Sybil-resistance and ETC-domain rules and SHALL NOT introduce alternate eligibility pathways.

1.3 Timelock Module

The Timelock Module SHALL:

  • enforce a mandatory execution delay,
  • expose queue/execute functions consistent with OpenZeppelin’s TimelockController,
  • ensure queued actions CAN ONLY be executed after the delay,
  • prevent immediate execution, and
  • prevent re-execution of actions.

The timelock delay MUST be strictly greater than zero and MAY only be changed via OIP.

Only the Governor MAY queue operations.
Only the Timelock MAY authorize the executor to act.

If batching is supported, all batched actions MUST execute atomically or revert entirely, and all queued operations MUST be visible on-chain prior to execution.

1.4 Executor Module

The Executor Module SHALL:

  • be the sole authorized caller of Treasury withdrawal functions,
  • receive operations from the Timelock,
  • execute the final Treasury call, and
  • revert any call not originating from the Timelock.

The Executor MAY NOT:

  • initiate execution,
  • bypass the Timelock,
  • validate proposal content or metadata,
  • execute arbitrary calls beyond scheduled operations,
  • modify Governor state, or
  • schedule new governance actions.

No EOA, multisig, contract, or Child-DAO MAY bypass the executor.

2. Governance Upgrade Process (OIP)

All governance-layer evolution SHALL occur through the Olympia Improvement Proposal (OIP) process.
The OIP process SHALL be the exclusive pathway for modifying:

  • voting models,
  • governor parameters,
  • timelock parameters,
  • module implementations,
  • executor upgrades,
  • Child-DAO governance pipelines,
  • governance extensions, or
  • emergency-module behavior.

The OIP process MUST:

  • operate as standard on-chain Governor proposals,
  • follow the same voting → queueing → timelock → executor semantics as all governance actions, and
  • NEVER bypass the executor for Treasury actions.

OIPs MUST preserve all invariants defined in this ECIP, and OIPs MUST NOT:

  • modify ECIP-1112 Treasury immutability,
  • modify ECIP-1111 consensus rules,
  • set quorum/thresholds/delays to zero, or
  • disable voting.

Any non-compliant OIP SHALL be invalid.

3. Access Control & Treasury Interaction

The following SHALL be enforced:

  • The Treasury SHALL designate exactly one authorized caller — the executor.
  • Only actions processed by the Governor → Timelock → Executor pipeline MAY call Treasury withdrawal functions.
  • Unauthorized calls MUST revert.
  • Governance MUST NOT modify Treasury code, authorization rules, or immutability guarantees.

The executor address MAY ONLY be modified using procedures defined in ECIP-1112, not by governance defined in this ECIP.

Governance MUST treat Treasury functions as opaque and MUST NOT implement ECIP-1114 metadata logic.

4. Proposal Semantics (Architecture Only)

ECIP-1113 defines only the governance-execution architecture, not proposal content.

Thus:

  • Governance MUST expose interfaces for approving actions originating from ECIP-1114,
  • MUST NOT interpret proposal metadata or funding logic, and
  • SHALL operate strictly on action identifiers and execution payloads.

Funding lifecycle rules or proposal-content validation are out of scope for ECIP-1113.

5. Optional Governance Modules

5.1 Emergency Pause Module (Optional)

An Emergency Pause Module MAY be deployed via OIP.
Its scope SHALL be limited to:

  • pausing queued (but not executed) actions,
  • blocking timelock execution during emergencies, and
  • initiating recovery-oriented OIPs.

It SHALL NOT:

  • approve funding,
  • execute withdrawals,
  • modify Treasury logic, or
  • override governance outcomes.

Pauses MUST be time-limited and revocable by OIP.
The module MUST NOT permanently disable governance or Treasury execution.

5.2 Execution Guard Module (Optional)

An Execution Guard MAY:

  • enforce deterministic runtime checks (e.g., batch limits, argument validation),
  • reject malformed or invalid payloads.

It SHALL NOT:

  • interpret metadata,
  • inspect ECFP contents,
  • depend on off-chain data,
  • rely on multisig/committee decisions, or
  • introduce discretionary veto power.

All checks MUST be deterministic, rule-based, and publicly specified.

6. Child-DAO Governance Pipelines

Child-DAOs are governance modules, not funding mechanisms.
They MUST be registered and modified solely through OIP.

6.1 Definition

A Child-DAO is a subordinate Governor-compatible module created to manage domain-specific governance tasks.

Child-DAOs:

  • MAY propose actions to the main Governor,
  • MAY aggregate domain-specific voting,
  • MUST NOT call the Treasury, and
  • MUST route all actions through the main Governor → Timelock → Executor pipeline.
6.2 Creation & Modification

Child-DAOs:

  • MUST be created, modified, or dissolved exclusively through OIP,
  • MUST have strictly scoped authority,
  • SHALL NOT bypass the main Governor, and
  • MUST NOT control OIP outcomes.
6.3 Architectural Requirements

Child-DAOs MUST:

  • implement minimal Governor-equivalent logic,
  • delegate Treasury authorization to the main DAO,
  • emit transparent audit logs, and
  • avoid circular delegation paths.

Child-DAO participation, membership, or domain rules are NOT defined here and MAY be governed by OIP or operational policy.

7. Transparency Requirements

All governance modules MUST:

  • emit standardized events for proposal creation, queueing, execution, and upgrades,
  • preserve full on-chain auditability, and
  • enable indexers to reconstruct governance state solely from event logs.

Treasury-specific events remain defined in ECIP-1112 and ECIP-1114.

8. Prohibited Features

Governance contracts SHALL NOT:

  • use proxy upgrades,
  • use delegatecall for dynamic logic,
  • include owner-only functions,
  • include privileged multisigs or committees,
  • allow off-chain entities to unilaterally approve or veto actions,
  • read ECFP metadata,
  • encode funding schedules or milestones, or
  • modify Treasury state outside the executor’s authorized call.

Any implementation containing these features is non-compliant with ECIP-1113.

Rationale

Modular, Security-Oriented Governance Architecture

The Olympia governance system is structured to preserve strict separation between governance execution, consensus behavior, and Treasury logic.
ECIP-1113 defines only the governance-execution architecture; ECIP-1112 defines the immutable Treasury, and ECIP-1114 defines the proposal lifecycle and metadata semantics.
This separation ensures that governance cannot modify Treasury rules or consensus behavior, and that Treasury spending cannot occur without governance-authorized execution.

A modular architecture—composed of Governor, Voting Module, Timelock, and Executor—reduces attack surface and aligns with extensively audited governance frameworks.
Requiring behavior functionally equivalent to the OpenZeppelin Governor and Timelock model provides predictable, verifiable lifecycle semantics that have been validated across high-value EVM systems.

Deterministic Execution and Invariant Preservation

A mandatory Governor → Timelock → Executor pipeline enforces deterministic execution.
This prevents:

  • immediate or surprise execution,
  • bypassing governance approval,
  • modification of Treasury logic,
  • unilateral action by multisigs or EOAs, and
  • re-execution or conflicting execution of proposals.

These invariants ensure that proposal outcomes cannot be altered after voting concludes and that all execution paths remain transparent and auditable.

Sybil Resistance and Domain Restriction

One-address-one-vote governance is vulnerable to Sybil attacks, identity markets, infiltration, and cross-ecosystem governance raids.
ECIP-1113 therefore requires a modular Voting Module that incorporates:

  • externally implemented Sybil resistance,
  • ETC-domain participation requirements,
  • identity-aging and uniqueness enforcement,
  • non-transferable voting rights,
  • periodic participation requirements,
  • contextual ETC-specific attestation, and
  • decentralized attestation sources.

These requirements ensure governance reflects sustained, legitimate ETC participation rather than external coalitions or identity-leasing markets.

Upgradeability Through the OIP Process

Governance parameters and module implementations may need to evolve as new identity systems, voting models, or security techniques emerge.
To prevent unsafe or discretionary upgrades, ECIP-1113 restricts all governance-layer evolution to the Olympia Improvement Proposal (OIP) process.

This guarantees that upgrades:

  • follow the same voting, queueing, and timelock semantics as all governance actions,
  • cannot modify consensus rules or Treasury immutability,
  • cannot remove mandatory modules, and
  • cannot introduce prohibited features such as proxies, owner-keys, or discretionary veto authority.

OIP-restricted upgradeability enables controlled evolution while preserving all security invariants defined in this ECIP.

Protection Against Governance Capture and Privilege Escalation

The architecture mitigates multiple governance attack classes, including:

  • External Raid Attacks — prevented by domain-restricted identity layers.
  • Slow-Roll Infiltration — mitigated by identity-aging and activity requirements.
  • Identity-Leasing Markets — mitigated by non-transferable voting rights.
  • Cross-DAO Credential Reuse — prevented via ETC-specific attestation.
  • Child-DAO Capture — prevented by routing all authority through the main Governor.
  • Timelock Zeroing — prevented by requiring non-zero delays.
  • Executor Abuse — prevented through strict, narrow withdrawal permissions.
  • Emergency-Module Abuse — limited via narrow scope and time-bound operation.
  • Off-Chain Veto Committees — explicitly prohibited.

This ensures governance cannot be captured by external actors, privilege escalation, or informal off-chain power centers.

Justification for OpenZeppelin-Equivalent Architecture

OpenZeppelin’s Governor and Timelock patterns are among the most widely used and audited governance frameworks in the EVM ecosystem.
Requiring functional equivalence ensures:

  • predictable lifecycle semantics,
  • consistent edge-case handling,
  • minimized implementation risk,
  • strong audit coverage, and
  • compatibility with existing tooling and analysis pipelines.

This requirement preserves implementation flexibility while leveraging mature, validated governance semantics.

Role of Child-DAO Governance Pipelines

Child-DAOs enable domain-specific governance—such as client development or infrastructure coordination—without increasing main DAO proposal load or introducing centralizing actors.
They provide modular delegation while remaining subordinate to the main Governor.
Child-DAOs:

  • cannot initiate or execute Treasury withdrawals, and
  • cannot influence OIP outcomes beyond standard governance processes.

This supports scalable governance while preserving decentralization and accountability.

Alignment With Ethereum Classic Governance Principles

The architecture reflects Ethereum Classic’s foundational governance principles:

  • Immutability — Treasury code is immutable; governance cannot alter consensus.
  • Determinism — execution flows follow a single, non-bypassable pipeline.
  • Neutrality — no privileged actors or discretionary committees.
  • Security — no admin keys, no proxy upgrades, no owner-only functions.
  • Auditability — all governance actions are transparent, time-locked, and indexable.
  • Resilience — identity systems and modules are replaceable via OIP under strict invariants.

Together, these properties yield a governance system that is evolvable yet resistant to capture, modular yet secure, and permissionless yet protected against common DAO-level attacks.

Olympia DAO’s governance architecture draws from proven patterns in high-value EVM governance systems while applying constraints required by Ethereum Classic’s immutable Treasury (ECIP-1112) and modular OIP-based governance upgrade path.
The design incorporates established approaches to on-chain voting, timelock-controlled execution, and modular governance composition used across major Layer-1 and Layer-2 networks.

Governance Architecture Precedents

Several governance frameworks inform the modular Governor → Timelock → Executor pattern defined in this ECIP:

  • Compound Governor Bravo
    Defines a structured proposal lifecycle with immutable snapshots and parameterized governance.
    Its invariant-driven architecture informs Olympia’s requirements for deterministic thresholds, immutable snapshots, and mandatory proposal flow sequencing.

  • OpenZeppelin Governor
    A widely audited, modular governance suite with a dedicated Timelock Controller and pluggable voting mechanisms.
    Olympia DAO requires functional equivalence to its behavioral invariants to ensure predictable, verifiable execution flows.

  • Aragon OSx
    Demonstrates a plugin-based governance architecture with scoped permission modules and delegated authority.
    Olympia adopts this modularity for optional extensions (Child-DAOs, guards) while enforcing stricter anti-capture constraints and mandatory executor isolation.

  • Aave Governance
    Utilizes layered timelocks, vote delegation, and strict separation between governance contracts and protocol logic.
    This separation inspires Olympia’s prohibition on discretionary executors and external veto mechanisms.

  • MakerDAO (MIPs Framework)
    Provides a formal improvement process with domain-specific modules and timelocked execution.
    The Olympia Improvement Proposal (OIP) process follows similar principles: controlled upgradeability with deterministic, time-delayed execution.

  • ENS DAO Governance
    Employs a minimal, predictable, and transparent governance contract surface area.
    This aligns with Olympia’s emphasis on deterministic proposal lifecycles and standardized event logs.

  • Gitcoin Passport / Sybil-Resistance Frameworks
    Demonstrate modular identity-layer voting systems grounded in external attestations.
    Olympia adapts these concepts to support ETC-domain-restricted, Sybil-resistant voting with additional anti-capture safeguards.

Executor & Timelock Precedents

Deterministic, timelock-controlled execution is a well-established foundation of secure DAO governance:

  • Uniswap Governor + Timelock
    Enforces strict separation between governance logic and execution.
    Olympia adopts this separation and strengthens it by requiring executor exclusivity for Treasury withdrawals.

  • Yearn, Synthetix, and Lido Timelock Models
    Highlight the importance of non-zero delays, pre-execution transparency, and replay protection.
    Olympia incorporates mandatory delay invariants and transparent, atomic batch semantics.

These precedents collectively demonstrate the necessity of executor isolation, mandatory delay windows, and deterministic, replay-protected execution—core requirements of this ECIP.

Identity & Domain-Restricted Governance Precedents

Multiple governance ecosystems employ identity-layer or domain-restricted voting to mitigate capture:

  • Gitcoin Passport — multi-attestation Sybil resistance
  • Optimism Citizenship — domain-restricted participation
  • BrightID / Proof-of-Personhood — unique identity verification
  • POAP-based voting — contextual participation requirements

Olympia extends these concepts by combining external attestations with:

  • ETC-domain contextual participation,
  • identity-aging requirements,
  • non-transferable voting rights, and
  • periodic participation thresholds.

This combination is tailored to mitigate both rapid-coordination attacks and slow-roll infiltration—risks relevant to a Proof-of-Work L1 with a protocol-level Treasury.

Application to Ethereum Classic

Olympia DAO adapts the above governance models to the constraints inherent to Ethereum Classic:

  • Executor Isolation
    Only a designated executor may call the Treasury.
    Olympia strengthens this model by prohibiting proxy upgrades, arbitrary executor calls, or owner-privileged override paths.

  • Immutable Treasury Interaction
    Unlike many upgradeable treasuries, the Olympia Treasury cannot be replaced or modified.
    This necessitates a strictly enforced Governor → Timelock → Executor pipeline.

  • Modular Upgradeability Through OIP
    Governance must remain evolvable, but only through deterministic, on-chain improvement processes.
    This parallels MakerDAO’s MIPs and Aragon’s plugin architecture, with stricter anti-capture constraints.

  • Domain-Restricted, Sybil-Resistant Voting
    ETC requires defenses against cross-ecosystem governance raids.
    Olympia incorporates identity modules and contextual participation rules inspired by Gitcoin and Optimism, with additional layers suitable for an L1 Treasury.

These adaptations yield a governance architecture aligned with Ethereum Classic’s principles of immutability, neutrality, determinism, and verifiable on-chain guarantees, while resisting common DAO-level governance attacks.

Implementation

Olympia DAO SHALL be implemented as a modular suite of audited smart contracts deployed on Ethereum Classic.
In accordance with this ECIP, the governance system:

  • manages proposal lifecycle, voting, and scheduling,
  • enforces a mandatory Governor → Timelock → Executor execution pipeline, and
  • authorizes calls to the immutable Olympia Treasury (ECIP-1112) via a single, restricted Executor contract.

All interaction with proposal content, metadata, and funding semantics (including the ECFP process defined in ECIP-1114) SHALL occur outside the governance contracts. The governance system operates only on action identifiers and execution payloads defined at the interface boundary.

1. Governor Contract

The Governor contract SHALL be implemented using a governance framework functionally equivalent to the audited OpenZeppelin Governor pattern. It MUST:

  • manage the complete proposal lifecycle (creation, state transitions, queueing, execution),
  • record immutable snapshot state for voting power at the proposal’s snapshot block,
  • enforce quorum, approval thresholds, voting delay, and voting period as on-chain parameters,
  • dispatch approved actions exclusively to the Timelock Module, and
  • source all voting power from a dedicated Voting Module (see §2), not from token balances or off-chain authorities.

The Governor MUST NOT include Treasury logic, funding rules, ECFP rules, metadata parsing, or BASEFEE mechanics.
These belong to ECIP-1112 (Treasury) and ECIP-1114 (Funding Proposal System).

Implementations SHOULD reuse well-reviewed governance libraries (e.g., OpenZeppelin Governor) but MAY diverge from specific inheritance structures as long as required invariants are preserved.

The following is an illustrative, non-normative example.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

// Illustrative, non-normative example Governor that integrates an
// external Voting Module and OpenZeppelin-style Governor + Timelock
// semantics. It is NOT a complete reference implementation.
//
// In production, this contract MUST be audited and wired into the
// Timelock and Executor modules as defined elsewhere in ECIP-1113.

import "@openzeppelin/contracts/governance/Governor.sol";
import "@openzeppelin/contracts/governance/extensions/GovernorSettings.sol";
import "@openzeppelin/contracts/governance/extensions/GovernorCountingSimple.sol";
import "@openzeppelin/contracts/governance/extensions/GovernorTimelockControl.sol";

interface IOlympiaVotingModule {
    function votingPower(address voter, uint256 snapshotBlock)
        external
        view
        returns (uint256);
}

contract OlympiaGovernor is
    Governor,
    GovernorSettings,
    GovernorCountingSimple,
    GovernorTimelockControl
{
    IOlympiaVotingModule public votingModule;
    uint256 private _quorumVotes;

    constructor(
        IOlympiaVotingModule _votingModule,
        TimelockController timelock,
        uint256 initialVotingDelay,      // in blocks
        uint256 initialVotingPeriod,     // in blocks
        uint256 initialProposalThreshold,
        uint256 initialQuorumVotes       // absolute quorum in votes
    )
        Governor("OlympiaGovernor")
        GovernorSettings(
            initialVotingDelay,
            initialVotingPeriod,
            initialProposalThreshold
        )
        GovernorTimelockControl(timelock)
    {
        require(address(_votingModule) != address(0), "OlympiaGovernor: voting module required");
        require(address(timelock) != address(0), "OlympiaGovernor: timelock required");
        require(initialQuorumVotes > 0, "OlympiaGovernor: quorum must be > 0");

        votingModule = _votingModule;
        _quorumVotes = initialQuorumVotes;
    }

    /// @notice Quorum is expressed as an absolute number of votes.
    function quorum(uint256 /* blockNumber */)
        public
        view
        override
        returns (uint256)
    {
        return _quorumVotes;
    }

    /// @notice All voting power is sourced from the external Voting Module.
    function _getVotes(
        address account,
        uint256 blockNumber,
        bytes memory /* params */
    )
        internal
        view
        override
        returns (uint256)
    {
        return votingModule.votingPower(account, blockNumber);
    }

    /// @notice Governance-only update of core parameters (via OIP path).
    function updateGovernanceParams(
        uint256 newVotingDelay,
        uint256 newVotingPeriod,
        uint256 newProposalThreshold,
        uint256 newQuorumVotes
    ) external onlyGovernance {
        require(newVotingDelay > 0, "OlympiaGovernor: delay must be > 0");
        require(newVotingPeriod > 0, "OlympiaGovernor: period must be > 0");
        require(newQuorumVotes > 0, "OlympiaGovernor: quorum must be > 0");

        _setVotingDelay(newVotingDelay);
        _setVotingPeriod(newVotingPeriod);
        _setProposalThreshold(newProposalThreshold);
        _quorumVotes = newQuorumVotes;
    }

    /// @notice Governance-only migration of the Voting Module (via OIP).
    function updateVotingModule(IOlympiaVotingModule newModule)
        external
        onlyGovernance
    {
        require(address(newModule) != address(0), "OlympiaGovernor: module cannot be zero");
        votingModule = newModule;
    }

    // Required overrides for multiple inheritance.

    function state(uint256 proposalId)
        public
        view
        override(Governor, GovernorTimelockControl)
        returns (ProposalState)
    {
        return super.state(proposalId);
    }

    function _execute(
        uint256 proposalId,
        address[] memory targets,
        uint256[] memory values,
        bytes[] memory calldatas,
        bytes32 descriptionHash
    ) internal override(Governor, GovernorTimelockControl) {
        super._execute(proposalId, targets, values, calldatas, descriptionHash);
    }

    function _cancel(
        address[] memory targets,
        uint256[] memory values,
        bytes[] memory calldatas,
        bytes32 descriptionHash
    )
        internal
        override(Governor, GovernorTimelockControl)
        returns (uint256)
    {
        return super._cancel(targets, values, calldatas, descriptionHash);
    }

    function _executor()
        internal
        view
        override(Governor, GovernorTimelockControl)
        returns (address)
    {
        return super._executor();
    }

    function supportsInterface(bytes4 interfaceId)
        public
        view
        override(Governor, GovernorTimelockControl)
        returns (bool)
    {
        return super.supportsInterface(interfaceId);
    }
}

Governance parameters MUST be stored in contract state and MUST only be modifiable through OIP-approved governance actions.
In the intended example, this is enforced via the onlyGovernance modifier, ensuring all parameter changes—including migration to a new Voting Module—pass through the Governor → Timelock → Executor pipeline.

2. Voting Module and Identity Integration

The Voting Module SHALL be implemented as a distinct contract (or set of contracts) that provides all voting power data to the Governor.
The Governor MUST NOT derive voting power from token balances, multisig attestations, or off-chain authority.
All voting power MUST be obtained through calls to the Voting Module.

At initial deployment, the Voting Module MUST implement:

  • Sybil resistance via a one-address-one-vote model,
  • ETC-domain restriction, ensuring that eligibility is derived solely from state observable on Ethereum Classic L1 and not from external chains, bridges, L2 systems, or unverifiable off-chain data,
  • snapshot determinism, where voting power is computed solely from state available at the proposal’s snapshot block, and
  • identity or activity requirements (e.g., minimum account age, recent activity window, or attestation-based eligibility).

Eligibility MUST be proposal-agnostic; the Voting Module MUST NOT introduce proposal-specific or content-dependent filtering conditions.

Voting power MUST NOT be transferable, delegatable, or assignable to any other address.

All examples in this section are illustrative and MUST NOT be interpreted as normative reference implementations.

The Voting Module MAY consume attestations from one or more decentralized identity systems, provided that:

  • no identity provider may veto or approve proposals,
  • no single identity oracle, multisig, or off-chain group may control eligibility,
  • attestations MUST be verifiable on-chain without trusting external signatures, and
  • replacing, upgrading, or removing an identity provider MUST occur only through the OIP process.

The Voting Module MUST expose a minimal interface for the Governor, at minimum providing proposal-agnostic votingPower and isEligible view functions.

The following is an illustrative, non-normative example.

// Illustrative, non-normative voting module interface.
// Olympia Governor implementations read voting power and eligibility
// from modules conforming to this interface.
pragma solidity ^0.8.20;

interface IOlympiaVotingModule {
    /// @notice Returns voting power for `voter` at `snapshotBlock`.
    /// Implementations MUST be snapshot-deterministic.
    function votingPower(address voter, uint256 snapshotBlock)
        external
        view
        returns (uint256);

    /// @notice Returns true if `voter` is eligible to participate in
    /// governance at `snapshotBlock`. Implementations MAY apply
    /// age/activity/identity rules but MUST be deterministic.
    function isEligible(address voter, uint256 snapshotBlock)
        external
        view
        returns (bool);
}
Example: One-Address-One-Vote Eligibility Module

An illustrative module MAY enforce:

  • one-address-one-vote,
  • minimum account age,
  • recent activity requirements,
  • full snapshot determinism, and
  • no delegation, no ownership, and no privileged identity authority.

The following is an illustrative, non-normative example.

// Illustrative, non-normative one-address-one-vote Voting Module.
// This example enforces simple age and activity-based eligibility and
// returns either 0 or 1 unit of voting power per address.
pragma solidity ^0.8.20;

interface IOlympiaVotingModule {
    function votingPower(address voter, uint256 snapshotBlock)
        external
        view
        returns (uint256);

    function isEligible(address voter, uint256 snapshotBlock)
        external
        view
        returns (bool);
}

contract OneAddressOneVoteModule is IOlympiaVotingModule {
    // Example constants; real values SHOULD be tuned by OIP.
    uint256 public constant MIN_ACCOUNT_AGE = 200_000;    // ~1 month (example)
    uint256 public constant MIN_ACTIVITY_WINDOW = 50_000; // recent activity window

    mapping(address => uint256) public firstSeenBlock;
    mapping(address => uint256) public lastActiveBlock;

    event ActivityRecorded(address indexed user, uint256 blockNumber);

    /// @notice Called by integration points (e.g., frontends, adapters)
    /// to record that `user` has performed some governance-related activity.
    function recordActivity(address user) external {
        if (firstSeenBlock[user] == 0) {
            firstSeenBlock[user] = block.number;
        }
        lastActiveBlock[user] = block.number;
        emit ActivityRecorded(user, block.number);
    }

    function votingPower(address voter, uint256 snapshotBlock)
        external
        view
        override
        returns (uint256)
    {
        return isEligible(voter, snapshotBlock) ? 1 : 0;
    }

    function isEligible(address voter, uint256 snapshotBlock)
        public
        view
        override
        returns (bool)
    {
        uint256 seen = firstSeenBlock[voter];
        if (seen == 0) return false;
        if (seen > snapshotBlock) return false;

        // Enforce minimum account age at the snapshot block.
        if (snapshotBlock < seen + MIN_ACCOUNT_AGE) return false;

        uint256 lastActive = lastActiveBlock[voter];
        if (lastActive == 0) return false;

        // Require activity within the configured window before snapshot.
        if (lastActive + MIN_ACTIVITY_WINDOW < snapshotBlock) return false;

        return true;
    }
}
Upgradability and Identity Migration

Changes to any of the following:

  • account age rules,
  • activity requirements,
  • attestation providers,
  • decentralized identity mechanisms, or
  • vote weighting models

MUST occur solely through the Olympia Improvement Proposal (OIP) process.

Identity systems MAY evolve over time, but no identity provider or attestation mechanism may introduce veto power, proposal filtering, or privileged approval authority.

The Governor MUST NOT contain hardcoded identity logic and MUST NOT depend on any particular identity provider.

The Voting Module MUST remain replaceable via an OIP-governed update (e.g., an updateVotingModule() function in the Governor as defined in §1), ensuring full modularity and future extensibility.

3. Timelock Contract

The Timelock Module SHALL be implemented using a pattern functionally equivalent to OpenZeppelin’s TimelockController. It MUST:

  • accept scheduled operations from the Governor,
  • enforce a strictly positive, configurable delay before execution,
  • expose queue and execute functions callable only by the Governor (for queuing) and the Executor (for execution), and
  • ensure that completed, cancelled, or expired operations cannot be re-executed.

No governance action MAY bypass the Timelock. The Timelock MUST NOT expose any owner, admin, guardian, or emergency-bypass roles that can alter queued operations or execute transactions outside the standard Governor → Timelock → Executor pipeline.

If batched operations are supported, the implementation MUST:

  • execute all operations atomically or revert in full, and
  • publish the complete batch contents on-chain prior to execution.

The following is an illustrative, non-normative example.

// Illustrative, non-normative Timelock example.
// Enforces a strictly positive, immutable delay and restricts:
// - queue() to the Governor
// - execute() to the Executor
//
// This contract does NOT implement batching, cancellation windows,
// or role rotation; those concerns are left to production designs.
pragma solidity ^0.8.20;

interface IOlympiaTimelock {
    function queue(
        address target,
        uint256 value,
        bytes calldata data
    ) external returns (bytes32 operationId);

    function execute(
        address target,
        uint256 value,
        bytes calldata data
    ) external returns (bytes memory);

    function delay() external view returns (uint256);
}

contract OlympiaTimelock is IOlympiaTimelock {
    uint256 private _delay;
    address public immutable governor;
    address public immutable executor;

    mapping(bytes32 => uint256) public eta;

    event Queued(
        bytes32 indexed operationId,
        address indexed target,
        uint256 value,
        bytes data,
        uint256 executeAfter
    );

    event Executed(
        bytes32 indexed operationId,
        address indexed target,
        uint256 value,
        bytes data,
        bytes result
    );

    constructor(uint256 initialDelay, address _governor, address _executor) {
        require(initialDelay > 0, "Timelock: delay must be > 0");
        require(_governor != address(0), "Timelock: governor required");
        require(_executor != address(0), "Timelock: executor required");

        _delay = initialDelay;
        governor = _governor;
        executor = _executor;
    }

    function delay() external view override returns (uint256) {
        return _delay;
    }

    /// @notice Queue an operation; callable only by the Governor.
    function queue(
        address target,
        uint256 value,
        bytes calldata data
    ) external override returns (bytes32 operationId) {
        require(msg.sender == governor, "Timelock: only governor");
        operationId = keccak256(abi.encode(target, value, data));
        require(eta[operationId] == 0, "Timelock: already queued");

        uint256 executeAfter = block.timestamp + _delay;
        eta[operationId] = executeAfter;

        emit Queued(operationId, target, value, data, executeAfter);
    }

    /// @notice Execute an operation after the delay; callable only by the Executor.
    function execute(
        address target,
        uint256 value,
        bytes calldata data
    ) external override returns (bytes memory) {
        require(msg.sender == executor, "Timelock: only executor");

        bytes32 operationId = keccak256(abi.encode(target, value, data));
        uint256 readyTime = eta[operationId];

        require(readyTime != 0, "Timelock: not queued");
        require(block.timestamp >= readyTime, "Timelock: not ready");

        delete eta[operationId];

        (bool ok, bytes memory out) = target.call{value: value}(data);
        require(ok, "Timelock: execution failed");

        emit Executed(operationId, target, value, data, out);
        return out;
    }
}

In production deployments, Timelock parameters (including the delay) MUST be modifiable only via the full Governor → Timelock → Executor pipeline; no instantaneous or retroactive changes to execution latency are possible. The simplified example above uses an immutable delay for brevity and does not show the OIP-controlled update path.

4. Executor Contract

The Executor contract SHALL be implemented as a minimal, deterministic execution module that:

  • can only execute operations that have been previously scheduled and unlocked by the Timelock,
  • can only call the Treasury’s restricted withdrawal functions and other explicitly allowed, OIP-approved targets, and
  • MUST revert any execution attempt that is not authorized by the Timelock.

The Executor MUST:

  • trust a single Timelock address as its sole authority for execution authorization,
  • perform calls exactly as specified by the Timelock (target, value, calldata) without modification, and
  • emit events for all successful executions to enable full on-chain auditability.

The Executor MUST NOT:

  • schedule governance actions,
  • alter proposal state,
  • interpret proposal metadata,
  • perform arbitrary calls outside the set of operations provided by the Timelock,
  • use delegatecall to execute arbitrary logic, or
  • expose any owner, admin, or emergency-bypass role.

If batching is supported via future OIP-approved Timelock extensions, the Executor MUST execute all batched operations atomically and MUST NOT introduce any batching functionality on its own.

The Executor SHALL be a pure forwarding module: it MUST NOT contain business logic, Treasury accounting logic, or funding rules of any kind. The Executor MUST NOT perform state-changing logic before or after the external call that could introduce reentrancy risk.

The following is an illustrative, non-normative example of a module whose parameters are only updateable via an on-chain call from the governance Executor (the endpoint of the Governor → Timelock → Executor pipeline).

// Illustrative, non-normative Executor example.
// The Executor is a pure forwarding module:
// - It ONLY accepts calls from the Timelock.
// - It forwards (target, value, data) exactly as provided.
// - It does not encode business logic, Treasury rules, or metadata checks.
pragma solidity ^0.8.20;

interface IOlympiaExecutor {
    function execute(
        address target,
        uint256 value,
        bytes calldata data
    ) external returns (bytes memory);
}

contract OlympiaExecutor is IOlympiaExecutor {
    address public immutable timelock;

    event Executed(
        address indexed target,
        uint256 value,
        bytes data,
        bytes result
    );

    constructor(address _timelock) {
        require(_timelock != address(0), "Executor: timelock required");
        timelock = _timelock;
    }

    /// @notice Only the Timelock may trigger execution.
    function execute(
        address target,
        uint256 value,
        bytes calldata data
    ) external override returns (bytes memory) {
        require(msg.sender == timelock, "Executor: unauthorized caller");
        require(target != address(0), "Executor: invalid target");

        (bool ok, bytes memory result) = target.call{value: value}(data);
        require(ok, "Executor: call failed");

        emit Executed(target, value, data, result);
        return result;
    }
}

The Executor address SHALL be hardcoded into the Treasury (ECIP-1112) according to ECIP-1112’s deployment rules and MUST NOT be changeable by any governance action in ECIP-1113. No OIP, upgrade, or external contract MAY modify the Executor reference inside the Treasury once deployed. The Treasury MUST reject any call to its withdrawal functions that does not originate from this Executor.

5. OIP Implementation (Governance Upgrades)

The Olympia Improvement Proposal (OIP) process SHALL be implemented as a subset of Governor-managed proposals whose execution payloads modify governance parameters or module references, rather than initiating Treasury disbursements.
OIPs are strictly limited to governance-layer configuration changes and MUST NOT perform any action that alters consensus behavior, Treasury mechanics, or funds.

All OIP proposals MUST be processed exclusively through the standard lifecycle:

Governor → Timelock → Executor → (Authorized Module)

No contract, module, or off-chain actor MAY bypass this sequence.

Implementation guidelines:

  • OIP proposals SHOULD be tagged or categorized within the Governor for on-chain indexing and UX clarity.
  • OIP proposals MUST follow the same voting delay, voting period, quorum, and Timelock delay rules as all other governance proposals.
  • Execution payloads for OIPs MUST update only:
    • governance parameters (quorum, thresholds, voting delay, voting period, Timelock delay),
    • references to Voting Modules or identity systems,
    • references to Timelock or Executor modules (if migrated via OIP), or
    • optional module configuration (Child-DAOs, Execution Guard, Emergency Pause).

The implementation MUST enforce that OIP proposals CANNOT:

  • modify or override consensus-layer rules (ECIP-1111),
  • modify or redeploy the Treasury contract (ECIP-1112),
  • modify the funding proposal lifecycle or metadata rules defined in ECIP-1114,
  • upgrade or replace contracts via delegatecall, proxy patterns, or external upgrade infrastructure, or
  • introduce any feature prohibited in this ECIP’s Security or Prohibited Features sections.

All OIP parameter updates MUST be persisted on-chain and MUST only become effective after execution through the Timelock and Executor.
No governance state MAY be mutated within the Governor prior to Timelock-mediated execution.

The following is an illustrative, non-normative example.

// Illustrative, non-normative example of a contract whose governance
// parameters are only updateable via the Governor → Timelock → Executor
// pipeline. The Executor address is treated as the on-chain governance
// authority for this module.
pragma solidity ^0.8.20;

contract OIPExample {
    address public immutable governanceExecutor;

    uint256 public quorumVotes;
    uint256 public votingDelay;
    uint256 public votingPeriod;

    event GovernanceParamsUpdated(
        uint256 quorumVotes,
        uint256 votingDelay,
        uint256 votingPeriod
    );

    constructor(
        address _governanceExecutor,
        uint256 initialQuorum,
        uint256 initialDelay,
        uint256 initialPeriod
    ) {
        require(_governanceExecutor != address(0), "OIPExample: executor required");
        require(initialQuorum > 0, "OIPExample: quorum > 0");
        require(initialDelay > 0, "OIPExample: delay > 0");
        require(initialPeriod > 0, "OIPExample: period > 0");

        governanceExecutor = _governanceExecutor;
        quorumVotes = initialQuorum;
        votingDelay = initialDelay;
        votingPeriod = initialPeriod;
    }

    modifier onlyGovernance() {
        require(msg.sender == governanceExecutor, "OIPExample: only governance");
        _;
    }

    /// @notice Called only as the target of an executed governance proposal.
    function oipUpdateGovernanceParams(
        uint256 newQuorum,
        uint256 newDelay,
        uint256 newPeriod
    ) external onlyGovernance {
        require(newQuorum > 0, "OIPExample: invalid quorum");
        require(newDelay > 0, "OIPExample: invalid delay");
        require(newPeriod > 0, "OIPExample: invalid period");

        quorumVotes = newQuorum;
        votingDelay = newDelay;
        votingPeriod = newPeriod;

        emit GovernanceParamsUpdated(newQuorum, newDelay, newPeriod);
    }
}

6. Integration With ECIP-1114 (Execution Payloads Only)

While ECIP-1114 defines the Ethereum Classic Funding Proposal (ECFP) process, ECIP-1113’s governance contracts interact with ECIP-1114 only at the execution payload boundary.
The Olympia Governor, Timelock, and Executor SHALL treat all ECIP-1114 data (identifiers, hashes, metadata references) as opaque values and SHALL NOT implement or re-implement any ECFP logic.

The implementation MUST:

  • accept execution payloads that reference proposal identifiers and hashes defined in ECIP-1114,
  • treat those identifiers and hashes as opaque values (e.g., bytes32 proposalId, bytes32 metadataHash), and
  • enforce that execution of any ECIP-1114-related funding action is contingent on:
    • successful approval by the Governor under the rules of this ECIP,
    • successful elapsing of the Timelock delay, and
    • successful invocation by the Executor of the Treasury’s restricted interface, as defined in ECIP-1112.

All of the following concerns MUST be handled outside of ECIP-1113, as specified in ECIP-1114:

  • proposal metadata structure and content,
  • ECFP categorization, milestones, and funding schedules,
  • off-chain or cross-chain references (IPFS, URLs, documents),
  • any interpretation of proposal content, purpose, or risk.

ECIP-1113-compliant implementations MUST NOT:

  • parse, validate, or transform ECIP-1114 metadata,
  • enforce ECFP rules such as spending caps, categories, or milestones,
  • introduce proposal-content-based veto logic or metadata-based approval checks.

From the perspective of the governance system, an ECIP-1114-driven funding action is represented only by:

  • a target address (typically the Treasury),
  • a value (if applicable),
  • calldata (including opaque identifiers such as proposalId, metadataHash, or schedule IDs).

These values SHALL pass through the Governor → Timelock → Executor pipeline verbatim and MUST NOT be altered by ECIP-1113 logic.

The following is an illustrative, non-normative example.

// Illustrative, non-normative example showing how an opaque
// ECIP-1114 funding payload can be encoded as a call into the
// Treasury and queued in the Timelock. The governance system
// treats proposalId and metadataHash as opaque bytes32 values.
pragma solidity ^0.8.20;

interface IOlympiaTimelock {
    function queue(
        address target,
        uint256 value,
        bytes calldata data
    ) external returns (bytes32 operationId);
}

contract ECIP1114IntegrationExample {
    IOlympiaTimelock public immutable timelock;
    address public immutable treasury; // ECIP-1112 Treasury contract

    struct FundingPayload {
        bytes32 proposalId;    // defined by ECIP-1114 (opaque here)
        bytes32 metadataHash;  // defined by ECIP-1114 (opaque here)
        uint256 amount;
        address recipient;
    }

    constructor(IOlympiaTimelock _timelock, address _treasury) {
        require(address(_timelock) != address(0), "Integration: timelock required");
        require(_treasury != address(0), "Integration: treasury required");
        timelock = _timelock;
        treasury = _treasury;
    }

    /// @notice Encodes a Treasury.disburse(...) call using opaque ECIP-1114
    /// identifiers and queues it in the Timelock. Governance logic lives
    /// outside this helper.
    function queueFundingAction(FundingPayload calldata payload)
        external
        returns (bytes32 operationId)
    {
        bytes memory data = abi.encodeWithSignature(
            "disburse(bytes32,bytes32,address,uint256)",
            payload.proposalId,
            payload.metadataHash,
            payload.recipient,
            payload.amount
        );

        operationId = timelock.queue(treasury, 0, data);
    }
}

7. Optional Modules: Emergency Pause & Execution Guard

Optional safety modules MAY be deployed alongside the core Governor → Timelock → Executor pipeline.
When present, these modules MUST integrate without altering the fundamental governance flow or introducing any privileged actors.
All optional modules MUST be governed entirely through OIPs and MUST remain removable or replaceable via OIP-controlled updates.

7.1 Emergency Pause Module

The Emergency Pause Module MAY be deployed to provide a temporary, reversible halt on governance execution.
Its behavior MUST comply with the following invariants:

  • It MUST be capable of blocking one or both of:
    • execution within the Timelock,
    • execution attempts forwarded by the Executor.
  • It MUST NOT modify queued operations or alter proposal state.
  • It MUST NOT bypass the Governor — activation and deactivation MUST occur exclusively through OIP.
  • The paused state MUST be stored on-chain, deterministic, and publicly auditable.
  • Pause state MUST automatically unblock once revoked by an OIP-governed action.

The module MUST NOT interpret proposal metadata, funding semantics, milestones, or any proposal content.

This is an illustrative, non-normative example.

// Illustrative, non-normative Emergency Pause module.
// In a full deployment, only the governance Executor (or another
// OIP-designated authority) may toggle the paused state.
pragma solidity ^0.8.20;

contract PauseModule {
    bool public paused;
    address public immutable governanceExecutor;

    event Paused(bool value);

    constructor(address _governanceExecutor) {
        require(_governanceExecutor != address(0), "Pause: executor required");
        governanceExecutor = _governanceExecutor;
    }

    modifier onlyGovernance() {
        require(msg.sender == governanceExecutor, "Pause: only governance");
        _;
    }

    /// @notice Toggle global pause state; callable only via governance.
    function setPaused(bool value) external onlyGovernance {
        paused = value;
        emit Paused(value);
    }

    function isPaused() external view returns (bool) {
        return paused;
    }
}
7.2 Execution Guard Module

The Execution Guard Module, when deployed, acts as a deterministic validation layer that checks execution requests before the Executor performs them.
It MUST:

  • validate calldata structure, size, or format,
  • reject operations that violate explicit, on-chain rules (e.g., invalid targets, forbidden selectors, excessive batch size),
  • operate only on raw calldata and execution parameters,
  • emit deterministic reverts for invalid operations,
  • NEVER inspect metadata, ECFP contents, proposal descriptions, or other off-chain inputs.

The Guard MUST NOT:

  • approve or veto proposals,
  • possess any external control keys,
  • modify proposal or governance state.

The Guard may only accept or reject execution payloads based on a deterministic rule set defined on-chain and modifiable solely through OIP.

This is an illustrative, non-normative example.

// Illustrative, non-normative Execution Guard.
// This module enforces a simple, deterministic rule:
// - reject execution requests targeting the zero address.
//
// Real deployments MAY extend this with additional on-chain rules
// (selector allowlists, size limits, etc.) but MUST NOT inspect
// off-chain metadata or introduce discretionary veto power.
pragma solidity ^0.8.20;

contract ExecutionGuard {
    function validate(
        address target,
        uint256 /* value */,
        bytes calldata /* data */
    ) external pure returns (bool) {
        return target != address(0);
    }
}
7.3 Integration Requirements

When optional modules are deployed:

  • They MUST NOT alter the mandatory execution sequence:
    Governor → Timelock → Guard(s) → Executor → Treasury
  • They MUST be modular contracts referenced by the Timelock or Executor (not embedded logic).
  • All updates or replacements MUST occur through OIP-authorized governance actions.
  • Guard rejections MUST produce deterministic failures without mutating queued Timelock operations.
  • Their absence MUST NOT affect correctness of the core governance pipeline—these modules provide optional risk-reduction, not required functionality.

8. Child-DAO Governance Pipelines

Child-DAO modules MAY be deployed to manage domain-specific governance (e.g., Core Client Maintenance, Infrastructure Coordination, Public Goods, etc.) while preserving the strict separation of authority defined in this ECIP.
A Child-DAO operates as a subordinate governance layer whose outputs MUST always be routed through the main Olympia Governor.

A Child-DAO SHALL:

  • manage its own internal voting or signaling process,
  • maintain its own proposal lifecycle and domain-specific rules,
  • optionally aggregate votes or input from its participant set, and
  • produce derived actions or recommendations that are forwarded to the main Governor for binding execution.

A Child-DAO MUST NOT:

  • execute actions directly against the Treasury (ECIP-1112),
  • bypass the main Governor’s quorum, voting, or timelock rules,
  • introduce external or privileged veto actors,
  • or possess any direct write-access to protocol-level parameters.

All actionable output from a Child-DAO MUST be submitted to the main Governor as a standard proposal payload. The main Governor SHALL then:

  1. apply its own voting delay, voting period, quorum, and OIP rules,
  2. queue any approved actions into the Timelock, and
  3. execute them via the Executor if not vetoed or paused.

This ensures that all binding authority remains with the main Governor, while Child-DAOs serve as modular contributors or domain-specific governance pipelines.

Child-DAO configuration—including membership criteria, internal voting rules, and optional delegation mechanics—MAY be defined or updated via OIP. However:

  • no Child-DAO MAY violate the Sybil-resistance and ETC-domain restrictions defined for the main Voting Module, and
  • no Child-DAO MAY impose proposal-specific veto power or privileged access to the Treasury.

The following illustrative example demonstrates how a Child-DAO MAY package a domain-specific action and submit it to the main Governor using a standard propose() call.
The Child-DAO does not execute actions directly and does not interact with the Treasury; it simply forwards an action for main-governor consideration under the normal voting and timelock rules.

The following illustrative, non-normative example shows how a Child-DAO MAY package a single-target domain-specific action and submit it to the main Governor using a standard propose() call. The Child-DAO does not execute actions directly and does not interpret Treasury details; it only forwards its recommendation into the main Governor for consideration under the normal voting and timelock rules.

// Illustrative, non-normative Child-DAO example.
// The Child-DAO cannot execute Treasury actions itself; it only
// forwards a single-target proposal into the main Olympia Governor
// for binding approval under the normal Governor → Timelock → Executor flow.
pragma solidity ^0.8.20;

interface IOlympiaGovernor {
    function propose(
        address[] calldata targets,
        uint256[] calldata values,
        bytes[] calldata calldatas,
        string calldata description
    ) external returns (uint256);
}

contract ChildDAO {
    IOlympiaGovernor public immutable mainGovernor;

    event ChildProposalSubmitted(
        uint256 indexed proposalId,
        address indexed target,
        bytes data,
        string description
    );

    constructor(IOlympiaGovernor _mainGovernor) {
        require(address(_mainGovernor) != address(0), "ChildDAO: governor required");
        mainGovernor = _mainGovernor;
    }

    /// @notice Packages a single-target action into the main Governor.
    /// Any caller MAY submit an action; domain-specific membership or
    /// admission rules, if desired, are enforced outside this example.
    function submitAction(
        address target,
        bytes calldata data,
        string calldata description
    ) external returns (uint256 proposalId) {
        require(target != address(0), "ChildDAO: invalid target");

        address;
        uint256;
        bytes;

        targets[0] = target;
        values[0] = 0;
        calldatas[0] = data;

        proposalId = mainGovernor.propose(
            targets,
            values,
            calldatas,
            description
        );

        emit ChildProposalSubmitted(proposalId, target, data, description);
    }
}

9. Audit & Testnet Rollout

Before mainnet activation, all Olympia DAO components SHALL undergo comprehensive security review and multi-client testnet validation.
The full governance suite MUST be deployed and exercised on the Mordor Testnet prior to any mainnet hard fork.

9.1 Security Audits

At minimum, one independent third-party security audit SHALL be performed, covering:

  • the Governor contract suite,
  • the Voting Module and all identity/eligibility logic,
  • the Timelock and Executor modules,
  • any optional modules (Emergency Pause, Execution Guard), and
  • any deployed Child-DAO contracts.

Audits MUST verify adherence to the invariants defined in this ECIP, including:

  • prohibition of upgradeable proxy patterns,
  • absence of owner/admin/guardian roles,
  • immutability of the governance pipeline,
  • determinism of snapshot and eligibility logic, and
  • correct enforcement of Timelock delays and Executor authorization.

All findings SHOULD be resolved or mitigated before mainnet activation.

9.2 Mordor Testnet Deployment

A full-system deployment SHALL be performed on the Mordor Testnet, validating:

  • proposal creation, queueing, execution, and lifecycle transitions,
  • snapshot-based voting power and eligibility correctness,
  • Timelock delay enforcement and replay protection,
  • Executor isolation and correct Treasury-call behavior,
  • proper handling of OIP-driven parameter and module upgrades, and
  • cross-client consensus consistency across all governance-related operations.

Testnet trials MUST exercise all mandatory governance flows and SHOULD include:

  • benign governance scenarios (parameter updates, module replacements),
  • adversarial and edge-case behaviors (invalid operations, replay attempts),
  • activation and revocation of Emergency Pause,
  • rejection and acceptance paths for Execution Guard rules, and
  • real-world identity/attestation interactions under varied conditions.

Successful testnet validation SHALL be considered a requirement for readiness prior to scheduling any mainnet activation block.

10. Modular Deployment and Activation

Consistent with the modular design of ECIPs 1111–1114, deployment and activation of Olympia SHALL proceed in discrete, independently verifiable phases.
Each phase MUST preserve the invariants of this ECIP and MUST NOT grant premature authority to any undeployed or unaudited module.

10.1 Staged Deployment
  • The Treasury (ECIP-1112) MAY be deployed and begin accumulating BASEFEE-redirected funds prior to activation of ECIP-1113.
  • The Olympia Governor, Voting Module, Timelock, Executor, and any optional modules MAY be deployed to testnet or mainnet in advance, provided they do not yet control the Treasury.
  • Child-DAO modules MAY also be deployed early, provided that they route all binding actions to the main Governor and do not interact with the Treasury directly.

Early deployment MUST NOT grant control of the Treasury until the community, client implementers, and auditors have verified correctness.

10.2 Preconditions for Mainnet Activation

Mainnet activation of ECIP-1113 SHOULD occur only after:

  • independent third-party audits have been completed and reviewed,
  • Mordor testing demonstrates correct behavior under benign, adversarial, and edge-case conditions, and
  • the Ethereum Classic community has had sufficient opportunity to review and discuss the governance architecture defined in this ECIP.
10.3 Handover of Treasury Control

Handover of execution authority to Olympia DAO SHALL occur by setting the Executor address inside the Treasury (ECIP-1112) according to the deployment rules defined in that proposal.

Once this address is set:

  • all authorized Treasury withdrawals MUST pass exclusively through the
    Governor → Timelock → Executor
    pipeline defined in this ECIP, and
  • no subsequent governance action MAY modify the Treasury’s reference to the Executor.

After handover, the Treasury becomes fully governed by the on-chain, OIP-controlled Olympia DAO framework, and all protocol-level funding actions MUST conform to the access-control and execution pipeline defined in ECIP-1113.

Backwards Compatibility

ECIP-1113 introduces no changes to Ethereum Classic’s consensus rules, block structure, transaction formats, opcodes, or EVM semantics.
Olympia DAO governance operates entirely at the application layer through smart contracts and does not modify consensus-layer behavior.

Protocol Impact

  • Nodes that implement ECIP-1111 (BASEFEE activation) and ECIP-1112 (Olympia Treasury) but not ECIP-1113 will remain in consensus with the canonical chain. However:
    • they will be unable to construct or execute governance transactions, and
    • they will still validate blocks containing governance-related transactions, since such transactions conform to existing consensus rules.
  • Nodes that fail to implement ECIP-1111 (EIP-1559-style BASEFEE + redirection) will fork from the canonical chain at the ECIP-1111 activation block.

Application-Layer Isolation

  • All Olympia DAO logic — proposal creation, voting, timelock scheduling, parameter updates, and execution — is isolated from consensus logic.
  • Existing smart contracts and dApps remain fully compatible and unaffected unless they opt in to interact with Olympia DAO governance or Treasury events.
  • Participation in governance is entirely optional; non-participating nodes and applications remain fully valid.

Treasury Execution Requirements

To authorize or construct Treasury disbursements, clients MUST support:

  • the immutable Olympia Treasury contract (ECIP-1112),
  • the Olympia DAO Executor (ECIP-1113), and
  • the ECIP-1114 execution path, including hash-bound proposal verification.

Clients that do not implement ECIP-1113 or ECIP-1114:

  • cannot create, sign, or participate in governance transactions,
  • but will continue to validate Treasury executions so long as they comply with consensus rules.

State and Data Integrity

  • Proposal state, voting records, timelock queues, and execution events are stored entirely within smart contract state.
  • No historical consensus-layer state is altered.
  • Governance-layer state is deterministic and does not affect block validity or canonical chain selection.

By keeping all governance logic strictly isolated from consensus mechanics, ECIP-1113 preserves Ethereum Classic’s protocol stability and immutability while enabling a secure, opt-in, on-chain governance and funding system.

Governance Parameter Invariants

Olympia DAO governance parameters SHALL be implemented as on-chain, OIP-controlled variables that define the safety envelope for all governance operations.
These parameters MUST be stored in contract state, enforced deterministically, and modifiable only through the Governor → Timelock → Executor pipeline.

Quorum and Approval Thresholds

  • A minimum quorum MUST be required for any proposal to be valid.
  • An approval threshold MUST be required for any proposal to pass.
  • Both quorum and approval thresholds MUST be modifiable only through OIP-authorized parameter updates.
  • No external authority MAY alter these values.

Voting Delay and Voting Period

  • A voting delay MUST be enforced between proposal creation and voting start.
  • A minimum voting period MUST be enforced to allow global participation.
  • Both parameters MUST be encoded on-chain and modifiable only through OIP-controlled governance actions.

Proposal Submission Requirements

  • The DAO MAY define additional submission requirements (e.g., eligibility checks, identity-based verification) provided they remain:
    • permissionless,
    • modular, and
    • enforced by the Voting Module or associated identity systems.
  • These requirements MUST NOT introduce privileged actors, trusted committees, or off-chain authority.

Timelock Enforcement

  • All approved proposals MUST pass through a Timelock before execution.
  • Timelock delay MUST be strictly greater than zero and modifiable only through OIP.
  • Timelock delays MUST NOT be bypassable by any module, external actor, multisig, or emergency mechanism.

On-Chain Auditability

  • All governance-parameter changes MUST be recorded on-chain.
  • Events MUST be emitted for updates to quorum, thresholds, delays, and voting periods.
  • Parameter changes MUST only take effect after successful execution through the Timelock.

These invariants ensure that Olympia DAO governance remains auditable, transparent, and resistant to rushed or captured decision-making, while preserving permissionless participation and deterministic on-chain behavior.

Security Considerations

Olympia DAO governance is designed to minimize attack surfaces while preserving permissionless participation and transparent on-chain execution.
This section outlines the core security properties and mitigations required for the Governor → Timelock → Executor pipeline defined in this ECIP.

1. Contract Immutability and Access Control

  • Governance contracts (Governor, Timelock, Executor) MUST NOT include admin keys, owner roles, guardian roles, or upgradeable proxy patterns.
  • Governance parameters (quorum, thresholds, delays, periods) MUST be modifiable only through OIP-controlled proposals executed via the full governance pipeline.
  • The Olympia Treasury (ECIP-1112) SHALL remain immutable and MUST accept calls only from the approved Executor; all other callers MUST revert.
  • No external contract, off-chain actor, multisig, or Child-DAO MAY bypass the Timelock or alter queued operations.

2. Execution Integrity and Determinism

  • All execution payloads MUST be treated as opaque byte arrays and executed exactly as encoded.
  • The Governor, Timelock, and Executor MUST NOT transform, reinterpret, sanitize, or conditionally modify payloads.
  • Operations MUST be executed atomically; partial execution MUST revert.
  • Timelock operationId hashing MUST ensure replay protection, uniqueness, and non-reexecution of completed or canceled entries.

3. Replay Protection

  • Proposals and execution payloads MUST be domain-separated using block.chainid or equivalent chain-bound identifiers.
  • Replay-protection logic MUST be implemented consistently across the Governor, Timelock, and Executor.
  • Executed operations MUST be marked in contract state to prevent same-chain re-execution.

4. Governance Process Risks

  • Low participation risk — mitigated via quorum requirements, configurable voting periods, and mandatory voting delays.
  • Governance capture — minimized through one-address-one-vote, optional Sybil-resistant identity systems, and ETC-domain restrictions.
  • Rushed execution — prevented via strictly positive Timelock delays and optional Emergency Pause modules.
  • Module misconfiguration — mitigated by requiring all module references (Voting Module, Timelock, Executor, Guard, Pause) to be updated exclusively via OIP.

5. Client and Network Safety

  • Governance execution MUST NOT modify consensus rules, transaction validation logic, or block format.
  • Clients verifying Treasury disbursements MUST validate:
    • the target address (Treasury),
    • the caller (Executor),
    • and that the calldata matches the expected withdrawal function signature.
  • All governance operations MUST be deterministic across clients to avoid consensus divergence.
  • Full cross-client testing on Mordor Testnet SHALL confirm identical execution paths on all supported ETC clients prior to activation.

6. Event Logging and Auditability

  • All governance actions — including proposal creation, voting, parameter changes, queueing, and execution — MUST emit standardized events.
  • Events MUST allow complete off-chain reconstruction of proposal state transitions.
  • The Timelock MUST emit events for all queued operations, and the Executor MUST emit events for all executed operations.
  • Off-chain indexers SHOULD track these events to provide verifiable governance audit trails.

By enforcing immutable access control boundaries, deterministic execution, replay protection, and comprehensive logging, Olympia DAO ensures secure, transparent, and tamper-resistant governance over Ethereum Classic’s protocol-level execution pipeline.

ECIP-1113 is one of four coordinated ECIPs that together introduce a modular, decentralized, and transparent protocol-funding framework for Ethereum Classic.
Each component focuses on a distinct layer of the system.

Interdependency Summary

  • ECIP-1111 introduces protocol-level revenue via BASEFEE redirection.
  • ECIP-1112 deploys the immutable Treasury vault that stores this revenue.
  • ECIP-1113 defines the governance layer that can authorize withdrawals from the Treasury.
  • ECIP-1114 defines the proposal format and metadata rules that ECIP-1113 consumes as opaque execution payloads.

These ECIPs are designed for modular activation:

  • ECIP-1111 and ECIP-1112 may be deployed first, allowing the Treasury to accumulate funds.
  • ECIP-1113 and ECIP-1114 may be activated later, enabling transparent, on-chain governance and disbursement of accumulated funds.

Copyright and related rights waived via
CC0

Appendix: Governance Architecture Precedents

This appendix provides informal background on governance patterns that inspire the modular Governor → Timelock → Executor architecture defined in ECIP-1113.
These precedents are non-normative and do not impose implementation requirements.

Established EVM Governance Patterns

Olympia DAO draws conceptual influence from widely deployed and audited on-chain governance frameworks, including:

  • OpenZeppelin Governor
    Modular governance architecture with pluggable voting strategies and a dedicated Timelock Controller.
    Demonstrates deterministic lifecycle semantics and strong audit coverage.

  • Compound Governor Bravo
    Snapshot-based voting, deterministic proposal states, timelock enforcement, and configurable quorum/threshold parameters.
    Serves as a proven reference for transparent, parameterized governance logic.

  • Aragon OSx
    Plugin-based governance modules and scoped authority paths.
    Demonstrates modular governance composition, which aligns with Olympia’s optional modules (e.g., Guards, Child-DAOs).

  • ENS / Gitcoin / Aave Governance Systems
    Illustrate predictable proposal lifecycles, on-chain execution, and identity-or voting-module-based authorization consistent with a modular governor design.

These systems collectively validate the architectural principles required for Olympia DAO:

  • deterministic proposal lifecycles,
  • transparent on-chain execution,
  • mandatory timelock delays,
  • modular voting and execution components, and
  • strict avoidance of privileged roles or upgradeable-proxy patterns.

Scope Note

This appendix is informational only.
Treasury custody precedents and cross-ecosystem treasury designs are documented in ECIP-1112 and are intentionally excluded here to preserve strict modular boundaries between:

  • ECIP-1112 — Treasury storage and immutability
  • ECIP-1113 — governance and execution architecture
  • ECIP-1114 — funding proposal metadata and payload structure

The Olympia DAO design adheres to governance patterns proven across the EVM ecosystem while maintaining Ethereum Classic’s requirements for immutability, neutrality, and deterministic on-chain execution.