TPS in Blockchain: Transactions Per Second, Speed Metrics, and Real-World Capacity

Understanding transactions per second (TPS)

TPS is one of the first numbers people compare when evaluating blockchains, but it’s easy to misread. A network can advertise impressive throughput while offering a very different experience for a user swapping tokens, minting an NFT, or sending a payment during a busy period.

To use the metric properly, you need to understand what counts as a transaction, how much work each transaction requires, and whether the reported figure measures theoretical capacity, attempted activity, successful execution, or settled state changes.

How throughput works in distributed systems

In a distributed system, multiple computers coordinate to maintain a shared view of data. A blockchain uses this model to process transactions and agree on changes to its state, such as token balances, smart contract storage, or ownership records.

Throughput describes the rate at which a system processes work. For blockchain networks, TPS expresses that rate as transactions per second:

TPS=TransactionsprocessedElapsedtimeinseconds

Suppose a blockchain processes 18,000 transactions over a 60-second window. Its average throughput during that period is:

18,00060=300TPS

That calculation is simple. Deciding which transactions belong in the numerator is where comparisons get complicated.

A transaction may be submitted by a wallet but never included in a block. It may be included but fail during execution. It may execute successfully on a Layer 2 network but not yet be finalized on its settlement layer. Some networks also count consensus-related transactions that support network operation but do not represent an ordinary user action.

For a useful benchmark, I would want to know whether the number refers to:

• Submitted transactions: Requests sent to the network, including ones that may never be processed.
• Included transactions: Transactions accepted into blocks or batches, whether they succeed or fail.
• Successful transactions: Transactions whose intended state changes execute successfully.
• User-operation TPS: Successful application-level actions, ideally excluding consensus overhead and other non-user activity.
• Finalized transactions: Transactions whose results have reached the relevant network’s definition of finality.

These measures answer different questions. A high submitted-transaction rate can indicate strong demand, but it does not prove that the network is processing all those requests. A high included-transaction rate can also overstate useful work if many transactions fail or serve internal network functions.

Even successful transactions are not directly comparable across chains. A single transaction might transfer an asset from one wallet to another, execute a complex decentralized exchange swap, or bundle multiple instructions into one atomic operation. The transaction count is the same in the metric, but the computational work can be very different.

That is why TPS should be treated as one performance indicator, not a complete ranking of blockchain quality.

The mathematical formula for theoretical maximum TPS

A simplified throughput model estimates the number of transactions a network can process based on its available block capacity, the average resource cost of each transaction, and the time between blocks.

For a gas-limited blockchain, a useful approximation is:

\[ \text{Theoretical TPS}= \frac{\text{Block gas capacity}} {\text{Average gas per transaction}\times\text{Block time}} \]

For a byte-limited system, a similar approximation is:

\[ \text{Theoretical TPS}= \frac{\text{Block data capacity}} {\text{Average transaction size in bytes}\times\text{Block time}} \]

These are simplified models. Real protocols may impose additional constraints on execution, state access, signatures, block propagation, data availability, or transaction scheduling. Some networks also use multiple resource limits, meaning no single denominator captures their full capacity.

Let’s use Ethereum as an example. The Ethereum documentation describes a proof-of-stake block slot every 12 seconds; that timing is a consensus cadence, not a guarantee that every slot contains a full block of transactions. See the official explanation of Ethereum blocks.

For a deliberately simplified calculation, assume:

• Block gas capacity: 30,000,000 gas.
• Average transaction cost: 21,000 gas.
• Block interval: 12 seconds.

A basic native ETH transfer commonly uses 21,000 gas under ordinary conditions. Using the example figures:

30,000,00021,00012119.05TPS

This is the theoretical rate under those assumptions, not a claim that Ethereum L1 sustainably delivers 119 successful user transactions per second. The example assumes every block is full of transactions that all cost exactly 21,000 gas, leaving no capacity for contract calls or other transactions with different costs. Actual gas limits and usage also change over time.

