How long until a stablecoin transfer is final?
$ txfinality measure --chain solana --runs 20 ✓ 20 of 20 transfers reached finalized · 18 Oct 2026 21:18 UTC · srv2, Falkenstein DE · rpc solana-mainnet.infura.io slowest: confirmed 1.1 s · finalized 8.1 s · 1 USDC each, one at a time levels: processed 1.1 s → confirmed 1.1 s → finalized 8.1 s saved runs/solana/2026-10-18T2118Z.json
"Confirmed" is what wallets show; "finalized" is the rooted slot, about thirty-two slots later, which the docs call about thirteen seconds. Both are real, and they are seconds apart.
A block the cluster recognizes as finalized with maximum lockout, meaning it has reached the strongest confirmation state used by the network.
the chain’s docs ↗ · read 18 Oct 2026 · next read 18 Nov · why the figure differs ↗// measure/run.ts, watchOne — the loop that produced the numbers above while (t.failed === undefined && t.levels[final] === undefined) { if (performance.now() - from > capMs) return; const statuses = await driver.status([t.id]); const now = performance.now(); t.polls++; const s = statuses.get(t.id); if (s) { for (const level of reached(driver.levels, s.level)) { if (t.levels[level] === undefined) { t.levels[level] = Math.round(now - from) / 1000; say(log, ` ${level.padEnd(12)} ${t.levels[level]}s`); } } if (s.failed !== undefined) { t.failed = s.failed; say(log, ` failed on chain: ${s.failed}`); } } await sleep(pollMs); }Sub-half-second blocks and a finality vote two blocks later. The number to trust is the second one. The dollar here is USDT as Binance issues it on its chain (BSC-USD), which is what everyone on BNB Chain uses. Not measured yet.
With Fast Finality enabled (since the Plato upgrade), the chain is finalized within two blocks if ⅔*N or more validators vote normally. At the current block time of 0.45 seconds, this means finality is achieved in approximately 1.125 seconds.
the chain’s docs ↗ · read 18 Oct 2026 · next read 18 Nov · why the figure differs ↗levels: in a block 450 ms → fast finality 1.1 sThe EVM of an exchange chain: blocks every second, committed by HyperBFT, and no later level named. One level, and it is fast, if the docs are right. Not measured yet.
The HyperEVM consists of EVM blocks built as part of Hyperliquid's execution, inheriting all security from HyperBFT consensus.
the chain’s docs ↗ · read 18 Oct 2026 · next read 18 Nov · why the figure differs ↗levels: in a block 1.0 sA rollup: the sequencer answers in two seconds (and in 200 ms if you read its flashblocks), Ethereum makes it final about twenty minutes later. Which one you need depends on whom you are trusting. Not measured yet; the figures are the docs' own.
After roughly 2 minutes, a Base batch containing the transaction has been posted to Ethereum.
the chain’s docs ↗ · read 18 Oct 2026 · next read 18 Nov · why the figure differs ↗levels: in a block 2.0 s → posted to L1 2 min → L1 finalized 20 minSame shape as Base: instant from the sequencer, final on Ethereum's clock, a quarter of an hour. Not measured yet; the figures are the docs' own.
Hard finality—the `safe` and `finalized` tags—is inherited from the parent chain and is what makes a block reorg-proof.
the chain’s docs ↗ · read 18 Oct 2026 · next read 18 Nov · why the figure differs ↗levels: in a block 1.0 s → posted to L1 ? → L1 finalized 15 minBlocks come quickly, but a milestone is what makes them final, and the docs now put that at two to five seconds. The checkpoint to Ethereum comes later and is a separate matter. Not measured yet.
Milestones typically finalize a transaction within 2 to 5 seconds.
the chain’s docs ↗ · read 18 Oct 2026 · next read 18 Nov · why the figure differs ↗levels: in a block ? → milestone 5.0 sOKX's chain, now on the OP Stack with the AggLayer. One-second blocks; what final means on Ethereum, the docs do not yet say in numbers. Not measured yet.
Fast execution happens on L2 with 1-second block times.
the chain’s docs ↗ · read 18 Oct 2026 · next read 18 Nov · why the figure differs ↗levels: in a block 1.0 s → L1 finalized ?Accepted is final, the docs say, in about a second; the RPC's finalized tag points one step later, at the block whose execution results are themselves accepted. Not measured yet.
In Avalanche, acceptance/rejection are final and irreversible and only take a few seconds.
the chain’s docs ↗ · read 18 Oct 2026 · next read 18 Nov · why the figure differs ↗levels: accepted 1.0 s → settled ?A new chain made for stablecoins, with native USDC. Its docs promise finality in seconds and say the consensus design is still subject to change; the runs will say. Not measured yet.
Block finality is achieved in seconds with minimal communication overhead, and validator selection is driven by a simplified Proof of Stake system optimized for performance and predictable behavior.
the chain’s docs ↗ · read 18 Oct 2026 · next read 18 Nov · why the figure differs ↗levels: in a block ? → finalized ?A ledger closes every few seconds and a validated ledger is final; there is nothing after it. Old, simple, and it has not changed. Not measured yet: the driver is to be written; the figure is the docs' upper bound.
When the network agrees on the contents of a ledger version, that ledger version is validated , and its contents can never change.
the chain’s docs ↗ · read 18 Oct 2026 · next read 18 Nov · why the figure differs ↗levels: validated 6.0 sAn Arbitrum chain run by Robinhood. Its docs list no USDC or USDT, only Paxos's USDG, so that is the dollar this row would move. Final means Ethereum, minutes after posting. Not measured yet.
Full finality — your transaction inherits Ethereum's security and is irreversible.
the chain’s docs ↗ · read 18 Oct 2026 · next read 18 Nov · why the figure differs ↗levels: in a block 1.0 s → posted to L1 ? → L1 finalized ?One level: committed is final, and the docs say it takes under a second end to end. Not measured yet: the driver is to be written; the figure is the docs' own.
A successful payment is final as soon as the transaction commits (BFT consensus, no extra block confirmations).
the chain’s docs ↗ · read 18 Oct 2026 · next read 18 Nov · why the figure differs ↗levels: committed 1.0 sA shard block is quick, and the masterchain block that seals it is what the docs call final: about a second, they say. One level counts, and it is fast. Not measured yet: the driver is to be written; the figure is the docs' own.
TON achieves transaction finality after a single masterchain block confirmation, typically within 1 second.
the chain’s docs ↗ · read 18 Oct 2026 · next read 18 Nov · why the figure differs ↗levels: in a shardchain block ? → in a masterchain block 1.0 sCircle's own chain, with USDC as the gas. Two states and nothing between: pending, then final, in under a second by its docs. Below the cut by stablecoins held today; listed because it is new and built for exactly this. Not measured yet.
Arc uses a two-state transaction model. A transaction is either pending (in the mempool) or final (included in a committed block). There is no intermediate "confirming" state and no concept of accumulating confirmations.
the chain’s docs ↗ · read 18 Oct 2026 · next read 18 Nov · why the figure differs ↗levels: final 1.0 s- not measured · final takes minutes by design
By design: a block every three seconds, but the docs call that pending; the only level Tron stands behind is "solidified", nineteen producers later, about a minute. Nothing in between to measure, so it is listed with its docs, like Ethereum.
Blocks become irreversible — solidified — once at least 19 distinct active SRs have each produced a block at that height or above, typically in about 1 minute.
the chain’s docs ↗ · read 18 Oct 2026 · next read 18 Nov · why the figure differs ↗documented: in a block 3.0 s → solidified 60 sBy design: a slot every twelve seconds, and a block is finalized once the checkpoint after its epoch's checkpoint is justified. The docs give the mechanism and the slot, not the minutes; the 6.4 and 12.8 minutes here are arithmetic on them. Faster finality is a research track, not a setting. Not measured.
Time in proof-of-stake Ethereum is divided into slots (12 seconds) and epochs (32 slots).
the chain’s docs ↗ · read 18 Oct 2026 · next read 18 Nov · why the figure differs ↗documented: slot 12 s → safe 6 min → finalized 13 minBy design: a block about every ten minutes, and six of them is the custom, which the docs themselves call somewhat arbitrary. Holds no major stablecoin, so the rule leaves it out; shown because it is the chain everyone asks about. Not measured.
6 confirmations: The network has spent about an hour working to protect the transaction against double spends and the transaction is buried under six blocks.
the chain’s docs ↗ · read 18 Oct 2026 · next read 18 Nov · why the figure differs ↗documented: one confirmation 10 min → six confirmations 60 min
What does “final” mean here?
The chain's own last level: once a transfer is there, nothing in the chain's rules can undo it. Each chain names it differently — Solana calls it finalized (the slot is rooted), Tron solid, a rollup is final when its batch is finalized on Ethereum. The row's details print the chain's own name for it.
The figure is the slowest of the 20 transfers in the latest run, sent one at a time, so the true time is at or below it — that is the ≤. Milliseconds under a second, seconds under two minutes, minutes above. A chain whose final takes minutes by design is listed with ≈ and its documented figure, and not measured.
What does “done” mean?
The earliest level at which the chain itself says the transfer will not be dropped — the level wallets show and exchanges act on. Solana's confirmed, a rollup's sequencer confirmation, a BNB block.
When a chain's final takes longer than three seconds but done is under three, done is printed in black with a green mark: on those chains a fast use case still works, if you accept the chain's word for done. When final itself is under three seconds, done is left quiet.
Why is a figure not what the chain's docs claim?
The docs describe the design: a block every so many milliseconds, final after so many blocks. The figure is the whole path as a sender meets it: signing on our machine, the RPC's queue, inclusion, the chain's own confirmation rule, and the RPC answering our poll — the slowest of twenty tries. The gap between the two is the point of the page.
Every row quotes the chain's claim beside its measurement, with the date the docs were read. When the two disagree by more than twice, the row says so and the change appears under what changed. If you think we measured the wrong level, run it yourself or report a correction.
Why these chains — and why is mine not here?
- 1Ranked by the USD stablecoins each chain holds, from DeFiLlama's public list of chains, read on the day of the run. The top 15 are in. The dollar figures are DefiLlama's, read the same day; the token's market cap is CoinGecko's.
- 2A chain whose own docs give no confirmation inside about ten seconds is shown in its place with the docs, and not measured.
- 3Bitcoin holds no major stablecoin and is out by the rule. It is shown anyway: it is the chain everyone asks about.
next below the cut · tempo 0.72 · monad 0.70 · arc 0.67 · op mainnet 0.60 · stellar 0.54 · mantle 0.54 · sui 0.50 · $bn stablecoins · 18 Oct 2026
A chain enters at the first run after it crosses the line, and leaves one run after it falls below. If yours holds more than the fifteenth chain here, it is on its way; if it does not, you can still run it yourself today with the same code, and we will gladly link your run.
Why are Ethereum and Bitcoin not measured?
Because their docs already answer the question, in minutes: Ethereum is final after two epochs, 12.8 minutes or more; Bitcoin's custom is six blocks, about an hour. Measuring them would only confirm the docs. They are listed in their place, with the docs, so that nobody has to ask where they went.
Why the slowest of 20, and not an average?
A figure that was true for every transfer in the run. An average hides the one you would have hit; a median hides half of them. If you need the distribution, every transfer is in the run file, with its hash.
Why 1 USDC, and why from one machine?
A dollar is the smallest transfer anyone makes, and a plain token transfer is the simplest practical transaction, so nothing in it but the chain is being timed. Each one goes alone and is watched until it is final before the next is sent. One machine with a named RPC provider makes the runs comparable with each other — both are part of the number, so both are printed in every run. Your machine and your RPC will give you your number: run it yourself.
How is it measured?
- aA wallet of ours sends 1 USDC (USDT where the chain has only USDT) to a second wallet of ours, one the runner derives from the first wallet's key and never stores. Nothing else is in the transaction beyond what makes it land and tells it apart: on Solana, a memo naming the run and a small priority fee.
- bThe clock starts the instant before the signed transaction leaves our machine. The machine and the RPC provider are named in every run: both are part of the number. No simulation or preflight is run before sending; a transfer that cannot land is recorded as failed.
- cThe transaction is polled on the chain's own RPC until it reaches each level the chain defines: first in a block, the earliest level the chain calls safe (*done* on the page), the level it calls final (*final*). The chain's own names for its levels are kept and printed. A level's time is the moment the poll that first showed it came back, so a figure carries up to one poll interval (100 ms by default, recorded in the run, with the number of polls each transfer took) plus one RPC round trip of slack. Figures are never smaller than the truth.
- dTwenty transfers per chain per run, one at a time: a transfer is sent alone and watched until it is final (or fails, or its cap passes) before the next one is built. Nothing else runs meanwhile. One run a week. The page shows the slowest of the twenty; the run file has all of them, with hashes.
- eEach chain's own claim is quoted from its documentation beside the link, with the date it was read and the date it will be read again.
- fThe method is versioned. A run records the version it was made under; the page shows the latest version's runs and links the older.
- gSetup and teardown are not timed. Before the first transfer the runner creates what transfers need (the recipient's token account, say); after the last it sends the asset back to the first wallet, closes what it created and reclaims the rent. Their transaction ids are in the run file too.
- hBy design: a chain is listed with its documented figures and not measured when even the earliest level it stands behind takes a minute or more (Ethereum: an epoch; Bitcoin: a block; Tron: solidified). Chains whose first safe level comes in seconds are measured, however long their last level takes — the rollups included.
- iUntil a chain is measured, the page shows the seconds its own docs give, marked ≈, with the quote beside them. Where the docs give no number, the page shows ?.
- jA chain may be listed outside the cut by decision, when it is new and built for stablecoins (Arc), or because everyone asks (Bitcoin); the landscape file says so.
- ·The method is versioned; old runs keep the version they were made under. method v0 ↗
What changed?
- 18 octthe first run: Solana. Twenty transfers of 1 USDC, one at a time, from srv2 (Falkenstein, DE) through Infura: runs/solana/2026-10-18T2118Z.json. Slowest *confirmed* 1.105 s, slowest *finalized* 8.075 s; the twenty finalized between 7.164 s and 8.075 s. Method v0. The runner holds one key, makes its recipient from it, and returned the 20 USDC and the account rent afterwards; those transactions are in the run file too.
- 18 octmocks 7 and 8. The byline above the list; *done* emphasised when it is fast while *final* is not; the column words link to their questions; everything below the list is a question that expands; a link to a chain opens and highlights its row.
- 18 octthe project starts. The premise, the page design (six mocks), the structure and the method draft are in docs/. Nothing is measured yet.
Can I run it myself, for my chain?
Yes — for one chain, a handful, or all. The code is the code behind every figure here. With one wallet of yours and an RPC URL:
git clone https://github.com/burmisov/txfinality.com cd txfinality.com && npm install cp .env.example .env # your RPC URL for the chain; never committed npx txfinality wallet --chain solana # a sender into .env; fund it with a little SOL and 20 USDC npx txfinality measure --chain solana --runs 20 # → runs/solana/<stamp>.json, with the hashes; funds come back
The runner makes its own recipient, returns the USDC and closes the accounts afterwards. Or hand the README to your agent and ask it for your chain's numbers. Something wrong on the page: report a correction.
Who made this, and why?
Sergey Burmisov. "Final in N seconds" is a claim every chain makes and nobody measures the same way; this page measures it the same way for all of them and shows its work. It grew out of building a router for stablecoin transfers, where the real finality time is the number that matters.