“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?

Ask any Lightning wallet one question: if your servers are hacked, can my funds be stolen? If the answer is yes, the keys are on a custodial hot node. VLS exists so the answer can be no.

A Lightning channel is a running agreement that updates over time, with old versions cancelled as new ones replace them. VLS keeps its own copy of that history so it can refuse a request to revive a cancelled version.

VLS enforces limits the node cannot override: where closes can go, how big payments can be, how fast funds can leave, what fees are acceptable. The node can ask to violate these limits. It just will not get a signature.

If your Lightning node is hacked, the useful question is what the attacker can actually do. With VLS, the answer is: only what your rules already allow. Everything else gets no signature.

VLS can run on a $10 microcontroller like an ESP32. The same checks that protect a server deployment fit on a chip that costs less than lunch. The code that does it is public on our GitLab.

A validating signer and a hardened node solve different problems. Hardening tries to keep attackers out. VLS assumes one gets in and stops them from moving funds anyway. You can do both. You should do both.

VLS signs for Core Lightning and LDK nodes. The keys move to the signer, the node keeps doing everything else, and every signature now passes through policy checks first.

Most Lightning theft does not break any cryptography. A bug or an attacker gets the node to sign something harmful, and the node has the authority to do it. VLS takes that authority off the node.

With VLS, "your keys" is not just where the key file sits. It is who decides what gets signed. The user's signer makes that call, so even a hosted node cannot spend without passing its checks.

A leaked node credential lets an attacker send commands to your node. If the keys live on the node, that's game over. If VLS holds the keys, the attacker has wasted their time and resources for nothing.

What VLS does, plainly: it holds the keys, keeps its own record of every channel, and refuses to sign any request that does not match that record. The node never touches a key.

The point of VLS in one line: compromising your Lightning node is no longer enough to steal your funds. The attacker also has to get past a separate signer that checks every request.

VLS is written in Rust and licensed Apache-2.0. The full signer, every policy check, is public on GitLab. You can read exactly what it will and will not sign before you trust it with anything.

A hosted Lightning node gives you uptime without running your own server. Pair it with VLS and the host still cannot move your funds: the keys and the rules live on your signer, not theirs.

In Lightning, the same key signs many times as a channel updates. So the signer must know the channel's current state to sign safely. VLS tracks that state. A signer that does not cannot tell a valid request from a theft.

VLS does not trust the node. It keeps its own view of every channel and treats each signing request as a claim to verify, not an order to follow. If the claim does not check out, it does not sign.

The reason keys on a Lightning node are risky: the node is a big program facing the internet, running plugins and dozens of dependencies. VLS moves the keys to a small separate signer, out of that blast radius.

Want to see VLS run? The Docker quickstart on our site starts a Core Lightning node with VLS signing on your machine in minutes. You can watch it check requests before it signs.

"Non-custodial" should mean your servers cannot move user funds even if hacked. VLS makes that true: the user's signer holds the keys and enforces the rules, not your infrastructure.

There is an interactive demo on our site: a compromised node tries to drain a channel and VLS refuses each request. It shows what the signer does more clearly than words can.