Processed vs Confirmed: Solana's 13-Second Trade-Off

The Drop-Down That Decides Everything

I'm staring at a single argument in my RPC client and trying to convince myself that picking the right value matters more than the next ten lines of code combined. The argument is the commitment level, and the choices are processed, confirmed, and finalized. To anyone reading the docs casually, these three words look like log verbosity settings. To a Solana arbitrage bot, they're the difference between catching a price gap and watching it close, between trusting a balance read and acting on a phantom one.

The more I read, the more I realize this isn't really a technical choice. It's a small philosophical commitment, no pun intended, about how much uncertainty I'm willing to act on. Solana is fast enough that the network gives me three different stories about the same transaction, each one a little more believable than the last, and each one arriving a little later. Whichever story I choose to act on, I'm choosing how patient — or how greedy — my bot gets to be.

A Network That Tells Three Stories at Once

Most blockchain people grew up on Ethereum's mental model: a transaction is either pending or mined, and once it's mined you wait a handful of blocks for safety. Solana shatters that. Slots tick at roughly 400 milliseconds, and as a developer, you get to ask the cluster three different questions about the same transaction:

• Did some validator see this in a block? → processed
• Did two-thirds of stake vote for the block containing it? → confirmed
• Did 32 more blocks get built on top of it? → finalized

The official Agave/Anza validator documentation lays out the precise definitions: processed means the block has been received and might be on the majority fork; confirmed means at least 66% of stake has voted on the block; finalized means 31 or more confirmed blocks have been built on top of it. These aren't marketing tiers; they're directly tied to Tower BFT's voting mechanics.

What that means in practice is that Solana, by design, hands you a slider between speed and certainty. It doesn't pick for you. Every line of code that touches RPC inherits that choice, and most of the time the default confirmed is silently doing the deciding behind your back.

What "Processed" Actually Looks Like

If I ask the network at processed, I'm essentially saying: show me the freshest opinion you have, and I'll deal with the consequences. The block has just landed at some validator, the transaction is inside, and that's enough.

The Solana Foundation's official developer guide is unusually blunt about what that costs you. According to Transaction Confirmation & Expiration on solana.com, "roughly 5% of blocks don't end up being finalized by the cluster so there's a real chance that your transaction uses a blockhash that belongs to a dropped fork." That's the price of going early. Roughly one in twenty bets you make on the most recent state could land on a fork that the network later abandons.

The same official guide notes that "Choosing processed will let you fetch the most recent blockhash compared to other commitment levels," which is exactly why latency-sensitive code reaches for it. Feedback comes back nearly instantaneously, sub-second, well before the cluster has gathered its votes. According to a leading infrastructure provider's blog, this is the realm of wallet pending states and development workflows — places where being wrong occasionally is cheaper than being slow always.

Think of processed as the live broadcast of a high-stakes motorsport event. You're seeing the cars in real time, but the officials haven't ruled on the lap times yet. Most of what you see will hold up. Occasionally, a yellow flag retroactively erases a position. If you're a fan watching at home, the broadcast is the right view. If you're paying out a wager, it isn't.

What "Confirmed" Actually Buys You

The step from processed to confirmed looks tiny in the documentation — one extra criterion, the 66% stake vote — but in operational terms, it is the entire difference between hope and a near-guarantee.

One well-regarded technical writeup puts the safety claim in unusually strong terms: "No confirmed block has reverted in Solana's five-year history." That's a single-source claim worth treating cautiously, but it captures the lived experience that production teams describe. Once two-thirds of stake have voted, reversing that block would require a coordinated attack by more than a third of the network's stake — economically irrational under almost any scenario.

What does it cost in time? According to a leading infrastructure provider's blog, confirmed typically lands roughly 500–600ms after block production, only a few slots behind processed. That's half a second. In human terms, an eye blink. In MEV terms, an eternity. In wallet-UX terms, indistinguishable from instant.

The Solana Foundation's own developer guidance is explicit: "The confirmed commitment level should almost always be used for RPC requests." That sentence, sitting in the official docs, is doing a lot of work. It's telling you that the network's own maintainers consider half a second a fair price for vanishing your rollback risk.

And Then There's Finalized

If processed is the live broadcast and confirmed is the official scoreboard, finalized is the certified record book. The block has been voted on, then 31 more blocks have been stacked on top of it, and the cumulative voting cost of unwinding that chain is so high that it functionally cannot happen without a catastrophic network event.

The price tag is real, though. The official Solana developer documentation describes "typically at least a 32 slot difference between the most recent confirmed block and the most recent finalized block." A leading infrastructure provider translates that into a concrete number: roughly 12.8 seconds of deterministic finality lag. That's the gap between we're pretty sure and we are absolutely sure.

For most application logic, 12.8 seconds is forever. For an exchange crediting a deposit, or a cross-chain bridge releasing assets, it's a perfectly reasonable wait. The bigger the value at risk, the more you want this tier.

