The Invoice That Lied: Autopsying the lnd/tapd State Divergence

On September 21, 2026, Lightning Labs published an advisory that most of the market filed under "old news." Sixteen months old by the timestamp. A retrospective patch disclosure — already shipped, already resolved. Nothing to see.

I read it three times. Then a fourth, because the sentence that matters is not in the headline. It is buried in the mechanics: for a class of otherwise ordinary Bitcoin payments, a merchant's invoice can be marked settled in the database while the payment itself has already been cancelled at the network layer and returned to the sender.

Two state machines. One payment. Zero agreement between them.

Nothing was stolen here. No private key was compromised. No funds moved to an attacker. That is precisely why this is more interesting than a hack. The system issued a confident, incorrect answer to the one question a merchant actually needs answered: has this been paid?

Hype builds the floor; logic clears the debris. The debris here is a settlement signal that lies.

Context

The Lightning Network is Bitcoin's second-layer payment protocol. It has no native token. Its three dominant client implementations — lnd (Lightning Labs), Core Lightning (Blockstream), and Eclair (ACINQ) — carry the network's routing and settlement logic. A fourth, LDK, ships as an embeddable library.

Lightning Labs packages lnd inside a node management interface called Lightning Terminal. Terminal also bundles tapd, the daemon for Taproot Assets — a protocol for issuing and transferring assets on Bitcoin and over Lightning channels. This bundling is convenient. It is also the structural fact that turns a single component defect into a distribution event.

The affected scope is precise, which is to its credit: legacy Terminal builds, taproot assets ≤ v0.5.0, and lnd between 0.18.4-beta and 0.18.5-beta.

The trigger does not require an asset channel. That single sentence is the most under-read line in the disclosure. It means a merchant running an asset-enabled node with zero asset activity can still be hit by an asset-layer logic error.

The Bitcoin L2 narrative is currently in its acceleration phase. Every funding round, every quarterly report, every conference panel repeats the same thesis: Lightning is the payment rail, Taproot Assets is the asset layer, and the two together form Bitcoin's financial stack. Functionality is being stacked faster than it is being stress-tested. This is the environment in which the defect lived for eighteen months.

Core

Here is the failure, reconstructed as an execution trace.

A sender initiates an HTLC — a Hash Time-Locked Contract, the atomic primitive Lightning uses to make off-chain payments either complete or refund. The HTLC can carry custom TLV extensions: opaque fields appended to the wire message.

In a tapd-enabled node, an invoice interceptor inspects incoming HTLCs. Its rule is blunt: any HTLC carrying custom wire records is treated as a Taproot Asset payment. That assumption is reasonable inside tapd's own domain. It is catastrophic when it leaks outside it.

Because some sender implementations append experimental endorsement records to HTLCs — even for plain BTC payments. Not maliciously. Just experimentally. A wallet developer testing a feature.

The result: tapd's strict forwarding rules classify a plain Bitcoin payment as an asset payment and instruct lnd to cancel the entire HTLC set. lnd complies. The network layer cancels the HTLC and returns the funds to the sender, correctly.

Then lnd writes the invoice as settled in its database. That is the second defect, and it lives in lnd, not tapd.

Two components, two bugs, one outcome. The interceptor misfired; the ledger recorded the misfire as success.

Code does not lie, but it often omits the truth. The network state was honest. The database state was not.

The broader exposure sits in lnd's HtlcModifier interface — a hook that lets clients intervene and cancel HTLC sets. Any third-party client that calls it and cancels a set can reproduce the same mismatch. The advisory does not list such clients. It does not need to. The interface's generality is the risk.

The architectural sin is a boundary. tapd was written to intercept asset payments. Its classification rule — custom records equal asset — works only if custom records are exclusive to assets. They are not. HTLC wire records are a general-purpose extension field, and experimental implementations were already using them. tapd's rule assumed a closed namespace inside an open protocol.

That is the same class of error I documented in the Parity multisig wallet in 2017, where a library function's initialization assumption collided with a caller that never initialized it. Different layer, same logic: a component trusting an unverified precondition it does not own. I spent four weeks on that audit and wrote 45 pages on memory allocation instead of chasing a bounty. The lesson that carried into every subsequent engagement is this: the defect is almost never in the component that fails. It is in the assumption the component inherited.

