Ethereum Classic
Olympia Upgrade — ECIP-1111, ECIP-1112, ECIP-1121 Implementation & Mordor Testnet #530
Replies: 26 comments 50 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. |
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment has been hidden.
This comment has been hidden.
Hi, Ethereum Classic community! I just found this discussion from https://ecips.ethereumclassic.org/ECIPs/ecip-1113. From this ECIP, I learned that your community seems to have chosen a custom governance contract based on the OpenZeppelin Governor contracts. I want to introduce our UI/UX solution, https://github.com/ringecosystem/degov, for your consideration. It is designed based on the standard OpenZeppelin Governor contract. To support Ethereum Classic governance, we may need to make some customizations, but it should be easy. Please let me know if you are interested. |
Thanks for adding this contribution to the discussion — a great example of a UX built around the OpenZeppelin Governor contracts highlighted in the spec. If you’re interested in integrating with Ethereum Classic, it would be extremely helpful to add support for Mordor testnet (for experimentation) and ETC mainnet (for production) into your project. For testing on Mordor, here’s a faucet for some mETC: The community would very much welcome open collaboration on this. As Olympia governance progresses, having a user-friendly interface will be an important piece of the ecosystem. Feel free to experiment, share progress — your contributions could have a real impact in making ETC governance more accessible. |
|
Glad to help! Will check the details next week and give it a try. |
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: |
Summary of ECIP-1111 Responses (Updated March 2026)ECIP-1111 activates EIP-1559 and EIP-3198 on Ethereum Classic as part of the Olympia upgrade.
ECIP-1111 is minimal and consensus-only: it introduces no governance logic, no new tokens, and no changes to miner priority fees. ECIP-1111 preserves ETC's monetary policy under ECIP-1017 (fixed issuance, no inflation), maintains full miner incentives, and brings ETC into alignment with modern EVM standards for tooling, UX, and interoperability. ✅ ECIP-1111: Criticism / Response Mapping (Click to Expand)
This March 2026 revision reflects the final ECIP-1111 architecture and implementation status:
|
Summary of ECIP-1112 Responses (Updated March 2026)ECIP-1112 defines the Olympia Treasury, an immutable, consensus-enforced smart contract deployed at a deterministic address via The Treasury's responsibilities are intentionally minimal:
The Treasury cannot be modified, overridden, paused, upgraded, or accessed directly by any EOA, multisig, DAO LLC, or contract other than the authorized executor. Because ECIP-1112 contains no governance logic, all participation, voting, security parameters, and upgrade paths live entirely in ECIP-1113 (governance) and ECIP-1114 (funding process). ✅ ECIP-1112: Olympia Treasury Contract — Criticism / Response Mapping (Click to Expand)
This March 2026 revision fully aligns ECIP-1112 with the finalized Olympia architecture and implementation status:
The Treasury remains the immutable foundation of ETC's transparent, protocol-native funding system. |
Summary of ECIP-1113 Responses (Updated March 2026)ECIP-1113 defines the Olympia DAO governance framework, the sole on-chain executor authorized to release funds from the immutable Olympia Treasury (ECIP-1112). All Treasury disbursements must pass through the Governor → Timelock → Executor pipeline and use the hash-bound, chain-ID-protected execution model defined in ECIP-1114. Optional, strictly limited safety modules include:
Child-DAO modules (Client/Infra/Security) provide recurring, auditable pipelines for core infrastructure while remaining fully subordinate to the main DAO. ECIP-1113 corrects the failures of ECIP-1098 by ensuring:
The result is a secure, capture-resistant, minimal, and modular governance system aligned with ETC's Proof-of-Work, immutability, and neutrality. ✅ ECIP-1113: Criticism / Response Mapping (Click to Expand)
This March 2026 revision reflects the finalized governance architecture and current implementation status:
|
Summary of ECIP-1114 Responses (Updated March 2026)ECIP-1114 defines the Ethereum Classic Funding Proposal (ECFP) process, the exclusive, standardized, and permissionless workflow for requesting and executing disbursements from the immutable Olympia Treasury (ECIP-1112). ECIP-1114 ensures that every funding decision is:
The ECIP is designed to be minimal and modular: ✅ ECIP-1114: Criticism / Response Mapping (Click to Expand)
This March 2026 revision aligns ECIP-1114 with the complete Olympia architecture and current implementation status:
The ECFP lifecycle provides Ethereum Classic with a transparent, decentralized, deterministic funding mechanism for the next decade. |
Summary of ECIP-1115 Responses (Updated March 2026)ECIP-1115 introduces an optional governance-layer smoothing mechanism that reshapes a configurable portion of Treasury-held BASEFEE revenue across a future window using a deterministic L-curve.
ECIP-1115 defines only a framework. The smoothing module cannot withdraw funds automatically — every payout requires a normal ECFP → DAO vote → timelock → executor call. Its purpose is to create more predictable long-term miner-support schedules as fixed issuance (ECIP-1017) declines — without altering block rewards, EIP-1559 semantics, or supply. ECIP-1115 is the data-driven path for miners to receive a share of the basefee directly — with distribution parameters set after real fee market evidence exists, not before. This is by design: getting the parameters right matters more than getting them first. ECIP-1115 enables ETC to gradually explore long-term, non-inflationary miner-alignment tools while preserving strict immutability, neutrality, and DAO-controlled evolution. ✅ ECIP-1115: Criticism / Response Mapping (Click to Expand)
This March 2026 revision reflects the final ECIP-1115 design and its role in the phased deployment sequence:
Deployment sequence: ECIP-1111/1112 activate → Treasury accumulates → CoreDAO deploys → fee market data collected → ECIP-1115 parameters informed by evidence → miner distribution path opens.
ECIP-1115 provides ETC a future-proof, non-inflationary way to smooth Treasury-based miner incentives as long-term security needs evolve. |
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 — 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. 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.
|
This comment has been hidden.
This comment has been hidden.
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. The executor address is pre-computed via CREATE2 and hardcoded into the Treasury at deploy time — the governance contract deploys to that address later, no setter required. 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. |
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
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.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
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. Branch links, block numbers, and testnet configuration will be published together as a coordinated Mordor activation announcement.
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. |
|
@chris-mercer Please can you provide links to the client implementation code? |
|
Branches will be shared at Mordor activation. The release is coordinated: code, block numbers, and testnet configuration drop together as a single announcement. |
|
Claiming client implementation is "complete" across three clients while declining to share the code is a red flag. The ECIP process is an open standard — reviewers need to be able to inspect the implementation to verify the claims being made, especially for consensus-level changes like BASEFEE redirection. "Branches will be shared at Mordor activation" is backwards. The point of review is to catch problems before testnet deployment, not after. If the code exists and works across Core-Geth, Besu, and a new client (Fukuii), there's no technical reason to withhold it. Reviewable code is how open processes work. Withholding it just asks the community to trust the claim. |
|
We agree with Istora - code should be shared when implementation is deemed complete. We personally even like sharing it sooner as drafts when it is still a work in progress because who knows when serendipity or questions might benefit the code or design? |
|
This comment was marked as spam.
This comment was marked as spam.
For the record, in the new ETC Discord, I tried to ask @chris-mercer again about the bootstrapping problem discussed in my comment that was hidden above. He didn't answer directly and told me to review call 42. This call didn't address the concern, which I have summarized: Olympia Bootstrap — The Unsolved Problem (Calls 42–43) Olympia requires a DAO to manage treasury funds, but how do you fairly bootstrap voting rights on a decentralized chain? Cody on the bootstrapping problem:
Istora agreed — coin voting is the only objective on-chain mechanism, but it's manipulable by whales and excludes cold-storage holders. Any alternative requires an admin system to decide who gets tokens, reintroducing centralization. Istora challenged Mercer directly:
Mercer pointed to BrightID and said "the ECIP has many examples" (00:58:34). We've reviewed the full transcripts of these calls with AI analysis and cannot find any concrete, worked-out mechanism for how bootstrapping would actually be deployed on ETC. On multiple hard forks:
The bootstrap problem remains the central unresolved blocker. Without a credible, fair mechanism to initialize governance, the treasury has no accountable way to operate. |
@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. |
|
To follow up, and for the wider community's information, I have discovered the code that is being worked on for Olympia. chris-mercer/core-geth@5da85c2 It's publicly available on github, and the contract contract referenced is deployed on chain. https://etc.blockscout.com/address/0xd6165F3aF4281037bce810621F62B43077Fb0e37?tab=contract 
This means that there is indeed an admin key and the current approach appears to just be a simple externally owned account that will be responsible from transitioning from 1112 into 1113. If this is the plan, and we can only assume it is because the author calls it "complete" and references this "staged admin transfer" in comments (but not the spec(!)), it represents an existential danger to the chain and must be opposed. It should be clear why but to spell things out.
Despite multiple attempts for me to get clarification about this process, as documented above, my questions been been avoided by author @chris-mercer, and this process and safety guarantees have not been documented at all. Again, I hope Olympia authors can clarify what the game plan with this transition is, but things cannot go forward in the current state, and it is highly concerning that announcements about Mordor testnet deployments are being made without a coherent plan. If this is not the plan, then it makes no sense to be avoiding this topic and working on code before getting any feedback about it. |
|
The contract referenced is a Mordor testnet deployment using OpenZeppelin's |
|
Sorry, @chris-mercer, I can't find what you're referring to in 1113 10.3: 
|
|
I've reviewed the olympiadao repos and the treasury contract implementation, and want to add some technical clarity to the current exchange. On the admin key concern The contract at The real issue: the spec and the implementation diverge That said, Istora's core instinct is correct that something is underdocumented — it's just not what was identified. ECIP-1112 as written describes a contract with "no admin keys, no privileged roles" and a single Three specific things that need to be addressed before Mordor activation is meaningful:
On code transparency The olympiadao GitHub org has been public the entire time and contains the full implementation. Pointing to it in this thread earlier would have preempted a lot of the confusion here. One additional item for me The olympiadao org lists ECIP-1117 as Futarchy DAO and ECIP-1118 as Futarchy Funding - there are existing draft ECIPs in those number slots that cover futarchy governance for ETC that need to be pushed. That numbering needs to be reconciled to avoid the same kind of collision that just created noise in the Elysium PRs. None of this changes the core technical direction, which is sound. But the spec needs to match the implementation before testnet deployment is a meaningful signal. |
Acknowledged. The referenced contract linked by @IstoraMandiri is demo v0.1 with testnet parameters for fast iteration. As Cody has clarified, the production deployment follows the CREATE2 pre-computation model — the governance executor address is hardcoded into the Treasury at deploy time, the executor contract deploys to that predetermined address later, and no admin key, setter function, or transition ceremony is required. ECIP-1112 will be updated to specify this concretely. ECIP-1117/1118 numbering has been resolved. Specs and implementation will be aligned in the coordinated announcement. Update Note: This is complete in live demo v0.2 |
|
Thank you @realcodywburns for clarifying that the Olympia spec is indeed incoherent in it's current state. I disagree with some of your framing; I don't think we can say something is technically sound if it's yet to be defined.
Is just false, since you are the first person to link to it in this discussion thread (Chris refused to share this code), and the first commit was 3 weeks ago. 
It's a shame that @chris-mercer doesn't have the confidence to directly respond to my critiques, as they've been standing since November without much change. We could have saved ourselves a lot of wasted time if authors had engaged in open discussion, a key requirement of ECIPs to be approved, but this has been avoided or intentionally misdirected, as documented by this discussion thread. This comment I posted earlier is still being edited and hidden from public view by @chris-mercer : 
This behavior is clearly biased in and in my belief is taking advantage of the ECIP maintainer role to shape discussion artificially in favor of the author's proposal, undermining the role itself and creating a concerning precedent. The role of maintainer should be neutral and not be weaponized to suppress opposing opinions. There's no need to hide this stuff from the public - let them make their own minds up instead of you deciding for them whether they should see it. I anticipate that the same tactics and avoidance of open discussion will continue with regards to this multisig spec, and the original issue of bootstrapping a DAO (weather it's via a multisig or not) remains completely unaddressed, but I will try to start a discussion nonetheless. I won't comment on this yet-to-be defined multisig, but I look forward to seeing it. Needless to say, a multisig brings it's own set of challenges, and honestly seems like a last minute change without much thought put into it. It's quite a coincidence that this is suddenly being added to the spec, especially since "no multisig" or admin keys has been touted repeatedly up until this point (1). I also want to reiterate that a multisig does not address the bootstrap problem itself - it merely kicks the can down the road and assumes it can be solved by some also undefined multisig council. Protocol neutrality, anyone? Remember, Ethereum Classic is founded on the idea that:
Announcements about "clients complete" and "testnet deployment" have been made before the spec is even complete, as you point out. Why are we doing testnet deployments before the spec is complete? How can the community reach consensus on a proposal that is not actually defined, and why does it feel like this critical step is being recklessly overlooked? (1) |
|
For the record I want to note that cody's post on 2026.03.18 was first actual mention of a "Specification" for this mechanism anywhere, which I've been asking for since November. 
The current specification is as follows:
So "it's a multisig of some sort" is all the spec we have to work with. We do know that it will be used to spend funds. We still need to understand:
|
|
A correction on my previous comment: I overstated the availability of the olympiadao org. The org was created approximately three weeks ago — it predates this nine-day comment thread but is recent development work, not a long-standing public resource. Saying it "has been available the entire time" was imprecise. Point taken. On the "incoherent" framing: I'd push back on that characterization. A spec that needs to be brought into alignment with an implementation is a documentation gap, not an architectural incoherence. The underlying mechanism - staged access control with a deterministic executor handover - is sound. The problem Istora correctly identified is that the v0.1 deployed contract uses On the bootstrap problem specifically: This is the concrete question that hasn't been answered, and it deserves a direct answer rather than a deferral. The cleanest resolution (and the one most consistent with what ECIP-1112 actually describes in text) is to hardcode the governance executor's future CREATE2 address into the treasury contract at deployment time. That address has no code at it initially. Any call to This makes the bootstrap question verifiable rather than trust-based: does the deployed DAO bytecode match the executor address hardcoded in the treasury? Anyone can check this independently. The community controls activation by controlling whether and when that contract gets deployed. A fraudulent DAO deploying to a different address gets no access. The only valid activation path is the pre-agreed bytecode at the pre-agreed address. The constraint this imposes -that the DAO contract's bytecode must be finalized before the treasury is deployed - is a feature, not a limitation. It forces governance design to be published and agreed before any ETC flows in, which is exactly what the process should require. The v0.1 contract is development code with testnet parameters. The production deployment needs to implement this pattern rather than the EOA admin model, and ECIP-1112 needs to be updated to specify it concretely rather than deferring to ECIP-1113. One of those two ECIPs has to own the transition mechanism, right now they point at each other. The comment moderation issue is a separate matter. Hiding substantive technical critique from a co-maintainer in an open ECIP discussion thread undermines the process regardless of which side of the argument it comes from. |
|
Thanks for this important clarification. If the hard code approach is indeed pursued, then 1112 cannot be deployed until we know the CREATE2 address of 1113, which means knowing the code for 1113. This means that Olympia 1111 and 1112 can only move forward if 1113 is first fully specified, audited, tested, validated, and consensus reached about it's mechanisms. This confirms what I have been repeatedly pointing out since November that there is indeed a hard dependency between 1111, 1112 and 1113, and they must be considered and appraised together, and 1112 cannot be deployed before 1113 is. In this case, why even use CREATE2 at all? I look forward to updates to the spec where 1113 is fully defined. |
Olympia Upgrade — April 2026 CheckpointClient implementation of ECIP-1111, ECIP-1112, and ECIP-1121 is complete across three execution clients: Fukuii — New ETC-native execution client.
The CoreDAO governance and funding contracts (ECIP-1113, ECIP-1114) are built on OpenZeppelin's Governor contract suite — heavily audited, widely adopted, and securing billions in treasury funds across the EVM ecosystem. It is likely, Olympia will utilize OpenZeppelin v5.6+ at ETC mainnet activation, leveraging the Spec-aligned phased rollout is live and functional (demo v0.2+):
Like every other ECIP, the Olympia ECIPs will be updated with implementation specifics and activation blocks in the coming future. |
|
As discussion around Olympia continues, additional questions have risen, and to maintain the security of the network, I encourage Olympia Authors to address them before advancing Olympia. It would be appreciated if along with these "Monthly Checkpoints", Authors could provide links to the commit hashes of source code referenced as completed to facilitate community discussion. As a reminder, I am still awaiting an answer to the question regarding Is the intention of the Olympia Authors to roll out 1111 and 1112 without an independent security audit of 1113? Other Olympia authors have indicated that Olympia will require KYC to participate. Is this confirmed? Do Olympia Authors have any comments on the modifications to 1121 suggested by other ECIP maintainers on call https://cc.ethereumclassic.org/calls/49/ ? Concerns have been raised about the whether implementing 1559 on a low utilization network like ETC will accrue any meaningful value into a Treasury. Have Olympia Authors modeled the expected base fees gathered on ETC with various realistic scenarios? If so, please could these figured be shared with the public to facilitate decision making. If not, why not, and how can we be confident that Olympia is likely to achieve it's stated goal of funding development? Thank you, and I look forward to your engagement. |
|
Two topics from my side.
|
|
Federated Web 2.5 with Decentralized Service Level Agreement (DSLA) on Based Rollup (L2)
Token model
DAO Access Model
Private AI Agent Oracles
User Story: The Maintenance Shift The Workflow (The "Boring" Reality)
The Check: The smart contract confirms you hold the Class B (0.25%) Governance Tokens. The Result: A Soulbound JWT (JSON Web Token) is issued to your session.
No password. No MFA app. Just your hardware wallet’s signature. You see the "Daily Work Slop": The Private Telemetry Oracle has flagged a minor memory leak in the latest geth-classic release candidate.
Action: You push your fix and open a Pull Request. The Filter: Because you have the 0.25% stake, your PR isn't flagged as "AI Slop." It goes directly to the Class A (10% Board Members) for review.
Veto/Approval: They sign off on the PR. The code is merged. The Signal: The DSLA contract on records the "Successful Resolution" metric.
|
|
I put it all together. What this whole stack could look like. |
|
I would like to put on the record that the https://nolympia.dev petition was launched in May 2026, and aimed to demonstrate how the wider ETC community feels about Olympia. The petition is a simple signalling of agreement with the following statement:
Prominent community members from East and West have signed it, including:
As well as other OGs, developers, and respected community members. This represents significant opposition and undeniably demonstrates that rough consensus will not be reached with the Olympia proposal. Recent additions of mining pool operators also demonstrate that the hash rate that Olympia needs for a clean majority hard fork is almost certainly not going to materialize, and any attempt to push forward with it will unilaterally impose undue risk on ETC stakeholders, through the potential of a chain split. It is a shame that the nolympia petition was necessary, but this is what happens when consensus gathering is not undertaken before claiming that a controversial hard fork is about to happen. In light of this new evidence, we ask the that the Olympia Authors take the honorable step of formally withdrawing the Olympia set of proposals, so that the Ethereum Classic project can refocus and progress in a direction that can in fact reach consensus. Thank you. |
|
This. |
Olympia Upgrade — May 2026 CheckpointMulti-client stability achieved to May 2026 LTS codebases. All three Ethereum Classic clients are stable, peered, and advertising Olympia as next hardfork on the wire.
What changed since April
Working Demo v0.3 infrastructure — live on Mordor testnet
Institutional Coordinating Organizations
Post-Olympia roadmapETC's core software returns to head-of-branch development following the 2024 maintenance period. In addition to full stack client work, the post-Olympia EL plugin roadmap is in active development via the ETC Cooperative — upstream ETC compatibility layers for Go-Ethereum, Nethermind, Erigon, Besu, and Reth. What's nextContinued client hardening and critical infrastructure modernization. Mordor testnet migration to a post-Olympia environment in preparation. On track for ETC mainnet activation before 2027. Full client details: ethereumclassic.com/build/clients |
|
How do you plan to demonstrate that consensus has been reached on Olympia? |
|
We get it, you don't want to be part of the development of ethereum classic. Are there not better uses of your time than haunting people building tools and doing work. Find some useful way to move the project forward and focus there. Plenty of things to do |
|
Hi Cody, thank you for engaging. While you reply doesn't address my question about consensus, which I still think deserves a proper answer, I'll address your point about my personal motivations, as I think it's important to restart a dialog. I fully reject your framing that I don't want to be part of the development of Ethereum Classic. The hundreds, maybe thousands of hours I've put in over the last decade are evidence of this, and I'm saddened that you'd frame my disagreement over this one proposal as my desire not be part of the project. The opposite is true, and I regard what I'm doing as steadfastly defending the project, at great personal expense in terms of time and opportunity to work on other more productive things. I explained this to Chris in the DM he leaked. This is not something I want to do - it's something I have to. It is a sacred obligation. I won't cease doing everything I can to stop Olympia until it, or at least the basefee redirect element of it, is withdrawn. I recognize that you are trying to solve a real funding problem, but the way you're going about this is not in line with the expectations of participants, nor the rules of the game that Ethereum Classic advertised itself as following. It breaks protocol neutrality, which the whole project was founded upon. There are better alternatives. But I don't want want to re-hash the argument here. Debate and activism from participants is extremely important in ensuring that destructive decisions do not get made. It is the sign of a healthy project with passionate participants that want to defend what they believe make this project special and why they are here in the first place. This type of work, while not directly yielding lines of vibe-code, can be far more valuable, since it manifests a corrective mechanism that the ECIP process is intended to ensure. Lines of code are downstream of this. The invaluable benefits that these debates yield, which you have decided to opt-out of, prevents us from making serious mistakes. Myself, and the majority of the community, believe that Olympia is one of those mistakes. As such, I don't see what I'm doing now as haunting the people doing the work. This might feel like a side effect, but it's not my primary concern. The thing I care about above all is to nurture and protect The Original Ethereum Vision. I did so for the last treasury proposal by spending an ungodly number of hours hand-writing https://ethereumclassicclassic.org. I believe what I wrote, and I'm spiritually committed to defending the protocol once again. One big misstep, which could have avoided this entire debacle, was skipping the consensus gathering around Olympia. This should have been done before announcing it as a the next hard fork. That is the essential step in the process of "moving the project forward", and should have been undertaken before any code was written. Since this was not done, I had to do this job for you, and in doing so I clearly demonstrated where there consensus actually is. For what it's worth, I'm doing plenty of work behind the scenes right now. The fruits of this will bare out in the coming months. How far you want to take things from here is entirely in your hands, but on personal level, I am always willing to separate the individual form the ideas they happen to have in their mind at any given time. The olive branch is a permanent fixture in my mode of operation. I advise against getting further trapped by repeating statements like "Olympias is the next hard fork", or that "miners support Olympia". Both claims were disproved by the nolympia.dev petition, which shows that at least 80% of the mining pool hashrate is explicitly against Olympia, and important community members won't support your fork. This guarantees a chain split and, at best, a minority chain for Olympia, which why I said "Game over for a Olympia as a majority chain" in the last call. You (and here I mean the Olympia authors collectively) could have said "Hey guys, Olympia might be the next hard fork, let's talk about it". Instead, you published articles claiming it was set in stone. You could have said "Miners might support Olympia, but we haven't checked yet", but instead a dangerous pretense that miners were going to support Olmypia was confected. You wouldn't need to make these exaggerated claims if you thought Olympia would be approved naturally. You wouldn't need to create a new Discord if the community was on your side. You wouldn't need to admonish treasured protocol developers in public if you were confident technically. But you chose to publicly push a narrative that damaged the reputation of the network, a narrative that will have to be walked back somehow, in lieu of actual consensus gathering, all to push through a contentious proposal that, coincidentally, you'd personally benefit from through your connection with the ETC DAO LLC. This, to me at least, is unacceptable, and that's why I'm fighting it. Please understand that I will be fighting any proposal that undermines the principles of ETC until the bitter end, and have an infinite spring of motivation to do so. Do not sideline my efforts in contributing to this project that I care so deeply about. Peace. |
|
Documentation of IstoraMandiri's recent permission removals of other contributors (timeline + mod log): Keeping this thread focused on ETC's client status and core development. Next checkpoint: June. |
Olympia Upgrade — June 2026 CheckpointMulti-client stability continued through June 2026 LTS codebases. All four Ethereum Classic clients are stable, peered, and advertising Olympia as next hardfork on the wire — with Nethermind joining this month via an ETC overlay.
What changed since May
Working Demo infrastructure — live on Mordor testnet
Institutional Coordinating Organizations
Post-Olympia roadmapETC's core software returns to head-of-branch development following the 2024 maintenance period. Alongside full-stack client work, the post-Olympia EL plugin roadmap covers upstream ETC compatibility layers for Go-Ethereum, Nethermind, Erigon, Besu, and Reth — with June's Nethermind overlay an early proof point. What's nextContinued client hardening and infrastructure modernization. Continued futarchy (ECIP-1117) development. Mordor testnet migration to a post-Olympia environment in preparation. On track for ETC mainnet activation before 2027. Full details: https://ethereumclassic.com/olympia |
|
I'm still trying to get my head around the Olympia proposal, but the ECIPs and contracts haven't been updated in line with the comments from its authors in this thread. It would be great if the proposals could be updated, and the contracts clearly linked, as the proposal evolves. From what I can tell, @chris-mercer initially intended to ship only 1112 in a minimal Olympia hard fork in 2026, and to "turn on" governance at some later point: https://github.com/orgs/ethereumclassic/discussions/530#discussioncomment-13758749
This framing also appears in the criticism-response table:
This is the core of my confusion, because it appears to misunderstand how CREATE2 works. The claim is that the treasury ships first and governance is audited and activated later. But that ordering is impossible here. The executor's address is baked into the treasury at deploy time, and a CREATE2 address is derived directly from the executor's own code. So you cannot deploy 1112 at all until the final executor code exists, which means the audit has to be finished before 1112 ships, not after. Governance can't "activate later and independently" because the treasury literally cannot be deployed until the governance code is finalized and locked in. Later, in https://github.com/orgs/ethereumclassic/discussions/530#discussioncomment-16182469, he confirmed exactly this:
That describes a valid deployment, but it directly contradicts the "governance activates later" claim. The address can only be hardcoded if the final executor code already exists, which is the opposite of activating it later. The fact that no setter or transition ceremony is required is not elegance; it is the proof that nothing about governance is being decided later. There is no switch to flip because the destination is fixed the moment the treasury is deployed. The "later" refers only to the timing of a single deterministic deploy transaction that anyone can run. The code itself, and therefore the audit it depends on, must already be done before 1112 can go out at all. Also worth flagging: "no admin key required" describes the deployment, not the system. The governance modules the executor relies on (SanctionsOracle, OlympiaMemberNFT) currently do have full admin rights. So a trustless deploy is being used to imply a trustless system, and those are not the same thing. So the current treasury contract doesn't actually leave governance open. It bakes in the executor's address as a fixed, unchangeable value at deploy time, and because that address is derived from the governance code itself, fixing the address fixes the code. If the address is already set, the governance code is already set too. At that point, why even have two contracts deployed at different times? You might as well just deposit the funds into a single address that is the governance system. As far as I can tell there are only three options: A: The governance contract (1113) is deployed at the same time as the treasury contract (1112). In that case you don't need any address precomputation at all, because you can deploy the whole contract system in one go, far more safely, to a single reserved address. B: As Chris seems to indicate earlier, the governance system is deployed after the hard fork. But the way it's currently built, the executor's address is already baked into 1112 and can't change, and since that address comes from the governance code, the code is already locked in at 1112's deploy time. So "decided later" isn't really true. (And if you already know the address, you're back to A.) If 1113's code genuinely isn't known when 1112 is deployed, then you'd need some way to point the treasury at whatever the "activated later" governance contract turns out to be, not a fixed address baked in up front. At that point, whether 1113 lands via CREATE2 or a normal deployment is moot. If the 1113 code is truly unknown when 1112 ships, what address are you even baking in? C: The whole thing is deployed across two sequential hard forks (the second updating whatever was baked into 1112). In that case you can just reserve two addresses, or simply overwrite the treasury contract's code with the new governance contract. B and C are clearly bad ideas. You put the network into a borked limbo state while committing to a governance system that may never exist. B is worse, because you still need another governance mechanism to decide how the switch gets flipped. And the two-stage approach seems pointless regardless. There's no rush to collect zero fees until governance is ready, unless you're expecting a 5+ year delay in deploying governance, in which case, why bother now? So A is effectively what the current contracts already do: the governance design is fully committed at 1112's deployment, just deployed in a second transaction. And if that's the case, the precomputed CREATE2 address dance buys nothing over deploying it all at once. The executor's code is frozen by the address it's pinned to, so any bug or post-audit recommendation can't be fixed by deploying corrected code (the address would change and the treasury would point at a dead address). Fixing it would require a whole new hard fork to redeploy the treasury. So either I'm an idiot who can't understand the proposed mechanism, in which case please enlighten me, or something is fundamentally off in the current approach. The main ECIP doesn't seem to have been updated in a while, so it's not totally clear what the actual proposal is. I'm piecing it together from various threads in the Olympia discussion on GitHub. According to Chris, "governance and funding processes activate later as independent modules." But the current contracts don't do that. The treasury locks in the executor's address, which locks in the executor's code, and that is the opposite of an independent module decided later. If there were an upgrade switch or a settable executor, then "activate later" would be possible, but introducing that switch reintroduces an admin or controller, which is the centralization problem in the first place. As built, you might as well go with A: one committed system, no precomputation needed. On the "the treasury itself has no admin" point: that's fair, the current treasury contract is genuinely clean (immutable, no owner, no upgrade path). But if the treasury contract system is hard-linked into governance, then the treasury effectively is the governance system. Whether or not my understanding is correct, strategically, if I only cared about Olympia failing I should just keep quiet and watch it blow up, or wait for someone else to figure this out later. But that would be standing by while watching the network be seriously damaged, so here I am trying to engage in good faith and getting stonewalled in the GitHub comments. This isn't an opinion I'm debating for fun. It's something I'm either right or wrong about, and I'm more than happy to eat my hat if I've got something wrong technically. I've looked at the governance contracts and I don't think anyone believes this will be ready before 2027. For reference:
Is this a serious attempt? We're being asked to bake this into ETC, this year? The demo is still at v0.4. I hope there'll be a real audit, and this needs to come before 1112 is deployed. And as I've said the whole time, having admin backdoors into a protocol-layer treasury system is not going to fly and is not decentralized. The bootstrap problem is real, still unanswered, and always will be. Futarchy? Cool, but unproven. It needs battle-testing in legitimate economic scenarios, which are hard to bootstrap, and it probably needs far more liquid markets than ETC has any interest in. Whether it is A, B or C, what's the rush in announcing this fork before we even have a plausible governance contract? Why hold up all the other EIPs we want to bundle just so you can claim Olympia is the next fork? |
Olympia Upgrade — August 2026 CheckpointDevelopment continued through August across the full client stack, anchored by three milestones: Fukuii's modernization and multi-network refactoring maturing ETC's only native execution client, Olympia's EVM alignment target extending from Fusaka to Glamsterdam, and continued futarchy development.
What changed since June
Working demo infrastructure — live on Mordor testnet
Institutional Coordinating Organizations
Post-Olympia roadmapETC's core software remains at head-of-branch development. The post-Olympia EL plugin roadmap covers upstream ETC compatibility layers for Go-Ethereum, Nethermind, Erigon, Besu, and Reth — with the Nethermind overlay an early proof point, and Glamsterdam-level EVM alignment now part of that forward track. What's nextContinued client hardening and infrastructure modernization. Continued application-layer development. Mordor testnet migration to a post-Olympia environment in preparation. EVM alignment extending toward Glamsterdam, tracking upstream readiness — Olympia activation follows testnet validation and multi-client parity. |
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: June 2026 — Client Implementation Complete, Client Modernization Complete
Next: Client Hardening, 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.
April 2026 Update
Client implementation of ECIP-1111, ECIP-1112, and ECIP-1121 is complete across three execution clients — Fukuii (new ETC-native client), Core-Geth (maintenance mode, deprecated upstream), and Besu (reference client). Sequential rollout of the governance and funding contracts is live at olympiatreasury.org, olympiadao.org, and ethereumclassicdao.org. Mordor testnet activation is the current phase.
May 2026 Update
Multi-client stability achieved to May 2026 LTS codebases. All three Ethereum Classic clients are stable, peered, and advertising Olympia as next hardfork on the wire.
Since April: Fukuii now runs as a dual-network execution client with Engine API V1–V4 for post-Merge Ethereum. Original ETH/69+ (EIP-7642) chain weight resolution implemented for PoW peer ranking — no upstream equivalent exists. Besu's ETH/69+ TD logic for PoW networks identified and resolved. Critical security patches, performance hardening, and dependency modernization across the full client stack.
Spec-aligned phased rollout (demo v0.3):
Institutional Coordinating Organizations:
June 2026 Update
Multi-client stability continued across June 2026 LTS codebases. All four Ethereum Classic execution clients are stable, peered, and advertising Olympia as next hardfork on the wire — with Nethermind joining this month as a fourth independent codebase.
Since May: Nethermind v1.39.x added as a fourth peered client via an ETC overlay — a fourth independent codebase broadening client diversity. Fukuii advanced to v0.8.x with ETH/70 added for ETH/Sepolia and a Scala 3.9 LTS readiness sprint underway. Core-Geth v1.13.x resolves v1.12.x known issues and is the final core-geth series before sunsetting. Critical security patches, performance hardening, and dependency modernization continue across the full client stack.
Futarchy (ECIP-1117) — continued development on decision-market governance.
Post-Olympia EL plugin roadmap covers upstream ETC compatibility layers for Go-Ethereum, Nethermind, Erigon, Besu, and Reth.
On track for ETC mainnet activation before 2027. Full client details: ethereumclassic.com/build/clients
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.
All reactions