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

A VLS rule you can set: velocity limits. VLS caps how much value can leave a channel in a given window. A node trying to drain funds through many small payments hits the cap and stops.

On most Lightning setups the node holds the keys and can sign anything. VLS moves the keys to a separate signer that checks each request first, so a compromised node can no longer sign whatever it wants.

A VLS rule you can set: a cap on how much a single payment can move. A compromised node cannot push one large payment out, because the signer rejects anything over the limit.

VLS is a separate signer for your Lightning node. The node asks it to sign. VLS signs only if the request matches valid channel state and the limits you set. That is the whole job.

A VLS rule you can set: channel closes may only pay out to addresses you approved ahead of time. A hacked node trying to close your channels to its own address gets refused.

VLS checks two things before it signs: is this a valid Lightning state transition, and does it obey the operator's rules? A request has to pass both. Fail either one and there is no signature.

A node running VLS still routes payments, opens channels, and talks to peers. The one thing it can no longer do is sign a transaction by itself. Signing now requires passing VLS's checks.

VLS remembers what your channels look like. When the node asks for a signature that contradicts that memory, VLS refuses and no signature is produced.

VLS keeps your Lightning keys off the node. The node proposes a transaction, VLS checks it against the channel's real state and your rules, then signs only if it passes. A hacked node cannot skip the check.

A tweet cannot hold a threat model. The site can. If anything we post here sounds too neat, the long version, with the caveats included, is one click away in the profile.

VLS runs on a $10 ESP32 with the same validation logic as a server deployment. If that sounds implausible for a Lightning signer, the code that does it is public.

Lightning funds have been lost to race conditions, fee gaps, and stale state. None of those attacks broke cryptography. Understanding why is the best reason to spend twenty minutes on our site.

A signing request arrives. The signer loads its own view of the channel, checks the request against protocol rules and policy, and only then signs. That whole pipeline exists as readable code you can step through. The repo is in our profile.

The policy checks in VLS read like a history of how Lightning funds get lost, written as prevention. Revoked states, bad closes, fee abuse, runaway velocity. Each check exists because the failure it blocks is real. The list is public.

Rust, Apache-2.0, no_std support, CLN and LDK integrations, published audit. If you are evaluating VLS for a build, everything you need for the first pass is public. No sales call required.

There is one production deployment of VLS you can read about in detail: Blockstream's Greenlight. The case study on our site covers how hosted nodes and user-held signing authority fit together.

VLS is developed in the open. Design discussions, issues, merge requests, release notes, all public on GitLab. If you want to know where a project is really at, its issue tracker tells you more than its homepage.

Security fixes in VLS land in public. Every team using it can see what changed and why. With a proprietary signing stack, you learn about problems when the vendor decides to tell you.