Skip to main content

Olympia

The Olympia Upgrade

Proposed · Draft ECIPs · Activation block TBD

Olympia is a proposed upgrade to Ethereum Classic, targeted for mainnet activation in 2027. Its ECIPs are drafts, and the ECIPs repository is the authority on what it specifies.

  • EVM alignment (ECIP-1121): advances the execution layer through Dencun, Pectra and Fusaka, and carries that work into Glamsterdam.
  • A base fee market (ECIP-1111): EIP-1559 and EIP-3198, with the base fee, which Ethereum destroys, credited instead to a permanent address. Block rewards and priority-fee tips are unaffected.
  • A treasury and its governance (ECIP-1112, ECIP-1113): the Sovereignty Vault address, and Olympia DAO, the only route by which the balance there could be spent.

What Olympia Proposes

Olympia is a set of draft ECIPs. Some change consensus at the activation block, some specify the Treasury and the governance deployed before it, one describes a later hard fork, and the rest are processes that run on those contracts. Each is listed by its own title.

ECIP-1111At the activation block

Base Fee Market and Redirection

Would activate EIP-1559 and EIP-3198. Where Ethereum destroys the base fee, Ethereum Classic would credit it, transaction by transaction, to a permanent address held in chain configuration. Block rewards and priority-fee tips would be unaffected.

Read ECIP-1111
ECIP-1112Before the fork

Sovereignty Vault

The permanent address at which base-fee revenue would accumulate: a stock OpenZeppelin transparent proxy, deployed and inspectable before the fork commits to it, whose logic could be repaired while the address stands.

Read ECIP-1112
ECIP-1113Before the fork

Olympia DAO Governance and Treasury

Olympia DAO: a Governor built from stock OpenZeppelin modules, the Timelock behind the Treasury proxy, and CoreNFT, a soulbound token carrying one non-delegable vote per member. It would be the only route by which the balance at the Sovereignty Vault address could be spent.

Read ECIP-1113
ECIP-1114Process

Olympia Funding Proposal Process

A funding proposal would be an ordinary Governor proposal that spends from the Treasury, with five categories and a description convention, and no contract of its own.

Read ECIP-1114
ECIP-1115Process

Olympia Miner Security Budget Smoothing

Funding proposals that would pay block producers from the base-fee revenue their blocks generated, spread across a window. No base fee is redirected, and nothing is owed until a proposal passes.

Read ECIP-1115
ECIP-1116A later hard fork

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 once ECIP-1115 has demonstrated a curve.

Read ECIP-1116
ECIP-1117Process

Olympia Ecosystem Growth DAOs

Bodies scoped to growing what is built on Ethereum Classic and open to anyone, each funded one season at a time by a funding proposal. Client development, network security and critical infrastructure stay with Olympia DAO.

Read ECIP-1117
ECIP-1118Process

Milestone-Structured Funding for Olympia Funding Proposals

A funding commitment paid in tranches, each its own funding proposal and decided on the work behind it. Nothing is held between tranches.

Read ECIP-1118
ECIP-1119Process

Sanctions Screening for Olympia Funding Proposals

The interface a member votes through would screen a proposal's recipient against a sanctions list and show the result, with no way to vote in favor of a designated address. No contract, oracle or role is involved.

Read ECIP-1119
ECIP-1121At the activation block

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.

Read ECIP-1121
Proposed · Draft ECIPs · Activation block TBD

Activation

Olympia is a proposal, targeted for mainnet activation in 2027. Its activation blocks are TBD: ECIP-1121 says they are decided at the Olympia Core Devs Call, and ECIP-1111 is the only document that records them.

* The countdown runs to , a placeholder target rather than an activation date, until the activation block is set.

