Lightning Network capacity surge past 6,500 BTC

The Lightning Network capacity crossed 6,500 BTC as River Financial expanded its routing nodes by 340%. I view this surge as a signal that the network handles high transaction volumes. The capacity grew 46% in less than two months after it held 1,500 BTC in June. This growth follows the 2015 proposal by Joseph Poon and Thaddeus Dryja to scale the Bitcoin base layer. The network currently holds over 65,000 open channels. In April, the network reached 10,000 nodes. One month later, the first dual-funded mainnet Lightning channel opened. July brought the BlueWallet mobile LDK implementation. Blockstream announced the Greenlight Lightning node service. Breez also welcomed Seetee as its latest investor. The protocol uses multisignature addresses where two users hold private keys. Users can share funds in the address, but the setup prevents malicious actions from either party. Alice can pay Charlie through Bob if they have interconnected channels. Alice moves 1000 sats to Bob, and Bob moves 1000 sats to Charlie. This routing requires enough liquidity on the channel paths for routing to work correctly. In a typical routing scenario, Alice wants to pay Charlie but lacks a direct channel. She uses Bob as an intermediary. Because the ledger updates locally between participants, the transactions remain cheap and instant. To prevent cheating, they use Hash Time Locked Contracts (HTLCs). An HTLC is a regular Bitcoin transaction with a unique script. It uses hashlocks and timelocks. A hashlock restricts an output’s spending until a specific piece of data is revealed. A timelock limits how long a payment channel remains open.

Tether and RGB integration

Tether integrated USDT on Bitcoin using the RGB protocol. This version 1.4 Tether Wallet update provides BOLT11 invoices and LNURL functionality. Users scan or share Lightning invoices to send Bitcoin. BOLT11 tells the sender the exact amount and the routing destination. LNURL makes the process human-friendly with reusable payment links and simplified authentication. Tether uses the Taproot Assets protocol to issue tokens on the base layer. This allows users to move USDT, USAT, and XAUT through the Lightning Network. The July 2025 release of RGB v0.11.1 made asset creation on mainnet possible. Users manage backups of both Bitcoin keys and RGB proofs. If you already use a self-custodial wallet, you understand that managing these proofs adds complexity. Tether partnered with Lightning Labs on January 30, 2025, to bring USDT directly to Bitcoin. This connection creates a bridge for stablecoins. River’s satUSD uses an Omni-CDP architecture. This architecture ensures that liquidity does not segment. The satUSD peg mechanism employs a multi-oracle price feed and a dynamic interest rate adjustment model. During periods of extreme market volatility, the Liquidation Module ensures that satUSD remains strictly pegged 1:1 to the USD. Will users prioritize the speed of Lightning over the complexity of RGB proofs?

Liquid Network vulnerabilities

Liquid Network users face settlement delays because an attacker exploited a vulnerability in the Elements software. The attacker still holds 598.5 bitcoins. This incident involved a failure in the transaction-validation cache. Researchers say the bug allowed the creation of unbacked tokens. One customer submitted 4,000 L-BTC through the SideSwap peg-out service on September 6. This prompted the release of approximately 3,996 BTC. Blockstream rejected the attacker’s request for a 10% bounty. The federation is currently updating the PAK list and placing redemption keys in cold storage. Some holders migrate funds through Sideswap and Sideshift.ai. These migrations involve a total price difference and fee of approximately 5%. The bug entered the Elements master development branch the previous week before it appeared in a tagged release. Federation functionaries accepted the exploit transactions and approved withdrawals. The vulnerability allowed the attacker to construct an invalid output and a proof that matched the cache key associated with a previously valid check, which bypassed the necessary range verification for the node. This issue surfaced at Liquid block 4,050,336. A single transaction there created approximately 3,996.0183 L-BTC before the subsequent withdrawal through SideSwap. This divergence showed that some nodes accepted the transaction while others, like those powering the mempool explorer, rejected the block. The flaw involves range proofs. Range proofs let nodes check that hidden transaction amounts fall within an allowed range. A hidden negative output could offset a larger positive output. This makes newly created tokens appear to balance mathematically.

Scaling metrics and compliance

Scaling solutions provide different benefits for Bitcoin users. Lightning uses smart contracts to settle final balances on the base layer. RGB relies on client-side validation to keep data off-chain. Liquid uses a federation to back L-BTC tokens 1:1 with BTC.

Compliance teams must also adapt. They need to monitor channel and routing behavior rather than just settlement outputs. The CSA Cloud Controls Matrix and NIST CSF 2.0 provide frameworks for this. Professionals must define which Lightning events are in scope, such as channel opens, closes, forwarding records, and internal node logs. If they cannot recreate the payment path from the first hop to the settlement output, they should treat the workflow as incomplete. Organizations using Lightning must define access roles and restrict operator permissions to the minimum needed for monitoring and settlement. They should collect node, routing, and channel logs that let investigators reconstruct payment flow end to end. For a control-oriented view of access, PCI DSS v4.0 provides an analogue because it emphasizes business need and continuous monitoring. The NIST Cybersecurity Framework 2.0 is also relevant for building a governance structure around payment flows. Teams should assign leadership oversight to the evidence sources used to supervise Lightning payment flows. They must verify that their compliance model includes channel opening and closing transactions as part of the lifecycle.