Olympia Upgrade — ECIP-1111, ECIP-1112, ECIP-1121 Implementation & Mordor Testnet #530
Replies: 15 comments 35 replies
-
📚 Olympia Introduction Series — Finalized (Updated November 2025)Introductory & Educational Articles
Historical & Contextual Articles
Additional Olympia Articles
Implementation Series (2025–2026)
More installments will follow as Mordor testing proceeds. |
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
-
Summary of Olympia Upgrade Resolution Matrix (Updated March 2026)The Olympia Upgrade resolves all major community criticisms through four core ECIPs (1111–1114) and one optional governance-layer enhancement (ECIP-1115). Key architectural choices now finalized across the ECIP suite:
ECIP-1115 introduces optional smoothing as a governance-layer mechanism only. Together, ECIPs 1111–1114 define the consensus-safe, non-inflationary, and fully transparent funding and governance framework for Ethereum Classic. ✅ Olympia Upgrade: Criticism Resolution Matrix (Click to Expand)
📜 Historical Sources of Community Feedback (Click to Expand)
🧩 Olympia Community Feedback Incorporated (Click to Expand)
The finalized November 2025 drafts of ECIP-1111 → ECIP-1114, with optional ECIP-1115, deliver a modular, permissionless, immutable, non-inflationary framework for long-term Ethereum Classic sustainability — while upholding: |
Beta Was this translation helpful? Give feedback.
-
Note on Opposition Tactics (September 2025)It’s become clear that opposition to Olympia is coming from only a handful of Discord accounts, not from material stakeholders in the Ethereum Classic ecosystem. One account in particular — Wedergarten ( @Soteria-Smart-Contracts )— has now been tied on-chain to past scam activity and to a misinformation bot campaign. Others have leaned on conspiracies, chain-split scare stories, and vague threats of petitions or websites. This is not constructive engagement with the ECIP process. For nearly a decade, the community has recognized the need for a decentralized, transparent solution to sustain client development, infrastructure, and security as block rewards decline under ECIP-1017. Olympia (ECIPs 1111–1114) was written to address exactly this — in an opt-in, permissionless way that preserves Proof-of-Work and makes a contentious hard fork extremely unlikely. Targeted deployment: Mordor testnet deployment is Q2 2026. Mainnet activation is targeted for Q3 2026, giving ample time for testnet validation and stakeholder alignment. The material stakeholders — client maintainers, infrastructure providers, miners, and ecosystem contributors — understand the dilemma and are already signaling intent to support Olympia, or any valid alternative solution presented transparently through the ECIP process. What is clear is that doing nothing is not an option for Ethereum Classic or its stakeholders. If Olympia is not the right answer, the productive path is not misinformation or theatrics, but drafting an alternative ECIP that directly solves the same problem. To date, no such alternative has been put forward.
Without a solution, the network faces only two outcomes:
Olympia exists to prevent those outcomes. If you believe there’s a better way, please bring it forward transparently in the ECIP process — not through bots, threats, or off-chain campaigns. |
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
-
Moderator Note (March 2026)The questions raised in this thread have been addressed through implementation. ECIP-1111 and ECIP-1112 do not depend on ECIP-1113 viability — the treasury contract receives funds independently of the governance layer, which is a subsequent deployment. The Ronin network demonstrates this staged rollout pattern in production. Client work implementing ECIP-1111, ECIP-1112, and ECIP-1121 is complete and entering Mordor testnet deployment. This thread is resolved. Marked as outdated. Moderator Note (Nov 2025)The Olympia ECIPs (1111–1115) are now finalized for the November 2025 review phase.
Further discussion is welcome but should be grounded in the current November 2025 specifications and aligned with the ECIP-1000 review process. |
Beta Was this translation helpful? Give feedback.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
-
Olympia Upgrade — March 2026 CheckpointClient implementation of ECIP-1111, ECIP-1112, and ECIP-1121 is complete across three execution clients — Core-Geth, Besu, and Fukuii. Implementations have been validated against go-ethereum, erigon, and nethermind reference clients. A multi-client Hive test suite is in place with both pre and post-Olympia configurations across all three clients. Mordor testnet deployment is the next phase. Block numbers will be set following testnet.
The BASEFEE redirected under ECIP-1111 was specified to be burned under standard EIP-1559. Olympia redirects it instead of destroying it — representing less than 0.01% of current miner income, with all priority fees and tips fully preserved. ECIP-1115 provides a data-driven path for miners to receive basefee distribution directly once core network needs are sustainably funded. |
Beta Was this translation helpful? Give feedback.
This comment was marked as spam.
This comment was marked as spam.
This comment has been hidden.
This comment has been hidden.
-
|
@chris-mercer I kindly request that you stop hiding my comments. They contain useful information for the public to see, especially your recent moderator note, which says:
However, this means that ECIPs 1112 and 1113 have a circular dependency around how the Treasury contract gets linked to its governance executor. ECIP-1112 says the Treasury is immutable — no upgrades, no proxy, no selfdestruct. During the accumulation phase the executor address is set to an invalid value so withdrawals are blocked. But 1112 doesn't define how that address later gets updated to point to the real executor. It says "see ECIP-1113." ECIP-1113 says the executor address "SHALL be hardcoded into the Treasury according to ECIP-1112's deployment rules." It points back to 1112 for the mechanism. Neither spec actually defines the concrete step where an immutable contract transitions from an invalid executor address to a valid one. For an immutable contract there are really only two options:
The claim that "governance activates as a contract layer after the consensus fork with no second hard fork required" and uses a "staged admin transfer with mandatory delay" doesn't appear to be grounded in either specification as written. One of these two proposals needs to own this transition mechanism and specify it concretely, because right now they each defer to the other. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Olympia Upgrade — ECIP-1111, ECIP-1112, ECIP-1121 Implementation & Mordor Testnet
Last Updated: March 2026 — Client Implementation Complete, Mordor Testnet Phase
Olympia is a protocol upgrade initiative that introduces a protocol-native funding primitive to Ethereum Classic — designed to secure the long-term health of the network for miners, developers, and the broader ETC ecosystem.
The term Olympia refers to a family of ECIPs, not a single mandatory governance system. These ECIPs share common design goals but differ in scope, activation requirements, and consensus impact. No new issuance is introduced at any phase.
Why Olympia Matters for Miners
Ethereum Classic miners are the backbone of the network. Olympia is designed with miners in mind at every stage.
The basefee was going to be burned. Under the standard EIP-1559 specification, the basefee is destroyed — permanently removed from circulation. Olympia diverts this value instead of burning it, redirecting it into a transparent on-chain treasury to fund the core software and infrastructure that keeps the network miners are securing alive and competitive.
The math is straightforward. At current transaction volumes, the basefee represents less than 0.01% of total miner income. All miner tips and priority fees are fully preserved. This is not a tax on miners — it is a redirect of value that would otherwise be destroyed.
The long-term play is for miners. As ETC's block rewards decline on the emission curve, network security depends increasingly on transaction fee volume. Olympia builds the infrastructure — client software, public RPC endpoints, block explorers, bootnodes — that attracts the on-chain activity needed to grow that fee market. A robust fee market on ETC is the long-term security budget for proof-of-work mining. Olympia builds toward that directly.
Miners participate in the upside. Once core network needs are sustainably funded, ECIP-1115 provides a path for miners to receive a share of the basefee directly — with distribution parameters informed by real empirical data from a live fee market rather than theoretical models. This is not hardcoded at launch; it is designed to be dialed in correctly once the data exists to do so responsibly.
March 2026 Update
Client implementation of ECIP-1111, ECIP-1112, and ECIP-1121 is complete across three execution clients — Core-Geth, Besu, and Fukuii. Implementations have been validated against go-ethereum, erigon, and nethermind reference clients. The multi-client Hive test suite is in place with both pre and post-Olympia configurations. Mordor testnet deployment is the next phase. Block numbers will be set following testnet.
Consensus-Affecting ECIPs
The following ECIPs introduce consensus-layer changes and require explicit network upgrades if adopted:
Application-Layer and Mixed-Scope ECIPs
The following ECIPs operate entirely above consensus or depend on prior consensus changes without introducing new consensus rules themselves:
Design Constraints
Discussion Scope (March 2026)
This thread serves as a shared discussion venue for:
Note: ECIP-1116 and ECIP-1120 represent protocol-level hardcoding of distribution mechanisms. These are scoped for evaluation after observable empirical evidence from ECIP-1115 experimentation and are not tracked in this thread.
No proposal discussed here is implied to be final, canonical, bundled, or mutually dependent unless such dependency is explicitly stated in the ECIP itself.
Moderation Note: This discussion thread is actively moderated. Comments that are outdated, resolved, or spam are hidden to maintain clarity. Hidden comments remain accessible via the "Show comment" toggle for anyone wishing to review the full history.
Beta Was this translation helpful? Give feedback.
All reactions