A smart contract swap can consume substantially more gas than a simple transfer. If the average transaction costs 150,000 gas, the same simplified model gives:

30,000,000150,0001216.67TPS

Nothing about Ethereum’s block interval changed. The estimated throughput fell because each transaction consumed more of the available block capacity.

The same principle applies to byte-limited systems. If a block can carry 1 MB of transaction data and the average transaction occupies 500 bytes, a simple size-based estimate gives 2,000 transactions per block. If a block arrives every 10 seconds, the estimate becomes 200 TPS. In practice, signatures, metadata, protocol overhead, and transaction-format rules can reduce the usable capacity.

There is also a broader limitation: these formulas assume block capacity is the only bottleneck. In real distributed systems, a network must propagate data to other nodes, validate transactions, reach consensus, and maintain its state. Raising the block limit may increase nominal throughput while making those tasks harder.

For this reason, theoretical TPS is best treated as a first-pass engineering estimate. To understand actual capacity, you need measurements from live network activity or reproducible benchmarks that disclose their workload and test conditions.

Real-world TPS vs theoretical maximum TPS

A theoretical maximum is useful for understanding a protocol’s design limits, but it is not the same as sustained mainnet performance. Real networks operate with changing transaction demand, different workloads, variable hardware, and the need to keep nodes synchronized.

When you see a headline such as “65,000 TPS,” the right response isn’t automatically to dismiss it. Ask what the figure measures, which software version produced it, whether it came from a laboratory test or live mainnet activity, and how the system behaved while processing that workload.

Lab benchmarks vs real-time mainnet performance

A benchmark can test a controlled environment with selected transaction types, hardware, and network conditions. This is valuable for measuring engineering progress, but the result may not predict what the same network delivers in production.

For example, a test may use simple transfers between accounts that do not compete for the same state. Another may execute complex smart contracts that read and update shared data. The second workload may be much harder to parallelize, even if the two tests use the same number of transactions.

Real mainnet performance is affected by several factors:

Transaction complexity. Each transaction consumes resources. A basic transfer and a multi-step DeFi swap are not equivalent workloads.

Contention. Transactions that try to update the same account, storage slot, or liquidity pool may have to be processed in a particular order. This can limit parallel execution.

Network propagation. Validators and nodes need enough bandwidth to receive, verify, and distribute transaction data. Large blocks can take longer to propagate, increasing the chance of disagreement or missed opportunities to produce blocks.

Consensus overhead. Nodes must exchange information and agree on the canonical chain or ledger state. Some architectures count consensus-related activity in their transaction metrics; others report it separately.

Failed transactions. A system can spend computing resources processing requests that ultimately revert or fail. Counting every included transaction without distinguishing successful execution can exaggerate useful throughput.

Demand and congestion. A network that handles a short burst of transactions may not sustain the same rate continuously. During busy periods, users may encounter higher fees, delayed inclusion, or dropped requests.

A fair comparison should therefore disclose at least the observation window, transaction type, success rate, and whether consensus transactions are included. Ideally, it would also report latency percentiles, resource utilization, and sustained throughput over a sufficiently long period.

I would also distinguish peak throughput from average throughput. Peak TPS tells you what a system achieved during a specific interval; average TPS tells you how much activity it processed over a broader window. Neither tells the whole story alone.

The vote transaction inflation problem

Solana illustrates why counting rules matter. The network’s transaction metrics can include validator vote transactions, which are part of its consensus process rather than ordinary application actions initiated by end users.

Solana’s own RPC performance interface distinguishes total transactions from numNonVoteTransactions, allowing analysts to examine activity without vote transactions. This is documented in the official getRecentPerformanceSamples RPC reference. Its public data dashboard also separates vote and non-vote transaction counts through the Solana Data platform.

That distinction can produce materially different TPS figures. If a dashboard reports several thousand total transactions per second, you should check how many represent user-generated activity, how many are vote transactions, and how many user transactions succeed.

