Frequently Asked Questions

VLS (Validating Lightning Signer) keeps Lightning private keys off the node and validates every request before signing. If a node is compromised or misbehaves, VLS refuses the signature. Result: non‑custodial control, hot‑wallet speed and enterprise-grade security.

Blind signing is when a signer produces signatures without validating what it signs. Separating keys from the node helps only if the signer enforces protocol and policy. Without validation, you get shared custody (the node can trick the signer)and two failure paths (node or signer).

Because loss can occur if either the node or the signer is compromised. Custodial and hot‑wallet models expose one primary loss path; blind signing exposes two. More complexity, more ways to lose funds.

Yes. Under the standard definition: only the user who holds keys with VLS can move funds. The node may propose updates, but the validating signer enforces policy and approves or rejects. A compromised node alone cannot move funds.

Confirm one of two truths: (1) you run both node and keys (hot wallet), or (2) your keys sit behind a validating signer that enforces protocol and policy. If the signer is blind, it’s shared custody regardless of marketing. Check your Lightning wallet.

The attacker can request operations, but VLS checks channel state, HTLCs, amounts, destinations, and timing before signing. Malicious or out‑of‑policy requests are rejected, containing the incident.

If an attacker controls your signing keys, they can steal funds in any model. Different setups have different security risks: blind signers are the least secure, hot wallets are next, and VLS is most secure. VLS allows you to use defense‑in‑depth: isolate and harden the signer (separate host or enclave), restrict reachability, and enforce strict policy limits. Pair with independent state sources (UTXO oracle, channel tracking) to cross‑check node claims.

Not in production. For tiny balances, custodial can be simpler; for meaningful funds, VLS is the safer path. Blind signing brings high complexity with weak security guarantees.

We strongly recommend you never do this. If the seed was exposed before, moving it to VLS won’t retroactively secure those keys. Generate new keys and migrate cleanly.

Lightning requires online keys (hot). VLS reduces hot‑wallet risk by keeping keys off‑node and validating every operation before signing.

Lightning requires timely, online responses (channel updates, HTLC deadlines, penalties). Pure cold storage is too slow. VLS gives cold‑wallet‑style validation at Lightning speed.

Yes. Start by protecting high‑risk ops (channel closes, large payments), then widen coverage. Teams often delete bespoke validation code and keep the same UX while VLS silently blocks unsafe requests.

VLS ships reference integrations for CLN and LDK. LND and Eclair are not yet supported.

Run the vlsd daemon next to your CLN node, enable the CLN plugin, and point it at the signer. Set minimal policy (start with high‑risk ops), test on regtest/signet, then roll out and widen coverage.

Add the VLS client to your LDK app, configure the signer endpoint, and define minimal policy. Exercise channel and payment flows in test, then gate production with policy approvals.

Validating signer with policy engine, vlsd daemon/Docker, UTXO oracle (txood), Lightning Storage Server, and CLN/LDK integrations. Licensed Apache‑2.0 and open for audit.

Off‑node, in your environment. Commonly on a separate host or enclave, and may integrate OS‑level secrets or an HSM/KMS boundary. The node never gets raw key material.

1. Stand up VLS alongside your node; 2) Start with read‑only checks in staging; 3) Enforce policy for high‑risk operations; 4) Gradually disable blind signing; 5) Expand policy to routine flows.

Fewer custody incidents and less custom security code frees up time to ship features. Non‑custodial options powered by VLS attract users who won't deposit funds in custodial solutions. See Greenlight's case study.

Add a non‑custodial tier to reach new regions (regulatory freedom), attract self‑custody users (expanded TAM), and reduce balance‑sheet exposure (lower capital requirements).

Yes. Keep custody where it's strategic. Add a non‑custodial tier for new geographies, users who won't deposit, and reduced regulatory overhead. Serve both personas.

You can keep custodial lines (and their moat) while testing product faster in a non‑custodial tier. Differentiate by choice, not by lock‑in.

Blockstream Greenlight, Breez SDK, Lipa, and more. Read the Greenlight case study.

The node cannot proceed without signatures. Run the signer highly‑available (active/standby or quorum) and monitor like any critical dependency.

State backups aren't enough. If your state is off by one commitment, you could lose funds. Use synchronous state replication (e.g., PostgreSQL synchronous replication).

Yes, validation decisions and policy rejections are recorded so you can trace who/what/why for each request. Use these logs for incident response and compliance reporting.

Yes, see here. The code is also open for review. We follow coordinated disclosure (Security Policy).

VLS is an extra defense layer with "deny‑by‑default" for unknown requests. The project is Apache‑2.0, public on GitLab, and accepts vulnerability reports. Pin versions, roll back, or constrain policy while upgrading.

Common deployments pair the signer with a chain state source (UTXO oracle) and optional cloud state service for Lightning state. These help the signer independently verify node claims.

Not when deployed correctly. Policy checks are lightweight and tunable; validations complete in sub‑second time and UX remains unchanged.

Yes. Scale horizontally and isolate components (signer, policy engine, state services). Use connection pooling and keep state hot in memory where appropriate.

If you don't hold custody of user funds, you typically avoid custodial compliance overhead. VLS enables a non‑custodial tier while you keep custodial products where strategic. (Not legal advice; confirm with counsel.)

VLS is open‑source and released under the Apache‑2.0 license. You can audit, fork, and self‑host.

No. VLS is open source. If you use a hosted provider (e.g., as part of an LSP offering), their standard service fees may apply.

Check the validation log for the exact rule that failed (amount limit, destination list, expired invoice, velocity, outside hours, etc.). Re‑test on signet/regtest and adjust policy thresholds if appropriate.

Gate high‑risk operations first, run with verbose logs, then expand policy to routine flows. Keep a fast rollback (toggle or env flag) for early stages.

Documentation (Docs), example policies (Policy Examples), and real‑time help in Matrix. Open issues on GitLab.

Per‑tx and velocity limits, destination allow/deny lists, close‑to addresses, time‑of‑day windows, invoice freshness, multi‑party approvals. Start with high‑risk ops, then expand.

A signer that approves properly formatted requests without validating them against protocol rules and policy. Unsafe requests can pass.

A signer that independently checks each request (protocol and policy) before producing a signature. Unsafe requests are rejected; node compromise cannot steal funds.

A trusted chain state source the signer can query to verify on‑chain claims (e.g., funding outputs, balances, fees) independently of the node.

Only the user can move funds: either the user runs their own node and holsd their own keys, or keys behind a validating signer that enforces rules, and then a third party can run the node without giving up custody.

Multiple parties can move funds independently. Blind signing creates shared custody between user and service provider (e.g. LSP).

A wallet that sends/receives BTC over Lightning channels. With VLS, users get non‑custodial Lightning without blind‑signing or hot wallet risks.

A provider that opens/manages channels, liquidity, and routing. With VLS, LSPs can remain non‑custodial: keys stay off‑node and the signer validates requests.