Lightning Network Upgrades Its Plumbing, Unevenly

Bitcoin’s Lightning Network has spent 2026 collecting headlines for its stablecoin rails and record transaction volume, with BTC trading in the mid $60,000s and a market capitalization above $1.2 trillion, according to CoinGecko’s live pricing. Underneath that growth story, a quieter and arguably more consequential shift has been underway: the protocol itself is finally shipping upgrades that developers have discussed since 2020, and not every piece of software that runs the network has kept up.

Two changes anchor that shift. A specification called BOLT12, which replaces single-use invoices with reusable payment codes known as offers, is now live natively in three of Lightning’s four major implementations. Splicing, which lets a node resize a payment channel without closing and reopening it, shipped by default in Core Lightning earlier this year. Both are genuine engineering wins nearly six years in the making. Both also expose an uncomfortable fact: LND, the implementation that still runs on more public Lightning nodes than any other, has shipped neither natively. This piece walks through what BOLT12 and splicing actually change, why LND’s absence matters more than a routine feature gap, and what the resulting patchwork means for wallets, liquidity providers, and the security assumptions Lightning users take for granted.

The State of Lightning in August 2026

Before getting into the upgrades, it helps to ground the discussion in where the network actually stands. According to research published by Bitcoin infrastructure company Spark, Lightning’s public capacity sat at roughly 4,898 BTC in May 2026, spread across about 41,080 channels and 17,438 reachable nodes. That capacity figure is down from an all-time high of around 5,637 BTC recorded in December 2025, though well above the roughly 4,200 BTC low the network touched in August 2025. Node count tells a longer-running story: 17,438 is down from a 2022 peak above 20,700, a decline that has continued even as capacity and transaction volume have grown.

That last part is the more interesting number. Spark’s research put monthly Lightning-settled volume at approximately $1.17 billion in November 2025, describing it as roughly 266 percent year-over-year growth, with around 12 million monthly transactions by late 2025. Put together, more money is moving across fewer machines. That is the backdrop against which BOLT12 and splicing arrived, and it shapes who benefits from them most.

Two Upgrades, One Long-Awaited Moment

Lightning’s core payment mechanics have barely changed since the network’s early mainnet years. Two additions this cycle count as genuine departures from that baseline. The first, BOLT12, began as an idea Blockstream engineer Rusty Russell started championing around 2020 and was formally merged into the Lightning specification repository in September 2024, the first new BOLT added since 2017, according to the original proposal thread on GitHub. The second, splicing, has an even longer history of discussion but only reached production maturity this year: Core Lightning turned splicing on by default with its v26.04 release in April 2026, nicknamed Negative Routing Fees.

Neither shipped as a surprise. Both went through years of specification work, testnet trials, and cross-implementation coordination before landing in production software, which is normal for changes that touch how Bitcoin moves inside payment channels. What is less normal is the gap that has opened between implementations in how quickly each has adopted the finished specifications.

BOLT12 Offers, Explained

The Lightning invoices most users have interacted with since the network launched follow BOLT11: a single-use string generated for one payment, tied to one amount, that expires and cannot safely be reused without leaking information about prior payments. That design works fine for a one-time checkout but breaks down for anything recurring or public, like a donation QR code taped to a coffee shop counter or a static payment link on a creator’s profile.

BOLT12 offers solve that by making the payment code reusable. An offer looks like a string starting with lno1 and can be scanned or shared indefinitely, requested at any amount if the creator allows it, and settled through blinded paths that hide the recipient’s node identity from the payer, improving privacy relative to BOLT11’s exposed routing hints. Offers also support use cases BOLT11 handles awkwardly at best: refunds, recurring subscriptions, and payments to a lightning address in the format name@domain under BIP 353, which resolves to a fresh offer rather than a static, reused invoice. Blockstream engineer Rusty Russell, who has led the offers work since its earliest drafts, has described the format in talks published on Blockstream’s blog as behaving more like a reusable business card than a disposable ticket, a framing that captures why merchants and creators have been the most eager early adopters.

Splicing: Channels That Breathe

