Post-Mortem: Security Update - August 5th, 2026

On August 5th, ZEUS infrastructure was attacked. We took our services offline, contained the incident, and restored operations in stages over the following week.

No customer funds were lost. No customer funds were ever at risk.

We promised a full accounting once our investigation was complete.

What happened

On August 5th, an attacker gained access to ZEUS infrastructure. The entry point was a recently disclosed vulnerability in BTCPay Server, which we use for auxiliary functionality in our stack including providing fiat currency exchange rates and accepting donations. The vulnerability allowed attackers to obtain the admin macaroon for a connected LND node, the credential that grants full access to that node. This wasn't unique to us. The same bug was exploited against many BTCPay instances across the ecosystem.

It's since been patched upstream. If you run BTCPay Server, update to 2.4.2 or later now. In Docker-based deployments this also regenerates your LND macaroons. Those on custom deployments are advised to do this manually.

We detected the intrusion and mitigated the attack the same day, then kept everything offline while we audited every system before bringing anything back.

Most of our publicly-announced and many of our private LSP channels were closed by the attacker using the stolen credentials. It's worth understanding what a channel close actually does: it settles each side's balance back to its owner, on-chain, by protocol design. Closing a channel doesn't steal its funds. Disruptive? Absolutely. But customer balances landed exactly where the protocol promises: under their owners' control. Replacement channels for affected customers have been processing since the week of August 10th. Contact customer support if you need a replacement channel; we will provide you with one at no cost to you.

We didn't walk away unscathed, though. The attacker stole funds from ZEUS's own operational wallets. That loss is ours alone. The company absorbed it, and no customer funds were involved at any point. It's the deal you sign up for as a non-custodial operator: your funds are yours, the operational risk is ours. We took the hit, but the model held.

Restoration ran in stages. ZEUS Pay Lightning addresses returned August 6th. ZEUS White, block source, and graph data services never went down. Olympus, our primary Lightning node, came back online August 8th, and LSP channel services followed.

One more note from that week: we asked large node operators to help us bootstrap Olympus with inbound liquidity, and the network answered. Operators opened significant capacity into our infrastructure within days. Thank you. Lightning is a network of peers, and this is what that looks like when it matters.

What we found

The vulnerability was upstream. It was responsibly disclosed by Craig Raw and the Bitcoin Red Team, and the BTCPay Server team has patched it and published their own advisory and response, including direct support for the researchers who found it. Go read it if you run their software. That's the disclosure norm this ecosystem needs.

The blast radius, though, was ours. Our investigation identified three conditions that let a foothold in one service become a company-wide incident. Multiple teams have reviewed our systems independently afterward. They confirmed our findings and surfaced a handful of additional minor issues, all since remediated. We've hardened both our infrastructure and our internal services.

We're sharing the three findings in full because none of them are unique to ZEUS. Any operator on this network can use them.

Too many resources on one box. Our BTCPay Server instance, our Lightning node, and Olympus services shared infrastructure. Co-location means a foothold in one service is a foothold near all of them. A bug in a payment server should never be within reach of a node's credentials. These services now run isolated from each other, so a compromise of one is a compromise of one.

Firewall configurations were too permissive. Our rules were broader than the services behind them needed. Every rule has been rebuilt to the minimum each service requires. Nothing more.

Credential files at rest on disk. Macaroon files, the credentials that grant access to a Lightning node, should never sit where other services can reach them. Ours could be reached from the compromised service, and that's what turned a web vulnerability into node access. That pattern is gone from our infrastructure. It's also the single most transferable lesson here: if you run a node, go look at where your macaroons live. Right now.

One point of precision on our original advisory: we said we found no evidence this incident resulted from a vulnerability in Lightning node software. That holds. The vulnerability was in BTCPay Server. LND did exactly what it was designed to do when presented with valid credentials. The failure was that those credentials were reachable at all. That part's on us, and we've fixed it.

The AI question

There's been a lot of discussion about AI-assisted attacks on Bitcoin infrastructure lately, and this summer gave the ecosystem real reasons for it. BTCPay instances across the ecosystem were exploited through the vulnerability described above. Boltz suspended its swap service after sustained AI-assisted attacks, several of which succeeded, with the losses falling on Boltz itself rather than its users. Then us, through that same BTCPay bug.

So here's our honest read on where AI actually stands, because the picture is more nuanced than the headlines.

Our attacker was more capable than a script kiddie. They were also clearly not a Bitcoin specialist. Their actions during the incident showed a limited understanding of how Lightning actually works, which shaped what they could and couldn't do with the access they had.

There's a detail from this vulnerability's discovery worth knowing: the developer who worked the initial incident reports that a leading frontier AI model couldn't find the underlying bug on its own. Only after the developer was attacked, pulled the logs, and fed the model that context did it identify the issue. The models aren't moonshotting these attacks. They still need an operator with real context to point them.

That's the silver lining, and we'll take it. But it's a snapshot, not a trend line. AI keeps lowering the cost of probing every codebase on this network, and that cost only goes down from here. The correct response isn't relief. It's raising the floor:

• Regular penetration testing of our own systems. Offense against ourselves before anyone else gets the chance.
• Continuous code scanning across our repositories.
• Infrastructure as code, so our run scripts manage everything and configuration lives in reviewed, versioned code instead of being copied between machines.

Assume breach. Build so that when one lands, it reaches nothing that matters.

Zaplocker

As part of this security review, we've disabled Zaplocker.

Zaplocker's design relies on receiving services correctly implementing their own payment checks. Where a service hasn't implemented those checks properly, the mechanism can be abused to extract funds from that service. In the current threat environment, running a system whose safety depends on every downstream implementation getting it right isn't responsible. So we shut it off.

For users, alternatives are already in the app: Nostr Wallet Connect (NWC) and Cashu-based ZEUS Pay addresses cover remote-node and 'node in the phone' users alike, albeit with their own set of tradeoffs. Moving forward, we're evaluating a few other different approaches for self-custodial Lightning addresses.

Boltz, swaps, and splicing

What happened to Boltz this month says something structural about this network. It goes beyond any one incident, including ours.

Boltz was hit by the same wave. AI-assisted attacks against their infrastructure grew in frequency and sophistication over months, and several succeeded. Because Boltz is non-custodial, user funds were never at risk. The losses landed entirely on Boltz itself, and on August 3rd they suspended the service to stop the bleeding. Within days, a group of Bitcoiners stepped in with the capital and engineering resources to take the project over. The founders stepped down, and the new team is working to bring swaps back. We hope they succeed, and soon. The Boltz team built something the whole ecosystem leaned on, and they absorbed the cost of the attacks themselves rather than pass any risk to their users. That deserves to be said.

But look at what the episode demonstrated. Non-custodial design protects your funds. It doesn't protect your workflow. Wallets and services that relied on Boltz for swaps lost that capability overnight, and whether it comes back, and when, came down to a change of ownership and a rescue that a five-person team couldn't have counted on. If your product depends on one company existing and operating, that's a dependency, no matter how well the custody model is built and no matter how good the people running it are.

We're part of this story too. ZEUS runs a swap service built on Boltz's open-source stack, and we took our own instance offline as a precaution when Boltz first disclosed what they were up against. It remains offline while we review. Any decision about its future will be based on the security work, not the news cycle.

We run one of the most connected nodes on the network and operate an LSP serving thousands of self-custodial wallet users. At that scale, rebalancing channel liquidity is a daily operational reality, and swaps were one of the tools for doing it without on-chain channel operations. Swaps may return. But the dependency they represent doesn't go away when the service comes back. So what do you build on that can't be suspended, acquired, or rescued?

Splicing.

It was already on our roadmap. Splicing lets you add or remove funds from a live channel without closing it. It's negotiated directly between the two channel peers and settled on-chain. No third party.

The protocol side is ready. Splicing was merged into the BOLT specs. Core Lightning enabled it by default. Eclair runs it in production. LDK moved splice support to a production feature bit in February. The remaining work sits in the signing layer, and that's where we're putting our weight: we're directing resources to the Validating Lightning Signer project's splicing effort in an attempt to accelerate it. After this summer, we think protocol-native rebalancing with independent signer validation is the best long-term answer for anyone on this network, not just us.

When a splice happens, the signer independently verifies it: value conserved, splice-out destinations pinned to addresses the funds' owner controls, balance changes reconciled. The signer checks, or it doesn't sign.

Our LDK-VLS fork isn't public yet. It will be. VLS itself is open source, our work builds on it, and open-sourcing our contributions is part of the plan, not an afterthought. When it lands, you'll be able to read the splice validation logic yourself.

It's not magic. On-chain settlement means miner fees, so in a high-fee environment a splice won't always beat what a swap costs. Splice validation is new signer logic, which earns trust the way all signer logic does: testing and an audit before anyone relies on it. Until then, cooperative close remains the fallback. It's the most conservative operation in Lightning.

Splicing moves rebalancing from something a vendor provides to something the protocol does. A protocol feature can't announce it's disabled until further notice. No fee to a middleman, no counter-party in the flow, no service to go down.

What this confirmed

Our original advisory said this incident reinforces work we'd already been doing. Here's exactly what that means.

The architecture for ZEUS Route we've been building separates the node from the authority to spend. Keys live inside a trusted execution environment. Every transaction the node proposes is independently validated against policy by the Validating Lightning Signer before anything gets signed: destinations, amounts, velocity, channel state. The node requests. The signer decides.

Under that architecture, an attacker who fully compromises a node gets an incident, not a theft. They can disrupt. They can force channel closures, and the funds land back at addresses the owner controls. What they can't do is reach signing authority, because it was never on the box they took.

August 5th showed both sides of that line. Where a credential on disk was spending authority, a web vulnerability became access to funds. Where the signer stands apart and validates every transaction, the same compromise is an outage, not a loss.

That's the design for ZEUS Route to securely allow treasury deployments, and it's where all of our infrastructure is headed. August 5th didn't change that direction. It confirmed it, and it moved up the timeline.

What's next

Fewer vendors in the critical path. More protocol in their place. Less standing between an attacker and nothing.

Thank you to our customers and the broader Bitcoin community for the patience and support over the past week. It was felt.

Always forward.