Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

Guaranteed blockspace

Stable v1.4.0 divides each block into lanes with separate gas budgets. Eligible priority transactions enter the VIP lane, so normal traffic cannot consume the capacity reserved for them.

Block lanes

The proposal and validation rules recognize three lane types:

  • VIP lane: carries transactions whose NonceKey is in the protocol-reserved range.
  • Transaction-type lane: reserves capacity for a configured transaction category.
  • Normal lane: carries standard transactions that do not match another configured lane.

Each lane has its own gas quota. A proposer fills the lanes within those limits, and validators enforce the same limits when they validate the proposed block.

This makes the reservation deterministic at the protocol level. It does not depend on a proposer voluntarily leaving space unused.

Two-dimensional nonces

An Ethereum account normally has one nonce sequence. If transaction 12 is missing or stuck, transactions 13 and later cannot execute.

A two-dimensional nonce, or 2D nonce, gives the account multiple independent sequences. NonceKey selects the sequence, and the transaction's nonce gives its position within that sequence.

For example, a payment account could use NonceKey = 1 for payroll and NonceKey = 2 for supplier settlements. A delayed payroll transaction would not block the supplier sequence.

The nonce-key space has three important regions:

  • NonceKey = 0 keeps the standard EVM-compatible nonce behavior.
  • The upper half of the uint64 range is reserved for protocol use. VIP membership is signaled through this range.
  • NonceKey = MaxUint64 marks an unordered transaction. TimeoutTimestamp provides its replay-protection deadline.

Stable carries these fields in CustomTx, transaction type 0x3F. Existing EVM transaction formats remain available, and the default nonce channel preserves their expected behavior.

Governance and activation

Governance controls the lane definitions and gas quotas through one MsgUpdateParams proposal. Accepted parameters take effect at the next block.

The defaults contain no reserved lanes. Until governance configures them, the chain behaves as one normal lane. This makes lane configuration additive to existing transaction processing.

Guarantee boundaries

VIP transactions receive deterministic next-block inclusion when all of these conditions hold:

  • The transaction is eligible for the VIP lane.
  • The lane has enough reserved gas for the transaction.
  • Validators follow the protocol.
  • The network remains synchronous enough for validators to receive the transaction before proposal.

Stable's mempool-less validator ingress model supplies VIP transactions to validators. Reserved proposal capacity then prevents normal traffic from displacing them.

Where to go next

  • Guaranteed settlement: See the payment pattern that depends on guaranteed blockspace: timed DvP settlement cycles with deterministic inclusion.
  • Network upgrades: Review the full v1.4.0 release and its rollout status.
  • Execution: Understand how Stable executes the transactions selected for each block.