ECIP 1112: Olympia Treasury Contract

Simple Summary

Redirect all BASEFEE amounts introduced by ECIP-1111 to a deterministic, immutable smart contract — the Olympia Treasury — instead of burning them. The Treasury functions as a governance-isolated vault that can receive protocol-level revenue but cannot be modified or accessed except through a single, authorized execution entry point defined in a separate governance ECIP.

Abstract

This ECIP defines the deployment of the Olympia Treasury, a deterministic and immutable smart contract that receives all BASEFEE amounts redirected under ECIP-1111. The Treasury is deployed at a fixed address, derived deterministically, and is hardcoded as the canonical recipient of protocol-level revenue. It functions exclusively as a governance-isolated vault: it may receive funds, but it cannot be upgraded, modified, or accessed directly.

The Treasury exposes a minimal, restricted interface that accepts revenue transfers and permits withdrawals only from a single, authorized execution entry point defined in separate governance ECIPs. No governance logic, proposal processing, or allocation rules are implemented within this contract. Its sole purpose is to provide a transparent, auditable, and immutable custody layer for protocol-level funds.

This ECIP does not introduce consensus behavior beyond that defined in ECIP-1111, and it does not define how funds are allocated or governed. Those mechanisms are specified independently in downstream ECIPs.

Motivation

Ethereum Classic requires a transparent and protocol-native method to retain the BASEFEE amounts introduced under ECIP-1111. Because Ethereum Mainnet burns the BASEFEE, a deterministic mechanism is needed on Ethereum Classic to receive and hold this value at the protocol level without altering monetary policy or relying on discretionary off-chain actors.

A contract-based Treasury provides this functionality by:

• Offering an immutable, governance-isolated location for protocol revenue.
• Ensuring that accumulated funds are custodied transparently and audited on-chain.
• Providing a deterministic address that all upgraded clients can reference consistently.
• Enforcing strict separation between fund custody (this ECIP) and any governance or allocation logic (defined in separate ECIPs).

By deploying a minimal, immutable vault contract, Ethereum Classic gains a durable mechanism for securely accumulating protocol-level revenue while preserving consensus neutrality and avoiding any implicit trust in privileged intermediaries. This enables the network to adopt BASEFEE redirection under ECIP-1111 without introducing governance or execution semantics into the consensus layer.

Specification

Treasury Address

The Olympia Treasury contract SHALL be deployed at a fixed, deterministic address.
This address SHALL be derived using a reproducible method (e.g., CREATE2) and SHALL be publicly documented prior to testnet activation.

Upon activation of ECIP-1111, all BASEFEE amounts defined in that ECIP SHALL be transferred to this address at the consensus layer.

Client implementations MUST treat this address as the canonical recipient of protocol-level BASEFEE revenue.

Deterministic Deployment

The Treasury contract’s address derivation MUST be identical across all client implementations.
The derivation method SHALL:

• Use a fixed deployer address
• Use a fixed, published salt
• Use the keccak256 hash of the final Treasury contract bytecode

An implementation MAY use CREATE or CREATE2, but the resulting address MUST be predetermined and published in advance of deployment.

A reference derivation method is provided below:

address computedAddress = address(
    uint160(uint256(
        keccak256(
            abi.encodePacked(
                bytes1(0xff),
                deployerAddress,
                salt,
                keccak256(bytecode)
            )
        )
    ))
);

This code is illustrative only; client implementations SHALL rely on the published final address.

Consensus-Layer Funding Source

Upon activation of ECIP-1111:

• The full basefee-derived amount from each EIP-1559 transaction MUST be credited to the Treasury address at the consensus layer.
• This transfer SHALL occur during block finalization. Clients that omit, alter, or redirect this behavior SHALL fork from the canonical chain.

ECIP-1112 defines:

• the immutable Treasury contract,
• the consensus-layer requirement that 100% of the basefee-derived amount be deposited into it, and
• the single authorized withdrawal entry point.

All allocation, smoothing, or redistribution of Treasury-held BASEFEE — including mechanisms defined in ECIP-1114 and ECIP-1115 — occurs strictly after deposit and must use the governance-controlled execution pathway defined in ECIP-1113. ECIP-1112 itself implements no allocation logic or distribution rules.

No additional revenue sources are defined in this ECIP.

Contract Requirements

The Olympia Treasury contract MUST satisfy the following constraints.

Immutability

The contract:

