How It Started

A colleague who runs his own Bitcoin payment infrastructure reached out to let us know he believed his server had been compromised. The moment we heard, we started tracking the situation closely — not just to help, but because a threat hitting one BTCPay operator is a signal to every BTCPay operator.

At the time, our own SwissLayer BTCPay instance was running a more recent version of BTCPay Server than the one associated with the affected deployment — not the absolute latest release, but newer than the version in question.

We verified that our colleague’s server had in fact been compromised — and when we looked at the on-chain activity, the stolen funds amounted to over 1.5 million USD. Ours remained fully online and functioning normally. We won’t be sharing any details about his incident — that’s not our story to tell, and publishing specifics helps no one but attackers.

Why We Took Our Own Node Offline Anyway

Shortly after, we saw a post from BTCPay Server’s lead developer, Nicolas Dorier, on X addressing the situation. Even though our instance was unaffected and running a newer version, we made the call to bring our node down as a precaution.

That decision comes down to a simple principle: when real funds are involved and there’s active uncertainty about a vulnerability, the cost of being cautious is minutes of downtime. The cost of being wrong is your customers’ money. That’s not a close call.

Monitoring Before Acting

With our node offline, we didn’t just sit and wait blindly. We kept a close eye on the official BTCPay Server Telegram channel, where the team confirmed that the more recent versions had not been affected by the threat.

We didn’t treat that as the all-clear and rush back online. We deliberately waited a further eight hours, watching for any reports of the newer versions being vulnerable. Only once that window passed with no such reports did we move forward.

Updating and Verifying

With confidence that the current release was safe, we:

Updated to the latest version of BTCPay Server.

Verified all funds were present and accounted for — nothing had been touched.

At that point our infrastructure was back on the newest, fully patched release, with funds confirmed intact. But we didn’t stop there. The incident made one thing clear: being on the latest version is necessary, but it is not sufficient. We decided to fundamentally change how our Bitcoin wallet is secured.

Moving to a Watch-Only Wallet

The most important change we made was migrating our Bitcoin wallet to a watch-only setup. In this model, the payment server holds only the wallet’s public key (the xpub). It can generate receiving addresses and watch for incoming payments — but it physically cannot spend. The private keys that authorize spending live offline, under our control, never touching the server.

If an attacker ever gets into the server, there is simply nothing there to steal. You cannot take keys that aren’t present.

Here is exactly how we implemented it, start to finish:

1. Generated a New Wallet Offline

Using Sparrow Wallet on a controlled desktop machine, we created a brand-new wallet with a freshly generated 24-word seed phrase. Native SegWit, single signature.

2. Backed Up the Seed Physically

The 24-word recovery phrase was written down on paper and stored offline. This seed is the only thing that can ever spend the funds — it lives on paper and in the Sparrow wallet file on our machine, and nowhere else. It never goes near the server.

3. Exported the Public Key

From Sparrow, we took only the wallet’s extended public key (xpub) — the public component, safe to share, that allows watching but not spending.

4. Connected It to BTCPay as Watch-Only

On the payment server, we replaced the existing wallet configuration, entering the xpub as the derivation scheme. BTCPay now had the public key only.

5. Verified the Connection — the Critical Step

We generated a receiving address in BTCPay and compared it, character for character, against the first address shown in Sparrow. They matched exactly. This confirms that BTCPay is generating addresses our offline wallet actually controls — not someone else’s.

6. Tested with Real Funds, End to End

We sent a live payment to a BTCPay-generated address and confirmed it arrived correctly in our offline wallet. We then confirmed the reverse: that the server itself is incapable of signing a transaction to move those funds. That inability to spend, from the server’s side, is precisely the point.

With that, the migration was complete and proven: payments flow in, addresses are watched, and spending authority exists only offline.

Why This Matters More Than Ever

Two lessons came out of this, and both are worth internalizing.

Staying up to date is non-negotiable. Self-hosted infrastructure doesn’t patch itself. The version you installed six months ago is not the version you should be running today. Threats emerge, disclosures happen, and the gap between a vulnerability becoming known and your systems being patched is pure exposure. Follow the official channels, apply updates promptly, and actually complete them — a downloaded patch that hasn’t been applied protects nothing.

Watch-only is the architecture the current threat landscape demands. We are now in an era where attackers are faster, more automated, and increasingly augmented by AI. Automated tooling can scan, identify, and exploit exposed infrastructure at a scale and speed that no manual attacker ever could. A hot wallet — one where the spending keys sit on an internet-connected server — is a standing target in that environment, no matter how well patched the software is. Patching closes known holes; it does nothing about the ones not yet disclosed.

A watch-only setup changes the math entirely. It doesn’t matter how sophisticated the attacker or their tooling is, or what undiscovered vulnerability they might hold — if the keys aren’t on the server, they cannot be taken from the server. You remove the prize instead of trying to out-defend every possible attack. In a world where the offense is accelerating, that structural guarantee is worth far more than any single security control.

Where We Stand

Our infrastructure is back online, running the latest patched version, with funds secured under a watch-only model and spending authority held entirely offline. Payments are processing normally, and we continue to monitor the situation.

We moved fast, we stayed cautious when caution was warranted, and we came out of it with a materially stronger setup. If any of this helps another operator secure their own infrastructure, it was worth sharing.

Running Bitcoin payment infrastructure on Swiss servers with the security to match? Talk to us.