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.

Full control of the node host: root access, any command, and the ability to send the signer whatever requests they want. With VLS, the keys live on a separate signer, which checks each request against its policy and operator's limits and refuses anything that breaks it.

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.