TPS: The Metric That Separates Blockchain Hype from Scalable Infrastructure

Every new blockchain project announces impressive throughput numbers. Tens of thousands of transactions per second in crypto https://primexbt.com/glossary/transactions-per-second-tps-definition/ get cited as evidence that a network has solved what Bitcoin and Ethereum could not. Some of those claims are accurate, most are theoretical peaks under ideal conditions, and almost none come without a tradeoff that the headline number does not reveal. Understanding what TPS actually measures, how it is determined by underlying architecture, and what it costs to achieve at different levels separates a useful analytical tool from a marketing number.

What TPS Measures and How It Is Calculated

Transactions per second is exactly what it sounds like: the number of transactions a blockchain network can confirm and settle within a single second. It is the throughput metric, the velocity at which the network moves transactions from pending to finalised.

The number is not chosen arbitrarily. It is determined mechanically by two architectural parameters: block size and block time. Block size sets the maximum data that can be included in a single block. Block time sets how frequently a new block is produced and added to the chain. Divide the maximum number of transactions that fit in one block by the block time in seconds, and you have the theoretical maximum TPS.

Bitcoin's calculation is concrete and illustrative. A Bitcoin block is limited to approximately 1 megabyte of data. A typical Bitcoin transaction uses around 250 bytes, which means a full block holds roughly 4,000 transactions. Bitcoin's block time is 10 minutes, or 600 seconds. Dividing 4,000 by 600 gives approximately 6.7 transactions per second, which rounds to Bitcoin's commonly cited figure of around 7 TPS.

Ethereum uses larger blocks and a 12-second block time, producing approximately 15 TPS on its base layer. Solana uses a fundamentally different consensus architecture with 400-millisecond block times, producing theoretical throughput in the range of tens of thousands of TPS. Each number is a direct consequence of the architectural parameters chosen at protocol design, not a performance achievement that can be upgraded without touching the underlying design.

The Blockchain Trilemma: Why Higher TPS Always Costs Something

The reason Bitcoin still operates at 7 TPS after more than 15 years is not that its developers cannot do arithmetic. It is that the parameters producing that number are deliberate consequences of prioritising specific properties over throughput.

The blockchain trilemma describes a constraint that no blockchain has fully escaped: security, decentralisation, and scalability cannot all be maximised simultaneously. Improving one requires compromising at least one of the others. Understanding where each major blockchain sits on this tradeoff is more useful than comparing TPS numbers in isolation.

Bitcoin sits at the security-decentralisation end. A 1 MB block limit and 10-minute block time mean that even basic consumer hardware can run a full node and independently verify the entire blockchain without needing specialised equipment. This is what makes Bitcoin's validator set the most decentralised of any major blockchain: the barrier to participation is intentionally low. Raising TPS would require larger blocks or faster block times, both of which increase the data that validators must process and store, raising the hardware requirements and reducing how many participants can afford to run nodes.

The December 2017 Bitcoin congestion demonstrates what happens when demand exceeds this constrained capacity. During Bitcoin's rally to approximately $20,000, transaction volumes overwhelmed the 7 TPS limit. Confirmation times stretched from the normal 10 minutes to 30-60 minutes. Average fees spiked from roughly $1 to over $50 as users competed for the limited block space by outbidding each other. Transactions below a fee threshold simply sat unconfirmed in the mempool, sometimes for days.

Solana sits at the opposite end of the trilemma. Its 400-millisecond block times and high throughput require validators to run hardware that would cost several thousand dollars at minimum and demands very high-bandwidth internet connections. This hardware requirement reduces the number of entities that can practically participate as validators, making the network more centralised than Bitcoin by several orders of magnitude. Solana has also experienced multiple significant network outages, including a 17-hour outage in September 2021, which reflects the additional stability risk that comes with a consensus mechanism designed primarily for speed.

Bitcoin: Theoretical TPS: ~7; Block time: 10 minutes; Primary tradeoff: Maximum security and decentralisation.

Ethereum: Theoretical TPS: ~15; Block time: 12 seconds; Primary tradeoff: Flexible but congestion-prone at scale.

Solana: Theoretical TPS: ~65,000; Block time: 400 milliseconds; Primary tradeoff: High centralisation, network instability history.

Polygon: Theoretical TPS: ~7,500; Block time: 2 seconds; Primary tradeoff: Inherits Ethereum security; some trust assumptions.

Avalanche: Theoretical TPS: ~4,500; Block time: 1 second; Primary tradeoff: Faster than Ethereum; lower validator decentralisation.

