Taproot’s Lightning Moment: Channels Shipped, PTLCs Didn’t
Simple taproot channels went production-ready in June 2026, almost five years after the soft fork. But PTLCs, the private payments Taproot promised Lightning, still have not shipped.
Almost five years ago, Bitcoin activated its last soft fork. Taproot locked in at block 709,632 on 14 November 2021, bundling Schnorr signatures, a cheaper way to hide unused spending conditions, and a cleaner scripting language into a single upgrade that went live with little drama, as CoinDesk reported at the time. The pitch was never only about on-chain transactions. A large part of the promise pointed at the Lightning Network, the payment layer that sits on top of Bitcoin, where Taproot was supposed to make channels cheaper, more private, and eventually capable of a new kind of payment that leaks far less information.
In June 2026 the first half of that promise finally arrived in production. The second half is still waiting. This is the story of what Taproot actually delivered to Lightning, what it has not, and why the gap says more about how Bitcoin changes than any roadmap slide ever could.
The backdrop is a market that has cooled hard. Bitcoin traded at $82,413 on 9 October 2026, down about 0.25% on the day and roughly 32% below where it sat a year earlier, when it printed an all-time high near $126,198 in early October 2025 (Fortune). Lower prices sharpen the exact question Lightning was built to answer: if the fee market is thin and the block subsidy keeps halving, can Bitcoin still move value cheaply and privately without asking users to trust a custodian? Taproot was supposed to help. The honest 2026 answer is: partly.
What Taproot Actually Changed
Taproot is three Bitcoin Improvement Proposals that shipped together. BIP 340 introduced Schnorr signatures, a scheme whose math lets several signatures be combined into one. BIP 341 defined Pay-to-Taproot (P2TR), the output type behind the bc1p addresses now visible across block explorers, along with a tree structure (MAST) that lets a spender reveal only the one spending condition they actually use and keep the rest hidden. BIP 342 updated the scripting language, Tapscript, to work with the new signatures. The authors across the three proposals include Pieter Wuille, Jonas Nick, Tim Ruffing and Anthony Towns.
Two properties matter for everything that follows. First, a Taproot output can be spent either through a single aggregated key (the key path) or by revealing a script (the script path), and a cooperative key-path spend looks identical to any other single-signature Taproot payment. Second, Schnorr signatures can be combined with a protocol called MuSig2 (BIP 327), so two parties can jointly produce one signature that reveals nothing about the fact that two of them were involved. Those two facts, indistinguishability and aggregation, are exactly what a Lightning channel wants.
The Lightning Promise Taproot Made in 2021
A Lightning channel is, at its base, a two-of-two multisignature address that two parties fund and then update between themselves off-chain. Before Taproot, that funding address was a visible two-of-two script, which meant anyone watching the chain could pick Lightning opens and closes out of the crowd. Every channel announced itself. The transactions used more block space than a plain payment, and the on-chain footprint told a surveillance story about who was opening capacity with whom.
Taproot offered to fix all three problems at once. Fund the channel through a MuSig2 key, and the open looks like an ordinary single-signature Taproot spend. Close it cooperatively, and the close looks the same. Aggregate the signatures, and the transaction is smaller and cheaper. Then, further out, swap the payment mechanism itself for one built on elliptic-curve points rather than hashes, and you get payments that colluding routing nodes can no longer stitch back together. Developers named the near-term piece simple taproot channels and the further-out piece PTLCs. Five years on, one is in production and the other is not.
Bastien Teinturier, CTO of the French Lightning company ACINQ, which builds the Eclair node implementation and the Phoenix wallet, drew the line between the two cleanly on the Stephan Livera Podcast. Taproot channels, he explained, “just makes you use taproot for the funding transactions, the transactions that create lightning channels, but doesn’t use taproot yet for the payments themselves.” The payments, the part that would use MuSig2 and adaptor signatures and all of those fancier tools, were always meant to be a later step.
Simple Taproot Channels, Explained
Simple taproot channels are the minimum viable version of a Taproot-native channel. Lightning Labs introduced them in LND 0.17 in October 2023, describing the format as the smallest commitment-format upgrade needed to bring MuSig2 and Tapscript into the Lightning protocol. The funding output becomes a MuSig2 key shared by the two channel partners. When both cooperate, which is the common case, their signatures aggregate and the resulting open or close is indistinguishable on-chain from a normal single-signer Taproot transaction.
The privacy win is structural, not cosmetic. A chain analyst can no longer flag a transaction as Lightning simply from its shape. The efficiency win follows from the same mechanism: an aggregated Schnorr signature takes less space than a spelled-out two-of-two script, so cooperative opens and closes weigh less and cost less in fees. Phoenix, ACINQ’s mobile wallet, measured roughly a 20% reduction in on-chain fees for channel opens and closes after moving to Taproot, according to Lightning research compiled by Spark.
There is a catch baked into the early design. From the start, simple taproot channels could not be publicly announced. They worked as private, unadvertised channels only, because the part of the Lightning protocol that gossips channel existence to the rest of the network, the routing map everyone shares, did not yet understand the new format. A phone wallet like Phoenix does not care; it opens private channels to a trusted peer anyway. A public routing node that wants to advertise capacity very much does.
June 2026: The Feature Finally Goes Production-Ready
For almost three years simple taproot channels carried an experimental label. That changed with LND v0.21, released on 11 June 2026, which graduated them to production-ready with finalized channel scripts, optimized signature checks, and support for fee-bumping a cooperative close through replace-by-fee. The specification behind it lives in the Lightning BOLTs repository as pull request 995, an extension to the base protocol rather than a change to it.
LND was not alone. ACINQ’s Eclair added an initial implementation, and then, after cross-implementation compatibility testing, shipped the final version of taproot channels alongside channel splicing in a 2026 release. The Zeus mobile wallet carried support as far back as v0.8.0 in December 2023. The table below shows where the major implementations stand, according to the Bitcoin Optech topic tracker and each project’s own release notes.
| Implementation | Taproot channel status (2026) | First shipped | Notes |
|---|---|---|---|
| LND (Lightning Labs) | Production-ready (v0.21, June 2026) | Experimental in v0.17 (Oct 2023) | Finalized scripts, RBF cooperative close |
| Eclair (ACINQ) | Production, enabled by default | Initial support 2025 | Bundled with splicing and dual funding |
| Phoenix (ACINQ wallet) | Full support | 2026 | About 20% lower on-chain fees for opens/closes |
| Zeus (wallet) | Supported | v0.8.0 (Dec 2023) | Early mobile adopter |
| Core Lightning / LDK | No default support reported | Following BOLT #995 | Awaiting spec finalization |
The pattern across the table is worth noting. The two implementations closest to end users, Phoenix and Zeus, were among the earliest to carry Taproot channels, because their users open private channels to a known peer and never touch the public routing graph. The heavier routing nodes have moved more slowly, because for them the missing piece is not the channel format but the gossip that makes a channel findable in the first place.
What a Taproot Channel Looks Like On-Chain
It helps to picture the before and after. Open a pre-Taproot channel and the funding transaction pays into an obvious two-of-two output; anyone running chain analysis can tag it as Lightning on sight, estimate the capacity, and start mapping who connects to whom. Open a simple taproot channel and the funding output is a single bc1p address, the same Taproot output type an individual might use for an ordinary savings transaction. The channel hides in the crowd of every other Taproot spend.
The user sees none of this. In a wallet like Phoenix, opening a channel is a background step behind a receive screen, and the roughly 20% fee saving Spark measured shows up only as a slightly smaller deduction. The cooperative close is the same story: because both sides sign with MuSig2, the closing transaction reads as a routine single-signature spend rather than the tell-tale multisig unwinding of the old format. The privacy benefit, in other words, is strongest exactly when both parties behave well, which is the overwhelmingly common case.
The leak returns only in a forced close, where one side publishes the channel’s script path because the other has gone offline or tried to cheat. Then the HTLCs still in flight appear on-chain in their recognizable form, which is one more reason the move to PTLCs matters: it would shrink the information that even an ugly close reveals.
HTLCs Versus PTLCs: The Hash Problem Taproot Was Meant to Fix
To understand what Lightning still has not upgraded, look at how a payment hops across the network today. A Lightning payment is routed through a chain of intermediaries, and each hop is secured by a Hash Time-Locked Contract, or HTLC. The sender picks a secret, hashes it, and the same payment hash is used at every hop along the route. When the receiver reveals the secret to claim the final hop, that secret unwinds back along the path, releasing each intermediary’s funds in turn.
The weakness is that single shared hash. It is the same kind of cryptographic fingerprint that appears all over Bitcoin, and inside an HTLC it is identical at every hop. Two routing nodes that happen to sit on the same payment path, and that quietly compare notes, can see the same hash on both of their channels and conclude they handled one payment. On a network where a handful of well-connected nodes route a large share of traffic, that correlation is a real privacy leak, not a theoretical one.
Point Time-Locked Contracts, or PTLCs, close the gap. Instead of a shared hash, each hop is locked to a different point on an elliptic curve, and the payment is claimed with an adaptor signature rather than a revealed preimage. Each hop carries a different secret, so two colluding nodes see two unrelated points and cannot link them, as the Lightning infrastructure firm Voltage describes it. The benefits stack: payments decorrelate across hops, a PTLC that lands on-chain looks like an ordinary signature for an ordinary key, and because the construction is lighter than an HTLC it uses less block space and pays lower fees. PTLCs also make it cleaner to retry a stuck payment and to build escrow-style contracts that are awkward with plain hashes.
| Property | HTLC (today) | PTLC (not yet shipped) |
|---|---|---|
| Lock mechanism | Shared SHA-256 payment hash | Elliptic-curve point plus adaptor signature |
| Same value across hops? | Yes, identical hash every hop | No, a different secret each hop |
| Routing-node correlation | Possible by colluding nodes | Decorrelated |
| On-chain appearance | Recognizable script | Looks like a normal signature |
| Transaction size and fees | Larger | Smaller, cheaper |
| Enabled by Taproot? | No (pre-Taproot) | Yes (Schnorr plus adaptor sigs) |
| Status in 2026 | Universal, in production | Not in any production channel |
Why PTLCs Still Are Not Here
If PTLCs are better on privacy, fees, and flexibility, the obvious question is why five years of Taproot availability have not put them into a single production channel. The answer is partly ordering and partly caution. Simple taproot channels, by design, keep using HTLCs; the specification says explicitly that the format continues to rely on hash locks and that PTLC support would arrive in a later upgrade, per the Bitcoin Optech tracker. Developers chose to ship the funding-transaction change first, prove it in production, then come back for the payment change.
The caution is the bigger factor. Teinturier, back on the same podcast, was blunt about the holdup: for PTLCs, “there’s not enough good support yet, even in the cryptographic libraries that we use.” Adaptor signatures and the multi-party signing they lean on are newer, more fragile code than the battle-tested hash locks they would replace, and a bug in channel-signing logic can cost real money. His conclusion was that the teams did not want to rush. Years later that judgment has held: the libraries have matured, MuSig2 standardized as BIP 327 and shipped in production wallets, yet the full PTLC payment path is still not something any node runs by default.
That conservatism is not timidity for its own sake. Lightning handles live funds in signing code that runs unattended, and the industry’s own audit track record in 2026 is a standing reminder of what happens when novel cryptographic code ships before it is ready. The cost of a subtle flaw in a new signing scheme is not a failed transaction; it is drained channels. Measured against that, shipping the funding change first and leaving payments on the old, well-understood hash locks was the responsible order, even if it means the headline privacy feature is still on the waiting list.
Taproot Gossip and the Road to Public Channels
The nearer-term work is not PTLCs at all; it is gossip. Lightning nodes share a map of public channels so that payments can be routed, and that gossip layer has to learn the Taproot channel format before a Taproot channel can be advertised to the whole network. Until it does, Taproot channels stay private, which is fine for a phone wallet and limiting for a routing business.
Work on that map is underway. The base protocol has a pull request, numbered 1059 in the BOLT specification repository, that adds Taproot-aware gossip messages, and LND merged the corresponding wire-message handling in the run-up to late 2026. Lightning Labs framed the June production release as the step that sets the stage to finalize taproot gossip and, eventually, public taproot channels. The sequence is deliberate: lock the channel scripts, then teach the network to talk about them, then, much later, change what flows through them.
For users the practical effect over the next year is quiet. Wallets that already use private Taproot channels keep getting cheaper opens and closes. Public routing nodes gain the ability to advertise Taproot capacity once gossip lands, at which point the share of the network that looks like plain Bitcoin on-chain rises. None of this is visible in a payment; it shows up as a slightly smaller fee and a slightly smaller surface for chain surveillance.
What Lightning Built Instead: Dollars on Bitcoin
While PTLCs waited, the Lightning ecosystem spent much of its energy somewhere few people predicted in 2021: moving dollars, not bitcoin. Taproot Assets, Lightning Labs’ protocol for issuing tokens on Bitcoin and routing them over Lightning, reached version 0.7 in December 2025 with reusable addresses and auditable supplies, and in March 2026 Tether’s USDT went live over Lightning, the first major stablecoin to do so, according to Spark’s state-of-the-network research.
The groundwork was laid earlier. Olaoluwa Osuntokun, co-founder and CTO of Lightning Labs, had already demonstrated what he called the first mainnet multi-hop asset payment over Taproot Asset channels, routing a dollar-denominated balance through a bitcoin hop and out the other side. The picture he sketched was Lightning as a currency-agnostic payment layer settled in Bitcoin, where the thing moving over the wire might be a stablecoin and the thing securing it is still the base chain.
That reframing matters for how ordinary users will meet Taproot. Most will never open a channel by hand or inspect a signature. They will tap a wallet that opens a private Taproot channel for them, holds a dollar balance issued as a Taproot Asset, and settles over Lightning in the background. It is the same trend visible across self-custody, where the wallet quietly does the hard part and the user sees only a balance and a send button. Taproot turned out to be the plumbing; stablecoins turned out to be the product.
There is a second track running alongside. Spark, a statechain-inspired Bitcoin layer built by Lightspark, leans on the same Taproot primitives to scale self-custodial payments and stablecoins while staying compatible with Lightning. Whether statechains or channels capture more real usage is still an open question, but both are downstream of the same 2021 soft fork.
Eltoo and LN-Symmetry: The Upgrade That Needs Another Soft Fork
There is a third thing Taproot was supposed to make possible for Lightning, and it is stuck even harder than PTLCs, because it needs Bitcoin itself to change again. Today’s channels use a penalty model: both parties keep every past channel state, and if one broadcasts an old, more favorable state, the other can take the whole channel balance as a penalty. It works, but it is unforgiving. A node that restores from a backup and accidentally publishes a stale state can lose everything, which the Bitcoin Optech eltoo writeup calls “toxic waste,” and the model forces every node to store the full history of a channel.
Eltoo, since renamed LN-Symmetry, replaces the penalty with a simpler rule: any later channel state can replace any earlier one, so publishing an old state merely wastes a transaction fee rather than forfeiting funds. That makes backups far safer and lets devices with tiny storage, such as hardware wallets, take part in a channel, though a hardware wallet is only ever as trustworthy as the supply chain that delivered it. It also makes it practical for three or more parties to share a single channel, the basis for channel factories. The catch is that it needs a new signature mode, SIGHASH_ANYPREVOUT, specified as BIP-118 by Christian Decker and Anthony Towns, which remains a draft and is not activated.
This is where the Lightning story runs straight into the larger Bitcoin story. BIP-118 requires a soft fork, and Bitcoin has not activated one since Taproot. Draft proposals such as BIP-446 and BIP-448 sketch a Taproot-native path to LN-Symmetry through new opcodes, part of the broader covenant debate that has filled Bitcoin development forums through 2026, but none carries an activation schedule. Until the base layer moves, LN-Symmetry stays on paper, and the promise of letting a low-storage signing device safely hold a channel stays theoretical.
The Numbers: A Thinner, Quieter Lightning in 2026
All of this plays out on a network that has contracted, not grown, over the window in which Taproot was supposed to supercharge it. Public Lightning capacity sat around 4,898 BTC in mid-2026, worth roughly $400 million at October prices, down from a December 2025 peak near 5,637 BTC, according to Spark’s research. The node count has fallen to about 17,438 from a 2022 peak near 20,700, and the network carried roughly 41,080 public channels.
| Metric | 2026 figure | For reference |
|---|---|---|
| Public capacity | About 4,898 BTC (roughly $400M) | Peak about 5,637 BTC (Dec 2025) |
| Nodes | About 17,438 | Peak about 20,700 (2022) |
| Public channels | About 41,080 | Private capacity est. roughly 2x public |
| Taproot channels | Production since LND v0.21 (Jun 2026) | Private-only until gossip lands |
| Stablecoins | USDT live since Mar 2026 | Carried via Taproot Assets |
Read pessimistically, those numbers say Lightning shrank. Read carefully, they say something subtler. Analysts at Spark attribute the decline to consolidation, fewer nodes running more efficiently, and note that private channels, which never appear in public figures, are estimated at roughly twice the public capacity. Taproot channels are themselves private by default today, so the more the network adopts them before gossip lands, the less of it the public totals can even see. A quieter Lightning is not the same as a smaller one; some of the apparent shrinkage is the network learning to hide.
Why Bitcoin Moves This Slowly
It is worth sitting with the central fact of this story: a privacy and efficiency upgrade that was designed, specified, and technically available in 2021 is, in 2026, only half-shipped on the layer it was most meant to help. On most software platforms that would read as failure. In Bitcoin it is closer to the design.
The contrast with the other large smart-contract ecosystem is stark. Ethereum reshaped what a wallet even is through account abstraction, pushing programmable accounts to users over a couple of years and iterating in public, breakage included. Bitcoin takes the opposite stance. There is no central roadmap, no team that can ship a consensus change by decree, and a strong cultural preference for leaving money-handling code alone until it is provably safe. Taproot’s script paths can express rich spending conditions, but the community reaches for them slowly and on purpose.
Teinturier’s refusal to rush PTLCs is the same instinct one layer down. The cost of being wrong in Lightning signing code is drained channels; the cost of being wrong in a Bitcoin soft fork is worse and effectively permanent. So the sequence is funding transactions first, then gossip, then payments, then maybe, years out and only if the base layer cooperates, the state-replacement model that needs its own soft fork. Slowness here is not inertia; it is a priced-in choice about what a monetary network should optimize for.
Who Governs Any of This (and Who Does Not)
Because none of these upgrades has a company or a foundation that can push a button, there is also no regulator that approves or blocks them. In the United States, the Securities and Exchange Commission oversees securities and the intermediaries that deal in them; a Lightning channel, a MuSig2 funding transaction, and a draft like BIP-118 are none of those things. The SEC does not sign off on a soft fork, and neither does any European authority under the bloc’s crypto rulebook. Protocol changes are governed, to the extent they are governed at all, by rough consensus among the developers who write the code and the node operators and miners who choose whether to run it.
The one place regulation does touch this story is the product that rode in on Taproot’s plumbing. Dollar stablecoins moving over Lightning are exactly the kind of instrument sitting inside the stablecoin rules the SEC and other agencies have been shaping, even though the rails underneath are pure Bitcoin protocol. The channel is not regulated; the dollar inside it might be. That split, an open protocol below and a supervised asset above, is likely to define how Taproot-era Lightning meets the law.
What to Watch Next
For readers tracking whether Taproot’s Lightning promise finally completes, a handful of concrete milestones will tell the story over the next year:
- Taproot gossip finalizing in the BOLT spec and in LND, the switch that lets public routing nodes advertise Taproot channels and stop hiding out of necessity.
- Any production implementation moving a real payment over a PTLC rather than an HTLC, which would mark the first time Taproot touches Lightning payments and not just channel funding.
- Progress on a soft fork that enables LN-Symmetry, whether through BIP-118 or the newer BIP-446 and BIP-448 drafts, since none of the channel-factory and safe-backup benefits arrive without it.
- More wallets defaulting to Taproot channels, pushing the share of Lightning that looks like ordinary Bitcoin on-chain higher and shrinking the public capacity figures further.
- Stablecoin volume over Taproot Assets, the metric that will show whether dollars-on-Lightning is the use case that finally gives the layer organic demand.
The quiet verdict five years in is that Taproot did what Bitcoin upgrades tend to do. It arrived without drama, delivered its safest benefits first, and left the ambitious ones to a slower clock. Simple taproot channels are real, in production, and already saving fees. PTLCs and LN-Symmetry are real too, just not yet, and in a system that treats caution as a feature rather than a bug, not yet is a long way from never.
Frequently Asked Questions
What are simple taproot channels?
Simple taproot channels are Lightning channels whose funding transaction uses a Taproot MuSig2 key instead of a visible two-of-two script. When both parties cooperate, the open and close look like ordinary single-signature Taproot payments on-chain, which improves privacy and lowers fees. They went production-ready in LND v0.21 in June 2026, though they stay private-only until taproot gossip is finalized.
What is the difference between an HTLC and a PTLC?
An HTLC locks every hop of a Lightning payment with the same hash, which lets colluding routing nodes link the hops and correlate the payment. A PTLC locks each hop with a different elliptic-curve point and claims it with an adaptor signature, so the hops cannot be linked, transactions are smaller and cheaper, and an on-chain PTLC looks like a normal signature. PTLCs need Taproot, and as of 2026 no production channel uses them yet.
Why have PTLCs not shipped if Taproot activated in 2021?
Developers deliberately shipped the funding-transaction change, simple taproot channels, first and left the payment change for later. The bigger reason is caution: as ACINQ’s Bastien Teinturier has said, the cryptographic library support for the adaptor signatures PTLCs rely on was not mature enough, and rushing fragile signing code risks draining channels. The libraries have improved since, but the full PTLC path is still not run by default.
Does Taproot let Lightning carry stablecoins?
Indirectly, yes. Taproot Assets, a protocol built on Taproot, lets issuers put tokens on Bitcoin and route them over Lightning. Tether’s USDT went live over Lightning in March 2026, the first major stablecoin to do so. The dollar balance rides over private Taproot channels and settles in Bitcoin, which is why many users will meet Taproot without ever knowing it.
Does the SEC regulate the Taproot or Lightning upgrade?
No. The Securities and Exchange Commission regulates securities and the intermediaries that handle them, not Bitcoin’s consensus rules or the Lightning protocol. A soft fork such as the draft BIP-118 that LN-Symmetry needs is adopted by developer consensus and node-operator choice, not regulatory approval. Regulation can reach the stablecoins that move over Lightning, but not the channels themselves.
By Marcus Okafor, senior bitcoin-layer1 correspondent at HOGE Wire.