ECIP 1112: Olympia Treasury Contract Source

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

Simple Summary

Redirect the BASEFEE introduced by ECIP-1111 (EIP-1559) to a protocol-defined on-chain treasury contract—the Olympia Treasury—instead of burning it. This mechanism establishes a sustainable, non-inflationary funding stream secured at the consensus layer. The treasury contract is immutable, transparent, and governance-isolated, enabling decentralized allocation of funds for core client development, infrastructure maintenance, and ecosystem resilience.

Abstract

This ECIP specifies the deployment of the Olympia Treasury, a protocol-level smart contract at a fixed, deterministic address on the Ethereum Classic network. Upon activation of ECIP-1111 (which implements EIP-1559), all BASEFEE revenue will be redirected to this contract instead of being burned.

The Olympia Treasury serves as an immutable, externally auditable funding vault for Ethereum Classic. It accumulates protocol-level fee revenue and is designed to interoperate securely with a permissionless governance layer (ECIP-1113). Disbursements are executed exclusively through on-chain proposals approved by Olympia DAO.

This treasury mechanism introduces a transparent, non-inflationary funding model to support client maintenance, protocol development, infrastructure, and ecosystem growth—without reliance on trusted intermediaries. This architecture draws on successful precedents from EVM-compatible networks such as Ronin, Celo, and Mantle, which redirect BASEFEE or sequencer revenue into DAO-governed treasuries to fund public goods. Off-chain fiat interfacing and administrative execution are supported by the Ethereum Classic DAO LLC, a legally registered entity that operates under binding instructions from Olympia DAO (see ECIP-1114).

Motivation

Ethereum Classic currently lacks a sustainable, transparent, and decentralized mechanism to fund core protocol development, infrastructure, and ecosystem tooling. Historical support has relied on nonprofit foundations, one-time grants, or centralized donors—many of which have discontinued operations or withdrawn funding.

With block rewards declining over time under ECIP-1017, Ethereum Classic requires a funding model that preserves its fixed monetary policy while aligning with its core principles of immutability, decentralization, and Proof-of-Work security.

Redirecting the BASEFEE introduced by EIP-1559 into a protocol-owned treasury—rather than burning it—establishes a native, non-inflationary funding stream tied directly to network usage. This model:

  • Aligns incentives between miners, users, and developers.
  • Strengthens Ethereum Classic’s long-term security and maintenance budget.
  • Enables a sustainable, on-chain mechanism for funding public goods—without introducing monetary inflation or trusted third parties.

By capturing endogenous protocol revenue and routing it into an immutable, decentralized treasury, Ethereum Classic secures the financial infrastructure needed to support client development, ecosystem resilience, and long-term viability.

Specification

Treasury Address

The Olympia Treasury contract SHALL be deployed at a fixed, deterministic address. This address SHALL be hardcoded into Ethereum Classic’s consensus logic as the recipient of the BASEFEE defined in ECIP-1111.

  • Placeholder Address: 0x0000000000000000000000000000000000OLYMPIA
    (Final address to be derived via CREATE or CREATE2 and published prior to testnet deployment in coordination with client implementers.)

The address derivation MUST be reproducible across all client implementations to ensure deterministic deployment and cross-client consensus integrity.

Example: CREATE2 Address Derivation

The Olympia Treasury contract address SHALL be deterministically derived using the CREATE2 opcode to ensure consistent deployment across clients.

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

// Derive the deterministic address of the Olympia Treasury contract using CREATE2
address treasuryAddress = address(
    uint160(uint256(
        keccak256(
            abi.encodePacked(
                bytes1(0xff),         // Required prefix for CREATE2
                deployerAddress,      // Known deployer (e.g., DAO multisig)
                salt,                 // Fixed constant (e.g., bytes32("OLYMPIA_VAULT"))
                keccak256(bytecode)  // Hash of compiled contract bytecode
            )
        )
    ))
);

