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 modernize gas pricing mechanics. Unlike Ethereum Mainnet, where the BASEFEE is burned, Ethereum Classic redirects it to the Olympia Treasury (ECIP-1112) — an immutable, governance-isolated on-chain funding contract.

This establishes a transparent, non-inflationary protocol-level funding source while preserving Proof-of-Work consensus and Ethereum Classic’s principles of immutability, neutrality, and decentralization.

Until governance defined in ECIP-1113 and ECIP-1114 is activated, the Treasury accumulates funds passively with no disbursements, ensuring secure and trustless value storage.

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 adjustment mechanism to improve fee predictability and market efficiency.
• EIP-3198: Adds the BASEFEE opcode for full EVM opcode 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), a deterministic, immutable contract defined at the protocol level. Governance and funding flows for this Treasury are specified separately in ECIP-1113 (Olympia DAO Governance Framework) and ECIP-1114 (Ethereum Classic Funding Proposal Process).

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.

EIP Summaries and Expected Action

Included in the Olympia Upgrade

• EIP-1559 – Fee Market Change
  Introduces a new transaction type with a dynamically adjusting basefee based on block gas usage and an optional miner tip (priorityFee).
  On Ethereum Classic, unlike Ethereum Mainnet, the basefee is not burned. It is redirected at the consensus layer to the deterministic Olympia Treasury address defined in ECIP-1112. Miner tips (priorityFee) remain payable directly to block producers.

• EIP-3198 – BASEFEE Opcode
  Adds opcode 0x48 (BASEFEE), returning the current block’s basefee.
  This enables fee-aware contract logic, improved gas estimation, and standard EVM opcode compatibility.

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 final coordination and release 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 long-term maintainability.

EIP-1559 and EIP-3198 provide several benefits:

1. Improved EVM Compatibility
   Adoption of EIP-1559 and the BASEFEE opcode enables Ethereum Classic to support transaction formats and gas-pricing conventions now standard across most EVM networks. This reduces friction for developers and tooling providers and improves cross-chain portability.

2. Modernized Fee Market
   EIP-1559 introduces a dynamic basefee mechanism that provides more predictable gas pricing and a clearer distinction between network congestion pricing and miner incentives. This results in more consistent application and user behavior across EVM chains.

3. Expanded Tooling and Infrastructure Support
   Parity with widely supported EVM standards improves compatibility with wallets, infrastructure services, and development frameworks that increasingly assume EIP-1559 semantics.

4. Sustainable Protocol-Level Funding
   Redirecting the BASEFEE to the Olympia Treasury (ECIP-1112) creates a transparent, non-inflationary source of protocol revenue. This supports long-term client maintenance, infrastructure reliability, and ecosystem security as block rewards decline under ECIP-1017.

While EIP-1559 originated on Ethereum, its inclusion here remains consistent with Ethereum Classic’s principles of immutability and censorship resistance. It modifies no historical state, introduces only additive transaction formats, and does not require trust in off-chain actors.

Specification

The Olympia upgrade activates the following Ethereum protocol improvements on Ethereum Classic. All specifications are implemented exactly as defined in the canonical Ethereum Improvement Proposals (EIPs), except where noted for consensus-layer BASEFEE redirection.

Protocol Changes Adopted from Ethereum’s London Hard Fork

• EIP-1559 – Fee Market Change
  Introduces a new transaction format with a dynamically adjusting basefee based on block gas usage and an optional miner tip (priorityFee).
  On Ethereum Classic, the basefee is not burned. Instead, it is redirected at the consensus layer to the deterministic Olympia Treasury address defined in ECIP-1112. Miner tips (priorityFee) continue to be paid directly to block producers.

• EIP-3198 – BASEFEE Opcode
  Adds opcode 0x48 (BASEFEE), allowing smart contracts to access the current block’s basefee.
  This enables fee-aware smart contract logic, improved gas estimation, and consistent EVM behavior across supported tooling.

Example: Consensus-Layer BASEFEE Redirection

// --- BEGIN PSEUDOCODE ---
// Illustrative example of consensus-layer handling of BASEFEE.
// This demonstrates redirection of the BASEFEE amount to the
// Olympia Treasury instead of burning it.

func finalizeBlock(block, state) {
    // Calculate total BASEFEE from gas used in all transactions
    baseFeeAmount = block.gasUsed * block.baseFee

    // Redirect BASEFEE to the fixed Treasury address
    state.addBalance(treasuryAddress, baseFeeAmount)

    // Miner receives priority fees (tips)
    state.addBalance(block.miner, block.totalPriorityFees)

    return
}
// --- END PSEUDOCODE ---

Pseudocode Notes

• This example is illustrative only; actual implementations appear within each client’s consensus and state-transition logic.
• state represents the client’s execution ledger for applying balance changes during block processing.
• This behavior is consensus-critical and MUST be implemented identically across any participating Ethereum Classic clients.

🔒 Consensus-critical logic: BASEFEE redirection is enforced during block finalization and cannot be bypassed or altered without a hard fork. The Treasury transfer occurs before miner rewards are applied.

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

Implementation Notes

• Clients MUST implement EIP-1559 and EIP-3198 exactly as specified, with the modification that the basefee amount is redirected to the Treasury address defined in ECIP-1112 rather than burned.
• Test vectors MUST be updated to reflect Treasury accumulation instead of basefee destruction.
• Activation SHALL occur at predefined block heights on Mordor Testnet and Ethereum Classic Mainnet (see Activation section).

Clients and infrastructure providers MUST validate implementation using cross-client consensus tests, including basefee calculation, transaction-type handling, and correct Treasury accumulation.

Monetary Policy Consideration

Redirecting the BASEFEE to the Olympia Treasury replaces Ethereum Mainnet’s burn mechanism with protocol-level treasury accumulation, without altering ETC’s total supply or issuance schedule. Monetary policy defined in ECIP-1017 remains unchanged. This change preserves Ethereum Classic’s fixed monetary policy while enabling sustainable, transparent funding for ecosystem maintenance and public infrastructure.

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 (Governance Framework), and ECIP-1114 (Funding Proposal Process) are distinct, independently testable components built atop standard smart contract primitives.
• Each layer can be activated or upgraded independently, allowing protocol functionality, governance, and funding mechanisms to evolve without coupling changes across the stack.
• No new token is introduced or distributed as part of this upgrade.

This separation mirrors ECIP-1112’s minimalist vault architecture and ECIP-1113’s modular governance structure, ensuring each layer can be maintained or improved without modifying the others.

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 that increasingly assume EIP-1559-style transactions

By adopting canonical Ethereum upgrades, Ethereum Classic maintains alignment with widely supported EVM conventions, improving tooling compatibility and reducing friction for developers and infrastructure providers.
EIP-1559 and EIP-3198 adoption also fulfills the dependency required for the Olympia Treasury’s BASEFEE revenue capture mechanism (ECIP-1112).

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.
• No retroactive modification of the ETC ledger occurs.

This preserves Ethereum Classic’s core principle of immutability while enabling forward-compatible improvements.

Standards Compliance

Canonical EIPs such as 1559 and 3198 are now expected defaults across most major L1 networks and rollups:

• Many tools, libraries, and RPC providers assume EIP-1559 support.
• Without these upgrades, Ethereum Classic risks incompatibility with upstream EVM tooling and reduced developer accessibility.

Adopting these standards ensures that ETC remains aligned with the broader EVM ecosystem, improving long-term maintainability for both dApp and client developers.

Modular Activation

ECIP-1111 introduces consensus-layer BASEFEE redirection to an on-chain Treasury but does not require immediate activation of downstream governance components — including ECIP-1113 (Olympia DAO Governance Framework) or ECIP-1114 (Ethereum Classic Funding Proposal Process).

Instead, BASEFEE is redirected to a passive, immutable, governance-isolated Treasury contract defined in ECIP-1112. This Treasury:

• Accumulates protocol revenue without disbursing funds
• Remains immutable and transparent through on-chain auditability
• Restricts all withdrawals until governance contracts are activated under separate ECIPs

This modular approach allows ECIP-1111 to remain a single, isolated consensus change, consistent with ECIP-1000. It enables the network to adopt EIP-1559 and EIP-3198 immediately, without introducing:

• Dependencies on governance readiness
• Coordination requirements beyond client activation
• Any operational or administrative prerequisites

Activation of governance control over the Treasury is intentionally specified outside of ECIP-1111. It is defined in:

• ECIP-1113, which establishes the on-chain governance framework
• ECIP-1114, which defines the standardized funding proposal process

This separation ensures that consensus changes, Treasury deployment, and governance activation can proceed independently and safely, each undergoing appropriate testing and review.

Implementation & Reference Client

Testnet Coordination & Implementation Status

At the time of writing, prototype implementations of EIP-1559, EIP-3198, and consensus-layer BASEFEE redirection are under active development within the Ethereum Classic client ecosystem.

Specific client names, branches, or release artifacts MAY be documented in this section once reference implementations are publicly announced and tagged by their respective maintainers.

Prior to any Mainnet activation, the Olympia upgrade SHALL be tested on the Mordor Testnet. Testnet coordination SHOULD cover at minimum:

• Activation parameters (block height or activation epoch)
• basefee calculation and adjustment behavior under varying gas usage
• Correct accounting of Treasury balances (ECIP-1112)
• Handling of Legacy (Type-0), Access List (Type-1), and EIP-1559 (Type-2) transactions
• Cross-client state-transition equivalence and replay protection

Final activation block numbers for both Mordor and Mainnet SHALL be agreed by client implementers, node operators, and other stakeholders, and SHALL be published in an update to this section and in the relevant client release notes.

Client Requirements

All ETC client implementations MUST:

• Implement EIP-1559 basefee targeting logic
• Support Legacy (Type-0), Access List (Type-1), and EIP-1559 (Type-2) transactions
• Implement the BASEFEE opcode exactly as defined in EIP-3198
• Redirect the BASEFEE amount to the deterministic Olympia Treasury address (ECIP-1112)
• Enforce replay protection and fork ID behavior around the activation block
• Apply state-transition rules identically to other participating clients to maintain consensus

Testing and Coordination

Validation MUST occur on the Mordor Testnet before any Mainnet activation.

Test coverage SHOULD include:

• Transaction lifecycle for Legacy (Type-0), Access List (Type-1), and EIP-1559 (Type-2) transactions
• Accurate fee accounting (BASEFEE redirection vs miner tips)
• Correct Treasury accumulation at the consensus layer
• BASEFEE opcode behavior under empty, partially full, and full gas blocks
• Cross-client consensus testing, including block execution equivalence
• Fork ID, chain configuration, and replay protection validation
• Optional integration testing with ECIP-1112, and—once deployed—ECIP-1113 and ECIP-1114

Activation block heights for Mordor and Mainnet SHALL be finalized through open coordination among client implementers, node operators, miners, exchanges, and infrastructure providers.

Scope of This ECIP

This ECIP strictly introduces:

• Activation of EIP-1559
• Activation of EIP-3198
• Consensus-layer BASEFEE redirection to the Olympia Treasury (ECIP-1112)

All governance, funding, and contract-layer functionality is defined separately in:

• ECIP-1112 — Treasury Contract
• ECIP-1113 — Governance Framework
• ECIP-1114 — Funding Proposal Process

These ECIPs are independent of ECIP-1111 and MAY be deployed and activated on separate timelines under the modular rollout model.

EIP Compatibility Scope

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

• EIP-1559 — Introduces the dynamic basefee mechanism and replaces Ethereum Mainnet’s burn behavior with consensus-layer BASEFEE redirection to the immutable Olympia Treasury (ECIP-1112).
• EIP-3198 — Adds the BASEFEE opcode (0x48), enabling contract-level visibility of the current block’s basefee.

These EIPs improve fee-market behavior and EVM interoperability without modifying existing contract semantics or introducing any consensus-layer changes beyond the redirection of BASEFEE.

No additional EIPs are activated by this proposal. All other Ethereum Foundation EIPs — spanning from Tangerine Whistle (2016) through Prague–Electra (2025) — were reviewed only for compatibility context and are listed in the Appendix: EVM Compatibility Roadmap and Upgrade Candidates section of this ECIP. Their inclusion in the appendix does not imply adoption; any future EVM upgrades would require separate ECIPs.

