Glamsterdam makes a signed execution payload bid part of the beacon block. The proposer commits to the builder and payload before the builder reveals the full payload.
The network uses two global gossip topics:
proposer_preferencestells builders the public proposal policy; andexecution_payload_biddistributes builder commitments.
Proposer preferences
The topic carries SignedProposerPreferences.
dependent_root: Root
proposal_slot: Slot
validator_index: ValidatorIndex
fee_recipient: ExecutionAddress
target_gas_limit: Uint64
signature: BLSSignature
The dependent root fixes the proposer lookahead branch used to derive the validator assignment. A proposer may broadcast preferences after lookahead names its future slot and before that slot starts.
A receiver ignores:
- preferences after the proposal slot has started;
- a proposal whose proposer is not known yet;
- an unknown or failed dependent block;
- a duplicate
(dependent_root, proposal_slot); or - a root that cannot be the shuffling-dependent root for the lookahead epoch.
It rejects a dependent block at or after the lookahead boundary, a validator
that is not the assigned proposer, or an invalid BLS signature under
DOMAIN_PROPOSER_PREFERENCES.
If a proposer does not publish valid preferences, the consensus validator guide says that it will not accept a trustless builder bid for that slot.
The global object does not contain max_execution_payment. A proposer sends
that per-builder trust limit through the Builder API. Builders must not infer
it from the gossip object.
Bid object
The topic carries SignedExecutionPayloadBid. Its message contains:
parent_block_hash: Hash32
parent_block_root: Root
block_hash: Hash32
prev_randao: Bytes32
fee_recipient: ExecutionAddress
gas_limit: Uint64
builder_index: BuilderIndex
slot: Slot
value: Gwei
execution_payment: Gwei
blob_kzg_commitments: ProgressiveList[KZGCommitment]
execution_requests_root: Root
value is the builder's collateral-backed consensus payment. The payload
fields and roots bind the later envelope to one execution and beacon parent.
Gossip admission
The receiver uses the bid's parent block post-state and advances it to the bid slot for builder checks.
It ignores:
- a bid outside the current or next slot;
- another valid bid from the same builder for the same slot and parents;
- a bid whose value is not above the best value seen for those parents;
- an unknown beacon parent or unavailable parent post-state;
- a bid beyond proposer lookahead;
- missing matching proposer preferences;
- a fee recipient that differs from those preferences;
- an unknown execution parent;
- a gas limit incompatible with the parent and target gas limit;
- a bid incompatible with the current head branch; or
- a builder whose collateral cannot cover
value.
It rejects:
- a slot not later than the parent state slot;
- too many blob commitments for the proposal epoch;
- a wrong
prev_randao; - an out-of-range, inactive, or wrong-version builder;
- a bad builder BLS signature; and
- in the pinned gossip rule, any non-zero
execution_payment.
The node records the accepted builder key and highest value only after all checks pass.
Small bid increments can cause forwarding work. Implementations should require a useful increment or forward only the best bid at bounded intervals. Local policy must not turn an otherwise invalid bid into a valid one.
Proposer selection
The proposer can learn a bid from gossip or the direct Builder API. Both enter the same fixed-field checks.
A selected bid must:
- name the proposal slot and current beacon parent root;
- name the correct execution parent;
- carry the current
prevRandao; - fit the epoch blob limit;
- have an active builder with enough collateral for
value; and - pass
process_execution_payload_bid.
For a self-build, builder_index is BUILDER_INDEX_SELF_BUILD, value is
zero, and the signature is the point at infinity. For an external builder, the
normal builder signature and collateral checks apply.
The proposer puts exactly one selected SignedExecutionPayloadBid in the
beacon block. A later higher bid does not change an already signed block.
Source conflict: execution payment
The pinned builder specification permits execution_payment up to the
proposer's per-builder max_execution_payment, and permits a bid to use both
value and execution_payment.
The pinned consensus gossip function rejects every bid whose
execution_payment is non-zero. The beacon-chain transition records only
value as a collateral-backed pending payment and does not resolve the
gossip mismatch.
This corpus therefore cannot claim that a non-zero execution payment is interoperable. With the pinned revisions, such a bid can be built under the Builder API text but cannot pass consensus gossip validation. The source projects must align before this field has one complete network contract.