Summary: Solana's transactions per second (TPS) number is one of the most cited and, at the same time, most misunderstood metrics in the crypto space. The theoretical cap is in the tens of thousands, while the sustainable mainnet number is in the low thousands. Starting October 21, 2026, thanks to the Alpenglow upgrade, all transactions are user transactions because validator votes never go through the blocks anymore. For your application, there are three critical numbers: TPS during peak times, how much throughput you get during the network congestion, and the latency between submission and finality. This article explains the way TPS is counted on the current Solana network, why there is such a huge difference, and how to think about throughput for your application.
Key Takeaways
- Solana's TPS numbers do not include any transactions other than user transactions. Since the introduction of the Votor consensus (Alpenglow) on mainnet on October 21, 2026 (epoch 1064), every transaction is a user transaction as validator votes are exchanged peer-to-peer and aggregated into BLS certificates, so no vote transaction ever enters a block. TPS figures from before that date included votes and are not comparable.
- A Solana block occurs every 200 ms (starting October 9, 2026) and finality is targeted at about 150 ms after the block (compared to about 12.8 seconds with TowerBFT).
confirmedandfinalizeddescribe the same state now.- The throughput cap on Solana is measured in compute units per block and per account, not transactions per block. The limit is 50 million compute units per 200 ms block (the 100 million of SIMD-0286 was set for 400 ms blocks and scales with slot time) and 20 million per writable account.
- The congestion on Solana is localized to the hot accounts: thousands of transactions can go through while just one pool is saturated. The per-account write budget is the bottleneck on Solana.
- For your application, throughput is a function of the priority fee and a staked submission path, not the network TPS.
How TPS is counted
Each Solana block (slot occurs every 200 ms) carries a list of transactions. The TPS number is a simple calculation of the number of transactions in recent blocks divided by the elapsed time. There are three aspects that may affect this calculation significantly:
User transactions only. The introduction of the Votor consensus (Alpenglow) on mainnet on October 21, 2026, shifted voting off-chain: the validator sends its vote to other validators directly, votes are aggregated into a BLS certificate, and the block finalizes once at least 80% of the stake notarizes the block in the first round (or 60% in the second round in case the fast path is missed). Proof of History no longer regulates the block production, and the tick entries stop appearing in the shred stream. As a result, each transaction inside a block is a transaction that a user or a program sends. If an explorer still shows a separate "non-vote" or "true" TPS line, that distinction is historical: the two lines are now the same number. Before October 21, 2026, the TPS data included votes, which constituted about two-thirds of the total, so a chart that spans the upgrade shows a drop that is an accounting change, not a loss of throughput.
Fails are counted. A transaction that runs and fails because of slippage checks, program errors, and so on takes up space in a block and is counted. At volatile times, many of the DEX transactions may fail, thus the TPS number looks high although successful user throughput is much lower.
Choosing the period of averaging makes a difference. A spike in one second versus the average over one day are very different things and with Solana blocks every 200 ms, the one-second period covers only five blocks.
Theoretical versus real throughput
There is a difference between the theoretical max and the real performance because of three reasons: real transactions are heavier than benchmark transactions, real networks have latency between leaders, and the limit is the per-block compute budget, not the transactions per block.
The real limit: compute units, not transaction count
Solana does not enforce a transactions-per-block limit. Solana enforces the compute-per-block limit and the per-account compute limit inside a block. A block can have up to 50 million compute units at today's 200 ms slots: SIMD-0286 raised the limit to 100 million on 29 July 2026 for 400 ms blocks, and SIMD-0525 scales the per-block limits with the slot time, so the capacity per second of 250 million units is unchanged. A single writable account can use up to 20 million per block, meaning one hot account can occupy at most 40% of a block. Anza has proposed raising the per-block limit back to 100 million; that is a discussion, not an active change. Each transaction requests and consumes compute units: a simple transfer transaction uses a few hundred units while a complex DEX route can cost hundreds of thousands of units. With blocks every 200 ms, the network offers those 50 million units five times a second.
Two important conclusions follow from the above:
First, heavy transactions lower the TPS. A block with many swaps can accommodate fewer transactions than the block with simple transfers. Therefore, the TPS is partially reflecting the workload of the network rather than the capacity.
Second, hot accounts create local congestion. Each account has its per-block write budget, and one hot pool or token can be saturated, while other parts of the network have a lot of capacity. That is the reason why one memecoin launch can saturate one DEX pool, making the trading unfeasible while other transfers go well. Congestion on Solana is localized, and so is the fee market. Priority fee estimation must take into account the accounts you interact with, not the global average. Solana transaction fees explained covers that market.
What TPS means for your application
The aggregate TPS tells you almost nothing about the chances of success of your transaction. Three numbers matter the most:
Priority relative to other transactions that target the same accounts. Trading the hot pool, you compete with everybody else who accesses that pool for its write budget and your priority is determined by the priority fee. Estimate the fees per pool, not globally.
Your submission path. During the congestion, the network leader prioritizes the transactions that came via staked connections first. Unstaked submissions are dropped first, regardless of the network capacity. A stake-weighted QoS lane or a Jito bundle preserves your throughput during TPS spikes. See Solana MEV relayers compared for the options.
Latency to finality. The transaction that lands in the next slot (200 ms) versus the transaction that is five slots behind are two different throughput numbers for your application even if the TPS is the same. Region matters: the distance to the current leader determines the minimum time. Alpenglow targets finality about 150 ms after a block is produced, so waiting for finalized takes almost nothing extra and confirmed is the same state (note: confirmed will be removed from the RPC in a later release; use finalized in new code). One effect of faster slots is that a blockhash still expires in 150 blocks, or about 30 seconds. So offline signing workflows have less time margin now.
For the read-heavy applications, the relevant question becomes how quickly you observe changes, which is dependent on your choice of data feed rather than TPS. Geyser and gRPC feeds now have a bank_id next to each slot, so the consumer application should buffer by both slot and bank. What is Shredstream covers the earliest possible observation point.
How to measure throughput that matters to you
- Landing rate: during the busy hour, out of transactions that you submit, how many of them land within two slots (400 ms)? That number reflects your effective throughput.
- Slot delta: the distribution of the gap between submitted and landed slots. The tail of the distribution is what your users actually experience.
- Failure rate: among your landed transactions, how many of them fail to execute because of the slippage or the stale state? Every failed transaction consumes the fee without any benefit.
- Compute units per transaction: are you requesting way too many compute units? Overrequesting adds to your cost and congests the blocks.
Tightening your compute budgets, estimating the priority per account, and submitting transactions via the staked connection path will increase your effective throughput much more than any network-wide change.
Why the headline number still matters
Aggregate TPS is a reasonable proxy for the health of the network and its ability to handle the load without degradation. Sustainable TPS in the thousands with the subsecond finality allows consumer applications to treat Solana as a transactional backend. Network upgrades of 2026 (100 million compute unit blocks in July, 200 ms slots in October, Alpenglow consensus on October 21, and new validator clients such as Firedancer) continuously increase the ceiling. Phase two of Alpenglow, Rotor, is still to come as the replacement of Turbine block propagation. But please, do not confuse the ceiling with your own throughput. The latter is engineered by you.
Conclusion
Solana's TPS headline is a single figure that mixes fails and light transactions and tells you almost nothing about your application. The throughput that matters to you is localized: the write budget of the accounts you access, your priority fee relative to others accessing the same accounts, and whether your transactions go through a staked path to a nearby leader. Measure landing rate during peak hours, tune the compute and priority fees, and engineer your own throughput, not the network's.
If you need the submission path that is resilient to the peaks in the headline TPS, OrbitFlare RPC plans provide the staked transaction landing in eleven regions.
