ECIP 1112: Olympia Treasury Contract

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 exclusively through the Olympia DAO (ECIP-1113) and the Ethereum Classic Funding Proposal (ECFP) process (ECIP-1114).

All BASEFEE revenue is redirected at the protocol level and disbursed only upon successful, on-chain approval of an ECFP, ensuring alignment with Ethereum Classic’s principles of immutability, decentralization, and transparency.

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 and redirects BASEFEE revenue — all BASEFEE amounts SHALL be transferred 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 the Olympia DAO (ECIP-1113), which is the only governance-authorized execution contract permitted to initiate disbursements. All withdrawals MUST be initiated through on-chain proposals following the Ethereum Classic Funding Proposal (ECFP) process (ECIP-1114).

Execution of approved ECFPs uses a hash-bound disbursement model consistent with ECIP-1114’s “Metadata and Proposal Integrity” section, ensuring that each release is cryptographically bound to immutable proposal metadata (proposal ID, recipient, amount, metadata CID, and chain ID).

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. It follows the Modular Activation approach described in ECIP-1111, enabling the Treasury to accumulate funds securely prior to governance activation.

Off-chain fiat interfacing and administrative execution, where required, SHALL be performed by the Ethereum Classic DAO LLC — a legally registered entity that operates strictly under binding instructions from Olympia DAO governance, with no discretionary authority.

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. This has led to inconsistent resource availability, governance bottlenecks, and exposure to central points of failure.

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 ECIP-1111 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 by making protocol revenue scale with ecosystem activity.
• Strengthens long-term sustainability for client maintenance, infrastructure services, and security audits, as formalized in ECIP-1113 and executed via ECIP-1114.
• Enforces governance neutrality by ensuring that all disbursements are approved through the permissionless, on-chain ECFP process.
• Eliminates dependency on trusted intermediaries by replacing off-chain discretion with immutable, transparent, and verifiable on-chain execution.

By capturing endogenous protocol revenue and routing it into an immutable, DAO-controlled treasury, Ethereum Classic can secure the financial infrastructure necessary for a resilient, decentralized, and self-sustaining ecosystem — consistent with the Modular Activation strategy in ECIP-1111.

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 defined in ECIP-1111 — as the canonical recipient of the BASEFEE.

• 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 (e.g., DAO executor or governance multisig used for deployment).
• 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:
  • No proxy pattern, upgrade hooks, selfdestruct, delegatecall, or runtime modification opcodes.
  • Deployment MUST be single-step and final, with no admin or owner-controlled logic.
• Traceability:
  • MUST emit standardized events (FundsReleased, Receive) for auditability.
• Transparency:
  • Public view methods for accessing balance and transaction metadata.
• Access Control:
  • Revert all direct withdrawal attempts from EOAs or unauthorized contracts.

Governance Integration

The Treasury contract SHALL expose a restricted interface callable only by the DAO-designated execution contract defined in ECIP-1113.
This interface MUST include:

• release() and/or execute() disbursement functions, callable only by the authorized DAO executor.
• Execution MUST follow the hash-bound disbursement model described in ECIP-1114, where the proposalHash is computed as:

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

• This hash MUST match exactly between the DAO proposal and Treasury execution call to ensure one-time, verifiable disbursement.

Example: Olympia Treasury Contract

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

    // --- BEGIN TREASURY RELEASE FUNCTION ---
    /// @notice Executes an approved proposal via hash-bound disbursement
    /// @dev This function is called only by the authorized DAO executor contract
    ///      after an on-chain vote and timelock delay have completed.
    ///
    /// This function ensures:
    /// - Execution happens only once per proposalHash
    /// - Funds are transferred only to valid recipients
    /// - Emits a standardized event for auditability
    ///
    /// This function MUST NOT include any voting or validation logic.
    /// It is a pure disbursement hook to preserve governance separation.
    /// @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);
    }
    // --- END TREASURY RELEASE FUNCTION ---
}

Execution Control and Spam Mitigation

• DAO-Only Execution: Only the DAO executor MAY invoke disbursement functions.
• Proposal Isolation: Proposals MUST be validated externally; the Treasury SHALL enforce execution-only logic.
• Spam Protection: Throughput controls are the responsibility of DAO governance per ECIP-1113 and ECIP-1114, not 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 redirected under ECIP-1111.

This design ensures:

