What are Solana Commitment Levels?

Solana is a high-performance blockchain that processes thousands of transactions per second. To ensure both speed and security, Solana provides commitment levels for transaction confirmations. A commitment level indicates how “final” a given block or transaction is, balancing trade-offs between responsiveness and certainty. 

In simple terms, stronger commitment levels (e.g. finalized) provide more reliable guarantees that a transaction is confirmed by the network (i.e. less likely to be rolled back), while weaker commitment levels (e.g. processed) give feedback faster, but offer less-certain confirmations.

This blog explains all of Solana’s commitment levels—Processed, Confirmed, Finalized, and others (including deprecated terms)—with technical definitions, differences, internal mechanics, developer use cases, and impacts on reliability, performance, and security.

What are Solana commitment levels?

Solana commitment levels are a standardized way to measure the network’s consensus on a given block or transaction. When you query a Solana RPC node for a transaction’s status or account data (e.g., getTransaction), you can specify a commitment level to indicate how finalized you want the data to be. Solana uses this commitment level to let clients balance latency vs. certainty: lower commitment gives quicker feedback, while higher commitment levels give developers stronger assurances that the state won’t revert.

Solana defines three primary commitment levels (in descending order of finality):

Finalized

The highest level of certainty, indicating the block has been confirmed by a super-majority of stake (≥66 %), and at least 31 further confirmed blocks have been built on top of it, giving the slot the maximum 32-vote lock-out. A finalized transaction is effectively irreversible.

Confirmed

An intermediate level where the block has been voted on by a supermajority of stake (≥66%), but not yet finalized by a more extended period of continued voting that makes it harder to reverse. This is often called optimistic confirmation, providing a strong assurance the transaction is on the “main fork,” or canonical chain.

Processed

Processed means the transaction was just processed by a leader and included in the most recent block that the node knows about. However, that block may not yet have any cluster-wide votes. The transaction could still be dropped if that block doesn’t end up in the majority fork.

These levels represent stages in a transaction’s lifecycle. 

A freshly submitted transaction will move from Processed → Confirmed → Finalized as more of the network observes and votes on the block containing it, and subsequent blocks are built atop that block. Higher commitment implies more nodes have agreed on the transaction’s inclusion, reducing the risk of a fork or rollback. 

Let’s explore each level in detail.

Processed Commitment Level

A transaction is Processed as soon as a validator node (i.e., the current leader) includes it in a block. This is the earliest acknowledgment: the transaction has been received and incorporated into the ledger state locally. 

Key characteristics of the Processed level include:

• Included in a Block: The transaction resides in a block that a validator produced.
• No Guarantee of Majority Fork: This block may or may not end up on the majority (longest/heaviest) fork
• Fastest Feedback: It provides immediate feedback that the transaction was processed by a node. This is useful for quick client-side updates (e.g., showing a pending transaction in a wallet UI).
• Not Fully Secure: At this stage, there is no assurance that other validators have seen or voted on the block. The cluster could still “skip” this block or overwrite it with an alternate fork. In other words, Processed = included but not yet confirmed by others.

Processed Block Example: 

Suppose Alice submits a transfer on Solana. As soon as the current leader adds it to a block (slot N), the transaction is marked as Processed. Alice’s wallet might immediately show the transaction as pending/processed. 

However, if that leader’s block is not accepted by the majority of validators (e.g., the leader was slow or offline and another fork took over), Alice’s transaction might disappear (i.e., get dropped) because the processed block didn’t become part of the main chain.

Confirmed Commitment Level

A Confirmed commitment level indicates that the transaction’s block has been accepted by the cluster’s supermajority and is very likely on the canonical chain. Technically, “confirmed” means ≥66% of stake-weighted validators have voted on that block directly. 

Key characteristics:

• On the Majority Fork: The block containing the transaction is recognized as part of the majority fork of the ledger. This implies the network considers this block as a canonical block.
  
  
• Supermajority Votes: At least two-thirds of the total stake has voted to confirm the block. These votes are gathered via Solana’s gossip mechanism, meaning validators have broadcast and observed votes for this block across the network. This stage leverages optimistic confirmation, as introduced in Solana v1.3, which allows nodes to treat a block as confirmed as soon as a supermajority votes on it (even before it’s finalized).
  
  
• Low Risk of Reversion: With 66%+ consensus, it’s highly unlikely, though not impossible, for a conflicting fork to replace this block. All honest validators have effectively committed to this block unless a major reorg happens. No confirmed block has reverted in Solana’s five-year history.
  
  
• Faster Than Finalized: The confirmed status usually occurs shortly (within a second or two) after a given block or transaction is marked as processed, since validators promptly vote on new blocks. It does not wait for many subsequent blocks. Thus, confirmed offers a good balance of speed and confidence in normal conditions.
  
  
• Optimistic Finality: Often, developers treat a confirmed transaction as essentially final for most practical purposes, given Solana’s fast consensus. However, there remains a small chance of rollback until finalization.

Confirmed Block Example: 

Alice’s transaction from above becomes Confirmed once the cluster’s validators vote on block N. In practice, if the next few validators (by slot N+1, N+2, etc.) vote and see block N, reaching the 66% threshold, the network marks block N as confirmed. Alice’s wallet can now safely show the transaction as confirmed to the user. 

The probability of Alice’s transfer being reverted at this point is very low (only if a rare fork or network issue occurs). This is analogous to “N confirmations” in other chains, but on Solana it’s based on stake voting rather than a fixed number of block confirmations.

Finalized Commitment Level

A transaction is Finalized when its block has been voted on by supermajority and sufficient additional blocks have been built on top of it. With respect to Solana’s consensus, this corresponds to the block achieving maximum lockout, typically after 32 consecutive votes (slots) have confirmed it. Finalized is the strongest commitment level, offering the highest degree of certainty that the transaction will not be reversed. 

Characteristics of Finalized include:

• Irreversible Block: The cluster has recognized this block as finalized, meaning it’s been rooted in the ledger state. Validators will not roll it back, and it’s effectively permanent.
  
  
• Supermajority + Lockout: Like Confirmed, at least 66% of stake endorsed the block. Additionally, 31+ subsequent confirmed blocks have been added after it. In other words, the network has built a deep chain on top of this block, reaching the lockout depth where reorg is infeasible.
  
  
• Maximum Lockout (32 votes): Solana’s Tower BFT mechanism doubles the lockout period of votes exponentially. Once a block has accumulated 32 votes in the tower (meaning it has remained the head of the fork through 32 more slots), it reaches the maximum lockout and is finalized. At this point, any validator that attempts to vote for an alternate fork would be violating consensus rules.
  
  
• Most Secure, Slowest Confirmation: Finalization typically lags behind the processed and confirmed levels by some time (on the order of ~10-20 seconds under normal conditions, since 32 slots at ~400ms each ≈ 13 seconds). This is the trade-off for Finalized certainty. By waiting for finalization, clients eliminate all risk that the transaction will be dropped or reversed, at the cost of additional latency.
  
  
• Confirmed + Built Upon: Another way to see finalization: it’s a confirmed block that has been buried under many more blocks. All honest nodes have verifiably locked in this block as part of the permanent ledger.

Finalized Block Example:

Alice’s transaction reaches Finalized status after the network continues to produce blocks beyond slot N. Suppose by slot N+32, a supermajority of validators have voted on each successive block up through N+32 (with no forks taking over). Block N (with Alice’s tx) is now finalized. 

At this point, Alice’s transaction is absolutely permanent in Solana’s ledger – even if she waits for a while, the state including her transfer will not change. 

Any application requiring strong finality (like an exchange releasing funds) can now safely act on this transaction. Notably, if an attacker tried to revert this, they would need to control over 1/3 of the stake and violate consensus.

Deprecated Commitment Levels

Earlier versions of Solana (pre-2021) exposed additional commitment levels that have since been deprecated in favor of the three above.

For completeness, here are the legacy terms and how they map to the current levels:

• recent – Deprecated; equivalent to Processed. In older documentation, “recent” simply refers to the latest state the node knows.
  
  
• single and singleGossip – Deprecated; equivalent to Confirmed. These referred to confirmations involving a single validator or via gossip, which aligns with the confirmed definition.
  
  
• root and max – Deprecated; equivalent to Finalized. “Root” referred to the rooted state finalized in the cluster, and “max” referred to maximum lockout—both effectively meaning finalized.

Today, developers should use only processed, confirmed, or finalized when specifying a commitment level. The Solana JSON-RPC API as of v1.5.5 defaults to these terms and treats the deprecated ones as aliases for their mapped level. 

Additionally, if no commitment is specified in an RPC request, the default is Finalized (i.e., the node returns the most finalized state by default).

Differences Between Commitment Levels

