Mini-Blocks: SSV-Backed Sub-Slot Auctions for Ethereum PBS

MatheusFranco99 · May 18, 2026, 4:56pm

This work has been done in collaboration with Gal Rogozinski.

Motivation

Ethereum block value is heavily concentrated at the top of the block. The first few transactions — arbitrage legs, liquidations, oracle-sensitive trades — capture a disproportionate share of the value extracted over a slot, while the remainder of the block settles in a comparatively quiet, lower-value regime. This is partly a consequence of the slot cadence itself: builders compose a single ordered payload once every 12 seconds, and competitive searchers concentrate their effort on the positions where execution risk is lowest.

Mini-blocks address this by decomposing a single slot into an ordered sequence of partial payloads. Each mini-block is the outcome of its own auction round within the slot, is signed by the proposer, and extends the state accumulated by previously accepted mini-blocks. The canonical Ethereum block is still produced at the end of the slot through the standard PBS pipeline — mini-blocks are a sub-slot layer on top of it — running several top-of-block-like auctions per slot rather than a single one, so that the value currently locked up in the first few positions can also be realized across the rest of the block.

The economic logic follows from the reasons why value concentration happens at the top of the block: searchers running CEX-DEX arbitrage and related strategies face execution risk that grows with the time between decision and inclusion, and optionality that widens over the same interval. As shown in the nuconstruct analysis [1], shortening the interval between auctions reduces searcher execution risk faster than it shrinks optionality, so running several shorter rounds within a slot raises the expected value that searchers — and therefore builders and proposers — are willing to pay for each round, rather than merely repackaging the same transaction set across more slots.

Several concrete benefits follow. Proposers capture more value per slot because they run more priced auctions per slot. Users get faster confirmations as a side-effect of the round cadence, which sets up a natural extension path toward explicit preconfirmations without changing the block-building pipeline. Builders get several well-defined top-of-block-shaped opportunities per slot instead of one, which diversifies the kinds of strategies that can compete profitably.

The design also improves flexibility for builder and relay participation strategies. Builders can bid whenever they find a profitable mini-block, whether with small or large bundles. Validators have a free market to select profitable bids.

Critically, these gains require no new infrastructure. The main design principle is to reuse existing PBS infrastructure — relays and builders — and run multiple auction rounds per slot rather than introducing a separate block-building pathway. By fully inheriting the PBS design and its trust assumptions, it preserves the unified pipeline that existing infrastructure relies on and keeps the operational and trust profile for relays and builders essentially unchanged.

The key technical enabler is SSV’s Distributed Validator Technology (DVT). A DVT cluster produces valid BLS signatures only when a threshold of independent operators agree, making the cluster’s signature on a mini-block header a credible commitment: reneging requires corrupting a threshold of separate parties, not a single key holder.

This document covers the following topics:

Communication layer between SSV operators and relays.
Protocol overview: round structure, bid selection, and state advertisement to relays and builders.
Block packing and submission to the Ethereum network.
State advertisement to users and transaction simulation on top of it.
Security.
Conclusions.

Actors

SSV Operators (DVT Cluster): a BFT set of operators jointly running an SSV validator. For the purposes of this document, the cluster is treated as the proposer-side entity that selects mini-block bids during the slot and later signs the final block.
Relays: entities that receive mini-block-related messages from the DVT cluster, source candidate segments from builders or local orderflow, and expose partial state interfaces to downstream consumers.
Builders: entities competing to provide profitable transaction sequences for mini-block windows. A final block may contain mini-blocks sourced from different builders and relays.
Users, searchers, and applications: external consumers of the partial state who may want to observe the evolving block, simulate transactions on top of it, or submit new orderflow targeting subsequent mini-block windows.

1. Communication layer between SSV operators and relays

Client-server style interface

The communication model follows a client-server style interface between the SSV operators and the relay set, mirroring the usual relay-proposer relationship in standard PBS.

Registration

The first step in this interface is a long-lived advertisement that a given validator opted-in to the mini-block process. This advertisement is a one-time registration rather than a per-proposal-duty event: it lets relays know ahead of time that proposals from this validator will follow the mini-block flow, so they are ready to submit mini-block bids when the validator obtains a proposer duty.

This can be accomplished by extending the SignedValidatorRegistrationV1 container for the Builder-API [6] with a mini-block field. Relays already consume validator_registration as the canonical opt-in signal from a validator, it is signed with the validator’s BLS key over a well-defined domain, and extending it avoids introducing a parallel registration path. Concretely, we add a miniblocks_enabled field to the registration message of the builder specs [7]:

class ValidatorRegistrationV1(Container):
    fee_recipient: ExecutionAddress
    gas_limit: uint64
    timestamp: uint64
    pubkey: BLSPubkey
    miniblocks_enabled: boolean  # new

A validator opts in by submitting a standard SignedValidatorRegistrationV1 with miniblocks_enabled = true. The rest of the call behaves exactly as today.

Slot communication

While the registration is long-lived, no per-slot setup exchange is needed. Relays already know, via the registration, that this validator runs the mini-block flow. When operators obtain a proposer duty, they simply begin accepting bids from registered relays for that slot — mirroring how validators interact with relays today. Authentication of decisions follows the existing conventions using the validator’s BLS key.

Relays communicate with all operators in the cluster symmetrically. In practice this means that relays propose segments to all operators and, after consensus is reached, await a valid proven output from at least one of them.

2. Protocol overview

A slot is decomposed into an ordered sequence of mini-block windows (or rounds), followed by a full-block phase in which the final block is assembled and submitted. Before describing the messages and protocol steps, we establish the timing constraints that bound how many rounds are feasible and how long each one can last.

2.1 Timing

The total time available for the mini-block protocol is derived from two boundary conditions:

Start: the protocol begins at second -8 relative to the proposal slot start. SSV operators use the prior window (-12 to -8) to construct the RANDAO validator signature for the upcoming slot, so by -8 the pre-consensus phase is complete and mini-block auctions can begin.
End: mini-block auctions close at T=0 (the start of the proposal slot). From this point the protocol transitions to the full-block phase: relays immediately forward FinalBlockBids, and the cluster selects and signs the best bid — exactly as validators play timing games in standard PBS today, for example waiting up to 1.5 seconds into the slot to maximize bid value.

This gives 8 seconds for mini-block auctions, after which the full-block phase begins at T=0 and follows the same timing dynamics as standard PBS. With the default of M = 4 mini-blocks, each auction window lasts 8 / 4 = 2 seconds.

