I. Introduction — From Concepts to Code
Part 0 introduced Olympia at a high level: its purpose, its history, and how ECIPs 1111–1115 fit into a modular, multi-layer upgrade path. This installment steps into the engineering work underway for the two ECIPs that define Olympia’s consensus boundary:
- •ECIP-1111 — EVM & Protocol Upgrades
- •ECIP-1112 — Immutable Treasury Contract
These two proposals are the only components of Olympia that modify consensus behavior. Everything else in the framework — governance (ECIP-1113), funding proposals (ECIP-1114), and optional smoothing (ECIP-1115) — operates at the contract layer and does not affect block validity or fork choice.
On 11/11/2025, Ethereum Classic core developers began the implementation phase, preparing the consensus logic and reference-client plumbing for potential Mordor testnet deployment.
This article outlines:
- •what ECIP-1111 introduces,
- •how ECIP-1112 defines the Treasury destination,
- •how these components fit together,
- •and what is currently being prototyped within reference-client development efforts.
This article describes the proposed design and implementation work without implying future activation or acceptance under the ECIP-1000 process.
II. ECIP-1111 — Modernized Fee Mechanics, Minimal Network Disruption
ECIP-1111 incorporates two widely used EVM improvements:
1. EIP-1559-style fee mechanics (BASEFEE + optional tip)
This introduces:
- •a dynamically adjusting BASEFEE,
- •optional priority fees (tips) that continue going directly to miners,
- •and a more predictable fee market used across modern tooling.
2. Type-2 (1559-style) transaction support
Already standard across most wallets and infrastructure.
3. BASEFEE opcode (0x48)
This exposes the current block’s BASEFEE to contract logic (gas estimators, DEX routers, tooling, etc.).
What changes for ETC?
Only one behavior differs from Ethereum Foundation (ETH) Mainnet:
- •Ethereum Foundation (ETH): BASEFEE is burned.
- •Ethereum Classic (ETC): BASEFEE is redirected to the Treasury defined in ECIP-1112.
All other EIP-1559 semantics remain unchanged.
What does not change?
- •Miner tips remain unchanged.
- •Block rewards remain unchanged.
- •Monetary policy (ECIP-1017) remains unchanged.
- •Legacy transaction types (Type-0 and Type-1) remain fully valid.
- •No contracts break; existing applications require no changes.
- •No additional trust assumptions or permissioning are introduced.
ECIP-1111 is additive, minimal, and strictly scoped to modernizing fee mechanics and enabling BASEFEE redirection.
III. ECIP-1112 — An Immutable, Deterministic Treasury
ECIP-1112 defines the destination for redirected BASEFEE amounts: a minimal, immutable smart contract deployed at a deterministic address.
Key properties
- •Immutable: No upgrade keys, no administrators, no proxy patterns.
- •Deterministic address (e.g., via CREATE2): All clients agree on the same Treasury destination.
- •Receive-only at activation: The Treasury can accumulate value but cannot release it until governance is later activated.
- •No governance logic inside: It is strictly a custody layer, not a decision-making layer.
At activation (testnet or mainnet):
- •The Treasury can only receive funds.
- •No withdrawal mechanism is enabled until ECIP-1113 and ECIP-1114 are deployed, audited, and intentionally activated.
This separation keeps the consensus upgrade predictable and independent from any future governance rollout.
IV. A Clear Consensus Boundary
Although Olympia includes five ECIPs, only ECIP-1111 and ECIP-1112 alter consensus behavior.
Consensus Boundary Summary
- •ECIP-1111 — Protocol layer. Introduces a consensus change: adds BASEFEE mechanics, Type-2 transactions, and the BASEFEE opcode.
- •ECIP-1112 — Protocol/Contract layer. Introduces a consensus change: defines the deterministic Treasury destination for redirected BASEFEE.
- •ECIP-1113 — Contract/Application layer. No consensus changes.
- •ECIP-1114 — Contract/Application layer. No consensus changes.
- •ECIP-1115 — Contract/Application layer. No consensus changes.
This modular structure ensures:
- •consensus-critical logic remains small and auditable,
- •governance and funding mechanisms can evolve at the contract layer,
- •improvements to ECIP-1113–1115 do not require additional consensus changes.
If adopted, clients implementing ECIP-1111 and ECIP-1112 would remain consensus-compatible regardless of later governance-layer deployments.
V. Why Governance Activation Occurs Later
If ECIP-1111 and ECIP-1112 were activated, BASEFEE would begin flowing into the Treasury — but Treasury spending would remain disabled.
This two-stage rollout allows:
- •independent testing of BASEFEE accounting,
- •full audits of ECIP-1113 and ECIP-1114,
- •careful coordination among client implementers and infrastructure providers,
- •predictable behavior for node operators.
If governance contracts were later deployed and activated, the Treasury would be connected to its authorized executor entirely at the contract layer — not the consensus layer.
VI. Type-2 Transactions and Long-Term EVM Interoperability
Type-2 support is essential for ETC to remain compatible with:
- •modern wallets,
- •exchanges and custodians,
- •RPC infrastructure,
- •tooling frameworks (Hardhat, Foundry, etc.),
- •block explorers,
- •cross-chain interoperability.
Type-2 transactions do not alter user requirements or introduce permissioning. Legacy transaction types stay fully supported.
Type-2 is an additive feature that maintains ETC’s interoperability with the dominant transaction formats used across the EVM ecosystem.
VII. Broader Context — Maintaining a Programmable PoW Base Layer
Taken together, ECIP-1111 and ECIP-1112 provide a foundational step toward enabling Ethereum Classic to explore sustainably funded, programmable Proof-of-Work operation — if the community chooses to adopt them.
They do so without:
- •modifying miner incentives,
- •introducing inflation,
- •altering monetary policy,
- •adding governance to consensus,
- •changing ETC’s security assumptions.
Their purpose is strictly to:
- •modernize the fee market,
- •establish a transparent protocol-level value destination.
If adopted, these changes enable the contract-layer governance and funding systems proposed later in Olympia without requiring additional consensus rules.
VIII. Conclusion — Minimal, Safe, and Forward-Compatible
ECIP-1111 and ECIP-1112 define the consensus-layer elements proposed within the Olympia framework. They:
- •add Type-2 and BASEFEE mechanics,
- •redirect BASEFEE to a deterministic Treasury,
- •keep all existing user and miner behaviors unchanged,
- •prepare ETC for future contract-layer components.
They do not introduce governance logic into consensus and do not add new trust assumptions beyond existing EIP-1559 / EIP-3198 semantics.
The intent is to keep ETC’s core protocol conservative and compatible with the broader EVM ecosystem, while enabling sustainable value flow at the contract layer.
ECIP Procedural Clarity
The Olympia ECIPs (1111–1115) are currently in Draft status and remain under active discussion.
Early implementation work on ECIP-1111 and ECIP-1112 within a reference client has begun, which is fully permissible at the Draft stage under ECIP-1000. Reference implementations will undergo testing on the Mordor Testnet prior to any consideration of mainnet activation.
Upon successful testnet results, ECIP authors may propose updates to the specifications. Any consideration of advancing toward Accepted status or scheduling a mainnet activation would occur only after community review and full ECIP-1000 evaluation.
This article summarizes the design and implementation work underway during the Draft phase.
Next in the Series
👉 Olympia Development Series (Part 2): Exploring ECIP-1112 — The Immutable Treasury Contract