The differences between Processed, Confirmed, and Finalized can be understood in terms of how much of the network has acknowledged the transaction, and how likely it is to be reversed. The table below (adapted from the official Solana documentation) summarizes the key distinctions:

In summary, Processed means only that the transaction is in a block (nothing more). Confirmed means the cluster has agreed on that block (supermajority votes) but it’s still near the tip of the chain. Finalized means the block is deep in the chain with many confirmations—so deep that it’s effectively immutable.

Another way to view the difference is by the probability the transaction remains in the canonical ledger over time. 

Immediately when processed, the probability is not 100% (there’s a chance of a fork or failure). Once confirmed by >66% stake, the probability of inclusion jumps very high. By the time it’s finalized with dozens of blocks on top, the inclusion probability is ~100%. 

This is illustrated in the chart below, which shows how the likelihood of a transaction being finalized increases as more slots pass and commitment level rises:

Likelihood of a transaction being included in the final canonical chain grows over time. Initially at slot n (transaction processed), there’s some risk the transaction could be “skipped” or forked out. With optimistic confirmation (confirmed), the inclusion likelihood sharply rises as validators vote. After enough consecutive forks are built upon it (finalized), the probability of reversal reaches effectively zero. This demonstrates the decreasing risk of rollback as commitment level increases.

How does Solana determine commitment levels?

Understanding how Solana’s consensus works “under the hood” can clarify why these commitment levels exist:

Proof of History (PoH) and Block Production

Solana’s leaders produce blocks in rapid succession (one leader per slot, slots ~400ms). Transactions are streamed into a Proof of History (PoH) hash chain, forming entries in a block. Blocks propagate quickly through the network via Turbine (Solana’s block propagation protocol). When a leader produces a block with your transaction, that block is immediately propagated but not yet confirmed — corresponding to the Processed stage.

Voting (Tower BFT)

Solana uses a BFT consensus algorithm called Tower BFT. Validators (each controlling some stake) vote on blocks they believe should become the next part of the ledger. Votes are themselves Solana transactions, and they include a concept of lockout. Every time a validator votes on a block at slot N, it incurs a lockout such that if it later votes on a conflicting fork, it might lose the ability to vote for some time. 

These lockouts double exponentially with each successive vote on the same fork (1, 2, 4, 8... slots of lockout) and cap at 32 votes. If a validator has voted 32 times in a row on a fork (meaning the block from 32 slots ago is still part of the heaviest fork), that block is at max lockout. This mechanism incentivizes validators to stick with the majority fork and finalize blocks.

Confirmation (Optimistic Confirmation)

When a block is produced, validators broadcast votes for it. As soon as a supermajority (≥66%) of stake has voted on a block, Solana nodes consider that block optimistically confirmed. This is the Confirmed commitment level. It happens quickly, often within one or two slots after the block, because votes propagate via gossip. 

Importantly, Solana’s implementation doesn’t require waiting for the block to become rooted in the ledger; it trusts the supermajority vote as an optimistic signal that this block will be finalized eventually (barring <33% of stakes misbehaving). 

This is why it’s called optimistic confirmation: under normal Byzantine fault assumptions (at most 1/3 dishonest), a supermajority vote means the block will not be overturned. If a fork was to override it, >33% of validators would have to vote for an alternate chain, which breaks the assumptions.

Finalization (Rooting a Block)

As new blocks continue to be produced and voted on, each confirmed block moves deeper in the fork. Once a block has accumulated votes in 32 consecutive slots after it, it reaches the maximum lockout. At this point, the network roots that block, marking it as finalized and irreversible. Finalization means the block is at least 31 blocks behind the head and was never abandoned in favor of another fork. All nodes now consider this block part of the immutable history (ledger state up to that slot is frozen). 

In effect, the Finalized commitment corresponds to “block has ≥32 confirmations” in a PoW chain analogy, but Solana achieves this via time-locked votes rather than proof-of-work confirmations. The 32-slot rule is a consequence of Tower BFT’s design (lockouts doubling until 2^32) and provides a mathematical guarantee of finality under the 1/3 fault tolerance assumption.

Fork Choice & Rollback

Solana’s consensus continuously evaluates forks. Validators use a heaviest-fork selection algorithm (based on stake voting weight) to decide which fork to build on. If a block is only processed by a subset of validators and fails to get votes, another fork can override it. This is why a Processed transaction can be dropped. 