Related Work

Precedents for Protocol-Level Fee Redirection

While Ethereum Mainnet burns the basefee as part of EIP-1559, several production EVM networks have adopted alternative designs that redirect protocol-level fee revenue to on-chain treasuries or governance-controlled funding systems. These precedents fall into two broad categories:

Networks that Redirect EIP-1559 BASEFEE

• Ronin Network — Redirects the EIP-1559 basefee to a DAO-governed treasury that funds infrastructure, validators, and ecosystem programs.

Networks that Redirect Other Forms of Protocol or Sequencer Revenue

• Celo — Redirects gas fees to a governance-managed Gas Fee Handler that allocates funds to community and climate initiatives.
• Mantle — Routes sequencer revenue to a DAO treasury for grants, tooling, and infrastructure.
• Polygon CDK — Allows sovereign rollups to implement EIP-1559-compatible fee hooks for governance-controlled treasuries.
• OP Stack (used by Base, Optimism) — Supports sequencer revenue splitting for public-goods funding.
• Arbitrum — Directs sequencer revenue into a DAO-managed treasury, with allocations governed through the AIP process.
• Optimism — Allocates sequencer revenue to Retroactive Public Goods Funding (RPGF).
• zkSync Era & Scroll — Include revenue hooks that can forward sequencer income to protocol-aligned treasuries.
• Avalanche Subnets — Some subnet configurations route transaction fees to validator-governed treasuries.
• Gitcoin DAO — While not fee-based, it provides a notable example of transparent, governance-directed public goods funding.

These examples demonstrate that redirecting protocol-level fee or revenue flows to transparent, governance-controlled treasuries is an established design pattern across modern EVM systems. Such mechanisms support sustainable funding for core protocol work, infrastructure, and public goods.

In adopting consensus-layer BASEFEE redirection, Ethereum Classic implements a non-inflationary, protocol-native funding mechanism that maintains ETC’s fixed monetary policy while enabling transparent and auditable treasury accumulation.

Future Work (Non-Consensus Extensions)

The scope of ECIP-1111 is intentionally limited to the activation of EIP-1559, EIP-3198, and consensus-layer BASEFEE redirection to the Olympia Treasury (ECIP-1112).

Additional miner-alignment or revenue-smoothing mechanisms MAY be proposed in a separate, additive ECIP. A future proposal — tentatively referred to as ECIP-1115 — may explore optional approaches to modifying how Treasury-bound BASEFEE is handled at the application or governance layer.

Any such proposal:

• SHALL be introduced as an independent ECIP
• SHALL be strictly additive and SHALL NOT modify the consensus rules introduced in ECIP-1111
• SHALL undergo full review under the ECIP-1000 process
• SHALL require independent testnet validation prior to activation
• WOULD remain optional and modular within the broader Olympia framework

No additional miner-alignment or smoothing mechanics are included in ECIP-1111 to preserve its role as a minimal, isolated consensus change.

Backwards Compatibility

The Olympia upgrade introduces:

• A new transaction type: Type-2 (EIP-1559)
• A new EVM opcode: BASEFEE (EIP-3198)
• Consensus-layer redirection of the BASEFEE amount to the immutable Olympia Treasury (ECIP-1112)

All existing functionality remains unchanged:

• Type-0 transactions continue to be valid and fully supported
• Type-1 (Access List) transactions introduced by ECIP-1103 remain valid and unchanged
• Previously deployed contracts operate without modification
• Historical blocks and state are preserved without retroactive changes

The upgrade is fully additive — the new transaction format and opcode are optional to use. Legacy (Type-0) and Access List (Type-1) transactions continue to function without modification.

Client Upgrade Requirements

• Clients that do not implement the Olympia upgrade will diverge from the canonical Ethereum Classic chain at the designated fork block.
• To remain in consensus, node operators MUST upgrade to a client version that supports:
  • EIP-1559 (basefee mechanism and Type-2 transactions)
  • EIP-3198 (BASEFEE opcode)
  • Consensus-layer BASEFEE redirection to the deterministic Treasury address defined in ECIP-1112

Compatibility Characteristics

