ECIP 1112: Olympia Treasury Contract
Author | Cody Burns, Chris Mercer |
---|---|
Discussions-To | https://github.com/orgs/ethereumclassic/discussions/530 |
Status | Draft |
Type | Meta |
Created | 2025-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 viaCREATE
orCREATE2
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.
- The contract SHALL include no proxy pattern, upgrade hooks,
- Traceability:
- Emits
Transfer
,Receive
, andProposalExecuted
events for auditability.
- Emits
- Transparency:
- Public
view
methods for accessing balance and transaction metadata.
- Public
- 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 {}
// --- 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 ---
}
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/orexecute()
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 viaBASEFEE
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-1559BASEFEE
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.
Related Work
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-1559BASEFEE
into a DAO-controlled treasury. Funds are used to support infrastructure, community grants, and long-term protocol maintenance.
View Contract -
Celo (Layer 1)
Uses aGas Fee Handler
to redirect transaction fees toward climate initiatives and community development via a governance-controlled treasury.
View Govenance and Treasury Contracts -
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 redirectBASEFEE
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:
-
Ronin Treasury Contract
0x22ce...694e
-
Celo Governance and Treasury Gas Fee Handler
0x471E...8438
-
Mantle Fee Mechanism
https://docs.mantle.xyz/network/system-information/fee-mechanism -
Polygon CDK (Modular Rollup Framework)
https://docs.polygon.technology/
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 theBASEFEE
in every post-upgrade block. -
Fee Redirection Logic:
The default EIP-1559 burn behavior MUST be replaced with logic that transfers theBASEFEE
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
orCREATE2
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 redirectBASEFEE
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, nodelegatecall
, 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 redirectBASEFEE
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 achain 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.
Related ECIPs in the Olympia Upgrade
- ECIP-1111: Olympia EVM and Protocol Upgrades
- ECIP-1112: Olympia Treasury Contract
- ECIP-1113: Olympia DAO Governance Framework
- ECIP-1114: Ethereum Classic Funding Proposal Process
Copyright
Copyright and related rights waived via
CC0