However, I would avoid claiming that Solana’s “true” user TPS is always 800–1,000. That range can be used as an illustrative estimate in some discussions, but it is not a fixed property of the network. User activity varies over time, and the result depends on whether the metric includes failed transactions, what time window is measured, and how the data source classifies activity.

Visa’s published analysis has also distinguished Solana’s user-generated throughput from its overall transaction counts. In a Visa analysis of Solana’s payment-network potential, Visa reported an average of around 400 user-generated TPS at the time of publication, with peaks above 2,000. That is a dated observation, not a current guarantee, and it should not be directly compared with a different network’s peak figure without matching the methodology.

This is the central point: the metric’s definition matters as much as the number itself. A network with a lower total TPS but more successful user operations may be more useful for a particular application than a network whose headline number includes substantial internal overhead.

Simple transfers vs complex smart contract computations

Transaction counts are especially misleading when comparing networks that support different types of application activity.

A native asset transfer usually involves a relatively small set of state changes. A smart contract transaction can do far more: execute a token swap, update liquidity positions, calculate fees, check permissions, and call other contracts. It may also require additional storage access or cryptographic operations.

Consider a decentralized exchange. One transaction might swap a token through a single liquidity pool. Another might route the trade across several pools, interact with multiple contracts, and update multiple balances. Both may count as one transaction even though the second uses considerably more computing resources.

This makes raw TPS a poor stand-alone measure of application capacity. If you’re building a payment app, you may care most about simple transfers, inclusion latency, and low fees. If you’re building a lending protocol, you need to know how well the chain handles complex state changes and contention around shared markets.

For technical benchmarking, I recommend comparing similar workloads:

• Simple transfers: Measure how many successful native or token transfers are processed per second.
• Contract calls: Use a representative smart contract rather than an empty or minimal transaction.
• DeFi workloads: Test swaps, lending operations, liquidations, or other interactions relevant to the application.
• Mixed workloads: Combine several transaction types to approximate real user activity.
• Stress conditions: Measure performance during congestion, high state contention, and partial node or infrastructure failure.

A benchmark that reflects your application will tell you more than a universal TPS leaderboard.

TPS vs time to finality (TTF)

TPS and time to finality are related, but they measure different things. TPS tells you how much transaction activity a network can process over time. Time to finality measures how long it takes before a transaction’s inclusion is considered irreversible under the system’s consensus rules.

Confusing the two can lead to poor technical decisions. A blockchain might process thousands of transactions per second yet require users to wait longer for strong settlement assurances. Another network may process fewer transactions but offer a simpler or faster path to finality.

What TPS and TTF tell you

A useful way to think about this is to separate three stages:

• Submission: Your wallet sends the transaction to the network.
• Inclusion or confirmation: A block or batch includes the transaction, and the application can often show a provisional result.
• Finality: The transaction reaches the settlement assurance defined by the protocol or application.

These stages don’t always occur at the same moment. A transaction may appear successful in a wallet before it reaches strong finality. Some applications accept a provisional confirmation because the risk is acceptable; others, especially exchanges or large-value financial systems, may wait for stronger guarantees.

Ethereum is a clear example. Its proof-of-stake consensus uses 12-second slots, but finality typically takes around 15 minutes under its current consensus design. The Ethereum documentation on single-slot finality explains the distinction and the ongoing work to reduce this delay. A 12-second slot therefore should not be interpreted as a guarantee that a transaction is finalized after 12 seconds.

The distinction also matters for Layer 2 rollups. An optimistic rollup may show a transaction as confirmed on the L2 well before the full withdrawal challenge period expires. Ethereum’s optimistic rollup documentation describes the fraud-proof model and the commonly used challenge period of about seven days for withdrawals to Ethereum L1. That delay concerns a particular settlement and withdrawal path; it does not mean every L2 transaction takes seven days to become usable within the L2.

