What Happens in Those 12 Seconds Between Ethereum Blocks
Breaking down Ethereum's block building pipeline - searchers, builders, relays, proposers, and the MEV supply chain
What Happens in Those 12 Seconds Between Ethereum Blocks
There's an entire ecosystem running between Ethereum blocks. Searchers, builders, relays, proposers, all competing over what goes into the next block. It's a complex dance that happens every 12 seconds, and most users have no idea it's happening.
Let's break down Ethereum's block building pipeline as it stands in 2026.
The Basics: Slots, Epochs, and Committees
Time on Ethereum gets split into 12-second slots. Each slot, one validator proposes a block. 32 slots make one epoch (~6.4 minutes). And after 2 epochs, blocks reach finality. That's when your transaction is truly irreversible.
With ~1M validators on the network, not everyone can verify every block. That would be impossibly slow. So validators are randomly split into committees using RANDAO (the randomness beacon built into the protocol). There are 64 committees per slot, each with 128+ validators attesting whether the block head is valid or not.
This committee structure is what makes Ethereum's consensus scalable. Instead of a million validators all checking the same thing, you have smaller groups that rotate responsibilities. The randomness prevents attackers from knowing which validators will be in which committee ahead of time.
MEV: The Game Within the Game
Now the fun part. MEV.
MEV (Maximal Extractable Value) is extra profit squeezed out by reordering, inserting, or excluding transactions in a block. If you've ever wondered why your swap executed at a slightly worse price than expected, MEV is probably why.
Front-running, back-running, sandwich attacks, all of this exists to extract MEV from transactions. Someone sees your big swap in the mempool, buys before you (front-run), lets your swap push the price up, then sells after you (back-run). You got sandwiched. The MEV searcher made money. You got a worse price.
It sounds predatory, and some of it is. But MEV also includes legitimate arbitrage that keeps prices consistent across exchanges. The line between "helpful price correction" and "extractive behavior" is blurry.
Before PBS: The Wild West
Before PBS (Proposer-Builder Separation), validators did everything. They picked transactions from the mempool, ordered them however they wanted, built the block, and proposed it. They could reorder transactions to extract MEV themselves.
The problem? The same people securing the network were also the ones gaming it. Large validators had a huge edge. They could run sophisticated MEV extraction strategies that small validators couldn't compete with. Censorship was easy because validators had full control over what went into blocks. And MEV bot gas wars spiked fees for everyone else. Searchers would bid up gas prices trying to get their transactions included first, and regular users paid the price.
This centralization pressure was bad for Ethereum's decentralization. If running a validator means you also need to run a sophisticated MEV operation to stay competitive, you're going to end up with fewer, larger validators.
PBS: Separating the Roles
This was fixed with Proposer-Builder Separation (PBS), by splitting block building into two roles:
-
Builders: Specialized actors who construct optimized blocks, including MEV extraction. They compete to build the most profitable blocks.
-
Proposers (validators): They pick the block with the highest bid from builders, through mev-boost. They don't need to understand MEV. They just pick the highest number.
This separation is elegant. Validators can stay simple and decentralized. Builders can be sophisticated and centralized (there are only a handful of major builders). The system works because builders compete on price, and proposers just take the best offer.
The MEV Supply Chain
Here's how transactions actually flow through the system:
Step 1: Transaction Submission
Users submit a transaction through their wallet. It enters the public mempool or increasingly, a private channel. Private channels (like Flashbots Protect) hide your transaction from searchers, preventing you from being sandwiched. The tradeoff is you might not get the absolute best execution, but you're protected from the worst outcomes.
Step 2: Searchers Hunt for MEV
Searchers scan the mempool for MEV opportunities. They're looking for arbitrage, liquidations, sandwich opportunities, anything they can profit from. When they find something, they package ordered bundles of transactions, and send them to builders with a bribe. The bribe is what they're willing to pay the builder to include their bundle in the block.
The searcher might say "here's a bundle that makes me $10,000. I'll give you $8,000 to include it." The builder makes $8,000, the searcher keeps $2,000, everyone's happy (except maybe the user who got sandwiched).
Step 3: Builders Construct Blocks
Builders receive searcher bundles plus regular mempool transactions and construct the most profitable block possible. They're playing Tetris, fitting together bundles and transactions to maximize total value. They add a bribe for the proposer at the end. The more profitable the block, the more they can afford to bid, the more likely they are to win.
But builders don't talk to proposers directly. That would be messy and require trust.
Step 4: Relays as Middlemen
Relays sit between builders and proposers. They validate builder payloads (making sure the block is actually valid and the bid is real) and surface the best bid to proposers.
Here's the clever part about how relays work. To prevent the proposer from seeing the block's transactions and just rebuilding it themselves (stealing the MEV), relays send only the block header to the proposer. The proposer signs and commits to this header without seeing the contents.
Step 5: Commitment and Reveal
The proposer signs the header, sends it back to the relay, and only then receives the full block to propose.
Why can't the proposer just steal the block contents after seeing them? Because signing two different headers for the same slot is a slashable offense. The builder can broadcast both signatures as evidence and get the proposer slashed. The proposer loses 1 ETH and gets kicked out of the validator set. Not worth it.
This commitment scheme is what makes the whole system work without requiring trust between builders and proposers. The relay just facilitates the exchange.
The Problem: Off-Chain Trust
But here's the thing. This entire system runs off-chain. Relays are trusted third parties. Nothing is enshrined in the protocol. If a relay goes down, builders can't reach proposers. If a relay is malicious, it could censor transactions or manipulate bids.
We're running a trustless blockchain with a trusted middleware layer. That's not great.
That's where ePBS comes in.
EIP-7732 (ePBS) is the headliner for the Glamsterdam hard fork. It moves the builder-proposer auction directly into the consensus layer, removing the middle layer of trusted relays. Builders submit bids on-chain. The auction happens in-protocol. No more trusting Flashbots or other relay operators.
This is a big deal for Ethereum's credible neutrality. The block building market becomes protocol-enforced, not dependent on the goodwill of relay operators.
The Censorship Problem
But there's still the censorship problem. Builders can exclude transactions and nothing in the current protocol stops them. A builder might be legally compelled to censor certain addresses. Or they might just choose to. The protocol doesn't care. It sees a valid block.
The solution: FOCIL (Fork-Choice Enforced Inclusion Lists, EIP-7805).
Each slot, 16 random validators form an inclusion list committee. Each member looks at the mempool and gossips a list of transactions that must be included. The builder has to include these transactions or attesters won't vote for the block.
You only need 1 honest member out of 16 to prevent censorship. That's a 1-of-N honesty assumption, much weaker than requiring all members to be honest. As long as one person on the committee is honest and their inclusion list propagates, censorship gets caught.
FOCIL is slated for Hegota, the fork after Glamsterdam. Between ePBS and FOCIL, Ethereum will have protocol-enforced builder markets and protocol-enforced inclusion guarantees. No more trusting third parties for either.
Preconfirmations: Faster Than 12 Seconds
Perhaps one of the best updates of 2025 is preconfirmations going from research to production.
The 12-second block time is fine for most things, but it's slow for real-time applications. If you're building a trading interface or a game, 12 seconds feels like forever. You submit a transaction and then... wait. Maybe it gets included in the next block. Maybe the one after. You don't know.
Preconfs (preconfirmations) let proposers issue signed commitments guaranteeing your transaction will be included within a specific timeframe. Instead of waiting 12 seconds and hoping, you get a cryptographic promise in milliseconds.
The proposer is essentially saying "I promise to include your transaction. Here's my signature. If I don't include it, you can prove I lied." There are slashing conditions and bonds involved to make this credible.
Taiko launched the first based preconf sidecar on mainnet in August 2025, delivering ~2 second confirmations. I've been working on this during my time at Nethermind and it's pretty cool. The UX improvement is dramatic. Transactions feel instant even though the underlying blockchain still runs at 12-second slots.
Based Rollups: Bringing MEV Home
Preconfs matter even more because of based rollups. These are L2s that use Ethereum validators for sequencing instead of centralized sequencers.
Most L2s today have a single sequencer that orders transactions. It's fast, but it's centralized. The sequencer can censor, can extract MEV, can go down and halt the chain. Based rollups eliminate this by using Ethereum's validators for sequencing.
MEV flows back to L1 validators instead of being captured by a single sequencer. This is better for Ethereum's economic security (validators earn more, making staking more attractive) and better for decentralization (no single point of failure).
The tradeoff is latency. If you're using Ethereum validators for sequencing, you're bound by Ethereum's 12-second slots. That's where preconfs come in. Based rollups with preconfs get the decentralization benefits of Ethereum sequencing with the speed benefits of sub-second confirmations.
Wrapping Up
That's an introduction to block building, Proposer-Builder Separation, and some of the recent work happening in this space. The block building pipeline is one of those areas where research moves fast and the production systems are constantly evolving.
We went from validators doing everything, to PBS splitting roles, to ePBS enshrining the auction on-chain, to FOCIL adding inclusion guarantees, to preconfs making everything feel faster. Each step addresses a real problem with the previous design.
This is what I've been studying and working on lately. If you're interested in this stuff, the best way to learn is to read the EIPs, follow the client teams, and maybe run some simulations. The details matter, and they're fascinating.
Topics