EIP-6110: putting validator deposits in the block
To become a validator you deposit 32 ETH to a contract on the execution layer — but the consensus layer used to learn about that deposit by polling and voting on the contract's state, a fragile 'eth1 voting' dance that added ~12 hours before activation. EIP-6110 puts deposits directly in the block, so the consensus layer just reads them.
- the Merge & the beacon chain
- EIP-7002 (EL-triggerable withdrawals)
Prague / Electra, May 2025. Becoming a validator starts with a simple act: deposit 32 ETH to the deposit contract — an ordinary contract on the execution layer. But the consensus layer doesn’t execute that contract; it runs a different machine. So how does it find out a deposit happened? For years the answer was a surprisingly baroque one — the consensus layer watched the deposit contract from the outside, polling its state and having validators vote on what they saw. That worked, but it was slow and brittle, and after the Merge fused the two layers into one block, it made no sense at all. EIP-6110 removes the middleman. Let’s derive it.
The problem: the consensus layer polled and voted
The deposit lives on the execution layer, but only the consensus layer can register a new validator. Pre-6110, it bridged that gap with eth1 voting The mechanism by which the beacon chain learned execution-layer state before EIP-6110: validators observed the deposit contract at a safe 'follow distance' behind the head and voted, over a voting period, on the deposit-contract state to adopt. Robust against reorgs, but slow and complex. : validators observed the deposit contract at a conservative follow distance behind the chain head — far enough back that a reorg couldn’t retract it — and then voted, over a voting period, on which deposit-contract state to accept. Only once that vote concluded were the deposits admitted and the validators queued for activation. The follow distance plus the voting period added up to roughly half a day of latency before the chain even acknowledged your deposit.
→ Step 2: stop watching — read the deposits straight out of the block.
EIP-6110: deposits become a block request
The fix is to make the deposit part of the block itself. When the deposit contract emits a deposit, EIP-6110 has the execution client collect those events and include them in the block as a new deposit request A deposit event surfaced directly in the execution block (as part of the block's requests). The consensus layer reads deposits from the block it already processes, instead of polling the deposit contract and voting on its state. — part of the block’s requests list. The consensus layer, which already ingests and validates every execution block, now simply reads the deposits out of it. No polling, no follow distance, no vote. Because a deposit is only in the block if the block is valid, and the block is only canonical once finalized, reorg safety comes for free from ordinary consensus — the very thing eth1 voting was hand-rolling.
→ Step 3: the deposit is recognized almost immediately.
The payoff: fast activation, one uniform flow
Because a deposit is now processed the moment its block is, the long eth1-voting delay disappears: recognition drops from hours to minutes (activation still passes through the validator activation queue, but the discovery latency is gone). Just as important, EIP-6110 deletes a fragile, consensus-critical subsystem — one fewer thing that can break the chain. And it slots deposits into the same execution-layer request A uniform mechanism (EIP-7685) where the execution layer emits typed requests in the block — deposits (6110), withdrawals (7002), and consolidations (7251) — that the consensus layer reads and acts on. One framework replaces several bespoke bridges between the layers. framework as EIP-7002 withdrawals and EIP-7251 consolidations: deposits in, withdrawals out, consolidations within — all flowing through the block as requests, all read by the consensus layer the same way.