Solana is a proof-of-stake blockchain that gets its speed from a published schedule of block producers, parallel execution of non-conflicting transactions, and a new block slot every 200 milliseconds. On October 21, 2026, it also replaced its voting system with Alpenglow, targeting finality near 150 milliseconds. Sampled hours in October 2026 showed roughly 2,000 to 2,600 user transactions per second. The price is demanding hardware and concentrated stake.
"Fast" means three different things
Speed claims about any blockchain mix three measures, and it helps to separate them:
- Slot time is how often a block can be produced.
- Finality is how long until a block can't be reversed.
- Throughput is how many transactions fit in each second.
Two of these changed in October 2026. Slot time fell from 400 to 200 milliseconds on October 9, 2026, in four 50-millisecond steps. Earlier steps ran 15 to 19 milliseconds above target, and no full measured average at 200 milliseconds was available when the change went live.
Shorter slots did not double capacity. Per-slot limits scale with slot time, so blocks come twice as often with half the room. Solana had raised the block compute limit from 60 million to 100 million units on July 29, which is the change that added room.
Theoretical vs. observed TPS
Solana's headline transactions-per-second (TPS) figures measure very different things.
| Figure | What it is | How to read it |
|---|---|---|
| 1,000,000+ | Firedancer demo at Breakpoint 2024 | A single-client test, not the live network |
| 710,000 | An older upper estimate | Theoretical |
| 65,000 | Often-quoted design capacity | Theoretical, not a daily rate |
| 107,540 | Peak in August 2025 | Real, but mostly no-op calls that did no useful work |
| About 2,000-2,600 | Non-vote TPS in sampled hours, October 20-21, 2026 | Actual user activity |
| 1,584 | Average non-vote TPS, July 2026 | Actual user activity |
Observed TPS shows demand, not the ceiling, so it understates what the chain could carry. Watch out for older totals, though. Validator votes made up about 62% of processed transactions in the week before Alpenglow. Votes have now left the block, so totals from October 21 onward can't be compared with earlier ones. Non-vote TPS is the like-for-like series.
How a Solana transaction moves through the network
- You sign. The transaction lists every account it will read or write. Read what you approve, because some wallet drainers hide an owner change in a Solana transaction.
- It goes straight to the leader. Solana has no public waiting room, or mempool. An RPC node forwards it to the current and next leaders. If it isn't processed within 150 slots, it expires.
- The leader executes it. Non-conflicting transactions run in parallel.
- Validators receive the block. The leader streams it out in pieces as it builds.
- Validators vote. Once enough stake agrees, the block is final.
The leader schedule
The leader schedule says which validator produces blocks in each slot. Each validator computes it locally, weighted by stake, using ledger state from the start of the previous epoch. An epoch is about 432,000 slots, which works out to 24 hours at 200 milliseconds. The schedule has allocated groups of 4 slots at a time.
Because the producer is known in advance, a transaction can go straight there, with no need to spread it across the whole network first.
What proof of history did, and what changed
Proof of history (PoH) is a running hash chain that proves time has passed. Anything hashed into it must have existed before that point. This gave validators a shared clock without syncing wall clocks, and it let them process incoming data before voting.
PoH was never the consensus mechanism, which is a common confusion. Solana secures itself with proof of stake. PoH only ordered events.
Many explainers still credit PoH for Solana's speed, but that is now out of date. Alpenglow moves consensus away from PoH, so since October 21 it no longer paces block production. Local timers do that job, with a purpose the proposal calls "akin to Proof-of-History, but without any notion of synchronized time."
From Tower BFT to Alpenglow's Votor
Tower BFT was Solana's voting system until October 21, 2026. Validators voted on-chain, and each new vote doubled the lockout on earlier ones, making it steadily costlier to switch forks. Full finality was usually given as 12.8 seconds. Galaxy estimates about 6 seconds at today's shorter slots, so that older baseline flatters the improvement.
Alpenglow is the replacement, and only its first half has shipped:
- Votor, live since October 21, 2026. Validators send votes directly to each other, and those votes are combined into compact certificates. Under SIMD-0326, a block finalizes in one round with 80% of stake, or in two rounds with 60%. The proposal describes a "20+20" security model, generally explained as tolerating 20% malicious stake plus another 20% offline.
- Rotor, not yet scheduled. It would replace Turbine, the current way of spreading blocks across validators.
Treat the numbers carefully. The 150 milliseconds is a target. A single dashboard reading showed 202 milliseconds, which is not a sustained average. The new consensus was also only a day old at the time of writing, so its behavior under heavy stress is unproven. For users, the Solana Foundation says transactions, programs and fees are unchanged.
How Sealevel runs transactions in parallel
Sealevel is Solana's runtime. Because each transaction declares its accounts up front, the runtime can see which ones overlap. Transactions touching different accounts run at the same time across CPU cores. Two that write to the same account must take turns. Several can read one account at once.
Smart contracts on Solana, called programs, keep their data in separate accounts, which is what makes this possible. Solana's approach is to scale one chain directly, while Ethereum's plan leans on layer 2 rollups.
Local fee markets
A local fee market means congestion raises prices only for the transactions competing over the busy accounts. The base fee is fixed at 5,000 lamports per signature, which is 0.000005 SOL. On top sits an optional priority fee, set per compute unit.
Compare this with a single network-wide price for gas fees, where one popular mint can make everything more expensive. On Solana, a block also caps the compute that can write to any one account, so a rush on one token can't fill the block by itself. A hot market can still get expensive, but a simple transfer elsewhere should not.
Firedancer and client diversity
Firedancer is an independent validator client written in C, developed mainly by Jump Crypto. It went live on mainnet in December 2025. A second codebase matters because one bug in a shared client can stop the whole network.
Solana is still short of that goal. Fidelity's FCAT data from October 2026 showed about 63% of stake on Jito-based clients, about 24% on Harmonic variants and about 15% on Firedancer-labeled setups, all before the switch. The Alpenglow switch itself required Agave-based software. Firedancer's release notes mark v26.10.2 as mainnet-ready with Alpenglow support, but say migration from Tower to Alpenglow is unsupported, so operators had to leave for the handoff.
Outages: what has gone wrong
Solana halted repeatedly in its early years, and restarts needed validators to coordinate. Helius's history lists these:
| Date | Length | Cause |
|---|---|---|
| December 2020 | About 6 hours | Block propagation bug |
| September 14, 2021 | About 17 hours | Bot transaction flood during a token sale |
| April 30, 2022 | About 8 hours | NFT mint spam crashed validators |
| June 2022 | About 4.5 hours | Durable nonce bug split consensus |
| September 2022 | About 8.5 hours | Duplicate blocks and a fork-choice bug |
| February 2023 | Almost 19 hours | An oversized block flooded the network |
| February 2024 | Almost 5 hours | Compiler cache bug caused an endless loop |
FCAT reports no mainnet outage across the past two years. That record predates Alpenglow, which hasn't yet been tested by anything comparable.
The hardware and decentralization trade-off
Speed costs money. Anza's recommended validator specs list at least 12 cores, 256 GB of RAM, multiple NVMe drives and a 10 Gbit/s connection. Ethereum's recommended specs for a validating node are 8 cores, 64 GB of RAM and a 25 Mbit/s upload. Helius calls home operation impractical on Solana.
The results show up in Solana Compass's review of FCAT's report, with figures as of October 2026:
- Validators: 678 with active stake.
- Validators holding a third of stake: about 18.
- Geography: roughly 40% of stake in Frankfurt and Amsterdam.
- Hosting: the largest network provider holds about 29% of stake, above the Solana Foundation's 25% target.
One operator can also run several validators, so the true count of independent parties is lower. Validators now pay a flat 0.8 SOL per epoch to take part, replacing vote fees. Epochs now last about a day, so that is a real running cost. For more, see our Solana hub and performance coverage.
Key takeaways
- Solana's speed comes from a known leader schedule, no mempool, parallel execution and very short slots.
- Proof of history no longer paces blocks. Since October 21, 2026, Alpenglow's Votor has replaced Tower BFT, with a 150-millisecond finality target still to be proven.
- Treat 65,000 TPS and 1 million TPS as theoretical or test figures. Observed user activity ran near 2,000 to 2,600 TPS in October 2026.
- Local fee markets keep congestion on busy accounts from raising fees everywhere.
- Solana has had seven major outages, though none in the two years before this upgrade.
- The trade-off is costly hardware, concentrated hosting and low client diversity.
Sources
Get the weekly commit
New blockchain deep dives every week.
