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 (ECIP-1112) — an immutable, governance-isolated on-chain funding contract governed exclusively by the Olympia DAO (ECIP-1113) through the Ethereum Classic Funding Proposal Process (ECIP-1114).

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

Until governance is activated via ECIP-1113 and ECIP-1114, 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), governed exclusively through the DAO-designated execution contract (ECIP-1113) via the Ethereum Classic Funding Proposal Process (ECIP-1114). Off-chain administrative execution and optional fiat interfacing are supported by the Ethereum Classic DAO LLC, a Wyoming-registered legal wrapper that operates strictly under binding instructions from on-chain governance, with no 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 immutable, governance-isolated smart contract defined in ECIP-1112, governed exclusively through Olympia DAO (ECIP-1113) and the Ethereum Classic Funding Proposal Process (ECIP-1114). This design ties network activity directly to a transparent, non-inflationary security and development budget 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, on-chain funding mechanism enforced at the consensus layer. In addition, the Olympia Treasury address is fixed and deterministically derived via the CREATE2 deployment method as specified in ECIP-1112. This ensures reproducible, cross-client address derivation and prevents any modification to the treasury destination after activation.

• 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, immutable, 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 (ECIP-1113) through the Ethereum Classic Funding Proposal Process (ECIP-1114).

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 administrative support and optional fiat handling follow the governance and legal interface model 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 — at the consensus layer — to the immutable, governance-isolated Olympia Treasury (ECIP-1112), hardcoded at a deterministic address derived via CREATE2. This treasury is accessible only to the authorized DAO executor defined in ECIP-1113, which may release funds solely through successful proposals approved under the Ethereum Classic Funding Proposal Process (ECIP-1114).
  • 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.

Example: Hardcoded BASEFEE Redirection

// --- BEGIN PSEUDOCODE ---
// This logic is implemented at the client level (e.g., Core-Geth) in Go.
// It illustrates how EIP-1559's BASEFEE is redirected to the Olympia Treasury
// instead of being burned (as on Ethereum mainnet).

func finalizeBlock(block *Block, state *StateDB) error {
    ...
    // Calculate total BASEFEE from gas used in all transactions
    baseFeeAmount := block.GasUsed * block.BaseFee

    // Redirect BASEFEE to the fixed Olympia Treasury address
    treasuryAddress := common.HexToAddress("0x4242...ecip1112") // Replace with deployed value
    state.AddBalance(treasuryAddress, baseFeeAmount)

    // Miner still receives priority fees (tips)
    minerAddress := block.Coinbase
    state.AddBalance(minerAddress, block.TotalPriorityFees())

    ...
    return nil
}
// --- END PSEUDOCODE ---

Pseudocode Notes

• This is illustrative only — the real implementation resides in Core-Geth’s mining and state transition logic.
• StateDB is Core-Geth’s execution ledger, used to apply balance changes during mining.
• This logic is consensus-critical and must match across clients to preserve fork integrity.

