A flashblocks preconfirmation is a receipt for a transaction the sequencer has ordered into the block it is still building. Base updates that pending block about every 200 ms, so a receipt can arrive well before the block is sealed. You can tell it apart by its block hash: all zeros. Its status and block number held in our samples; its L1 data fee sometimes did not.
What does the RPC return before the block is sealed?
Base builds each block in small pieces. The sequencer orders transactions into the block in progress and publishes it as the pending block about every 200 ms (Base flashblocks docs). A wallet or agent that asks for a receipt right after sending can get one from that pending block.
That receipt looks normal, with one exception. Here is one transaction on Base Sepolia, read twice, four seconds apart:
Field
Preconfirmation
Sealed receipt
blockHash
0x0000…0000
0x7aae3ebf…a605b
blockNumber
47635923
47635923
status
0x1 (success)
0x1 (success)
l1Fee
5,831,617,727 wei
19,224,330,220 wei
The zero block hash is the tell: the block it points to doesn’t exist yet.
Which fields can you trust?
We read six fresh receipts this way on 2026-10-03. Status and block number never changed. The L1 data fee changed in four of the six, once by more than three times.
So a preconfirmation answers “did it go through, and where?” quickly. It doesn’t reliably answer “what did it cost?”. A fee read from it can be wrong, and the error isn’t visible: the number looks like any other fee.
This has been reported to Base as a bug: preconfirmed receipts showing the l1Fee of an earlier transaction (base/base#5473). Until it is fixed, treat fees on a zero-hash receipt as provisional.
What does this mean for an agent?
Acting fast is fine. An agent can move on after a successful preconfirmation, which is the point of flashblocks.
Accounting needs the sealed receipt. Budgets, spend reports and cost per agent step should use fees from a receipt with a real block hash.
Durations measure what you waited for. A confirmation time based on the preconfirmation is the wait the caller saw, not the time to a sealed block.
FAQ
How do I know a receipt is a preconfirmation?
Its blockHash is 0x000…0. The pending block itself reports a zero hash too. A sealed receipt carries the real block hash.
Can a preconfirmed receipt change?
It can. In six receipts we read on Base Sepolia, status and block number matched the sealed receipt every time, but four had a different l1Fee. Read fees from the sealed receipt.
Should an agent wait for the sealed block?
For deciding what to do next, the preconfirmation is usually what makes flashblocks useful. For recording what the transaction cost, wait for the sealed receipt.
