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 holds keys, tracks channel state, and evaluates policy. It does not route, gossip, run plugins, or accept peer connections. Everything it does not do is attack surface it does not have.

A Lightning channel is a running agreement, not a static balance. Old states get revoked, new ones replace them. VLS keeps its own record of that history and refuses to sign anything that contradicts it.

Lightning signing happens fast and often. Routing, channel updates, closes. A validating signer that checks each request without slowing the protocol down is the design VLS targets.

Per-payment amount limits in VLS bound the size of a single HTLC the signer will approve. A compromised node cannot exceed the cap by request, regardless of what the protocol would otherwise allow.

Lightning balances large enough to matter for a payment network are larger than anyone wants to keep on a hot wallet. Moving keys off the node and enforcing policy independently is how balances become reasonable to hold at scale.

Lightning is stateful. Same key, same channel, different commitment number, different valid signature. A signer without its own state cannot tell the difference between a current state and a revoked one. VLS tracks state for this reason.

If Lightning is going to serve a large number of users, it needs merchants. Merchants need channel balances they are comfortable with. That comfort depends on the security of the setup. It is one of the key pieces that needs to be in place.

VLS treats node requests as untrusted input. The signer decides whether the request is allowed and produces a signature only if the answer is yes.

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.

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.

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.

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.

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.

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.

Greenlight runs Lightning nodes as a hosted service while users keep signing authority through VLS. Hosted convenience, user-side signing decisions, working in production.

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.

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.

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.

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."

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.