ECIP 1111: Olympia EVM and Protocol Upgrades

Simple Summary

This proposal introduces EIP-1559 and EIP-3198 to Ethereum Classic via a hard fork named Olympia. These upgrades enhance EVM compatibility and improve gas pricing mechanics by adopting Ethereum’s EIP-1559 dynamic fee model. Instead of burning the BASEFEE, the protocol redirects it to the Olympia Treasury (defined in ECIP-1112), a decentralized funding contract governed by Olympia DAO (ECIP-1113).

This enables Ethereum Classic to establish a protocol-level funding mechanism that is sustainable and non-inflationary. All BASEFEE revenue is redirected to a decentralized on-chain treasury, preserving Proof-of-Work consensus and the core principles of immutability and decentralization.

Until governance is activated, the Treasury accumulates funds passively with no disbursements allowed — ensuring secure, trustless accumulation.

Abstract

This ECIP proposes the activation of select Ethereum protocol upgrades on Ethereum Classic under the hard fork name Olympia. Specifically, it introduces:

• EIP-1559: Implements a dynamic BASEFEE mechanism to improve fee predictability and market efficiency.
• EIP-3198: Adds the BASEFEE opcode for full EVM compatibility.

These changes improve interoperability with Ethereum and other EVM-based networks, while preserving Ethereum Classic’s Proof-of-Work consensus and principles of immutability.

All BASEFEE revenue is redirected to the Olympia Treasury (ECIP-1112), an immutable smart contract governed by on-chain proposals submitted through Olympia DAO (ECIP-1113). Proposal execution and fiat interfacing are supported by the Ethereum Classic DAO LLC, a Wyoming-registered legal wrapper that performs administrative actions under binding instructions from on-chain governance, without discretionary control.

This upgrade explicitly excludes changes related to Ethereum’s Proof-of-Stake transition, including validator operations and beacon-chain-based randomness, which are not applicable to Ethereum Classic. Implementation requires coordinated deployment across client software and node operators, with block heights to be finalized for both Mordor Testnet and Mainnet activation. Olympia DAO does not launch with a governance token. The system supports future upgrades to more decentralized governance models, including quadratic voting, veOLY staking, and soulbound token delegation (see ECIP-1113).

EIP Summaries and Expected Action

Included in Olympia Upgrade

• EIP-1559 – Fee Market Change
  Introduces a new transaction type with a dynamically adjusting BASEFEE per gas and an optional miner tip (priorityFee). On Ethereum Classic, unlike Ethereum Mainnet, the BASEFEE is not burned. Instead, it is redirected to the Olympia Treasury, an on-chain development fund governed by Olympia DAO. This design ties network activity directly to long-term funding for infrastructure, tooling, and client maintenance — critical as block rewards continue to decline under ECIP-1017. It aligns incentives between developers, miners, and users by creating a sustainable, non-inflationary security and development budget.

• EIP-3198 – BASEFEE Opcode
  Adds a new opcode that returns the current block’s BASEFEE, enabling smart contracts to read fee market conditions in real time. This supports gas-optimized applications, fee-aware protocols, and consistent behavior across EVM chains.

This ECIP proposes activation of both EIPs at the following block heights (to be finalized after successful testnet deployment):

• Mordor Testnet: TBD
• Ethereum Classic Mainnet: TBD
  (See Activation section for coordination details)

For technical implementation details, see the Specification section below.

Motivation

The Olympia upgrade enhances Ethereum Classic’s protocol by integrating widely adopted Ethereum Virtual Machine (EVM) features — specifically EIP-1559 and EIP-3198. These changes bring Ethereum Classic into closer alignment with the modern EVM ecosystem, improving interoperability, developer experience, and economic sustainability.

By adopting these enhancements, Ethereum Classic gains four key benefits:

1. Improved EVM Compatibility
   Enables seamless deployment of EVM-standard smart contracts and dApps on Ethereum Classic without requiring modification or network-specific workarounds. This reduces integration complexity and fosters cross-chain development.

2. Modernized Fee Market
   EIP-1559 introduces a dynamic base fee and priority fee mechanism, offering more predictable gas pricing and a better user experience. This upgrade standardizes transaction behavior across EVM networks and improves usability.

