We’re the team behind Validating Lightning Signer (VLS), an open-source project that separates Lightning node keys from the node itself.
VLS independently validates signing requests before approving them, reducing the risk that a compromised or buggy Lightning node can steal funds.
It supports Core Lightning and LDK, and is used in production by Blockstream Greenlight.
Ask us anything about VLS, Lightning security, remote or hardware signers, CLN/LDK integration, threat models, the project’s roadmap, or anything else you want to know about us.
Why no support for LND?
VLS was originally developed for CLN (and primarily uses the internal interface of CLN to its signing component) so that remains the primary supported implementation. The CLN interface, although internal, goes through OS pipes to a separate signer process, and that was the easiest implementation to replace its signer at the time the project was started.
When LDK started exposing a formal documented signing interface, we also implemented that interface. It is in some ways drastically different from the CLN interface, so our support for LDK isn't quite as good as that for CLN yet (we do must of our testing against CLN). CLN has also started coordinating with us for some years already to somewhat improve their internal interface into something that actually works out better for a separated, higher-security signer with spending policies. For example, before, you would have to manually replace the CLN binary for its signer with our binary, but now, CLN has a command-line argument to do tell it to use a different signer binary for the signer process. LDK I believe still has some internal gaps where it expects to have the signing key in its process rather than calling into the formal published interface, especially for onchain funds (though don't hold me to that since I think LDK is actively fixing that).
LND still uses internal function calls to its signer (unlike CLN which does OS pipes into a separate process which is a lot easier to hack into without modifying CLN itself) that are undocumented (unlike LDK which has a formal documented signing intrface). I believe similar situation also with Eclair.
@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.
I doubt they would listen to me plus isn’t LND FOSS?
What concrete attack or failure scenario does VLS prevent that isn't already covered by a well-configured node with keys in hardware?
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.
So, if I understand it right, VLS is like a notary that reads the contract before signing it. Where do those rules come from?
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.
Thanks for the explanation. If the policy is what decides, I imagine it lives in the signer. How do you make sure the node can't touch it?
the policy setup is on the VLS machine itself as part of the VLS configuration, and there is also a VLS command interface that lets you tweak some policies (like e.g. adding addresses to the allowed-to-be-sent-to list). Assuming your VLS machine is not compromised (it can be hardened, e.g. by firewalls that disallow all incoming connections since VLS itself makes an OUTgoing connection to the node) then the node cannot change the VLS policy.
Now, in theory, the VLS software can be compromised by some protocol shenanigans with the node software itself (e.g. some parsing error in the node<->VLS protocol might lead to a buffer overrun?), but now you are compromising both the node software and VLS, which is something of a failure mode we really cannot protect against; our security argument is that compromising the node software (which generally needs to be allowed to accept incoming BOLT8 connections, and has to handle stuff like gossip maps and routing) is a lot easier than compromising the VLS machine (which as noted can be hardened by disallowing all incoming connections)
Knowing there's a design where the node can be fully compromised and still only get to ask "will you sign this?" is a good reason to sleep better as a bitcoiner.
Thanks for the AMA, for the answers, and above all, for building ⚡🔨
You're welcome. You can always choose how you deploy the software. For instance, even if you are constrained and can only use a single device for both the node software and VLS, you can also use any Unixlike OS and have separate users for the node software and VLS. Then even if the attacker can shellcode your node software, it still cannot access the VLS userspace, as it is a different user. Of course, if the node software is rootkitted, it can now access everything, which is why we still recommend separate devices, but it is still a (smaller) security improvement to have VLS on the same machine but under a separate user.
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.
Big thanks
In addition to what @jackronaldi said, for the policy side, VLS ships with defaults, and the signer enforces whatever limits you set, so tightening them for your use case.
deleted by author
Just to emphasize, we recommend keeping the signer on a separate device from the Lightning node. Running both the node and signer on same device removes much of the benefit, since compromising the device could expose the signing key.
Agreed! I would go further and suggest that the signer machine should be domiciled in your home/office/citadel/bunker/spacestation. In general, securing your own devices physically is something ordinary human beings can reason about more easily, than securing things in a remote server (even if you already trust the remote rack operator).
Regardless, even separating it out into an AWS Nitro enclave while running the node software in the hosting ECS instance would still improve your security in practice, as it at least makes it somewhat harder to exfiltrate your keys for anyone not named "Amazon".
The thing you have to balance here is that obviously if you are running the signer in your home Internet connection then the latency from your home Internet connection to the node machine is added on to every signing event. That is why we also have alternate deployments like running on an STM32 that is connected to the USB port of the node machine, which reduces that latency, and the new proof-of-concept work done by Vatsal to run it in AWS Nitro.
Node software is compromised, asks the hardware to sign a transaction that sends all funds to the peer. Since the node software always has to directly have a TCP connection with the peer, it is PRECISELY the peer that is in the best position to attack your node software.
How much validation is the hardware doing? If the hardware "signs blindly" (i.e. as of 2026-September, not running VLS, as it is the only signer implementation that actually validates) then it will accept ANY transaction the node software presents it.
In short, it protects not only against your outer service (the one that sends commands to the node software) being compromised, it also protects against your actual node software from being compromised.
What improvements to VLS are you excited about releasing in the next year?
Splicing support!
🙌
Yup splicing support indeed.
Splicing indeed 🙌💯
Thanks for doing this. I'm working on some lightning adoption projects. Particularly focused on small businesses.
Do you have any real or hypothetical use cases for VLS in the meat space? What problems does it solve or could it solve for real world lightning users with moderate technical competence?
Also, is VLS suitable for a ESP32 keyring-style form factor (maybe based on m5stack.com or waveshare.com)?
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.
Well, if the user is, say, running a RaspPi with a CLN node + bitcoind, it would be possible to buy an STM32 device and run VLS on it (though I don't know if that fits with "moderate" technical competence, heh), and connect it to your RaspPi via the USB port. We have a proof-of-concept code for this, though there are pretty big gaps, but at least it would isolate the key away from the RaspPi itself.
deleted by author
What's the most surprising thing you've all learned in the last few years developing VLS?
For me, the surprising thing was that we had to implement almost everything just to have validation. To check a signing request, the signer has to understand channel state, commitments, HTLCs, and the chain, which means reimplementing much of what a Lightning node does.
Is VLS something you see mostly being used by routing nodes and professional node runners or is it something that you think everyone running a node will likely use?
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.
Agreed. Much like my other old project CLBOSS, however, any deployment that includes VLS with CLN can only be improved compared to just CLN out-of-the-box.
Even if you end up just running VLS on the same machine as the node software (very much NOT our recommended setup), if you do something like run them as separate users and restricting the VLS user and completely disabling its password (which you should also do to CLN BTW if you can arrange it), you can still get a little more security simply from the additional isolation.
Running it on a separate device makes a lot sense to me.
Other than Greenlight, can you share if other LSPs are using VLS?
At the moment, no. But we are in working with some folks. Once anything materializes, we will announce.
I do know of maybe two or three large Lightning operators / services who are interested in possibly integrating VLS, but I do not know if they would be willing to let me share their names :P you would just have to trust me that we do have a few potential users asking about us.
Greenlight is somewhat unique in that their service inherently depends on VLS being actually a thing (they want you to run a VLS on your hardware, while they run the CLN node on their server rack).
This pretty makes sense. They are giving the user the power of self custody of their keys while taking care of the technicality and running of the node.
Congrats on the beta release!
I learned about VLS on here last night. I wasn't aware of the project. Love that it's in Rust. Seems to solve some real operational problems.
I just saw from the docs that VLS uses FROST. Any plans to integeate NOIST for async multiparty signing?
Currently, VLS does not use any multi-signer protocol like FROST. In the future we MIGHT. It really depends on what we end up going with to consider for k-of-n. Overall, the Real Problem is not in fact signing --- signing is the easy part, and if NOIST is better, that is fine too (By my understanding FROST requires simultaneously-online setup for all N signers). But the hard part is REVOKING. See here for more: https://delvingbitcoin.org/t/towards-a-k-of-n-lightning-network-node/2395
We are actually shipping our v1.0 mainnet readiness release Soon™️
I was reading your post on recent lightning attacks and whether VLS could have mitigated (or stopped them altogether). But I'm not quite sure I've wrapped my head around the different situations.
Do you have a brief way of explaining the difference between circumstances where VLS helps and where it isn't as effective?
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.
As a concrete example: You can configure a policy that will make VLS limit the amount of satoshis that can be sent per unit of time (i.e. the "velocity" of sent payments).
Then if you are integrating the node software in a larger service that has to send out money for any reason, if THAT service is compromised and starts trying to send out as much of your funds as possible, then the VLS policy triggers and stops outgoing transfers beyond the velocity limit you sent. This can at least prevent some losses.
Similarly, if your larger service is compromised and the node happens to have onchain funds, you can set policies that limit what onchain addreses can be sent to, so that the even if the larger service that uses the LN node is compromised, VLS can at least prevent some of the theft attempts.
As for something VLS CANNOT protect you from: you probably want to run some kind of node manager that automatically reopens channels that get closed. If THAT manager is compromised so that it always points your liquidity at specific nodes (and thus distorting the Lightning Network fee market in favor of those nodes) VLS cannot really detect and protect against that. Similarly, if you have policies that would prevent you from interacting with certain nodes, operators, or IP ranges, VLS cannot really prevent your node from connecting out to those, it is ONLY a signer.
I'm not the most knowledgeable with Lightning, so forgive me if this is an ignorant question, but if I'm running a routing node, is there way that my VLS polices get included in gossip? How will other nodes know that they can't send the full amount of liquidity on my node?
I think there is no way to do that in the gossip map, unfortunately.
We probably should implement a velocity setting for arbitrary outgoing payments that is separate from forwarding, however, since it is the arbitrary outgoing payments that is the theft risk: we should generally be willing to forward any amount out as long as we get more in an incoming HTLC.
Other than your work on VLS, what do you think the Lightning ecosystem most needs?
Me personally (not speaking for the team): Forwardable Peerswaps.
Hey guys! Thanks for doing this.
How much extra effort is involved in using VLS with a lightning node as opposed to normal lightning node management?
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.
I should also probably shill my old project CLBOSS, which is really useful to make any CLN deployment a practically-hands-off thing, just load it up with sats onchain and let CLBOSS rip. ksedgwic, who used to be a VLS contributor, is the current CLBOSS maintainer (LOL we basically swapped projects).
I did not know about CLBOSS, very cool!
https://github.com/ksedgwic/clboss
Largely you probably want to use CLN. We have some instructions on how to deploy with CLN: https://vls.tech/docs/latest/get-started/cln-vls/ . We have the theoretical ability to connect to an LDK-based node, but we cannot connect with the "official server version"
ldk-nodeproject yet. We have a separate LDK-based project,lnrod, whose instructions for integration are: https://vls.tech/docs/latest/get-started/ldk-vls/ , and you can also dive deeper into the actual codebase if you are writing your own LDK-based node software for how to integrate it.I suggest running at least one extra machine: a very secure machine, ideally domiciled by you and not hosted on cloud or remote rack, that will run VLS. I would suggest locking all incoming ports in the firewall for this machine (VLS actually "connects out" to the node, instead of being a server and waiting for the node to connect in) and disabling everything, including SSH on the machine (i.e. use the machine's console directly). The "connect out" gives a tiny security boost, in that you can actually lock out many possible attackers by simply completely disallowing incoming connections and only allowing outgoing to the very specific node software machine.
In addition to VLS itself, you need TXOO server, which you can probably run with the machine that runs bitcoind. CLN needs a bitcoind as well anyway.
As to overhead, additional network roundtrips will occur due to the node software having to call out to the VLS machine. How much impact this has will depend on your setup between the VLS machine and the node software.
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
Do you have a favorite mobile lightning wallet?
As a project, no.
As an individual, right now I personally like Phoenix wallet for small balances.
I'd never heard of it. Is that hardware/software or both?
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.
5 years from now, do you think most consumers will only touch the chain for channel open and close and otherwise be using lightning?
From experience in Africa I have not come across consumers using the base chain. so if this trend as MoE continues. then YES.
Me personally (not speaking for the team): Yes.
Do you see a world where VLS is offered as a third-party service?
ie. I run a routing node, I want to up my security. Someone offers a service where they spin up and run my VLS in a TEE or something like Enclavia and I just specify the policies?
My recommendation is that you should run VLS on hardware you have domiciled in your home/office/bunker/citadel. So actually the reverse: someone else runs your node software, YOU run VLS on your own hardware. I believe this is what Greenlight intends to provide as a service.
The important part is "not your keys not your coins" IMO. Having someone else run the VLS means the one holding the keys --- the signer --- is someone else, not you.
I see! I was thinking about it backwards. This helps a lot.
GM from Lagos! New stacker here. Just connected my Blink wallet. Stacking 1000 naira daily. Happy to be here and learn. Any tips for a beginner from Nigeria?
Interesting post...thanks for sharing...great job
[AI-assisted comment, verified before posting] One angle not covered yet: how does VLS policy enforcement behave across signer state loss/restore, and does that interact differently on unannounced/private channels?
Concretely: an external signer like VLS presumably persists per-channel commitment/revocation state so it refuses to co-sign a commitment number lower than the last one it already approved. This guards against the classic "time travel" risk for any signer-node split, where a node restored from an old backup could otherwise trick a naive signer into re-approving a stale, since-revoked state that is now worth broadcasting.
Two questions:
Watchtowers cover a counterparty broadcasting an old state; this is about the signer itself being fooled into re-approving one after a bad restore, which seems like a related but distinct failure mode worth documenting if it is not already.