The multi-round MEV-Boost paper [2] models each PBS round as taking approximately 4 seconds, broken down as roughly 2 seconds for builder construction and bid selection, and 2 seconds for state dissemination to other builders. Our design improves on that because dissemination is decoupled from the round: the MiniBlockHeader already carries the state_diff, and thus builders can begin constructing their next bid while dissemination of the transaction list is still propagating, meaning dissemination runs concurrently with construction rather than sequentially after it. We therefore retain the same 2 seconds for construction but pay zero additional time for dissemination, halving the effective round cost and making 2-second windows feasible.

One additional factor is DVT consensus latency: within each window, the cluster must reach threshold agreement on the winning bid before returning a SignedBlindedMiniBlock, consuming part of the construction budget. The time available for builder construction is therefore the initial window_duration − consensus_latency seconds of the window. For example, if consensus_latency is 0.5 seconds, operators are expected to pick the best bid when there is around 0.5 seconds left for the window to finish, and relays can optimize for it. Namely, validators may optionally advertise an expected consensus latency at registration, allowing relays to calibrate their bid submission deadlines accordingly. Furthermore, while this may take a considerable portion of the window, in the future, DVT clusters will be able to choose consensus algorithms with better timing guarantees optimized for this specific problem.

Hyper-parameters

Parameter	Default	Description
`STARTING_TIME`	`-8s`	Start of mini-block auctions relative to proposal slot
`NUM_MINIBLOCKS`	`4`	Number of mini-block windows; each lasts `8s / NUM_MINIBLOCKS`

[!NOTE] The 2s partition is a baseline for the first protocol phase. Future refinements could relax the rigid round cadence to better track the continuous bid streams relays may naturally produce — see the continuous bids appendix for future work on that matter.

2.2 Messages

// Relay -> DVT Cluster: bid for a mini-block window
message BlindedMiniBlock {
    uint64 slot                   = 1;
    uint64 mini_block_index       = 2;
    bytes  parent_mini_block_root = 3; // hash(SignedBlindedMiniBlock[i-1]), or parent block root for i=0
    uint64 bid_value              = 4; // payment to the proposer
    bytes  tx_root                = 5; // BinaryMerkleRoot([keccak256(t_1),...,keccak256(t_k)])
    bytes  state_root             = 6; // post-execution EVM state root
    bytes  state_diff             = 7; // account/storage delta produced by this tx sequence
    uint64 gas_used               = 8; // total gas consumed by this tx sequence; cumulative gas across all accepted mini-blocks must not exceed MAX_BLOCK_GAS
    uint64 tx_count               = 9; // number of transactions k_i; must equal len(T_i) and is consistent with tx_root
    bytes  builder_signature      = 10; // builder's BLS signature over this bid
}

// DVT Cluster -> Relay: signed acceptance of a winning bid
message SignedBlindedMiniBlock {
    BlindedMiniBlock bid               = 1;
    bytes        cluster_signature = 2; // threshold BLS signature from the DVT cluster
}

// Relay -> Builders/Users: broadcast after each round
message MiniBlockHeader {
    uint64 slot             = 1;
    uint64 mini_block_index = 2;
    bytes  mini_block_root  = 3; // hash(SignedBlindedMiniBlock[i])
    bytes  state_root       = 4;
    bytes  state_diff       = 5;
    uint64 gas_used         = 6; // gas consumed by this accepted mini-block
}

// Builder -> Relay: bid for the final full-block auction.
// The relay verifies the mini-blocks consistency by their placements and the full execution_payload list.
// The relay does not forward execution_payload or mini-block placements to the cluster.
message FinalBlockBid {
    uint64 slot                          = 1;
    uint64 bid_value                     = 2;
    bytes  execution_payload             = 3; // full ExecutionPayload; relay later creates blinded header for cluster
    repeated MiniBlockPlacement placements = 4; // one per accepted mini-block, in chain order
    bytes  builder_signature             = 5; // builder's signature over fields 1–4
}

// Declares where mini-block i's transactions are placed in the final block.
// The relay verifies this against execution_payload and the stored SignedBlindedMiniBlock headers.
// Not forwarded to the cluster.
message MiniBlockPlacement {
    bytes  mini_block_root = 1; // hash(SignedBlindedMiniBlock[i]) — links placement to the signed header
    uint64 start_index     = 2; // s_i: declared starting position; relay cross-checks against stored k_j values
}

BlindedMiniBlock is a blinded bid forwarded by relays to the cluster. Following PBS conventions, the builder sends the full transaction list to the relay alongside this message; the relay keeps it private and the cluster only ever sees the blinded header.
BlindedMiniBlock.tx_root = BinaryMerkleRoot([keccak256(t_1), ..., keccak256(t_k)]) is a commitment to the ordered transaction sequence. Anyone holding the transaction list can verify it against this root; the relay uses it to enforce rule B1 (Section 5).
BlindedMiniBlock.gas_used carries no per-round gas. The relay tracks the cumulative gas_used across accepted mini-blocks in the slot and rejects any bid that would push the running total above Ethereum’s MAX_BLOCK_GAS. At finalization, the remaining headroom is available for T_extra.
BlindedMiniBlock.tx_count is the number of transactions k_i in this mini-block’s sequence. Together with the tx_count values of prior accepted mini-blocks, it allows any party to derive the starting offset s_i = sum_{j < i} k_j without needing the underlying transaction lists. This makes s_i reconstructible from the signed headers alone and is required for on-chain evidence in rule B2 (Section 5).
BlindedMiniBlock.builder_signature is the builder’s BLS signature over the signing root of all other fields in the message. The relay verifies this as part of bid validation. Post-hoc, any watcher can check whether the builder_signature embedded in a published SignedBlindedMiniBlock verifies against the bid’s own fields — an invalid signature is evidence that the relay altered the bid before forwarding it to the cluster.
MiniBlockHeader is the relay broadcast after each round, carrying the state diff so builders can immediately start constructing bids for the next window.
FinalBlockBid extends the standard PBS full-block bid with MiniBlockPlacement entries declaring where each mini-block’s transactions sit in the final block. The relay verifies these placements against the ExecutionPayload and stored headers (see Section 3.3); they are not forwarded to the cluster.
FinalBlockBid.builder_signature is the builder’s BLS signature over fields 1–4, committing the builder to a specific payload and set of placements. A FinalBlockBid whose placements are inconsistent with the committed tx_root_i values is evidence of builder misbehavior under rule B2 (Section 5).

2.3 Protocol

Mini-block auction rounds

The following steps repeat for each mini-block window i:

Builders construct a candidate partial payload against the execution state produced by all previously accepted mini-blocks (when i > 0). Each builder sends the full transaction list to one or more relays, together with a BlindedMiniBlock committing to that list via tx_root and state_root. The transactions are held privately by the relay — the cluster never sees them at this stage, mirroring how PBS works today.
Relays validate incoming bids — verifying tx_root and state_root against the submitted transactions, checking that parent_mini_block_root matches the last accepted mini-block, and rejecting any bid whose gas_used disagrees with the cost of executing the revealed transactions or whose gas_used would push the slot’s cumulative accepted gas above MAX_BLOCK_GAS — and forward the highest-value valid blinded BlindedMiniBlock to all DVT cluster operators.
DVT Cluster operators run consensus on the received bids. The bid selection rule mirrors PBS: highest value wins, subject to validity against the known prefix. Once threshold agreement is reached, the cluster returns a SignedBlindedMiniBlock to the relays.
Relay broadcasts the MiniBlockHeader (containing state_diff and state_root) to all builders. From this point, builders can start constructing bids for window i+1. In parallel, the winning relay broadcasts the full transaction list for that round, signed over keccak256(T_i || mini_block_root) so any recipient can verify the reveal authenticates against the committed tx_root_i in the signed header.
Repeat from step 1 for window i+1.

Full-block phase

Once all M mini-block windows are complete at T=0, the protocol transitions to the full-block phase, which is identical to a standard PBS proposal: relays immediately begin forwarding FinalBlockBids and the cluster selects and signs the best bid. Timing game behaviour is fully preserved and left to the cluster’s discretion, exactly as it is for validators today.

Builders assemble the full ExecutionPayload by prefixing the transaction sequences from all accepted mini-blocks in order, optionally followed by additional transactions filling remaining block capacity. Participation requires having received and verified all transaction list reveals from the mini-block rounds. Builders submit the full payload along with a MiniBlockPlacement per accepted mini-block — each declaring the mini-block’s starting index s_i in the final transaction list (see Section 3.3).
Relay verifies the placements — confirming that each committed tx_root_i matches the transactions at its declared position range in B — and, if all checks pass, forwards only the blinded ExecutionPayloadHeader to the cluster. The placements are not forwarded.
DVT Cluster receives the blinded header. Mirroring standard PBS, the cluster does not independently verify the placements — it trusts the relay to have performed this check, in the same way a standard PBS proposer trusts its relay. The cluster signs the BlindedBeaconBlock.
Relay assembles the signed BeaconBlock and propagates it to the Ethereum network.

2.4 Sequence Diagram

sequenceDiagram
    autonumber
    participant B as Builder
    participant R as Relay
    participant C as DVT Cluster

    note over B,C: Mini-block window i (repeated M times)

    B->>R: transactions + BlindedMiniBlock (tx_root, state_root, bid_value)
    R->>C: BlindedMiniBlock (blinded — best bid)
    C->>C: consensus on bid
    C->>R: SignedBlindedMiniBlock
    R->>B: MiniBlockHeader (state_diff, state_root) + transaction list reveal
    note over B: start building for window i+1 in parallel

    note over B,C: Finalization window

    B->>R: FinalBlockBid (ExecutionPayload + MiniBlockPlacements)
    R->>R: verify placements against tx_roots and B
    R->>C: BlindedBeaconBlock header (placements verified, not forwarded)
    C->>R: signed BlindedBeaconBlock

3. Block packing and submission to the Ethereum network

Mini-block auctions follow a commit-and-reveal pattern. During each round, the winning bid commits to a transaction sequence via tx_root, defined as BinaryMerkleRoot([keccak256(t_1), ..., keccak256(t_k)]) where [t_1, ..., t_k] is the ordered transaction list — without revealing the transactions themselves. This keeps orderflow private during the round: the cluster, other relays, and other builders see the effect of the mini-block on state via the state_diff, but not the exact content that produced it. The builder is cryptographically anchored to the committed transaction list.

3.1 Commitment chaining

Each SignedBlindedMiniBlock header contains a tx_root committing to the transactions of that round, and a parent_mini_block_root linking it to the previous signed header. Across a slot with M accepted mini-blocks, this forms a hash chain:

genesis (slot parent block root)
  └─ SignedBlindedMiniBlock[0]: tx_root_0, parent = genesis
       └─ SignedBlindedMiniBlock[1]: tx_root_1, parent = hash(SignedBlindedMiniBlock[0])
            └─ ...
                 └─ SignedBlindedMiniBlock[M-1]: tx_root_{M-1}, parent = hash(SignedBlindedMiniBlock[M-2])

The cluster’s threshold signature on each header is a binding commitment to both the transaction sequence for that round and the entire history of prior mini-blocks. Breaking the chain — e.g. inserting, reordering, or omitting transactions — is detectable by anyone holding the signed headers.

3.2 Transaction reveal

Once the cluster commits to a winning bid by signing a SignedBlindedMiniBlock, the winning relay immediately broadcasts the transaction list for that round — which it already holds from the builder’s original submission. Note that the relay cannot substitute a different transaction set at this point because the tx_root in the signed header cryptographically fixes the committed list — any deviation is detectable and slashable under rule B1 (Section 5).

3.3 Full block construction and consistency check

Let T_i = [t_{i,1}, ..., t_{i,k_i}] be the transaction sequence committed in SignedBlindedMiniBlock[i], with k_i transactions. Define s_i = sum_{j < i} k_j as the starting index of mini-block i in the final block (so s_1 = 0). The final block’s ordered transaction list is:

B = T_1 || T_2 || ... || T_M || T_extra

R = transactions_root is the Ethereum MPT root over B: keys are RLP(j), values are RLP(b_j), for 0 <= j < n.

What the builder computes and sends to the relay.

The finalization builder, holding all revealed T_i and its own T_extra:

Assembles B = T_1 || ... || T_M || T_extra and computes R = MPT_root(B).
Submits FinalBlockBid to the relay, carrying the full ExecutionPayload (including R and the full transaction list B) and one MiniBlockPlacement per accepted mini-block, each declaring mini_block_root and start_index = s_i.

What the relay verifies.

The relay holds the accepted SignedBlindedMiniBlock[i] headers and the full transaction list B from the ExecutionPayload. Each header carries bid.tx_count = k_i as a signed field, so k_i is a committed value derivable from the headers alone. The relay independently computes s_i = sum_{j < i} k_j from those signed k_j values. Before forwarding to the cluster, the relay performs the following checks:

Execute B against the prior state and verify the state_root in the ExecutionPayload. Verify that the total gas used by B does not exceed MAX_BLOCK_GAS.
For each mini-block i: verify mini_block_root == hash(SignedBlindedMiniBlock[i]) — confirms the placement refers to the correct signed header.
For each mini-block i: verify BinaryMerkleRoot([keccak256(B[s_i + j]) for j in 0..k_i]) == tx_root_i — confirms that the transactions at position s_i in B exactly match the commitment the cluster signed.

Check 3 is sufficient to establish consistency end-to-end: it simultaneously verifies the transaction content and its position in B. Only if all checks pass does the relay proceed. The relay then forwards only the blinded ExecutionPayloadHeader (containing R) to the cluster — the mini-blocks placements or transaction list are not forwarded.

What the cluster receives and signs.

The cluster receives the ExecutionPayloadHeader from the relay. The cluster does not independently verify the placements. Mirroring standard PBS, it trusts the relay to have completed these checks before forwarding the blinded header — the same trust relationship that governs standard PBS today, where a validator signs a blinded block without ever seeing the transaction content. The cluster signs the BlindedBeaconBlock header.

The consistency property established here is: the final block’s transaction list must contain, as an ordered prefix, the exact transaction sequences committed in all accepted mini-block headers — formally, b_{s_i + j} = t_{i,j} for all i and 0 <= j < k_i. The cluster holds signed commitments to both tx_root_1, ..., tx_root_M (from the SignedBlindedMiniBlock chain) and R (from the BlindedBeaconBlock). Relay accountability for this consistency guarantee is discussed in Section 5.

3.4 Non-delivery

As in standard PBS, it’s possible that a relay that wins a mini-block window fails to reveal its transaction list T_i. If the reveal arrives late but before finalization opens, it is still usable and the protocol absorbs the delay with no harm. If the reveal is still missing when the full-block phase opens, the slot is missed. Note that there’s no slashing for such timing event; enforcement follows the same reputational model that governs relays today, where consistent non-delivery results in loss of order flow.

Both variants are discussed in detail under case III in Section 5.

4. State advertisement to users and searchers

Users and searchers should be able to query for the current partial state of the in-progress block and simulate transactions on top of it before slot finalization. Relays participating in the mini-block protocol expose two complementary interfaces for this purpose.

Relay-assisted simulation. Following EthGas’s realtime API, relays extend familiar RPC methods to provide a partial in-slot execution view. This is the accessible path for most users without requiring local execution.

State-diff query. As a complementary interface, relays may expose the cumulative state_diff of all accepted mini-blocks in the current slot as a queryable endpoint. Searchers and users who prefer to simulate locally can apply the cumulative state_diff to their own state and run simulations independently.

5. Security

The mini-block layer builds on the PBS design and its trust assumptions without introducing a new trusted party or requiring changes to Ethereum consensus. Relays remain brokers between builders and the proposer-side cluster, the validator remains the accountable signer for everything that reaches the Ethereum network, and builders and relays see the same overall trust profile they see today in PBS, extended round-by-round across the slot.

However, the sub-slot commit-and-reveal structure creates misbehavior vectors and failure modes that standard PBS does not cover. The table below enumerates them; each is discussed in the remainder of this section.

#	Faulty scenario
I	No builder submits a valid bid in a mini-block window.
II	The cluster fails to produce a `SignedBlindedMiniBlock[i]` within the window (consensus latency overshoots or operators are partitioned).
III	The winning relay fails to reveal the committed transaction list, or reveals late.
IV	The cluster equivocates on `(slot, mini_block_index)` — signing two different bids for the same window.
V	The cluster signs `SignedBlindedMiniBlock[i]` with a `parent_mini_block_root` that does not link to `SignedBlindedMiniBlock[i-1]`.
VI	A builder reveals a transaction list whose Merkle root does not match the committed `tx_root`.
VII	A builder’s committed `state_root` or `gas_used` does not match the result of executing the revealed transactions against the prior state.
VIII	No builder produces a `FinalBlockBid` at finalization.
IX	The winning finalization relay goes silent (same failure mode as a standard PBS missed slot).
X	A builder submits a `FinalBlockBid` whose placements do not match the committed `tx_root_i` values, or whose total gas exceeds `MAX_BLOCK_GAS`.
XI	The cluster signs a `SignedBlindedMiniBlock` that pushes the slot’s cumulative accepted gas above `MAX_BLOCK_GAS`.
XII	The winning finalization relay publishes to Ethereum a block whose execution payload does not match the `FinalBlockBid` signed by the winning finalization builder.

The remainder of this section discusses each case and, where applicable, the slashing rule that enforces it. Slashing rules are grouped by the actor they target: C1, C2, and C3 concern the DVT cluster; B1 and B2 concern builders (assuming they post collateral as a precondition for participation). B1 covers the mini-block round phase, and B2 covers the finalization phase. Relay failures at the finalization step follow the same reputational enforcement model as standard PBS today and are not on-chain slashable.

I — No valid bids

If no valid BlindedMiniBlock arrives from any relay before window i’s deadline, the cluster reaches consensus on a canonical empty bid and produces a regular SignedBlindedMiniBlock[i] over it. The empty bid is defined as:

tx_root = BinaryMerkleRoot([]) = 0x0...0
state_diff = ∅
state_root = state_root of SignedBlindedMiniBlock[i-1] (i.e. the pre-state is unchanged)
bid_value = 0
parent_mini_block_root = hash(SignedBlindedMiniBlock[i-1]) (or the slot parent block root for i = 0)
builder_signature = 0x0...0

The cluster signs this header with its threshold BLS signature exactly as for a non-empty bid, broadcasts to relays, who then broadcast the corresponding MiniBlockHeader (with empty state_diff) so builders know the window closed cleanly and can begin constructing bids for window i+1 without waiting.

II — Cluster fails to produce SignedBlindedMiniBlock[i] within the window

If the cluster does not reach threshold agreement on a bid within window i’s deadline, the protocol’s rule is simple: relays and builders wait until the clusters outputs a decision. The cluster will continue running consensus and once it produces a valid SignedBlindedMiniBlock[i], the relay will broadcast the corresponding MiniBlockHeader and the protocol resumes from there.