Where:

  • deployerAddress is the known deployer address (e.g. DAO multisig or fixed deployer)

  • salt is a constant value (e.g. bytes32("OLYMPIA_VAULT"))

  • bytecode is the keccak256 hash of the compiled treasury contract

This method allows deterministic pre-publication of the treasury address for testnet coordination and client integration.

Fee Redirection and Consensus Enforcement

  • Funding Source: 100% of the BASEFEE from all EIP-1559 transactions SHALL be redirected to the Olympia Treasury.
  • Enforcement: This behavior SHALL be enforced at the consensus layer upon activation of ECIP-1111. Clients that fail to implement this redirection SHALL fork from the canonical chain.

Contract Requirements

The Olympia Treasury contract MUST meet the following technical constraints:

  • Immutability:
    • The contract SHALL include no proxy pattern, upgrade hooks, selfdestruct, delegatecall, or any opcode enabling runtime modification. Deployment MUST be single-step and final.
    • No admin or owner-controlled logic.
  • Traceability:
    • Emits Transfer, Receive, and ProposalExecuted events for auditability.
  • Transparency:
    • Public view methods for accessing balance and transaction metadata.
  • Access Control:
    • Reverts all direct withdrawal attempts from EOAs or unauthorized contracts.

Reference Implementation (Solidity)

Example: Olympia Treasury Contract

This example contract ensures funds can only be released by the authorized DAO executor address, with immutable logic and one-time execution per proposal. The proposalHash links to an off-chain metadata digest, ensuring alignment between proposal content and disbursement.

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

/// @title Olympia Treasury - Immutable Vault Contract
/// @notice Accepts BASEFEE revenue and permits disbursement only by DAO executor
contract OlympiaTreasury {
    /// @notice Authorized DAO executor contract
    address public immutable dao;

    /// @notice Tracks executed proposal hashes to prevent re-execution
    mapping(bytes32 => bool) public executedProposals;

    /// @notice Emitted when funds are released to a recipient
    event FundsReleased(
        bytes32 indexed proposalHash,
        address indexed recipient,
        uint256 amount
    );

    /// @param _dao Address of the authorized DAO executor
    constructor(address _dao) {
        require(_dao != address(0), "Invalid DAO address");
        dao = _dao;
    }

    /// @notice Fallback to accept incoming BASEFEE transfers
    receive() external payable {}

    /// @notice Executes an approved proposal via hash-bound disbursement
    /// @param proposalHash Unique hash derived off-chain from proposal metadata
    /// @param recipient Target address to receive funds
    /// @param amount Amount of ETC (in wei) to transfer
    function release(
        bytes32 proposalHash,
        address payable recipient,
        uint256 amount
    ) external {
        require(msg.sender == dao, "Not authorized");
        require(!executedProposals[proposalHash], "Already executed");
        require(recipient != address(0), "Invalid recipient");

        executedProposals[proposalHash] = true;

        (bool success, ) = recipient.call{value: amount}("");
        require(success, "Transfer failed");

        emit FundsReleased(proposalHash, recipient, amount);
    }
}

Example: Off-Chain Proposal Hashing

For compatibility with the release() function, each proposal MUST generate a unique hash off-chain to ensure one-time disbursement enforcement.

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

// Example for generating a verifiable proposal hash off-chain:
bytes32 proposalHash = keccak256(
    abi.encodePacked(
        ecfpId,         // Unique proposal ID
        recipient,      // Address receiving funds
        amount,         // Amount of ETC to disburse
        metadataCID,    // Optional IPFS or Arweave metadata reference
        block.chainid   // Chain binding
    )
);

Governance Integration

The Treasury contract SHALL expose a restricted interface callable only by a designated DAO executor contract (see ECIP-1113). This interface MUST include:

  • release() and/or execute() disbursement functions, callable only by the authorized executor.
  • On-chain event logging for every executed proposal.
  • Stateless logic enabling milestone-based or time-locked funding (controlled by external governance, not the Treasury itself).