3. Increased Utility and Adoption
   Aligning with the EVM upgrade roadmap positions Ethereum Classic as a viable, Proof-of-Work alternative to Ethereum for developers, tooling providers, and infrastructure operators. Compatibility attracts broader adoption and ecosystem support.

4. Sustainable Protocol Funding
   Redirecting the BASEFEE to the Olympia Treasury establishes a transparent, non-inflationary mechanism for protocol-level funding, aligned with ECIP-1017’s fixed monetary schedule. This approach eliminates reliance on centralized entities or inflationary subsidies. This supports long-term client maintenance, infrastructure, and security as block rewards decline under ECIP-1017. It replaces reliance on centralized grants or off-chain foundations with a transparent, on-chain system governed by Olympia DAO.

Together, these changes reinforce Ethereum Classic’s position as a secure, decentralized, and developer-friendly Proof-of-Work smart contract platform.

While EIP-1559 originated on Ethereum, its inclusion here does not violate Ethereum Classic’s principles of immutability or censorship resistance. It is an optional transaction format that improves gas predictability, enables sustainable protocol funding, and aligns incentives — all without changing historical state or requiring trust in centralized actors.

Off-chain execution, fiat handling, and administrative duties are performed by the Ethereum Classic DAO LLC — a legally registered entity that operates under binding instructions from Olympia DAO, as defined in ECIP-1114.

Specification

The Olympia upgrade activates the following Ethereum protocol improvements on Ethereum Classic. All specifications are implemented as described in the canonical Ethereum Improvement Proposals (EIPs):

Protocol Changes Adopted from Ethereum’s London Hard Fork

• EIP-1559 – Fee Market Change
  Introduces a new transaction format with a dynamically adjusting basefee per block and an optional priorityFee (tip) for miners (fee adjustment formula based on block gas usage).

  • On Ethereum Classic, the basefee is not burned. Instead, it is redirected to the Olympia Treasury, a decentralized, immutable contract for funding network development.
  • Miner tips (priorityFee) remain payable to block producers as direct compensation for inclusion.

• EIP-3198 – BASEFEE Opcode
  Introduces opcode 0x48 (BASEFEE) to the EVM, allowing smart contracts to access the current block’s basefee. This improves fee-aware contract design and enhances gas estimation tools.

Ethereum Classic–Specific Behavior

• The basefee is redirected (not burned) to a designated treasury address managed by the Olympia Treasury contract (ECIP-1112).
• The treasury contract is immutable, non-upgradable, and governed exclusively by on-chain proposals submitted and executed through Olympia DAO (ECIP-1113).

Example: Hardcoded BASEFEE Redirection (Solidity)

// Core-Geth basefee redirection logic (simplified pseudocode)
address constant TREASURY = 0x4242...ecip1112; // Replace with final deployed treasury address

function finalizeBlock(...) internal {
    ...
    uint256 baseFeeAmount = block.basefee * gasUsed;
    payable(TREASURY).transfer(baseFeeAmount); // Send to Olympia Treasury
    ...
}

🔒 Consensus-critical logic: This redirection is enforced within the client’s block finalization process and cannot be bypassed or altered without a hard fork. The BASEFEE is transferred to the Olympia Treasury at the protocol level before miner rewards are issued.

No additional EVM changes, consensus rules, or opcodes are introduced in this upgrade.

Implementation Notes

• Client developers must ensure full compliance with EIP-1559 and EIP-3198 behavior, adjusted only to redirect basefee instead of burning it.
• Reference vectors from Ethereum Mainnet must be adjusted to reflect treasury accumulation for block-level fee accounting.
• A coordinated network upgrade at predefined block heights will activate these changes on both Mordor Testnet and Ethereum Classic Mainnet (see Activation section).

Clients and infrastructure providers MUST validate implementation using test vectors and cross-client consensus tools prior to activation. Testing MUST include BASEFEE accounting, transaction type behavior, and treasury accumulation consistency.

Monetary Policy Consideration

Redirecting the BASEFEE to the Olympia Treasury replaces Ethereum’s burn mechanism with treasury accumulation, without altering ETC’s total supply or issuance schedule. Monetary policy defined in ECIP-1017 remains fully intact. This change redirects value that would otherwise be burned into a transparent funding mechanism — preserving monetary integrity while enabling sustainable development.

Rationale

Simplicity by Design

