ECIP 1111: Olympia EVM and Protocol Upgrades

Author	Cody Burns, Chris Mercer
Discussions-To	https://github.com/orgs/ethereumclassic/discussions/530
Status	Draft
Type	Meta
Created	2025-07-04

Simple Summary

This proposal activates select Ethereum protocol upgrades on Ethereum Classic via a hard fork named Olympia. Specifically, it introduces EIP-1559 and EIP-3198 to enhance Ethereum Classic’s EVM compatibility, improve gas pricing, and redirect the BASEFEE to a decentralized, permissionless on-chain treasury (ECIP-1112), governed by Olympia DAO (ECIP-1113), for sustainable development funding. The goal is to enhance interoperability with the broader Ethereum ecosystem while preserving Ethereum Classic’s Proof-of-Work consensus and core principles.

Abstract

This ECIP proposes the activation of selected Ethereum protocol upgrades on the Ethereum Classic network under the hard fork name Olympia. The upgrade includes EIP-1559, which introduces a dynamic base fee mechanism to improve transaction fee predictability and market efficiency, and EIP-3198, which adds the BASEFEE opcode for EVM compatibility. These changes are intended to enhance interoperability with Ethereum and other EVM-based networks while preserving Ethereum Classic’s Proof-of-Work consensus and immutability principles. The Olympia Treasury (see ECIP-1112) receives all BASEFEE revenue, which is governed on-chain by Olympia DAO (ECIP-1113) through the Ethereum Classic Funding Proposal process (ECIP-1114), and executed off-chain by Ethereum Classic DAO LLC as a legal interface for compliance, payments, and treasury administration.

The proposal excludes upgrades tied to Ethereum’s transition to Proof-of-Stake or those irrelevant to Ethereum Classic’s architecture, such as validator withdrawal operations and randomness derived from the beacon chain. Implementation requires coordination across client software and network participants for a scheduled hard fork at block heights to be determined on Mordor Testnet and Ethereum Classic Mainnet.

EIP Summaries and Expected Action

Included in Olympia Upgrade

EIP-1559 – Fee Market Change Introduces a new transaction type with a dynamically adjusting base fee per gas and an optional priority tip to incentivize miners. On Ethereum Classic, instead of being burned (as on Ethereum Mainnet), the BASEFEE is retained and redirected to the Olympia Treasury, an open on-chain development fund. This design aligns incentives between developers, miners, and users by converting transaction demand into sustainable network funding. As ETC’s block reward continues to decline under ECIP-1017 monetary policy, this mechanism ensures the network retains a long-term security and development budget tied directly to economic activity on-chain.
EIP-3198 – BASEFEE Opcode Adds a new opcode that allows smart contracts to access the current block’s basefee, as defined by EIP-1559. This enables more accurate on-chain gas estimation and supports modern fee-aware applications.

This ECIP proposes the activation of these changes at the following block heights:

Mordor Testnet: TBD
Ethereum Classic Mainnet: TBD

For full technical specifications, see the Specification section below.

Motivation

The Olympia upgrade seeks to advance Ethereum Classic’s protocol capabilities by adopting proven Ethereum Virtual Machine (EVM) enhancements introduced by the Ethereum Foundation. By implementing EIP-1559 and EIP-3198, Ethereum Classic will gain compatibility with modern transaction formats and smart contract expectations used across the broader EVM ecosystem.

These changes provide four core benefits to the Ethereum Classic ecosystem:

EVM Compatibility – Developers can deploy EVM-standard dApps on Ethereum Classic without modification or workarounds, reducing friction and enabling seamless cross-chain application deployment.
Fee Market Modernization – EIP-1559 introduces a more predictable and user-friendly gas pricing mechanism, aligning ETC with fee market improvements already adopted by major EVM chains.
Network Utility and Adoption – Aligning with the broader EVM roadmap ensures Ethereum Classic remains relevant for developers, tooling providers, infrastructure teams, and users seeking a Proof-of-Work alternative to Ethereum.
Sustainable Development Incentives – Redirecting the BASEFEE to the Olympia Treasury enables Ethereum Classic to fund open-source development and long-term protocol maintenance without inflating supply. This ensures that, as block rewards decline under ECIP-1017, the network retains a credible on-chain security and innovation budget. This structure not only replaces centralized or discretionary funding models but also formalizes the relationship between protocol revenue and ecosystem development.

Specification

The Olympia upgrade activates the following EIPs on the Ethereum Classic network. Technical specifications and implementation details are defined in the canonical EIP documentation:

Included from London Hard Fork

EIP-1559 – Fee Market Change
Introduces a new transaction type with a dynamic basefee, redirected per block to the Olympia Treasury (ECIP-1112), while miner tips remain payable to block producers.

EIP-3198 – BASEFEE Opcode Adds the BASEFEE opcode (0x48) to the EVM, allowing smart contracts to query the current block’s base fee.

On Ethereum Classic, the BASEFEE is not burned but redirected to a dedicated, non-upgradable smart contract known as the Olympia Treasury (see ECIP-1112). This contract accumulates protocol-level fee revenue to fund ecosystem development and security, and is governed transparently via on-chain processes.

No additional changes beyond these EIPs are included in the Olympia upgrade. Clients should adhere strictly to the behavior defined in the linked specifications.

Rationale

Interoperability: Maintaining interoperability with Ethereum and other EVM-compatible chains is essential to ensuring developer portability, tooling support, and infrastructure reuse. By aligning with key protocol features like EIP-1559 and EIP-3198, Ethereum Classic reduces fragmentation and remains a viable deployment target for modern EVM applications and clients (e.g., ETC ↔ ETH parity).

Immutability: The proposed upgrades introduce new transaction types and opcodes but do not alter the semantics of existing contracts or state. Historical contracts will behave identically, and no prior behavior is retroactively affected. These are strictly additive changes to EVM functionality and maintain the network’s commitment to immutability.

Standards Compliance: Supporting canonical EIPs is critical for application-layer compatibility. Without EIP-1559 and EIP-3198, Ethereum Classic would lack support for transaction types and opcodes widely expected by wallets, bridges, rollups, and contract compilers. Adopting these standards helps ensure that modern Web3 applications can be deployed on ETC without modification.

Real-World Precedents for BASEFEE Redirection

While Ethereum Mainnet burns the BASEFEE under EIP-1559, a small number of EVM-compatible networks have chosen to redirect this fee to protocol treasuries instead. For example, the Ronin sidechain (Axie Infinity) routes base fee revenue to its Ronin Treasury contract, while Celo (a Proof-of-Stake L1) directs base fees to a Gas Fee Handler contract governed by its DAO. These implementations demonstrate that treating BASEFEE as protocol income — rather than as a deflationary burn — is a viable and increasingly adopted alternative. By doing so, Ethereum Classic aligns with a growing trend toward using network activity to fund decentralized development in a sustainable, transparent, and incentive-aligned manner.

Other networks such as Mantle and Polygon CDK also incorporate protocol revenue flows into DAO treasuries through modular treasury contracts. While not all use the BASEFEE directly, these implementations support the broader design of EVM-aligned, treasury-governed ecosystems.

Implementation

Adopting the Olympia upgrade requires a coordinated hard fork, as it introduces non-backward-compatible changes to the Ethereum Classic protocol and transaction format. Clients must implement support for the EIP-1559 fee market and the EIP-3198 BASEFEE opcode.

The following client currently maintains compatibility with the Ethereum Classic network and supports the necessary features introduced in Ethereum’s London upgrade:

Core-Geth – Maintained by the Ethereum Classic community, Core-Geth includes a stable implementation of EIP-1559 and EIP-3198, and will be the primary reference client for the Olympia fork.

Client implementers must ensure correct behavior as defined in the relevant EIPs and coordinate activation on both Mordor Testnet and Ethereum Classic Mainnet at the block heights defined in this ECIP.

Testing should include full validation of:

Legacy and EIP-1559 transaction types
Gas accounting for basefee burn and miner tips
BASEFEE opcode availability and correct return values
Cross-version transaction replay protection

Community coordination is required to finalize testnet and mainnet fork block numbers, along with updated client releases that embed the Olympia fork rules.

Implementation of the Olympia Treasury (ECIP-1112) and Olympia DAO governance (ECIP-1113) — including its legal interface via ECIP-1114 — are defined separately. This ECIP strictly introduces the on-chain redirection mechanism and EVM upgrades. This ECIP solely introduces the protocol-level redirection logic and opcode activation.

Reference Implementation

Reference client: Core-Geth
EIP-1559 and EIP-3198 are implemented in Core-Geth under the olympia-upgrade branch, which also includes basefee redirection to the treasury contract as per ECIP-1112.
Testnet deployment and validation will occur on Mordor prior to mainnet activation.

EIP Compatibility Scope

The Olympia upgrade is purposefully limited in scope. It includes only the two EIPs relevant to fee market modernization and EVM compatibility (EIP-1559 and EIP-3198).

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