• MUST NOT contain upgrade mechanisms, proxy patterns, delegatecall, or selfdestruct.
• MUST be deployed exactly once.
• MUST NOT allow modification of authorization or upgrade-related state variables.

Minimal Responsibilities

The Treasury contract MUST:

• Accept incoming ETC transfers, including consensus-directed BASEFEE redirection.
• Expose its balance publicly through standard EVM semantics.
• Provide a single restricted withdrawal entry point callable only by the authorized governance executor defined in separate ECIPs.

The Treasury contract MUST NOT:

• Perform governance, voting, proposal validation, or metadata verification.
• Perform accounting logic beyond optional duplicate-execution prevention.
• Modify consensus-layer fee rules or participate in fee calculation.
• Emit governance-level events or track proposal metadata.

Access Control

The Treasury contract MUST:

• Restrict withdrawals to a single, authorized caller address.
• Reject all direct withdrawal attempts from EOAs.
• Reject calls from contracts other than the authorized governance executor.

This ECIP does not define the governance executor contract or its lifecycle; those are specified in ECIP-1113.

Minimal Reference Interface

A minimal Treasury interface MAY be expressed as:

interface ITreasury {
    function release(address recipient, uint256 amount) external;
}

The release() function:

• MUST transfer the specified amount to recipient only if msg.sender is the authorized executor.
• MAY internally track identifiers to prevent duplicate execution.
• MUST NOT implement proposal validation, metadata hashing, or governance logic.

No additional externally callable methods SHALL be exposed.

Event Emission

The Treasury contract MUST emit events sufficient for basic auditability.
At minimum:

• FundsReleased(address indexed recipient, uint256 amount)
• Received(address indexed from, uint256 amount)

These events MUST NOT include governance metadata or proposal identifiers, which are defined in ECIP-1113 and ECIP-1114.

Out-of-Scope Elements

The Treasury contract MUST NOT implement:

• Proposal hashing or metadata binding
• ECFP lifecycle logic
• Governance decision-making
• Timelock, voting, queueing, or scheduling
• Role delegation or admin key models
• Off-chain integrations
• Legal entity handling
• Fee smoothing, escrow logic, or L-curve mechanics

These functions are defined exclusively in downstream ECIPs.

Rationale

Minimal, Immutable Architecture

The Olympia Treasury is intentionally designed as a minimal, immutable contract whose sole role is to receive and hold protocol-level BASEFEE revenue redirected under ECIP-1111. By excluding governance logic, proposal handling, or metadata processing, the Treasury remains simple, auditable, and resistant to operational or upgrade-related risks.

A minimal vault architecture provides:

• Safety at activation — No logic beyond accepting and releasing funds reduces the chance of deployment-time vulnerabilities.
• Long-term stability — With no upgrade paths or privileged roles, the Treasury remains reliable throughout the lifecycle of the protocol.
• Deterministic and verifiable behavior — All clients interact with the same immutable contract at a fixed address.

This approach limits the attack surface and ensures that the Treasury can safely begin accumulating funds before any governance mechanism is deployed.

Separation of Concerns

Strict separation between custody (ECIP-1112) and governance (ECIP-1113/1114) is a core design principle.
This separation ensures:

• The Treasury does not depend on the lifecycle, parameters, or implementation details of future governance systems.
• Governance upgrades or replacements can occur without modifying the Treasury contract.
• Consensus-layer behavior remains fully isolated from application-layer governance logic.

The Treasury exposes only one restricted withdrawal entry point, callable by an external executor defined in separate ECIPs. This creates a clear boundary between value custody and decision-making.

Deterministic Deployment and Client Consistency

A fixed, deterministic Treasury address is necessary for:

• Consensus-layer correctness — Clients must transfer BASEFEE revenue to an identical address to maintain consensus.
• Cross-client interoperability — Deterministic address derivation prevents divergence between implementations.
• Auditability — Participants can reliably verify inflows and contract behavior across all clients.

Using deterministic deployment via CREATE2 further guarantees that the published address can be reproduced independently.

Transparent, Protocol-Level Fund Custody

Redirecting the BASEFEE to a contract rather than burning it requires an on-chain location that is:

• Publicly visible
• Immutable
• Programmatically accessible
• Free of discretionary control

The Treasury contract satisfies these requirements by acting solely as a transparent ledger entry that accumulates protocol-level value without applying any discretionary logic to it.

Rationale Summary

