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.8.0 divides each block into lanes with separate gas budgets. Eligible priority transactions enter the Enterprise lane, so normal traffic cannot consume the capacity reserved for them.

Block lanes

The proposal and validation rules recognize three lane types:

  • Enterprise lane: carries CustomTx transactions whose NonceKey has bit 63 set, except the unordered marker MaxUint64.
  • Transaction-type lane: reserves capacity for a configured transaction category.
  • Normal lane: carries standard transactions that do not match another configured lane.

maxBlockspaceGasWeight sets the percentage of the block gas limit reserved across all configured lanes. Each lane's weight sets its percentage of that reserved pool.

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. Setting bit 63 signals Enterprise-lane eligibility.
  • 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 v1.8.0 Mainnet upgrade seeded maxBlockspaceGasWeight = 20 and one Enterprise lane with weight = 50. It did not seed a transaction-type lane. Governance can change these parameters later.

The blockspaceLanes() query on the StableSystem precompile returns the active configuration. Both lane arrays are sorted by id in ascending order, with lower IDs matched first.

Guarantee boundaries

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

  • The transaction is eligible for the Enterprise 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 Enterprise RPC gateway supplies eligible 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.
  • StableSystem precompile: Query the active Enterprise and transaction-type lane definitions.
  • Network upgrades: Review the v1.8.0 release and activation details.
  • Execution: Understand how Stable executes the transactions selected for each block.