The Lightning Security Spectrum

A Promise and Problem of Lightning

You researched and chose a non-custodial Lightning wallet because you believe in "not your keys, not your coins." You carefully secured your seed phrase. You hold your own keys.

Then one morning, you wake up to find your channels have been closed. Your sats have been sent to addresses you don't recognize. The logs show your node approved everything. Your bitcoin is gone. Your Lightning wallet just rugged you.

Lightning promised Bitcoin's secure and self-sovereign principles for instant payments. But something went wrong.

Non-custodial isn't a security model

On Bitcoin L1, non-custodial pairs cleanly with security: private keys stay in cold storage and only sign when you choose. Lightning changes the constraints. Payments, HTLCs, and channel updates are time-sensitive, so signing keys must be online, on your phone, a server, or somewhere in between. On Lightning, "I hold the keys" does not automatically mean "my funds are safe":

• Non-custodial still matters. It means a provider cannot simply move funds at will.
• But non-custodial alone is not enough. Because signing is online, you need a compromise model. Assume an attacker controls your node: what stops them from getting signatures to steal funds?

What matters is this:

If your Lightning node is compromised, what can the attacker do?

Let's map common Lightning setups and find out.

The Lightning Security Spectrum

This spectrum is ordered by a simple test: how hard is it for an attacker to steal funds?

As you move up the spectrum, you generally trade simplicity for a smaller attack surface and stronger guarantees under compromise.

How to choose the right level

Lightning security has two knobs: probability of compromise (how likely someone breaks in) and blast radius (how much can be lost if they do).

A practical way to choose is: how much could you lose before this becomes a real problem?

Keep smaller balances in simpler models. As balances become serious or business-critical, invest in designs that reduce worst-case loss, not just the chance of an incident.

Security is a product decision. The right level depends on how much you are protecting, your risk tolerance, and what failure modes you can tolerate.

Hardened Node Environments (Secure Enclaves / HSM-like)

Level 3 is a common instinct: if the node environment is the risk, harden it. Stronger isolation, tighter access controls, and hardware-backed protections can reduce the chance that "server compromise" becomes "keys stolen."

This can meaningfully raise the bar, especially for operators with mature security and deployment practices. But it's still a hot, online system, so your worst case is still: what will a compromised node sign?

Here is what Level 3 looks like in practice:

Real Incidents and Disclosed Vulnerabilities

These are real Lightning incidents where funds were drained without "breaking Lightning cryptography." The common theme is simple: if an attacker can influence what gets signed, they can steal funds.

These aren't exotic attacks. They are common software and operational failures that become drains because the node is a hot wallet with full authority to approve the theft.

VLS: A Separated Signer With Fewer Attack Vectors

VLS aims to contain compromise by changing the architecture, not just hardening the same architecture.

It does three things at once:

1. Separation: keys and signing decisions move out of the node into a dedicated signer.
2. Reduction: the signer does far less than a node; fewer dependencies, smaller attack surface.
3. Enforcement: the signer validates requests against policy before signing, so a compromised node can't force harmful actions.

Instead of "I hold the keys," the promise becomes:

Even if the node is compromised, the attacker cannot get signatures for actions that violate policy.

Examples of policies:

• Close destinations restricted to approved addresses
• Fee bounds and rate limits
• Payment amount limits and velocity limits
• "Panic button" behavior (lock down signing if something looks wrong)
• And more

VLS in Action

Proof in Practice: Greenlight

Greenlight is an example of the Level 4 pattern in the wild: hosted node convenience paired with a VLS-based validating signer.

This answers the obvious objection:

"Sure, separation and validation sound great, but can it ship without destroying UX?"

Greenlight demonstrates that you can have hosted Lightning convenience without turning 'hot server keys' into your biggest existential risk.

How to Check Your Current Setup

Most Lightning products can tell you whether they are custodial or non-custodial. Almost none will clearly tell you what happens when something gets compromised. So here is a checklist that forces the real answers.

If the only reassurance you get is "it's non-custodial," you do not have an answer to the compromise question.

Call to Action for Developers

Stop selling "non-custodial" as if it answers the hard questions. Ship explicit guarantees.

1. Define your worst-case compromise model (and write it down).
2. Publish what controls prevent unauthorized closes and policy violations.
3. Document recovery, auditability, and operational safeguards.
4. If you want hosted UX, aim for a validating-signer model where node compromise cannot steal funds outside policy.

Security is an architecture choice, not a checkbox.

The Current State: How Secure is Your Wallet?

Here's where major Lightning wallets and LSPs actually fall on the security spectrum.