The Merge — Swapping the Engine Live

The last five pages built Proof of Stake from the ground up: validators staking 32 ETH, a clock of slots and epochs, attestations feeding LMD-GHOST, and Casper FFG finalizing checkpoints. Every one of those mechanisms describes how a set of validators agrees on the order of blocks. But there is a fact we’ve quietly skipped: for the first seven years of its life, Ethereum did not use any of it. It mined. It burned electricity like Bitcoin.

This page is the hinge. It answers the question that sounds impossible when you first hear it: how do you change the consensus engine of a running network that already holds tens of billions of dollars of value — without stopping it, forking it, or asking anyone to move their coins? The answer, delivered on 15 September 2022 in an event called The Merge, is the single cleanest demonstration of the throughline this whole book turns on: consensus decides order; execution decides state; and because those two jobs are separable, you can replace one while the other keeps running untouched.

Two chains that ran side by side for 21 months

The most important thing to understand about The Merge is that Proof of Stake did not appear on 15 September 2022. It had already been running, in the open, for nearly two years.

On 1 December 2020, Ethereum launched the Beacon Chain: a brand-new, separate Proof-of-Stake chain whose only job was to run validator consensus. It had no accounts you could send money to, no smart contracts, no EVM. It did nothing but let validators stake, get shuffled into committees, propose empty-of-real-transactions blocks, and attest to each other — exercising every mechanism the previous pages described, with real ETH staked and real slashing risk, on a live network.

Meanwhile, the Ethereum everyone actually used — the one with your balance, your tokens, your contracts — kept mining under Proof of Work, completely unaware the Beacon Chain existed.

   Dec 2020 ───────────────── 21 months ───────────────── Sep 2022

   Beacon Chain (PoS)   ●━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━●  consensus, ordering
     validators, slots, attestations, finality           │   (proving itself)
                                                          │
                                                          ▼  THE MERGE
   Mainnet (PoW)        ●━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━●━━━━━━━━━►  state, EVM,
     mining, blocks, accounts, EVM, your balance       stops         your balance
                                                       mining        (carries over)

Running the new consensus engine in parallel for ~21 months was the whole safety strategy. By the time The Merge arrived, the Beacon Chain wasn’t an experiment — it had a battle-tested validator set, months of finalized checkpoints, and a track record. The Merge didn’t start Proof of Stake. It connected the already-proven Proof-of-Stake consensus to the chain that held the value.

What actually happened on 15 September 2022

At a pre-agreed point, the execution layer — the old Proof-of-Work Ethereum — did something it had never done before: it stopped mining and started asking the Beacon Chain, “what block comes next?”

Before The Merge, an Ethereum node did both jobs in one program. It picked which transactions to include and decided which chain was canonical by burning electricity to find a valid hash. After The Merge, those two jobs were split across two pieces of software running side by side on every node:

   BEFORE (Proof of Work)              AFTER (The Merge, Proof of Stake)
   ───────────────────────            ──────────────────────────────────
   one client does everything:         consensus client   execution client
     - order transactions               (orders blocks) ◄──► (runs the EVM,
     - pick canonical chain             - runs PoS            holds state)
       by MINING (burn energy)          - LMD-GHOST +       - executes txs
                                          Casper FFG        - computes state root
                                        - NO EVM, NO state  - NO consensus

The trigger was not a date on a calendar — it was a Terminal Total Difficulty (TTD). “Total difficulty” is the sum of all mining difficulty ever accumulated by the Proof-of-Work chain. The upgrade set a specific target value; the last Proof-of-Work block was whichever block first pushed the cumulative difficulty past that threshold. Using an accumulated-work target rather than a wall-clock time meant every node switched at the exact same block, not the same second — no node could be ahead or behind. That last mined block was produced on 15 September 2022; the very next block was proposed by a Proof-of-Stake validator. The engine had been swapped, mid-flight, and the network never stopped.

By the numbers — the swap that changed nothing you could see

   Beacon Chain launched        :  1 December 2020
   parallel run before Merge     :  ~21 months
   Merge date                    :  15 September 2022
   trigger                       :  Terminal Total Difficulty (not a clock)
   downtime for users            :  0 — no halt, no snapshot, no coin migration
   energy use after Merge        :  ~99.95% lower than before
   your account balances         :  identical the block before and the block after

The staggering part is the last two lines together. The chain’s security mechanism changed completely — from “whoever burns the most electricity” to “whoever stakes and attests honestly” — while the chain’s state (every balance, every contract, every storage slot) was byte-for-byte continuous. A user who did nothing noticed nothing, except that Ethereum now used roughly a thousandth of the energy. Treat the ~99.95% as an order-of-magnitude estimate (2022 Ethereum Foundation and independent analyses); the thousandfold drop is well established.