The Olympia Upgrade introduces no additional consensus-layer complexity beyond the well-established specifications of EIP-1559 and EIP-3198, both of which have been extensively tested and adopted across the EVM ecosystem.

Olympia’s architecture is modular by intent:

• ECIP-1112 (Treasury), ECIP-1113 (DAO), and ECIP-1114 (Funding Process) are distinct, independently testable components built atop standard smart contract primitives.
• Each layer can be activated or upgraded on its own schedule, enabling Ethereum Classic to scale participation and governance incrementally, without forcing immediate ecosystem-wide coordination.
• No new token is introduced or distributed as part of this upgrade.

This approach avoids overengineering while establishing a robust foundation for long-term, community-driven growth.

Interoperability

Maintaining EVM interoperability ensures compatibility with:

• Cross-chain infrastructure (wallets, bridges, RPC providers)
• dApp frameworks (e.g., Hardhat, Foundry, Scaffold-ETH)
• Developer tooling and compilers expecting EIP-1559 support

By aligning with canonical Ethereum upgrades, Ethereum Classic remains a viable target for modern Web3 applications and developer migration paths — especially for those seeking a secure, Proof-of-Work execution layer.

Immutability

EIP-1559 and EIP-3198 are strictly additive upgrades:

• No changes are made to existing opcodes, transaction types, or state semantics.
• Historical contracts behave identically post-fork.
• These upgrades do not retroactively alter any part of the ETC ledger.

This preserves the chain’s core principle of immutability while expanding its capabilities in a forward-compatible manner.

Standards Compliance

Canonical EIPs like 1559 and 3198 are now expected defaults across most major L1s and rollups:

• Many tools, libraries, and RPC providers now assume 1559-style transactions.
• Without this support, Ethereum Classic risks incompatibility with upstream tooling, reducing developer adoption.

Upgrading ensures ETC remains standards-aligned and future-proof for both dApp and client developers.

Modular Activation

ECIP-1111 introduces the redirection of BASEFEE revenue to an on-chain treasury but does not require immediate activation of downstream governance components — including ECIP-1113 (Olympia DAO) or ECIP-1114 (legal execution interface).

Instead, BASEFEE is redirected to a passive, non-upgradable treasury contract defined in ECIP-1112. This treasury:

• Accumulates protocol revenue without disbursing funds
• Enforces immutability and transparency through on-chain auditability
• Prevents unauthorized spending until DAO governance is enabled

This modular rollout allows ECIP-1111 to be activated independently:

• Network participants gain immediate benefits from EIP-1559 and EIP-3198, such as improved fee estimation and application compatibility
• No dependency is introduced on governance readiness, legal entities, or multisig operators
• Funds remain secure in the treasury until on-chain governance processes (ECFPs) are established, as defined in ECIP-1114

By decoupling protocol upgrades from governance deployment, Ethereum Classic ensures a safe, incremental path to full treasury activation — one that preserves user confidence while enabling sustainable funding infrastructure.

Implementation

The Olympia upgrade requires a coordinated hard fork, as it introduces non-backward-compatible changes to Ethereum Classic’s transaction format and EVM behavior. Specifically, it activates:

• EIP-1559: Dynamic fee market
• EIP-3198: BASEFEE opcode

Client Support

The following client currently supports Ethereum Classic and includes stable implementations of the above EIPs:

• Core-Geth
  Maintained by the Ethereum Classic community, Core-Geth will serve as the reference implementation for the Olympia upgrade.

Client teams MUST implement:

• Correct fee market behavior and basefee targeting logic (per EIP-1559)
• Support for legacy and EIP-1559 transaction types
• Accurate BASEFEE opcode return values
• Replay protection between legacy and upgraded chains

Testing and Coordination

Validation MUST occur on the Mordor Testnet prior to mainnet activation. Testing SHOULD include:

• Full transaction lifecycle (legacy and type-2)
• Gas accounting for basefee and miner tip separation
• BASEFEE opcode execution under various block conditions
• Fork ID and chain replay protection validation

Mainnet and testnet activation block heights SHALL be finalized through coordination between client developers, node operators, exchanges, miners, and infrastructure providers. Official release builds MUST include embedded fork activation logic.

Scope of This ECIP

This ECIP strictly introduces the on-chain redirection of BASEFEE and the activation of EVM changes defined in EIP-1559 and EIP-3198.