For users, the right question is not simply “How fast is this blockchain?” It’s “How soon can I safely rely on this specific transaction for the action I want to take?”

Why high TPS doesn’t guarantee instant settlement

A high TPS figure can coexist with slow finality because the two metrics are constrained by different parts of the architecture. Transaction execution may be fast while consensus requires additional rounds of communication or a defined waiting period.

The reverse can also happen: a network may provide fast confirmation or finality for each transaction but have limited capacity under heavy demand. When activity exceeds available capacity, transactions may queue, fees can rise, and inclusion latency can increase even if the protocol’s nominal block time remains unchanged.

For an application, these differences affect design decisions:

• A retail payment app may accept a fast confirmation for small-value transactions while applying risk controls to larger ones.
• A centralized exchange may require a defined number of confirmations or protocol finality before crediting a deposit.
• A DeFi application may treat a transaction as complete within its chain while still considering cross-chain settlement pending.
• A bridge may require extra confirmations or proofs before releasing assets on another network.

Cross-chain applications make this especially important. A transaction can be finalized on one chain while a corresponding action on another chain still depends on relayers, proofs, liquidity providers, or bridge contracts. There is no single universal TTF for the entire cross-chain journey.

Blockchain TPS benchmarks: Layer 1s, Layer 2s, and legacy networks

Comparing blockchain TPS is useful when the methodology is consistent. It becomes misleading when theoretical maxima, short-lived peaks, mainnet averages, and settlement times are placed in the same table as if they were equivalent measurements.

The table below is a high-level reference, not a real-time leaderboard. Its figures are rounded, illustrative ranges or design claims drawn from different measurement methods. Actual throughput changes with network conditions, transaction mix, software versions, and the source’s counting rules. I would not use this table alone to select a chain for production.

Comparing network architectures and throughput

For Bitcoin, the familiar 3–7 TPS estimate is a rough calculation based on block timing and typical transaction sizes, not a fixed protocol ceiling for every possible transaction format. For Ethereum, the 12-second slot cadence and roughly 15-minute finality timing are described in Ethereum’s block documentation and its finality roadmap.

Solana provides a particularly useful example of why methodology matters: its official RPC interface makes it possible to distinguish total transaction counts from non-vote transactions. Visa, meanwhile, describes its network’s capacity as exceeding 65,000 transaction messages per second in its official network overview. Capacity under testing is not the same thing as average daily usage, and neither number alone measures the entire payment-settlement process.

How to read these benchmarks correctly

The most important distinction is between a capacity claim and a measured workload. A theoretical or laboratory result may show what a particular architecture could achieve under favorable conditions. A live mainnet figure shows what it actually processed during a specific window, given the workload and operating conditions at that time.

You should also avoid treating Layer 2 TPS as equivalent to Layer 1 TPS. A rollup processes transactions on its own execution layer and relies on another layer for some combination of data availability, settlement, and security. The L2 can offer a much higher rate of user activity, but the underlying L1 still imposes constraints on the amount of data the rollup can publish and on the security properties of its settlement process.

Likewise, comparing a blockchain’s transaction count directly with Visa’s can obscure important differences. Visa operates a centralized payment network with its own transaction definitions, authorization systems, and settlement relationships. Blockchain transactions may include consensus operations, contract interactions, or asset transfers that don’t map one-to-one to card payment messages.

If you’re choosing infrastructure for a real application, use a benchmark that reflects the transaction types, latency requirements, failure tolerance, and settlement assumptions your users actually need. A single headline TPS figure is a starting point, not the verdict.

 How modern blockchains scale TPS

Blockchain scaling is not simply a matter of making computers run faster. A network has to execute transactions, distribute the relevant data, verify state changes, and maintain agreement among participants. Each task introduces its own constraints, and improvements in one area can shift the bottleneck somewhere else.

Modern scaling strategies generally fall into three broad categories: process more work in parallel, move execution to another layer, or increase the amount of data the network can safely handle. Many blockchain ecosystems combine these approaches rather than relying on just one.