• Legacy Contract Support — Existing smart contracts and dApps function without modification.
• Treasury Isolation — The Treasury contract logic (ECIP-1112) is independent of application-layer behavior.
• Transaction-Type Flexibility — Users, miners, and developers may continue using Type-0 and Type-1 transactions if desired; Type-2 support is additive.

As with ECIP-1112, any non-upgraded clients will fork permanently from the canonical chain at activation. All blocks, transactions, and state transitions on the minority fork will be invalid on the main chain.

Security Considerations

The Olympia upgrade introduces no new consensus-critical vulnerabilities beyond those already inherent in EIP-1559 and EIP-3198. Both features are widely deployed across the EVM ecosystem and have undergone extensive testing, review, and validation. Security considerations for ECIP-1111 focus primarily on ensuring correct and consistent implementation of consensus-layer BASEFEE redirection.

1. EIP-1559 and EIP-3198 Safety

• Production Maturity — EIP-1559 and the BASEFEE opcode have been active on Ethereum Mainnet since 2021 and are implemented across numerous EVM-based networks (e.g., BSC, Polygon, Arbitrum, OP Stack chains).
• Independent Validation — These features have undergone formal analysis, multi-client testing, and long-term operational usage in production environments.

2. BASEFEE Redirection Logic

• Single Consensus Deviation — The only functional divergence from Ethereum Mainnet’s EIP-1559 behavior is that ETC redirects the BASEFEE amount to the Olympia Treasury (ECIP-1112) rather than burning it.
• Consensus Enforcement — This redirection is enforced directly within the block finalization logic. All participating clients MUST apply identical state-transition rules to avoid consensus divergence.
• Treasury Immutability — The Treasury contract defined in ECIP-1112 contains no upgrade mechanisms, administrative keys, or privileged withdrawal paths. It is a deterministic, immutable vault.

3. Client Implementation Requirements

• State-Transition Accuracy — Clients MUST correctly compute and redirect the BASEFEE amount to the Treasury. Incorrect calculation or transfer risks:
  • Rounding inconsistencies
  • Ledger imbalance
  • Block execution mismatches
• Test Vector Updates — Test vectors that assume basefee burning MUST be adapted to validate Treasury accumulation behavior.
• Cross-Client Alignment — All clients MUST produce identical results for basefee calculation, transaction processing, and Treasury accumulation.

4. Treasury Isolation

• Execution Separation — ECIP-1111 specifies only consensus-layer revenue redirection. No withdrawal or governance logic is included in this ECIP.
• Independent Governance — Treasury spending and governance mechanisms are defined separately in ECIP-1112, ECIP-1113, and ECIP-1114. Their activation or operation does not alter the consensus rules introduced in ECIP-1111.

5. Testnet and Audit Strategy

• Mordor Testnet Deployment — All ECIP-1111 functionality MUST be validated on Mordor prior to Mainnet activation. Testing SHOULD include:
  • Legacy (Type-0), Access List (Type-1), and EIP-1559 (Type-2) transaction handling
  • Accurate BASEFEE accounting
  • Treasury accumulation verification
  • BASEFEE opcode correctness
• Audit Coordination — Although ECIP-1111 affects consensus-layer logic only, its interaction with ECIP-1112 SHOULD be reviewed to ensure correct integration of Treasury accumulation mechanisms.

Security Considerations Summary

The Olympia upgrade activates established EVM improvements and introduces a single consensus-layer modification to redirect the BASEFEE amount to an immutable Treasury contract. The upgrade is fully additive, preserves all existing EVM semantics, and makes no changes to historical state or previously deployed contracts. With correct implementation, cross-client alignment, and thorough testnet validation, the consensus changes defined in ECIP-1111 can be adopted safely and predictably across the Ethereum Classic network.

Related ECIPs in the Olympia Upgrade

ECIP-1111 is one of four coordinated proposals that together define the Olympia upgrade path.
Only ECIP-1111 introduces a consensus-layer change. ECIP-1112, ECIP-1113, and ECIP-1114 operate entirely at the contract or application layer and do not require a network hard fork.
Although ECIP-1113 and ECIP-1114 are not required for activation of ECIP-1111, they are required for any future Treasury disbursements. Until those governance components are deployed, the Treasury defined in ECIP-1112 remains an immutable, non-spending vault.

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

