Confirmation levels
What "confirmed" means on Solana, and how Mainly picks safe defaults so you rarely have to think about it.
Background
Solana doesn't have a single notion of "the current state." Data can be read at three levels of certainty, which raw RPC calls a commitment level:
| Level | Meaning | Typical latency | Can it be rolled back? |
|---|---|---|---|
processed | Seen by the current leader | ~400 ms | Yes — a small percentage of processed slots are skipped |
confirmed | Voted on by a supermajority of the cluster | ~1 s | Practically never |
finalized | Rooted; 31+ confirmed blocks built on top | ~13 s | No |
Mainly's defaults
Every read endpoint accepts an optional confirmation query parameter:
GET /wallets/{address}/balance?confirmation=finalized- The default everywhere is
confirmed— the level virtually all production Solana apps use. It's fast and, in practice, irreversible. - Use
finalizedwhen you're about to act irreversibly off-chain (credit a user's account, ship a product, release funds). processedis allowed only on real-time endpoints where speed beats certainty. History endpoints reject it — Solana itself doesn't supportprocessedreads of historical data — with aunsupported_confirmationerror.
Writes
When sending a transaction with
"confirm": true, Mainly waits for confirmed status before responding,
and the status endpoint
reports the level a transaction has reached (submitted → confirmed →
finalized).
If you never touch the confirmation parameter, you get the behavior most
apps want.