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?

The VLS signer is deliberately narrow: it holds keys, tracks state, checks policy, signs. It does not route, gossip, or run plugins. Less code near the keys means fewer ways in.

VLS tracks each channel's commitment state, so it can tell a current, valid request from a replay of an old one. That difference is invisible to a signer without its own state, and it is where funds get stolen.

Keys on the node means the node can sign anything. That is fine at small balances. Once the channel is worth stealing, it becomes the whole risk. VLS is for the point where that risk gets real.

VLS is grant-funded and open source. No license fee, no locked features, no vendor deciding who gets good security. You can use it, read it, run it, and fork it.

You can set VLS limits as tight or loose as you need: small per-payment caps and a strict close allowlist for a treasury, looser rules for a busy routing node. The rules are yours to write.

The node proposes, the signer decides. That is the VLS model. Every Lightning signature starts as a request the signer can refuse, and there is no path around it to sign directly.

VLS separates two jobs that usually sit in one program: running the Lightning node, and deciding what to sign. Splitting them means a bug in the first cannot directly spend your funds.

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.