• No operational complexity at launch.
• No upgrade paths or privileged access.
• A stable foundation for phased governance activation via the Ethereum Classic Funding Proposal Process.

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
  With block rewards decreasing under ECIP-1017, 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
  More network usage → more transactions → more Treasury revenue → more development → more adoption.
  This virtuous cycle aligns developers, miners, and users around shared network growth.

• Open and Permissionless Access
  Unlike closed foundations or opaque grant programs, the Treasury enables any contributor to request funds through transparent, on-chain ECFPs per ECIP-1114.

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

• Governance Modularity
  Governance logic resides outside the Treasury in the Olympia DAO framework (ECIP-1113).
  This separation allows DAO upgrades or replacements without modifying the Treasury contract.

Ecosystem Precedents

Multiple EVM-based networks successfully route protocol-level fees into DAO-governed treasuries for public goods funding. These examples validate the neutrality, feasibility, and sustainability of the Olympia model:

• Ronin Network — Routes EIP-1559 BASEFEE to a DAO-controlled treasury for infrastructure and ecosystem growth.
• Celo (Layer 1) — Redirects gas fees to a governance-managed treasury for climate and community initiatives.
• Mantle (Layer 2) — Directs sequencer revenue into a DAO treasury for grants and tooling.
• Polygon CDK — Allows sovereign rollups to integrate EIP-1559-compatible treasury hooks.
• Arbitrum DAO — Manages sequencer revenue through on-chain AIP governance.
• Optimism — Allocates sequencer revenue to Retroactive Public Goods Funding (RPGF).
• Avalanche Subnets — Some subnets use validator-governed fee-to-treasury models.

These precedents demonstrate that redirecting endogenous protocol revenue into an immutable, transparent treasury is a proven, incentive-aligned strategy for funding public goods without inflation or centralized gatekeepers.

Summary

The Olympia Treasury advances Ethereum Classic’s principles of immutability, decentralization, and transparency, while introducing a secure and credible method of funding long-term development.
Its separation from governance logic — per ECIP-1113 — ensures safety during deployment and flexibility for future governance upgrades.
Its enforcement of the ECIP-1114 ECFP process ensures all disbursements are transparent, standardized, and verifiably bound to approved on-chain proposals.

Related Work

The Olympia Treasury design builds on proven patterns across the EVM ecosystem in which protocol-level revenue — such as EIP-1559 BASEFEE or sequencer fees — is routed to on-chain treasuries and allocated through DAO governance.
These precedents demonstrate that redirecting endogenous network revenue into transparent, governance-controlled treasuries is an effective, neutral, and sustainable strategy for funding public goods without inflation or centralized gatekeepers.

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

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

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

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

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

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

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

Note: L2 examples above typically fund treasuries via sequencer revenue rather than direct BASEFEE capture; they are included as governance and treasury-design precedents relevant to Ethereum Classic’s application-layer governance and distribution model under ECIP-1113 and ECIP-1114.

Addendum: Verified Contract References

For deeper implementation study and validation, the following verified contracts and governance docs illustrate relevant patterns:

• Ronin Network — Ronin Treasury Contract
• Celo — Governance & Fee Handler
• Mantle — Mantle Treasury
• Polygon — Polygon Community Treasury
• OP Stack (Base / Optimism) — Governance Docs
• Arbitrum DAO — Arbitrum Treasury
• Optimism RPGF — Optimism Atlas
• Gitcoin DAO — Site
• Avalanche Subnets — Subnet Docs
• zkSync Era / Scroll — zkSync Docs · Scroll Docs

These references support the neutrality, feasibility, and resilience of protocol-level fee redirection and provide governance models applicable to the Olympia Treasury’s integration with ECIP-1113 and ECIP-1114.

Implementation

The Olympia Treasury is implemented at the consensus layer as part of the Olympia upgrade defined in ECIP-1111.
Client software MUST redirect all EIP-1559 BASEFEE to the fixed Treasury address and MUST NOT expose any alternative handling (e.g., burning), ensuring deterministic behavior across all upgraded implementations.

Client Responsibilities

• Consensus Enforcement
  Hardcode the Olympia Treasury address as the canonical recipient of BASEFEE in every post-fork block.
  (Clients that fail to enforce this behavior will fork from the canonical Ethereum Classic chain.)

• Fee Redirection Logic
  Replace Ethereum mainnet’s burn behavior with a consensus-layer transfer of the BASEFEE to the Olympia Treasury contract (ECIP-1112).

