Bitcoin processes roughly 7 transactions per second. On a congested day, closer to 3 or 4. Visa advertises capacity around 24,000 TPS. That gap gets cited constantly as evidence that Bitcoin is a failed payments system — a slow, clunky technology that was interesting in theory but can't compete in the real world.
The comparison is real. The conclusion it's used to support usually isn't.
Whether Bitcoin is "too slow to be useful" depends entirely on what you need it to do. Most people making the argument skip that question entirely.
Why Bitcoin Produces 7 TPS
Bitcoin's throughput ceiling comes from two fixed parameters: block size and block time.
Each block has a data limit — roughly 4 MB of weight under the current SegWit rules (though the older 1 MB nominal limit still gets quoted). Blocks are produced approximately every 10 minutes. Divide available block space by average transaction weight, and you get your ceiling: somewhere between 7 and 10 TPS in ideal conditions, 3–5 TPS in normal operation as transactions have grown more complex over time.
The 10-minute block interval isn't a performance limitation someone failed to optimize. It's a deliberate design choice. Bitcoin operates across a global network of nodes, and blocks need time to propagate to all participants before the next one arrives. Tighten the interval and you increase the "orphan rate" — the frequency with which two valid blocks are produced simultaneously, forcing the network to pick one and discard the other. That creates instability and pushes the system toward centralization, because larger, better-connected miners are less exposed to orphan risk. Satoshi Nakamoto settled on 10 minutes as a balance between confirmation frequency and propagation safety. Changing it isn't a simple tuning dial.
Here's the part the TPS comparison usually skips: Visa isn't a settlement network, it's an authorization network.
When Visa "processes" a transaction, it's approving a payment. The underlying interbank settlement — the actual movement of funds between financial institutions — happens later, through systems like ACH, Fedwire, or SWIFT correspondent banking. That can take one to three business days. When you compare Bitcoin's ~10-minute confirmations against Visa's 24,000 TPS, you're comparing a settlement mechanism against an authorization mechanism. They're not the same thing. Traditional final settlement is measured in days, not milliseconds.
Bitcoin's confirmations are slower than Visa authorization. They're considerably faster than most traditional final settlement.
What the Lightning Network Changes
The Lightning Network is Bitcoin's Layer 2 payment channel system. Two parties lock bitcoin into a multisig smart contract on the base chain, then conduct an unlimited number of transactions between each other off-chain — instantly, cheaply. When they're done, the final balance is settled to the main chain and the channel closes.
Through well-connected routing nodes, payments can traverse multiple channels to reach a counterparty you've never opened a channel with directly. The theoretical throughput across a mature Lightning network is effectively unlimited. In practice, routing large payments reliably and operating a non-custodial mobile wallet remain genuinely difficult — Lightning is real and functional, but it's not a finished consumer product for most use cases.
It's worth being clear about what Lightning does and doesn't change. It doesn't make Bitcoin's base layer faster. It creates a separate layer where speed is handled differently. The "too slow" critique, if it applies anywhere, becomes specifically a critique of Bitcoin's base chain as a retail payment processor — a job it was never designed to do.
The Tradeoff Is Real
Increasing Bitcoin's on-chain throughput would require either larger blocks or faster block times. Both moves have costs.
Larger blocks mean more data per block, which means higher bandwidth and storage requirements for node operators. As those requirements rise, fewer people run full nodes. As the full-node count falls, the network becomes more dependent on a smaller set of participants — which is centralization. The 2017 block size debate produced a hard fork (Bitcoin Cash) along this fault line, and the resulting split largely settled the question within Bitcoin's core community: the 1 MB base block limit stays, scaling happens at other layers.
Faster blocks compound the orphan-rate and centralization problem described above. This isn't a technological failure waiting to be solved — it's the direct cost of prioritizing security and decentralized validation above raw throughput. Bitcoin's designers made a choice. The choice has consequences. The honest framing is that this is a tradeoff, not a deficiency.
Where Bitcoin's Speed Actually Matters
For specific use cases, Bitcoin's throughput is genuinely limiting.
Micropayments below a few dollars become economically irrational on the base chain when fees are elevated. High-frequency merchant transactions can't wait 10 minutes for confirmation. Any application requiring real-time settlement at scale doesn't fit the base layer.
For other use cases, it doesn't matter much. Large-value transfers, cross-border settlement, institutional treasury management, and long-term value storage don't require sub-second finality. Bitcoin's confirmations are more than adequate for these, and its security properties — uninterrupted operation since 2009, no successful double-spend attacks at scale, no administrator who can reverse transactions — are genuinely valuable in ways that authorization speed doesn't address.
The question "is Bitcoin too slow?" is actually the question "too slow for what?" The answer is different depending on the use case.
Confirmation and Invalidation
If the thesis that Bitcoin is "too slow to be useful" is overstated, you'd expect to see: continued institutional settlement flows using Bitcoin (present — ETF custody, corporate treasuries, cross-border transfers); Lightning adoption growing for small-payment use cases (active — Strike, Cash App, Bitrefill, and others have functional implementations); and no migration of large-value settlement from Bitcoin to a faster alternative on security-equivalence grounds.
The thesis would gain real weight if Lightning fails to reach genuine consumer scale and remains perpetual infrastructure-in-progress; if sustained high-fee environments make the base chain economically inaccessible for most users even with L2 options; or if a protocol offering Bitcoin-equivalent security properties but meaningfully higher throughput captures the store-of-value use case. That last scenario hasn't materialized, but the structural argument for why it couldn't is weaker than it's often presented.
Timing
Now: Bitcoin's base-layer throughput is what it is. If you need high-frequency, low-value payments, Lightning handles that use case — with the caveat that routing complexity and UX still require technical tolerance.
Next: Lightning infrastructure is the active development thread. Channel splicing (adjusting capacity without closing), improved routing algorithms, and simplified self-custodial apps are the near-term improvements worth watching.
Later: Any change to Bitcoin's base-layer block parameters would require community consensus that doesn't currently exist. This is a long-horizon theoretical question, not an active roadmap item.
What This Doesn't Mean
Bitcoin being slower than Visa authorization is a real fact. It doesn't mean Bitcoin is broken, nor does it mean all use cases require Visa-level throughput. The mechanism explains a design tradeoff — not a failure.
This is the static explanation. It doesn't constitute a recommendation to buy, hold, or transact in Bitcoin, and it doesn't address the tax or regulatory treatment in any jurisdiction.