This mirrors the behavior of standard PBS today. In regular Ethereum, if a DVT cluster fails to finish consensus on the block in time, the validator misses the slot — there is no magic fallback that forces a decision. The mini-block layer inherits exactly the same assumption at a sub-slot granularity: if the cluster is too slow to decide, the mini-block is delayed, and if it is never decided, nothing is signed.

The only visible effect is that subsequent windows have less time to run. If SignedBlindedMiniBlock[i] signs δ seconds after its window’s deadline, then window i+1’s budget shrinks from window_duration to window_duration − δ. However, later windows recover their full budget — the delay is absorbed once, not propagated. For example, with window_duration = 2s and a 500ms late signature for mini-block i: window i+1 effectively has 1.5s, and window i+2 is back to 2s.

Cross-rounds case: δ > window_duration. If the cluster is so late on mini-block i that its delay consumes the entirety of window i+1’s wall-clock slot, window i+1 has no time to run as a normal auction. In that case, as soon as the cluster unblocks from i, it detects expired windows and immediately starts consensus on i+1 with the empty bid (as defined in case I), catches up on the missed windows, and resumes normal auctioning from whatever window is next. The chain then shows SignedBlindedMiniBlock[i] (non-empty, late) followed by one or more empty SignedBlindedMiniBlock[i+1], ... until the pipeline is caught up to the current wall-clock position.

Builder-side optimization. Although the protocol itself does not require any speculative behavior, builders can optimistically start collecting bundles for window i+1 as soon as they submit their candidate BlindedMiniBlock[i], without waiting for MiniBlockHeader[i]. They adjust once the SignedBlindedMiniBlock[i] actually arrives: if the winning bid matches what they were building on, their work carries over; if it differs, they reconcile based on the announced state_diff. This is a local builder choice with no protocol impact — it simply hides some of the delay from the critical path when the cluster is marginally slow.

III — Winning relay fails to reveal the committed transaction list, or reveals late

The cluster has signed SignedBlindedMiniBlock[i] — committing to tx_root_i, state_root_i, and state_diff_i — and the winning relay is expected to broadcast the underlying transaction list T_i so that finalization builders can assemble the full block.

Variant III-a — Reveal arrives late but before finalization.

If T_i is broadcast after window i’s deadline but before the full-block phase opens, it is still usable. Subsequent windows absorb the delay in the same way as case II, though again builders can optimistically start the work for the next mini-blocks. No protocol action is required — T_i is incorporated normally, and the final block is assembled with the full M-mini-block prefix.

A question that arises here is whether builders for window i+1 can inadvertently duplicate a transaction that was in T_i. That’s where state-diffs come in hand. They cannot: builders construct window i+1’s payload against the post-T_i state announced in MiniBlockHeader[i].state_diff, and state_diff already increments the nonce of every sender that appeared in T_i. Any attempt to re-include a transaction from T_i — or any other transaction using one of those already-consumed (sender, nonce) pairs — is rejected by EVM validation at the relay (§3.3, step 1).

Variant III-b — Reveal never arrives, or arrives after finalization opens.

If T_i is not available by the time finalization must begin, the slot is missed. This is the PBS-parallel failure: in standard PBS today, if the winning relay goes silent after the validator signs the BlindedBeaconBlock, the validator does not produce a block for that slot and there is no on-protocol recourse. Mini-blocks inherit this behavior at a sub-slot granularity — if any winning relay fails to reveal in time, the slot is missed in the same way and for the same reason.

As with missed slots in PBS today, enforcement is reputational: a relay that consistently fails to reveal loses order flow. No slashing rule is introduced — purely withholding data, absent an equivocation, is hard to prove on-chain and is governed by the same bilateral/reputational model that governs relays today.

A value-preserving alternative to this rule — partial assembly, under which the slot still produces a block using only the revealed prefix — is discussed in the appendix as a design we considered but did not adopt for the main protocol, in the interest of keeping the protocol simple and the failure model aligned with PBS.

IV — Cluster equivocation on (slot, mini_block_index)

Enforced by slashing rule C1 (below).

V — Cluster signs SignedBlindedMiniBlock[i] with a parent_mini_block_root that does not link to SignedBlindedMiniBlock[i-1]

Enforced by slashing rule C2 (below).

VI — Builder reveals a transaction list whose Merkle root does not match the committed tx_root

Enforced by slashing rule B1 (below).

VII — Builder’s committed state_root or gas_used does not match the result of executing the revealed transactions

Not slashable on-chain. Relays execute the tx list and verify both state_root and gas_used before forwarding a bid to the cluster (§2.3 step 2), so bids with a mismatched state_root or gas figure are rejected at that point and never become a SignedBlindedMiniBlock. If such a bid does reach the cluster, responsibility lies with the relay — see Relay consistency accountability below.

VIII — No builder produces a FinalBlockBid at finalization

If no builder submits a FinalBlockBid before the finalization deadline, the cluster has nothing to sign as a BlindedBeaconBlock and the slot is missed. This is the PBS-parallel failure: in standard PBS, if no builder delivers a block in time, the validator either misses the slot or falls back to local execution — and without the latter in scope here, mini-blocks inherit the former.

In practice the scenario is narrow. By the full-block phase all T_i reveals have either arrived (no case III-b firing) or have not, in which case the slot was already missed under III-b; so VIII only meaningfully triggers when every reveal succeeded but no builder submits an assembly. A builder in that position has everything needed to assemble B and a natural economic incentive to submit (even a zero-bid assembly realizes T_extra and the proposer tip), which is why the situation is rare in practice.

IX — Winning finalization relay goes silent after receiving the signed BlindedBeaconBlock

Once the cluster signs the BlindedBeaconBlock, the winning relay is expected to publish the full block to Ethereum (§2.3, finalization step 4). If it stays silent, the slot is simply missed. This is the standard PBS missed-slot failure mode; absence-of-publication has the same proof problem as case III-b and is left to reputational enforcement. The SignedBlindedMiniBlock[0..M-1] headers for that slot are orphaned, analogous to partial assembly (Appendix).

X — Relay forwards a final block whose placements do not match the committed tx_root_i values, or whose total gas exceeds MAX_BLOCK_GAS

Enforced by slashing rule B2 (below).

XI — Cluster signs a SignedBlindedMiniBlock that pushes the slot’s cumulative accepted gas above MAX_BLOCK_GAS

Enforced by slashing rule C3 (below).

XII — Winning finalization relay publishes a block whose execution payload does not match the FinalBlockBid signed by the winning finalization builder

