The execution-layer alignment
Two of the specifications that activate at the first hard fork change nothing about money. One brings the machine that runs contracts back into line with Ethereum’s. The other writes down three network settings that have been held together by habit. Both are unglamorous, and both are the reason the rest of Olympia has something solid to sit on.
Ethereum Classic and Ethereum run the same virtual machine. Over a decade of Ethereum upgrades, Ethereum Classic took some of the changes and deliberately left others, and the distance between the two accumulated. That distance is not abstract. It is why a developer’s tools sometimes needed Ethereum Classic-specific handling, and why a wallet or an exchange had to decide whether supporting this chain was worth the extra work.
This specification closes that distance in a single upgrade, and what it writes down is an inventory rather than a redesign. It invents nothing. It lists the changes Ethereum has already made that Ethereum Classic can take without becoming a different kind of network, and it says in the same document which ones it is leaving out and why.
16
changes to the execution layer
Grouped by what they do, in four sets: gas and state access, evm safety, cryptographic precompiles and execution context. They arrive together at the activation block.
2
peer-to-peer protocol versions
These are how nodes talk to each other rather than how contracts run, and they do not need the fork at all. Two nodes agree on a version when they connect, so a network can move to a newer one without every participant changing at the same moment.
Why that set, and not another
A list of changes does not explain itself. The specification states three tests, and every entry passes all three of them. They are also what makes the exclusions further down readable as decisions rather than as gaps in the coverage.
- 01
Not already done
Ethereum Classic did not activate it at Spiral in 2024 or at Mystique in 2022. Anything those upgrades already delivered is not on the list, because it is already running.
- 02
Execution layer only
It changes how contracts run, what an operation costs, or what a node exposes over its interfaces. Anything that changes the rules a block is judged by belongs in a different specification, and one candidate is held out on exactly that ground.
- 03
Works on Proof-of-Work
It carries no dependency on validators, on a beacon chain, or on the data-availability machinery Ethereum built for its Layer 2s. Ethereum Classic is and stays a Proof-of-Work chain, so anything resting on those foundations cannot be adopted here whatever its merits.
It changes nothing economic, and that is deliberate. This specification defines no governance behavior and no monetary behavior, and it replaces no other specification in the set. It is the execution-layer bookend: the part of the upgrade a reader can understand without knowing anything about treasuries or voting.
It does depend on the fee market activating alongside it. A client that shipped one without the other would start applying new behavior at a block where the rest of the network was not, and stop agreeing with it. The specification names that outcome as a client bug rather than a flaw in the design, which is the same reason every client publishes its release well ahead of the block.
Every change, one by one, and which Ethereum upgrade it came from
Three settings every client must enforce
The second specification is shorter and, for anyone running a node, more immediately felt. It sets three values that every Olympia client is required to enforce identically.
All three have one thing in common, and it is the point of the document. Each writes down something the network was already relying on and had never actually stated. Miners held a price floor by convention. The size of a block was kept in range by people agreeing to keep it there. The defense against chain reorganizations was switched on because operators chose to run it, and later switched off.
Informal arrangements of that kind work until they do not, and each of these three has already been tested. The specification’s own word for what it is doing is codifying: turning practice that everyone assumed into something a client enforces.
A floor under the miner's tip
MIN_MINER_TIP = 1 gwei
- Until now
- Miners set their own price floors by convention. The limit a client actually enforces has been one wei since it was inherited from Ethereum's own software, a billionth of what people pay in practice, and any operator can change it.
- From Olympia
- A conformant client enforces the same floor and checks it twice: when a transaction arrives, and again when it selects transactions for a block.
A gas target the network sets
8,000,000 to 60,000,000
- Until now
- The 8,000,000 target was social convention rather than a rule. Nothing prevented an operator from deviating, and Ethereum Classic has watched that turn into an incident.
- From Olympia
- The target for each era becomes a value the network sets, which an operator's own gas-limit flag cannot override. It rises to 60,000,000 at Olympia.
MESS comes back on
ECIP-1100 re-activated
- Until now
- Chain-reorganization resistance was active from block 11,380,000, then switched off at block 19,250,000. That block is Spiral, so the deactivation was a scheduled part of that upgrade rather than a response to anything.
- From Olympia
- It is restored at the Olympia activation block, which closes a window that runs precisely from Spiral to Olympia.
“Configuration” here means the opposite of what it usually means
None of the three is a rule that blocks are judged by. They live in the configuration a client ships with, which sounds weaker than a rule and in one specific way is: a node that ignores them still follows the same chain as everyone else, so nobody can be forced off the network for non-conformance.
What it does not mean is that each operator picks a value. That is precisely the defect all three exist to close. Configuration here means a value every client ships with and no operator flag can override. The gain from keeping it out of the block rules is that the network can revise a number by releasing new client software rather than by scheduling another hard fork.
That distinction has one consequence worth stating plainly. Two of the floors under a transaction’s price come from different places. The one on the protocol’s share is a consensus rule and holds against everybody. The one on the miner’s share is configuration, so a block producer that declines to enforce it can still include cheaper transactions, and every other node has to accept and store them.
So the combined two gwei is what a conformant network charges rather than a promise the protocol makes, and one gwei is the figure that holds regardless. The specification says so in its own security section rather than leaving a reader to discover it, which is also why it asks every client to adopt the value instead of treating it as a local preference.
The floors side by side, and what a transaction actually costs
What is deliberately not included
Most specifications list what they contain. This one also lists what it does not, and gives a reason for each. The stated principle is worth quoting because it is unusual: a proposal that appears in no section is indistinguishable from one that was considered and declined, and that ambiguity is itself treated as a defect.
So the omissions below are content. They also do not all mean the same thing, and collapsing them into “not supported” is the most common way this document gets misread.
- Excluded16Proof-of-Stake
- Not applicable rather than postponed. Beacon-chain dependencies, the separation of block proposers from block builders, and the machinery for validators joining and leaving all assume a network Ethereum Classic is not and does not intend to become. There is no version of this list that gets adopted later.
- Deferred9Blob data availability
- Ethereum added blobs to carry data for the networks settling on top of it. Ethereum Classic is a Layer 1 execution chain and does not have that problem, so it takes the execution-layer work without inheriting the scaffolding underneath it. The specification is careful that deferral does not imply rejection.
- Excluded2Fee-market governance
- The only exclusion that is a filing decision rather than a judgment. The fee market and the opcode that exposes the base fee to a contract both ship at this same fork; they are simply specified in ECIP-1111 instead, because the question of where the money goes is the subject of its own set of documents.
- Blocked6Waiting on a dependency
- Tracked rather than rejected, and each meets this specification's own tests. Five of them resolve to one proposal that adds a field to the block header, which makes it a change to the rules a block is judged by and so needs a specification of its own. The sixth waits on a proposal that is itself in the Proof-of-Stake list above.
The third of those is the one to read twice. The base fee is excluded from this specification, and the base fee is the whole reason Olympia exists. Nothing is missing. It is specified next door, in the document that also decides where the money goes, and it activates at this same block. A reader who takes the exclusion at face value concludes the opposite of what happens.
The same applies to the opcode that lets a contract read the current base fee. It ships, it is simply not this document’s to define.
A further 7 proposals are listed without being decided. They pass all three tests and none of them is adopted or rejected here; classifying them is a decision for the developer call that sets the activation block. Listing them anyway is the same principle as the exclusions: an undecided proposal that appears nowhere reads as one nobody thought about.
Glamsterdam is the target, not a finished job. Ethereum’s next upgrade is still being assembled, so nobody can align to a set that is not settled yet. What this specification does is take the 2 pieces of it that are ready and stable, track the rest, and say which is which. Reading that as full parity overstates it in one direction, and reading it as Ethereum Classic sitting the upgrade out overstates it in the other.
Fusaka is a different case and gets confused with it. That cycle is delivered and settled on Ethereum, and its execution-layer work is in this set wherever it does not depend on blobs or on Proof-of-Stake. It is not something Ethereum Classic is still waiting on.
Where this sits in the five stages
Both specifications on this page are stage one, and stage one is a hard fork: every node has to be running a release that knows about it before the block arrives. Of the five stages, only the first and the last are forks. The three in between deploy contracts and run governance on a chain whose rules are already settled.
The roadmap is a schedule for rolling things out, not an order for building them. That sentence is the specification’s own, and flattening the two is the most common way the five stages get misread.
Nothing is deployed at the fork
Every contract the first fork commits to is already on-chain, already audited and already readable before that block: the membership token, the contract that holds the money, the one that counts votes, and the permanent contract consensus credits. The fork is the moment the protocol begins paying a published address, which is not the same act as creating it. The audit window therefore sits in front of the fork rather than in a gap after it.
Two pieces are deliberately outside that set, and the reason is worth following. The sanctions oracle and the proposal registry each attach later through a setter that only governance can call, and neither is built into anything else, so both may be deployed and audited on either side of the fork. Until the oracle is attached the spending gate refuses to open at all, so revenue accumulates and cannot be spent. Failing shut is what makes deferring that audit safe.
After the fork the stages stop being about consensus. The second is governance becoming able to spend, the third deploys the market contracts, and the fourth switches on a distribution experiment using funds the treasury already holds. Only the fifth is a second hard fork, and it cannot be scheduled until the fourth has produced the evidence it exists to harden.
Both specifications leave the activation block to open coordination among the people who have to act on it: client developers, node operators, miners, exchanges and infrastructure providers. Mordor activates first, and the mainnet block follows a clean run there and a stakeholder readiness check.