How Fast Is Solana in 2026? TPS, Compute Limits, Throughput

Q: How many transactions per second can Solana do?

Sustained real-world throughput rose from roughly 1,700 transactions per second in mid-2025 toward several thousand per second in 2026. Stress tests have briefly exceeded 100,000 transactions per second, and the Firedancer client has demonstrated over one million per second in testing, though that is a hardware ceiling rather than typical mainnet load.

Q: Why are Solana's TPS numbers confusing?

Historically a large share of Solana transactions were validator votes, which inflated raw TPS figures relative to actual user activity. The Alpenglow upgrade moves votes off-chain, so headline TPS numbers measured before and after activation are not directly comparable.

Q: How long is a Solana slot?

A Solana slot is roughly 400 milliseconds, and an epoch is about 432,000 slots, which works out to roughly two to three days. The slot cadence itself is not changing under the planned 2026 consensus upgrade.

"How fast is Solana?" is one of the most-searched questions about the network, and one of the most poorly answered. Headline numbers range from a few thousand transactions per second to over a million, and they are all "true" in different senses. This guide separates real-world throughput from stress-test ceilings, explains the block-limit changes driving capacity in 2026, and clears up why Solana's TPS figures are so easy to misread.

Quick answer

In 2026, Solana sustains several thousand transactions per second in normal production, up from roughly 1,700 per second in mid-2025. Stress tests have briefly passed 100,000 per second, and the Firedancer client has shown over one million per second in testing. The gap exists because real throughput is limited by demand and protocol block limits, not by the software's ceiling.

~1,700

Sustained TPS mid-2025, rising since

100K+

Stress-test peak TPS

1M+

Firedancer test ceiling TPS

60M

CU per-block limit (SIMD-0256)

On this page

Real throughput versus stress tests
Compute units and the block limit
SIMD-0286 and SIMD-0370
Why TPS numbers are misread
How client and protocol interact
Frequently asked questions

Real throughput versus stress-test ceilings

The first thing to understand is that there are several different "TPS" numbers, and they measure different things.

Number	What it measures	Approximate value
Sustained production TPS	Normal day-to-day mainnet load	~1,700 in mid-2025, rising toward several thousand in 2026
Stress-test peak	Controlled tests and extreme events	Briefly past 100,000
Frankendancer live demo	Hybrid client in live conditions	Several hundred thousand
Firedancer test ceiling	Independent client on commodity hardware	Over 1,000,000

The headline million-per-second figure is a hardware-and-software capability, not a description of typical mainnet traffic. Real throughput is constrained by how many transactions users actually submit and by the protocol's block limits, both of which sit far below the client's raw capacity. A useful real-world data point: during the large market sell-off in October 2025, the network sustained very high packet rates and full blocks without service degradation, which is exactly the kind of stress that used to break it.

What is a compute unit, and what is the block limit?

Solana meters work in compute units (CUs), roughly analogous to Ethereum's gas. Every transaction requests a compute-unit limit up front, and each block has a maximum total compute budget. Block limits exist primarily to ensure the vast majority of validators can keep pace with block production: they cap how much work a leader is allowed to pack into a block.

The block limit has been rising. In mid-2025, SIMD-0256 raised the per-block ceiling to 60 million compute units, which at the time helped the network process around 1,700 transactions per second during daytime traffic. Each block spans roughly 400 milliseconds, so this budget is consumed and refreshed several times per second.

SIMD-0286 and SIMD-0370: where block capacity is heading

Two proposals define the next stage of Solana's capacity story.

SIMD-0286

Raise the block limit to 100M CU

Proposes raising the per-block limit from 60 million to 100 million compute units, a 66% increase, authored by Jito Labs' Lucas Bruder. The motivation is that recent mainnet performance suggests blocks are no longer constrained by execution time, so heavy applications such as order-book exchanges and complex multi-step DeFi transactions can be given more room before they hit "compute budget exceeded" errors. Crucially, it raises only the total block limit; the per-account write limit (roughly 12 million compute units) stays the same, so the extra capacity benefits parallelizable transactions like swaps and mints rather than adding pressure on any single account.

SIMD-0370

Remove the fixed block limit entirely

From the Firedancer team at Jump Crypto, goes further: it proposes removing the fixed block limit entirely so that block size scales dynamically, bounded only by the processing capability of the most performant validators. The idea is a "performance flywheel," where well-resourced block producers upgrade hardware to pack more transactions and earn more rewards, lifting overall network capacity. This proposal is positioned to build on the foundational improvements from the Alpenglow upgrade.

A real debate, not just hype: dynamic or larger blocks raise legitimate centralization concerns. If keeping up requires ever more expensive hardware, smaller validators could be squeezed out, concentrating stake among a few powerful operators. This trade-off between raw throughput and decentralization is actively contested in Solana governance.

Why Solana's TPS numbers are so easy to misread

Here is the nuance that almost every "Solana does X TPS" claim ignores: historically, a large majority of Solana's transactions were validator votes, not user activity. Votes have made up roughly three-quarters of transactions, which means raw TPS figures substantially overstate genuine user throughput.

This matters enormously for 2026, because the Alpenglow upgrade moves validator votes off-chain. Once that happens, vote transactions stop appearing in the count, so the raw TPS number will drop even as usable capacity for real transactions rises. In other words, headline TPS before and after Alpenglow will not be comparing the same thing. When you read a Solana throughput statistic, always ask whether it includes vote transactions.

The one question to ask: does this TPS figure include validator votes? Before Alpenglow, roughly three-quarters of transactions were votes. After it, they vanish from the count, so a lower headline number can actually mean more real user capacity.

How the client and the protocol interact

It is worth being clear about what limits throughput today. The Firedancer client can already process far more than current block limits permit, so in 2026 the binding constraint is increasingly the protocol's block limits and validator hardware, not the client software. That is precisely why the block-limit proposals above exist: the software outran the protocol's caps.

Beyond block limits, the network's longer-term scaling work targets the physical layer too. An initiative often summarized as "increase bandwidth, reduce latency" underpins much of this roadmap, and a dedicated low-latency networking layer for validators (delivering block data over private fiber) has been rolling out to improve propagation. The Solana Foundation has tied these efforts to an explicit ambition to support internet-scale capital markets later this decade.

Key takeaways

• Sustained production throughput is several thousand TPS in 2026, up from ~1,700 in mid-2025.
• Stress tests exceed 100,000 TPS, and Firedancer has shown over 1,000,000 TPS in testing.
• The block limit reached 60 million compute units; SIMD-0286 and SIMD-0370 push it higher or remove it.
• Most historical TPS was validator votes; Alpenglow's vote removal changes the accounting.
• The bottleneck is now block limits and hardware, not the client software.

Frequently asked questions

How many transactions per second can Solana do?

Sustained real-world throughput rose from roughly 1,700 per second in mid-2025 toward several thousand per second in 2026. Stress tests have briefly exceeded 100,000 per second, and Firedancer has demonstrated over one million per second in testing, which is a hardware ceiling rather than typical load.

What is Solana's block limit?

The per-block compute limit was raised to 60 million compute units in mid-2025. SIMD-0286 proposes raising it toward 100 million, and SIMD-0370 proposes removing the static cap entirely so blocks scale with the most performant validators.

Why are Solana's TPS numbers confusing?

Historically a large share of transactions were validator votes, which inflated raw TPS relative to user activity. Alpenglow moves votes off-chain, so figures before and after activation are not directly comparable.

How long is a Solana slot?

A slot is roughly 400 milliseconds, and an epoch is about 432,000 slots (roughly two to three days). The slot cadence is not changing under the planned 2026 consensus upgrade.

What limits Solana's throughput, the software or the hardware?

Increasingly the protocol's block limits and validator hardware. Firedancer can process far more than current block limits allow, which is why proposals like SIMD-0370 aim to let block size scale with validator capacity.

High throughput is only useful if you can read it.

More transactions per second means more on-chain activity to track. SolanaHolderBot watches holder growth, whale moves, and distribution shifts in real time, so the signal does not get lost in the volume. Set it up in minutes.

Try SolanaHolderBot