# Flashblocks: a receipt before the block exists

> Base's flashblocks return a transaction receipt before its block is sealed. What a preconfirmation is, how to spot one, and why its fee can change.

Source: https://hashspan.dev/learn/flashblocks-preconfirmations

## Short answer

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.

Figure: One Base Sepolia transaction read twice: the receipt right after send comes from the pending block with a zero block hash and an L1 fee of 5,831,617,727 wei, the sealed receipt four seconds later has the real block hash and 19,224,330,220 wei, and hashspan takes the fee from the sealed one.

## 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](https://docs.base.org/base-chain/flashblocks/apps)). 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](https://hashspan.dev/learn/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](https://github.com/base/base/issues/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.

**In a hashspan trace:**
Since 0.8, `@hashspan/viem` treats a receipt with a zero or null block hash as a preconfirmation ([ADR 0024](https://github.com/selimaytac/hashspan/blob/main/docs/adr/0024-sealed-receipt-fees.md)). The `confirm` span ends when the preconfirmation arrives, so its duration is the wait your code saw. Its fee attributes come from the sealed receipt, fetched off the caller's path for up to 30 seconds:

  - `blockchain.tx.l1_fee` and `blockchain.tx.fee`: from the sealed receipt
  - if no sealed receipt comes in time: the span keeps the preconfirmation's status and block, and records no `effective_gas_price`, `l1_fee` or `fee` rather than a wrong one

The project's test lab has a scenario for exactly this: it watches up to 50 transactions of other accounts on Base Sepolia and compares every confirm span with the sealed receipts of its block. Its results are on [testnet runs](https://hashspan.dev/docs/runs).

## 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.