Proposer builder separation and the MEV supply chain

The supply chain, link by link

The validator chosen to propose an Ethereum slot almost never decides what goes into it. It sells that right, every twelve seconds, to whichever specialist builder bids the most, and the builder in turn sources transactions and bundles from wallets, private RPCs and searchers. Proposer builder separation (PBS) is the name for that division of labor. It exists because MEV turned block building into a job for professionals, and making every validator compete at it would have favored the largest stakers.

Every row boundary is a trust boundary. The sections below walk them in order, then turn to what the protocol is changing.

MEV-Boost: PBS outside the protocol

MEV-Boost is the software that made PBS real. Built by Flashbots, its mainnet relay went live on September 1, 2022 and version 1.0 shipped on September 12, days before the Merge. It sits beside the consensus client and runs a four step auction.

1. Register once per epoch

   The validator signs a registration carrying its fee recipient and preferred gas limit and sends it to the relays it has chosen to trust. Builders learn where to pay.

2. Ask for headers, not blocks

   When its slot arrives, the validator asks every configured relay for the best bid on this slot and parent. Each relay answers with an execution payload header and a value. The transactions stay hidden.

3. Sign blind

   The validator picks the highest bid and signs a blinded beacon block that commits to that header. The signature is the commitment: signing a second block for the same slot is a slashable equivocation, which deters the proposer from taking the builder’s contents and building its own. Deters, not prevents: the April 2023 incident below shows a proposer taking that risk when the prize was large, which is why relays now publish the block before anyone sees the body.

4. Reveal

   The validator returns the signed blinded block to the relay, which publishes the full block. Only now does anyone outside the builder and relay see the transactions.

# The builder API that MEV-Boost speaks (ethereum/builder-specs)

POST /eth/v1/builder/validators
     # registerValidator: fee recipient and gas limit, signed by the validator key

GET  /eth/v1/builder/header/{slot}/{parent_hash}/{pubkey}
     # getHeader: the best bid for this slot, as a header plus a value, no transactions

POST /eth/v2/builder/blinded_blocks
     # submitBlindedBlockV2: the relay publishes the full block and blobs, answers 202.
     # The v1 endpoint, which returned the payload instead, is deprecated after Fulu.

POST /eth/v1/builder/execution_payload_bid/{slot}/{parent_hash}/{parent_root}/{proposer_pubkey}
     # getExecutionPayloadBid: for the Gloas fork, where the bid is an in protocol object

If no bid clears a floor the operator sets with MEV-Boost’s -min-bid flag, it returns nothing and the consensus client falls back to building locally. Few validators end up there. For the 24 hours to September 28, 2026, relayscan.io counted roughly 6,600 blocks delivered through relays against 7,200 slots, about 92% of the day.

What everyone trusts the relay for

Blind signing only works if somebody holds the payload between the bid and the signature, and checks it before the proposer commits. That somebody is the relay, which Flashbots’ own documentation describes as trusted by both sides.

The failure mode is not hypothetical. On April 3, 2023 a malicious proposer signed an invalid block header. The relay did not validate the header before revealing the body, so the proposer received the full block, including sandwich bots’ bundles, while the invalid block itself could never be published. It then built its own block that turned those bundles against their owners, taking about $20 million from the bots, according to the Flashbots post-mortem. Relays were patched to withhold the body unless they succeed in publishing the block. The general lesson: every check a relay skips is a trust assumption someone else is carrying.

Why block building concentrates

A builder’s bid is bounded by what its block is worth: priority fees plus the MEV it captures by ordering, minus its costs. It does not need to bid all of that. It needs to beat the second best builder, so its margin is roughly the gap between the two block values.

Work an illustrative slot. Every builder sees the same public mempool and can build a block worth 0.080 ETH. One builder also receives private orderflow worth 0.015 ETH that nobody else sees. It bids a hair over 0.080, wins, and keeps most of the 0.015. Public value goes to the proposer; exclusive value becomes margin. That is the flywheel: exclusive orderflow wins auctions, winning makes a builder the natural destination for more orderflow, and wallets and trading firms route to whoever lands their transactions most reliably.

