Solana's glow-up, explained: every 2026 performance upgrade in one place
TLDR: Solana shipped Agave 4.0 in May 2026 with major speed and capacity upgrades (p-Token, Wincode, Faster Replay, QUIC-only TPU). Block size rises from 60M to 100M CUs via SIMD-0286. Alpenglow consensus rewrite arrives late 2026 with ~150ms finality. Decentralization upgrades (SIMD-0123, Constellation) follow.
Performance has always been the soul of Solana's engineering. When @toly founded Solana, he built around a thesis he knew wouldn't change: people always pick cheaper over expensive and faster over slow.
That principle has been rebuilt into the network over the years, and the work has accelerated lately. Solana is in the middle of a foundational rewrite: a wave of upgrades that change how much the network can handle, how fast it settles, how reliably it stays up, and how fairly it runs.
In this article, we cover the upgrades rolling out across 2026, most in Agave 4.0 (Anza's validator client, shipped May 2026), with more coming in Agave 4.1 and Alpenglow later in the year and what they mean for users, now and ahead.
The effects are already showing. On October 10, 2025, the largest liquidation event in crypto history hit the network with roughly 6x its normal peak traffic, and Solana stayed up with fees mostly under a cent.
Activity has been climbing the whole time: average daily transactions rose 50% in Q1 2026 to a record 112.6 million. The network absorbed all that while staying cheap and stable because of these upgrades. Most of it is invisible when you actually use Solana. It shows up indirectly, in transactions that don't fail when the network is busy, fees that stay low when everyone shows up at once, and confirmations that feel instant.
We've grouped the upgrades by what each one does for the network:
- Increasing network capacity: XDP, SIMD-0256, SIMD-0286, p-token, p-ATA, p-memo
- Improving speed: faster replay, Wincode, Alpenglow
- Reliability: Firedancer, DoubleZero, QUIC-only
- Decentralization and fairness: SIMD-0123, Constellation
First up: capacity, the most basic measure of how much the network can handle.
1. How is Solana increasing network capacity in 2026?
Capacity on Solana is the amount of computational work that fits into a single block, measured in compute units (CUs). A simple SOL transfer costs almost nothing, just a few hundred CUs. A complex multi-step swap or heavy smart-contract execution can burn tens or hundreds of thousands. Each block has a hard cap on total CU usage, called the block limit. That’s the network’s real ceiling on how much it can process in one ~400 ms slot.
There are two ways to fit more into a block:
Increase block capacity
The most direct way to add capacity is to make the block bigger, so it holds more work overall. That limit has been raised in steps: 48M, then 50M (April 2025), then 60M CU, which is live now (since July 2025). The next target is 100M.
But just raising the number not enough
Picture a block like a delivery truck. The leader validator loads it up with transactions, then has to blast that whole truck out to every other validator on the network before the next 400 ms slot starts.
Two things decide real throughput: how fast the truck gets delivered and how big it can safely be. They’re locked together. If propagation is slow, a bigger truck just arrives late, validators fall behind, and the network risks skipping slots or breaking. That’s why the upgrades always roll out in this exact order: speed first, then size. You can’t just crank the CU limit without first making the network way faster at moving data around.
1. What is XDP and how does it let Solana ship bigger blocks?
XDP (short for eXpress Data Path) is a high-speed shortcut for Solana’s network traffic. Normally, when data moves in and out of a computer, it has to go through many layers of the Linux operating system. This is like driving through a crowded city with lots of traffic lights, stop signs, and detours; it’s slow and uses a lot of energy (CPU power). XDP lets Solana skip most of those layers. It allows the validator software to talk almost directly to the network card (the hardware that sends and receives internet data).
This is done using a special low-level trick in the Linux kernel. In Solana, when a validator produces a block, it doesn’t send one big file to everyone. Instead, it breaks the block into hundreds or thousands of small packets (“shreds”) and rapidly fans them out to ~200 other validators. With bigger blocks, the number of packets goes up massively; large validators can send over 150,000 packets per second.
Without XDP:
- The computer wastes a lot of CPU just handling these packets.
- Retransmissions (when a packet gets lost and needs to be resent) take a long time — around 600 milliseconds in older tests.
With XDP:
- One CPU core can now do the work that used to need 12 cores.
- Retransmission time drops dramatically, down to about 0.8 milliseconds.
- The whole process becomes way more efficient and uses far less power.
This upgrade is one of the main reasons the network can push toward 100 million CU blocks soon.
https://x.com/bw_solana/status/2045875014000603252?s=20
2. How Solana raised its block limit from 50M to 60M CUs (SIMD-0256 live):
The first step was raising the block limit from 50 million compute units to 60 million, a 20% increase. It went live in mid-2025.
Blocks were regularly hitting the old 50M limit during busy periods. When a block is full, extra transactions get dropped, and fees rise as people compete for the remaining space. The higher limit reduced both, more transactions fit, so fewer get dropped, and fees stay steadier under load.
This held up under real stress. On October 10, 2025, crypto saw its largest liquidation event on record, with roughly $19.5 billion wiped out in a day. Solana handled about 6x its normal peak traffic, over 100,000 inbound packets per second, while block times stayed near 400ms and most fees stayed under a cent. The higher 60M limit and the early XDP rollout were a big part of why it stayed stable.
3. When will Solana's block limit increase to 100M? (SIMD-0286 coming):
The limit is set to rise again, from 60 million to 100 million compute units, a 66% increase, the largest so far. It isn't live yet.
This would be the largest single capacity boost so far. It means way more room per block for complex DeFi trades, NFT mints, and heavy program executions. Fewer dropped transactions during crazy market moments, lower average fees, and much smoother experience for users when demand spikes.
2. How is Solana making transactions use less block space?
Instead of only making the block bigger, Solana is also making every transaction use less space inside the block.
This is the “lighter cargo” approach. The network rewrites its most heavily used core programs using Pinocchiol Anza’s zero-copy, zero-dependency Rust library that eliminates wasteful memory copies and heap allocations. It also removes other sources of waste (like on-chain votes).
The result: the exact same actions now burn dramatically fewer compute units (CUs), so more real user transactions fit inside every block, without any code changes for apps or users.
1. What is p-Token and how much does it cut Solana transaction costs? (live since May 2026)
The SPL Token program (Tokenkeg) is the most-used program on Solana after the System program. It handles almost every token transfer, mint, burn, etc. Over the past year it was quietly eating ~10% of total block CU usage. SIMD-0266 replaced it with p-Token, a drop-in, 100% backward-compatible rewrite built on Pinocchio.
Exact savings (no app changes required):
- Normal transfer: 4,645 CU → 76 CU (98% reduction)
- transfer_checked: 6,200 CU → 105 CU
- initialize_mint: 2,967 CU → 105 CU
- Most other instructions: 93–98% cheaper
Because tokens touch the majority of onchain activity, this one upgrade freed ~10–13% of total block space across the entire network. DeFi swaps, NFT mints, gaming, and every other program now have more room.
p-Token is fully live on mainnet (activated during the Agave 4.0 cycle in May 2026) and already delivering measurable relief.
2. What is p-ATA and how does it reduce token account costs?
Associated Token Accounts (ATAs) are the deterministic accounts that actually hold your token balances. Wallets and dApps create them constantly. The p-ATA rewrite (Pinocchio-based) is well underway and expected to ship soon after p-Token. It will cut the CU cost of creating and managing ATAs the same dramatic way p-Token did for transfers, a big daily win for wallets, DEXs, payment apps, and any protocol that spins up token accounts on behalf of users.
3. What is p-Memo and how does it cut memo transaction costs?
The Memo program lets you attach a short note (payment reference, order ID, compliance memo, etc.) to any transaction. It’s heavily used in payments and institutional flows. Early benchmarks already show 80–87% CU reduction. Once live, any memo-attached transaction will cost noticeably less.
2. How is Solana getting faster in 2026?
Solana is already one of the fastest blockchains in the world, producing blocks every ~400 ms. But “speed” on Solana means more than just block production time.
It’s about how quickly the network confirms transactions, how fast validators can replay and validate blocks, how quickly the leader can hand off to the next validator, and how soon users and apps can trust that a transaction is final.
Right now, optimistic confirmation (the point where most wallets show “confirmed”) happens in roughly 1 second, but full economic finality still takes ~12.8 seconds on average.
The upgrades in this section attack every part of that latency, making the network feel dramatically snappier for everyday users while giving builders the confidence to ship real-time applications.Here are the three main upgrades focused purely on speed:
1. How Faster Replay in Agave 4.0 makes Solana validators 3x quicker
The replay stage is the part of every validator where it re-executes every transaction in a received block to make sure it matches exactly what the leader produced.
This is one of the most CPU-intensive and time-sensitive jobs a validator does, especially for RPC nodes and validators that fall behind and need to catch up.
In Agave 4.0 (May 2026), Anza moved two of the heaviest verification steps off the main replay thread’s critical path:
- PoH (Proof of History) entry verification is now done asynchronously in the background.
- Ed25519 signature verification is split: the cheap hash/message check happens immediately for safety, while the full expensive signature check runs in the background and is only joined right before the block is finally accepted.
Real measured impact (from Anza’s internal benchmarks):
- Mean replay time per block dropped from ~130 ms to ~50 ms — almost 3x faster.
- RPC nodes see 2–9 ms improvement in P50/P90/P95 latency for account updates and transaction streaming.
- Validators can process and catch up to new blocks much quicker, especially during high-load periods or after restarts.
This is a pure under-the-hood win that makes the whole network more responsive without changing anything users see directly.
2. What is Wincode and how does it speed up Solana validators?
Almost every piece of data on Solana, blocks, accounts, snapshots, network messages, has to be serialized (turned into bytes) and deserialized (turned back into usable data). This happens constantly inside validators and is a hidden source of CPU usage and latency.
Wincode is Anza’s brand-new, bincode-compatible serialization library built specifically for Solana. It focuses on in-place initialization and direct memory writes with almost no copying or temporary buffers.
In Agave 4.0, more performance-critical paths (blockstore, snapshots, network messages, etc.) switched from the older bincode to Wincode. The result is lower CPU usage and faster processing everywhere data is packed or unpacked.
It’s one of those quiet foundational upgrades that compounds across the entire system, every validator and every RPC node benefits from the reduced overhead, making the network feel smoother overall.
3. What is Alpenglow and when will it launch on Solana? (targeted late 2026)
This is the biggest speed upgrade on the roadmap, a complete rewrite of Solana’s consensus layer (SIMD-0326). Alpenglow replaces the current Tower BFT + Proof of History system with a much simpler and faster design:
- Moves almost all voting off-chain using fast BLS certificates (this is the same vote eviction we saw in the efficiency section).
- Introduces a new finality engine called “Votor” that achieves deterministic finality in 100–150 ms.
- Replaces PoH with a more efficient mechanism for ordering transactions and leader handovers.
- Validators pay a simple one-time Validator Admission Ticket (~1.6 SOL per epoch) instead of spamming on-chain votes.
Current status (June 2026): Governance passed with 98%+ approval. It is now in heavy validator testing and expected to activate with Agave 4.1 or shortly after. What it means in practice:
- Confirmation latency drops from ~12.8 seconds (full finality) to ~150 ms, up to 100x faster.
- Leader handovers become almost instant.
- The network can safely support even higher block CU limits in the future without risking instability.
What do these Solana upgrades mean for users and developers?
For everyday users, these upgrades translate to noticeably faster and more reliable experiences:
- Transactions confirm almost instantly (you’ll see “confirmed” in your wallet in under a second, with full finality in ~150 ms once Alpenglow lands).
- During busy periods (memecoin launches, DeFi frenzies, NFT drops), fewer transactions get dropped or delayed.
- Fees stay low and predictable because the network wastes less time and compute on internal overhead.
For builders and apps, it unlocks entirely new use cases:
- Real-time DeFi (instant swaps, liquidations, and order books that feel like centralized exchanges).
- Payments and gaming that need sub-second finality.
- RPC providers and indexers can handle much higher query volumes with lower latency.
In short: Solana already felt fast. After these upgrades, it will feel instant, the kind of speed people expect from traditional finance or Web2 apps, but with all the benefits of a decentralized blockchain. The network is getting faster from the inside out, without asking users to change anything.
3. How is Solana becoming more reliable in 2026?
Solana has always been fast, but reliability is what turns that speed into something you can actually depend on at scale. Reliability here means the network keeps producing blocks and confirming transactions even under extreme stress, massive liquidation events, memecoin launch spam, DDoS attempts, or sudden traffic spikes, without outages, skipped slots, or degraded performance.
The biggest historical risks of blockchains have been single points of failure: one dominant validator client (a bug could halt most of the network) and fragile public-internet networking (jitter, packet loss, congestion).
The upgrades in this section directly attack those risks: client diversity, dedicated high-performance networking, and hardened transaction ingestion. They make Solana far more resilient without sacrificing speed.
1. Firedancer (live on mainnet, phased rollout)
Firedancer is Jump Crypto’s completely independent validator client, written from scratch in C. It is not a fork of Agave, it’s a brand-new implementation with a modular “tile” architecture (each major function runs in its own isolated process). Key reliability wins:
- True client diversity: Before Firedancer, >90% of stake ran on Agave (or Jito forks). A single bug in one codebase could (and historically did) cause network-wide outages. Firedancer breaks that single point of failure.
- Fault isolation: If one tile (e.g., networking or QUIC handling) has an issue, the rest of the validator keeps running.
- Higher resilience under load: Custom QUIC stack, NUMA-aware design, and optimized data paths make it more stable during spam or high-throughput periods.
Firedancer (and Frankendancer hybrids) already run a portion of mainnet stake and have produced tens of millions of blocks with zero consensus divergence. Full independent execution is live and growing fast.
2. QUIC-only TPU (live in Agave 4.0)
The Transaction Processing Unit (TPU) is how transactions reach validators for inclusion in blocks. Anza fully removed the old UDP protocol. QUIC is now the only way to submit transactions. Reliability benefits:
- QUIC has built-in congestion control, encryption, and stream management, far more robust than UDP.
- It dramatically reduces spam/DDoS vectors and handles high traffic without overwhelming validators.
- Transaction ingestion is more stable and predictable under load.
This was a long-planned change that removes a known fragility point in the network stack.
4. How is Solana improving decentralization and fairness in 2026?
Decentralization on Solana isn’t just about having more validators, it’s about making sure no single validator or small group can unfairly control transaction ordering, extract excessive MEV, or capture most of the economic rewards. Fairness means stakers get a real, predictable share of revenue, and users get predictable, non-manipulable transaction inclusion. These two upgrades directly address the remaining centralization risks in block production and validator economics.
1. SIMD-0123: Block Revenue Distribution (approved March 2025, under development)
SIMD-0123 introduces a native, protocol-level mechanism that lets validators automatically share priority fees and other block revenue with their stakers/delegators.How it works:
- Validators set a commission rate on block revenue (exactly like they already do for inflation rewards).
- At the end of every epoch, the protocol automatically calculates the post-commission amount and distributes it proportionally to all delegated stake accounts.
- Fully on-chain, transparent, and automatic — no more manual off-chain agreements or opaque Jito-style tips.
Current status (June 2026): Approved by stake-weighted governance vote in March 2025 (74.91% YES). It is now under active development and expected to activate by Agave 4.1.
- Priority fees have become a large part of validator revenue (especially after earlier changes gave validators 100% of them). Before this upgrade, stakers got none of that revenue by default.
- It makes staking yields more competitive and predictable for delegators (especially institutions and retail stakers).
- It reduces validators’ incentive to hide or hoard MEV through off-chain deals.
- It strengthens decentralization: smaller validators can more easily attract stake because delegators know they’ll automatically receive a fair share of real block revenue.
2. Constellation: Multiple Concurrent Proposers
Today one validator at a time runs block production. While it's the leader, it sees transactions before anyone else and decides what gets in and in what order. It can reorder them, push its own ahead, or drop yours. That control is where MEV comes from: front-running, sandwich attacks, and selective censorship.
Most fixes just redistribute the profits from that monopoly. Constellation tries to break it.
It does this with Multiple Concurrent Proposers (MCP). Instead of one leader controlling the block, around 16 proposers run at once, collecting transactions in parallel. A separate set of attesters records what they see and signs off on it, and that signed record forces the leader to include those transactions. If enough attesters confirm a transaction, the leader can't exclude it without producing a block the network rejects. So a fee-competitive transaction that clears the threshold gets in, and no single validator can quietly censor it.
That's a real guarantee, but it's worth being clear about what it doesn't fix.
Proposers are still chosen by stake weight, so the same large operators that dominate today also get most of the proposer slots: 16 proposers is better than one, but it isn't full decentralization.
Each proposer also still sees the transactions sent to it, so sandwiching isn't solved, and submitting to several proposers for safety actually exposes your transaction to more of them.
A proposer can quietly delay a competitor's transaction to push it out of the window, which leaves no on-chain proof and can't be punished. The team acknowledges all of this openly.
There's also a speed cost. The extra attester round and the 50ms cycle add latency, which is why parts of the community pushed back: it trades some raw speed for a fairness guarantee, and whether that's the right trade is still being argued. It's still a proposal, not live. Constellation builds on top of Alpenglow (targeting Q3 2026), so it comes after that, with key details still to be worked out.
Conclusion
For everything these upgrades change, it adds up to something simple. Transactions land when the network is busy instead of failing. Fees stay near zero even when everyone shows up at once. Swaps confirm in milliseconds, fast enough that you stop thinking about them. The network keeps performing the same, whether it's quiet or slammed.
That's the thread running through every upgrade here: none of it asks you to do anything, learn anything, or change how you use the chain. It just removes the friction you used to hit when the network got slammed — the failed transactions, the fee spikes, the slowdowns, on the days that friction was worst.
Solana spent its early years proving it could stay online. This is what comes after: making that performance something you never have to think about.
And the same work reaches further than everyday use. The capacity, speed, and fairness that keep ordinary activity smooth are the same foundation that lets serious onchain trading, market making, and financial infrastructure run on Solana at all. That's what's next: how this rewrite reshapes the ground for finance, and what it opens up that wasn't possible before.
