The Lightning Custody Spectrum
Your Keys, Not Your Coins?
TL;DR
- The Current State of Lightning Wallets and LSPs, asking what and who is truly Non-Custodial.
- On Bitcoin Layer 1, holding keys means self-custody. On Lightning, even if you hold your keys, but your signer blindly approves requests without validation, a compromised node can move your funds. That's shared custody.
- Blind signing is neither non-custodial nor safe. It creates two failure points (node and signer). If either is compromised, funds can be lost.
- VLS (Validating Lightning Signer) provides a true non-custodial solution by separating keys from the node and validating every request. Node compromise cannot lead to fund loss.
Table of Contents
- A Promise and Problem of Lightning
- What Is Blind Signing in Lightning?
- Why Blind Signing Is Worse Than Hot Wallets
- How Attacks Actually Happen
- Why Lightning Custody Isn't Like Bitcoin
- LSPs: The Solution That Created a New Problem
- How VLS Fixes This
- Proof It Works: Blockstream Greenlight
- The Four Lightning Custody Models
- The Current State: Who's Really Non-Custodial?
- How to Check Your Current Wallet
- Choosing the Right Model for Your Funds
- Call to Action For Developers: Stop Shipping Blind Signers
- Your Move: Demand Real Self-Custody
- The Path Forward
- FAQ
A Promise and Problem of Lightning
You carefully researched and chose "non-custodial" because you believe in "not your keys, not your coins." You carefully secured your seed phrase. You hold your own keys.
Then one morning, you wake up to find your channels have been closed. Your sats have been sent to addresses you don't recognize. The logs show your signer approved everything. Your bitcoin is gone. Your "self-custody" wallet just rugged you.
Lightning promised Bitcoin's self-sovereign principles for instant payments. But something went wrong.
Your wallet might claim to be non-custodial because you "hold your keys," but if your signer blindly approves requests without validation, who really controls your funds?
This is the reality of blind signing, Lightning's dirty secret.
What Is Blind Signing in Lightning?
Lightning has two actors:
- The node proposes updates.
- The signer decides whether those updates are safe to sign.
In a proper non-custodial setup, the signer validates every request against protocol rules and your policies before signing.
With blind signing, the Lightning private keys are separated from the node, but the signer blindly approves whatever the node requests without validation. This is because the blind signer rubber-stamps properly formatted transactions, but it does not have enough information to tell the difference between safe and unsafe requests.
Marketing a blind signer as "non-custodial" is like a bank saying it's non-custodial just because it doesn't know your encrypted password. Keys without validation aren't control, they're theater.
Users deserve to know the truth: blind signing is shared custody, and it's actually riskier than some custodial solutions. For years, Lightning technology companies have camouflaged blind signing solutions as "non-custodial" or "self-custodial."
The Hardware Wallet Test
Imagine a Bitcoin hardware wallet that signed any transaction without checking the change address, fees, or destination. Would you call that non-custodial? Would you trust it?
That's blind signing on Lightning.
Why Blind Signing Is Worse Than Hot Wallets
Blind signing literally doubles your attack surface while still being custodial. You can lose funds if the node OR the signer is compromised. Yet companies market this as an improvement over custodial solutions. We are calling this out because users deserve to understand the truth.
A hot wallet user at least knows they're taking a risk. Do blind signing users think they're safe because they 'hold their keys'?
How Attacks Actually Happen
Every compromise starts somewhere. Here's how vulnerabilities turn into theft:
Scenario 1: Supply Chain → Compromised Node → Malicious Close
Scenario 2: Social Engineering → LSP Access → Revoked State
Scenario 3: Insider Threat → Fee Manipulation
Why Lightning Custody Isn't Like Bitcoin
On Bitcoin Layer 1, self-custody is straightforward. Your hardware wallet (cold wallet) validates every transaction by checking addresses, fees, and change, before signing. This validation paired with control of private keys is what makes it self-custodial. Your keys genuinely means your coins.
Bitcoin's cold wallet model doesn't translate directly to Lightning because:
- Channel states update constantly - Unlike Bitcoin's static addresses
- HTLCs have deadlines - Missing them means losing funds
- Penalties require quick response - Broadcast revoked states must be challenged immediately
- Routing needs sub-second signatures - Cold wallets are too slow
These requirements meant early Lightning required running your own node with hot keys, this is complex for users and risky for funds.
LSPs: The Solution That Created a New Problem
Lightning Service Providers (LSPs) emerged to solve Lightning's usability crisis. Running a Lightning node requires technical expertise, constant monitoring, channel management, and liquidity provision. LSPs handle all of this complexity, and they deserve credit for this. This is a huge UX upgrade.
However, to make LSPs work while being "non-custodial," the industry adopted blind signing. The pitch was simple: the LSP runs your node, you keep your keys. Your keys, your coins, right?
Wrong. When your keys blindly sign whatever the LSP's node requests, without validation, you're trusting the LSP not to steal. That's not self-custody, it's shared custody at best.
The irony: LSPs made Lightning usable, but blind signing made it less secure than either hot wallets OR custodial services. You get complexity without control.
The good news: LSP convenience doesn't require this compromise. Validation solves it.
How VLS Fixes This
VLS (Validating Lightning Signer) implements what every Lightning signer should do: validate before signing.
Before signing anything, VLS checks:
Protocol Compliance
- Is this a revoked state? → Reject
- Do HTLC balances match? → Verify
- Are fees reasonable? → Check limits
- Is the destination approved? → Validate
Policy Enforcement
- Payment amounts within limits
- Closing addresses on approved list
- Unusual patterns blocked
- Large transactions need extra approval
Independent Verification
- Chain state validated separately
- Channel states tracked independently
- Timelock expirations monitored
- Node claims cross-checked
VLS in Action
Blind Signer
VLS
Proof It Works: Blockstream Greenlight
Greenlight proves this works at scale:
- Architecture: Blockstream runs nodes, users control validation via VLS
- Track record: Zero funds lost to node compromise
- Security: Node compromise cannot steal funds
- Performance: Sub-second validations don't impact UX
- Users: Thousands using true self-custody
This model proves you can have LSP convenience without custody compromise. Read more about why Greenlight chose VLS and their experience with integration.
The Four Lightning Custody Models
Understanding where your Lightning wallet falls on this spectrum is crucial:
1. Custodial
- You have:
- Nothing
- They have:
- Keys + node
- Custody:
- 0% (they control everything)
- Attack surface:
- 1 point (the custodian)
- Examples:
- Most exchange wallets
- Best for:
- Trying Lightning with coffee money
2. Shared Custody: Blind Signing
- You have:
- Keys that blindly sign
- They have:
- Node that requests signatures
- Custody:
- ~50%, shared custody: both parties needed, but the node can trick the signer (remember, they're actors!)
- Attack surface:
- 2 points (node OR signer compromise = loss)
- Examples:
- Many "non-custodial" LSP wallets
- Reality check:
- Worse than custodial - more complex, more attack vectors, still requires trust
3. Self-Custody Hot Wallet
- You have:
- Keys + node on same device
- They have:
- Nothing
- Custody:
- 100% (you control everything)
- Attack surface:
- 1 point (your device)
- Examples:
- Zeus (local node), Phoenix (self-hosted)
- Best for:
- Power users comfortable with hot wallet risks
4. Self-Custody with Validation (VLS)
- You have:
- Keys + validation logic
- They have:
- Node (but can't steal)
- Custody:
- 100% (node can propose, only you can approve)
- Attack surface:
- 1 hardened point (validating signer)
- Examples:
- Blockstream's Greenlight uses Validating Lightning Signer ("VLS")
- Best for:
- Anyone with funds they care about
The Current State: Who's Really Non-Custodial?
Here's where major Lightning wallets and LSPs actually fall on the custody spectrum. Take note of how many "non-custodial" services actually use blind signing. Marketing claims don't match technical reality!
Filters
Click to filter by custody type. Select multiple to compare.
How to Check Your Current Wallet
Ask your Lightning wallet provider these specific questions:
Question 1: "If your servers/node got hacked today, could the attacker steal my funds?"
- "No, validation prevents it" → Self-custody with validation
- "No, you hold the keys" → Red flag for blind signing
- "Yes" → At least they're honest
Question 2: "What specific checks does the signer perform before signing?"
- Detailed list of validations → Real self-custody
- "It signs what you authorize" → Blind signing
- Vague security claims → Blind signing
Question 3: "Can I close my channel to any address?"
- "Only to your whitelisted addresses" → Validation
- "To any address you sign for" → Blind signing
Choosing the Right Model for Your Funds
For $10-100 ("coffee money"):
- Custodial is fine - simple and honest about trust
- Avoid blind signing - unnecessary complexity
For $100-1,000 ("spending money"):
- Hot wallet if you're technical
- Quality custodial LSP if you're not
- Definitely avoid the risk of blind signing
For $1,000+ ("real money"):
- VLS: validated self-custody only
- Hot wallet if you are sure you really know what you're doing
- Never blind signing
For business/exchange reserves:
- VLS is the only responsible choice
Call to Action For Developers: Stop Shipping Blind Signers
What kind of setup?
-
I’m a business or app developer who just wants a secure Lightning setup without deep infrastructure work
→ Use a hosted non-custodial provider powered by VLS: Greenlight by Blockstream or Breez SDK -
I want to control my own Lightning node, but don’t want to build everything from scratch
→ Use CLN + VLS; secure and flexible, without full custom integration. -
I want full control and deep integration flexibility
→ Use LDK + VLS; great for custom deployments.
Which Lightning Stack?
Choose your stack to get started:
-
CLN + VLS
Use ourvls-hsmdplugin to forward signing requests from Core Lightning. -
LDK + VLS
Integrate via thevls-proxycrate inside your LDK-based node. -
Docker Sandbox
Run CLN + VLS + Bitcoind locally using Docker. Great for testing. -
LND or Eclair
Not yet supported. Help move things forward by reaching out to LND or Eclair to encourage VLS support:
There's no technical excuse for blind signing anymore. VLS is Apache licensed, open source, and production-ready.
Your Move: Demand Real Self-Custody
The Lightning ecosystem has confused holding keys with controlling funds for too long. Blind signing is shared custody with extra steps, not self-custody.
VLS proves true Lightning self-custody is possible. No more excuses. No more blind signing.
The Path Forward
Lightning's future depends on honest custody models. We're asking:
Users:
- Understand what you're actually trusting
- Choose custody models that match your risk tolerance
- Demand transparency from wallet providers
- Vote with your sats; support true self-custody
Developers:
- Stop calling blind signing "non-custodial"
- Implement validation or be honest about custody
- Compete on real security, not marketing
- Differentiate with true non-custodial offerings
LN Ecosystem:
- Establish validation as the minimum standard
- Call out blind signing for what it is: shared custody
- Advocate for projects that prioritize true self-custody
- Phase out blind signing entirely
You now know the truth. The question is: what will you do about it?
- Today: Check your current wallet using our questions
- This week: Move funds to validated non-custodial wallets if needed
- Going forward: Demand transparency, support real solutions
FAQ
What is blind signing in Lightning?
A signer that approves requests without validating them against Lightning protocol rules or policy. It creates shared custody, not self-custody, and doubles the attack surface.
Why is blind signing worse than custodial?
Custodial has one point of failure. Blind signing has two, if either the node OR signer is compromised, you lose funds. More complexity, more attack surface, same trust requirement.
Why can't I use a cold wallet for Lightning?
Lightning requires timely responses to channel updates and on-chain events. Pure cold wallets can't react fast enough. VLS provides cold wallet-style validation with Lightning-appropriate speed.
How do I verify true non-custodial Lightning?
Either you control both node and signer (hot wallet), or your keys are separated with a validating signer that enforces rules. If it's blind signing, it's shared custody regardless of marketing.
Is there ever a good reason for blind signing?
No. It's more complex than custodial with worse security. For small amounts, use custodial. For large amounts, use validated self-custody. Blind signing is the worst of both worlds.