Validating Lightning Signer

Non-custodial Lightning security for serious balances.

Off-node keys + full validation = a compromised node can’t steal funds

Open source Rust SDK.

[Validating Lightning Signer @VLSProject]

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

[Validating Lightning Signer @VLSProject]

For an LSP running nodes on behalf of users, VLS means your infrastructure never holds the power to spend user funds.

The user's signer does.

That is a cleaner story for users and regulators alike.

[Gideon Bature @0xGideonBature]

Do not trust, verify!

[Validating Lightning Signer @VLSProject]

VLS was built on the assumption that the node can be compromised.

So it checks every request as if the node might be lying.

That assumption is what makes it useful the day something goes wrong.

[Validating Lightning Signer @VLSProject]

VLS is one signer with a rule set you control.

Adjusting a limit or adding an approved close address is a config change, not new code.

The rules that guard your funds stay easy to read.

[Validating Lightning Signer @VLSProject]

You do not have to run a full Lightning node to use VLS.

A hosted node handles connectivity while your VLS signer, even on cheap hardware, holds the keys and the veto.

Real custody, less to run.

[Validating Lightning Signer @VLSProject]

Two records of the same channel: the node's and the signer's.

VLS trusts its own.

If a hacked node reports a different reality to get a signature, the mismatch is caught and the request fails.

[Validating Lightning Signer @VLSProject]

A Lightning node has to be online and reachable to route payments.

That is exactly why keys on it are exposed.

VLS keeps the keys on a separate signer that does not carry the node's exposure.

[Validating Lightning Signer @VLSProject]

A plugin extends what a Lightning node can do, which means a malicious one extends what an attacker can do.

With keys on a separate VLS signer, a rogue plugin on the node still cannot produce a signature that breaks your rules and steals your funds.

[Validating Lightning Signer @VLSProject]

ALWAYS assume your internal network is compromised.

Then build your security around that assumption.

If there's any takeaway from the past few weeks, it should be that. And it will likely only get worse before it gets better.

[Validating Lightning Signer @VLSProject]

VLS turns a node compromise from "aaaand it's gone, it's all gone" into "no can do, attacker."

That change comes from one decision: keys and policy live on a separate signer, and the node cannot sign without it.

[Validating Lightning Signer @VLSProject]

Every dependency your Lightning node pulls in is code that could be compromised in an update.

With VLS, the keys sit on a separate signer, out of reach of the node's entire dependency tree.

[Validating Lightning Signer @VLSProject]

For a Lightning product, the custody question decides your legal requirements.

VLS lets you keep users in control of their own keys, which keeps you out of custody and the compliance that follows.

[Validating Lightning Signer @VLSProject]

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.

[Validating Lightning Signer @VLSProject]

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.

[Validating Lightning Signer @VLSProject]

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.

[Validating Lightning Signer @VLSProject]

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.

[Validating Lightning Signer @VLSProject]

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.

[Validating Lightning Signer @VLSProject]

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.

[Validating Lightning Signer @VLSProject]

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.

[Validating Lightning Signer @VLSProject]

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.