• Gas Accounting Adjustments
  Maintain full EIP-1559 semantics — including dynamic basefee calculation and miner priority tips — while adjusting accounting to reflect Treasury accumulation.

Deployment Artifacts

• Publish the Treasury contract’s bytecode, deployment method (CREATE or CREATE2), and deterministic address with the Olympia upgrade release.
• Use deterministic deployment to ensure reproducibility across all client implementations and simplify test vector creation.
• Complete independent security audits of the final contract before mainnet deployment.

Test Coverage and Validation

• Mordor Testnet
  Validate:
  1. Accurate BASEFEE transfer to the Treasury in every block.
  2. Correct emission of all required transparency events (Transfer, Receive, and governance-related logs).
  3. Compatibility with governance executor calls (propose(), release(), execute()).
  4. Cross-client consensus alignment using shared test vectors and replay protection validation.
• Governance Integration
  Perform end-to-end testing with the Olympia DAO executor (ECIP-1113) and the Ethereum Classic Funding Proposal (ECFP) process (ECIP-1114) to ensure:
  • Proposal hash binding matches ECIP-1114’s “Metadata and Proposal Integrity” rules.
  • One-time execution per proposal hash.
  • Full on-chain auditability of disbursement events.

These requirements ensure the Olympia Treasury operates as a secure, deterministic, and auditable protocol-level vault, fully interoperable with the governance and funding mechanisms defined in ECIPs 1113 and 1114.

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 the formal funding proposal process (ECIP-1114), enabling a phased rollout consistent with the Modular Activation strategy defined in ECIP-1111.

Pre-Governance Activation

• The Treasury 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 in this phase.

Security During Accumulation Phase

• All disbursement functions (release(), execute()) SHALL remain inaccessible unless called by the authorized DAO executor defined in ECIP-1113.
• Any withdrawal attempt from EOAs or unauthorized contracts MUST revert.
• This ensures funds remain locked until on-chain governance is active and able to process ECFPs under ECIP-1114.

Deployment Advantages

• Forward Compatibility — Governance modules may be integrated later without modifying the deployed Treasury.
• Security Isolation — Treasury logic is fully decoupled from governance execution, minimizing attack surface in the early phase.
• Phased Rollout Support — Supports staggered deployment of ECIPs 1111–1114, allowing independent audit and activation of each component while enabling early accumulation of funds.

This deployment pattern ensures that protocol revenue capture begins as soon as ECIP-1111 is active, while governance, proposal, and execution layers (ECIP-1113 and ECIP-1114) can be deployed after thorough testing and community onboarding.

Backwards Compatibility

The Olympia Treasury contract modifies the default EIP-1559 behavior 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 per ECIP-1111.

Node Behavior

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

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

  • Fail to recognize Type-2 transactions.
  • Continue to burn the BASEFEE or process it incorrectly.
  • Remain unaware of the Treasury contract address.

  These nodes will diverge at the fork block, causing a permanent consensus split from the canonical Ethereum Classic chain.

Contract and Tooling Compatibility

• Legacy Transactions: Type-0 transactions remain valid and unaffected.
• Existing Contracts: Deployed contracts that do not reference the BASEFEE or Treasury address will continue to function normally.
• Tooling and dApps: Applications that are EIP-1559-agnostic remain fully functional.
• Governance Layer: The Treasury can accumulate funds without ECIP-1113/ECIP-1114 deployed. Disbursements require both governance and proposal processes to be active.

This upgrade preserves backward compatibility for legacy transaction types and contracts, while introducing a consensus-enforced funding redirection for post-fork blocks.
As with ECIP-1111, clients that do not upgrade will fork permanently from the canonical chain at activation.

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 addressed across the following domains:

1. Contract Immutability and Access Control

• Immutable Deployment — The Treasury is deployed once and cannot be upgraded.
  No proxy mechanisms, no delegatecall, no selfdestruct, and no admin keys are present.
• Restricted Execution — Only the authorized DAO executor defined in ECIP-1113 may call disbursement functions (release() / execute()).
• Minimal Attack Surface — The contract performs no voting or validation logic; it is strictly a disbursement hook bound to approved proposals under ECIP-1114.

2. DAO Governance and Integration Risks

