Why finality, not speed, is the real settlement metric

Every payments conversation eventually produces the same slide: a bar chart of block times, ranked fastest to slowest. It is a satisfying chart and it is almost entirely misleading for anyone actually trying to settle money.

Block time measures how long until a transaction is included. Inclusion is a promise that is usually kept and occasionally broken. When it breaks, the transaction disappears from the canonical chain and reappears nowhere, and whatever you credited against it becomes a loss.

Two clocks, not one#

Every network has two clocks worth caring about:

• Inclusion — the transaction appears in a block. Fast, cheap to measure, not a guarantee.
• Finality — reverting the transaction would cost more than reversion is worth. Slower, harder to measure, and the only one you can book revenue against.

Charts that rank by the first clock are ranking confidence tricks. A network with one-second inclusion and probabilistic finality is not faster than a network with twelve-second inclusion and explicit finality; it is just louder about the wrong number.

Modelling reversion risk#

We treat reversion as a hazard rather than a yes/no property. For each network we maintain an estimate of the probability that a transaction included at depth d is later reverted. That estimate comes from observed reorgs, validator set concentration, and — on L2s — the timing of the batch posting that anchors state to a settlement layer.

The output is a curve, not a constant:

// Probability a transaction is still reverted away, by confirmation depth.
const reversionRisk = {
  base:     [0.0041, 0.00042, 0.00006, 0.000004],
  arb:      [0.0038, 0.00039, 0.00005, 0.000004],
  solana:   [0.0022, 0.00011, 0.00001, 0.000001],
  ethereum: [0.0009, 0.00004, 0.000002, 0.0000001],
};

Each value is the residual risk at that depth, and it decays quickly but never reaches zero on probabilistic networks. The important consequence is that "how many confirmations" is not a property of the chain — it is a property of the risk you are willing to carry.

Turning risk into a routing decision#

Once reversion has a price, routing becomes an expected-cost problem rather than a vibe. For a transfer of $V, the expected loss on a candidate route is roughly:

$$E[\text{loss}] \approx V \times p_{\text{revert}}(d^*) + c_{\text{network}} + c_{\text{consolidation}}$$

where $d^*$ is the depth at which the route's residual risk falls below your tolerance, and the consolidation term captures the future cost of leaving value stranded on a chain you do not normally hold.

Two things fall out of that formula that a block-time ranking would never show you:

1. Small payments tolerate less finality than large ones. A $20 payout on a chain with 0.004 residual risk expects 8 cents of loss; a $200,000 payout expects $800. Same chain, same depth, wildly different decisions.
2. Consolidation cost can dominate. Routing a small payout to the cheapest chain is a loss if you never hold anything there, because you will pay to move it back.

This is why JuicePay routes per transfer rather than per account. A single global preference would be wrong for at least half the payments a typical account makes.

What we tell you, and when#

By default, a payment intent becomes succeeded at finality, not inclusion. That is the conservative choice and the right default: it means the status you see is one you can book without a caveat.

Where speed genuinely matters — digital goods delivered instantly, a checkout where ten seconds of latency measurably costs conversions — we let you opt into announcing at inclusion:

{ "settlement_confidence": "included" }

You then receive payment_intent.succeeded early, and if the transaction is later reorganised away you receive payment_intent.reverted and the ledger entries reverse. That is a deliberate trade, not a free speedup. The test we apply before enabling it is simple: can you describe how your system would undo a delivered order? If the answer is a shrug, you want finality.

The uncomfortable part#

Finality is a security property, and security properties have costs. The networks that give you an unambiguous finality signal are the ones with expensive consensus. The networks that are cheap and fast are cheap and fast precisely because they are making a weaker promise, and they are entitled to break it.

None of this makes fast chains bad. It makes them fast, which is different. The mistake is not choosing a probabilistic chain — it is choosing one and then accounting as though the promise were absolute.

Pick your tolerance, price the risk, and let the routing follow. The chart will look less impressive and your finance team will sleep better.