The order the ECIPs set

  1. 01

    The governance contracts deploy on Ethereum Classic as it runs today, in dependency order, with no address predicted or reserved: the Treasury's Timelock behind its proxy, then CoreNFT, then the Governor, which alone is granted the Timelock's roles to propose, execute and cancel.

    ECIP-1113 §"Deployment and Activation"
  2. 02

    Their security review and multi-client validation on the Mordor testnet complete before the activation block is scheduled, with the whole process rehearsed while the Treasury holds nothing.

    ECIP-1113 §"Audit and Testnet Rollout"
  3. 03

    The Treasury's address is published with the network it is on, together with three things, each reproducible from chain state: the verified source of every contract at and beneath it, where upgrade authority rests, and its full role table.

    ECIP-1112 §"Deployment and Publication"
  4. 04

    The activation blocks for Mordor and for mainnet are set through open coordination, and ECIP-1111 is the only document that records them. Both read TBD.

    ECIP-1111 §Implementation
  5. 05

    At the activation block, EIP-1559 begins with the base fee credited to the Treasury's address, and the core EIPs ECIP-1121 adopts take effect.

    ECIP-1121 §Activation

ECIP-1116, which would pay block producers from base-fee revenue at the consensus layer, is a separate hard fork after Olympia and is scheduled on its own.

ECIP-1121

EVM Alignment Into Glamsterdam

ECIP-1121 advances Ethereum Classic’s execution layer through Dencun, Pectra and Fusaka, and carries that work into Glamsterdam. It gives every execution-layer EIP of those four upgrades one disposition. Glamsterdam is included without being adopted whole: ECIP-1121 adopts part of its set, holds 4 of its EIPs on a dependency, and defers or excludes those tied to blob data availability or Proof-of-Stake.

Ethereum Classic is at Shanghai until the activation block, so the instructions these EIPs add, such as TLOAD, TSTORE and MCOPY, are not valid on it before then (ECIP-1121 §“Instruction Set Before and After Activation”). Modern EVM tooling assumes EIP-1559, and ECIP-1111 would remove the Ethereum Classic-specific path that integrators maintain for it today.

Adopted at the Olympia block

20 EIPs

Core EIPs: each changes what blocks are valid, and takes effect only at the activation block.

Dencun

Pectra

Fusaka

Glamsterdam

Adopted with a modification

5 EIPs

Each is adopted at the same block, with a change Ethereum Classic's Proof-of-Work consensus requires. ECIP-1111 states it for EIP-1559 and EIP-3198, and another ECIP in the suite for the block access list EIPs.

Adopted without a block

3 EIPs

Networking and interface EIPs. A client may adopt them before or after the activation block, through capability negotiation or as an API.

Blocked by a dependency

4 EIPs

Tracked, not rejected: each depends on an EIP that is out of scope, and adopting it waits on resolving that dependency rather than on a judgment about the EIP.

  • EIP-2780 Resource-based intrinsic transaction gas
  • EIP-8037 State creation gas cost increase
  • EIP-8038 State-access gas cost update
  • EIP-7708 ETH transfers emit a log
Deferred9 EIPs

Blob data availability. Ethereum Classic does not implement blobs, and deferral does not imply rejection.

  • EIP-4844 Shard Blob Transactions
  • EIP-7516 BLOBBASEFEE instruction
  • EIP-7691 Blob throughput increase
  • EIP-7840 Add blob schedule to EL config files
  • EIP-7594 PeerDAS: Peer Data Availability Sampling
  • EIP-7892 Blob Parameter Only Hardforks
  • EIP-7918 Blob base fee bounded by execution cost
  • EIP-8070 eth/72: Sparse Blobpool
  • EIP-8136 Cell-Level Deltas for Data Column Broadcast
Excluded20 EIPs

Proof-of-Stake EIPs, which do not apply to a Proof-of-Work chain, and EIPs with no client behavior to adopt.

  • EIP-4895 Beacon chain push withdrawals as operations
  • EIP-4788 Beacon block root in the EVM
  • EIP-7044 Perpetually Valid Signed Voluntary Exits
  • EIP-7045 Increase max attestation inclusion slot
  • EIP-7514 Add Max Epoch Churn Limit
  • EIP-6110 Supply validator deposits on chain
  • EIP-7002 Execution layer triggerable withdrawals
  • EIP-7251 Increase the MAX_EFFECTIVE_BALANCE
  • EIP-7549 Move committee index outside Attestation
  • EIP-7685 General purpose execution layer requests
  • EIP-7917 Deterministic proposer lookahead
  • EIP-7688 Forward compatible consensus data structures
  • EIP-7732 Enshrined Proposer-Builder Separation
  • EIP-7843 SLOTNUM opcode
  • EIP-8045 Exclude slashed validators from proposing
  • EIP-8061 Increase exit and consolidation churn
  • EIP-8282 Builder Execution Requests
  • EIP-7935 Set default gas limit to 60M
  • EIP-7904 Compute Gas Cost Analysis
  • EIP-8261 Gas Limit Schedule
