Transaction Throughput

What Is Transaction Throughput?

Transaction throughput is the rate at which a payment network or blockchain processes transactions, typically expressed in transactions per second (TPS). It is one of the most frequently cited metrics for comparing blockchain scalability, but also one of the most commonly misunderstood.

In traditional finance, throughput describes how many authorization messages a network like Visa or Mastercard can handle. In blockchain systems, throughput is constrained by block size, block time, and consensus mechanism design. Bitcoin deliberately keeps base-layer throughput low to preserve decentralization and security, then relies on layered protocols like the Lightning Network and Spark to handle high-volume payments.

How It Works

A blockchain's throughput is determined by two variables: how many transactions fit in a block and how often blocks are produced. The formula is straightforward:

TPS = transactions_per_block / block_time_in_seconds

# Bitcoin example
# ~2,500 transactions per block / 600 seconds = ~4.2 TPS

# Ethereum example
# ~180 transactions per block / 12 seconds = ~15 TPS

For Bitcoin, the block weight limit of 4 million weight units (introduced by SegWit in 2017) caps the data in each block. A standard SegWit transaction is roughly 250 bytes, which allows approximately 2,000 to 3,000 transactions per block depending on transaction complexity. With a target block time of 10 minutes, this yields 3 to 5 TPS in practice, with a theoretical ceiling around 7 TPS for the simplest transactions.

Ethereum's throughput is bounded by gas limits rather than raw block size. Each block has a gas limit (currently around 30 million gas), and transactions consume varying amounts of gas depending on complexity. A simple ETH transfer costs 21,000 gas, while a complex DeFi interaction might consume 500,000 or more. This means Ethereum's effective TPS ranges from about 12 to 15 for typical transaction mixes.

What Counts as a Transaction

One reason TPS comparisons break down: the definition of "transaction" varies across networks. A single Bitcoin transaction can include multiple outputs, effectively batching dozens of payments into one on-chain record. Solana inflates its headline TPS by including validator vote messages (consensus overhead), which typically comprise 60 to 80 percent of all recorded "transactions." Visa counts authorization messages that settle in batch the following business day.

When Solana claims 4,000 TPS, the actual user-initiated throughput is closer to 400 to 1,000 TPS. When Visa claims 65,000 TPS capacity, the number reflects peak infrastructure capacity for authorization messages, not final settlement. These distinctions matter enormously when evaluating a network for real-world use.

Throughput Across Networks

The following table compares throughput metrics across major payment networks. Note the differences in finality time and what each "transaction" represents:

These numbers reveal a pattern: networks that achieve high TPS typically sacrifice either decentralization (by requiring powerful validator hardware) or finality guarantees (by deferring settlement). Bitcoin and Ethereum prioritize security and decentralization at the base layer, then scale throughput through Layer 2 protocols.

The Blockchain Trilemma and Throughput

The blockchain trilemma, articulated by Vitalik Buterin, states that a blockchain can strongly optimize for only two of three properties: scalability (throughput), security, and decentralization. This framework explains the design choices behind every major network.

Bitcoin maximizes security and decentralization. Anyone can run a full node on modest hardware, and its proof-of-work consensus makes attacks extraordinarily expensive. The cost is low base-layer throughput.

Solana prioritizes throughput and security but requires validator nodes with 128+ GB of RAM and high-bandwidth connections, concentrating node operation among fewer entities and reducing decentralization. Ethereum sits in the middle on all three dimensions, then offloads throughput to rollups.

Layer 2 solutions aim to break the trilemma by building on top of a secure, decentralized base layer. They inherit L1 security guarantees while processing transactions at much higher rates off-chain. This is the thesis behind both Ethereum's rollup-centric roadmap and Bitcoin's layered scaling approach.

How Layer 2 Solutions Scale Throughput

Rather than modifying the base layer (which would compromise security or decentralization), Layer 2 protocols multiply effective throughput by moving transaction execution off-chain while anchoring final settlement on-chain.

Lightning Network

The Lightning Network creates bilateral payment channels between participants. Transactions within a channel settle in milliseconds without touching Bitcoin's base layer. Only channel opening and closing require on-chain transactions. Because each channel operates independently, the network's aggregate throughput scales with the number of active channels: there is no single bottleneck equivalent to a block size limit.

The practical constraint is liquidity: each channel can only move funds up to its capacity, and multi-hop routing requires sufficient liquidity along the entire path.

Spark Protocol