Before splicing, resizing a Lightning channel meant closing it (an on-chain transaction), waiting for confirmation, and opening a new one (a second on-chain transaction) sized the way the operator actually wanted. Every step cost on-chain fees, and the channel sat offline, unable to route or receive, for the duration. For a routing node adjusting liquidity constantly, or a wallet provider selling inbound liquidity to new users, that friction added up fast.

Splicing collapses that into a single interactive on-chain transaction that adds or removes funds from an existing channel while it keeps operating. According to Bitcoin Optech’s technical overview, the channel never needs to close, its short channel ID and routing history stay intact, and counterparties can even splice in and splice out within the same negotiation. Core Lightning has the most mature implementation and runs it by default; Eclair has an advanced, cross-implementation-tested build still labeled experimental; LDK has shipped splice-out support and moved it toward production status. The practical payoff, per Spark’s research, is real money saved: resizing in place avoids the close-and-reopen fee cycle and keeps a channel earning routing fees the entire time instead of sitting dark for however long confirmation takes.

The Feature Matrix: Who Supports What

Laid out side by side, the unevenness between implementations becomes clear.

LND’s Holdout, and Why the Biggest Implementation Is the Slowest Mover

LND’s lag would matter less if it were a minor player. It is not. LND commands the largest share of public Lightning nodes of any implementation, largely because it ships bundled inside popular self-hosted node packages like Umbrel and RaspiBlitz, and because it underpins Lightning Labs’ own product line, including Lightning Pool, Loop, and various custody integrations built on top of it. That footprint cuts both ways. It gives LND’s engineering choices outsized influence over the network, and it makes LND a more conservative codebase to change, since more economic value depends on it not breaking.

Recent development activity backs that reading. A pull request merged into LND’s GitHub repository in March 2026 added coordinated nonce exchange for splice operations specifically for taproot channels, which is groundwork required before splicing can ship rather than splicing itself. A separate, long-tracked GitHub issue requesting splicing support remains open. Taproot channels, LND’s own next-generation channel format, appear to be first in the queue, with BOLT12 and splicing support for that channel type following once the underlying taproot work stabilizes. That is a defensible sequencing decision for a team running the most economically significant Lightning codebase, but it means the two features most of the ecosystem now treats as standard are, for LND users, still on a roadmap rather than in a release.

The Workarounds: LNDK and Patchwork Compatibility

LND users are not entirely locked out of BOLT12 in the meantime. LNDK is a standalone daemon, built by developer Carla Kirk-Cohen alongside Block’s Spiral team, that connects to a running LND node over its gRPC interface and handles offers externally, effectively acting as a translation layer between LND’s existing APIs and BOLT12’s requirements, as documented in the project’s GitHub repository. Running it requires LND version 0.18.0 or newer compiled with specific sub-servers enabled, and the project describes itself as experimental rather than production-hardened.

That workaround is a reasonable stopgap, but it is still a stopgap: a second piece of software to deploy, monitor, and keep in sync with LND releases, on top of the node software itself. Wallets built on LND face the same choice. Zeus, a popular mobile wallet and remote node manager, shipped BOLT12 offers and BIP 353 lightning addresses for Core Lightning users first, with LND support dependent on running LNDK alongside the node, according to the project’s own release notes. For a wallet trying to offer one consistent feature set regardless of which node a user runs, that is friction that Core Lightning, LDK, and Eclair users simply do not have.

What This Means for Wallets, Merchants, and Liquidity Providers

The practical benefits show up differently depending on where a business sits in the stack:

• Merchants get one payment code that does not expire after the first sale, cutting support overhead from broken or reused invoices.
• Refunds can route back through the same offer instead of requiring a manually constructed second transaction.
• Liquidity providers can resize a customer’s channel in place instead of closing and reopening it on-chain.
• Routing nodes keep earning fees on a channel while it is being resized rather than sitting offline during the process.

Both sets of benefits currently arrive unevenly depending on which node software sits underneath a given wallet or service. A liquidity provider running Core Lightning nodes can splice today; one standardized on LND is waiting on taproot-channel groundwork to finish first. That is not a reason to expect a mass migration away from LND, whose stability and tooling ecosystem remain considerable advantages, but it is a real cost that shows up as engineering time spent on workarounds like LNDK rather than on product features.

