LibraryMarkets2022Design paperCorpus record
MEV-Boost: a proposer and builder marketplace for Ethereum blocks
MEV-Boost. Flashbots.
MEV-Boost publishes a sidecar that lets a proposer accept a builder's block header and reveal the body only after committing, so the proposer need not build the block.
A reading of the project's public design document. Not a copy, not a benchmark, and not an offer.
MEV-Boost publishes a sidecar that lets a proposer accept a builder's block header and reveal the body only after committing, so the proposer need not build the block.
- Evidence
- Primary paper
- Re-measured
- No
- Assumptions
- 3
- Records linked
- 3
01 Claim ledger
What the paper is allowed to say
Each row is a sentence already in the study. The status is the same on every row: a model claim, not a live measurement.
Claim 01 · Paper model
The defect
A marketplace for blocks is not the protocol's fork choice. It is an out-of-protocol auction. A proposer can ignore it.
Claim 02 · Paper model
The proposal
MEV-Boost publishes a sidecar that lets a proposer accept a builder's block header and reveal the body only after committing, so the proposer need not build the block.
Claim 03 · Paper model
The mechanism
Builders construct payloads. Relays hold them. The proposer signs a header. The body is revealed so the network can form the block.
Claim 04 · Paper model
The bound
This note states no share of blocks and no payment total.
02 Three cuts
Observation, model, falsifier
A desk does not stop at the summary. Each claim is cut three ways, using only this study's own assumptions and checks. Nothing here is a new figure.
01 The defect
Observation
What the study says
A marketplace for blocks is not the protocol's fork choice. It is an out-of-protocol auction. A proposer can ignore it.
Model
What has to hold
You are reading the MEV-Boost repository. An enshrined PBS proposal is a different text.
02 The proposal
Observation
What the study says
MEV-Boost publishes a sidecar that lets a proposer accept a builder's block header and reveal the body only after committing, so the proposer need not build the block.
Model
What has to hold
You are reading the MEV-Boost repository. An enshrined PBS proposal is a different text.
03 The mechanism
Observation
What the study says
Builders construct payloads. Relays hold them. The proposer signs a header. The body is revealed so the network can form the block.
Model
What has to hold
No price, supply, yield, or adoption figure is added by this desk.
Falsifier
What would retire it
Who can see the transaction contents before the header is signed?
04 The bound
Observation
What the study says
This note states no share of blocks and no payment total.
Model
What has to hold
You are reading the MEV-Boost repository. An enshrined PBS proposal is a different text.
Falsifier
What would retire it
Who can see the transaction contents before the header is signed?
03 Sequence
One action, as an operating tape
- 01Builders construct payloads. Relays hold them. The proposer signs a header. The body is revealed so the network can form the block.
- 02The relay is a trusted party in the basic design: it can see order flow and can fail to reveal. That trust is the design, not a surprise.
- 03Proposer-builder separation inside the protocol, if a later EIP enshrines it, is a different document from this sidecar.
04 Load-bearing
The argument, and where a pitch drops it
What the name has to mean
The cut
MEV-Boost publishes a sidecar that lets a proposer accept a builder's block header and reveal the body only after committing, so the proposer need not build the block.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
A relay's censorship policy is a policy of that relay. Do not describe the sidecar as neutral without reading the relay.
What actually moves
The cut
The relay is a trusted party in the basic design: it can see order flow and can fail to reveal. That trust is the design, not a surprise.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
A relay's censorship policy is a policy of that relay. Do not describe the sidecar as neutral without reading the relay.
What a later deployment may change
The cut
Proposer-builder separation inside the protocol, if a later EIP enshrines it, is a different document from this sidecar.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
A relay's censorship policy is a policy of that relay. Do not describe the sidecar as neutral without reading the relay.
05 Register
What has to be true
Model · Not re-measured
You are reading the MEV-Boost repository. An enshrined PBS proposal is a different text.
Model · Not re-measured
The document is the one at the source URL. A marketing page with the same brand is not this text.
Model · Not re-measured
No price, supply, yield, or adoption figure is added by this desk.
06 Divergence
What happened after the paper
This is not a validity proof and not a consensus change.
A later client, parameter set, or reward formula is a different object. Cite this paper for the mechanism. Cite a primary release for the network. This desk has not re-run the proof.
07 Pre-mortem
What to check before you use the idea
- 0 of 3 marked on this browser. A mark is a reading note, not a pass, a rating, or a recommendation.
08 Anatomy
The paper, in the order a builder needs
The problem it names
A marketplace for blocks is not the protocol's fork choice. It is an out-of-protocol auction. A proposer can ignore it.
What the design proposes
- Builders construct payloads. Relays hold them. The proposer signs a header. The body is revealed so the network can form the block.
- The relay is a trusted party in the basic design: it can see order flow and can fail to reveal. That trust is the design, not a surprise.
- Proposer-builder separation inside the protocol, if a later EIP enshrines it, is a different document from this sidecar.
How the mechanism is specified
- Builders construct payloads. Relays hold them. The proposer signs a header. The body is revealed so the network can form the block.
- The relay is a trusted party in the basic design: it can see order flow and can fail to reveal. That trust is the design, not a surprise.
- Proposer-builder separation inside the protocol, if a later EIP enshrines it, is a different document from this sidecar.
What this page does not treat as proven
- This note states no share of blocks and no payment total.
- A relay's censorship policy is a policy of that relay. Do not describe the sidecar as neutral without reading the relay.
- This is not a validity proof and not a consensus change.
Why the desk still reads it
MEV-Boost publishes a sidecar that lets a proposer accept a builder's block header and reveal the body only after committing, so the proposer need not build the block.
09 Lexicon
Terms, opened into the record
- Builder
- A party that assembles a payload. They are not the proposer.
- Relay
- A party that holds the payload and can fail to publish it. Trust sits here in the basic design.
10 Repository
Every linked record on this page
Underlined words open a page that already exists: a concept, a protocol profile, a failure record, or another paper. If a word is not underlined, this desk does not have a record for it.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.