Day 3/5 ~ Unpacking Confirmations ~ How chains model finality, and why your app needs to think probabilistically ~ yesterday, we explored how “confirmation” depends on the chain. Today, let’s unpack how those chains actually model finality, and why your app needs to move beyond a binary view of “confirmed vs not" Most chains don’t offer a single clean answer. Instead, you’re working with a spectrum: 1. deterministic finality: chains using BFT-style consensus (e.g. cosms, some alt-DAs), L1 settlement (e.g. ethereu after finality) and most PoS offer hard guarantees - once finalized, a transaction can’t be reverted. 2. probabilistic finality: pow chains (like bitcoin) and ethereum "pre-finality" offer statistical guarantees. A tx buried 12 blocks deep is unlikely to be reorged - but not impossible. the deeper, the safer. 3. soft signals: sequencer confirmations, mempool inclusion, builder relays - they’re fast, but carry risk. these signals are useful, but must be treated carefully. apps often treat these sources equally: → “wait X blocks” → “trust the sequencer” → “check for inclusion” But that abstraction breaks as soon as you go interop. A cross-chain app might span: ~ A fast-finality BFT chain ~ An optimistic rollup with 7-day fraud windows ~ An L1 with probabilistic finality ~ A chain with sequencer-only guarantees your app logic can’t hardcode a one-size-fits-all rule. you need to ask: “How likely is this tx to revert? And who enforces that?” ==> finality isn’t binary and the tradeoff between speed and security isn’t linear. (multisigs, for example, don’t gain speed or trust.) → what you need is programmable, chain-aware confidence == a way to express what “confirmed” means in each context