Learn · 04
Blocks, finality and pre-confirmation
Who produces blocks, when a transaction becomes final, and what a 20 ms pre-confirmation does and doesn't promise.
Checked against official docs on 2026-10-29
StatusDevnet design. All timings are targets from the official docs, not public-network measurements.
Who makes the blocks
- Up to 64 validators, who stake BNB.
- The active set is chosen once a day, ranked by stake.
- Validators take turns: each produces 16 blocks in a row, then the next takes over.
- If the scheduled validator misses its slot, another steps in after a short, predictable delay.
When is a transaction final?
Validators sign the order of each block using BLS signatures. Once two-thirds of them have signed, the order is locked in. In the common case a block is justified one block later and finalized two blocks later, which the docs estimate at roughly half a second.
Future targetBlock interval of 200 ms and sub-second finality are stated as latency targets. The docs also note these are chain parameters that can change.
Pre-confirmation, explained simply
Before a block is even finished, the validator building it streams small signed sub-blocks. If your transaction appears in one, you learn in about 20 ms that the validator has committed to including it at a specific position.
Think of a waiter saying "order received". It's useful and fast, but your meal isn't on the table yet.
The confirmation ladder
| Stage | Roughly when | Can it be reversed? |
|---|---|---|
| Pre-confirmed | ~20 ms | Yes, it can be revoked |
| Ordered | ~1 block | Not yet final |
| Order-finalized | 1 to a few blocks | The order is irreversible |
| Executed | Shortly after ordering | The result is known locally |
| Execution-finalized | After the result is committed and finalized | Final |
Confirmed by official docsOfficial docs describe pre-confirmation as a best-effort, revocable promise about ordering. It is not execution and not finality, and it does not say whether the transaction will succeed. Irreversible actions should wait for execution finality.
Limits worth knowing
- A pre-confirmation is lost if the validator fails before finishing its turn.
- It covers ordering only, not whether the transaction succeeds.
- Apps must handle revoked pre-confirmations.