Slot-Based Transaction Ordering
Understand why we use slot-based transaction ordering
Radius introduces a slot-based transaction ordering model in Lighthouse.
A slot is a unit of transactions, comprising searcher bundles (from Lighthouse) and user transactions (from SBB). Slot-based ordering runs independently of block times, managing the ordering of transactions within each slot.
Once slots are submitted to the mempool and included in a block, they are executed in a predetermined order defined by the slot. This model guarantees deterministic outcomes and eliminates risks of arbitrary reordering.
Slot Structure
Each slot is divided into two segments:
Top-of-Slot (Priority Txs): Arbitrage bundles from searchers via Lighthouse auctions. These transactions backrun previous slots and capture market opportunities.
Bottom-of-Slot (User Txs): User transactions via SBB, protected from manipulation such as frontrunning or sandwich attacks.
This two-tier structure ensures value-capturing arbitrage and user activity coexist under fair, transparent rules.
Why slots, not blocks?
Slot ordering guarantees deterministic execution. It solves key limitations of block-based ordering:
Network Congestion: Fixed block intervals risk hitting gas or size limits during transaction surges, preventing committed transaction orders from being included in the block.
Communication Delays: Latency between rollups and external systems (e.g., SBB or Lighthouse) disrupts timely block production.
External Failures: Failures in external systems (such as SBB or Lighthouse) can cascade into the transaction pipeline, impacting how the rollup processes transactions.
Last updated