.png){kind=logo}
Solana follows a different scaling philosophy from Ethereum. Rather than relying primarily on Layer 2 networks, Solana aims to expand capacity directly on its base layer while reducing the time between network updates. Recent upgrades show how aggressively that architecture is being pushed.
A Solana slot is the period during which a designated validator can produce a block. The network historically targeted about 400 milliseconds per slot, but SIMD-0525 is progressively cutting that figure.
Mainnet moved to 350ms and then 300ms in August 2026. Solana’s September 18 changelog confirmed activation of a further reduction to 250ms, equivalent to four targeted slots per second. The longer-term target remains 200ms. Shorter slots provide wallets, exchanges and trading applications with more frequent state updates.
Transaction-per-second figures require context, as Solana statistics have historically included validator voting activity. User TPS separates transactions generated by applications and users.
The Solana Foundation reported in September that the network had sustained more than 5,000 user TPS for the first time. August also produced a record 216 million non-vote transactions in one day and 1.32 billion during the week of August 17-23.
Capacity expanded separately from slot speed. SIMD-0286 raised Solana’s block compute limit to 100 million compute units in July, increasing the computational work that can fit within blocks.
Reducing target slot time from 300ms to 250ms increases targeted slot frequency by 20%, but it does not automatically increase usable throughput by the same percentage.
Transactions consume compute units, and performance depends on transaction complexity, account contention, bandwidth, validator hardware and scheduling efficiency. Applications competing to modify the same accounts can still encounter congestion even when headline network capacity is high.
Throughput matters only when the network remains available. On August 12, a routing failure at infrastructure provider TeraSwitch knocked nearly 29% of Solana’s stake offline. Blocks continued to be produced and transactions continued landing, with the provider recovering in just over 30 minutes. Solana says it maintained 100% uptime since February 2024.
The next major change is Alpenglow. Solana says its Votor consensus protocol targets roughly 150ms finality, compared with about 12.8 seconds under TowerBFT. Importantly, 150ms refers to finality, not slot time. Alpenglow’s first phase is expected with Agave 4.3.
Solana throughput cannot be reduced to one TPS figure. Slot speed, compute capacity, user activity and finality measure different aspects of performance as real-world application demand continues growing across Solana. Faster slots and Alpenglow could improve responsiveness, but sustainable scaling still depends on validator capacity, network resilience and efficient execution.
Also Read: Can Solana Hold Key Support as DeFi Competition Intensifies?
1. How many transactions per second can Solana process?
Solana sustained more than 5,000 user transactions per second in September 2026. User TPS excludes validator voting activity, making it more useful for understanding actual application and user demand.
2. What is Solana’s current target slot time?
Solana reduced its target slot time to 250 milliseconds in September 2026, equivalent to four targeted slots per second. SIMD-0525 ultimately aims to reduce it further to 200ms.
3. Does a faster Solana slot time automatically increase TPS?
Not proportionally. Throughput also depends on block compute limits, transaction complexity, account contention, bandwidth, validator hardware and scheduling efficiency.
4. What is Alpenglow and how will it improve Solana?
Alpenglow is Solana’s redesigned consensus architecture, with its Votor protocol targeting approximately 150ms finality. This could substantially reduce the time required for transactions to reach finality compared with TowerBFT.
5. What limits Solana’s overall network capacity?
Solana’s capacity is constrained by compute limits, validator resources, network bandwidth, transaction complexity and account contention. Sustainable scaling therefore requires more than simply increasing headline TPS or reducing slot times.
