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
| Level | Latency | Rollback risk | Use case |
|---|---|---|---|
| Processed | ~400ms | Possible (rare) | Trading bots, real-time displays |
| Confirmed | ~5–10s | Very unlikely | Most applications |
| Finalized | ~12–30s | Impossible | Payments, 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: