Lightning Taproot Channels: Smaller Footprint, Better Privacy, New Possibilities

Lightning channels have always left a fingerprint on the Bitcoin blockchain. The standard P2WSH funding output broadcasts a 2-of-2 multisig script that chain analysis firms can trivially identify as a Lightning channel. With the simple taproot channels upgrade, that fingerprint disappears: funding outputs become ordinary P2TR outputs, cooperative closes produce a single Schnorr signature indistinguishable from any other Taproot spend, and the on-chain cost drops by roughly 40% per input.

The specification for simple taproot channels (BOLTs PR #995) merged on May 4, 2026. LND shipped production support in v0.21.0 (June 2026), and Eclair followed with v0.14.0 (May 2026). This article covers what changed, why it matters, and what it unlocks next.

What Changes On-Chain

The core change is straightforward: Lightning channel funding outputs move from P2WSH (SegWit v0) to P2TR (SegWit v1). Instead of encoding a 2-of-2 multisig script on-chain, the two channel peers combine their funding keys into a single aggregate key using MuSig2 (BIP 327). The on-chain output becomes OP_1 <32-byte-aggregate-key>: no script, no multisig fingerprint, just a key.

Funding Output: Before and After

All six commitment transaction output types (to_local, to_remote, local anchor, remote anchor, offered HTLC, accepted HTLC) also convert to P2TR. Outputs where key-path spending must be impossible (such as to_local, which requires a timelock or revocation path) use a NUMS (nothing-up-my-sleeve) internal key derived from the string "Lightning Simple Taproot", ensuring nobody can bypass the script conditions.

Still using HTLCs: Simple taproot channels continue to route payments with HTLCs, not PTLCs. This maintains full backward compatibility with existing non-taproot nodes on a payment route. PTLCs require additional specification work and will come as a separate upgrade.

How MuSig2 Signing Works in Channels

The privacy and size gains of taproot channels depend on MuSig2, a two-round interactive signing protocol defined in BIP 327. Both channel peers contribute to every signature, but the result is a single 64-byte Schnorr signature that validates against the aggregate public key.

The Two Rounds

1. Nonce exchange: each party generates a secret nonce and shares the corresponding public nonce. The protocol aggregates both public nonces into a single aggregate nonce. This step can happen before the message to sign is known.
2. Partial signature exchange: each party computes a partial signature using their private key, secret nonce, and the aggregate nonce. The two partial signatures combine into one valid Schnorr signature.

Nonces must never be reused across signing sessions. The production implementation in LND v0.21.0 uses a just-in-time nonce pattern: closer nonces are bundled with signatures in ClosingComplete messages, and the protocol state machine prevents reuse across RBF rounds. Nonces for commitment transactions travel in existing Lightning messages: revoke_and_ack carries the next nonce set, and commit_sig contains the current nonces and partial signature.

This flow happens twice per state update: once for the local commitment transaction and once for the remote commitment transaction. The overhead is manageable because nonce exchange piggybacks on messages the protocol already sends.

Privacy: Cooperative Closes Vanish

The single largest privacy improvement is that cooperative channel closes become indistinguishable from ordinary single-sig Taproot spends. When both parties agree to close, they produce a MuSig2 aggregate signature via the key-path. No script is revealed. No multisig structure is exposed. On-chain observers see a standard P2TR-to-P2TR transaction with a single signature.

This matters especially for unannounced (private) channels, which make up the majority of the Lightning Network. Before taproot channels, even private channels revealed their nature when closed because the 2-of-2 multisig witness was visible on-chain. With taproot, a private channel can be opened, used for years, and closed without ever appearing as anything other than ordinary Bitcoin transactions.

Force Closes Still Leave Traces

When a channel is force-closed, the spending party must use a script-path spend, revealing the specific tapscript branch for the revocation or timelock condition. This exposes internal structure and remains identifiable as Lightning-related. However, only the branch actually used is revealed: unused branches stay hidden behind the Merkle tree. This is still an improvement over P2WSH, where the entire script is always visible.

Since the vast majority of channel closures are cooperative, the privacy improvement applies to most real-world channel lifecycles.

No in-place upgrade: Existing P2WSH channels cannot be converted to taproot without an on-chain transaction. Channels must be closed and reopened, or upgraded during a splice operation. Eclair v0.14.0 supports upgrading the commitment format to taproot during a splice, avoiding the full close-and-reopen cycle.

On-Chain Footprint Savings

The witness size reduction translates directly into lower fees. A P2WSH 2-of-2 multisig input requires approximately 219 raw witness bytes (two DER-encoded ECDSA signatures plus the redeem script), costing roughly 96 vB. A P2TR key-path input needs only 66 raw witness bytes (a single 64-byte Schnorr signature), costing roughly 57.5 vB. That is a 40% reduction per input.

Real-world measurements from Phoenix wallet's Swaproot upgrade (which combines taproot channels with MuSig2 and BIP 32 key rotation) show practical fee savings at the transaction level:

• 1-input transaction: ~16% cheaper
• 2-input transaction: ~23% cheaper
• 3-input transaction: ~27% cheaper

The compounding savings matter because Lightning channel operations (opens, cooperative closes, splices) happen frequently. Over the lifetime of a routing node managing hundreds of channels, the cumulative fee reduction is significant.

Implementation Status Across Lightning

Simple taproot channels have moved from experimental to production across the two largest Lightning implementations, with the remaining two in active development.

LND (Lightning Labs)

LND first introduced experimental simple taproot channels in v0.17.0-beta (October 2023) via PR #7904, limited to unannounced channels. Over subsequent releases, the implementation added watchtower support, TLV type changes, and RBF cooperative close with a MuSig2 just-in-time nonce pattern. LND v0.21.0 (June 2026) marks the production release with feature bits 80/81. Channels must be explicitly requested: lncli openchannel --channel_type=taproot.

Eclair (ACINQ)

Eclair landed taproot channel support across several PRs in 2025: low-level taproot transaction creation (#3016), MuSig2 partial signature storage (#2896), and full simple taproot channel support (#3103). Eclair v0.14.0 (May 21, 2026) shipped production taproot channels alongside final splicing and zero-fee commitments. ACINQ confirmed full interoperability with LND's implementation by April 2026.

A distinctive Eclair feature: channel commitment formats can be upgraded to taproot during a splice transaction, avoiding the need to close and reopen the channel entirely.

CLN (Core Lightning)

Core Lightning has not shipped simple taproot channels as of mid-2026. CLN supports taproot wallet addresses (newaddr p2tr, since v23.08) and taproot change addresses, but the channel-level upgrade is not yet available. CLN's development focus has been on BOLT12 offers, splicing, and the Greenlight hosted infrastructure. The merged specification (BOLTs PR #995) and cross-implementation interop between LND and Eclair may accelerate CLN's adoption.

LDK (Lightning Dev Kit)

LDK's taproot channel work is in active development. Foundational PR #2289 defines option_taproot feature bits and introduces a signer type enum. LDK has its own MuSig2 implementation for development but is waiting for the libsecp256k1 MuSig2 module with Rust bindings before shipping to production, citing security assurance requirements.

Wallet Adoption

Several wallets already use taproot channels in production. Phoenix (Eclair-based) shipped taproot channels in v2.7.1 (October 2025) and auto-upgrades existing channels during the next on-chain operation. Blixt (embedded LND) has supported simple taproot channels since v0.6.9, and Zeus enabled them in v0.8.0 via its embedded LND node.

The Public Channel Gap: Gossip 1.75

One important limitation: taproot channels must currently remain unannounced (private). The Lightning gossip protocol (BOLT 7) does not yet support advertising or verifying taproot channel funding outputs. Announcing a taproot channel requires Gossip 1.75 (BOLTs PR #1059), which updates channel announcements to use BIP 340 Schnorr signatures and MuSig2 key aggregation for single-signature verification.

Until Gossip 1.75 is finalized and deployed, routing nodes cannot advertise taproot channels to the network. This limits taproot channel adoption to end-user wallets connecting to their LSP via private channels, which is the most common mobile wallet configuration anyway. LND v0.21.0 explicitly prevents auto-selection of taproot for public channels to avoid announcement failures.

What Taproot Channels Unlock Next

Simple taproot channels are explicitly designed as a foundation. The "simple" qualifier signals that this is the minimal commitment format upgrade needed to enable the Schnorr and Tapscript machinery within Lightning. Several features depend on this foundation being in place.

PTLCs: Fixing the Hash Correlation Problem

Point Time-Locked Contracts (PTLCs) replace HTLCs by using signature adaptors instead of hash preimages. Today, every hop in a Lightning payment uses the same hash and preimage, creating a correlation vector: any node that sees the same hash on two of its channels knows they are part of the same payment. This is the single largest privacy leak in Lightning onion routing.

With PTLCs, each hop uses a different cryptographic point and adaptor signature. No two hops share a common identifier. Additionally, point locks can be combined with other required signatures, potentially consuming zero bytes of additional block space compared to a regular spend.

PTLCs require Schnorr signatures (available since Taproot activation in November 2021) and taproot channels as prerequisites. They also require all nodes along a payment route to support the new protocol. The specification, outlined in a design document by t-bast, describes a modified commitment protocol with a new commitment_proposed message for adaptor signature exchange. PTLCs remain at the design stage as of mid-2026.

Channel Factories

Channel factories are multi-party funding constructs where multiple channels are opened from a single on-chain transaction. Instead of each channel requiring its own funding transaction, a group of nodes pools into one n-of-n multisig output that can be subdivided into individual channels off-chain.

Taproot helps channel factories in two ways. First, MuSig2 makes the n-of-n factory funding output look like a single-sig P2TR output on-chain, regardless of how many participants are involved. Second, Taproot's Merkle tree structure means exit transactions only reveal the specific spending path used, keeping the remaining factory structure private.

Channel factories remain in the research phase with no production implementation in any Lightning client. The scaling potential is significant: a factory with 10 participants opening 2 channels each replaces 20 on-chain transactions with 1.

More Efficient Splicing

Splicing lets channels add or remove funds without closing. With taproot channels, splice transactions benefit from the same privacy improvements as cooperative closes: they look like ordinary P2TR spends. Eclair already supports upgrading legacy channels to taproot format during a splice, and LND PR #9982 adds nonce coordination for splice operations in taproot channels.

Dynamic Commitments

Dynamic commitments allow upgrading channel parameters without closing the channel. Built on top of taproot channels, this mechanism enables progressive feature upgrades (such as adding PTLC support later) and can upgrade legacy commitment formats entirely off-chain. This avoids the costly close-and-reopen cycle that would otherwise slow adoption of new channel features.

Specification Architecture: Extension BOLTs

The simple taproot channels specification introduced a new organizational concept to the BOLT standards: extension BOLTs. Rather than modifying the base BOLT documents (BOLTs 2, 3, and 5) with conditional logic for taproot, the changes are documented in a separate extension BOLT that references the base specifications. This approach keeps the base specs readable while allowing substantial upgrades to be reviewed and merged independently.

The specification assigns feature bits 80/81 for simple taproot channels and defines the complete protocol: taproot funding outputs, MuSig2 signing flows, P2TR commitment outputs with tapscript trees, and RBF cooperative close with nonce management.

Timeline of Key Milestones

How Spark Compares

Lightning's taproot channel upgrade is a meaningful step forward for on-chain privacy, but it arrives incrementally: implementations must be updated, channels must be reopened or spliced, and the full benefit (PTLCs, channel factories) remains years away. Spark takes a different approach.

Spark's FROST-based threshold signatures produce single-sig-equivalent outputs from day one. There is no legacy format to migrate from, no channel state to manage, and no gossip protocol to upgrade. Every Spark transaction uses Schnorr-based key aggregation natively, achieving the on-chain privacy that Lightning is still rolling out incrementally.

The tradeoffs are real: Lightning is fully trustless while Spark requires a 1-of-n honest operator assumption. But for users who prioritize privacy and simplicity, Spark provides the benefits that taproot channels promise without the multi-year migration path. The two networks are complementary: Spark supports native Lightning payments, so users can benefit from both.

What Remains

Simple taproot channels are production-ready in two of four major implementations, but the ecosystem still has work to do:

• Gossip 1.75 (BOLTs PR #1059) must be finalized before routing nodes can advertise taproot channels publicly
• CLN needs to implement simple taproot channels
• LDK is waiting for libsecp256k1 MuSig2 Rust bindings before shipping to production
• PTLCs require additional specification work and universal adoption across the route
• Channel factories remain in the research phase with no production implementation

The upgrade path is clear, but the full vision of taproot-enabled Lightning (private routing via PTLCs, scalable onboarding via channel factories, seamless splicing) will take years to materialize. In the meantime, end-user wallets connecting via private channels to their LSP can already benefit from the smaller footprint and improved privacy of simple taproot channels today.

For developers building on Lightning, the Spark SDK offers an alternative path: Schnorr-native key aggregation, no channel management, and Lightning interoperability out of the box. For a deeper look at how Taproot and Schnorr signatures work at the cryptographic level, see our Taproot and Schnorr signatures explainer.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.