Latency to relays, integration with a trading desk that prices arbitrage against centralized exchanges, and the balance sheet to bid aggressively all compound it. On relayscan.io for the 24 hours to September 28, 2026, three builders produced about 94% of MEV-Boost blocks: Titan 54.3%, BuilderNet 21.7% and Quasar 18.3%. Relays were less concentrated, and the second largest that day, titanrelay.xyz, carries the brand of the largest builder.

Builder concentration is less dangerous than validator concentration, because a builder cannot reorganize the chain or vote on finality. What it controls is which transactions get in quickly, and that is where censorship enters.

Censorship and weak inclusion

In late 2022 several builders and relays excluded transactions touching addresses on the US OFAC sanctions list. At the November 2022 peak about 80% of daily blocks were compliant in that sense; by May 2023, as non filtering builders and relays gained share, the figure had fallen to 27% (The Block). One of the largest relays in September 2026 still carries “regulated” in its name.

Censorship by a subset of builders delays a transaction rather than stopping it: it waits until a non censoring builder, or a validator building locally, wins a slot. If a share c of slots goes to builders that exclude it, and slots are independent, the wait is geometric.

Minutes are survivable for a payment. They are not survivable for a liquidation, an oracle update, a fraud proof or a forced withdrawal through a rollup’s escape hatch, all of which race a deadline. That is the protocol level case for inclusion lists: censorship resistance should not rest on the goodwill of a handful of builders.

FOCIL: inclusion lists enforced by fork choice

Fork choice enforced inclusion lists (EIP-7805) turn inclusion from a courtesy into a condition that attesters check. In each slot a committee of 16 validators (IL_COMMITTEE_SIZE) builds inclusion lists from its own view of the public mempool, each capped at 8 KiB of transactions (MAX_BYTES_PER_INCLUSION_LIST = 8192), and gossips them. Validators store the lists they see before a view freeze deadline 9 seconds into slot N. When they attest to the block for slot N+1, they check it against the union of those lists.

# What an attester checks in slot N+1 under FOCIL (EIP-7805), simplified.
# il_txs: every transaction from the inclusion lists it stored before the
# view freeze deadline of slot N (16 committee members, 8 KiB per list).

def block_satisfies_inclusion_lists(payload, il_txs):
    gas_left = payload.gas_limit - payload.gas_used
    state = post_state(payload)
    for tx in il_txs:
        if tx in payload.transactions:
            continue                  # included, anywhere in the block
        if tx.gas > gas_left:
            continue                  # block is full: conditional inclusion
        if not valid_if_appended(tx, state):
            continue                  # nonce, balance or validity changed
        return False                  # it fit, it was valid, it was left out
    return True                       # otherwise the block can be attested to

Three choices do the work. Inclusion is conditional: a full block, or a listed transaction that has since become invalid, is not a violation, so nobody can force spam into a block. It is anywhere in block: the builder keeps full control of ordering, which leaves little reason to buy a position through a side channel. And it needs only one honest member out of 16: a single committee member that lists a censored transaction forces it into the next block, or that block loses its attestations. Committee members are not paid for this; the EIP relies on that 1 of N assumption instead of adding a fee mechanism.

Enshrined PBS (EIP-7732)

Enshrined PBS moves the auction into consensus and removes the need to trust anyone with the payment or the payload escrow. As specified in EIP-7732:

• Builders become protocol entities. They are staked in the beacon state with their own withdrawal credential prefix (0x03), can stake as little as 1 ETH, do not validate, and sit outside the validator deposit and exit queues.
• The beacon block carries a bid, not a payload. The ExecutionPayload field is replaced by a SignedExecutionPayloadBid: the builder’s commitment to a block hash and a value.
• Payment is unconditional. Processing the beacon block deducts the value from the builder’s balance and queues a withdrawal to the proposer. If the builder then withholds its payload, the slot is empty, and the proposer is still paid.
• A committee judges timeliness, not correctness. A Payload Timeliness Committee of 512 validators (PTC_SIZE) attests to whether the committed payload and its blob data arrived on time. It does not execute anything.
• Execution leaves the critical path. Consensus on the beacon block no longer waits for execution, so the EIP gives the next proposer about 6 seconds and every other validator about 9 seconds to validate the payload. Today execution has to fit before the attestation deadline, 4 seconds into the slot.

