Olympia
The agenda for the call that would set Olympia's activation blocks: the draft ECIPs, client readiness, and the order the ECIPs set before a block is scheduled.
Olympia Core Devs Call: Agenda
When: TBD · Duration: 120 min max Where: Twitter/X Space, @ETC_Network (recorded)
Olympia is a proposal: its ECIPs are drafts, and its activation blocks are TBD. ECIP-1121 says those blocks would be decided at the Olympia Core Devs Call, and ECIP-1111 is the only document that would record them.
The Olympia ECIPs
At the activation block:
- ECIP-1111: Base Fee Market and Redirection: Would activate EIP-1559 and EIP-3198, crediting each transaction's base fee to a permanent address held in chain configuration rather than destroying it, as Ethereum does. Block rewards and priority-fee tips would be unchanged.
- ECIP-1121: EVM Alignment Specification (Olympia Hardfork): Classifies every execution-layer EIP of Dencun, Pectra, Fusaka and Glamsterdam: adopted at the Olympia block, adopted with a modification, already in force, blocked by a dependency, deferred or excluded.
To be deployed and published before the activation block:
- ECIP-1112: Sovereignty Vault: The permanent address where base-fee revenue would accumulate: an unmodified OpenZeppelin transparent proxy, deployed and open to inspection before the fork commits to it. Its logic could be repaired while the address stays the same.
- ECIP-1113: Olympia DAO Governance and Treasury: Olympia DAO: a Governor built from unmodified OpenZeppelin modules, the Timelock behind the Treasury proxy, and CoreNFT, a soulbound token that gives each member one vote they cannot delegate. It would be the only way to spend the balance at the Sovereignty Vault address.
Processes that would run on the governance contracts, changing no consensus rule:
- ECIP-1114: Olympia Funding Proposal Process: Defines a funding proposal: an ordinary Governor proposal that spends from the Treasury, filed under one of five categories and written to a description convention, with no contract of its own.
- ECIP-1115: Olympia Miner Security Budget Smoothing: Funding proposals that would pay block producers from the base-fee revenue their blocks generated, spread over a window of blocks. No base fee is redirected, and nothing is owed until a proposal passes.
- ECIP-1117: Olympia Ecosystem Growth DAOs: Bodies open to anyone that would grow what is built on Ethereum Classic, each funded one season at a time by a funding proposal. Client development, network security and critical infrastructure stay with Olympia DAO.
- ECIP-1118: Milestone-Structured Funding for Olympia Funding Proposals: A funding commitment paid in tranches, each tranche its own funding proposal, decided on the work delivered for it. Nothing is held in reserve between tranches.
- ECIP-1119: Sanctions Screening for Olympia Funding Proposals: The interface members vote through would screen a proposal's recipients against a sanctions list and show the result, with no way to vote for a designated address. No contract, oracle or role is involved.
A separate hard fork after Olympia, to be scheduled on its own:
- ECIP-1116: Consensus-Layer: Sustainable Network Security Budget via Base Fee Miner Distribution: Would pay block producers a smoothed share of base-fee revenue at the consensus layer. It is a separate hard fork after Olympia, scheduled only after a smoothing curve has been demonstrated through ECIP-1115.
ECIP-1121 classifies every execution-layer EIP of Dencun, Pectra, Fusaka and Glamsterdam, and adopts part of Glamsterdam's set. Every EIP by its disposition.
The Order the ECIPs Set
- The governance contracts would be deployed on Ethereum Classic before the fork, in dependency order, with no address predicted or reserved (ECIP-1113 §"Deployment and Activation").
- Their security review and multi-client validation on Mordor would be complete before the activation block is scheduled, rehearsed while the Treasury holds nothing (ECIP-1113 §"Audit and Testnet Rollout").
- The Treasury's address would be published, already in its final configuration, before the activation block is scheduled (ECIP-1112 §"Deployment and Publication").
- Cross-client equivalence would be demonstrated on Mordor before a mainnet block is scheduled (ECIP-1111 §"Test Cases"), and both blocks would be recorded in ECIP-1111 §Implementation.
Network Security Context
- Core-Geth went 21 months without a maintenance release, from June 2024 to the emergency releases of March 2026.
- Every v1.12.x release still carries at least one disclosed CVE unpatched; Core-Geth v1.13.0 fixed every client CVE the audits found.
- The previous repository had no active maintainer: security disclosures went unanswered, and core development had no redundancy.
- Core-Geth is released and maintained in the ethereumclassic GitHub organization.
The full Core-Geth security audit is published. A node on any v1.12.x release should move to the Core-Geth v1.13 line now, by the steps on coregeth.com, with the migration guide for the detail.
Client Readiness
No released client implements Olympia. A client's Olympia readiness is what its maintainers publish, listed at client readiness as they publish it.
| Client | Language | Role |
|---|---|---|
| Core-Geth | Go | Recommended: an Ethereum Classic execution client and public-good Go reference client, a go-ethereum downstream released and maintained in the ethereumclassic GitHub organization. Run its v1.13 line |
| Fukuii | Scala | Alternative: an execution client in Scala 3 that continues IOHK's Mantis client, maintained by Chippr Robotics LLC. Its maintainers mark it alpha |
ETC plugins, a planned framework, would add Ethereum Classic support to clients other projects maintain. A plugin is not a client implementation: the codebase it extends, and the decisions about it, stay with the project that maintains it. Plugins are therefore not part of client readiness.
Development Sustainability
- Who funds the work today. Ethereum Classic's core developers and community contributors do the work. Ethereum Classic DAO maintains and funds the public goods kept in the ethereumclassic GitHub organization as their funder of last resort, and it does not control or lead Ethereum Classic.
- The ETC Cooperative. A US 501(c)(3) non-profit that funded Ethereum Classic's public goods from 2017. It entered maintenance mode at the end of 2024, and its board has communicated that it will dissolve.
- The legal wrapper. ECIP-1114 names Ethereum Classic DAO LLC as the legal wrapper Olympia DAO would use for the off-chain acts an on-chain organization cannot perform, such as signing an audit engagement Olympia DAO has voted to fund. Ethereum Classic DAO would be downstream of Olympia DAO in authority, and it holds no role in Olympia until Olympia DAO is operating.
- On-chain contributions. The Treasury would accept any asset at one address, so there would be one contribution address for every asset class (ECIP-1113).
Regulatory Context
- CLARITY Act. ETC is positioned for classification as a digital commodity under the CLARITY Act. The Senate Banking Committee cleared the bill, 15 to 9, in May 2026, and a Senate cloture vote failed, 49 to 50, on September 15, 2026.
- GENIUS Act. The GENIUS Act sets a federal framework for payment stablecoins, and ETC is a Proof-of-Work EVM platform for them.
- Institutional access. The Grayscale Ethereum Classic Trust (ETCG), a trust product, provides regulated securities exposure to ETC.
Activation
| Network | Block | Target |
|---|---|---|
| Mordor Testnet | TBD | TBD |
| ETC Mainnet | TBD | Targeted for 2027 |
Agenda
- Network security context and the Core-Geth v1.13 line
- The Olympia ECIPs: ECIP-1111, ECIP-1112, ECIP-1113 and ECIP-1121
- Client readiness, as each client's maintainers publish it
- The order the ECIPs set: deployment, review and the Mordor rehearsal
- Mordor testnet activation block
- ETC mainnet activation block
- Development sustainability and the legal wrapper
- Regulatory context
- Open discussion
Related
- Olympia, the proposal across every ECIP
- Olympia for node operators
- Core-Geth security audit: the June 2024 to March 2026 gap, fixed in v1.13.0
Call Results
To be updated after the call.