Hook
On September 14, ACINQ shipped Eclair 0.14.3. The release notes read like plumbing โ a version bump, a handful of behavioral changes, a nudge to upgrade. What they actually describe is a method by which a counterparty can delete your channel balance without taking a single satoshi for themselves. The value doesn't move to the attacker's wallet. It moves to a miner's.
I read that patch three times before the economic model resolved, and when it did, the discomfort wasn't about the exploit. It was about the motive. Every security model I've built over the last decade assumes the adversary wants your money. This one doesn't. The adversary wants your balance destroyed, and the profit accrues to a third party who never signed a transaction with you and may not even know your node's pubkey. That is a different species of threat, and the standard defensive playbook โ watch for outflows, reconcile your ledger, alert on unexpected debits โ is largely blind to it. There is no outflow to alert on. There is only a channel that closes at a number you never agreed to, and a fee that lands in a block you can't reverse.
The ledger remembers what the code tries to hide. So let's read it.
Context
To understand why this matters beyond a single node implementation, you have to hold the Lightning Network's actual topology in your head โ not the marketing diagram, the real one.
Bitcoin's Lightning Network is a second-layer settlement system built on hashed timelock contracts and revocable commitment transactions. It has no canonical client. It has implementations, and those implementations compete for operators on the basis of throughput, liquidity tooling, and feature velocity. Three matter: LND, developed by Lightning Labs and by far the most widely deployed; Core Lightning, Blockstream's C implementation; and Eclair, maintained by the French team ACINQ, which runs leaner, ships faster, and makes a deliberate bet on aggressive feature delivery.
ACINQ is not a minor player, and this is where the story gets structurally interesting. They don't just ship Eclair. They also ship Phoenix Wallet, a non-custodial consumer wallet that sits on top of the same codebase. That means ACINQ occupies two layers of the same stack โ the node software and the end-user interface. When something breaks in Eclair, it doesn't stop at the operator's boundary. It walks downstream into wallets that ordinary people use to buy coffee and receive salary payments. I've spent enough time mapping counterparty exposure in trading systems to know that vertically integrated teams have enormous execution advantages and equal-amplitude blast radii. ACINQ is that.
Downstream of all three implementations sits another layer most retail readers never think about: integrators. BTCPay Server is the canonical example โ a self-hosted, open-source Bitcoin payment processor used by merchants who specifically do not want a custodial processor holding their settlement. BTCPay runs on LND. When BTCPay has a bad week, merchants feel it. When merchants feel it, they stop accepting Lightning, and that decision is far stickier than the original integration.
And then there's Bitcoin Optech, the technical intelligence newsletter that functions as the ecosystem's de facto verification layer. Optech doesn't publish marketing. It publishes diffs and consequences. When Optech confirms a patch has landed and explains its scope, that confirmation carries more weight in my risk model than any vendor's security page. Uptime is a promise; downtime is the truth.
Now set that against the current market. We are in a bear tape. Capital is scarce, LP positions are under pressure, and every protocol in the ecosystem is being asked the same question by the same people: is my money safe, and if not, how fast can I get out. In a bull market, security disclosures are a footnote. In a bear market, they are the entire valuation model. This disclosure landed in the second environment, which is why a set of patches that would have been a two-day story in 2021 is now a structural event.
Core
Three distinct defects shipped in the same advisory window, and they share a signature: each one is triggered by a counterparty who behaves badly on purpose, and each one sits on a code path that Eclair itself chose to make more capable than its competitors.
Start with the cooperative close fee manipulation. In a cooperative close, both parties agree to sign a single transaction that settles the channel and returns each side its balance minus a negotiated fee. The fee is supposed to be a rounding error โ a few thousand sats to get the transaction mined. Eclair, when it was responsible for proposing or evaluating that fee, used a fallback negotiation path that would accept a proposal even when the proposed fee exceeded the local party's available balance. The result is mechanically simple and economically ugly: the victim's output gets erased. Their balance doesn't go to the attacker. It goes to the miner, because a transaction's fee is simply the difference between inputs and outputs, and the victim's erased output is now part of that difference.
This is a value-destruction attack, not a theft attack. I want to be precise about that, because the distinction changes how you defend against it and how you should think about who profits. There is no preimage to steal, no key to exfiltrate, no hot wallet to drain. There is a negotiation that should have been rejected on arithmetic grounds and wasn't. The patch logic is exactly what you'd expect once you see the flaw: refuse to entertain a fee proposal above a hard ceiling, and force closure using the fully signed current state rather than an improvised one.
The second defect is the splice lockup. Splicing is the operation of resizing a channel โ adding or removing on-chain funds โ without closing it. It's a genuinely useful primitive, and Eclair implemented it earlier and more eagerly than LND did. The attack works by sequencing: Eclair signs first, the counterparty withholds its signature, and now the latest channel state depends on a transaction the victim cannot broadcast. The counterparty can then let the inbound leg of an in-flight payment expire, broadcast an older state, and use the payment preimage to claim the outbound leg for itself.
If that sequence sounds familiar, it should. Withhold a signature, let the counterparty's clock run out, broadcast a stale state, harvest the preimage โ that is the architectural fingerprint of the replacement-cycling family of channel-jamming attacks that Antoine Riard spent two years warning the ecosystem about. I'm inferring the lineage, not asserting it; the advisory doesn't name the attack class. But the mechanics rhyme too closely to be coincidence, and the defensive conclusion is the same either way: a protocol that lets one side sign before the other can be made to hold the bag.
The third defect is the one that should worry operators of routing nodes specifically. Eclair supports on-the-fly funding โ sometimes called JIT channels โ where a node opens a channel in the same flow as forwarding a payment. A malicious wallet can manipulate the expiry of the payment so that the on-chain outbound payment is claimable while the inbound payment has already expired, leaving the routing node holding a loss it never agreed to. This is counterparty risk wearing a disguise. The routing node thinks it's being paid for a service; it's actually extending unsecured credit to a stranger with a clock.
And then there's the fix that tells you the most about the system's prior assumptions. Eclair 0.14.3 introduces a default automatic fee ceiling of 50 sat/vB. That number is not arbitrary and it is not the headline. The headline is that Eclair's fee logic was previously trusting an external estimator to a degree that let bad data drive bad behavior. A fee estimator is an oracle. It ingests mempool conditions and returns a number your code will act on without further scrutiny. Any time you accept an external number as an input to a financial decision, you have accepted an oracle dependency, and oracle dependencies fail in exactly one direction: quietly, at the worst possible moment. Capping the output at 50 sat/vB is the engineering equivalent of refusing to sign a blank check. It's a good patch. It's also an admission.
Now step sideways to the second front in the same news cycle, and it's a different kind of failure. BTCPay Server โ and by extension the merchants running on it โ was targeted by operators exploiting LND's RPC interface. Not a cryptographic break. A configuration and operations problem. Nodes with manually exposed LND APIs and weak or reused credentials were at risk of full takeover; an attacker who gets the macaroon controls the node's spend authority, which means the wallet goes with it.
That last part deserves emphasis, because macaroons are frequently misunderstood by operators who treat them as read-only API keys. They aren't. A macaroon is a bearer credential encoding specific permissions, and if the wrong one leaks, the holder can do everything that macaroon permits โ including moving funds. There is no password check on the other end of a valid macaroon. There is only the cryptographic assertion that the holder is allowed.
And here's the operational detail that made me sit up. BTCPay's mitigations included using a unique password, blocking unauthenticated routes at the network edge, and advising operators not to expose the API at all. Those are sound hardening steps. They're also remediation at the perimeter rather than the root. When your fix is "block the door better" rather than "remove the door," you're telling the market that the underlying interface design remains the exposure. I've seen this pattern in institutional trading infrastructure for years: a counterparty gets breached through a hand-configured port, everyone patches the port, nobody asks why production spend authority was reachable from the public internet in the first place.
And there's a detail in the BTCPay disclosure that most coverage skipped entirely: bots were observed probing the exposed endpoints, and the vulnerability window widened whenever an administrator manually re-enabled external access for maintenance. That is not a targeted campaign. That is automated scanning at scale, with opportunistic exploitation of a human operational rhythm. The attacker doesn't need to know you. They need to know that some percentage of operators reopen a door every time they perform maintenance, and they need a bot that checks every few minutes. The math of that is brutal and it's the same math I use when sizing any asymmetric trade: low probability per attempt, enormous number of attempts, catastrophic payoff. Against a population of hundreds of nodes, it's not a question of whether someone gets hit. It's a question of how many.
Trace the value flows and the picture sharpens. In the cooperative close attack, the loss is externalized to miners via elevated transaction fees. In the splice and JIT attacks, the loss lands on routing nodes โ the liquidity providers whose business model depends on forwarding payments for a fee and whose capital is therefore concentrated in exactly the channels being attacked. In the BTCPay and LND attacks, the loss lands on merchants and, transitively, on any customer transacting with them during the window. In none of these cases is the primary victim the party holding the most information about the risk. The routing node didn't sign up to underwrite a stranger's expiry manipulation. The merchant didn't sign up to be the endpoint of an attack on an RPC interface. The channel holder didn't sign up to donate their balance to a mining pool.
I trade the gap between expectation and execution. And the gap here is enormous. Operators expect that running current software means running correct software. The advisory says otherwise.
Contrarian
Here's the angle that I think most of the coverage got wrong, and it's not a technical point โ it's an economic one.
The cooperative close bug has a zero-yield paradox at its center. The attacker gains nothing. The victim loses everything. The value flows to a miner who is, in the ordinary case, a completely passive third party. A rational, profit-maximizing adversary does not run this attack, because the return on capital is negative once you account for the cost of finding and maintaining counterparties to exploit. So either the attacker is not profit-maximizing, or they are not the only beneficiary.
Three plausible resolutions. First, the attacker is a miner or is coordinating with one, and the "fee to the miner" is actually a rebate to the attacker through a side channel. Second, the motive is griefing โ pure destruction, which exists in this ecosystem and always has, but doesn't scale as a business. Third, and this is the one I'd watch, the real victim isn't the channel holder at all. It's whoever sits downstream of that channel holder and depends on their solvency. An exchange. A custodial service. A merchant processor. If you can burn a routing node's balance for free, you can degrade a competitor's liquidity position at your own expense and their existential one. That's not a hack. That's a slow-motion seizure of market share dressed as vandalism.
The second thing most coverage missed is a framing problem. The headlines leaned on the most dramatic phrasing available โ an entire balance going straight to miners โ which is technically accurate and materially misleading about the current state of risk. The vulnerability was patched. Optech confirmed it. ACINQ shipped within a reasonable disclosure window and told operators, in no uncertain terms, to upgrade. The residual risk is not "your funds are in danger." The residual risk is "you have not upgraded." That's a completely different threat model, and conflating the two produces bad decisions in both directions. Panic sells the software that would fix it; complacency leaves unpatched nodes online for months.
And this brings me to the structural claim I actually want to make, the one that should outlast this news cycle. The three Eclair vulnerabilities did not cluster randomly. They clustered on splicing and on-the-fly funding โ the two features Eclair shipped earlier and more aggressively than LND. That is not a coincidence and it is not an indictment of ACINQ's engineering. It is a statement about the state of the entire Lightning implementation layer: feature velocity is outrunning security verification, and the gap between the two is where capital gets destroyed.
I have a version of this argument I use about Layer 2 data availability, which I'll save for another piece, but the shape is the same. A capability gets shipped because it's a differentiator, gets adopted because it's a differentiator, and gets stress-tested only after it holds real money. The stress test is not optional and it is not cheap. Splicing is a genuinely useful primitive. On-the-fly funding is a genuinely useful primitive. Both were shipped before either was proven against a motivated adversary, and the cost of discovering that was a set of channel-balance losses and lockups for operators who upgraded their client on release day.
That's the real signal, and it's ecosystem-wide. LND, the dominant implementation, was under simultaneous pressure from a completely different vector โ the operational one. Two implementations, two entirely different failure classes, one news cycle. If you're reading this as "Eclair had bugs and fixed them," you're reading it as a single-node story. Read it as an implementation-layer story. The maturity of the whole stack is being price-tested in public, in a bear market, in front of a user base that is already inclined to be skittish.
There's a corollary I'll state plainly because it affects how I size exposure. Routing nodes are now structurally targeted. Both the splice attack and the JIT attack aim at nodes that forward payments, because that's where liquidity concentrates and where expiry windows create leverage for an adversary. The business model โ earn fees by committing capital to other people's transfers โ is the exact profile that attracts this class of exploit. Routing operators need to internalize that their counterparty set is an attack surface with a P&L attached, not a list of anonymous peers who are presumed well-behaved.
And one more contrarian note on the vendor side, because it's the kind of thing that gets decided quietly and matters for years: security posture is about to become a competitive axis between implementations in a way it hasn't been outside of core developer circles. Institutional adopters โ exchanges, payment processors, custody shops โ don't evaluate Lightning implementations on feature lists. They evaluate them on response latency, disclosure discipline, and whether the maintainer's incentives align with rapid remediation. ACINQ scored well on that this cycle. The next cycle is where the score gets defended.
Takeaway
The actionable layer of this is narrower than the coverage suggests, and it splits cleanly by whether you're an operator or an observer.
If you run Eclair: upgrade to 0.14.3 immediately, and set your automatic fee ceiling to a deliberately conservative value rather than accepting the default without thinking about it. Patch and parameter are separate decisions. The default of 50 sat/vB is the floor of responsible configuration, not the ceiling of it. If you run a routing node, audit your splice and JIT exposure after upgrading โ the patch closes the exploit path, not the underlying counterparty risk โ and start maintaining an explicit blacklist of peers who've demonstrated malicious behavior. That list is an asset. Build it before you need it.
If you run LND behind BTCPay or anything else: do not expose the RPC interface to the public internet. Use unique credentials for every macaroon, scope them to the minimum permission the service actually needs, and block unauthenticated routes at the network edge rather than inside the application. And pay attention to the maintenance-window problem, because that's the one that gets people. If your remediation involves briefly re-exposing a service, automate the re-exposure so the window is measured in seconds and is not dependent on a human remembering to close a door.
If you hold bitcoin and use Lightning incidentally: nothing in this cycle justifies moving your funds. The patched vulnerabilities do not threaten a wallet that runs current software, and the correct response to a disclosure of this type is update, not exit.
The forward-looking question is the one I'll leave sitting on the table, because I don't think anyone has answered it yet, and I don't think the answer is technical. Every implementation in this ecosystem now knows, publicly, that shipping a new primitive ahead of the competition carries a measurable balance-sheet cost. The next time a splicing improvement or a routing optimization is on the roadmap โ and there will be a next time, probably within two quarters โ does the ecosystem slow down to verify first, or does it keep shipping and continue to discover the costs in production? If the answer is the latter, then the fee-burn bug of September 2025 is not an anomaly. It's the template. Trust the math, verify the chain, ignore the hype โ and check whether the people building your infrastructure are willing to do the same before the exploit is published.