Once a block is confirmed by 2/3, an alternative fork would have to have more than 1/3 of stake behind it to win, which is very unlikely and would imply malicious behavior. 

After finalization, a fork that rewinds that block is essentially impossible without a catastrophic consensus failure. Even if the network halted or was attacked, reverting finalized slots would require coordination outside the protocol rules.

To summarize the mechanics: Processed = block produced (PoH) but not widely voted yet; Confirmed = cluster votes (Tower BFT) reached supermajority on the block (optimistic consensus); Finalized = block has persisted as the chain “root” after many more votes (absolute consensus finality). Solana’s design ensures that confirmed blocks become finalized after a short delay, providing fast confirmation and eventual absolute finality.

Developer Use Cases for Each Commitment Level

Choosing the appropriate commitment level is crucial when building on Solana. Different applications have different requirements for speed vs. certainty. 

Here are typical use cases and best practices for each level:

Use Processed for Immediate Feedback and Non-Critical Ops

Developers might use the Processed commitment in scenarios where speed is paramount and some risk of rollback is acceptable. For example, during development and testing, you may want instantaneous confirmation that a transaction was received by a validator. 

UI applications (like wallets or games) could optimistically show a transaction as soon as it’s processed to improve user experience (e.g., show a “pending” state). 

However, because processed transactions aren’t guaranteed to stick, this level is not recommended for production-critical flows. If used, it should be for low-value or non-critical transactions where a potential rollback would not cause serious issues.

Use Confirmed for Most Transactions

The Confirmed level is generally the recommended default for many use cases on Solana. It offers a strong assurance of success with minimal latency impact. 

For instance, a DeFi application making a token swap or a user transferring funds will usually rely on confirmed status: once the transaction is confirmed, the app can treat it as completed in the normal case. This level significantly reduces the chance of a transaction being dropped compared to Processed. Best practice is to use a commitment level of Confirmed especially when querying recent blockhashes and sending transactions, as it provides a better balance between latency and safety.

Use Finalized for High-Value and Critical Transactions

When absolute certainty is required, such as high-value asset movements, cross-chain bridges, or exchange deposit confirmations, developers should use the Finalized commitment level. This is common for scenarios where even a tiny risk of rollback is unacceptable. 

For example, an exchange might wait for a transaction to be finalized before crediting a deposit to a user’s account to avoid any chance of later reorg that could undo the deposit. 

Another use is after a series of transactions: one might ensure the final state is finalized before considering a complex operation complete (e.g., in an audit or settlement process that needs final ledger state). 

Developers should be aware that requiring a Finalized commitment will add latency and, under heavy network load, can increase the likelihood of transaction expiration since you’re effectively waiting for an older block’s hash to finalize. Finalized should be used judiciously for only the most critical transactions where the extra safety is worth the latency trade-off.

In summary, Processed is mostly for quick feedback and non-production use, Confirmed is the go-to for most operations providing a safety-performance balance, and Finalized is reserved for when you truly need guaranteed finality despite the wait. 

Many applications will use a mix: display UI updates on Processed, consider things done on Confirmed, and log once Finalized.

Impacts on Transaction Reliability, Performance, and Security

The choice of commitment level has direct consequences on reliability (will the transaction stick?), performance (latency), and security (risk of double-spend or fork issues):

Reliability

Higher commitment levels improve the reliability that a transaction is permanently recorded. A finalized transaction has essentially 100% reliability in terms of being in the ledger (barring extraordinary events), whereas a confirmed transaction has a very high, but not 100%, and processed transactions have lower reliability. 

As noted earlier, about ~5% of transactions could end up dropped if one only counts processed (due to fork churn), whereas confirmed drops that risk near 0%. 

In critical applications, using finalized commitment eliminates the risk of your transaction being in a fork that is later discarded.

Performance (Latency)

There is a clear trade-off in how quickly you get a confirmation vs. the commitment level. 

Processed confirmation is nearly instantaneous (within the block time, often sub-second). 

Confirmed adds a small delay (on the order of one or two slots, maybe ~0.5–1 second extra) to gather validator votes—it’s still very fast and usually unnoticeable to users in practice. 

Finalized adds the largest delay, since the transaction will only be reported as finalized once roughly 30+ subsequent blocks have been produced. Typically, ~10-20 seconds to reach finality. 

During periods of network congestion or slow block production, this delay could be longer. Thus, requiring a Finalized commitment can slow down user experience and throughput if overused. If an application waits for finalization, it must account for that extra time. However, this does not mean the transaction itself takes longer to execute on-chain; it means the client is waiting longer to ensure it’s finalized. Solana is still processing new transactions in the meantime.

