Open this lesson in your favourite AI. It'll walk you through the why, explain the demo, and quiz you on the try-it list.
Solana exposes three confirmation levels: processed (a single validator saw it), confirmed (2/3 stake-weighted vote), finalized (32 slots / ~13s deep). Each is a different point on the safety-vs-latency curve, and picking the right one for your application is operational hygiene.
Compare the three levels.
confirmed commitment, then re-check with finalized — observe the elapsed time difference.Use these three in order. Each builds on the one before.
In one paragraph, explain Solana's three confirmation levels and the trade-off.
Walk me through what 'confirmed' actually requires — how many validators, how their votes are tallied.
Given a cross-chain bridge moving $1M between Solana and Ethereum, design the confirmation strategy that balances UX waiting time vs reorg risk.
Level | Latency | Safety guarantee
--------------|---------------|----------------------------------------------
processed | ~400ms | One validator saw it. Reorgs possible.
confirmed | ~1-2s | 2/3 stake voted. Reorg requires >1/3 slashing.
finalized | ~13s (32 slots)| Effectively irreversible (would require fork).
Use cases:
processed: UX optimism — "your tx is on-chain!" before confirmed
confirmed: most consumer dApps — fast enough, safe enough
finalized: bridges, large-value DeFi, exchanges — paranoid mode
Code:
await connection.confirmTransaction({
signature,
blockhash,
lastValidBlockHeight
}, "confirmed"); // or "processed" or "finalized"
Reorg reality:
At "processed": ~5-10% chance of reorg within 1s on busy slots
At "confirmed": <0.1% chance of reorg
At "finalized": effectively 0 (would require >1/3 of stake to break)
Comparison to ETH:
Solana "confirmed" ≈ ETH HEAD (probabilistic safety)
Solana "finalized" ≈ ETH FINALIZED (cryptoeconomic safety)
Both finalize in <15s, much faster than ETH's ~12 min FFG finality.