• ECIP-1112 — Olympia Treasury Contract
  Defines the deterministic, immutable Treasury contract that receives all redirected BASEFEE revenue and holds it in a governance-isolated vault.
  Without ECIP-1113 and ECIP-1114, the Treasury can accumulate but cannot release funds.

• ECIP-1113 — Olympia DAO Governance Framework
  Specifies the governance architecture that, once deployed, becomes the required governance layer for authorizing Treasury disbursements. ECIP-1113 is optional relative to ECIP-1111 activation, but mandatory for enabling any spending.

• ECIP-1114 — Ethereum Classic Funding Proposal Process
  Defines the standardized, permissionless proposal format (ECFP) and the hash-bound execution model that ECIP-1113 uses to authorize Treasury disbursements.

Interdependency Summary

• ECIP-1111 introduces consensus-layer BASEFEE redirection to the Treasury.
• ECIP-1112 deploys the immutable Treasury contract to receive and hold funds.
• ECIP-1113 provides the governance framework that is required for any Treasury withdrawals.
• ECIP-1114 defines the standardized proposal process that ECIP-1113 enforces for all disbursements.

All four ECIPs are designed for modular and independent activation:

• ECIP-1111 and ECIP-1112 MAY be activated first to begin revenue accumulation.
• ECIP-1113 and ECIP-1114 MAY be activated later, enabling controlled Treasury governance and disbursement without requiring any changes to ECIP-1111.

Copyright

Copyright and related rights waived via
CC0.

Appendix: EVM Precedents for BASEFEE Redirection and EIP-1559 Adoption

ECIP-1111 activates EIP-1559 and EIP-3198 on Ethereum Classic, with the modification that the basefee amount is redirected to the Treasury contract defined in ECIP-1112 rather than burned. While Ethereum Mainnet treats the basefee as a deflationary burn, several EVM networks use alternative designs that redirect protocol-level fee revenue or sequencer revenue toward governance-controlled treasuries. These precedents demonstrate the diversity of fee-handling models within the broader EVM ecosystem.

Precedents for Protocol-Level Revenue Redirection

Lessons Applied in ECIP-1111

• Protocol-Layer Enforcement — ECIP-1111 redirects the basefee amount at the consensus layer, ensuring the behavior is deterministic and identical across all participating clients.
• Consistency with Existing EIPs — ECIP-1111 retains all other EIP-1559 semantics, including dynamic basefee adjustment, transaction pricing, and tip handling.
• Deterministic Treasury Address — ECIP-1112 defines a fixed, consensus-recognized Treasury address to ensure consistent behavior across clients.
• Modular Governance Separation — ECIP-1111 implements revenue redirection only. Governance mechanisms for Treasury withdrawals are defined separately in ECIP-1113 and ECIP-1114 and are not part of this ECIP.

ECIP-1111 adapts the established EIP-1559 fee market to route value to an immutable, protocol-defined Treasury contract rather than burning it, enabling transparent and auditable accumulation of consensus-layer revenue while preserving Ethereum Classic’s Proof-of-Work and immutability guarantees.

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 consideration. The table below categorizes EIPs based on their technical compatibility with Ethereum Classic’s Proof-of-Work model and their relevance to developer tooling and interoperability.

Note: The EIPs listed below are not included in ECIP-1111. Adoption of any additional EIPs would require a separate ECIP, independent community review under ECIP-1000, and successful Mordor Testnet validation before Mainnet activation.

✅ Candidates for Future Evaluation

These EIPs appear technically compatible with ETC’s Proof-of-Work design and may improve developer experience or EVM alignment without introducing breaking changes:

⚠️ Optional or Lower Priority

These EIPs have limited impact or depend on ecosystem factors not currently present on ETC:

❌ Incompatible or Out of Scope (PoS-Specific or High-Risk)

These EIPs require consensus structures incompatible with ETC’s Proof-of-Work model or introduce architectural assumptions ETC does not share:

Community members are encouraged to submit ECIPs for any desired EVM upgrade using the standard process, prioritizing compatibility, security, and Ethereum Classic’s Proof-of-Work integrity.