Reserved Blockspace
Reserved blockspace lets an OP Stack chain set aside a configurable share of every block for eligible transactions, so latency-sensitive transactions get predictable inclusion under congestion. When reserved demand is light, the unused space is ceded to normal traffic, so no blockspace is wasted.
During blockspace demand spikes, latency-sensitive transactions are otherwise at the mercy of the priority fee market: pay enough and you're in, pay too little and you wait. Some use cases, like the stake-based ordering experiment, need predictable inclusion rather than best-effort.
Why does reserved blockspace exist?
It closes a gap the stake-based ordering experiment exposed: eligible transactions above the reserved cap were dropped from the current block entirely, even though most of the block sat open to them. Reserved blockspace keeps that remaining space usable instead of stranding it.
The stake-based transaction ordering experiment on op-sepolia let senders stake OP for top-of-block access, and it proved the demand was real. But excess eligible transactions were simply dropped: they could land next block, not in the remaining 80% of the current one. It is hard to call a transaction high priority when 80% of the block is off limits to it.
How does reserved blockspace work?
Every block is split into two tiers. The Reserved tier sits on top and gets up to R% of the block's gas, open only to transactions that satisfy the active eligibility rule. The General tier below is open to everyone, ordered by priority tip. R is the single lever an operator pulls to size the reserved region.
The predicate that decides which transactions qualify for the Reserved tier (for example, the sender has staked) is a separate configurable surface, covered below. What happens at the cap depends on demand and one toggle, spillover:
Situation | Behavior |
|---|---|
Reserved demand below the cap | Unused reserved gas is ceded to the General tier. No blockspace is wasted on an empty privileged region. |
Reserved demand exceeds the cap, spillover on | Excess transactions compete in the General tier on priority tip alone. They lose the reserved privilege but can still land if they outbid General contenders. |
Reserved demand exceeds the cap, spillover off | Excess transactions wait for the Reserved tier of the next block. |
Eligible transaction too big for the remaining Reserved space | It spills over (if enabled), and smaller eligible transactions behind it may still fit. Same behavior as normal block building. |
The property worth holding onto: blockspace stays maximally available wherever reserved demand lands. Light demand does not strand blockspace, and heavy demand does not drop transactions that could otherwise be included.
Is reserved blockspace one feature or a framework?
It is a framework. The two-tier structure is fixed, but the rule that decides which transactions qualify for the Reserved tier is a pluggable surface. New use cases plug in there without touching the block-building path.
Two eligibility rules ship today:
Stake-based: a transaction qualifies if its sender has staked OP in a designated contract. This is the rule powering the stake-based ordering experiment.
From-address allowlist: a list of reserved senders, which can extend to gating on destination address and/or function selector.
The block-building machinery is indifferent to which rule is in use. A chain operator who wants to prioritize a different class of traffic defines a new rule and configures the builder to use it. The hard parts, two-tier sorting, spillover management, nonce handling, and the testing harness, are built once and reused.
What makes reserved blockspace hard to build?
Two problems hold most of the complexity: spillover and testing.
Why is spillover hard?
Spillover is hard because the two tiers sort by different criteria, the Reserved tier by eligibility and the General tier by tip, but the mempool hands us a single priority-sorted stream that mutates while we read it.
Two subtleties make it tricky. First, sorting: the mempool stream is not static. New transactions arrive while we build, slotting in by priority, and reading a transaction unlocks the next-nonce transaction from the same sender. The stream changes underneath us from both directions. Second, overflow: the stream is one-shot, read start to finish with no moving backward. When an eligible transaction overflows the Reserved cap, we cannot just put it back to compete later.
The fix is a parallel spillover queue ordered by tip. When an eligible transaction overflows the cap, we re-prioritize it by tip and place it in that queue. During General-tier construction, at each step we compare the top of the mempool iterator against the top of the spillover queue and take the better of the two, handling nonce-ordering edge cases like unlocked descendants of already-included transactions. The guarantee this preserves: if your reserve-eligible transaction would have made it into a block without reserved blockspace, it still makes it in with reserved blockspace on, without breaking eligibility ordering inside the Reserved tier.
Why is testing hard?
Testing is hard because the builder is stateful and concurrent: the mempool stream is live, transactions arrive mid-build, and correctness is defined by ordering invariants that interact in subtle ways. Deterministic tests catch the easy bugs; the interesting ones only surface under realistic load.
We covered the core logic with the usual deterministic unit, integration, and acceptance tests. The meaningful validation happened on a live devnet: we stood up the full stack, funded accounts to submit a realistic mix of Reserved-eligible and General transactions, and pushed hundreds of transactions per second of randomized traffic to saturate blocks. We reviewed the resulting blocks manually and programmatically to verify the ordering invariants held.
One subtlety: some invariants look violated when they are not. A transaction that enters the mempool mid-build can legitimately appear in a position that looks out of order against a static snapshot taken before the build began. The verification logic has to account for the live stream, not just the pre-build state, or it flags correct behavior as a bug.
How does reserved blockspace perform under congestion?
Under sustained congestion, eligible transactions get predictable inclusion (about 1.6s at p99) while non-eligible transactions climb past 10s. Reserved blockspace replaces the tip-market scramble with a predictable lane for the traffic that needs it.
Setup: we flooded a private testnet with 300 tx/sec using Contender across 20 senders, enough to saturate blockspace. Each transaction used about 200k gas, matching the median gas usage of typical OPM transactions. We ran with reserved blockspace on (R = 20, stake-based eligibility), with only a single sender eligible. Flashblocks were enabled at 250ms intervals with a 60M gas target per block, chosen to consistently fill blockspace and induce sustained congestion.
p50 | p95 | p99 | |
|---|---|---|---|
Eligible | 733ms | 1,629ms | 1,634ms |
Non-eligible (avg) | 6,364ms | 9,609ms | 10,355ms |
Latency under congestion. A grouped horizontal bar chart of this data is drafted as latency_under_congestion.png in the workspace; once added, caption it: "Under sustained congestion (300 tx/s, R=20, stake-based eligibility), eligible transactions get predictable sub-1.7s inclusion while non-eligible transactions climb past 10s at p99."
What is the status of reserved blockspace?
Reserved blockspace is live on OP Mainnet with the stake-based ordering experiment. We will watch how it behaves under real traffic and iterate on the implementation and eligibility rules from there.
FAQ
What is reserved blockspace?
Reserved blockspace is a block-building framework that sets aside up to a configurable R% of every block for transactions meeting an eligibility rule, giving them predictable inclusion under congestion while ceding any unused space to normal traffic.
Who is reserved blockspace for?
It is for latency-sensitive use cases that need predictable inclusion rather than best-effort, for example the stake-based ordering experiment, where senders stake OP for top-of-block access.
What happens to unused reserved space?
When reserved demand is below the cap, the unused gas is ceded to the General tier, so no blockspace is wasted on an empty privileged region.
What is spillover?
Spillover is a configurable toggle. When on, eligible transactions above the reserved cap compete in the General tier on priority tip. When off, they wait for the next block's Reserved tier.
Does reserving blockspace waste capacity?
No. Light reserved demand does not strand blockspace, and heavy demand does not drop transactions that could otherwise be included, so blockspace stays maximally available.
Is reserved blockspace live?
Yes. It is live on OP Mainnet with the stake-based ordering experiment, with implementation and eligibility rules iterating from real traffic.
Glossary
Reserved tier: the top portion of a block, up to
R%of gas, open only to transactions that satisfy the active eligibility rule.General tier: the rest of the block, open to all transactions and ordered by priority tip.
Eligibility rule (predicate): the pluggable condition deciding which transactions qualify for the Reserved tier, for example a staked sender or an allowlisted from-address.
Spillover: a toggle determining whether eligible transactions above the cap compete in the General tier on tip (on) or wait for the next block (off).
R: the single operator-set lever sizing the reserved region as a percentage of block gas.