Node Security

Use this page for Node-backed Payments and supported direct LND integrations. For Credit-backed Payments without direct node access, start with Payments Access.

Keep access layers separate

Control	Scope	Does not replace
Payments API key IP allowlist	Requests using that key at the Payments API	Node endpoint restrictions or LND permissions
Node IP allowlist	Enabled public LND REST and gRPC routes, and the litd web interface where enabled	A valid macaroon, TLS validation, or Payments API key restrictions
LND macaroon IP caveat	Requests authenticated with that constrained credential, as evaluated by LND	Node ingress policy or restrictions on other credentials
Team permissions	Permitted dashboard pages and actions	Credential revocation for copies already exported

A node allowlist is not a firewall for every product or service. It does not restrict Lightning peer connections, Sphinx endpoints, or the Payments API. Do not assume it covers other endpoints or internal network paths. Confirm additional interfaces with your Voltage advisor.

The managed ingress also allows required Voltage service addresses. Your displayed node list is not the complete effective source list. Confirm the effective policy and service exceptions with Voltage; do not treat it as access exclusive to your own addresses.

Node IP allowlisting

Restrict public node API access to the stable outbound addresses required by your integration and approved operators. An empty node allowlist removes this IP restriction; it does not mean “deny all.” LND still requires authentication for protected RPC calls.

Open the node’s Manage Access > IP Whitelist in the supported node-management dashboard. If you cannot access it, ask your Voltage advisor to confirm and configure the node policy before you fund the node.

1. Inventory callers: application servers, monitoring, operator VPNs, and required Voltage services.
2. Confirm their public outbound addresses after NAT, VPNs, proxies, and failover.
3. Ask Voltage to confirm required service addresses for this deployment. Do not guess or copy an old IP list.
4. Enter the approved addresses, one per line. The current dashboard form validates IPv4 entries.
5. Save the policy. Keep an approved recovery route available during the change.
6. Verify a harmless read succeeds from an approved source with an authorized credential.
7. Verify the same read fails from an unapproved source using an otherwise valid, narrowly scoped test credential.
8. Confirm Payments fulfillment and required operational connections still work. Record the results and policy owner.

If a required caller uses IPv6 or changing addresses, confirm the supported configuration with Voltage before launch. Never widen access to all addresses just to clear a connection error.

A saved policy is not proof of enforcement. Test each enabled interface after provisioning, policy changes, and network changes. Use controlled test credentials and your own systems; never put production secrets in shared diagnostics.

Note

Do not assume a newly created or existing node has a Voltage-only policy. Verify the effective configuration before launch.

Protect credentials and recovery material

• Keep Admin and Super Admin macaroons out of application backends. Use least-privilege macaroons.
• Store the node password in your approved password manager with tightly limited operator access.
• Keep seed phrases offline and separate from routine application credentials.
• Use the approved backup workflow. Keep backup decryption secrets separate from backup payloads.
• Record the recovery owner, storage location, access policy, and last validation date without recording secrets.
• Verify TLS in production. Never disable certificate validation to work around a connection problem.

Changing dashboard access, deleting an export, or changing a password does not by itself prove a macaroon was revoked. Follow credential lifecycle guidance and confirm the result at LND.

Prepare for mainnet

Complete the Mainnet Go-live Security Checklist before exposing a production integration or funding its node. If credentials may be exposed, contact your Voltage advisor through your established support channel immediately. Never send seeds, passwords, private keys, or macaroons in a support request.