Spark takes a different approach to scaling Bitcoin throughput. Instead of requiring users to open and manage payment channels, Spark uses a statechains-inspired model to transfer ownership of Bitcoin off-chain. This eliminates the liquidity management overhead of Lightning while supporting both Bitcoin and stablecoins like USDB. Users can send and receive payments without pre-funded channels, and the protocol inherits Bitcoin's base-layer security through on-chain settlement guarantees.

Rollups

On Ethereum, optimistic rollups and ZK rollups execute transactions off-chain and post compressed results to L1. Each rollup operates as an independent execution environment, meaning their throughput is additive: Arbitrum, Optimism, Base, and zkSync each handle 50 to 100+ TPS independently. The Dencun upgrade (March 2024) and Pectra upgrade (May 2025) dramatically reduced L2 costs by increasing blob capacity for data availability, enabling even higher aggregate throughput across the rollup ecosystem.

Why Raw TPS Comparisons Fail

Quoting a single TPS number without context obscures more than it reveals. Several factors make direct comparisons unreliable:

• Finality semantics differ: Bitcoin achieves probabilistic finality after roughly 60 minutes (6 confirmations). Visa authorizes in seconds but settles the next business day. Lightning settles in milliseconds. These timescales reflect fundamentally different security properties.
• Transaction complexity varies: a Bitcoin transaction batching 100 payments counts as one transaction. An Ethereum DeFi swap consuming 500,000 gas also counts as one transaction. Treating these as equivalent is misleading.
• Decentralization costs are hidden: Solana achieves higher TPS by requiring expensive hardware, reducing the number of independent validators. Bitcoin runs on a Raspberry Pi, enabling over 20,000 reachable nodes worldwide.
• Authorization is not settlement: Visa processes authorization messages at scale, but actual fund movement between banks happens in batch overnight. Every Bitcoin on-chain transaction is closer to final settlement.

A more complete comparison would account for finality time, cost per transaction, decentralization level, and what guarantees the "confirmed" transaction actually provides. For a deeper analysis of how Bitcoin's Layer 2 ecosystem addresses these tradeoffs, see the Bitcoin Layer 2 comparison.

Use Cases

Throughput requirements vary dramatically by application. Understanding where different throughput levels are sufficient (or insufficient) helps evaluate which network and layer fits a given use case:

• High-value settlement: Bitcoin's base-layer throughput of 3 to 7 TPS is more than adequate for large transfers where security and finality matter most. Central banks and institutions processing billions of dollars in daily volume can operate within this constraint.
• Retail payments: point-of-sale and e-commerce transactions require millisecond-level confirmation and thousands of TPS during peak hours. Lightning and Spark provide this without sacrificing Bitcoin's security model.
• Micropayments and streaming: use cases like pay-per-article, API metering, and content tipping require near-zero fees and high frequency. Lightning's per-channel throughput handles these natively, as does Spark with its simplified channel-free model.
• DeFi and complex execution: decentralized exchanges, lending protocols, and automated market makers require higher throughput for order matching and liquidation. Ethereum L2 rollups and Solana serve this market, with different decentralization tradeoffs.

Risks and Considerations

Centralization Pressure

The simplest way to increase throughput is to increase block size or reduce block time, but both approaches raise hardware requirements for node operators. Larger blocks need more storage and bandwidth. Faster blocks need lower-latency connections. Over time, this can push node operation toward data centers, reducing the number of independent participants and undermining censorship resistance.

Bitcoin's block size wars (2015 to 2017) settled this question for the Bitcoin community: the decision was to preserve small blocks and low node requirements, scaling throughput through layers rather than by expanding the base protocol.

Throughput as a Misleading Metric

Projects sometimes market peak theoretical TPS to attract users without disclosing that sustained throughput is far lower or that the figure includes non-user transactions. Always verify whether reported TPS figures are theoretical or measured, and whether they include consensus overhead like validator votes.

Layer 2 Complexity

Scaling throughput via Layer 2 introduces operational complexity: liquidity management on Lightning, fraud proof windows on optimistic rollups, and proof generation costs on ZK rollups. Each approach has its own failure modes and trust assumptions that users and developers must evaluate.

Security-Throughput Tradeoff

Higher throughput at any layer comes with some tradeoff. Shorter confirmation times mean less accumulated proof of work per confirmation. Larger blocks increase the time nodes need to validate and propagate blocks, creating opportunities for selfish mining or eclipse attacks. Understanding these tradeoffs is essential for choosing the right network and layer for a given application.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.