Lightning's Dirty Secret: Three Companies Control Most Bitcoin Payments
Lightning was supposed to be Bitcoin’s answer to Visa. Fast, cheap, decentralized payments for everyone. The promise was beautiful: instead of every transaction clogging the base layer, we’d build a network of payment channels where value could zip around instantly, peer-to-peer, no middlemen required.
Here’s the reality: as of March 2026, the top three nodes control 34% of the Lightning Network’s public routing capacity. Two of them belong to Bitfinex. The network’s Gini coefficient (a measure of inequality) sits at 0.97, approaching the theoretical maximum of 1.0.
This isn’t what decentralization looks like. It’s what happens when economic incentives collide with idealistic design.
The numbers don’t lie
Let’s start with what we can measure. The Lightning Network’s public capacity is spread across roughly 12,648 nodes and 43,763 channels, with about 4,103 BTC locked up for routing. Sounds distributed, right?
Look closer:
- bfx-lnd0 (Bitfinex): 355.77 BTC (13.7% of total capacity)
- bfx-lnd1 (Bitfinex): 273.43 BTC (10.6%)
- LNBiG [Hub-1]: 255.49 BTC (9.9%)
That’s just the top three. Expand to the top ten nodes and you’re looking at roughly 79% of the network’s routing capacity. For a system designed to avoid centralized control, that’s a staggering concentration of power.
What happened?
How hubs win (and keep winning)
A 2020 academic study published in PLOS ONE analyzed Lightning’s first year and found something uncomfortable: new nodes preferentially attach to well-established hubs. The network exhibits a power-law distribution in capacity-weighted connections, which is a fancy way of saying it’s structurally centralized.
The researchers found that by January 2019, the top 5% of nodes had 173,560 times more capacity than the bottom 5%. That’s not a typo. The network was vulnerable to targeted attacks. Removing the top central nodes caused “a remarkable drop in efficiency,” while the network remained resistant to random failures. Classic hub-and-spoke topology.
Why does this happen? Economics. To route payments, you need:
- Channels to both sender and receiver (or nodes close to them)
- Sufficient capacity in both directions
- High uptime and reliability
Small nodes can’t compete. Opening channels costs on-chain fees. Rebalancing costs fees. And routing fees? Tiny. Often less than 1% for small payments. A 2019 report noted that LNBiG, a major node operator who claimed to run ~40% of the network, earned minimal returns despite locking up $5 million in BTC.
The node with the most connections becomes the most attractive to connect to, which makes it even more connected, which makes it even more attractive. Network effects reward size. The rich get richer.
Between 2020 and 2024, the network didn’t grow more decentralized. It consolidated. Average channels per node dropped 30%. Public node count fell 39%, from a peak of about 20,700 to today’s 12,648. Total capacity grew, but through fewer, larger, better-capitalized operators.
The network is maturing toward efficiency. Just not the decentralized kind.
The LSP problem: by design, not by accident
Here’s where it gets worse. Most Lightning users don’t run their own nodes. They use mobile wallets like Breez, Phoenix, or Mutiny. These wallets connect through Lightning Service Providers (LSPs): essentially the ISPs of Lightning.
LSPs provide critical infrastructure:
- They open channels to users automatically
- They provide inbound liquidity (so you can receive payments)
- They route payments efficiently
- They manage channel rebalancing
But here’s the catch: most mobile wallets connect to a single LSP. That LSP sees:
- Your payment amounts
- Your payment timing
- Your channel balances
- Connection metadata
ACINQ, the company behind Phoenix wallet, controls 6.96% of network capacity and has connections to 11.59% of all nodes. Voltage and Breez run similar infrastructure. These aren’t evil actors. They’re just the logical endpoint of making Lightning user-friendly.
A 2024 privacy analysis noted: “Mobile wallets are particularly vulnerable as they often have a single connection to an LSP, enabling potential tracking by the LSP.”
Trampoline routing makes this worse. To reduce computational load on mobile clients, trampoline routing offloads route-finding to specialized “trampoline nodes.” Your phone doesn’t calculate the full path across the network. It just asks a trampoline to figure it out.
Convenient? Absolutely. Decentralized? Not even close. Trampoline nodes become mandatory intermediaries. Large, well-connected nodes become preferred hops because they know the network topology and have liquidity everywhere.
Censorship isn’t theoretical anymore
So what? Lightning payments are encrypted, right? A routing node can’t see who’s paying whom. Just because Bitfinex controls a quarter of the network doesn’t mean they can censor payments.
Except they can. Or at least, they could.
A 2024 academic paper presented at Advances in Financial Technologies demonstrated that network-level attackers can censor Lightning payments despite end-to-end encryption. An autonomous system or ISP with visibility into encrypted traffic can:
- Identify Lightning messages via traffic analysis (packet timing and size)
- Selectively drop packets for specific nodes or routes
- Force routes through compliant hubs
And then there’s the simpler attack: regulatory pressure. After the Tornado Cash sanctions in August 2022, exchanges and DeFi protocols blocked addresses. While a Fifth Circuit ruling in November 2024 limited OFAC’s ability to sanction immutable smart contracts, the precedent for regulatory pressure on intermediaries stands.
Imagine this scenario: regulators force LSPs and exchanges to KYC their users. This is already happening at Bitfinex, Binance, Kraken, and OKX, all of which operate top-10 Lightning nodes. Add requirements like:
- KYC for all users opening channels
- Chain analysis on channel-opening UTXOs (flagging “tainted” coins)
- Geographic restrictions (no channels for sanctioned countries)
- Payment censorship (blocking certain node pubkeys)
Suddenly, Lightning starts looking a lot like the traditional payment rails Bitcoin was supposed to replace.
The counterarguments (they’re not wrong)
Before you despair, let’s be fair. Lightning’s centralization isn’t that bad yet. Here’s why:
Onion routing provides partial privacy. Each routing node only sees the node before and after it in the route, not the sender or final receiver. Targeted censorship is harder when you can’t easily identify “Alice paying Bob.”
Switching LSPs is trivial. Unlike mining pools, which require specialized hardware, closing Lightning channels and opening new ones with a different LSP takes minutes. If Voltage starts censoring, you can route around them.
Private channels aren’t counted. Public Lightning capacity (4,103 BTC) is only what’s advertised for routing. Many large players use private channels for internal liquidity. Total Lightning capacity is higher than public metrics show.
These are valid points. But they assume users know how to switch LSPs, that most users care enough to bother, and that censorship attempts would be obvious rather than subtle. Convenience usually wins.
What decentralization actually costs
A 2023 academic study noted: “Efficiency through routing centralization, theoretically and empirically substantiated, conflicts with the goals of privacy and resilience in the presence of observers and jamming threats.”
That’s the trade-off in one sentence. Bitcoin’s base layer sacrifices efficiency for censorship resistance. Ten-minute blocks. Global broadcast. Proof-of-work. All of it is slow and expensive by design.
Lightning was supposed to add speed without sacrificing permissionlessness. Instead, we got:
✅ Speed: sub-second settlement
✅ Low fees: often under 1% for small payments
❌ Decentralization: Gini coefficient 0.97
❌ Censorship resistance: vulnerable to LSP/exchange chokepoints
Lightning works. Over 8 million monthly transactions and 266% year-over-year volume growth in 2025 prove demand. Merchants want reliable routing, deep liquidity, instant settlement. Users want their payments to just work.
That drives everyone toward known, reliable, well-capitalized hubs. Not because of conspiracy or failure, but because it’s the rational choice.
Can this be fixed?
Technical mitigations are in development:
Multi-path payments (MPP/AMP) split payments across multiple routes, reducing reliance on single hubs. Already deployed in some clients.
Channel splicing lets you resize channels without closing them on-chain, reducing rebalancing friction.
Liquidity markets like Lightning Pool and Magma let users buy and sell inbound capacity, potentially reducing LSP lock-in.
Blinded paths let receivers hide their identity by specifying partial routes, reducing LSP knowledge of final destinations.
eCash integration (Cashu/Fedimint) provides LSPs with plausible deniability. They hold eCash tokens instead of direct user balances, so they can’t surveil or censor individual users.
But the economics are harder to fix. You can’t force users to prefer small nodes when big nodes work better. You can’t subsidize hobbyist routing without violating Bitcoin’s ethos. Regulatory arbitrage might help, but fragmentation creates its own problems.
The honest take
Lightning is a scaling solution that works. Payments are near-instant. Fees are low. Volume is growing. It’s not vaporware.
But it’s not the decentralized scaling solution the early white papers promised. It’s a pragmatic hub-and-spoke network that traded some of Bitcoin’s permissionlessness for speed and cost.
The question is whether that trade-off is acceptable. Concentrating 34% of routing capacity in two Bitfinex nodes and one LNBiG operator recreates the systemic risks Bitcoin was designed to avoid. If Bitfinex got shut down tomorrow, Lightning would lose a quarter of its public routing capacity overnight. The network would probably survive, but it would be messy.
Your answer depends on your threat model:
- If you trust exchanges and LSPs won’t censor (or think you can route around them): Lightning works great.
- If you expect regulatory capture of chokepoints: Lightning has a problem.
Decentralization isn’t binary. It’s a spectrum. Lightning is more centralized than Bitcoin’s base layer and less centralized than Visa. Where you place it on that spectrum, and whether that’s acceptable, is the debate the Lightning community needs to have.
Because right now, we’re building a fast payment network on top of a slow, censorship-resistant base layer. If the fast layer becomes censorable, what was the point?
Sources
- 1ML Lightning Network Statistics (Real-time Lightning Network data, March 2026)
- CoinLaw Bitcoin Lightning Network Usage Statistics 2026 (Network capacity and Gini coefficient analysis)
- Zaballa, Jordi, et al. “The evolving topology of the Lightning Network: Centralization, efficiency, robustness, synchronization, and anonymity.” PLOS ONE 15.1 (2020) (Academic analysis of Lightning’s hub-and-spoke structure)
- “Bitcoin’s Lightning Network Is Still Struggling To Spark,” Crypto Briefing (August 27, 2019) (Early analysis of Lightning economics and LNBiG’s operations)
- “Lightning Network Privacy: Pros & Cons vs. Bitcoin’s Base Layer,” MassMux.org (November 2024) (LSP privacy vulnerabilities)
- “Payment Censorship in the Lightning Network Despite Encrypted Communication,” Advances in Financial Technologies (AFT 2024), Dagstuhl LIPIcs (Academic paper on network-level censorship attacks)
- US Treasury OFAC Tornado Cash Designation (August 8, 2022) (Regulatory precedent for intermediary sanctions)
- “Lightning Network Protocol Architecture and its Role” (UL Open Access, 2025) (Analysis of routing efficiency vs. censorship resistance trade-offs)
Published March 2, 2026