Growth Numbers That Hide a Consolidation Story

The statistics from earlier in this piece are worth revisiting with the upgrade picture in mind, because capacity and volume growing while node count falls is not a contradiction; it is a description of what is actually happening to the network’s shape.

Running a routing node that actually earns its keep now takes real capital and active liquidity management, work that splicing makes cheaper but does not make free. That favors professionally run infrastructure over the hobbyist operators who made up much of the network’s early growth, a dynamic that shows up as the same node-count decline this piece keeps returning to. It is also a dynamic playing out one layer down, on Bitcoin’s base chain. As the block subsidy keeps shrinking on its halving schedule, the question of who can still afford to run infrastructure applies to miners as much as it does to routing node operators; this outlet has covered how mining operations are adapting their power sourcing strategy to that squeeze, and how Bitcoin’s hashrate-driven security budget compares with Ethereum’s staking-based alternative.

The Security Debt: Replacement Cycling Attacks and Watchtower Limits

Protocol upgrades are only half the risk picture. Lightning has carried a known vulnerability class since December 2022, when developer Antoine Riard first flagged what became known as replacement cycling attacks in developer discussions, later assigned CVE-2023-40231 through CVE-2023-40234. The attack exploits inconsistencies between different nodes’ local mempools to manipulate hash time-locked contracts, the mechanism Lightning uses to guarantee a payment either completes across every hop or fails safely everywhere. In the most severe version described in Bitcoin Magazine’s postmortem, an attacker broadcasts the malicious replacement transaction directly to a mining pool rather than the public mempool, which hides the attempt from the victim’s node and from watchtower services meant to catch exactly this kind of foul play while the victim is offline.

Riard’s disclosure was serious enough that he stepped back from Lightning development entirely, saying, according to Cointelegraph’s reporting at the time, that the new attack class put Lightning in “a very perilous position.” All four major implementations have since shipped mitigations, and coverage from The Block notes that no verified real-world theft has been publicly linked to the attack class since patches landed. But mitigated is not the same as solved: researchers and node operators still debate how effective current defenses are against the most sophisticated version of the attack, and watchtowers, while genuinely useful, are a monitoring layer bolted onto the protocol rather than a structural fix. That distinction matters beyond Lightning specifically. Audits and patches reduce risk; they do not eliminate it, a lesson this outlet has covered at length in the context of smart contract security firms whose clients got exploited anyway despite clean audit reports.

Self-Custody Tradeoffs: Running a Node in 2026

None of this changes the core self-custody proposition that draws people to run Lightning nodes in the first place: funds in an open channel are secured by keys the operator controls, not by a custodian. What has changed is how much operational discipline that proposition now requires. A node’s channel funds are hot by necessity, since routing and receiving payments means the signing keys have to stay online, a fundamentally different risk profile from cold storage. Static channel backups, redundant off-site copies of seed material, and a tested recovery process are not optional extras for anyone running meaningful capacity; they are the difference between a hardware failure being an inconvenience and it being a loss event.

That is also why most serious node operators and businesses split their Bitcoin holdings by function rather than keeping everything in one place: a working balance in hot channels sized for routing and liquidity needs, and a larger reserve held in cold, multisig-secured storage that never touches a Lightning node at all. The operational practices that apply to that reserve, from key distribution across signers to geographic separation to tested recovery procedures, are the same ones this outlet has laid out in detail for multisig setups generally, and they matter more, not less, as the capital sitting behind routing infrastructure grows.

Where Offers and Splicing Fit Into Lightning’s Other 2026 Storylines

BOLT12 and splicing are not happening in isolation from Lightning’s other big 2026 storylines; they are quietly upgrading the plumbing underneath most of them. The stablecoin rails that have dominated Lightning headlines this year, principally USDT moving over the network through Lightning Labs’ Taproot Assets protocol, benefit from splicing the same way any liquidity-sensitive use case does: cheaper, faster channel resizing means less friction for the businesses routing dollar-denominated payments. Offers, meanwhile, are a natural fit for the recurring, machine-friendly payment patterns that the Nostr ecosystem’s zap culture has been experimenting with, where a static, reusable payment code fits better than a fresh invoice generated for every tip; this outlet’s look at whether Lightning can actually fix Nostr’s relay economics goes deeper into that specific use case.

