Network models3 min read

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.

Editorial illustration accompanying solana commitment levels in data applications.

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

Further reading

{{TODO: author name}}

Practical explanations of blockchain data, software integration and the context behind a record.

About Indexbase
← Back to all articles

Build with better context.

Get an update when private beta opens.

Form setup in progress. Nothing entered here is sent or saved. {{TODO: endpoint}} See the full form and email alternative.