The Treasury’s design emphasizes immutability, minimalism, and strict separation from governance.
This ensures that protocol-level revenue redirected under ECIP-1111 is held securely and transparently, while leaving all governance, allocation, and proposal processes to independently defined ECIPs.
By maintaining this separation, Ethereum Classic gains a durable and verifiable foundation for protocol-level fund custody without introducing dependencies, privileged roles, or upgradeable components into the vault itself.

Related Work

Several EVM-based networks use contract-based mechanisms to receive protocol-level fees or revenue at deterministic, on-chain addresses. These patterns demonstrate the viability of directing endogenous network value into immutable or minimally permissioned contracts for transparent custody.

Examples include:

• Ronin Network
  Implements EIP-1559-style BASEFEE redirection into a contract-based treasury rather than burning the fee.

• Celo (Layer 1)
  Routes gas fees to a fixed contract (Gas Fee Handler) that acts as an on-chain sink for protocol-level value.

• Mantle (Layer 2)
  Directs sequencer revenue into a deterministic on-chain vault contract.

• Polygon (Layer 2)
  Uses contract-based treasuries for receiving protocol-level revenue defined by network rules.

• Arbitrum
  Sends sequencer revenue to a deterministic contract address for transparent custody.

• Optimism
  Uses on-chain sinks for sequencer revenue prior to any governance or allocation logic.

Although these systems differ in governance structure and distribution logic—topics defined separately in ECIP-1113 and ECIP-1114—they share a common architectural pattern relevant to ECIP-1112:
protocol-level revenue is routed to a deterministic, immutable contract that serves as a transparent custody layer.

This approach has proven reliable across multiple EVM ecosystems and informs the design choice to implement the Olympia Treasury as a minimal, immutable vault contract with a fixed, reproducible address.

Implementation

The Olympia Treasury is implemented as a deterministic, immutable smart contract deployed at a fixed address.
Consensus-layer redirection of the BASEFEE amount is defined in ECIP-1111; this ECIP (1112) specifies only the contract that receives those funds.

Client Responsibilities

All Ethereum Classic client implementations MUST:

• Hardcode the Treasury address
  Clients MUST treat the published Treasury address as the canonical destination for protocol-level BASEFEE revenue following activation of ECIP-1111.

• Apply consensus-layer redirection
  During block finalization, clients MUST credit the full BASEFEE amount to the Treasury address in accordance with ECIP-1111.
  Clients MUST NOT expose alternative behaviors (e.g., burning).

• Maintain full EIP-1559 semantics
  Clients MUST preserve all EIP-1559 rules for calculating the basefee and miner priority fees, with the only modification being the redirection of the BASEFEE component to the Treasury address.

Failure to implement this behavior precisely SHALL result in a consensus fork.

Deployment Artifacts

Prior to activation on testnet and mainnet, the following SHALL be published:

• The Treasury contract’s bytecode
• The selected deployment method (CREATE or CREATE2)
• The fixed, deterministic address
• The derivation parameters (e.g., deployer address and salt), if using CREATE2

Deterministic publication of these artifacts ensures cross-client reproducibility and enables consistent verification by implementers and auditors.

Test Coverage and Validation

Testing MUST validate the following behaviors:

1. Correct Consensus Redirection
   Each client MUST correctly compute the BASEFEE amount and transfer it to the Treasury address in every post-activation block.

2. Cross-Client Consistency
   All upgraded clients MUST produce identical state transitions and balances for the Treasury address under shared test vectors.

3. Event Emission
   The Treasury contract MUST emit its defined events (FundsReleased, Received) during relevant operations and MUST NOT emit governance-related metadata.

4. Access Control Behavior
   The Treasury contract MUST accept incoming transfers from consensus-layer redirection and MUST reject unauthorized withdrawal attempts.

5. Reproducible Deployment
   The published deployment parameters MUST reproduce the exact Treasury address across all client implementations.

These tests ensure that the Olympia Treasury behaves as a minimal, deterministic vault compatible with ECIP-1111’s consensus-layer rules and suitable for integration with the governance executor defined in ECIP-1113.

Implementation Summary

This ECIP defines the immutable contract that receives protocol-level BASEFEE revenue.
Client software is responsible only for:

• redirecting BASEFEE to this contract, and
• ensuring consistent state-transition behavior across implementations.

All governance logic, proposal processing, and withdrawal authorization are defined outside this ECIP.

Modular Treasury Deployment

The Olympia Treasury is implemented as a standalone, immutable smart contract.
It MAY be deployed and activated independently of any downstream governance components defined in separate ECIPs.
This separation enables a phased rollout consistent with the modular activation strategy introduced in ECIP-1111.

Pre-Governance Activation

Upon activation of ECIP-1111, the Treasury SHALL begin passively accumulating BASEFEE revenue.
No governance contracts or auxiliary infrastructure are required for the Treasury to function as a secure, protocol-level vault during this phase.

Security During the Accumulation Phase

At deployment, the Treasury’s authorized executor address SHALL be configured to a value that cannot satisfy the contract’s access control checks.
Until a valid executor is established under a separate governance ECIP, the Treasury’s withdrawal entry point MUST NOT be callable by any account or contract.
Any attempted withdrawal from unauthorized addresses MUST revert.

This configuration ensures that all accumulated funds remain securely locked, regardless of the timing or readiness of governance systems.

Deployment Advantages

• Forward Compatibility — The Treasury can operate unchanged across future governance upgrades because it contains no governance logic of its own.
• Security Isolation — The Treasury’s immutability and minimalism reduce the attack surface during the period before governance deployment.
• Phased Rollout Support — ECIP-1111 and ECIP-1112 can be activated as soon as they are ready, while governance mechanisms defined in other ECIPs can be deployed, audited, and reviewed independently.

This modular deployment model ensures that protocol revenue capture can begin immediately once ECIP-1111 is active, without requiring simultaneous activation of governance or proposal systems.

Backwards Compatibility

ECIP-1112 introduces no changes to transaction formats, opcode behavior, or EVM semantics.
It defines only the immutable Treasury contract that receives the BASEFEE amounts redirected by ECIP-1111.
All consensus-layer changes related to BASEFEE handling are specified exclusively in ECIP-1111.

Node Behavior

• Upgraded Clients
  Clients that implement ECIP-1111 and recognize the Treasury address defined in this ECIP will:
  • Process Type-0 (Legacy), Type-1 (Access List), and Type-2 (EIP-1559) transactions correctly.
  • Redirect the computed BASEFEE amount to the Treasury address during block finalization.
• Non-Upgraded Clients
  Clients that do not implement ECIP-1111 and ECIP-1112 will:
  • Fail to process Type-2 transactions correctly.
  • Continue burning or mishandling the BASEFEE.
  • Remain unaware of the Treasury contract address.

  Such clients will diverge at the activation block, forming a permanent consensus fork.

Contract and Tooling Compatibility

• Legacy Transactions
  Type-0 transactions remain valid and unaffected.

• Access List Transactions (Type-1)
  Type-1 transactions introduced by ECIP-1103 remain valid and unaffected, as ECIP-1112 adds no new semantics for transaction execution.

• Existing Contracts
  Smart contracts that do not reference the BASEFEE or the Treasury address continue to function unchanged.

• Tooling and dApps
  Applications that do not rely on EIP-1559 semantics remain fully functional.
  Tooling that supports Type-2 transactions (EIP-1559) MAY require updates to reflect that Ethereum Classic redirects the BASEFEE to the Treasury address rather than burning it, as defined in ECIP-1111.
  No changes are required for transaction submission or execution semantics.

• Treasury Contract Independence
  The Treasury contract can securely accumulate funds even if downstream governance contracts defined in other ECIPs are not yet deployed.

This ECIP preserves backward compatibility for all existing transaction types and smart contracts.
Only clients that fail to upgrade to support ECIP-1111 and recognize the Treasury address defined here will fork from the canonical chain at activation.

Security Considerations

The Olympia Treasury is designed as an immutable, governance-isolated vault whose only responsibilities are to receive protocol-level BASEFEE revenue and permit withdrawals from a single authorized executor defined in a separate ECIP. The following security considerations apply.

1. Contract Immutability

• The Treasury contract MUST be deployed exactly once and MUST NOT contain any upgrade mechanisms.
• No delegatecall, selfdestruct, proxy patterns, or privileged administrative keys SHALL be present.
• Immutability ensures that neither the contract’s authorization logic nor its withdrawal behavior can be modified after deployment.

2. Access Control

• Withdrawals MUST only succeed when initiated by the authorized executor address defined in a separate governance ECIP.
• Until such an executor is deployed and configured, the withdrawal entry point MUST NOT be callable by any account or contract.
• All unauthorized withdrawal attempts MUST revert.

This ensures that protocol-level funds remain securely locked during the accumulation phase and cannot be accessed prematurely.

3. Consensus Enforcement

• Clients MUST correctly redirect all BASEFEE amounts to the Treasury address during block finalization as defined in ECIP-1111.
• Any deviation from this rule SHALL cause a permanent consensus fork.
• The Treasury contract itself performs no consensus logic; it relies on client implementations to uphold the protocol rules strictly.

4. Minimal Attack Surface

• The Treasury MUST NOT implement governance logic, proposal validation, metadata hashing, or voting semantics.
• Its design SHALL remain minimal and predictable, reducing potential vulnerabilities arising from complex logic.
• The contract SHOULD track only what is necessary to prevent duplicate withdrawals, if applicable.

5. Deployment and Initialization Safety

• At deployment, the executor address MUST be set to a value that cannot satisfy the Treasury’s authorization checks until the designated governance executor is deployed under a separate ECIP.
• This ensures that all funds remain locked and inaccessible during the pre-governance accumulation period.

6. Audit and Testing Requirements

• The Treasury contract SHALL undergo third-party security audits prior to mainnet deployment.
• Formal verification and static-analysis tools SHOULD be used to validate invariants such as:
  • Correct access control
  • Absence of upgrade paths
  • Safe handling of Ether transfers
• Testnet deployments MUST confirm:
  • Accurate BASEFEE accumulation
  • Correct rejection of unauthorized withdrawal attempts
  • Cross-client consistency under ECIP-1111 redirection

Security Considerations Summary

The Olympia Treasury provides a secure and immutable custody layer for protocol-level revenue. Its minimal design, strict access control, and reliance on consensus-layer enforcement ensure that funds are safely accumulated and remain inaccessible until governance becomes active under separate ECIPs.

Related ECIPs in the Olympia Upgrade

ECIP-1112 is one of four coordinated proposals that together define the Olympia framework for protocol-level funding on Ethereum Classic.

• ECIP-1111 — Olympia EVM and Protocol Upgrades
  Activates EIP-1559 and EIP-3198 on Ethereum Classic and redirects the BASEFEE amount to the Treasury address defined in this ECIP.

• ECIP-1112 — Olympia Treasury Contract
  Defines the deterministic, immutable smart contract that receives and holds all redirected BASEFEE revenue in a governance-isolated vault.

• ECIP-1113 — Olympia DAO Governance Framework
  Specifies the governance architecture, including the authorized executor contract that is permitted to initiate Treasury withdrawals.

• ECIP-1114 — Ethereum Classic Funding Proposal Process
  Defines the standardized proposal format and lifecycle used by the governance system to authorize Treasury disbursements.

Interdependency Summary

• ECIP-1111 provides the protocol-level BASEFEE revenue source.
• ECIP-1112 defines the immutable contract that stores this revenue.
• ECIP-1113 establishes the governance executor permitted to withdraw funds.
• ECIP-1114 defines the proposal structure and lifecycle used by governance to authorize withdrawals.

These ECIPs are designed for modular activation:

• ECIP-1111 and ECIP-1112 MAY be activated first to begin revenue accumulation.
• ECIP-1113 and ECIP-1114 MAY be deployed later to enable controlled, on-chain authorization of Treasury withdrawals.

Copyright

Copyright and related rights waived via
CC0

Appendix: EVM Precedents for Treasury Design

Several EVM-based networks use deterministic, contract-based mechanisms for receiving protocol-level fees or revenue. These designs demonstrate established patterns for routing endogenous network value into transparent, on-chain custody locations that operate independently of execution or governance logic.

Treasury Design Precedents

Design Principles Relevant to ECIP-1112

• Immutable Contract Custody
  Several networks use contracts with no upgrade mechanisms to provide predictable, tamper-resistant storage of protocol-level value.

• Deterministic Addresses
  Many systems deploy fee-receiving contracts at fixed or precomputed addresses to ensure consistent cross-client behavior.

• Automatic Revenue Routing
  Protocol-defined flows (e.g., BASEFEE, gas fees, sequencer revenue) are commonly forwarded directly into a contract without discretionary control.

• Transparent On-Chain Accounting
  Contract-based treasuries allow all inflows to be observed and audited directly on-chain.

ECIP-1112 adopts these proven design patterns by defining an immutable, deterministic Treasury contract that receives protocol-level BASEFEE revenue redirected under ECIP-1111, while leaving governance and allocation mechanics to separate ECIPs.