Implementation of the:

• Olympia Treasury
• Olympia DAO governance
• Legal execution layer

…is defined in separate proposals and may proceed independently.

This modular structure enables safe, phased deployment of protocol upgrades without dependency on governance infrastructure readiness.

Coordination with client teams, including maintainers of Core-Geth, will be required to ensure timely implementation of the Olympia upgrade. If necessary, third-party contributors or ecosystem developers may be enlisted to complete client-side changes, formalize testnet deployments, and validate consensus behavior. This open coordination model ensures the upgrade remains technically feasible and community-driven.

Reference Implementation

The Olympia upgrade will be implemented and tested in the following client:

• Reference Client: Core-Geth

Core-Geth includes support for:

• EIP-1559 (dynamic base fee and transaction type 2)
• EIP-3198 (BASEFEE opcode)
• BASEFEE redirection to the on-chain treasury as defined in ECIP-1112

These features are available under the olympia-upgrade branch.

Testnet Validation

• Deployment will first occur on the Mordor Testnet, enabling community testing and validation.
• Testnet results will inform finalization of mainnet activation parameters, including fork block height and client release tags.

EIP Compatibility Scope

The Olympia upgrade is intentionally limited in scope. It activates only two Ethereum protocol improvements:

• EIP-1559 – Dynamic fee market with BASEFEE redirection
• EIP-3198 – BASEFEE opcode for contract-level gas visibility

These EIPs improve transaction pricing and EVM compatibility without altering existing contract behavior or consensus security.

All other Ethereum Foundation EIPs — spanning from Tangerine Whistle (2016) to Prague-Electra (2025) — were reviewed and explicitly excluded based on one or more of the following criteria:

• Tied to Proof-of-Stake – Depends on Ethereum’s beacon chain, validator withdrawals, or finality gadgets incompatible with ETC’s Proof-of-Work model
• Consensus Incompatibility – Assumes execution-layer merge logic or trusted randomness
• Lack of Ecosystem Demand – No significant usage or tooling dependencies identified among ETC users or developers
• Immutability Risk – Changes semantics of deployed contracts or introduces backward-incompatible state behavior

This selective approach ensures Ethereum Classic remains compatible with the broader EVM ecosystem while preserving its core principles of immutability, Proof-of-Work, and backward compatibility.

Related Work

Precedents for BASEFEE Redirection

Although Ethereum Mainnet burns the BASEFEE as part of its monetary policy, several production EVM chains have chosen to redirect base fee revenue to treasury contracts for sustainable development:

• Ronin Network (Axie Infinity) sends BASEFEE to a DAO-governed Ronin Treasury
• Celo redirects base fees to a DAO-controlled Gas Fee Handler
• Mantle, Polygon CDK, and other modular L2 stacks implement treasury contracts that receive protocol revenue and route it via governance

These examples demonstrate that redirecting BASEFEE to a treasury — rather than burning it — is a proven, incentive-aligned design used to fund core protocol work, infrastructure, and public goods.

By adopting this structure, Ethereum Classic:

• Converts network usage into a sustainable on-chain revenue stream
• Funds long-term security and development without inflation
• Aligns ETC with the broader trend toward DAO-governed, treasury-enabled ecosystems

This model preserves ETC’s independence while securing its future.

Backwards Compatibility

The Olympia upgrade introduces:

• A new transaction type: Type-2 (EIP-1559)
• A new EVM opcode: BASEFEE (EIP-3198)

All existing functionality remains unchanged:

• Type-0 transactions continue to be valid and fully supported
• Previously deployed contracts operate without modification
• Historical blocks and state are preserved without retroactive changes

The upgrade is fully additive — new features are opt-in and only activated when using the new transaction format or querying the new opcode.

However, clients that do not implement Olympia will diverge from the canonical Ethereum Classic chain at the designated fork block. To maintain network consensus, node operators must upgrade to a client version that includes Olympia support.

This design ensures backward compatibility while enabling forward upgrades in a modular, non-disruptive manner. This ensures continuity for legacy users while enabling modern features for new applications.

Security Considerations

The Olympia Upgrade introduces no new consensus-critical vulnerabilities beyond the adoption of EIP-1559 and EIP-3198 — both of which are widely deployed and battle-tested across the EVM ecosystem. Security considerations fall into the following key areas:

1. EIP-1559 and EIP-3198 Safety

• Production Maturity:
  EIP-1559 and the BASEFEE opcode have been live on Ethereum Mainnet since 2021 and are implemented across major networks such as BSC, Polygon, Arbitrum, and OP Stack.

• Formal Validation:
  These features have undergone formal verification, economic analysis, and multi-client consensus testing over several years.

2. BASEFEE Redirection Logic

• Single Deviation:
  The only difference from Ethereum’s EIP-1559 is the redirection of BASEFEE to a treasury contract instead of burning it.

• Hardcoded Behavior:
  This redirection is enforced at the consensus layer and hardcoded into client logic. BASEFEE funds are automatically transferred to the treasury contract at the protocol level, ensuring tamper-proof accumulation.

• No EVM Modifications:
  The upgrade does not alter the opcode set, gas accounting, or transaction validation logic outside what is defined in EIP-1559 and EIP-3198.

3. Client Implementation Requirements

• State Transition Accuracy:
  Clients must correctly implement BASEFEE redirection to avoid:
  • Rounding errors
  • Ledger inconsistencies
  • Misaccounted gas usage

• Test Vector Adjustments:
  Ethereum test vectors that assume basefee burning must be modified to validate proper accumulation into the treasury address.

• Cross-Client Alignment:
  All participating clients must apply identical redirect logic to ensure consensus compatibility.

4. Treasury Isolation and Governance Safety

• Execution Separation:
  ECIP-1111 only redirects BASEFEE to an immutable treasury. It does not deploy or invoke any governance contracts.

• Governance Isolation: Treasury disbursement is gated by separate contracts and processes defined in ECIPs 1112–1114. These governance layers cannot affect base protocol logic.

• Custody Guarantees:
  No treasury funds can be moved without explicit on-chain governance approval, ensuring strict separation of concerns between consensus logic and DAO execution.

5. Testnet and Audit Strategy

• Simulation and State Validation:
  Testnets must confirm correct basefee handling and accumulation under both Type-0 and Type-2 transactions.

• Mordor Deployment:
  Prior to mainnet activation, the Olympia Upgrade will be deployed and validated on the Mordor Testnet, including:
  • Transaction formatting and validation
  • Basefee accounting and state transitions
  • Invariant checks on accumulated balances
• Audit Coordination:
  While ECIP-1111 affects protocol logic only, client implementers are encouraged to audit the integration in tandem with ECIP-1112–1114 for full-stack safety assurance.

Summary

The Olympia Upgrade applies well-established EVM upgrades and adds a consensus-level redirect of BASEFEE to a transparent, auditable treasury. It preserves all EVM guarantees, introduces no new opcodes or runtime changes, and maintains strict isolation between protocol consensus and governance execution. With comprehensive testnet validation and multi-client alignment, the upgrade strengthens Ethereum Classic’s security while enabling sustainable development funding.

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.

Appendix: EVM Compatibility Roadmap and Upgrade Candidates

Future Considerations: Toward Full EVM Compatibility

The Olympia Upgrade is intentionally limited in scope to EIP-1559 and EIP-3198. However, additional Ethereum protocol improvements have been reviewed as potential candidates for future adoption. The table below categorizes relevant EIPs based on their compatibility with Ethereum Classic’s Proof-of-Work model, utility to developers, and alignment with ETC’s principles of immutability, simplicity, and sovereignty.

This roadmap serves as a reference for ongoing community discussion and future upgrade planning.

Note: The EIPs listed below are not included in ECIP-1111. Their adoption would require a new ECIP, community consensus, and successful testnet validation under the ECIP-1000 process.*

✅ Candidates for Future Inclusion

The following EIPs are technically and philosophically aligned with ETC and may improve performance, developer experience, or compatibility without compromising Proof-of-Work security.

⚠️ Optional or Low Priority

These EIPs offer marginal or situational benefits and do not require urgent action.

❌ Incompatible or Out of Scope (PoS-Specific)

These EIPs are tightly coupled to Ethereum’s Proof-of-Stake architecture or require changes incompatible with ETC’s protocol values.

Community members are invited to submit additional proposals for EVM upgrade adoption using the ECIP process, prioritizing compatibility, security, and Proof-of-Work integrity.