Here's the counterintuitive part that bit me when I first read it: requesting a finalized blockhash actually increases your odds of transaction expiry. A major infrastructure provider flagged this clearly — by the time you receive a finalized blockhash, you've already burned around 13 seconds of its 60-second validity. Under network congestion, that's enough margin to matter. Picking the safest commitment level for reads doesn't automatically translate into the safest behavior for writes. The network punishes naive use of the strongest tier.

How I Came to Feel the Trade-Off

I didn't really internalize any of this from reading. I internalized it from watching the bot make decisions on stale data and then arguing with itself.

When the bot is scanning for arbitrage cycles, it's continuously asking: what's the current state of every relevant pool? If I read those pool accounts at finalized, I'm acting on a snapshot that is roughly 13 seconds old. On a network where block production happens every 400ms, 13 seconds is 32 slots of accumulated changes I haven't seen. By the time my transaction lands, the pool I targeted may have shifted multiple times, my predicted output may be wrong, and other searchers may already have closed the gap.

A DEV Community post by decoder_man captures this with a line I keep coming back to: "If you're 2–3 slots behind the tip, you're effectively 800–1,200ms in the past." The phrase that lodged in my head wasn't "800ms behind" — it was in the past. Acting on stale Solana state isn't a small inaccuracy. It's time travel in the wrong direction.

So for reading state during opportunity scanning, finalized is wildly inappropriate. Even confirmed may be too conservative if the goal is to find a fleeting price gap. Most scanning work pulls toward processed, with the understanding that some of the opportunities I'm reading will turn out to be ghosts.

But for acting — for the moment when the transaction is being constructed and sent — the calculus inverts. Now I'm exposing real lamports to the rollback risk. The 5% number the foundation cites stops being abstract.

The 5% That Won't Stay Theoretical

It's tempting to round 5% down to "basically never." That's a mistake.

If my bot makes a hundred opportunistic trades a day on a processed-only worldview, statistically five of them will reference a blockhash that ends up on a dropped fork. Five rejected transactions a day isn't a disaster, but it isn't free either. Each one consumed compute units to attempt. Each one might have locked up an opportunity slot during which a competitor went through. And if those five happened to be the largest, most profitable attempts of the day, the average return takes a real hit even though the rate sounds small.

This is why the practical answer for execution is rarely "just use processed everywhere." Production sniper writeups I've read tend to recommend something more layered: use the freshest commitment level for scanning and pre-trade simulation, but lean toward stronger commitments — or run additional simulation steps — for the actual send decision, especially when the trade size is large. As a representative example, a leading infrastructure provider describes "processed" commitment as recommended for earliest fills, with the implicit understanding that risk management still has to live somewhere downstream.

In other words: choosing a commitment level is not a single global setting. It's a per-call decision, sometimes a per-flow decision, and getting it wrong in either direction has a cost.

Why MEV Bots Live on Processed

The more I think about it, the more it becomes obvious that MEV is the use case the Solana commitment ladder was forced to support, not the one it was designed for.

Paul Timofeev's Medium piece on Solana MEV frames it cleanly: "On Solana, block production occurs every 400ms, and given Solana's FIFO transaction processing mechanism, searchers must compete over latency rather than fees." That sentence is the whole game. On Ethereum, you can outbid the field. On Solana, you have to outrun it.

When latency is the competitive axis, every signal that arrives earlier has economic value. processed is the earliest signal the cluster offers. Refusing to use it would be like a high-frequency trader refusing to colocate. You can choose dignity, but the spread isn't going to wait for you.

The broader infrastructure literature ties the same knot. Latency-focused providers describe "a 50ms delay could mean the difference between a successful backrun and a missed opportunity" — that line shows up in a leading provider's competitive sniper writeup and gets echoed across the ecosystem. The same source notes that the leading edge of competitive operations is targeting sub-40ms RPC performance from geographically co-located nodes.

In that environment, asking a bot to wait for confirmed to scan opportunities is asking it to give up the race before the flag drops.

What MEV Looks Like at Scale

According to Paul Timofeev's analysis, the overall MEV transaction success rate on Solana has hovered "under 3%" over the past year, and the top 10% of extractors capture roughly half of all extracted MEV. One notable bot in his dataset paid up to 21.78 SOL for priority blockspace on a single transaction. These are not numbers that suggest a relaxed competitive environment.

What those figures tell me is that the median searcher is losing money, the top decile is winning by enormous margins, and the gap between those two outcomes is largely about infrastructure choices — including, prominently, how aggressively you trust processed data. The conservative bot reading at confirmed is, on average, half a second behind the aggressive bot reading at processed. Over thousands of attempts a day, that gap compounds into the difference between the top decile and everyone else.

So when I'm picking a commitment level for the scanning path of an arbitrage bot, I'm not really choosing between two technical tiers. I'm choosing whether the bot competes in the same league as the operators who treat 50ms as a meaningful unit of time.

Why the Default Isn't Just Wrong

It would be easy to walk away from this thinking "production teams use confirmed, MEV bots use processed, end of story." But there's a third character in the conversation that I keep underestimating: the blockhash.