Governance logic SHALL be implemented externally. The Treasury contract SHALL enforce execution-only behavior and MUST NOT include proposal submission, vote tallying, or authorization mechanisms. This separation minimizes attack surface and supports modular DAO upgrades.

The Treasury contract does not assume the existence of a governance token. It supports modular integration with external governance systems that may use token voting, reputation-based models, or delegated authority (see ECIP-1113).

Execution Control and Spam Mitigation

  • DAO-Only Execution: Only the authorized governance executor MAY invoke disbursement functions.
  • Proposal Isolation: Proposals MUST be validated externally; the Treasury SHALL enforce execution-only logic.
  • Spam Protection: Proposal throughput SHALL be rate-limited by governance mechanisms, not enforced within the Treasury contract.

These constraints ensure the Olympia Treasury operates as a minimal, secure, and externally governed protocol vault—compliant with ECIP-1111 and prepared for governance activation under ECIP-1113.

Rationale

Minimalist Architecture for Secure Deployment

The Olympia Treasury is deployed as a minimal, immutable vault, without embedded governance or conditional logic. Prior to DAO activation (as defined in ECIP-1113), the contract functions solely as a passive accumulator of BASEFEE revenue.

This design ensures:

  • No operational complexity at launch
  • No upgrade paths or privileged access
  • A stable foundation for phased governance activation

By minimizing internal logic, the Treasury eliminates execution risks during the accumulation phase and supports safe, modular rollout of future governance components.

Design Objectives

The Treasury contract is a cornerstone of Ethereum Classic’s transition to sustainable, decentralized funding. It supports the following protocol-level goals:

  • Security Budget Continuity
    ECIP-1017 reduces block rewards over time. Treasury funding via BASEFEE redirection ensures ETC retains a native, non-inflationary source of capital for audits, client maintenance, and protocol upgrades.

  • Aligned Economic Incentives
    The design creates a virtuous cycle:

    More users and dApps → More transactions → More treasury revenue → More development → More adoption.

  • Open and Permissionless Access
    Unlike closed foundations or opaque grant programs, the Treasury enables any contributor to submit a proposal through transparent, on-chain governance (ECIP-1113).

  • Transparency and Accountability
    All inflows and disbursements are recorded on-chain through event emissions. This guarantees verifiability of treasury activity, deters favoritism, and builds long-term trust in the transparency and neutrality of protocol funding.

  • Governance Modularity
    Governance logic resides outside the Treasury contract. This allows upgrades or replacements of the DAO (ECIP-1113) without modifying the Treasury, improving resilience and long-term flexibility.

Ecosystem Precedents

Other EVM-based networks have adopted similar basefee redirection models to fund public goods:

  • Ronin Network
    Routes EIP-1559 BASEFEE to a DAO-controlled treasury supporting Axie Infinity infrastructure.

  • Celo (Layer 1)
    Redirects gas fees to a Gas Fee Handler for climate and community funding.

  • Mantle (Layer 2)
    Uses sequencer revenue redirection to support ecosystem grants via MantleDAO.

These precedents show that protocol-native treasury funding is a practical, scalable strategy for sustaining decentralized ecosystems.

Summary

The Olympia Treasury advances Ethereum Classic’s core values of immutability, decentralization, and transparency, while introducing a secure and credible method of funding long-term development. Its separation from governance logic ensures safety during deployment and flexibility for future upgrades.

The Olympia Treasury design builds on proven patterns from other EVM-compatible networks that use protocol-level fee redirection to fund public goods through DAO-managed treasuries. These implementations demonstrate the viability of using BASEFEE or gas-derived revenue to support sustainable, decentralized development.

  • Ronin Network (Axie Infinity sidechain)
    Redirects EIP-1559 BASEFEE into a DAO-controlled treasury. Funds are used to support infrastructure, community grants, and long-term protocol maintenance.
    View Contract

  • Celo (Layer 1)
    Uses a Gas Fee Handler to redirect transaction fees toward climate initiatives and community development via a governance-controlled treasury.
    View Handler

  • Mantle (Layer 2)
    Implements fee redirection from its L2 sequencer to a treasury contract managed by MantleDAO. Revenue supports grants, infrastructure, and developer programs.
    Read More

  • Polygon CDK (Modular Rollup Framework)
    Supports modular DAOs and EIP-1559-compatible treasury redirection in sovereign rollups, allowing rollup creators to govern and fund protocol upgrades.
    Polygon CDK Overview

  • OP Stack (used by Base, Optimism)
    The OP Stack supports EIP-1559-style transactions and sequencer revenue splitting, but does not redirect BASEFEE to a DAO treasury. This provides a useful counterexample for evaluating the neutrality and sustainability of treasury design decisions across rollup architectures.

These implementations reflect a broader trend: redirecting protocol revenue to transparent, on-chain treasuries is an effective, neutral, and incentive-aligned strategy for funding ecosystem development without introducing inflation or centralized control.

Addendum: Verified Contract References

For deeper implementation study and validation, below are verified contracts used by other EVM ecosystems:

These implementations support the validity, neutrality, and resilience of redirecting protocol-layer fees to transparent, on-chain treasuries.

Implementation

The Olympia Treasury will be implemented in the Core-Geth client as part of the Olympia network upgrade. This includes consensus-level changes to redirect BASEFEE revenue to a fixed treasury address defined in ECIP-1112.

Client Responsibilities

Ethereum Classic client implementations MUST include the following protocol changes:

  • Consensus Enforcement:
    The Olympia Treasury address MUST be hardcoded at the consensus layer as the canonical recipient of the BASEFEE in every post-upgrade block.

  • Fee Redirection Logic:
    The default EIP-1559 burn behavior MUST be replaced with logic that transfers the BASEFEE to the Treasury contract.

  • Gas Accounting Adjustments:
    Clients MUST adjust block reward, gas usage, and fee distribution calculations to account for the redirection and maintain compatibility with EIP-1559 mechanics.

Deployment Artifacts

  • The Treasury contract’s bytecode, deployment method, and deterministic address SHALL be published with the Olympia upgrade release.
  • Deployment MUST use either CREATE or CREATE2 to ensure reproducibility across clients and enable deterministic address derivation.
  • The finalized contract SHALL undergo formal security auditing prior to mainnet deployment.

Test Coverage and Validation

Clients MUST validate the following behaviors through integration testing and Mordor Testnet deployment:

  • Accurate and consistent BASEFEE transfers to the treasury in every block.
  • Correct emission of all required events, including Transfer, Receive, and governance-related logs.
  • Compatibility with DAO governance interfaces (propose(), release(), execute()).
  • Consensus alignment across client implementations using cross-client test vectors and replay validation.

These requirements ensure secure, deterministic integration of the Olympia Treasury across the Ethereum Classic network and client stack.

Modular Treasury Deployment

The Olympia Treasury is implemented as a standalone, immutable smart contract. It may be deployed and activated independently of downstream governance (ECIP-1113) or legal execution infrastructure (ECIP-1114), enabling a phased rollout of the Olympia Upgrade.

Pre-Governance Activation

  • The Treasury contract SHALL begin accumulating BASEFEE revenue immediately upon activation of ECIP-1111.
  • No governance contracts or DAO infrastructure are required for the Treasury to function as a passive accumulation vault.

Security During Accumulation Phase

  • All disbursement functions (e.g., release(), execute()) SHALL remain inaccessible unless triggered by an authorized governance executor.
  • Any withdrawal attempts from EOAs or unauthorized contracts MUST revert, ensuring funds remain locked until formal governance activation.

Deployment Advantages

  • Forward Compatibility:
    Governance modules may be integrated at a later time without requiring modifications to the deployed Treasury contract.

  • Security Isolation:
    Treasury logic is fully decoupled from governance execution, minimizing surface area and isolating risk during early stages.

  • Phased Rollout Support:
    This structure supports staggered deployment of ECIPs 1111–1114, allowing the community to independently audit and activate each component while permitting early accumulation of funds.

This modular deployment pattern enables secure, flexible treasury activation while reducing the need for full-stack coordination at launch.

Backwards Compatibility

The Olympia Treasury contract modifies the default behavior introduced by EIP-1559 by redirecting the BASEFEE to a fixed treasury address instead of burning it. This modification is enforced at the consensus level and requires updated client implementations under ECIP-1111.

Node Behavior

  • Upgraded Clients:
    Clients that implement ECIP-1111 and ECIP-1112 will correctly process Type-2 transactions and redirect BASEFEE to the hardcoded treasury address.

  • Non-Upgraded Clients:
    Legacy clients that do not implement ECIP-1111 will:

    • Fail to recognize Type-2 transactions (EIP-1559)
    • Continue to burn the BASEFEE or handle it incorrectly
    • Remain unaware of the Treasury contract address

    As a result, such clients will diverge at the fork block, causing a permanent consensus split from the canonical Ethereum Classic chain.

Contract and Tooling Compatibility

  • Type-0 transactions remain valid and are unaffected by this upgrade.
  • Previously deployed contracts that do not reference the BASEFEE or Treasury address will continue to operate as before.
  • Tooling and dApps that are EIP-1559-agnostic remain fully functional, ensuring forward compatibility for existing integrations.

This upgrade preserves backward compatibility for legacy transactions while enabling forward enhancements in a fully opt-in, consensus-driven manner.

Security Considerations

The Olympia Treasury contract introduces consensus-layer logic to redirect the BASEFEE and enforces immutability through strict smart contract constraints. Security risks are mitigated across the following five domains:

1. Contract Immutability and Access Control

  • Immutable Deployment:
    The contract is deployed once and cannot be upgraded. It includes no proxy mechanisms, no delegatecall, and no owner or administrative controls.

  • Restricted Execution:
    Only an authorized DAO executor contract may call disbursement functions (release(), execute()).
    All direct calls from externally owned accounts (EOAs) or unauthorized contracts SHALL revert.

  • Minimal Attack Surface:
    The contract implements minimal logic beyond permission enforcement and fund transfers, reducing the likelihood of exploitable vulnerabilities.

2. DAO Governance and Integration Risks

  • Governance Risks Are Out-of-Scope:
    This ECIP does not define DAO governance behavior. Risks such as spam proposals, collusion, or low-quorum attacks are addressed in ECIP-1113.

  • Fail-Safe Treasury Design:
    Even in cases of DAO failure or capture, funds remain inaccessible unless a proposal is executed by the authorized interface.
    This constraint ensures separation of concerns between protocol security and governance dynamics.

3. Client Enforcement and Network Safety

  • Consensus Enforcement:
    Clients MUST redirect BASEFEE to the hardcoded treasury address.
    Failure to do so results in consensus failure and permanent chain divergence.

  • Replay Protection:
    Clients SHOULD implement transaction replay protection at the chain ID level to prevent cross-fork execution.

4. Replay Safety and Execution Integrity

  • Chain-Bound Execution:
    Governance proposals MUST include a chain ID and unique identifier hash to ensure binding disbursement execution on the correct chain.

  • Proposal-Linked Disbursement:
    No funds may be released without a valid, approved, and hash-bound governance proposal.

5. Audit and Testing Strategy

  • Independent Security Audit:
    The contract SHALL be audited by external security firms prior to deployment.

  • Formal Verification:
    Automated tools such as Slither or MythX SHALL be used to statically analyze the contract for vulnerabilities and logic errors.

  • Testnet Simulation:
    Mordor Testnet SHALL be used to validate basefee redirection, governance integration, and disbursement mechanics prior to mainnet activation.

Summary

The Olympia Treasury is implemented as an immutable, governance-isolated vault. Its design prevents unauthorized access, minimizes runtime complexity, and enforces consensus correctness. Through external audits, formal verification, and testnet validation, the implementation provides a secure foundation for decentralized, on-chain funding of Ethereum Classic public goods.

Copyright and related rights waived via
CC0