This case is not a viable attack. The cluster signs the BlindedBeaconBlock, which contains the ExecutionPayloadHeader — including block_hash and transactions_root, which cryptographically commit to the exact transaction content of the execution payload. If the relay were to publish a different execution payload, Ethereum nodes would reject the block signature as invalid. The relay is therefore bound to publish exactly the execution payload used to construct the blinded header that it presented to the cluster.

Cluster slashing rules

C1 — Mini-block equivocation

The cluster signs two SignedBlindedMiniBlock messages for the same (slot, mini_block_index) with different bids.

Evidence: Two SignedBlindedMiniBlock messages M and M' such that:

M.bid.slot == M'.bid.slot
M.bid.mini_block_index == M'.bid.mini_block_index
M.bid != M'.bid
Both M.cluster_signature and M'.cluster_signature are valid threshold BLS signatures under the cluster’s public key

This is directly analogous to Ethereum’s proposer equivocation slashing condition. Because the evidence is two BLS-signed objects verifiable on-chain, this rule can be enforced by an SSV slashing contract without any additional execution context.

C2 — Chain-break

The cluster signs a SignedBlindedMiniBlock[i] whose parent_mini_block_root does not equal hash(SignedBlindedMiniBlock[i-1]) — effectively forking the mini-block history mid-slot.

Evidence: Two consecutive SignedBlindedMiniBlock messages SignedBlindedMiniBlock[i-1] and SignedBlindedMiniBlock[i] with valid cluster signatures, where SignedBlindedMiniBlock[i].bid.parent_mini_block_root != hash(SignedBlindedMiniBlock[i-1]).

It is a weaker form of equivocation: rather than signing two conflicting headers for the same index, the cluster breaks the hash link between consecutive indices.

C3 — Cumulative gas violation

The cluster signs a SignedBlindedMiniBlock that pushes the slot’s cumulative accepted gas above MAX_BLOCK_GAS. The cluster holds the signed headers for all prior mini-blocks in the slot and can compute the running total before signing — this is a simple summation of bid.gas_used fields across the chain of SignedBlindedMiniBlock headers it has already committed to.

Evidence: The full chain of SignedBlindedMiniBlock[0..i] headers with valid cluster signatures, where sum(SignedBlindedMiniBlock[j].bid.gas_used for j in 0..i) > MAX_BLOCK_GAS.

Same computational class as C1 and C2: no execution context, no reveal dependency, enforceable on-chain from the signed headers alone.

Builder slashing rules

B1 — tx_root mismatch

A builder provides a transaction list to the relay whose Merkle root does not match the tx_root committed in the accompanying BlindedMiniBlock. The relay detects this immediately upon receiving the bid — before forwarding anything to the cluster — and can slash the builder’s collateral bilaterally.

Evidence: The builder’s BlindedMiniBlock (containing bid.tx_root and builder_signature) and the transaction list submitted alongside it, where BinaryMerkleRoot([keccak256(t_1), ..., keccak256(t_k)]) != bid.tx_root. This check requires no execution — it is a pure Merkle root computation. No cluster involvement is needed; enforcement is relay-side against builder collateral.

If the relay is negligent and forwards the bad bid to the cluster anyway, the mismatch remains provable after the fact: once the relay broadcasts the transaction list for that round (§3.2), any party holding the list and the BlindedMiniBlock (or the SignedBlindedMiniBlock if the cluster signed it) can verify the mismatch and submit evidence to slash the builder. The bid.tx_root and builder_signature are present in both the signed and unsigned object, so cluster involvement is not required for the evidence to hold.

B2 — Final-block placement inconsistency

A builder submits a FinalBlockBid whose placement declarations are inconsistent with the tx_root_i values committed in the corresponding SignedBlindedMiniBlock[i] headers, or whose total gas exceeds MAX_BLOCK_GAS. The builder had full knowledge of the SignedBlindedMiniBlock chain (including tx_root_i and tx_count values) at the time of submission, so an inconsistent FinalBlockBid is a provable builder commitment violation, enforceable against collateral the builder has posted with the relay — the same model as B1.

Evidence (placement mismatch): The full chain of SignedBlindedMiniBlock[0..i] headers with valid cluster signatures (each carrying bid.tx_count = k_j, so s_i = sum_{j < i} k_j is derivable from signed data alone); a single transaction t together with a Merkle inclusion proof showing t ∈ tx_root_i; the canonical Ethereum block for that slot, showing that t does not appear at its expected position within s_i..s_i + k_i − 1 in B; and the builder-signed FinalBlockBid whose builder_signature covers the inconsistent placements. Note that only one such transaction needs to be exhibited.

Evidence (total gas violation): The canonical Ethereum block for the slot and the builder-signed FinalBlockBid. The block’s gasUsed is public; if it exceeds MAX_BLOCK_GAS, the violation is self-evident from the builder’s signed bid.

Both variants are pure cryptographic / arithmetic checks, in the same computational class as B1.

Relay accountability

Relays sit at several trust points in the protocol: they validate incoming BlindedMiniBlocks before forwarding them to the cluster (§2.3), they hold and broadcast the committed transaction list after each accepted mini-block (§3.2), and they verify placement consistency when assembling the final block (§3.3). The protocol inherits the same trust model for relays as standard PBS: relay failures are governed by reputational enforcement, not on-chain slashing. This section summarizes which failures fall outside the slashing surface and why.

Faulty case n.º X — builder is slashable, relay negligence is not. When a relay forwards a builder’s FinalBlockBid with inconsistent placements without catching the error, the builder’s builder_signature over the bad placements is on-chain evidence — rule B2 targets the builder. The relay’s failure to verify is a reputational concern, not an on-chain slashable one.

Not provable on-chain. Two relay failures remain outside the slashing surface:

Bid-side state_root misvalidation (case VII): a relay forwarded a BlindedMiniBlock to the cluster without executing the tx list to verify state_root. Proving this requires re-executing the transactions against the known pre-state — either on-chain EVM re-execution, which is prohibitively expensive; an interactive fraud-proof game, which introduces multi-round protocol machinery; or a ZK validity proof, which adds heavy prover infrastructure.
Non-reveal of T_i (case III-b): proving that a relay did not broadcast a message by a deadline is not a cryptographic object — it requires witnesses or attestations signing “we did not observe a reveal from relay R by time T,” which opens a social/protocol layer the slashing contract does not naturally handle. Enforcement is reputational, same as standard PBS.