Every Solana transaction needs a recent blockhash, and the official guidance reminds developers that blockhashes expire after 151 slots — roughly a minute at 400ms per slot. The freshness of the blockhash you fetch becomes its own commitment-level question. Asking for a finalized blockhash means starting your transaction with an expiration clock that's already had a 13-second head start. That can be the deciding factor during congestion, when transaction retries pile up and the network's effective throughput drops.

This is the kind of detail that makes me think the commitment level system is not really three discrete options — it's a continuous knob with two ends, where neither end is universally correct and the right setting depends on whether the call is about reading state, fetching a blockhash, or confirming an outcome. Each of those three has its own appetite for staleness.

The more I work with the network, the more I treat the choice the way I might treat shipping options for a fragile package. Overnight shipping isn't always "safer" — sometimes it just means the package sits in a sorting facility longer because the courier prioritizes guaranteed-time deliveries. Sometimes Ground gets there first. Picking the option labeled "highest assurance" isn't the same as picking the option with the best outcome.

A Mental Model That Finally Stuck

The analogy I keep returning to is courtroom evidence.

• processed is an eyewitness account. It's immediate, vivid, and roughly 95% of the time it holds up under scrutiny. But the other 5% of the time, it gets recanted on the stand, and anything you built on it falls apart.
• confirmed is a sworn statement signed by two-thirds of the jury. It hasn't gone through final appeal, but in practice, statements at this level don't get overturned. The widely cited claim that "no confirmed block has reverted in Solana's five-year history" is essentially saying the appeal court has, so far, always upheld the jury.
• finalized is the appellate ruling. By the time you have it, the question is settled forever — but the trial is already in the past tense, and 13 seconds of new evidence have accumulated that you haven't seen yet.

For a bot that has to act on the world right now, confirmed is almost always the right answer for the commit path. For a bot that has to see the world right now, processed is almost always the right answer for the read path. The hard work is making those two halves of the bot agree about what's real.

The Alpenglow Cliff

I keep noticing that all this nuance might have a shelf life.

Solana's Alpenglow consensus replacement has been live on a community test cluster since May 11, 2026, according to a crypto news outlet's coverage. According to a crypto news outlet's coverage, Alpenglow swaps out Tower BFT and Proof of History for a new pair of components, Votor and Rotor, and in the process it collapses the three-tier commitment ladder I've been agonizing over.

A leading infrastructure provider summarizes the new model in the kind of line that makes you re-read it twice: "Alpenglow collapses this into one level. 100–150ms, deterministic finality on every transaction." The same source notes the design eliminates the developer dilemma of "accept rollback risk and show the user a fast result, or wait 12.8 seconds and be certain." If Alpenglow ships to mainnet on the trajectory currently discussed, the entire processed-vs-confirmed-vs-finalized decision dissolves into a single deterministic window of roughly 100–150ms.

I'm not betting my code base on that timeline — testnets and mainnets keep their own schedules — but I am noticing that the careful balancing act I'm learning right now might be a temporary skill. The deeper skill, the one that survives the consensus upgrade, is the habit of asking what is the freshness budget for this particular decision every time I touch the RPC layer.

Living With the Choice

For now, the commitment level argument keeps sitting there in my code, deceptively small. I've stopped treating it as boilerplate. Every time I write a new RPC call I find myself asking a small set of questions:

• Is this read going to drive an immediate action, or is it going to be used minutes later? If it's immediate, lean fresher; if it's archival, lean stronger.
• Is the call about state I'll act on, or a hash I'll sign against? Those two have different staleness costs.
• If this read is wrong roughly 5% of the time, what protects the rest of the system from acting on the wrong answer? Is there a simulation step? A safety check? Or am I quietly assuming the read is gospel?

None of these questions have a single global answer. They're per-call decisions, and the discipline is treating them that way instead of letting the default decide silently. I don't think the official guidance to "use confirmed for almost all RPC requests" is wrong. I think it's the right default for a developer who hasn't yet decided what kind of bot they're building. Once that's decided, the defaults start to matter less than the exceptions you carve into them.

Key Takeaways

• Three commitment levels, three trade-offs. processed is sub-second but carries the official ~5% rollback risk; confirmed lands around 500–600ms with historically near-zero reversals; finalized is roughly 12.8 seconds out and effectively immutable.
• The official default is confirmed for almost all RPC requests, per Solana's own developer documentation — half a second of patience eliminates almost all rollback exposure.
• finalized isn't automatically "safer" for transaction sending — a finalized blockhash starts life roughly 13 seconds closer to expiry, which matters during congestion.
• MEV searchers gravitate toward processed for scanning because Solana's FIFO ordering forces competition on latency, not fees; the 5% rollback cost is a tolerable price for the freshest possible view of state.
• The three-tier system may not last. Alpenglow, currently testing on a community cluster as of May 2026, is designed to collapse the commitment ladder into a single deterministic 100–150ms window — making today's careful trade-offs a temporary skill on top of a more permanent habit: asking what freshness each individual call actually needs.