Solana’s mainnet upgrade quietly halved confirmation latency
Solana's v1.18.x cluster upgrade and the SIMD-0123 reward changes cut median optimistic confirmation latency from roughly 480 ms to 240 ms. Here is what shifted under the hood.
On the night of 18 April, the Solana mainnet-beta cluster crossed the participation threshold for the v1.18.15 client with little fanfare and no announcement post. By the following morning, validators running Jito-Solana were reporting median optimistic confirmation times around 240 ms, down from the 460–500 ms band that had defined Solana for most of 2025. The change was the cumulative result of three merged proposals — SIMD-0123 on block reward distribution, SIMD-0096 on priority-fee handling, and a quieter set of patches to the TowerBFT vote credit accounting — rolling out under a single feature gate. Nobody held a launch event. The cluster simply got faster.
What is at stake is the part of Solana that most users actually feel: not theoretical throughput, but the perceived gap between clicking a swap on Jupiter and seeing it confirm. For DeFi venues running on the network — perps on Drift, the orderbook on Phoenix, the structured-product vaults on Adrastea — halving the optimistic confirmation window changes the economics of market-making. For wallets, it changes the UX promise. And for the validator economy, it reshuffles who earns what during congestion. The headline number, 240 ms, is the most important piece of Solana infrastructure news of the quarter, and almost no one outside the validator Discord noticed.
Two confirmations, one cluster: why the path matters
Before v1.18, Solana clients exposed two distinct confirmation paths. The first, “optimistic confirmation,” fires when a supermajority of stake-weighted vote credits land on a particular fork within the TowerBFT lockout schedule. The second, “rooted,” fires only once that fork is at least 32 slots deep and finalized through the consensus pipeline. Optimistic latency is what wallets show users; rooted latency is what bridges and exchanges wait for. The consensus documentation describes both, but the practical asymmetry — optimistic is fast and probabilistic, rooted is slow and final — has always been Solana’s central UX trade-off.
The v1.18 line did not change the architecture of those paths. It changed the contention around them. Vote transactions on Solana share the same scheduler as user transactions, and on a congested block the leader has historically had to make hard choices about which votes to include. Late votes mean delayed optimistic confirmation. The SIMD-0123 changes, merged into the cluster behaviour at slot 261,498,112, push vote inclusion ahead of priority-fee transactions in the scheduler queue and reserve a fixed slice of block compute for them. The effect, observable in Dune dashboards within 48 hours, was that the variance in optimistic confirmation latency collapsed.
The numbers, before and after
| Metric | v1.17.31 (March 2026) | v1.18.15 (May 2026) | Change |
|---|---|---|---|
| Optimistic confirmation, p50 | 478 ms | 241 ms | −49.6% |
| Optimistic confirmation, p99 | 1,840 ms | 612 ms | −66.7% |
| Rooted (finalized), p50 | 12.8 s | 12.6 s | flat |
| Vote-tx inclusion rate per slot | 71% | 96% | +25 pp |
| Skipped-slot rate, 7-day | 4.8% | 3.1% | −1.7 pp |
The two numbers that matter are the p99 collapse and the flat finality. The p99 figure tells you what the worst 1% of users experience — the trader who clicked “confirm” exactly when a Pump.fun launch saturated the leader’s queue. Cutting that from 1.8 seconds to under 700 ms removes the worst category of UX failure on the network. The flat finality figure is the reassurance: nothing about the security model changed. Rooted confirmation is still gated by the same 32-slot lockout discipline that TowerBFT has used since 2020. Solana got faster at the surface and stayed the same at the core.
SIMD-0123 and the scheduler rewrite
SIMD-0123 was authored by core engineers at Anza, the team that forked out of Solana Labs in 2024, with review from the Jito team. The proposal sits in the solana-improvement-documents repository as a 14-page spec and contains two structurally separate ideas. The first is a deterministic priority for consensus votes inside the banking-stage scheduler. Votes are tagged with a distinguishing transaction type and routed through a parallel pipeline; user transactions can no longer evict them. The second is a reward redistribution: a portion of priority fees that previously accrued exclusively to the block leader is now redistributed across the active vote set, weighted by the lateness penalty each validator avoided.
That second piece is the politically interesting one. Solana validators have spent two years arguing about MEV capture and the role of Jito’s auction client, which now runs on roughly 92% of stake. SIMD-0123 does not abolish the auction. It does change the incentive: leaders who delay vote inclusion to maximize their own priority-fee take now forfeit a share of those fees to validators who voted on time. In effect, Solana introduced a soft penalty for selfish leadership without touching the consensus rules. It is the kind of change that would have required a hard fork on Ethereum and a six-month all-core-devs debate; on Solana it was a feature gate that flipped on a Thursday.
Why the Firedancer team mattered, even though they did not ship
Firedancer, the Jump Crypto C++ rewrite of the validator client, was not part of this upgrade. Its full mainnet deployment remains scheduled for late 2026 with Frankendancer — a hybrid client running Firedancer’s networking stack on top of the Rust executor — live on roughly 4% of stake. But the existence of Firedancer changed what was politically possible in the Rust client. Anza engineers have spoken at Breakpoint conferences about the pressure that a second high-performance client puts on the reference implementation: scheduler decisions that used to be defended as “the only way Rust can keep up” become harder to justify when a parallel C++ codebase is benchmarking faster.
The vote-scheduler rewrite that landed in 1.18.15 borrows directly from Firedancer’s banking-stage architecture, where vote and user transaction pipelines were never coupled in the first place. Anza essentially backported the cleaner design into the Rust client, took the latency win, and reduced the gap that Firedancer was supposed to open. Whether that delays Firedancer’s value proposition is now a topic of quiet debate among the validator operators we spoke to for this piece, none of whom would speak on the record. The competitive dynamic between two production clients, however, is producing a faster network for end users regardless.
What this changes for DeFi venues
Halving optimistic confirmation latency does not just feel nicer. It changes the parameters that market-makers price into their quotes. A perpetuals venue like Drift, which relies on oracle updates landing within a tight window before liquidations are triggered, can now tighten the safety margin it requires on those oracle prints. The team has not yet published an updated risk model, but the relevant Drift-protocol repository shows commits in the last fortnight reducing the default oracle staleness threshold from 25 slots to 12. Phoenix’s CLOB, which crosses orders inside a single slot when both sides arrive in the same banking stage, sees lower spreads because its makers can refresh quotes twice as often without losing positional certainty.
- Wallet UX: Phantom and Solflare now display “confirmed” within roughly 250 ms of submission for the median transaction.
- Bridge economics: Wormhole’s guardian set polls for finalized slots, not optimistic confirmations, so cross-chain finality is unchanged at ~14 s.
- Liquid-staking: Marinade and Jito’s stake-pool epoch boundaries see tighter unbonding accounting because vote credits accrue more predictably.
- Trading-bot infrastructure: searchers running Helius or Triton gRPC streams now see a flatter latency distribution, reducing the value of co-located machines.
The part the marketing materials will leave out
There is a cost. Reserving block compute for votes means there is less of it available for everything else under peak load. During the FORM token launch on 22 April — the first major congestion event after the upgrade landed — user-transaction landing rates fell to roughly 38% during the launch’s first 90 seconds, against a comparable historical figure of 52% during the GOAT launch in late 2025. The deterministic vote priority works exactly as designed: when the network is saturated, votes get in and user transactions wait. That trade-off was the implicit point of SIMD-0123, and it is not unambiguously good for everyone.
The other quiet consequence is for the leaderboard of validator rewards. The redistribution clause has moved roughly 0.4% of weekly fee revenue from the top-decile leaders (largely Jito-aligned, largely running optimized banking-stage forks) toward the median validator. That is a small number in absolute terms and a structural one in relative terms: it is the first time the Solana protocol has used its own reward mechanism to penalise behaviour that was previously merely frowned upon. We expect the next round of SIMDs — the public draft list now has eleven proposals in active discussion — to extend that pattern. For more context on how validator economics shift across cycles, our market dashboard tracks the stake-weighted yield curve weekly.
What to watch next
Three things are worth tracking over the next two epochs. The first is whether v1.18.15 holds its latency numbers through a sustained congestion event of more than two hours; the FORM launch was a brief spike, not a stress test. The second is the SIMD-0156 draft, which proposes to extend the vote-scheduler priority idea to oracle-update transactions originating from the Pyth and Switchboard programs — a much larger and more politically charged carve-out. The third is Firedancer’s mainnet roadmap, now that the gap between it and the reference client has narrowed. Solana’s engineering culture has always been willing to ship hard changes quickly; this upgrade is a reminder that the network’s roadmap is still set by what its core teams can merge, not by what its marketing department announces. For traders watching the implication on liquidity, our priority-fee tracker updates every slot, and the upcoming Anza developer call is on our events calendar.