🔒 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 (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 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 mirrors ECIP-1112’s minimalist vault architecture and ECIP-1113’s modular governance structure, ensuring each layer can be activated or upgraded 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 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.
EIP-1559 and EIP-3198 adoption also fulfills the dependency 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.
• 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 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
• 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 governance is activated via ECIP-1113 and disbursement rules are applied through the Ethereum Classic Funding Proposal Process (ECIP-1114).

Activation of governance control over the Olympia Treasury requires:

• Deployment of the Olympia DAO Governance Framework (ECIP-1113), which serves as the designated on-chain execution contract for treasury disbursements.
• Compliance with the Ethereum Classic Funding Proposal Process (ECIP-1114) for all treasury allocations. These dependencies ensure that treasury control is never transferred without full community-approved governance infrastructure in place.

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 & Reference Client

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 with consensus-layer BASEFEE redirection to the Olympia Treasury (ECIP-1112)
• EIP-3198 — BASEFEE opcode for contract-level gas visibility

Reference Client

• Core-Geth will serve as the reference implementation for the Olympia upgrade.
  Maintained by the Ethereum Classic community, Core-Geth implements:
  • EIP-1559 (dynamic base fee and transaction type 2)
  • EIP-3198 (BASEFEE opcode)
  • Consensus-layer BASEFEE redirection to the immutable Olympia Treasury (ECIP-1112), accessible only to the authorized DAO executor (ECIP-1113) for disbursements approved via the Ethereum Classic Funding Proposal Process (ECIP-1114)
    These features are available under the olympia-upgrade branch.

Client Requirements

All ETC client teams MUST implement:

• Correct fee market behavior and basefee targeting logic (per EIP-1559)
• Support for both legacy and EIP-1559 transaction types
• Accurate BASEFEE opcode return values
• Consensus-layer BASEFEE redirection to the deterministic Olympia Treasury address defined in ECIP-1112
• Replay protection between legacy and upgraded chains

Testing and Coordination

Validation MUST occur on the Mordor Testnet before 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
• Accurate BASEFEE redirection to the treasury at the consensus layer
• Fork ID and replay protection validation
• Integration testing with governance and funding process contracts from ECIPs 1113 and 1114

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 consensus-layer redirection of BASEFEE and the activation of EVM changes defined in EIP-1559 and EIP-3198.

Implementation of:

• ECIP-1112 — Olympia Treasury Contract
• ECIP-1113 — Olympia DAO Governance Framework
• ECIP-1114 — Ethereum Classic Funding Proposal Process

…is defined in those proposals and may be deployed independently in a phased rollout, consistent with the Modular Activation model.

Coordination with client teams, including maintainers of Core-Geth, will be required to ensure timely implementation. Third-party contributors or ecosystem developers may be enlisted to complete client-side changes, formalize testnet deployments, and validate consensus behavior.

EIP Compatibility Scope

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

• EIP-1559 — Dynamic fee market with consensus-layer BASEFEE redirection to the immutable Olympia Treasury (ECIP-1112)
• 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 in the Appendix: EVM Compatibility Roadmap and Upgrade Candidates section of this ECIP.

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) — Routes BASEFEE to a DAO-governed treasury supporting infrastructure, validators, and ecosystem growth.
• Celo — Redirects gas fees to a DAO-controlled Gas Fee Handler for community initiatives and climate-positive programs.
• Mantle — Sends sequencer revenue to a DAO-managed treasury that funds grants, tooling, and infrastructure.
• Polygon CDK — Enables sovereign rollups to integrate EIP-1559-compatible treasury redirection for protocol governance and upgrades.
• OP Stack (used by Base, Optimism) — Supports sequencer revenue splitting to fund public goods through governance-controlled treasuries.
• Arbitrum — DAO-governed treasury funded by sequencer revenue; allocations decided via the Arbitrum Improvement Proposal (AIP) process.
• Optimism — Allocates sequencer revenue to Retroactive Public Goods Funding (RPGF) to reward impactful ecosystem contributions.
• zkSync Era & Scroll — Include sequencer revenue hooks to fund development incentives and ecosystem growth.
• Avalanche Subnets — Some subnets route transaction fees to validator-governed treasuries for ongoing maintenance and ecosystem investment.
• Gitcoin DAO — While not funded via BASEFEE, Gitcoin DAO’s governance and grant allocation model demonstrates transparent, community-driven public goods funding.

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. They also validate the neutrality, transparency, and sustainability of protocol-native funding mechanisms.

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 monetary policy 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)
• Consensus-layer redirection of the BASEFEE to the immutable Olympia Treasury (ECIP-1112)

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.

Client Upgrade Requirements

• Clients that do not implement Olympia 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 (dynamic fee market)
  • EIP-3198 (BASEFEE opcode)
  • Consensus-layer BASEFEE redirection to the hardcoded 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 contracts.
• Opt-In Behavior — Users, miners, and developers may continue using legacy transactions if desired; new features are optional.

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

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 focus on ensuring correct and consistent implementation of the consensus-layer BASEFEE redirection to the immutable Olympia Treasury (ECIP-1112).

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 chains.
• Formal Validation — These features have undergone formal verification, economic analysis, and multi-client consensus testing over several years.