Dependence on Proof-of-Stake consensus
Incompatibility with ETC’s Proof-of-Work architecture
Lack of developer or user demand
Risk of breaking immutability or changing contract behavior

Backwards Compatibility

The Olympia upgrade introduces a new transaction type (Type-2) and an additional EVM opcode (BASEFEE). Legacy Type-0 transactions and all previously deployed contracts will remain valid and operate as before. However, nodes that do not upgrade will become incompatible and fork from the canonical Ethereum Classic chain upon activation. This upgrade does not retroactively alter historical blocks and maintains full execution compatibility with existing smart contracts. All new behavior is opt-in based on transaction type and client version.

Security Considerations

No new consensus-critical vulnerabilities are introduced by this upgrade. The BASEFEE opcode and EIP-1559 transaction format have been widely adopted and audited across the EVM ecosystem. Core-Geth implementers are advised to validate integration against existing test vectors and consensus tests.

Client implementers must ensure that redirecting the BASEFEE to the Olympia Treasury does not introduce rounding errors or state inconsistencies. Reference vectors from Ethereum Mainnet should be adjusted to reflect treasury accumulation rather than burn behavior.

As EIP-1559 and EIP-3198 are already deployed across major EVM networks (ETH, BSC, OP Stack), they have received extensive production testing and formal auditing. Only the redirect logic to the Olympia Treasury diverges from Ethereum’s reference model, and must be carefully validated.

Copyright

Appendix: EVM Compatibility Roadmap and Upgrade Candidates

Future Considerations: Toward Full EVM Compatibility

While the Olympia Upgrade is intentionally limited in scope to EIP-1559 and EIP-3198, a review of additional Ethereum protocol improvements was conducted to identify candidates for future adoption. The table below categorizes EIPs from Ethereum’s post-London upgrade path based on their compatibility with Ethereum Classic’s Proof-of-Work model, utility to developers, and alignment with ETC’s values of immutability, security, and simplicity.

This matrix serves as a foundation for community discussion and potential inclusion in future hard forks.

📘 Note: The EIPs listed below are not part of the current Olympia Upgrade activation but may be included in a subsequent ECIP following community consensus and testnet validation.

✅ Candidates for Future Inclusion

These EIPs are not included in ECIP-1111 but are technically and philosophically compatible with Ethereum Classic’s Proof-of-Work model. Their future inclusion would follow the ECIP-1000 process and require consensus among core developers, miners, and ecosystem stakeholders.

EIP	Title	Reason to Include
1283	SSTORE Gas Metering Changes	Improves storage efficiency; expected by many contracts and compilers. Low-risk, high-impact.
5656	MCOPY Memory Instruction	EVM performance upgrade; useful for zkApps and L2-compatible tooling. Adds parity without PoS entanglement.
6780	SELFDESTRUCT Semantics Change	Aligns behavior with post-Shanghai semantics. Requires discussion but brings full compatibility.
1153	Transient Storage Opcodes	Enables modern contract patterns (used in L2s and advanced dApps). Increasingly required by tooling.
2935	Save Historical Block Hashes in State	Adds native access to past block hashes. Useful for on-chain randomness and oracle logic.
7623	Increase Calldata Cost	Disincentivizes calldata abuse. Aligns ETC with post-4844 economic design. Can be tuned for ETC.

⚠️ Optional / Low Priority

EIP	Title	Notes
170	Contract Code Size Limit	Useful for DoS mitigation, but ETC hasn’t encountered this issue. Optional safeguard.
3228	Difficulty Bomb Delay	Only relevant to Ethereum’s PoS transition. No action needed.
7691	Blob Throughput Increase	Applies only to networks implementing EIP-4844. ETC does not currently support blobs.
7702	Set EOA Account Code	Supports future account abstraction. Not urgent unless ETC pursues this roadmap.

❌ Should Remain Omitted (PoS-Specific or Incompatible)

EIP(s)	Reason to Remain Excluded
3675, 4895, 4788, 4399, 6110, 7251, 7549, 7002, 7685, 7840	All relate to Ethereum’s Proof-of-Stake, beacon chain, validator operations, or staking exit logic — incompatible with ETC’s PoW consensus.
4844, 7516	Depend on blob transaction infrastructure and consensus changes. High complexity with minimal benefit unless ETC plans major infra upgrades.
2537	Introduces BLS12-381 precompile. Adds cryptographic surface area for PoS use cases; not currently useful for ETC.

ECIP 1111: Olympia EVM and Protocol Upgrades Source