Sequential EVM execution vs. parallel processing

Ethereum’s EVM provides a standardized environment for executing smart contracts. Traditional transaction execution must preserve the ordering and state semantics defined by the protocol. When transactions depend on the same state, their effects cannot simply be applied in any order without potentially changing the result.

Consider two transactions:

• Transaction A updates a user’s balance in a lending protocol.
• Transaction B updates the same user’s balance in that protocol.

If B depends on the state produced by A, the system must preserve the relevant dependency. Running both operations concurrently without coordination could produce an incorrect result.

Now consider two transactions that update unrelated accounts and do not depend on one another. These may be candidates for parallel execution, provided the system can establish that their state access does not conflict and that the result remains equivalent to valid sequential execution.

Parallel execution attempts to exploit that second situation. Rather than processing every independent transaction one after another, an execution engine identifies operations that can safely run at the same time.

Different networks approach this in different ways. Solana’s runtime schedules transactions according to their account access patterns and resource requirements. Sui and Aptos use the Move programming language and execution architectures designed to support parallel processing where transaction dependencies permit it. Meanwhile, projects building parallel EVM implementations aim to improve concurrency while preserving compatibility with Ethereum’s programming environment.

The practical benefits can include higher throughput and lower latency under workloads with limited state contention. But parallelism isn’t free. The system needs to identify dependencies, coordinate shared state, and handle conflicts correctly. A workload that repeatedly touches the same popular liquidity pool may be harder to parallelize than a workload that updates independent accounts.

Parallel execution also doesn’t remove consensus or networking costs. Even if a validator can execute transactions on several CPU cores, it still has to receive transaction data, verify the resulting state, and participate in the network’s consensus process.

When evaluating a claim about parallel execution, I would ask whether the performance gain was measured on realistic smart contracts or on a synthetic workload that avoids state conflicts. Both tests can be useful, but they answer different questions.

Layer 2 rollups and modular architectures

Layer 2 rollups scale a blockchain by executing transactions outside the base layer and then publishing information needed to verify or settle the resulting state changes. Instead of asking Ethereum L1 to execute every user transaction individually, a rollup can process many transactions and submit compressed data or proofs to Ethereum.

This division of responsibilities is part of a modular architecture:

• Execution: The rollup processes user transactions and updates its own state.
• Data availability: Relevant transaction data is made available so that state changes can be checked or reconstructed according to the system’s security model.
• Settlement: The base layer provides the mechanism through which rollup state updates are accepted, challenged, or otherwise secured.

Optimistic rollups generally assume submitted state transitions are valid unless a challenge successfully demonstrates otherwise during the relevant dispute period. ZK rollups use validity proofs to demonstrate that state transitions satisfy the system’s rules. Both approaches can reduce the execution burden placed directly on Ethereum L1, but their security assumptions and operational details differ.

Ethereum’s documentation on optimistic rollups explains the relationship between rollup execution, data availability, fraud proofs, and withdrawal delays. For ZK rollups, proof generation and verification are central to the validity model, while data availability remains important for users who need to reconstruct or interact with the rollup’s state.

The throughput benefits can be substantial because one L1 data submission may represent many L2 user transactions. However, a rollup does not create unlimited capacity. Its execution environment, sequencer, transaction format, data publication budget, and L1 costs still impose constraints.

There is also an important difference between fast L2 confirmation and full settlement. A user may see a transaction complete on the rollup long before a withdrawal to Ethereum L1 is available under the rollup’s security model. For some applications, that is a reasonable trade-off. For others, the delay must be reflected in the product’s design.

Sharding and data availability (Danksharding)

Sharding is a family of approaches that divide network responsibilities so that every participant does not have to perform every task in exactly the same way. In a sharded design, different parts of the system can process or verify different portions of the workload, subject to mechanisms that preserve overall security and consistency.

