Lightning Wallet Security Spectrum

Author: Jack Ronaldi

Source: https://vls.tech/posts/lightning-security-spectrum/

To make a long story short

"Non-custodial" cannot be used to describe the security mode of a Lightning wallet. Because signing requires an internet connection, the real question is: what happens if the connected node is compromised ? Most Lightning wallets are connected wallets (hot wallets). If it's just for spending money, there's no problem, but the risk increases rapidly with the amount of funds. Level 3 (Enhanced Environment) can reduce the probability of being compromised. Level 4 (VLS) limits the blast radius by enforcing certain spending rules outside the node, so even if the node is compromised, funds cannot be stolen. If you are a developer, node operator, or server holding a large amount of Lightning Channel funds, the difference is significant.

(Translator's note: The author's idea is to divide a fully functional Lightning node into two modules: one is a "node" responsible for networking, communication, and managing Lightning channels, and the other is a "signer" responsible for signing when the channel state transitions (receiving or paying); these two modules may be merged or isolated in different Lightning wallet implementations.)

A Glimpse into the Safety Spectrum

• Level 1: No signature verification . Meaningless, don't develop it.
• Tier 1: Fully managed hot wallet . The service provider holds your keys.
• Level 2: Non-custodial hot wallet . You own the key; it's simply stored with the network device provider.
• Tier 3: Enhanced nodes . Utilizes secure enclaves and Hardware Signature Modules (HSMs) for stronger isolation.
• Level 4: Validated Lightning Channel Signer (VLS) . An isolated signer that enforces spending terms.
• Level 5: VLS + Threshold Signature (Future)

A useful distinction

• Level 3 : Makes nodes harder to breach.
• Level 4 : Makes node breaches less dangerous (nodes cannot steal funds by using actions not permitted by the spending terms).

Ask the developer or service provider of your wallet.

• If a node is compromised, can it obtain a signature to steal funds?
• Is the signing of expenditure terms performed outside of the node, by a separate module?
• In the worst-case scenario, how great would the losses be? What could stop the blood loss?
• Check the current status of your wallet.

If the signature generator itself is compromised, then no measures will be effective. Therefore, our goal is to make it even more difficult to compromise than the node itself.

Lightning Network's promises and problems

You carefully researched and chose a "non-custodial" Lightning wallet because you firmly believe that "no private key, no coin." You carefully safeguard your seed key, while you retain control of the private key.

One morning, you wake up to find your Lightning Channel closed, and your satoshis sent to an address you don't recognize. The software logs show your node allowed all operations. Just like that, your Bitcoin has vanished. Your Lightning wallet has removed your chair.

The Lightning Network promised to maintain Bitcoin's security and self-custody principles for instant payments. However, something seems to have gone wrong.

"Unmanaged" is not a security model.

At the Bitcoin base layer, "non-custodial" is clearly paired with security: private keys reside on off-grid devices (cold storage) and are only signed when you choose to. Lightning wallets change this constraint. Payments, Hash Time Locked Contracts (HTLCs), and channel updates all have response time limits, so the signing key must be connected to the internet—either on your phone, with a service provider, or somewhere in between. In a Lightning wallet, "I hold the private key" does not inherently mean "my funds are safe."

• "Non-custodial" is still necessary, of course . It means that the service provider cannot arbitrarily transfer your funds.
• But simply being "unmanaged" isn't enough . Because signing occurs online, you need a disaster recovery mode. Suppose an attacker gains control of your Lightning node, what can prevent them from obtaining your signature and stealing your funds?

(Translator's note: The reason why attackers can steal funds without stealing private keys or controlling nodes is that the state changes of a Lightning Channel itself require a signature, i.e., node application and signatureer authorization; if the signatureer does not verify the content of the application, then naturally, simply controlling the node is enough to transfer all the victim's funds in the channel.)

The important thing is:

If your Lightning node is hijacked, what can the attacker do next?

Let's first take a look at the common lightning wallets.

Lightning Wallet Security Spectrum

This spectrum was derived from a simple test: how difficult is it for an attacker to steal a victim's funds ?

When we move across the spectrum, we sacrifice simplicity in exchange for smaller attack nodes and stronger disaster recovery capabilities.

No verified signature (bad mode)

What it is like : The signer is separate from the node, but it will authorize any request sent by the node without independently verifying the security of the request.

What happens when a node is hijacked : Once a node (or any module that can affect it) is compromised, it can trick the signer into authorizing harmful actions.

Why it's bad : It's more complex and less secure than a standard hot wallet because you now have two attack interfaces (node and signer) instead of just one.

Example : This is not how mainstream products work today. Developers should be aware: do not develop products like this .

Hosted hot wallet

What it is like : The service provider controls the key and runs the Lightning node on your behalf.

What happens when a node is hijacked : Supplier misconduct or insider activity can allow them to transfer your funds.

Trade-offs : Best user experience, least user responsibility, highest level of trust and business responsibility.

Best suited for : small amounts and beginners.

Case studies : Cash App , Strike , River

Non-custodial hot wallets

It works like this : You hold the key yourself, but it's stored in the networked environment (device) that runs your Lightning node (wallet).

What happens if a node is hijacked : If a node is hijacked, funds may be stolen.

Trade-offs : Autonomy, but security heavily depends on how secure your node's operating environment is.

Best suited for : everyday expenses.

Case studies : Phoenix (ACINQ) , ZEUS , Voltage

On-premises vs. cloud : Non-custodial wallets can run on a user's own device (on-premises) or on servers run by a team (cloud). The cloud is not necessarily more secure or more dangerous. It can reduce user error and professional teams can improve operational efficiency, but it often increases the interface for remote attacks and concentrates the risk on access to the infrastructure.

Enhanced node environment (secure enclave/HSM)

What it looks like : standard Lightning Node mode, but running in a hardened environment (secure enclave, HSM, attestation-driven secret distribution).

What it strengthens is that it makes it difficult for "server hijacking" and "administrator privileges" to be converted into key extraction, by isolating sensitive memory and strengthening key management.

What happens when a node is hijacked : If an attacker successfully executes malicious logic on a node (such as by exploiting a software vulnerability or hijacking a software update source), the node will be authorized for theft. Hardening measures can reduce the likelihood of hijacking, but do not limit the scope of brute-force attacks.

Trade-offs : Generally speaking, hardening measures are very costly, requiring specialized infrastructure, toolchains, and operational procedures (authentication, private key injection, controlled software deployment). Even top global operators say it has taken many years to achieve an acceptable situation.

Best suited for : large-scale operators who (a) cannot change their infrastructure in the short term; and (b) have a dedicated security and operations budget. This is a reasonable “starting point” for a typical hot wallet, but it’s not the end game if you want very strong guarantees.

Case Study : LEXE (Intel SGX) , ACINQ: Securing a ~$100M Lightning node (Nitro Enclaves) ( Chinese Translation )

VLS (Lightning Channel Signer with Validation)

What it is like : An isolated signer that verifies the request and enforces the spending terms before signing.

What it enhances : It changes the failure mode: even if a node is hijacked, it cannot steal funds through operations that are not permitted by the spending terms.

What happens if a node is hijacked : Hijacking a node has no significant impact. The signer is the critical security boundary.

Trade-off : Pre-integration of software and ongoing maintenance are required in exchange for stronger security guarantees.

Best suited for : amounts you're concerned about, especially for wallets in the cloud.

Case : Blockstream Greenlight , Blockstream App

VLS + Threshold Signatures (Future)

It is like this : it requires any M out of N signers to authorize the signing of lightning channel state changes (e.g., 3-of-5).

Current status : It is not yet the standard model for Lightning nodes, but it is a viable direction if there is demand.

Trade-offs : The strongest security guarantee, but also the most complex (potentially with more operational burden).

Best suited for : Treasury-style lightning funds, where overcoming friction is worthwhile to achieve multi-party control.

Case study : Not yet, but people's interest is increasing.

Demand signals : Some Lightning node operators want the Lightning Channel signing process to be compatible with internal corporate financial management (such as multi-user permissions). Flowrate recently contacted the VLS project expressing interest in using threshold permissions to safeguard customer funds. Currently, nodes are still being explored, and no "Lightning Channel multi-signature signer" architecture has yet emerged that is ready for production.

How to choose the correct security level

Lightning Wallet's security hinges on two key aspects: the likelihood of it being compromised (the probability that someone can hack into it) and the potential for massive losses if someone does manage to get in.

A practical approach is to consider: how much loss are you willing to accept if it actually breaks down ?

Use a simpler approach to safeguard smaller amounts. As the amount increases, becomes significant, or becomes crucial to your business, then choose a design that minimizes losses in the worst-case scenario, not just a design that reduces the probability of disaster.

Security is a product choice. The right level depends on how much you need to protect, how much risk you can tolerate, and the failure modes you can handle.

Enhanced node environment (secure enclave/HSM)

Level 3 is a common approach: if the node's operating environment is risky, then strengthen it. Stronger isolation, tighter access permissions, and hardware-based protection measures can reduce the probability of "server breach" escalating into "key theft".

This approach significantly raises the threshold, making it particularly suitable for operators with extensive security and deployment experience. However, it remains a networked system, so the worst-case scenario remains unchanged: what will a compromised node sign?

Here's what Level 3 looks like in reality:

Real-world case study : The ACINQ team's blog post, " Securing a $100M Lightning Node " ( https://acinq.co/blog/securing-a-100M-lightning-node) (Chinese translation available at https://www.btcstudy.org/2023/08/21/securing-a-100M-lightning-node/), describes their experience. They ran their own node within an AWS Nitro security enclave (isolation + authentication) and used a Ledger hardware signer to manually verify sensitive operations (such as software deployments). This significantly reduced operator risk and server access risks.

ACINQ also emphasizes that this is not the "ultimate" security:

• A secure enclave does not make dependencies trustworthy . Applications still need to verify that they are communicating with the correct server.
• You still have an online node . Serious node software vulnerabilities can still lead to the abuse of signature authorization.
• It is heavily reliant on operations . The highly complex security engineering has created a real operational burden.

Real-world incidents and disclosed vulnerabilities

Several real-world incidents related to the Lightning Network (one of which revealed a vulnerability that allowed theft) demonstrate that financial losses can occur without "breaking Lightning Network cryptography." They all share the same common thread: if attackers can influence what is signed, they can steal funds.

LNBank (BTCPay Server plugin): The race for concurrent withdrawals drained approximately 4.07 BTC.

A race condition in LNBank's balance processing allows an attacker to trigger numerous concurrent withdrawals before the database reflects the actual write-down, effectively draining a Lightning wallet by sending payments outwards.

• Spectral position : Level 2 for operators. Note: LNBank itself is a hosting layer (Level 1) for users.
• Impact : 407,361,805 satoshis (approximately 4.07 BTC) were reportedly transferred.
• Root cause of the problem : Under concurrent conditions, balance checks may use outdated states.
• The importance of the issue : “A node needs anything” can be dangerous, even without extracting the private key.

Sources : Victim reports , defender reviews

More details :

• Mechanism : The attacker submits a large number of concurrent withdrawal/payment requests, causing the software's state to jump back and forth between "accepting requests" and "database update".
• Observed action : A rapid series of Lightning Network outgoing payments occurred, causing the balance to run out.
• Response : After the issue was exposed, a fix was quickly released; a public report was also published.

LNbits: Malicious routing fees siphoned off >0.1 BTC

A public report (published as an issue on the LNbits codebase) claims that attackers drained an LNbits-backed wallet by forcing withdrawals through a node that charged exorbitant fees. Without strict limits on single-transaction fees, the wallet would have been completely emptied due to routing costs.

• Spectral position : Between level 1 and level 2 (hot wallet logic, plus fee expense restrictions, depending on how LNbits is deployed).
• Impact : The report claims a loss of "more than 0.1 BTC in total".
• The root cause of the problem is the lack of a single transaction fee limit and the lack of oversight of the "payment amount + fee" system (or there may be loopholes).
• Importance of the issue : On the Lightning Network, transaction fees are value. Transaction fee limits are also part of the security perimeter.

Source : LNbits Issue

More details :

• Mechanism : The attacker influenced the choice of payment path, so the only viable path included a node controlled by the attacker that charged expensive routing fees.
• Observed action : The payment is successful, but a large portion of the wallet balance is used to pay out routing fees.
• Response : The report was public; the issue was subsequently closed (with varying remediation and deployment methods).

LND “Replacement Transaction Stall” (a disclosed vulnerability that allows theft)

A disclosure of an LND vulnerability (“Replacement Transaction Stall”) describes a scenario that allows for theft: forcibly closing a channel, triggering the victim node to clean up outstanding HTLCs and send replacement transactions in the process; the report also recommends upgrade methods.

• Spectral location : Between level 2 and level 3 (hot node; infrastructure reinforcement cannot eliminate this risk).
• Impact : Vulnerabilities that allow theft (public disclosures do not always include confirmed losses).
• Root cause : An implementation-level failure that occurred in the rare scenario of clearing funds.
• The significance of the problem : Even with stronger infrastructure controls, software bugs can still lead to losses.

Source : Disclosure Report

More details :

• Who will be affected : People running nodes using the affected LND version.
• Importance : Hostile conditions surrounding forced shutdown and on-chain sweep.
• Mitigation : Upgrade to the fixed version.

These are not uncommon attacks. They are common software and operational glitches that escalate into incidents because the compromised node is a hot wallet with the authority to approve all operations.

VLS: A standalone signer with a smaller attack interface

VLS aims to combat hijacking by changing the architecture (rather than simply reinforcing the existing architecture).

It did three things at the same time:

1. Isolation : The private key and signing decision are moved out of the node and placed in a dedicated signer.
2. Reduction : Signers do far less than nodes; fewer dependencies mean fewer attack interfaces.
3. Forced : Before signing, the signer verifies the request against a set of spending terms, so the hijacked node cannot perform harmful actions.

Its promise is:

Even if the node is compromised, the attacker cannot get a signature for actions that violate the spending terms.

Example of expenditure clause:

• When the channel is closed, funds can only be sent to whitelisted addresses.
• Total transaction fees and fee rate limits
• Payment amount limits and frequency limits
• "Emergency button" (to stop the signature function if something seems wrong)
• And more

VLS in Action

Practical evidence: Greenlight

Greenlight is a real-world example of Level 4 mode: cloud node convenience, coupled with a VLS-based signature verification tool.

This answers a common question:

"Isolation and verification are certainly good things, but how can you prove that they won't ruin the user experience?"

Greenlight has demonstrated that you can have the convenience of cloud nodes without making "server hot private keys" a greater survival risk.

How to check the device you are using

Most Lightning wallet products can tell you whether they are custodial or non-custodial. But almost none of them will clearly tell you what will happen if a certain module is compromised . Below is a checklist to get the real answers.

Question 1: "If the node environment is compromised, can the attacker steal my money?"

A strong response : "Node hijacking can also be dealt with because the signer will enforce the spending conditions outside the node."

Unable to answer : "The user owns the wallet; it's private and not custodial."

The honest answer is : "Yes. If the node is breached, funds may be transferred out." (Treat it as level 2 or level 3.)

Question 2: "Where is the signature permission located?"

"In the app/node process" means you need to trust the entire runtime environment.
“In a separate signer, it enforces the spending clause,” indicating a different security boundary.

Question 3: "Which specific expenditure clauses were enforced outside of the nodes?"

• When the channel is closed, withdrawals can only be made to whitelisted addresses.
• Payment amount limits and frequency limits
• Fee limits and default security settings
• Emergency lock, or "emergency mode" that stops signing.

"We have security measures in place," but without providing details, usually means "Just trust me, bro."

In-depth exploration: More questions

Worst-case analysis, observability, insider risk, and recovery plan.

Question 4: "If a problem occurs, what is the worst-case scenario in which I will suffer losses?"

A good team will answer you with a long paragraph, explaining the measures that can stop the bleeding.

If they cannot describe the worst-case scenario, just assume their answer is: "All the money is lost."

Question 5: "If an attacker tries to steal my money, what will I see in the logs?"

Clear audit trails documented rejected attempts and warned of violations of spending terms.

"We don't know" or "It depends" implies poor observability.

Question 6: "How to prevent embezzlement?"

Separation of responsibilities, controlled deployment processes, restricted administrator actions, and the requirement for manual confirmation for dangerous operations.

If an administrator key can do anything, that doesn't qualify as a security mode!

Question 7: "How can we recover if a hijacking occurs?"

It includes a detailed incident response plan, emergency lockdown procedures, access closure strategy, and key rotation or reset plan.

Without a written plan, you're essentially a guinea pig.

If the only assurance you receive is "this is a non-custodial wallet," then you haven't actually received the answer.

Developers take action

When answering this difficult question, stop using "non-custodial" as a smokescreen. Please introduce clear safeguards.

1. Define the worst-case hijacking pattern (write it down).
2. Explain what measures can be taken to prevent unauthorized channel closures and actions that violate spending terms.
3. Write documentation on recovery, auditability, and operational safety measures.
4. If you want a cloud service experience, aim for the mode with a verified signature, so that if the node is hijacked, funds will not be transferred out of the spending terms.

Security is an architectural choice, not a to-do item.

Current situation: How secure is your wallet?

Here is a breakdown of where the major Lightning wallets and Lightning Network service providers actually stand on the security spectrum.

Note : The classification is based on publicly available information as of February 11, 2026. Suppliers are welcome to verify and update their status.

(over)