Solana Commitment Levels

Most Solana apps should not use one commitment level everywhere.

Use processed when freshness matters more than rollback safety, confirmed for most user-facing app and bot decisions, and finalized when the workflow values settlement confidence over speed.

This page owns the practical decision: which commitment level should your app ask Carbium RPC for? For the lower-level transaction path, use Transaction Lifecycle. For throughput and 429 behavior, use Solana RPC Rate Limits Explained.

Part of the Carbium Solana infrastructure stack.

The three levels

Solana RPC methods and subscriptions commonly accept a commitment parameter. The parameter tells the node how finalized the state must be before it returns data or sends a notification.

If a method accepts commitment and you omit it, many Solana clients and methods default toward finalized. That can be correct for audits, but it is often too slow for live product flows.

Use-case matrix

The short rule: show and decide on confirmed, speculate on processed, reconcile on finalized.

Copy-paste examples

JavaScript connection default

Set a default commitment when you create the connection:

import { Connection, PublicKey } from "@solana/web3.js";

const connection = new Connection(
  `https://rpc.carbium.io/?apiKey=${process.env.CARBIUM_RPC_KEY}`,
  "confirmed"
);

const balance = await connection.getBalance(
  new PublicKey("YOUR_WALLET_ADDRESS")
);

This is a good default for most app backends. It keeps simple reads, status checks, and confirmation loops aligned unless you intentionally override the commitment for one call.

Per-request commitment

Some methods accept commitment inside the request config:

const account = await connection.getAccountInfo(
  new PublicKey("ACCOUNT_ADDRESS"),
  "confirmed"
);

Use per-request commitment when one part of the app needs a different tradeoff than the default connection.

Raw JSON-RPC

curl https://rpc.carbium.io/?apiKey=$CARBIUM_RPC_KEY \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getBalance",
    "params": [
      "YOUR_WALLET_ADDRESS",
      { "commitment": "confirmed" }
    ]
  }'

For balance reads that drive UI or backend checks, confirmed is usually the right first setting.

Where teams usually get it wrong

Using finalized in every live path

This makes an app feel slower than it needs to. A wallet, swap frontend, or trading backend can often act on confirmed and then reconcile final state later.

Treating processed as settled

processed is useful when latency matters, but it is not a settlement signal. If your frontend marks a payment complete, unlocks an order, or retries a trade based only on processed, users can see confusing states when the app later disagrees with the chain.

Mixing reads and sends without a policy

If the quote path reads at processed, the signing path submits immediately, and the confirmation path waits for finalized, the app can feel inconsistent. Pick an explicit policy for each stage:

Retrying before checking status

Commitment level does not replace send-status logic. After submitting a transaction, check the signature status before deciding whether to retry. Blind retries can create duplicate user confusion even when the original transaction is still moving toward confirmation.

A practical Carbium default

For most production teams building on Carbium:

1. Use confirmed as the default connection commitment.
2. Use processed only for latency-sensitive reads that are re-checked before money or UX state changes.
3. Use finalized for reconciliation, analytics, payment audits, and support investigations.
4. Log which commitment level each critical request used.

That last point matters. When support is debugging a balance, swap, or bot incident, knowing whether the app read processed, confirmed, or finalized usually explains the difference between "the chain lied" and "the app asked an intentionally early question."

📘

Commitment is a correctness setting, not a performance trick. Faster is useful only when the app knows how to handle provisional state.

🔶

Building a production Solana app on Carbium? Start with confirmed, then use processed and finalized only where the workflow explicitly needs a different tradeoff.