• Governance Risks Out of Scope — Risks such as spam proposals, low quorum attacks, or vote manipulation are mitigated at the DAO layer per ECIP-1113.
• Fail-Safe Treasury Design — Even if DAO governance fails or is captured, funds remain inaccessible without a valid DAO executor call that matches an approved proposal hash.

3. Client Enforcement and Network Safety

• Consensus Enforcement — Clients MUST redirect the BASEFEE to the Treasury address as part of block finalization logic (per ECIP-1111).
  Any deviation results in a permanent consensus fork.
• Replay Protection — Proposal hashes include chainid to prevent replay attacks across forks or testnets.

4. Proposal Execution Integrity

• Hash-Bound Disbursement — All disbursements require a proposalHash computed exactly per ECIP-1114’s “Metadata and Proposal Integrity” rules:
  (ecfpId, recipient, amount, metadataCID, chainid).
• One-Time Execution — Each proposal hash may be executed only once, preventing double spending.

5. Audit and Testing Strategy

• Independent Security Audit — The Treasury contract SHALL undergo external audits prior to deployment.
• Formal Verification — Static analysis and formal verification tools (e.g., Slither, MythX) SHALL be used to detect vulnerabilities.
• Testnet Simulation — Mordor Testnet SHALL be used to validate BASEFEE redirection, governance integration, and disbursement logic before 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 independent audits, formal verification, and testnet validation, it provides a secure foundation for decentralized, on-chain funding in the Ethereum Classic ecosystem.

Related ECIPs in the Olympia Upgrade

ECIP-1112 is one of four coordinated proposals that together introduce sustainable, decentralized, and transparent protocol funding for Ethereum Classic:

• ECIP-1111 — Olympia EVM and Protocol Upgrades
  Activates EIP-1559 and EIP-3198 on Ethereum Classic and redirects the BASEFEE to the Olympia Treasury instead of burning it.

• ECIP-1112 — Olympia Treasury Contract
  Defines the immutable, governance-isolated smart contract that receives all redirected BASEFEE revenue and holds it until released by on-chain governance.

• ECIP-1113 — Olympia DAO Governance Framework
  Specifies the decentralized governance architecture that serves as the sole authorized executor for Treasury disbursements, including proposal submission, voting, and time-locked execution.

• ECIP-1114 — Ethereum Classic Funding Proposal Process
  Establishes the standardized, permissionless proposal format (ECFP) for requesting funds from the Treasury, ensuring transparent, hash-bound, and verifiable allocation of protocol-level funding.

Interdependency Summary

• ECIP-1111 enables protocol-level revenue generation via BASEFEE redirection.
• ECIP-1112 deploys an immutable vault to store that revenue, isolated from governance logic.
• ECIP-1113 creates the governance layer that can authorize Treasury disbursements.
• ECIP-1114 defines the standardized proposal process that ECIP-1113 enforces for all disbursements.

All four ECIPs are designed for modular activation:

• ECIP-1111 and ECIP-1112 can be deployed first, enabling revenue accumulation.
• ECIP-1113 and ECIP-1114 can be deployed later, enabling controlled, on-chain governance of Treasury funds.

Copyright

Copyright and related rights waived via
CC0

Appendix: EVM Precedents for Treasury Design

The Olympia Treasury (ECIP-1112) is an immutable, governance-isolated smart contract that receives protocol-level revenue redirected at the consensus layer under ECIP-1111.
Its design builds on established treasury mechanisms from other EVM-compatible networks that have demonstrated the ability to securely hold and disburse large-scale on-chain funds under community governance.

Treasury Design Precedents

Key Design Lessons Applied in ECIP-1112

• Immutable Vaults — Treasury contracts must be immutable after deployment, with no upgrade paths or admin keys; ECIP-1112 enforces this by design.
• Consensus-Layer Revenue Routing — Like Ronin and Celo, ECIP-1112 receives funds automatically at the protocol layer, preventing diversion or bypass.
• Governance-Isolated Execution — Treasury disbursements are possible only via an authorized governance contract (ECIP-1113) using a hash-bound execution model.
• Transparent On-Chain Accounting — All inflows and outflows are recorded on-chain, with standardized events to enable third-party indexing and auditing.
• Compatibility with Milestone-Based Funding — The treasury can support single, staged, or recurring disbursements as defined in funding proposals (ECIP-1114).

By adapting these proven treasury models to Ethereum Classic’s Proof-of-Work consensus and immutability principles, ECIP-1112 ensures secure, transparent, and sustainable custody of protocol-level funds.