Consensus Best Practices
Choosing the right commitment for your app.
Search across all documentation pages
Choosing the right commitment for your app.
confirmed or finalized. Do not treat processed as final.Agave 4.1.1 is transitioning toward Alpenglow—treat confirmation timings as version-dependent.
Use Solana CLI 3.0.10, which pairs with Agave 4.1.1. Install with agave-install init 4.1.1 (or your team's pin file), then verify with solana --version and agave-install --version.
Use @solana/kit 7.0.0 for new TypeScript—typed RPC methods, smaller API surface, and examples on this page already use Kit. Keep web3.js only for legacy codebases; migrate RPC calls and transaction building incrementally.
Use confirmed for UX that tolerates rare forks; use finalized before irreversible payouts or bridge messages. Re-benchmark timeouts during Alpenglow rollout.
When txs vanish, check commitment level: confirmed is not finalized. Log status transitions during migration.
Yes—point CLI and RPC to https://api.devnet.solana.com. Behavior matches mainnet; only account data and economics differ.
Consensus changes rarely affect CU—focus on confirmation UX and timeout configs.
Anchor 0.32.1 patterns apply when you write on-chain programs: typed accounts, require! guards, and IDL generation—use avm use 0.32.1 and anchor-lang = "0.32.1" in Cargo.toml.
Surfpool helps test client polling scripts against forked state; it does not simulate validator voting internals.
LiteSVM for program logic; devnet RPC for finality behavior during Alpenglow rollout.
The validator client rebranded to Agave (4.1.1), CLI 3.0.10 aligns with it, and Alpenglow work is changing finality—pin versions and read release notes each upgrade.
getSignatureStatuses at multiple commitments; getVoteAccounts for validator health.
Stack versions: This page was written for Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0, and LiteSVM 0.6.x.
Reviewed by Chris St. John·Last updated Jul 16, 2026