Solana in 2026: Every Major Network Upgrade Explained

For most of its life, Solana ran on a single family of validator software and a consensus design built around Proof of History. That design made Solana fast, but it also concentrated risk: a bug in one client could stall the whole network, and several high-profile outages in earlier years made reliability the chain's defining criticism.

The 2026 upgrades attack that criticism from three directions at once. Firedancer adds an independent codebase so the network no longer depends on one implementation. Alpenglow replaces the aging consensus path with a modern, formally analyzed design. And a series of smaller protocol changes keep raising capacity and tightening the fee market. The Solana Foundation has framed the longer-term goal as "increase bandwidth, reduce latency" (often shortened to IBRL), with an explicit ambition to support global, internet-scale capital markets later this decade.

The sections below summarize each change. Each links to a full, sourced explainer.

Firedancer is a Solana validator client built from scratch by Jump Crypto in C and C++. Because it shares no code with the original Rust client (now called Agave), it gives Solana genuine client diversity, the same property that Ethereum relies on to avoid single-client failures.

The rollout has been deliberately staged. A hybrid build called Frankendancer, which combines Firedancer's high-performance networking and block-production code with Agave's proven consensus, has run on testnet and mainnet-beta since 2024. The fully independent Firedancer client has since begun a cautious, gradual mainnet rollout, with broad validator migration intentionally held back until security audits are complete. In testing, Firedancer has demonstrated more than one million transactions per second on commodity hardware.

Alpenglow is the codename for SIMD-0326, the largest consensus change in Solana's history. It replaces Proof of History and Tower BFT (as consensus mechanisms) with a new direct-voting protocol called Votor.

Two numbers capture the impact. First, deterministic finality drops from roughly 12.8 seconds to a target of about 100 to 150 ms. Second, validator votes move off-chain and are aggregated using BLS signatures, which removes vote transactions that today consume around three-quarters of block space. The proposal passed governance in September 2025 with 98.27% approval and went live on a community test cluster in May 2026. Mainnet activation is expected later in 2026.

Solana fees have two parts: a fixed base fee of 5,000 lamports (0.000005 SOL) per signature, and an optional priority fee you bid to improve ordering. The detail that most guides miss is that fee pressure on Solana is local: contention attaches to the specific accounts a transaction writes to, not to the network as a whole.

This is why a simple transfer can stay nearly free during a chaotic token launch happening elsewhere on the chain. It also explains why "the network is congested" headlines are usually misleading, and why blindly raising your priority fee often just wastes SOL. A 2025 protocol change (SIMD-0096) also redirected all priority-fee revenue to validators, sharpening their incentive to include high-priority transactions.

Raw throughput has climbed steadily. The per-block compute limit was raised to 60 million compute units in mid-2025, with further proposals (SIMD-0286 toward 100 million, and SIMD-0370 to remove the static cap entirely) under way. Sustained real-world throughput rose from roughly 1,700 transactions per second in mid-2025 toward several thousand per second in 2026, and stress tests have briefly pushed past 100,000 transactions per second.

There is an important caveat to every Solana "TPS" figure: historically a large share of transactions were validator votes. Removing those votes under Alpenglow will change how throughput is measured and reported, so headline numbers before and after activation will not be directly comparable.

These changes are complementary rather than independent. Alpenglow's simpler consensus is also easier to reimplement in a second client, which helps Firedancer reach multi-client parity. Removing vote transactions frees block space, which compounds with larger block limits to raise usable throughput. And a healthier fee market makes that extra capacity actually useful instead of being absorbed by spam.