2. BASEFEE Redirection Logic

• Single Deviation from Ethereum Mainnet — The only functional difference is the redirection of BASEFEE to the Olympia Treasury rather than burning it.
• Consensus Enforcement — This behavior is enforced at the protocol layer; all clients must implement identical logic to avoid consensus divergence.
• Immutable Treasury Contract — The Treasury (ECIP-1112) is governance-isolated and contains no upgrade paths, admin keys, or backdoor withdrawal mechanisms.

3. Client Implementation Requirements

• State Transition Accuracy — Clients must correctly calculate and transfer the BASEFEE to the treasury address to avoid:
  • Rounding errors
  • Ledger inconsistencies
  • Misaccounted gas usage
• Modified Test Vectors — Ethereum Mainnet test vectors that assume burning must be updated to validate proper accumulation into the treasury.
• Cross-Client Alignment — All participating clients must apply identical redirection logic to maintain consensus compatibility.

4. Treasury Isolation and Governance Safety

• Execution Separation — ECIP-1111 does not include governance logic; disbursement is controlled exclusively by the Olympia DAO (ECIP-1113) and the Ethereum Classic Funding Proposal Process (ECIP-1114).
• No Off-Chain Control — No entity can move treasury funds outside of governance-approved on-chain proposals. All such governance-approved proposals MUST follow the Ethereum Classic Funding Proposal Process (ECIP-1114) to ensure that disbursements are transparent, standardized, and bound to an immutable on-chain execution payload.

5. Testnet and Audit Strategy

• Mordor Testnet Deployment — Full feature activation will occur on Mordor before mainnet, including:
  • Legacy and Type-2 transaction handling
  • Accurate BASEFEE accounting
  • Treasury accumulation verification
  • BASEFEE opcode functionality
• Audit Coordination — Although ECIP-1111 affects consensus logic only, its implementation should be audited in parallel with ECIP-1112–1114 to validate end-to-end integration.

Summary

The Olympia Upgrade applies established EVM improvements and adds a single, consensus-level modification to redirect BASEFEE to a transparent, immutable treasury. It preserves all EVM guarantees, introduces no backward-incompatible changes, and maintains strict separation between consensus rules and governance execution. With thorough testnet validation, cross-client alignment, and audits, the upgrade strengthens Ethereum Classic’s sustainability and security.

Related ECIPs in the Olympia Upgrade

ECIP-1111 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 BASEFEE Redirection and EIP-1559 Adoption

ECIP-1111 activates EIP-1559 and EIP-3198 on Ethereum Classic while modifying the default EIP-1559 behavior to redirect the BASEFEE to the Olympia Treasury (ECIP-1112) instead of burning it.
This approach draws on precedents from EVM-compatible networks that have adopted EIP-1559 or similar fee mechanisms while directing protocol revenue toward ecosystem funding rather than permanent destruction.

Precedents for BASEFEE Redirection

Lessons Applied in ECIP-1111

• Protocol-Layer Enforcement — Like Ronin and Celo, ECIP-1111 routes fees at the consensus layer to prevent diversion or bypass.
• Sustainability Over Burning — Redirecting BASEFEE creates a non-inflationary funding stream without altering Ethereum Classic’s fixed monetary policy.
• Interoperability with Existing EIPs — Retains full EIP-1559 semantics for transaction pricing and BASEFEE calculation, ensuring compatibility with existing tooling.
• Deterministic Treasury Address — Uses a fixed, consensus-recognized address (ECIP-1112) to ensure cross-client consistency.
• Governance Isolation — Revenue is stored in an immutable vault, accessible only via the governance process defined in ECIP-1113 and ECIP-1114.

By adapting the proven concept of EIP-1559 to redirect value to a community-governed treasury rather than burning it, ECIP-1111 ensures that Ethereum Classic captures sustainable, protocol-native funding while preserving its Proof-of-Work and immutability principles.

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.

Note: The EIPs listed below are not included in ECIP-1111. Their adoption would require a new ECIP, full community consensus under ECIP-1000, and successful Mordor Testnet validation before mainnet activation.

✅ 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.