In force before Olympia21 EIPs

EIPs the adopted ones depend on that Ethereum Classic already runs, from earlier upgrades and the devp2p lineage.

  • EIP-161 State trie clearing
  • EIP-170 Contract code size limit
  • EIP-198 Big integer modular exponentiation
  • EIP-1014 Skinny CREATE2
  • EIP-1052 EXTCODEHASH opcode
  • EIP-2200 Structured definitions for net gas metering
  • EIP-2565 ModExp gas cost
  • EIP-2718 Typed transaction envelope
  • EIP-2929 Gas cost increases for state access opcodes
  • EIP-2930 Optional access lists
  • EIP-3529 Reduction in refunds
  • EIP-3541 Reject new contract code starting with the 0xEF byte
  • EIP-3860 Limit and meter initcode
  • EIP-2681 Limit account nonce to 2^64-1
  • EIP-3607 Reject transactions from senders with deployed code
  • EIP-2124 Fork identifier for chain compatibility checks
  • EIP-2364 eth/64: forkid-extended protocol handshake
  • EIP-2464 eth/65: transaction announcements and retrievals
  • EIP-2481 eth/66: request identifier
  • EIP-4938 eth/67: removal of GetNodeData
  • EIP-5793 eth/68: add tx type to tx announcement
Read ECIP-1121 →

Governance, as Proposed

Under Olympia the Treasury’s balance would leave only through Olympia DAO, by funding proposals that are voted, queued and executed in public. As ECIP-1113 specifies them, the contracts that can hold or move funds are stock OpenZeppelin, so what the network reviews is a configuration rather than new code.

ECIP-1114 · ECIP-1119

A funding proposal

An ordinary Governor proposal that spends from the Treasury. It declares one of five categories: Core Development, Critical Infrastructure, Network Security, Ecosystem Growth, or Other. There is no registry and no submission contract, and the category describes a proposal without gating it.

  1. 01

    Submit

    The author calls the Governor from their own address, subject to the proposal threshold.

  2. 02

    Vote

    CoreNFT members vote For, Against or Abstain. The interface they vote through screens the recipient against a sanctions list.

  3. 03

    Queue

    A passed proposal is scheduled in the Timelock, in public, for its delay.

  4. 04

    Execute

    After the delay it executes, paying from the Treasury's own balance.

ECIP-1113

Olympia DAO

Three contracts, each unmodified OpenZeppelin except CoreNFT, which holds no funds: the Treasury, a transparent proxy over a TimelockController at the Sovereignty Vault address; a Governor built from stock modules, which is the Timelock's sole executor; and CoreNFT, a soulbound membership token carrying one non-delegable vote per member. After a published bootstrap list, members are admitted one governed mint at a time, with no minting committee and no account that can admit anyone alone.

ECIP-1117 · ECIP-1118

Ecosystem Growth DAOs and milestones

An Ecosystem Growth DAO is open to anyone and funded one season at a time by a funding proposal. Olympia DAO decides whether to seed a season, how much, and within what theme. The body's published model then decides which of the destinations the seeding proposal named receive the funds; that model may be a conditional market, an allocation strategy, a vote or a process that is not a contract. Client development, network security and critical infrastructure stay with Olympia DAO. A milestone program pays in tranches, each its own funding proposal, decided on the work behind it.

ECIP-1000

Protocol change stays with the ECIP process

Neither Olympia DAO nor an Ecosystem Growth DAO replaces it. A change to Ethereum Classic remains an ECIP, and it takes effect when client teams release it and node operators, miners and exchanges run it. Funding a piece of work does not adopt a specification.

ECIP-1114 names Ethereum Classic DAO LLC, Wyoming Filing ID 2025-001671865, as the legal wrapper it contemplates for Olympia DAO. An on-chain organization has no legal personality: it cannot sign a contract, engage an auditor or pay a contractor in fiat. A registered entity supplies that personality for the off-chain acts, without acquiring authority over the on-chain organization.

