Skip to main content
For a comprehensive introduction to how Flashblocks work, see the Flashblocks Overview.

​
Block Building

All Base blocks are built by the Flashblocks builder, meaning Flashblocks are always live. However, apps may choose not to rely on preconfirmations and can continue using standard RPCs without any Flashblocks integration.
No significant differences—both order transactions by fee. The main difference is timing: Flashblocks occur every 200ms instead of every 2 seconds.See Block Building for details.
The sequencer will not stop publishing Flashblocks unless an extreme circumstance makes running them unsafe. If this happens, preconfirmations are disabled network-wide and confirmations fall back to standard 2-second blocks. The sequencer continues operating normally.
Transactions with large gas limits (> ~18.75M gas, which is 1/10 of the ~187.5M block limit) may have longer inclusion times. This is because the builder allocates gas cumulatively—each Flashblock j can use up to j/10 of the total block gas limit. Large transactions can be included once enough cumulative capacity exists.See Gas Allocation for the full breakdown.
There’s no way to guarantee which Flashblock a transaction lands in, similar to how you can’t guarantee a specific block. To improve chances of quick inclusion:
  • Set a higher priority fee
  • Keep gas limits below ~18.75M (1/10 of block limit) to be eligible for Flashblock 1
The Flashblock builder uses a dynamic mempool that continuously accepts new transactions while building. This design prioritizes low inclusion latency over strict fee ordering.What this means:
  • Transactions are ordered by fee at the time they’re selected for inclusion
  • If a high-fee transaction arrives after a lower-fee transaction has already been committed to the current Flashblock, the high-fee transaction will appear after it (or in the next Flashblock)
  • This is expected behavior, not a bug—the builder doesn’t “reorder” already-committed transactions
Why this tradeoff?A “snapshot” mempool (freezing the transaction pool at the start of each block) would guarantee strict fee ordering but increase inclusion latency. The dynamic approach gets transactions included faster at the cost of occasionally “breaking” the expected priority gas auction (PGA) order.For traders and bots: If strict fee-based ordering is critical for your use case, be aware that arrival timing matters as much as fee amount within a 200ms Flashblock window.
Base targets a Flashblock reorg rate of < 0.1%. While reorgs are rare, applications should implement fallback logic for critical operations.Check current metrics at base.org/stats.
A reorg means a Flashblock was streamed as a preconfirmation but wasn’t included in the final block. This is rare due to architectural improvements in rollup-boost that prevent tail Flashblock reorgs. Apps should handle this possibility gracefully, but occurrences are minimal.

​
WebSocket

No. The raw Flashblocks WebSocket (wss://mainnet.flashblocks.base.org/ws) is reserved for infrastructure-to-node data syncing. Applications should not connect to it directly.Instead, query your RPC node or node provider (e.g., QuickNode, Alchemy, Infura, dRPC) for Flashblocks data via:
  • RPC API: Standard JSON-RPC methods with the pending tag
  • WebSocket subscriptions: Use eth_subscribe via your node provider’s WebSocket endpoint
See App Integration for implementation details.
Index 0 contains only system transactions and doesn’t use any gas limit. Indexes 1-10 are the actual Flashblocks that pull pending transactions from the txpool.
This is expected. When the previous block takes longer to build, the system compensates by allocating less time to the next block, resulting in fewer Flashblocks.
Transaction data in the diff.transactions array is Recursive Length Prefix (RLP) encoded.
The public WebSocket has a maximum connection limit. For production use, we recommend:
  1. Running your own Flashblocks-aware RPC node
  2. Using a third-party node provider with Flashblocks support

​
RPC

The public endpoint has explicit rate limiting. For production use:
  • Use a third-party node provider with Flashblocks support (Alchemy, Infura, QuickNode, dRPC)
  • Run your own Flashblocks-aware RPC node
The following methods are Flashblocks-enabled:
MethodUsage
eth_getBlockByNumberUse pending tag
eth_getBalanceUse pending tag
eth_getTransactionReceiptReturns preconfirmed receipts
eth_getTransactionByHashUse pending tag
eth_getTransactionCountUse pending tag
eth_callUse pending tag
eth_simulateV1Use pending tag
eth_estimateGasUse pending tag
eth_getLogsUse pending for toBlock
eth_subscribeStream Flashblock data in real-time (Beta)
base_transactionStatusCheck if transaction is in mempool (Beta)
See App Integration for full examples.

​
Node Setup

Use the Reth binary from the Base node repository. See the Enable Flashblocks guide for complete setup instructions.