Throughput vs. Expiration

An important subtle impact is on transaction expiration and blockhash usage. Solana transactions include a recent blockhash and are only valid for ~150 slots after that blockhash. 

If you request a finalized blockhash to sign your transaction, that blockhash is older (because finalized lags the tip), and you will have fewer slots remaining before the transaction expires. This can increase the chance of expiration if the network is congested and your transaction isn’t processed quickly. 

Using a more recent (Confirmed) blockhash gives a longer window. The official recommendation is to use Confirmed for getLatestBlockhash to reduce expiration risk. 

Therefore, using Finalized for the preflight or blockhash can slightly reduce the time your transaction has to get picked up, affecting reliability under load. 

In short, a Finalized commitment might trade off some liveness during heavy load—you gain certainty but possibly at the cost of more transaction timeouts if the network is near capacity.

Security

From a security standpoint (e.g., double-spend prevention, fork safety), Finalized is the safest. 

Once finalized, reversing a transaction would require more than one-third of the total stake to act maliciously, which would likely be noticed and punished. 

Confirmed is very secure under normal conditions (an attacker would have to create a conflicting fork and convince >33% of validators to support it after a supermajority already voted, which is extremely unlikely without a major coordinated attack). 

However, Confirmed does have a theoretical scenario where if some validators (just under 33%) withheld votes or a fork was just at the cusp, a confirmed block could be orphaned. However, Solana’s design (optimistic confirmation) assumes an honest majority to deter this. 

Processed provides the least security: until votes are in, there’s no guarantee any other validator even knows about the transaction. A malicious leader could even include a transaction and then fail to transmit the block properly, etc. 

Thus, Processed should not be relied on for any security-critical confirmation (it’s more like a “notifier” that the process has started). 

In summary: Finalized > Confirmed > Processed in terms of security against forks and double-spend.

Use of Commitment in Reads vs. Writes

When reading state from Solana (e.g., checking an account balance via RPC), you also specify a commitment level. If you use a Processed commitment level for a read, you might see very up-to-date data, but it could be from a fork that isn’t finalized. Using Finalized for reads gives you absolute consistency (the state everyone agrees on), but it may be a few slots behind. For most cases, using Confirmed for state queries is a good balance, just as with transactions. This ensures you don’t make decisions based on a fork that might revert. 

For write queries (i.e., sending transactions), the commitment primarily matters for how the client library waits for confirmation. A common pattern is sending a transaction with a certain preflightCommitment (which might simulate the TX against the latest state) and then using confirmTransaction with the same commitment level. Developers can choose to wait for finalized confirmation if needed.

To ground this in real numbers: based on recent measurements, Solana processed a transaction in ~0.4 seconds, reached the confirmed state in ~0.6 seconds, and achieved finalization in ~13 seconds. 

If your application, for example a payments app, can’t wait ~13 seconds per transaction, you should use confirmed, which still provides strong security. 

If you are moving a large amount between chains, you may choose to wait the full ~13 seconds to be completely sure. On the other hand, if you are building something where speed is critical and a little risk is acceptable, such as optimistically updating a UI, you might rely on the processed status to deliver a snappy user experience.

Conclusion

Solana’s commitment levels—Processed, Confirmed, and Finalized—are a core feature that allows developers to tailor the balance between speed and certainty for each transaction.

Processed gives immediate but uncertain results, Confirmed provides a near-final assurance within a second or two (sufficient for most applications), and Finalized offers absolute finality after additional time. 

Under the hood, these levels correspond to Solana’s consensus progress: from a block being produced, to voted on by a supermajority, to rooted in the ledger with maximum lockout.

When building on Solana, it’s vital to choose the right commitment level for the task:

• Use lower commitments for fast feedback or non-critical actions
• Use confirmed for standard operations where you need both speed and safety
• Use finalized for the cases where nothing but total finality is acceptable

Each level impacts how reliable the transaction inclusion is and how long you wait. 

By understanding the technical meaning (66% votes, 32 blocks, forks, lockouts) and following the latest best practices, developers can ensure they get the performance Solana promises without sacrificing the consistency and security of their applications.

Additional Resources

• Solana Documentation – Configuring State Commitment, Commitment Status Table
• Helius Blog – Consensus on Solana (consensus and finality mechanics)