Once Olympia DAO is operating, Ethereum Classic DAO would carry out the off-chain obligations a passed proposal has fixed. If Olympia DAO votes to fund a security audit, for example, Ethereum Classic DAO signs the engagement with the auditing firm; the proposal, not Ethereum Classic DAO, set the auditor, the scope and the amount. In ECIP-1114’s words, Ethereum Classic DAO is downstream of Olympia DAO in authority: Olympia DAO is not its subsidiary, and Ethereum Classic DAO holds no position in the ECIP process, which is ECIP-1000’s.

No off-chain entity can unilaterally approve or veto a governance action, Ethereum Classic DAO holds no on-chain role, and the Treasury’s balance moves only by a passed, timelocked proposal. Donations Ethereum Classic DAO receives off-chain are its own and are accounted for separately. Until Olympia DAO is operating, Ethereum Classic DAO holds no role in anything ECIP-1114 specifies.

Client Readiness

Olympia is in development and targeted for mainnet activation in 2027, so neither client’s releases are ready for it. Its activation block is TBD, and a client’s Olympia release is the one that sets it. Each client’s maintainers publish its readiness for Olympia. To choose and run a client today, see the clients page.

Core-Geth

Recommended

The recommended client: run its v1.13 line. Its releases, and its readiness for Olympia, are published from ethereumclassic/core-geth.

Fukuii

AlternativeAlpha

An alternative to try beside Core-Geth. Chippr Robotics LLC maintains it and marks it alpha: run its latest release. Its releases, and its readiness for Olympia, are published from chippr-robotics/fukuii.

Frequently Asked Questions

Common questions about the Olympia proposal, its Treasury, its governance, and node operations.

No. Olympia is a proposal in development: its ECIPs are drafts, its activation block is TBD, and neither client's releases are ready for it. It is targeted for mainnet activation in 2027.

It is targeted for mainnet activation in 2027. The activation blocks for Mordor and mainnet are decided at the Olympia Core Devs Call and recorded in ECIP-1111, and both read TBD. Before an activation block is scheduled, the governance contracts are deployed, reviewed and rehearsed on Mordor, and the Treasury's address is published.

ECIP-1111 activates EIP-1559 and credits each transaction's base fee to the Sovereignty Vault address, inside that transaction's own state transition, at the point where Ethereum destroys it. The credit runs no contract code. Ethereum Classic has no base fee today, so nothing is taken from what miners earn now.

No. ECIP-1111 leaves block rewards and priority-fee tips unaffected, and the base fee it introduces goes to the Treasury rather than to miners. Paying miners from base-fee revenue is the subject of ECIP-1115, through ordinary funding proposals, and of ECIP-1116, a separate hard fork after Olympia.

Only Olympia DAO, by a funding proposal that passes a vote of CoreNFT members, is queued in the Timelock and executes after its delay. The Governor is the Timelock's sole executor, and there is no admin key, multisig or committee. The Treasury's address is permanent, and the logic behind it can be repaired by a proposal.

No. Protocol change remains with the ECIP process, ECIP-1000. A funding proposal can pay for work on Ethereum Classic without conferring any authority over its specification, and an upgrade takes effect only when client teams release it and the network runs it.

ECIP-1114 names Ethereum Classic DAO LLC as the legal wrapper it contemplates for Olympia DAO, for the off-chain acts an on-chain organization cannot perform, without acquiring authority over it. Once Olympia DAO is operating, Ethereum Classic DAO would carry out the off-chain obligations a passed proposal has fixed, such as signing the engagement for a security audit Olympia DAO voted to fund. Ethereum Classic DAO is downstream of Olympia DAO in authority, holds no on-chain role and no position in the ECIP process, and holds no role in anything ECIP-1114 specifies until Olympia DAO is operating.

No. ECIP-1121 includes Glamsterdam and adopts part of its set. Some of its EIPs are blocked on a dependency that is out of scope, and those tied to Proof-of-Stake or blob data availability are excluded or deferred. The EIP lists on this page give each one.

Core-Geth, the recommended client: run its v1.13 line. Fukuii, which its maintainers mark alpha, is an alternative to try beside it: run its latest release. Neither client's releases are ready for Olympia, which is in development and targeted for mainnet activation in 2027.

Once the activation blocks are set and client releases implement them, a node that has not moved to such a release by the activation block stops following the chain at that block. Operators move by the steps their client's maintainers publish.