TPS (Transactions Per Second) is a common performance metric used to measure the number of transactions a blockchain network can process within a given period. It is also an important technical parameter in the competition among high-performance public blockchains. As public blockchains such as Solana, Sui, and Aptos continue to optimize parallel execution, consensus mechanisms, and transaction processing architectures, the blockchain industry has gradually shifted from its early focus on transaction costs and confirmation speed toward exploring higher throughput, lower latency, and more complex on-chain application scenarios.
However, a public blockchain's ability to process more transactions does not necessarily mean that there is an equivalent level of real user demand. One network may reach extremely high TPS in a testing environment but maintain low transaction activity on its mainnet over the long term. Another network may have lower TPS but support substantial stablecoin settlements, financial transactions, and high-value asset transfers. So, what can TPS actually measure? Why doesn't theoretical throughput equal actual transaction demand? And how should investors determine whether a high-performance public blockchain has achieved genuine market adoption?
Key Takeaways
-
TPS measures a blockchain's transaction processing capacity, but does not directly represent the network's value. High TPS shows that a network has the potential to process a large number of transactions, but does not prove that those transactions come from genuine user demand.
-
Theoretical TPS and actual TPS are materially different. Performance records achieved in testing environments may be affected by transaction types, hardware configurations, and network conditions, and cannot be directly equated with long-term mainnet performance.
-
An increase in transaction volume does not necessarily mean that economic activity has grown at the same pace. Bot transactions, arbitrage, low-cost repetitive operations, and system transactions can all increase on-chain TPS.
-
Genuine transaction demand needs to be assessed using multiple metrics. Active users, transaction fees, application revenue, stablecoin settlement volume, and user retention can reflect network usage more effectively than TPS alone.
-
Blockchain performance requires a balance among throughput, latency, cost, and decentralization. Higher processing capacity may improve the user experience, but it may also increase validator hardware requirements and network operating costs.
TPS refers to the number of transactions a blockchain network processes per second and is commonly used to describe its transaction throughput. For example, if a public blockchain processes 60,000 transactions in one minute, its average TPS is 1,000. For blockchains that need to support payments, trading, gaming, and other high-frequency applications, TPS helps developers understand how much transaction activity the network can support under specific conditions. It also reflects the efficiency of the network architecture when processing a large number of operations.
Early blockchains typically used relatively conservative block capacity and block production mechanisms to reduce node verification costs and maintain network security. As on-chain applications continued to develop, transaction demand expanded from simple asset transfers to decentralized trading, lending, gaming, and automated execution. Network processing capacity therefore became an important factor affecting the user experience. If transaction volume exceeds a network's processing capacity, users may face transaction queues, higher fees, or longer confirmation times. As a result, increasing TPS has become an important direction for scaling public blockchains.
However, TPS is only one aspect of blockchain performance. Different networks may define, execute, and count transactions differently. Simply comparing the TPS figures of two public blockchains cannot fully reflect their actual processing capabilities. For example, a standard token transfer and a complex transaction involving multiple smart contracts may differ significantly in their consumption of computing resources and state updates. TPS is therefore better suited to observing a specific network's throughput under clearly defined conditions than to serving as a universal ranking standard for the overall performance of different public blockchains.
What Is the Difference Between Theoretical TPS and Actual TPS?
Theoretical TPS generally refers to the transaction processing capacity a network can achieve under specific technical assumptions or in a testing environment, while actual TPS reflects the number of transactions the network processes under real operating conditions. The difference between the two mainly results from transaction complexity, network conditions, node hardware configurations, and actual user demand. A public blockchain may use a large number of simple transfer transactions in a controlled testing environment to achieve high throughput. However, when the mainnet runs complex smart contracts, processes cross-application calls, and faces real-world network latency, its sustained throughput may be significantly lower than the test results.
In addition, testing environments can control transaction inputs, node configurations, and network loads, while real mainnets must operate under more complex conditions. Validators may be distributed across different regions, with varying network bandwidth and hardware performance. Transactions may also involve state contention among different accounts. If a network uses a parallel execution architecture, whether multiple transactions can be processed simultaneously also depends on whether they access the same accounts or share the same state. When a large number of transactions concentrate on the same popular application, even a network with high theoretical parallel processing capacity may be constrained by localized resource contention.
Therefore, when evaluating public blockchain performance, it is important to distinguish among peak theoretical TPS, testnet TPS, actual mainnet TPS, and long-term sustainable throughput. Compared with the highest record achieved over a short period, a network's ability to process transactions continuously under high load, maintain stable confirmation times, and avoid a significant increase in failure rates is generally more meaningful in practice.
Why Doesn't Higher TPS Mean Greater Real Transaction Demand?
TPS measures the number of transactions processed, while real transaction demand reflects whether users are willing to continue using a network to conduct economic activities with a practical purpose. The two are related but not identical. For example, a public blockchain may attract large numbers of automated bots to perform repetitive transfers, arbitrage, or other high-frequency operations because its fees are extremely low, resulting in high TPS. However, these transactions may not correspond to a large number of unique users or generate a comparable amount of economic value.
In decentralized trading markets, automated market makers, arbitrage bots, and liquidation programs may continuously initiate transactions to capture price differences across markets. These operations serve a practical function for high-frequency trading applications, but their transaction volume may be far higher than the manual trading frequency of ordinary users. If all on-chain transactions are treated as demand from unique users, the network's user base may be overstated. Similarly, some low-cost on-chain activity may be driven by incentive programs, points systems, or short-term market trends. Transaction volume may decline rapidly after the activity ends.
Therefore, high TPS may indicate that a network is supporting a large number of real applications, but it may also reflect dense transaction activity generated by a small number of automated programs. When evaluating demand, it is necessary to further examine who initiated the transactions, which applications they primarily involve, whether they generate sustained fee revenue, and whether the activity can continue after incentives are reduced. The truly important question is not how many transactions the network processes per second, but whether those transactions form sustainable use cases.
Solana and Sui are both focused on high-performance blockchain technology, but they use different transaction execution architectures and performance optimization methods. Solana improves transaction processing efficiency through parallel execution, account state management, and a high-performance validator architecture. Sui optimizes throughput and transaction confirmation speed through its object-oriented data model, parallel execution, and Mysticeti consensus mechanism. Because the two networks have different transaction structures and measurement methods, directly comparing their published TPS figures may not accurately reflect real-world application performance.
In October 2026, Sui's Tunnel architecture achieved a peak TPS of more than 40 million during a performance activity. However, this metric measured operations within the off-chain Tunnel rather than on-chain transactions executed directly by the Sui mainnet. The test used 1,920 on-chain lifecycle transactions to support the initiation and settlement of more than 15.2 billion off-chain operations. By comparison, when analyzing Solana's actual transaction statistics, it is important to determine whether validator vote transactions are included and whether failed transactions are counted. Both technical approaches can increase the system's capacity to process activity, but their throughput metrics cannot simply be treated as the same type of on-chain transaction.
Therefore, when comparing high-performance public blockchains, it is necessary to use consistent measurement standards and clarify whether the data comes from the mainnet or a testing environment, whether it includes off-chain operations, whether the transactions executed successfully, and how computationally complex the different transactions were. For developers, the execution efficiency, confirmation latency, and fee performance of a specific application under real-world workloads are often more useful references than a single peak TPS figure.
Why Do Bot Transactions and Failed Transactions Also Affect TPS?
High-performance public blockchains typically have low per-transaction costs, allowing automated programs to submit transactions at high frequencies. In DeFi markets, arbitrage bots may continuously monitor price differences among liquidity pools, liquidation programs may automatically execute operations based on changes in collateral ratios, and market-making strategies may frequently adjust orders. These transactions may serve real economic functions, but their number does not equal the number of unique users. One automated address initiating tens of thousands of transactions per day may produce a similar result in TPS statistics as tens of thousands of users each completing one payment, even though the two represent entirely different levels of market demand.
Failed transactions also require separate analysis. On some blockchains, a transaction may consume network resources and be included in relevant transaction statistics even if it ultimately fails. For example, if a market price changes after an arbitrage bot submits a transaction and causes the preset slippage conditions to no longer be met, the transaction may revert. However, the network still consumes computing resources to order and execute it. In the first quarter of 2026, Solana processed approximately 10.1 billion non-vote transactions, of which approximately 25.6% were unsuccessful. This shows that even after consensus votes are excluded, total transaction volume does not fully equal successfully completed economic activity.
Therefore, when analyzing TPS, it is necessary to further distinguish among consensus transactions, ordinary user transactions, automated transactions, and failed transactions. Bot activity is not inherently without value. Some automated transactions can improve price discovery and the efficiency of capital allocation. However, their volume should not be directly treated as a measure of user adoption. A more reasonable approach is to consider the successful transaction ratio, computing resource consumption, distribution of transaction-sending addresses, and application types to determine the actual composition of network activity.
Why Doesn't an Increase in On-Chain Transaction Volume Necessarily Lead to Higher Network Revenue?
There is no fixed relationship between a public blockchain's transaction volume and its network revenue. Transaction fees are generally affected by the fee model, computing resource consumption, network congestion, and priority fee mechanisms. When a network can process a large number of transactions at low cost, total fees paid by users may not increase at the same rate even if TPS rises significantly. For example, if one network processes 10 million transactions per day and the average fee per transaction is only $0.0001, its total fees would be approximately $1,000. Another network may process only 100,000 transactions per day but charge an average fee of $0.10 per transaction, resulting in total fees of $10,000.
However, total fees do not fully equal the economic returns actually received by the network or token holders. Some fees may be paid to validators, some may be burned, and others may go to applications, sequencers, or other infrastructure participants. Therefore, when evaluating the economic performance of a public blockchain, it is necessary to distinguish among fees paid by users, revenue retained by the protocol, validator revenue, and the token value capture mechanism. Fee distribution rules differ across networks, so transaction fees cannot simply be treated as project profits.
In addition, low fees are not inherently a disadvantage. For payment, gaming, and high-frequency interaction applications, low transaction costs may be necessary to generate real demand. The key question is whether the network can create sustainable economic activity through continued growth in usage and provide sufficient incentives for validators, security maintenance, and infrastructure operations. TPS and network revenue should therefore be analyzed together rather than pursuing higher transaction volume or higher average fees in isolation.
Which Metrics Reflect a Public Blockchain's Real Transaction Demand Better Than TPS?
Determining whether a public blockchain has achieved genuine market adoption requires analysis across multiple dimensions, including user scale, economic activity, application usage, and long-term retention. Active addresses can help indicate network participation, but one user may control multiple addresses, while one address may be managed by a bot or an institutional system. Active addresses therefore cannot be directly equated with the number of real users. Transaction fees can reflect the costs that some users are willing to pay for network services, but fee mechanisms differ across public blockchains, so fees must still be understood in the context of transaction volume and application types.
For DeFi public blockchains, relevant metrics include decentralized exchange volume, lending demand, stablecoin circulation and settlement volume, and the sustained revenue of major applications. For payment-oriented networks, it is also necessary to analyze actual payment scenarios, transaction frequency, settlement amounts, and repeat usage. TVL can reflect the value of assets locked in on-chain protocols, but it may be affected by asset price changes, liquidity incentives, and double counting. It should not be treated as a complete representation of user demand.
| Evaluation Dimension |
Key Metrics |
Points to Consider |
| Network performance |
Actual TPS, confirmation latency, success rate |
Whether consistent measurement standards are used |
| User activity |
Active addresses, repeat usage rate |
Addresses do not equal unique users |
| Economic activity |
DEX volume, stablecoin settlement volume |
May include arbitrage and internal capital circulation |
| Network fees |
Total fees, average transaction cost |
Fees may not all belong to the protocol |
| Application ecosystem |
Active applications, protocol revenue |
Revenue sustainability should be considered |
| Capital utilization |
TVL, lending volume |
May be affected by token prices and incentives |
| Long-term demand |
User retention, transaction continuity |
The impact of short-term activities should be excluded |
Overall, real transaction demand is closer to a user's ability to continue using a network to complete valuable operations than to the number of transactions at any given point in time. For high-performance public blockchains in particular, it is important to observe whether newly added capacity is actually being used by applications and whether usage can continue after subsidies or short-term market trends end.
Does Higher TPS Affect the Decentralization and Security of Public Blockchains?
Increasing TPS generally requires improvements in transaction execution, data propagation, and node processing efficiency. However, different scaling solutions may have different effects on network operating costs. For example, if a public blockchain primarily increases throughput by raising hardware requirements for validators, nodes may need greater CPU performance, memory, storage, and network bandwidth. When operating costs exceed what some participants can afford, the number and distribution of validators may be affected, prompting discussion about the degree of decentralization.
However, higher TPS does not necessarily reduce decentralization. Parallel execution, optimized state access, data compression, and improvements to consensus protocols may also increase network efficiency without proportionally increasing hardware costs. Sui's Mysticeti, for example, improves performance by optimizing the consensus messaging process and parallel processing capabilities. However, its published benchmark tests also clearly distinguish between throughput in controlled environments and metrics from actual production networks.
Therefore, when evaluating scaling technologies, it is necessary to consider throughput, time to finality, node operating requirements, and fault recovery capabilities at the same time. Even if a network can process a large number of transactions, its overall performance may still be limited if it frequently experiences confirmation delays, failed transactions, or validator centralization under high load. A truly mature high-performance public blockchain should improve processing capacity while maintaining verifiability, stability, and reasonable participation costs.
For public blockchains in the early stages of development, building sufficient throughput capacity in advance can be reasonable. Networks need to reserve capacity for future applications and avoid immediate congestion when the user base grows. However, if applications capable of using that capacity sustainably are lacking over the long term, high theoretical TPS may simply represent technical capacity that has not been fully utilized. The development of a public blockchain ecosystem depends not only on underlying execution performance but also on developer tools, wallet experience, liquidity, application security, and stable user access points.
Different applications also have different performance requirements. Stablecoin payments may place greater emphasis on transaction certainty, fee stability, and settlement reliability. Decentralized exchanges may prioritize execution latency, transaction ordering, and liquidity. On-chain games may require high-frequency interactions and low-cost state updates. In some scenarios, high TPS is indeed an important condition for delivering a good product experience. In others, security, asset liquidity, and the developer ecosystem may be more important than extremely high throughput.
Therefore, competition among public blockchains should not focus solely on a single performance figure. More important considerations include whether the network's throughput matches application demand, whether technological improvements reduce the actual costs for developers and users, and whether the ecosystem generates sustained transaction activity and economic revenue. TPS determines the scale of transaction demand that a network can support, while application adoption and economic activity determine whether that capacity can create real value.
Summary
TPS is an important metric for measuring a blockchain's transaction processing capacity, but it cannot by itself represent a public blockchain's technical maturity, real transaction demand, or economic value. Theoretical tests, off-chain operations, and actual mainnet transactions use different measurement standards. Bot transactions and failed transactions may also affect the final figure. As a result, the TPS figures published by different networks need to be compared under consistent conditions.
For high-performance public blockchains, the value of increasing throughput lies in reducing transaction congestion, improving the user experience, and providing more operating capacity for applications. However, whether a network can achieve long-term market adoption still depends on real user activity, the application ecosystem, transaction fees, network stability, and economic sustainability. Rather than pursuing constantly updated TPS records, it is more important to determine whether the network genuinely needs this processing capacity and whether that capacity translates into sustained on-chain usage.
FAQ
Is a Public Blockchain Better If It Has Higher TPS?
Not necessarily. TPS reflects only transaction throughput. A public blockchain's overall performance also depends on confirmation speed, transaction success rate, security, decentralization, and real application demand.
What Is the Difference Between Theoretical TPS and Actual TPS?
Theoretical TPS usually comes from specific technical assumptions or testing environments, while actual TPS reflects the number of transactions processed by a network under real operating conditions. The two may differ significantly due to transaction complexity, hardware configurations, and network conditions.
Why Does Solana's TPS Data Need to Distinguish Vote Transactions?
Solana's consensus votes may be counted as on-chain transactions in total transaction volume, but these operations do not directly represent ordinary users' payment or smart contract usage needs. Therefore, non-vote transactions are generally analyzed separately when evaluating economic activity.
Does Sui's TPS in the Tens of Millions Mean That the Mainnet Processes Tens of Millions of On-Chain Transactions Per Second?
No. The high-throughput record came from off-chain operations within the Tunnel architecture. These operations can be executed off-chain and use on-chain transactions for initiation and settlement. They cannot be directly equated with the Sui mainnet's native transaction TPS.
Which Metrics Can Help Determine Whether a Public Blockchain Has Genuine Demand?
Relevant metrics include the number of successful transactions, active users, user retention, stablecoin settlement volume, DEX volume, protocol revenue, and transaction fees. It is also important to observe whether these metrics can be sustained over the long term.
Does Higher TPS Necessarily Reduce Transaction Fees?
Not necessarily. Higher throughput may ease network congestion, but actual fees also depend on the network's fee model, computing resource requirements, priority fee mechanism, and market usage.
