What a confirmation actually buys you
A transaction in a block can still vanish: if the network briefly produces two competing chain tips and yours loses, the blocks on the losing side are reorganized away and their transactions return to the mempool as if never mined. Each block built on top of yours makes that outcome exponentially less likely, because an attacker (or plain bad luck) now has to outrun the whole network for that many blocks. "Six confirmations" was never magic — it's the depth at which Bitcoin reversal stops being a rational attack for ordinary amounts.
Chains with explicit finality change the shape: Solana's consensus finalizes slots, XRP and TON close ledgers in seconds with no proof-of-work race to reverse. There, the waiting is less about attack budgets and more about network hiccups. That's why sensible thresholds aren't one number — a small count of cheap blocks can be worth less than one expensive one.
Reading a threshold table like an adult
Our defaults illustrate the trade: BTC credits at a couple of confirmations (each ~10 minutes of the most expensive hashpower on earth), while TRC20 waits through many more of Tron's 3-second blocks — more blocks, far less wall-clock, similar practical safety. EVM chains sit in the middle double digits; fast-finality chains like XRP and TON need only a handful; Lightning needs zero, because settlement is atomic. The full per-coin picture is on the currencies page. Two useful rules of thumb: compare wall-clock time to credit across chains, not raw counts; and remember the threshold prices reversal risk, so it can be low where blocks are costly and high where they're nearly free.
One size doesn't fit all merchants either. Selling instantly-consumable value — game credits, gift cards, anything an attacker can extract in minutes — justifies a higher bar than shipping physical goods tomorrow. That's why thresholds are raisable per coin in settings: you can demand more depth than our platform floor, never less.
What we do when a reorg actually happens
Reorgs are rare and usually shallow, but a payment system has to assume the tail. Three behaviors worth knowing:
- Confirmations only count up. A flaky RPC reporting a lower count for a deposit never un-credits anything — status moves forward only, so your webhook history can't whiplash.
- Credit is single-shot. The moment a deposit crosses its threshold it credits exactly once, idempotently; replays and re-scans can't double-credit an order.
- Suspected reorgs trip a circuit breaker. If a credited deposit's chain context looks rewound, outbound payouts in that coin pause briefly (you'd see a
reorg_quarantineerror) while the chain settles — the point is to never let money out on the strength of money in that just became uncertain.
The checkout translation
For buyers, all of this compresses into the two states our checkout and webhooks expose: Paying (seen on-chain, accumulating depth — show "payment detected", don't ship) and Paid (threshold reached, balance credited — ship). If you build on the API, wire your fulfillment to payment.paid and treat everything before it as advisory UI. And if a customer asks why their payment isn't instant, the honest sentence is this post in miniature: the network is making it progressively too expensive for anyone to take the payment back — we credit the moment that's true enough.