Two subtleties matter if you build on it. First, relays do not have to disappear. The EIP leaves room for trusted payments fulfilled elsewhere, and the builder API already defines a getExecutionPayloadBid endpoint for Gloas, the consensus layer half of Glamsterdam, so proposers can still source bids over HTTP from builders or intermediaries. What changes is that a trustless path exists. Second, the EIP’s own security section names a free option problem: the builder commits at the start of the slot and reveals seconds later, and if prices move against the block in between, a rational builder may prefer to withhold it and eat the bid. Preliminary simulations cited in the EIP suggest this could happen noticeably often, and variable penalties for withheld payloads have been proposed. The EIP also notes that proposers and attesters controlling consecutive blocks and more than 20% of stake could reorg a builder’s payload and still force it to pay.

Status: EIP-7732 is in Review and is the headline change of Glamsterdam. As of late September 2026 Glamsterdam was in final testing, with its Sepolia fork scheduled for October 6, 2026 and mainnet targeted for the fourth quarter of 2026 with no confirmed date. None of this section is live on mainnet yet.

Timing games

Bids rise through a slot, because builders keep adding transactions and new opportunities keep arriving. A proposer that asks for headers at 0 seconds gets the bid available at 0 seconds. One that waits gets more, as long as its block still reaches enough attesters before the 4 second attestation deadline. Wait too long and the next proposer can orphan the block, and the whole slot’s revenue is lost.

Schwarz-Schilling and coauthors modeled this in 2023 (Time is Money) as honest but rational proposers delaying to capture more MEV while still being included, and found on Ethereum data that timing games were worth playing but not yet widely exploited. The worry is structural: a second is worth most to well connected, sophisticated operators, and every late block eats into the time attesters and the next proposer have. Any change to slot timing, ePBS included, has to be checked against this incentive.

Orderflow auctions: giving MEV back

If orderflow is the scarce input, the user who creates it can be paid for it. Orderflow auctions sell the right to backrun a transaction, return most of the proceeds to its sender, and promise that nobody gets to front run or sandwich it.

Each design moves value back toward users and adds a party to trust: the auction operator not to leak flow, the enclave hardware not to be broken, the solvers not to collude. Each also pulls flow into private channels, one more force behind builder concentration.

Solana: no public mempool, same economics

Solana has no global mempool in the Ethereum sense. Transactions are forwarded to the scheduled leader (see inside the Solana runtime), and for years the MEV market has run through Jito, whose modified validator client most stake has run. Its unit is the bundle:

• Up to 5 transactions, executed sequentially and atomically: all of them land or none do.
• Paid for with a tip, which is any instruction that transfers SOL to one of 8 tip accounts, with a minimum of 1,000 lamports.
• Sold in parallel auctions that run on 50 millisecond ticks, ranked by tip per requested compute unit.

In March 2024 Jito shut down the mempool stream it had offered searchers, citing the harm sandwich attacks did to users. In September 2025 it launched BAM, the Block Assembly Marketplace, on mainnet. BAM nodes run inside trusted execution environments (AMD SEV-SNP), keep transactions encrypted until execution, let applications plug in their own ordering rules, and publish attestations of the order they produced. It is a different answer to the question PBS answers on Ethereum: who orders transactions, and what does everyone else have to trust about that.

What is still open

• Building after ePBS. ePBS removes relay trust, not the economics of exclusive orderflow. Decentralizing the builder role itself is research, not roadmap.
• Withholding. How often builders exercise the free option will only be known from mainnet data.
• Inclusion versus ordering. FOCIL makes inclusion hard to deny but leaves ordering to the builder, so it does nothing about sandwiching.
• Cross domain MEV. Based rollups would hand their ordering to L1 builders, tying these answers to rollup design.

Common questions

Where to go next