The lasting architecture: two layers, one API

The Merge is a date, but its real legacy is an architecture that is still how Ethereum works today. Every full node now runs two clients that talk to each other:

• The consensus layer (CL) runs Proof of Stake. It answers exactly one question: what is the ordered, canonical sequence of blocks? It runs LMD-GHOST fork choice and Casper FFG finality. It knows nothing about the EVM, balances, or storage.
• The execution layer (EL) runs the EVM. Given a block’s ordered transactions, it executes them, mutates the world state, and computes the new state root. It knows nothing about validators, attestations, or which chain is canonical.

They communicate over a small, local, authenticated interface called the Engine API.

   ┌────────────────────────┐   Engine API    ┌────────────────────────┐
   │   CONSENSUS LAYER (CL) │  (localhost,    │  EXECUTION LAYER (EL)  │
   │                        │   JWT-authed)   │                        │
   │  Proof of Stake        │ ──────────────► │  the EVM               │
   │  LMD-GHOST + FFG       │  "here is the   │  applies txs           │
   │  decides ORDER         │   next payload; │  computes STATE        │
   │                        │   is it valid?" │                        │
   │                        │ ◄────────────── │                        │
   │                        │  "valid / new   │                        │
   │                        │   head is X"    │                        │
   └────────────────────────┘                 └────────────────────────┘

The two verbs that carry almost all the weight are:

• engine_newPayloadV* — the CL hands the EL a proposed block (“execution payload”) and asks: is this a valid state transition? The EL runs every transaction and answers VALID or INVALID.
• engine_forkchoiceUpdatedV* — the CL tells the EL which block is now the canonical head (and which is finalized), the result of running fork choice. The EL updates what it considers the tip of the chain.

Notice the direction of authority. The consensus layer is in charge of order; the execution layer is in charge of correctness of the resulting state. Neither can do the other’s job, and that separation is precisely what made The Merge possible. You could unplug the “mining” consensus client and plug in the “Proof of Stake” consensus client, and the execution client — the EVM, the state, your balance — never had to know or care.

Under the hood — why execution carried over completely unchanged

This is the deepest point on the page, and it’s the payoff for everything you built in the earlier parts of the book. Consensus only decides the order of transactions. Everything downstream of the order is a deterministic function.

Recall the shape of a state transition. Given the current world state and an ordered list of transactions, applying them is pure, mechanical, and reproducible — every honest node computes the identical result. In the book’s companion chain, ethmini, that function is literally WorldState::apply:

// The execution layer, in miniature. Given ONE transaction and the
// current state, this validates and mutates deterministically — and
// then computes a fingerprint of the entire world.
impl WorldState {
    pub fn apply(&mut self, tx: &Transaction) -> Result<Receipt> {
        // validate nonce, balance, gas; run the VM; commit or revert.
        // Nothing here knows or cares HOW `tx` was ordered.
        // ...
    }

    pub fn state_root(&self) -> [u8; 32] {
        // one hash over the sorted accounts: the same inputs
        // always produce the same root, on every node.
        // ...
    }
}

Look at what apply takes: a transaction and the current state. Look at what it does not take: any notion of how that transaction came to be next in line. Whether the ordering was decided by a miner racing to find a hash, or by a validator proposing a slot, is completely invisible to apply. The state machine downstream of ordering is the same machine either way.

So the recipe for swapping consensus live is exactly this:

1. Keep the execution layer — the deterministic apply / state_root machine — byte-for-byte identical.
2. Replace only the component that decides the order fed into it.
3. Because step 1’s machine is a pure function of (state, ordered transactions), the output — every balance, every root — is continuous across the swap.

That is why The Merge could change what secures Ethereum without changing a single account. Mining and Proof of Stake are two different answers to “whose ordering is canonical?” — and the EVM, the gas schedule, the accounts, and the state root are all downstream of that question. Change the answer; the machine that consumes it doesn’t flinch.

What The Merge did — and, just as importantly, did not — do

The Merge is one of the most misremembered events in the ecosystem, because its name sounds like it should have improved everything. It did exactly one thing.

What people expected	What The Merge actually did
Lower gas fees	No. Fees are set by demand for blockspace under EIP-1559, untouched by the consensus swap.
Higher throughput / faster transactions	No. Block capacity and gas limits were unchanged; TPS did not jump.
Enable staked-ETH withdrawals	No. Withdrawals shipped later, in the Shanghai/Capella upgrade (April 2023) — see Withdrawals & Rewards.
Cut energy use	Yes — by ~99.95%. Mining stopped; the only remaining cost is validators running ordinary servers.
Change the consensus mechanism	Yes — that was the entire job: PoW → PoS.

