Applications should avoid hard dependencies on the WebSocket stream. RPCs provide stable behavior and automatic failover to regular blocks if Flashblocks go down.
For HTTP and WebSocket endpoint URLs, see the Flashblocks API Reference. Public endpoints are rate-limited — for production use, connect through a Flashblocks-enabled node provider such as Alchemy, QuickNode, or dRPC.
The gas budget is cumulative, not per-Flashblock. Each Flashblock unlocks an additional 1/10 of the total block gas:
Flashblock
Cumulative Gas Available
1
1/10 of block limit (~18.75M gas)
2
2/10 of block limit (~37.5M gas)
3
3/10 of block limit (~56.25M gas)
…
…
10
Full block limit (~187.5M gas)
Unused gas carries forward. If Flashblock 1 only uses 0.3/10 of gas, Flashblock 2 can use up to 1.7/10 (the cumulative 2/10 limit minus what’s already been used).
Implications for large transactions:
Transactions exceeding 1/10 of block gas (~18.75M) may not land in the first Flashblock — they wait until enough cumulative capacity exists.
There is a separate max gas limit per transaction on Base, distinct from Flashblock capacity.
If confirmation speed matters, keep individual transactions under ~18.75M gas to maximize the chance of inclusion in the earliest Flashblock.
Base targets a < 0.1% Flashblock reorg rate — meaning a preconfirmation was streamed but not included in the final block. This is rare, but apps should account for it.
Implement fallback logic. Treat preconfirmations as strong signals, not guarantees. For critical operations, confirm against finalized block data. Check live reorg metrics at base.org/stats.
If Flashblocks become unavailable, the sequencer continues operating normally and confirmation falls back to standard 2-second blocks. Build your app to handle both cases gracefully.