Layer 2 Solutions: Scaling Without Changing the Base Layer

The architectural solution that Bitcoin and Ethereum communities have converged on is not to change the base layer parameters, but to build additional processing layers on top of the base chain. These Layer 2 networks handle the volume of transactions, then periodically settle compressed summaries back to the base layer.

The Lightning Network addresses Bitcoin's throughput constraint by opening payment channels between participants. Two parties deposit Bitcoin into a multi-signature contract, then transact between themselves off-chain at arbitrary speed, updating a shared balance sheet that only the two parties know. When they close the channel, the net result is settled on the Bitcoin blockchain in a single transaction. Thousands of individual payments between those parties consume only two on-chain transactions total, one to open and one to close the channel.

Ethereum's Layer 2 ecosystem operates on similar principles but uses a broader set of mechanisms. Optimistic rollups assume transactions are valid and batch them together, posting the batched result to Ethereum while allowing a challenge window during which fraud can be demonstrated. ZK-rollups use cryptographic proofs to verify the correctness of batched transactions without requiring anyone to trust the operator. Both approaches allow Layer 2 networks to process thousands of transactions per second while inheriting Ethereum's base layer security for final settlement.

The critical distinction is that Layer 2 solutions do not improve the base layer's TPS. Bitcoin still processes 7 TPS on chain. Ethereum still processes around 15 TPS on chain. What Layer 2 solutions do is move most transactions off-chain, reducing the base layer's congestion by aggregating large numbers of user transactions into a small number of base-layer settlements.

Why Theoretical TPS and Sustained TPS Differ

Marketing materials cite theoretical TPS figures, which represent the maximum capacity under ideal conditions. Actual sustained TPS under real network load is almost always substantially lower.

The gap exists for several reasons. Not all transactions are the same size: complex smart contract interactions require more computation and space than simple value transfers, so a block filled with complex transactions holds fewer of them than a block filled with simple ones. Network propagation delays mean validators do not all see new blocks at exactly the same instant, creating occasional forks that slow effective throughput. And peak demand is not sustained: a network that can process 65,000 TPS in theory but only needs to process 500 TPS in practice never demonstrates its ceiling under real conditions.

Solana's 65,000 TPS figure represents a theoretical ceiling under optimal conditions on a test network. Actual sustained throughput on the live Solana network during normal conditions is substantially lower, measured in the hundreds to low thousands of TPS. This does not make the theoretical number fraudulent, but it does mean that evaluating a blockchain solely on its headline TPS without examining actual throughput under real demand and real network conditions misses most of the relevant information.

What TPS Means for Traders

For traders operating on centralised platforms, base-layer TPS is mostly indirect in its effects. Trades are executed off-chain in the platform's internal matching engine, and blockchain settlement only becomes relevant when moving assets on or off chain.

The cases where on-chain TPS directly affects trading experience are specific. Moving funds from a self-custody wallet to an exchange requires an on-chain transaction, and if the relevant blockchain is congested, that transfer takes longer and costs more in fees. During Bitcoin congestion periods, a deposit intended to fund a position could sit unconfirmed for hours, arriving after the opportunity had passed.

Gas fees on Ethereum, which spike during congestion, affect the economics of DeFi protocols built on the Ethereum base layer. A trader interacting with on-chain decentralised exchanges or lending protocols during high-demand periods pays fees that can make small positions uneconomical. The 2021 DeFi boom saw Ethereum gas fees reach $50-100 per transaction, effectively pricing out retail participation in protocols designed to be accessible.

Higher TPS networks can also affect liquidation mechanics in protocols designed around on-chain execution. A network that confirms transactions in seconds processes liquidations faster than one that takes minutes, which affects the risk parameters that DeFi lending protocols can safely offer.

Conclusion

TPS is a useful metric when understood correctly and a misleading one when taken at face value. It measures how many transactions a blockchain can process per second, determined by block size and block time, not by the ambition of the development team or the boldness of the marketing. High TPS comes with costs that the number itself does not reveal: centralisation, hardware requirements, and stability risks that lower-throughput chains avoid by operating more conservatively. Layer 2 solutions address congestion without changing base-layer TPS, by aggregating transactions off-chain and settling summaries on chain. For any blockchain claiming extraordinary throughput, the productive questions are: what are the validator hardware requirements, how many independent validators actually exist, and what does the network's outage history look like? Those answers, combined with the TPS figure, produce a complete picture of the architectural tradeoffs being made.

This release was published on openPR.