Trigger probability is not uniform across the network. It correlates with the distribution of specific wallet and LSP implementations — those that append experimental records. The defect did not fire evenly; it fired in clusters, wherever experimental senders and tapd-enabled merchants intersected. Cluster-located failures are historically the hardest to attribute. A merchant seeing intermittent settled-but-unpaid invoices would blame the payment, the counterparty, or their own accounting. Very few would blame the invoice interceptor.

Then there is the half-fix trap, and this is the detail I would escalate to any merchant running production infrastructure. Lightning Terminal v0.14.1-alpha contained the fix for Terminal — but the lnd version bundled inside it was still defective. A user who upgraded Terminal, watched the version number move, and assumed remediation would have been running a node that remained vulnerable. The advisory confirms this state occurred.

Docs confirm what should alarm you: this is not theoretical. Trust is a variable; verification is a constant — and here, version-number trust was the variable that failed.

Remediation, read as a timeline: tapd patched at v0.5.1 on February 12, 2025. lnd patched at v0.19.0-beta on May 22, 2025. Terminal's wrapper released as v0.15.0-alpha. Three layers, three releases, sequenced over roughly three months. The engineering is not in question. The sequencing is: because Terminal bundles lnd, a user upgrading one without the other lands in a half-remediated state, and version numbers do not make that visible.

The disclosure also arrived beside an unrelated warning: malicious bots actively scanning exposed Bitcoin payment servers to harvest admin macaroon credentials. Macaroons are lnd's authentication tokens — API keys, functionally. A leaked admin macaroon is full node control. A merchant reading the invoice advisory is being told their settlement signal can lie; the same merchant reading the macaroon warning is being told their credentials are being hunted. Two vectors, one operator, no slack.

Step back and the shape is familiar. A feature built for one domain — assets — introduced an attack surface into an adjacent domain — payments — without a boundary check. The interceptor was not compromised. It was granted authority it should never have had over a path it did not own. In state machine terms: the asset layer acquired write access to the payment layer's settlement record. That is privilege escalation by design.

Kill Switch

The exact conditions under which this defect causes loss:

First, the node runs a bundled Terminal build with tapd ≤ v0.5.0 and lnd in 0.18.4–0.18.5-beta. Second, a counterparty sends an HTLC carrying custom records with no asset channel in existence. Third, the interceptor cancels the set. Fourth, the merchant's order system trusts the invoice state and releases goods or credit.

All four must hold. Remove any one and the loss does not occur. The fourth condition is the only one under the merchant's direct control — and it is the one almost nobody instruments. Order systems, chargeback logic, and credit extension all key off the invoice state. Fewer still reconcile that state against network-layer finality. When the invoice says settled, the warehouse ships.

Contrarian

The bulls, for once, are substantially right, and I will say so because an audit that only finds fault is not an audit.

Sender funds were never at risk. Base-chain settlement never failed. The Lightning protocol performed as designed — this is an implementation defect, not a protocol flaw. And the response chain was clean and layered: tapd v0.5.1, lnd v0.19.0-beta, Terminal v0.15.0-alpha. Three components, three fixes, one coordinated sequence.

That is competent engineering.

What is not competent is the disclosure governance. The gap between fix and disclosure is roughly sixteen months. Severity was self-assigned, with no third-party audit cited. No loss statistics were provided. The advisory does not explain the delay.

A patch-first, silent-fix strategy has defenders. Ship the fix, suppress the announcement, deny attackers a roadmap. Defensible. But sixteen months is a long silence, and silence is a disclosure position, not the absence of one.

Takeaway

The patch has existed for eighteen months. The disclosure is days old. Everything that matters now lives in the gap between them — patch coverage.

Almost nobody is tracking it. Node version distribution is observable, and almost nobody is looking. That is the untracked variable of this entire event, and it determines whether the defect produced unrecognized losses during the sixteen months it was quietly fixed and quietly unknown.

Watch for a second narrative: settlement verifiability. Merchants content to trust a status field will start demanding reconciliation tooling. That demand is new, and it is rational.

The code was ready. Most of the network was not.