Solana Commitment Levels in Data Applications
Choose processed, confirmed or finalized Solana observations according to workflow requirements, and keep commitment separate from freshness and transaction success.

Overview
When translating these concepts into an integration, keep the scope described by the wallet history api with the result. The examples in wallet transaction history and smart contract event logs show how the same distinction affects neighbouring data questions.
Commitment expresses how a Solana observation relates to cluster confirmation. A low-latency display and a settlement record can require different commitments, even when they reference the same transaction.
Attach commitment to the query
Processed, confirmed and finalized represent different confidence points under Solana’s model. They do not establish that the transaction’s instructions succeeded; execution status is separate. Nor are they fixed wall-clock delays. Record the requested commitment and the returned slot or context so the result can be assessed later.
Worked example: provisional activity
A wallet UI displays a processed transaction as provisional. A payment service waits for its declared stronger commitment and validates the actual transfer before settlement. If the provisional observation changes, the UI updates the state rather than retaining an unsupported paid label.
Test availability and transitions
Handle a missing transaction, a stalled context and an endpoint that cannot provide the desired historical detail. Keep transaction error information alongside commitment. Do not silently downgrade a settlement query to a weaker commitment when a stronger one is unavailable. A separate freshness indicator helps users distinguish old but settled data from fresh provisional observations.
A practical acceptance test
Expose the same signature with different commitment observations and a transaction error. Assert that stronger commitment does not turn failed execution into success. Make the requested commitment unavailable and verify a defined unresolved result rather than an automatic downgrade. Freshness timestamps should remain separate from both execution status and the chosen confirmation policy.
Questions about the topic
Frequently asked questions
Does finalized mean the instructions succeeded?
No. Commitment and execution outcome are separate dimensions.
Are commitment levels fixed time delays?
No. Their timing depends on network progress.
Standards & technical documentation