Future on-protocol paths. Bid-side misvalidation can be brought under on-chain enforcement via Trusted Execution Environments (TEEs), where the relay executes inside an attested environment and the cluster or a slashing contract verifies the hardware attestation — preserving the PBS privacy boundary while tightening the consistency guarantee. Alternatively, validity proofs of correct execution could achieve the same guarantee without TEE hardware dependencies. Non-reveal is a harder case: proving absence of a message without a trusted oracle remains an open question.

6. Conclusions

Mini-blocks extend the existing PBS pipeline with a sub-slot auction layer that lets the Ethereum ecosystem realize more of a slot’s value, gives relays and builders several top-of-block-shaped opportunities per slot instead of one, and gives users and applications a faster, richer view of the in-progress block — all without introducing a new trusted party, a separate block-building pathway, or changes to Ethereum consensus. The design fits naturally into the infrastructure relays and builders already operate, compensates the additional operational load through the surplus it creates, and leaves room for incremental hardening (e.g. equivocation slashing) as the protocol matures. It is also a natural substrate for further extensions: in particular, by adopting the preconfirmation-aware transaction type introduced in [2], the same pipeline can be extended to embrace L2 preconfirmations, based preconfirmations, and synchronous L1↔L2 composability, without re-architecting the relay interface.

References

[1] nuconstruct, “Second Thoughts: How 1-second subslots transform CEX-DEX Arbitrage on Ethereum”. ArXiv, 2026. [2601.00738] Second Thoughts: How 1-second subslots transform CEX-DEX Arbitrage on Ethereum
[2] L. Oshitani, “Based Preconfirmations with Multi-round MEV-Boost.” Ethereum Research, 2024. Based Preconfirmations with Multi-round MEV-Boost
[3] J. Drake, “Based rollups — superpowers from L1 sequencing.” Ethereum Research, 2023.
[4] J. Drake, “Based preconfirmations.” Ethereum Research, 2023.
[5] EthGas Realtime API Documentation. Realtime Ethereum | ETHGas.
[6] Flashbots Relay Specs — Builder-API registerValidator. Relay-API
[7] Ethereum Builder API Specification - GitHub. GitHub - ethereum/builder-specs: Specification for the external block builders. · GitHub

Appendix

Protocol alternatives

Peer-to-peer communication

A fully peer-to-peer communication layer was considered but introduces extra gossip delay, additional networking complexity, and peer management overhead; for relays the relevant requirement is timely authenticated message exchange with the proposer-side cluster, which a client-server model satisfies directly.

Per-duty registration

Periodic or per-duty advertisement was considered in place of long-lived registration but adds redundant coordination overhead for every single slot.

Centralized SSV-side coordinator

A centralized coordinator approach was considered as it could simplify the external interface, but would add a centralized trusted component that goes against the decentralization goals of the design and hurts the byzantine decentralization advantage of SSV. Still, the symmetric approach can be optimized depending on the underlying protocol. For example, for a leader-based consensus protocol, relays could alternatively dedicate communication initially to the current leader as a protocol-level optimization, without changing the default interface.

Sequential (non-wall-clock-anchored) mini-block windows

When handling case II (cluster fails to produce SignedBlindedMiniBlock[i] within the window), an alternative to the wall-clock-anchored catch-up rule described in Section 5 is to treat mini-block windows as sequential rather than as fixed wall-clock intervals. Under this alternative, window i+1 does not start at a pre-determined wall-clock time; it starts as soon as MiniBlockHeader[i] is broadcast. Each window runs for its full window_duration, regardless of how late the previous one signed.

The consequence is that the number of mini-blocks actually signed per slot becomes a variable: the protocol runs windows sequentially until either M have been signed, or remaining_slot_time < window_duration. In this model M is an upper bound — “at most M mini-blocks per slot” — rather than an invariant. The final block has the form B = T_1 || ... || T_k || T_extra with k ≤ M.

This design is attractive because it is linear and keeps every signed mini-block non-empty: under delay the slot simply hosts fewer mini-blocks, without the chain accumulating empty headers. The chosen design in Section 5 instead preserves M as a hard invariant for simplicity, at the cost of allowing strings of empty SignedBlindedMiniBlock headers when consensus is very late. The two approaches are essentially equivalent in the value they deliver to the proposer under failure — both degrade gracefully — and the choice between them is a matter of which invariant is more convenient for the rest of the pipeline and for proving protocol correctness in its initial phases.

Partial assembly on missing reveal (case III-b)

When handling case III-b (winning relay fails to reveal T_i by finalization), an alternative to missing the slot is partial assembly: the final block is built using only the mini-blocks whose reveals were observed in time. Concretely, if T_i is missing, the final block is assembled as B = T_1 || ... || T_{i-1} || T_extra, where T_extra is computed against the state after T_{i-1}, and no MiniBlockPlacement is emitted for any j ≥ i. SignedBlindedMiniBlock[j] headers for j ≥ i exist on record but are orphaned — they do not appear in the final Ethereum block.

An important cascade in this variant is that a missing reveal at position i orphans the entire downstream suffix i..M-1, not only mini-block i itself. This is because SignedBlindedMiniBlock[i+1] was built on top of the state produced by T_i: builders constructing window i+1’s payload saw MiniBlockHeader[i].state_diff and assumed T_i would be applied. Executing T_{i+1}, ..., T_M against pre-T_i state would fail EVM validation on nonces and balances. So partial assembly naturally truncates at the last fully-revealed mini-block.

This design is consistent with the slashing rules: none of C1, C2, B1, or B2 requires that every signed mini-block header be included in the final Ethereum block. The protocol-level invariant is instead that the final block be consistent with the signed prefix it claims to include — orphaned headers are structurally analogous to unincluded attestations, which are signed artifacts that exist but do not land on-chain. A validator signing a prefix that is later truncated by a missing reveal is behaving correctly: the BlindedBeaconBlock it ultimately signs references only the included prefix, which remains internally consistent with the SignedBlindedMiniBlock[0..i-1] headers.

The chosen design in Section 5 opts for the simpler “slot missed” rule because it keeps the failure model aligned with standard PBS (silent relay = missed slot, governed by reputational enforcement) and avoids introducing a relay-driven accountability surface over which mini-blocks are included. Partial assembly is strictly more value-preserving, and is the natural implementation path once relay collateral and partial-inclusion accounting are specified.

Block consistency alternatives

The protocol requires establishing that the transactions under each committed tx_root_i appear faithfully at their expected positions in the final block’s transactions_root R. The structural tension is as follows. tx_root_i is a binary Merkle tree over transaction hashes — BinaryMerkleRoot([keccak256(t_{i,1}), ..., keccak256(t_{i,k_i})]) — while R is an Ethereum MPT over full transaction bytes — MPT_root({RLP(j) -> RLP(b_j)}). Proving that these two commitments encode the same transaction content without revealing the transactions requires either a cross-commitment proof between the two structures or a trusted intermediary. The alternatives below each attempt to satisfy this requirement. Each has significant drawbacks, which is why the design in Section 3.3 instead pushes verification to the relay, where direct list comparison is possible.

Cluster-side verification (requires transaction reveal)

Define tx_root_i = BinaryMerkleRoot([keccak256(t_{i,1}), ..., keccak256(t_{i,k_i})]) (as in the main protocol). The relay forwards T_i and s_i to the cluster alongside the blinded header, together with MPT inclusion proofs π_{i,j} = MPT_proof(R, s_i + j, t_{i,j}) for each transaction.

MPT proofs are necessary here because the cluster only holds R — the root hash — and not the full transaction list B. Unlike the relay (which has B and can verify by direct comparison), the cluster needs proofs to check that T_i sits at the correct position under R. The cluster verifies:

BinaryMerkleRoot([keccak256(t_{i,1}), ..., keccak256(t_{i,k_i})]) == tx_root_i — confirms the revealed list matches the commitment.
MPT_verify(R, s_i + j, t_{i,j}, π_{i,j}) = true for all i, j — confirms each transaction sits at its expected position in R.

This scheme is sound and requires no new infrastructure. The fundamental problem is step 1: the cluster must receive the full transaction list T_i to recompute the Merkle root, violating the PBS privacy boundary. In a slot with M = 4 mini-blocks and k = 20 transactions each, the cluster receives all 80 transactions at finalization time.

Proof size per mini-block: k_i * O(log_16(n)) MPT nodes, roughly k_i * 3 * 500 bytes for n = 300. For k_i = 20: ~30 KB per mini-block, ~120 KB total. For a fraud proof only one counterexample position is needed: O(log k_i + log_16(n)) nodes, ~2 KB.

Transaction-private cluster verification

Both variants below define a hash-based auxiliary commitment that the cluster can verify without seeing transaction content. However, they share the same fundamental limitation: the cluster cannot independently confirm that the auxiliary commitment is consistent with R. Closing this gap requires either trusting the relay (which collapses into the model of Section 3.3) or a new Ethereum field (which requires an EIP). The two variants differ structurally but lead to the same conclusion.

Variant A — Auxiliary root of mini-block commitments. Define:

aux_root = BinaryMerkleRoot([tx_root_1, tx_root_2, ..., tx_root_M])

The builder includes aux_root in the FinalBlockBid. The cluster recomputes aux_root from the tx_root_i values it already holds — no transaction content needed — and verifies BinaryMerkleVerify(aux_root, i, tx_root_i, path_i) = true for each i. This is cheap: O(M log M) hashes. The gap is that aux_root encodes only the M mini-block roots, not R; the cluster cannot verify that aux_root and R reflect the same transactions.

Variant B — Hash-keyed MPT. Define an alternative transactions root where leaves hold transaction hashes rather than full transaction bytes:

R_hash = MPT_root({RLP(j) -> keccak256(RLP(b_j)) : 0 <= j < n})

The builder provides, for each mini-block i and offset j, a binary Merkle path ρ_{i,j} in tx_root_i and an MPT proof π_{i,j} in R_hash, both over hashes only. The cluster verifies both without ever seeing full transaction bytes. Proof size matches cluster-side verification but the privacy boundary is preserved. The gap is that R_hash is a new object not present in the standard ExecutionPayload; the cluster has no way to verify it is consistent with R.

Shared resolution. Both variants face the same two options for closing their respective gaps:

Relay attestation. The relay signs a binding between the auxiliary commitment and R (e.g. BLS_sign(keccak256(aux_root || R || slot))). The cluster verifies the signature and trusts the relay for the link. This is functionally equivalent to the design in Section 3.3 — the relay is the trust anchor — and adds structured commitment objects without changing the underlying trust assumption.
Execution client integration (EIP). Add the auxiliary commitment (miniblocks_root or tx_hashes_root) as a first-class field to the ExecutionPayload header, computed by the execution client alongside transactions_root. Since both derive from the same transaction list in the same client, consistency is trivially guaranteed. Requires an EIP and execution client coordination.

Continuous relay bids

The round structure in §2.1 commits to fixed window_duration intervals (default 2s). In practice, relays may emit bids continuously as order flow arrives, and a more faithful protocol would ingest bids as they come rather than batching them into windows. The chosen design trades some of that fidelity for a rigid schedule that keeps the consensus layer simple and the slot timing predictable. The directions below sketch how the window rigidity could be relaxed in future protocol versions. This section complements the sequential-windows alternative, which addresses wall-clock slippage under consensus delay, though here the target is closer tracking a continuous bidding.

Shorter windows. The simplest refinement keeps the current protocol and only shrinks window_duration — for example to 0.5s with a correspondingly larger NUM_MINIBLOCKS — so that the round cadence samples the bid stream more finely. At this granularity, operators are also expected to decide not to commit when no attractive bid is standing, letting the slot skip ahead rather than forcing a commitment every fixed interval. The bound on this direction is DVT consensus latency: each window must accommodate one consensus instance, requiring an optimized consensus algorithms for that matter.

Input-triggered consensus. A deeper direction removes the fixed cadence and lets the protocol itself decide when to run a consensus round, triggered by the arrival of a sufficiently valuable bid rather than by a pre-determined clock tick. Rather than opening and closing auction windows at fixed instants, the cluster would begin deciding whenever the bid stream crosses a value or timing condition. This reshapes the consensus layer substantially — most existing consensus protocols assume a predictable start-of-round time — and sits in open research territory.

Leader-chosen proposal timing. A narrower path keeps a standard leader-based consensus protocol with a known start-of-round time but lets the leader choose, inside its round, when to emit the proposal message. The leader waits for better bids up to the latest safe point inside the round, while the overall schedule remains deterministic from the outside. This is compatible with most existing leader-based protocols and introduces strictly less machinery than input-triggered consensus.

Each of these directions trades some protocol simplicity for a closer fit to the continuous nature of relay bidding. None is adopted in the chosen design (for the sake of simplicity for the initial version) but they are the natural paths along which the 2-second window could be relaxed as consensus and networking improve.