Ethereum‘s roadmap uses the term Danksharding for a scaling approach focused on expanding data availability for rollups. The near-term improvements began with proto-danksharding, introduced through EIP-4844, which added blob-carrying transactions that give rollups a cheaper way to publish data. You can read the technical specification in EIP-4844 and the broader roadmap in Ethereum’s Danksharding documentation.

The idea is not that Ethereum L1 suddenly executes every L2 transaction. Instead, more affordable data publication can allow rollups to process and settle a greater volume of activity while relying on Ethereum for important security properties.

Data availability is crucial because users and independent verifiers need access to the data required to check state transitions or reconstruct state. Ethereum’s data availability documentation explains why publishing a summary without making the underlying transaction data available can undermine independent verification.

It is also important to distinguish data availability from permanent archival storage. Data needed to verify a recent rollup update does not necessarily need to remain stored forever by every node. Different components of the ecosystem can handle short-term availability and longer-term historical retrieval.

These improvements have trade-offs. More data capacity can lower rollup costs and improve throughput, but the network must still make that data available efficiently without imposing excessive hardware and bandwidth demands on participants. The design needs to balance scaling gains with the ability of independent nodes to verify the system.

In short, parallel execution helps process compatible transactions concurrently, rollups shift execution away from the base layer, and data-availability improvements help rollups publish the information needed for verification. These techniques can complement one another, but none makes the constraints of distributed systems disappear.

The scalability trilemma: The cost of ultra-high TPS

The scalability trilemma is a common way to describe the tension between decentralization, security, and scalability. It is a conceptual framework rather than a mathematical law proving that only two of these properties can ever be achieved. Still, it highlights a real engineering challenge: increasing capacity can raise the resources required to operate a node, while reducing verification requirements can change the network’s trust assumptions.

A blockchain’s TPS target should therefore be considered alongside its hardware requirements, state growth, networking demands, and validator economics. A network that delivers extremely high throughput but can only be verified by a small number of powerful operators may be a poor fit for applications that prioritize broad participation.

Hardware requirements and node centralization

Processing more transactions generally requires more computation, more data movement, and more state management. If a blockchain increases its block size or execution budget, validators may need more powerful CPUs, additional memory, faster storage, and higher network bandwidth to keep up.

The exact hardware requirement depends on the architecture and the type of workload. There is no universal rule that every high-throughput blockchain needs a 64-core CPU, 128 GB of RAM, or a 1 Gbps connection. Those figures may be reasonable for particular demanding environments, but they should not be presented as fixed requirements for every chain.

What matters is the relationship between resource demand and the number of people who can realistically operate nodes. If a network’s requirements rise faster than typical hardware capabilities or affordable connectivity, fewer independent participants may be able to validate the chain. This can concentrate infrastructure among professional operators or large service providers.

Centralization can also emerge in less obvious ways. Even if many validators technically exist, they may rely on a small number of cloud providers, geographic regions, client implementations, or infrastructure vendors. A disruption affecting one of those shared dependencies can affect a substantial portion of the network.

To assess this risk, look at more than the number of validators. Consider the distribution of stake, hardware requirements, geographic diversity, client diversity, network topology, and the practical process for an ordinary participant to run a node.

State bloat and storage overhead

Every transaction that changes blockchain state can add to the data a node must manage. Account balances, contract storage, token records, and other persistent information can accumulate as applications grow. Historical transaction data also has to be stored somewhere if users and infrastructure providers need to inspect or reconstruct the chain’s history.

At a sustained rate of 1,000 transactions per second, a network processes: 1,000606024=86,400,000

That is 86.4 million transactions per day. At 5,000 TPS, the same calculation yields 432 million transactions per day. These figures describe transaction counts, not storage size; the actual storage burden depends on transaction formats, state changes, compression, retention policies, and protocol overhead.

The distinction between historical data and current state is important. Historical records allow users to inspect past activity, while current state represents the data required to determine present balances and contract conditions. Different node types may retain different amounts of history, and some systems use pruning or external archival services to reduce the burden on ordinary nodes.

Pruning can reduce the amount of historical data a node needs to retain, but it does not make all storage concerns disappear. The network still needs reliable ways to verify new state transitions, maintain the current state, and make necessary historical information accessible when required.

Storage is also only part of the problem. A node must be able to process incoming data quickly enough to stay synchronized, verify the protocol’s rules, and recover after downtime. If the chain grows faster than nodes can reasonably download, validate, and store it, independent participation becomes harder.

For this reason, scalable blockchain design is about sustained performance rather than a one-time throughput record. A useful network should handle demand while preserving a reasonable path for independent verification, reliable recovery, and long-term data access.

Frequently asked questions about TPS

What is TPS (transactions per second) in crypto?

TPS measures how many transactions a blockchain or other transaction-processing system handles per second. It is commonly used to evaluate throughput and scalability, but its meaning depends on the measurement method. A useful TPS figure should clarify whether it counts submitted, included, successful, or finalized transactions and whether internal consensus activity is included.

What is the difference between real-world TPS and theoretical maximum TPS?

Theoretical maximum TPS estimates what a network could process under specified assumptions about block capacity, transaction size or gas cost, and block interval. Real-world TPS measures activity observed under actual operating conditions. It can be lower because of complex transactions, network overhead, state contention, failed execution, and other resource constraints. For a meaningful comparison, use similar workloads and measurement windows.

Why does time to finality matter as much as TPS?

TPS measures processing capacity, while time to finality measures how long it takes for a transaction to reach the protocol’s final settlement assurance. A network may process many transactions quickly but require additional time before users can confidently treat them as irreversible. For exchanges, bridges, and financial applications, finality can be just as important as throughput because it affects settlement risk and when funds can safely be reused.

How does Bitcoin or Ethereum’s TPS compare to Visa?

Bitcoin is commonly estimated to process roughly 3–7 transactions per second under typical block and transaction-size assumptions. Ethereum L1’s throughput varies with gas limits and transaction complexity, while Visa has stated that its network can handle more than 65,000 transaction messages per second under capacity testing. These figures are not directly equivalent: Visa’s capacity figure is not its average throughput, and blockchain transaction counts may include different types of operations. The right comparison requires consistent definitions and workload assumptions.

Why do some networks include validator vote messages in their TPS metrics?

Some blockchains count consensus-related transactions alongside user activity. These messages help validators coordinate and maintain the network, but they do not necessarily represent a payment, token transfer, or application operation initiated by a user. Solana’s official performance interface exposes both total transaction counts and non-vote transaction counts, allowing analysts to distinguish these categories. Always check a network’s metric definition before comparing its TPS with another chain’s figures.

How do parallel execution engines increase network TPS?

Parallel execution engines run transactions concurrently when their state dependencies allow it. If two transactions modify unrelated accounts, the engine may be able to execute them simultaneously instead of processing them strictly one after another. This can improve throughput, particularly for workloads with limited contention. However, transactions that access the same state may still require coordination, and parallel execution does not remove consensus, networking, or storage constraints.

Final thoughts: Measure what users actually experience

TPS is a useful metric, but the number alone won’t tell you whether a blockchain is right for your application. I would look at throughput alongside transaction success rates, fee behavior, confirmation latency, finality, hardware requirements, and the network’s ability to sustain performance during busy periods.

If you’re a developer, benchmark the transactions your application will actually generate rather than relying on a theoretical maximum. If you’re an investor, check whether a network’s advertised performance refers to live user activity or a controlled test. And if you’re comparing blockchain settlement with traditional payment networks, make sure you’re comparing equivalent stages of the transaction lifecycle.

The real goal isn’t to find the chain with the biggest number on a dashboard. It’s to find infrastructure that can process the work you need, settle it with the confidence your application requires, and continue doing so without making the network prohibitively difficult to operate or verify.