The Merge changed only the consensus mechanism. Lower fees and higher throughput are the province of other work — EIP-1559’s fee market, the layer-2 rollup frontier, and later data-availability upgrades. Bundling them into “The Merge” in your mental model is the single most common Ethereum misconception. The Merge swapped the engine; it did not resize the fuel tank or widen the road.

It actually happened — the quietest big-bang deploy in the industry

On 15 September 2022, a network settling on the order of hundreds of billions of dollars of value changed its entire consensus mechanism while live, with no scheduled downtime and no user action required. Contrast that with how most systems ship a change one-tenth as risky: maintenance windows, database migrations, a “we’ll be back in 4 hours” banner.

The reason The Merge could be a non-event for users is the same reason it’s the centerpiece of this page: the ~21-month parallel run meant the new consensus engine was already proven before it was connected, and the CL/EL separation meant the state machine never had to change. The lesson generalizes far past blockchains — if you can cleanly separate the part of a system that decides ordering from the part that computes results, you can replace the first without touching the second. Most production outages during “big” migrations come from systems that never drew that line. Ethereum drew it, ran the new half in the open for nearly two years, and then flipped one switch.

The architect’s lens

The Merge is best understood not as a feature but as an architecture — the clean split of consensus from execution — so interrogate that split:

• Why does it exist? To let Ethereum replace its consensus mechanism (Proof of Work → Proof of Stake) on a live, high-value network without halting it, forking users, or migrating any state — by separating the component that decides order from the component that computes state.
• What problem does it solve? The seemingly impossible one: changing what secures a running multi-billion-dollar chain mid-flight. It solves it by making the two jobs — ordering (consensus layer) and execution (execution layer) — swappable independently, connected only through the small Engine API.
• What are the trade-offs? Every full node now runs two clients that must stay in sync over the Engine API, adding operational complexity versus the old single monolithic client. In exchange you get a modular architecture where consensus and execution can evolve — and be re-implemented — independently.
• When should I avoid it? The lens here is the separation principle, and it’s the wrong tool when ordering and execution are genuinely inseparable, or when the coordination cost of two components exceeds the benefit — a small, single-purpose system rarely needs the split Ethereum required to survive a live engine swap.
• What breaks if I remove it? Collapse consensus and execution back into one component and the swap becomes impossible: you could no longer change how blocks are ordered without rewriting how state is computed, so a live PoW→PoS transition — the entire point of The Merge — would have required stopping the chain.

Check your understanding

1. When did the Beacon Chain launch, and what was its only job for the ~21 months before The Merge?
2. Describe precisely what changed on 15 September 2022 at the level of “what a node does next.” What triggered the switch — and why a difficulty target rather than a clock time?
3. Name the two layers of the post-Merge architecture, state which one decides order and which decides state, and name the interface they talk over.
4. The Merge is famous for what it didn’t do. Name three things it did not change, and the one thing (besides the consensus mechanism) it did.
5. Using the book’s throughline, explain why the execution layer — the EVM, accounts, and state root — could carry over completely unchanged when the consensus mechanism was replaced.

Show answers

1. The Beacon Chain launched 1 December 2020. For the ~21 months before The Merge its only job was to run Proof-of-Stake consensus — validators staking, committees attesting, checkpoints finalizing — with no EVM, accounts, or real transactions. It proved the new consensus engine in the open while mainnet kept mining under Proof of Work.
2. Before, each node did both jobs in one client and picked the canonical chain by mining (burning energy). On 15 September 2022 the execution layer stopped mining and began taking its block ordering from the Beacon Chain: it now asks a consensus client “what block comes next, and is it final?” over the Engine API. The trigger was the Terminal Total Difficulty (TTD) — a target sum of accumulated mining difficulty — rather than a wall-clock time, so every node switched at the exact same block, not the same second, with none ahead or behind.
3. The consensus layer (CL) decides order (runs PoS: LMD-GHOST + Casper FFG); the execution layer (EL) decides state (runs the EVM, applies transactions, computes the state root). They communicate over the Engine API (e.g. engine_newPayload to validate a block, engine_forkchoiceUpdated to set the head).
4. It did not lower fees, did not raise throughput/speed, and did not enable staked-ETH withdrawals (those came later, in Shanghai/Capella, April 2023). Besides swapping PoW → PoS, the thing it did change was energy use — down roughly 99.95%.
5. Because consensus only decides the order of transactions, and everything downstream of the order — validating, applying each transaction, mutating accounts, computing the state root (WorldState::apply and state_root in ethmini) — is a deterministic function of (current state, ordered transactions). That function doesn’t know or care how the order was chosen. Swapping mining for Proof of Stake changed only who decides the order, so the state machine that consumes the order — and every balance it produces — was byte-for-byte continuous across The Merge.