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]

Routing payments through high-fee adversarial nodes has been used to drain Lightning channels.

VLS checks fees against policy and refuses signatures on outgoing HTLCs that exceed the configured ceiling.

[Validating Lightning Signer @VLSProject]

Self-custody on Bitcoin L1 is the user holding the key and approving each transaction.

The equivalent on Lightning is the user controlling a signer that enforces policy on each request.

VLS provides the signer piece.

[Validating Lightning Signer @VLSProject]

Channel state.
Chain context.
Revocation history.

All are required to know whether a signing request is consistent with what has been signed before.

VLS keeps them and uses them.

[Validating Lightning Signer @VLSProject]

Boring is the goal for signer architecture.

Small codebase, narrow API, no gossip, no plugins, no peer traffic.

The Lightning node can be exciting.

The signer should be predictable.

[Validating Lightning Signer @VLSProject]

Open source security infrastructure does not depend on a single team's continued participation.

The signer code is on GitLab, the license is Apache-2.0, and anything found by one team can be fixed for all.

[Validating Lightning Signer @VLSProject]

Lightning incident postmortems often end with the same observation.

The compromise itself was routine.

The blast radius was the problem.

Architecture that limits blast radius is the missing piece in most setups.

[Validating Lightning Signer @VLSProject]

Greenlight runs Lightning nodes as a hosted service while users keep signing authority through VLS.

Hosted convenience, user-side signing decisions, working in production.

[Validating Lightning Signer @VLSProject]

Security shapes what you can build on top of it.

With weak security, you cap your channel sizes, limit your customer base, and stay cautious.

With strong security, those limits move.

That is why it is worth the investment early.

[Validating Lightning Signer @VLSProject]

After a breach, the sats are just the beginning.

You shut down operations to investigate.
You notify users who trusted you.
Potential partners pull back.
Rebuilding that trust takes months.

It is always worse than the number on the screen.

[Validating Lightning Signer @VLSProject]

When someone at a company asks "should we put real money on Lightning?"

the conversation goes better if you can point to an independent signer with explicit policies,

not just a hot node you hope does not get hacked.

[Validating Lightning Signer @VLSProject]

A validating signer makes a node compromise survivable.

Funds can still be at risk depending on the operator's policy, but the default outcome is no longer "it's all gone."

[Validating Lightning Signer @VLSProject]

A useful test for any Lightning deployment:

name the smallest component an attacker would need to own to move funds.

With keys on the node, the answer is the node and everything attached to it.

[Validating Lightning Signer @VLSProject]

VLS velocity limits cap how much value can move through a channel in a given window.

A compromised node trying to drain a channel through routine payment flows hits the ceiling and stops.

[Validating Lightning Signer @VLSProject]

We classified ~40 Lightning wallets and LSPs by security level.

Only two products currently use a validating signer.

The rest are hot wallets.

The data is public: https://t.co/iyVNuoBgFE

[Validating Lightning Signer @VLSProject]

VLS handles signing decisions.

Peer connections, routing, gossip, backups, monitoring, and the operational side of running a Lightning node still live on the node.

The split is the point.

[Validating Lightning Signer @VLSProject]

Refusing to sign a revoked commitment is not a heuristic in VLS.

It is enforced.

The signer tracks revocation state and will not produce a signature on a state it has already revoked.

[Validating Lightning Signer @VLSProject]

VLS is written in Rust and supports no_std targets.

The same signer code runs on a server, in a container, behind gRPC, over a serial line, on an ESP32, or inside an enclave.

[Validating Lightning Signer @VLSProject]

A useful question for any Lightning wallet or LSP:

What happens to funds if the node holding the keys is compromised?

If the honest answer is they can be stolen, the product is a hot wallet, regardless of how it is labeled.

[Validating Lightning Signer @VLSProject]

Theft-capable Lightning vulnerabilities have shipped without breaking cryptography.

The node produced signatures the protocol allowed but the user did not intend.

A separate signer with its own state fixes this.

[Validating Lightning Signer @VLSProject]

Fee bounds in VLS are part of policy.

If an HTLC or close transaction would pay fees above the configured ceiling, the signer refuses.