None of this displaces newer competing designs like Ark or Spark, which take a more structural approach to Lightning’s inbound-liquidity problems rather than a protocol-upgrade one. But it does mean the comparison between Lightning and those alternatives is a moving target: a Lightning implementation with splicing and offers looks meaningfully different, from a liquidity-management and user-experience standpoint, than the same implementation did two years ago.

Machine Payments: Why Offers Matter Beyond Human Users

One underdiscussed implication of BOLT12 is how well it fits automated, machine-to-machine payments rather than the human checkout flows most invoice designs are built around. An offer is a static, parseable, reusable object that a piece of software can request from, be quoted against, and pay without a human generating a fresh invoice for every call, which is exactly the shape of payment primitive that autonomous agents and API-metered services need if they are going to transact in sats directly rather than through an intermediary. That is not a uniquely Bitcoin problem; decentralized compute and AI-agent infrastructure projects elsewhere in crypto are wrestling with versions of the same machine-settlement question, metering and paying for automated work without a human in the loop for every transaction.

Whether Lightning offers end up as genuine infrastructure for agent-to-agent commerce or a niche used mostly by developers experimenting with the format is still an open question in mid-2026. Reusable, privacy-preserving, machine-payable offers are a real capability that did not exist on Lightning eighteen months ago, and capabilities tend to find uses once they exist.

What to Watch Next

The clearest signal to watch is LND’s own repository. The taproot-channel nonce-coordination work merged in March 2026 is a prerequisite, not the feature itself, and neither the project’s public issue tracker nor its release notes have committed to a ship date for native BOLT12 or splicing as of this writing. Until that lands, LNDK and similar sidecar workarounds are likely to remain the practical path for LND-based wallets and services that want offers now rather than later.

Two other threads are worth tracking alongside it. First, whether Eclair’s splicing implementation graduates from experimental to default the way Core Lightning’s already has, which would put three of four major implementations on equal footing and leave LND as the sole holdout rather than one of two. Second, whether standardized liquidity-provider specifications built on top of splicing, letting a wallet request a channel resize from a provider through a common API rather than a bespoke integration, gain real adoption, since that is where splicing’s fee savings turn into an actual product experience rather than a backend efficiency gain.

Frequently Asked Questions

What is BOLT12 on the Lightning Network?

BOLT12 is a Lightning Network specification, often called offers, that replaces single-use BOLT11 invoices with reusable payment codes. An offer can be scanned or shared repeatedly, requested at a flexible amount, and settled through blinded paths that hide the recipient’s node identity, which also makes it easier to support recurring payments, refunds, and static lightning addresses in the name@domain format.

Does LND support BOLT12 offers?

Not natively as of mid-2026. Core Lightning, LDK, and Eclair have all shipped native BOLT12 support, but LND has not, largely because its development has prioritized finishing its taproot-channel work first. LND users can access offers today through LNDK, an external sidecar daemon that connects to a running LND node, though the project describes itself as experimental rather than production-ready.

What is splicing in the Lightning Network?

Splicing lets a node resize an existing payment channel, adding or removing funds, without closing it and opening a new one. Before splicing, resizing required two separate on-chain transactions and left the channel offline in between; splicing does it in a single interactive on-chain transaction while the channel keeps operating and routing payments.

Is the Lightning Network safe to use in 2026?

For typical payments, yes, though no payment network is risk-free. Lightning’s most serious known vulnerability class, replacement cycling attacks disclosed in 2022 and 2023, has been mitigated across all four major implementations, and no verified real-world theft has been publicly linked to it since patches shipped. Watchtower services add a further layer of protection for offline nodes, though researchers still debate how completely current mitigations cover the most advanced attack variants.

How big is the Lightning Network in 2026?

As of May 2026, research from Spark put Lightning’s public capacity at roughly 4,898 BTC across about 41,080 channels and 17,438 nodes, with monthly settled volume near $1.17 billion as of a November 2025 reading. Capacity and volume have both grown substantially over the past two years, even as the number of public nodes has continued to decline from its 2022 peak above 20,700.

Reported by Marcus Okafor, HOGE Wire.