Skip to content

Learn

Understanding finality

A Frame transaction is acknowledged in about a third of a second and final in about one. Those are two different promises, and every page of this explorer shows both. Here is what happens in between, and why only FINALISED is safe to act on.

~1 s from submission to irreversible finality
3–4 × 300 ms sub blocks settled per global block (4-3-3 cycle)
0 reorgs a sealed window can never be rewritten

One second, four steps

round 1round 2round 34 01· submitted 02· admitted 03· sealed 0 ms3006001000 ms
04· finalised global block
Every second, the freshest sub blocks settle together into one global block. 300 ms rounds do not divide the second evenly, so consecutive windows hold four, three, then three of them. A quorum of validator signatures seals the window; after that, no fork and no reorg can touch it.
  1. instant

    Submitted

    Your wallet signs the transaction and hands it to a lane in the sender’s continent. Nothing is promised yet.

    Explorer shows Pending
  2. ~300 ms

    Admitted

    A lane committee seals it into the next 300 ms sub block. Optimistic: instant feedback, not a guarantee it will execute.

    Explorer shows Admitted (not final)
  3. ~1 second

    Sealed in a window

    Three or four sub blocks make one second of chain time (the 4-3-3 cycle). Validators settle the window into a global block; a quorum of signatures locks it.

    The moment the outcome becomes permanent
  4. terminal

    Finalised

    Execution applies the transfer and writes a terminal receipt. The outcome can never change.

    Explorer shows Finalised

Two confirmations, two meanings

at ~300 ms

Admitted (not final)

The network has your transaction and a committee sealed it into a sub block. Great for UX: a wallet can show a spinner turning into a tick within 300 ms.

  • Optimistic, not guaranteed
  • Execution has not happened yet
  • Can still end up rejected

at ~1 second

Finalised

The window settled, execution ran, and a terminal receipt exists. This is the only state a merchant, bridge, or exchange should ever act on.

  • Value has actually moved
  • Immutable: no reorgs below a sealed window
  • The receipt records exactly what happened

What this means for you

Paying someone?
Treat ADMITTED as "sent" and FINALISED as "done". The gap is under a second, so waiting for the real thing costs almost nothing.
Building on Frame?
Trigger business logic only from FINALISED receipts. The tx page shows both moments: the admitted sub slot and the sealing block.
Watching the explorer?
A transaction can also finalise as rejected. That is a recorded outcome, not an error; the receipt says exactly why.