in-solana by Supanode

Commitment Levels in Streaming

TL;DR

  • - Processed is fastest but can be rolled back
  • - Confirmed means 66.7%+ of stake voted — safe for most use cases
  • - Finalized means maximum lockout — cannot be rolled back
  • - Choose based on your latency vs safety tradeoff

When subscribing to Solana data via gRPC or WebSocket, the commitment level determines when you receive updates. Lower commitment means faster data with higher rollback risk.

The three levels

LevelLatencyRollback riskUse case
Processed~400msPossible (rare)Trading bots, real-time displays
Confirmed~5–10sVery unlikelyMost applications
Finalized~12–30sImpossiblePayments, settlements

Processed

The leader has processed the transaction in a block. You receive data as soon as the block is produced, before any voting.

Risk: if the leader’s block is not adopted by the cluster (fork), the data rolls back. This is uncommon but possible during network instability.

Best for: applications where speed matters more than certainty. Trading bots watching for new token launches or price movements.

Confirmed

At least 66.7% of stake-weighted validators have voted on the block containing this data. A rollback requires 66.7% of stake to reverse their votes, which has economic penalties.

Risk: theoretically possible but would require coordinated slashing-eligible behavior. In practice, confirmed data does not roll back.

Best for: most applications. The latency-safety balance suits wallets, explorers, and typical DeFi frontends.

Finalized

The block has reached maximum lockout depth in Tower BFT. It cannot be rolled back without violating protocol rules.

Risk: none under normal consensus operation.

Best for: payments, cross-chain bridges, settlement systems, and any flow where rollback causes financial loss.

Setting commitment in gRPC

In Yellowstone gRPC, commitment is set in the subscribe request:

{
  "commitment": 0
}

Values: 0 = PROCESSED, 1 = CONFIRMED, 2 = FINALIZED.

Setting commitment in WebSocket

WebSocket subscriptions accept commitment in the params:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "accountSubscribe",
  "params": [
    "vines1vzrYbzLMRdu58ou5XTby4qAqVRLmqo36NKPTg",
    { "commitment": "confirmed" }
  ]
}

Duplicate notifications

At processed commitment, you may receive an update for a transaction that later appears again at confirmed and finalized. Your application should handle deduplication by checking the slot number and signature.

FAQ

Should I always use finalized for safety? Only if rollback causes real damage (lost money, incorrect bridge relay). For most read-heavy applications, confirmed provides sufficient safety with much lower latency.

Can I subscribe to multiple commitment levels at once? In gRPC, each subscribe request has one commitment level. To receive both processed and confirmed, open two subscriptions with different commitment values.

Does commitment affect which transactions I see? No. The same transactions appear at all three levels. Commitment only affects when you see them — processed is fastest, finalized is slowest.

Updated: