pull down to refresh
Exactly. The policy lives on the signer side, and the whole point is to make the signer a separate trust boundary from the node.
The node should only be able to send signing requests over a narrow interface. It shouldn’t have access to the signer’s filesystem, memory, keys, or policy configuration.
How strong that separation is depends on the deployment. If the signer runs on the same machine, isolation is weaker. If it runs on a separate device, HSM, secure enclave, Nitro Enclave, etc., the node can be fully compromised and still only get to ask, “will you sign this?” We recommend the signer running on a separate device.
Policy changes can also be made to require direct or separately authenticated access to the signer, rather than letting the node rewrite its own rules.
A small business is actually a pretty good VLS use case.
Imagine a café or shop accepting Lightning all day. The Lightning node has to stay online and exposed to the network, and it might even be hosted for them by an LSP. With VLS, the keys and the authority to spend can live separately on a device the merchant controls. The node can do the day-to-day Lightning work without automatically having unrestricted access to the money. VLS was explicitly designed for setups ranging from a merchant using a small consumer device to an LSP-hosted node where the user retains the keys.
You can then layer policies on top: where money may be sent, fee limits, approvals, etc. For a merchant, you can imagine going even further: the always-online system can receive payments, while sending requires approval or a more protected signer to come online.
The goal for someone with moderate technical competence shouldn't be “learn how to operate VLS.” Ideally their wallet/POS/LSP integrates it, and they just choose the security policy they want.
That's a pretty good analogy. The important part is that the notary has its own copy of the rules and its own record of what has happened, rather than trusting the person handing it the contract.
The rules come from two places. First are Lightning protocol safety rules encoded in VLS: things like not signing revoked channel states or invalid HTLC/commitment transitions. VLS independently tracks enough channel state to enforce those rather than asking the node whether something is safe.
Second are policies chosen by the user or the wallet/service integrating VLS: things like approved destinations, fee limits, spending controls, or requiring additional approval.
So the node basically says, “please sign this,” and VLS asks both: is this valid Lightning, and is it allowed under this user's policy? Only then does it sign.
The key distinction is that hardware protects the key, while VLS also protects what the key is allowed to sign.
VLS also moves that security-critical logic off the Lightning node. A node has a large attack surface: it connects to peers, processes gossip and payments, manages channels, talks to Bitcoin, exposes APIs, may run plugins, and has many dependencies. A VLS signer does much less: track the state it needs, validate requests against Lightning rules and your policies, and sign.
That smaller component can run on a separate, hardened device or environment such as an HSM, secure enclave, microcontroller, or Nitro Enclave, with a much narrower connection to the node, including USB/serial or vsock.
VLS can also use tag-team signing: an always-on signer with restrictive policies can keep the node receiving/routing, while a more protected signer is only connected when you want to send.
So if a hardware signer already independently tracks Lightning state and validates every request, it’s moving toward the same model. But with a signer on the same device as the node, that device is still a single point of failure: compromise it deeply enough to extract or misuse the signing key, and the funds are at risk or already gone.
Longer term, VLS is designed to support multisig/threshold Lightning signing, so no single signer holds enough authority to move funds on its own. Compromising one device would therefore not be enough to steal them.
At the moment, no. But we are in working with some folks. Once anything materializes, we will announce.
A useful way to think about it is: if stealing the funds requires the node to obtain a signature it shouldn't get, VLS can potentially stop it. If the loss happens despite the signatures being valid, VLS usually can't.
So VLS is strong against compromised nodes, wallet/API bugs, excessive fees, repeated or unauthorized payments, and Lightning state transitions that violate its policies, because the signer can independently refuse them.
It's less effective against things like DoS, confirmation/mempool attacks, or bugs in how the node constructs and broadcasts an otherwise valid on-chain claim. In those cases there may be no bad signature for VLS to reject, although independent monitoring can sometimes provide an alert.
That's also what we found when we looked at 17 real Lightning incidents and disclosed vulnerabilities: some could have been directly prevented by signer-side policy, some could have had their damage limited, while others were outside the signer's control entirely.
Our hope is that it becomes a standard that everyone running a node will use, so that everyone can benefit from the increased security.
But, in terms of a path to wider adoption, we do think it would start with LSPs, professional node runners and routing nodes, really anyone with a lot of sats to protect.
For smaller balances, until the wallets make the UX seamless, I could see how people won't bother. Much like how many people do not take self-custody of their L1 bitcoin today.
Like ZmnSCPxj mentioned, there is some additional overhead compared with running a normal Lightning node, but how much depends a lot on the integration.
If VLS is integrated into a wallet or managed Lightning service, most of that complexity can be handled by the wallet/service. If you self-host, you also need to deploy and maintain the signer infrastructure yourself.
Beyond that, the operational overhead depends on how you want to use VLS and how much you automate. For example, you can automate policies, approvals and alerts, and choose between an always-on signer or setups where an always-on signer can receive while a more protected signing device only comes online when you want to send.
So VLS does add another layer to operate, but there’s a pretty wide spectrum between a highly automated integration that users barely notice and a more hands-on, security-focused self-hosted setup.
Do you have a favorite among the Ark, cashu, Spark, fedimint things?
We dont have a view on other layer 2 solutions, we are focusing on lightning security
I guess we need to do a better job of marketing VLS.🤠
It's free and open source software. It's an SDK that Lightning wallets can integrate into their product.
Ah ok. I will update Blocktank as well then.
And yeah, it seems blind signing is not being used anywhere. So the focus should be on the improved security VLS can bring, to your point. Seems I have more work to do to change our positioning back to security.
Appreciate your feedback!
As I understand it, the node handles most of the complex, high-risk stuff: gossip, routing, channel management, networking. The signer just validates and signs. By moving that logic onto a separate, hardened device, you can cut down the attack surface compared to everything running inside one node process.
You can also split signing roles: one signer that’s always on for receiving, and another that only turns on when you want to send or close channels. That isn’t possible with a monolithic node.
Thanks for the feedback Justin. That was my bad, I did not research these well enough. I've updated Voltage, Lightspark and WoS to correctly categorize them and will ship with the next round of updates in the next day or two.
For Synonym, AFAICT, while Bitkit is a mobile LND hot wallet, the Blocktank LSP seems to be a blind signer. From their website : "Instant Bitcoin transactions require a Lightning connection. Blocktank provides you with a self-custodial, stable, and seamless experience, while eliminating the complexity of managing a node."
Unless I'm missing something.
@BlokchainB If you'd like to see LND support in VLS, please let the LND team know so they can make the necessary changes on their end to allow VLS to integrate with it.