Validating Lightning Signer

“Non-custodial” is not a security model on Lightning. Because signing must be online, the real question is: If your node is compromised, what can the attacker do?

One underrated reason to use VLS: you stop asking your product team to become a Lightning security team. That means less custom key-management work, fewer homegrown mistakes, and more time building the actual product.

For tiny balances or hobby setups, a hot wallet may be an acceptable tradeoff. For larger balances, production services, or customer-facing infra, the bar should be much higher. Not every setup needs VLS. Serious ones do.

VLS is for teams that want Lightning security to hold up under failure. Not “secure if everything behaves.” Secure even when the node misbehaves. That’s a better design target.

Most Lightning setups still assume the node can be trusted with keys. It can’t. VLS is built around a different assumption: the node can be compromised, and funds should still be protected.

If your Lightning keys live in the same hot environment as your node, assume this: node compromise = total loss. ‘Non-custodial’ doesn’t change that. Only moving signing policy outside the node changes that.

VLS is not “a hardware wallet for Lightning.” It’s a different security boundary: the node proposes actions, and the signer independently checks channel state and policy before producing signatures. The goal is simple: make “node compromise” insufficient for theft.

A Lightning node is a big, messy program: networking, gossip, routing, plugins, updates. If keys live inside that blast zone, compromise is catastrophic. VLS moves keys into a smaller program with a narrower API and fewer dependencies. Smaller target, fewer ways in.

VLS is defense against the most common real-world failure mode: not “broken crypto,” but “attacker influences what gets signed.” If your threat model ends at “we are non-custodial,” you are not modeling the thing that actually drains wallets.

To evaluate a Lightning wallet quickly, ask: “Where do the keys live, and what code runs next to them?” If the answer is “inside the node or app,” assume huge attack surface. If the answer is “in a dedicated validating signer,” you are having the right conversation.

The best pitch for VLS is not “perfect security.” It is “smaller trust domain.” You are reducing the amount of software that must be perfect to protect funds. In Lightning, that is the difference between hoping nothing goes wrong and engineering for when it does.

Fun fact: not even Ethan Hunt can break into VLS. Source: he tried and failed. Mission impossible indeed.

Validating signer = separation + independent checks. The node can ask to sign something. The signer says: ‘Only if this request matches valid channel state and policy.’ That’s the entire point: reduce the set of things a compromised node can do.

Rather than asking “Do you use enclaves?” Ask: “What holds the keys and decides what gets signed?” If it’s the node, any compromise is game over. If it’s a separate validating signer, you’ve narrowed the ‘must-compromise’ target to something smaller and easier to secure.

If you run Lightning for real money the million dollar question is: “If my node gets owned tonight, what stops the bleeding?” “We’re non-custodial,” is not an answer. If the answer is “signing policy is enforced outside the node,” now you’re talking.

What does “policy” mean in practice? Stuff that actually stops drains: - destination allowlists for closes and withdrawals - per-tx limits - velocity limits - fee bounds - invoice freshness - time windows - emergency lockdown These are boring controls. That’s why they work.

This is the clean mental model:Hardening (enclaves, HSM-like controls) lowers the odds you get hacked. It doesn’t change what happens if you do. If the Lightning node still holds keys, a successful compromise still has unlimited signing authority.

“The node approved everything” is the scariest line in Lightning ops because it can be true even when keys were never extracted. If the attacker controls logic which influences what gets signed, signatures can be valid and losses still total.

VLS is a simple idea with big consequences: move signing decisions out of the node into a small signer that validates requests against policy before signing. That changes the failure mode from “node compromise drains funds” to “node compromise gets blocked outside policy.”

VLS doesn’t make compromise irrelevant. It changes which compromise matters. Node compromise becomes survivable. Signer compromise remains catastrophic.