Phantom Invoice

What Is a Phantom Invoice?

A phantom invoice is a Lightning Network invoice designed to be payable to any node in a group of cooperating nodes. Instead of directing payment to a single specific node, a phantom invoice references a virtual "phantom" node that does not actually exist on the network. Each real node in the group shares the phantom node's secret key, allowing whichever node receives the incoming payment to decrypt and claim it.

The technique solves a fundamental scaling problem for Lightning merchants and services. A single Lightning node has limited inbound liquidity and represents a single point of failure. If that node goes offline, all incoming payments fail. Phantom invoices allow a service to operate multiple nodes behind a single invoice, so if one node is down or lacks liquidity, the sender's wallet automatically retries through another node in the set.

Phantom invoices were introduced by LDK in 2022 and have since been adopted by enterprise Lightning deployments, most notably Cash App's Lightning infrastructure for withdrawals and deposits.

How It Works

Phantom invoices rely on a clever combination of route hints and shared cryptographic keys. The mechanism works without any changes to the Lightning protocol itself: from the sender's perspective, the payment looks like any other Lightning payment with route hints.

The Phantom Node Concept

In a standard Lightning payment, route hints tell the sender about private channels leading to the destination node. With phantom invoices, the route hints describe a path that ends at a node that does not exist: the phantom node. Each route hint in the invoice includes two hops:

1. A real node operated by the merchant (for example, "LNMerchantNode-A")
2. The phantom node (a virtual node identified by the phantom public key)

The invoice includes multiple route hints, one for each real node in the cluster. Each route hint advertises a fake private channel between that real node and the phantom. The sender picks one of these routes and constructs the payment onion accordingly.

Shared Secret Key

All participating nodes share the phantom node's secret key (called the cross_node_seed in LDK). This shared secret serves two purposes:

• It derives the phantom node's public key, which appears in the invoice as the payment destination
• It allows any real node in the group to decrypt the final layer of the onion packet, which the sender encrypted using the phantom's public key

When a real node receives an incoming HTLC, it inspects the forwarding instructions and recognizes the phantom channel ID. Instead of trying to forward the payment to a non-existent node, the real node uses the shared phantom secret to unwrap the final onion layer, verify the payment hash, and claim the payment directly.

Step-by-Step Payment Flow

1. The merchant generates a phantom invoice using create_phantom_invoice, which includes route hints for each real node in the cluster
2. The sender's wallet selects one of the route hints and builds the payment onion, encrypting the final hop to the phantom node's public key
3. The payment routes through the network and arrives at one of the merchant's real nodes
4. The real node detects the phantom channel ID in the forwarding instructions
5. Using the shared phantom secret, the real node decrypts the last onion layer and verifies the payment details
6. The real node knows the preimage and claims the payment without forwarding
7. If the chosen node is offline, the sender's wallet retries with a different route hint, reaching a different real node

LDK Implementation

LDK provides phantom invoice support through the PhantomKeysManager struct and the create_phantom_invoice utility function. The PhantomKeysManager extends the standard KeysManager with an additional cross_node_seed parameter shared across all participating nodes:

// Each node uses its own unique seed plus
// the shared cross_node_seed
let keys_manager = PhantomKeysManager::new(
    &node_seed,       // unique per node
    current_time,
    &entropy,
    &cross_node_seed, // shared across all phantom nodes
);

// Generate a phantom invoice payable to any node
let invoice = create_phantom_invoice(
    Some(amount_msat),
    payment_hash,
    "Payment for order #1234".to_string(),
    invoice_expiry_secs,
    phantom_route_hints,  // from each real node
    entropy_source,
    node_signer,          // PhantomKeysManager
    logger,
    network,
    None,  // min_final_cltv_expiry_delta
    None,  // duration_since_epoch
);

The cross_node_seed must be identical across all nodes participating in phantom payments and must persist across restarts. Changing this seed would invalidate any outstanding phantom invoices.

Use Cases

Enterprise Load Balancing

High-volume Lightning services process thousands of payments per day. A single node can become a bottleneck due to limited channel capacity or processing power. Phantom invoices distribute incoming payments across multiple nodes automatically: the sender's wallet picks a route hint at random, spreading load without any coordination from the merchant.

Cash App, one of the largest Lightning-enabled payment apps, uses LDK with phantom invoices to operate multiple wallet nodes for handling Lightning withdrawals and deposits at scale.

High Availability

For services that cannot afford downtime, phantom invoices provide fault tolerance. If one node goes offline for maintenance, software updates, or due to hardware failure, payments automatically route to the remaining online nodes. The sender's wallet handles the retry transparently: when the first route hint fails, it tries the next one.

Geographic Distribution

Operators can deploy nodes in different data centers or regions. A phantom invoice allows payments to reach whichever node has the best connectivity or lowest latency to the sender, improving payment success rates across geographically distributed infrastructure.

Liquidity Optimization

Different nodes in a cluster may have different levels of inbound liquidity across their channels. By issuing a single phantom invoice, the merchant allows the payment to naturally find a node with sufficient inbound capacity. If one node's channels are depleted, the sender's wallet retries through a node that still has available capacity.

Risks and Considerations

No Multi-Path Payment Support

Phantom invoices do not support multi-path payments (MPP). This is a deliberate security restriction: if MPP were allowed, partial payments could arrive at different nodes, and coordinating the settlement across nodes would introduce complexity and potential race conditions. In practice, this means phantom invoices work best for smaller payment amounts that fit within a single channel's capacity.

Shared Secret Key Risk

All participating nodes must share the cross_node_seed. If this secret is compromised, an attacker could potentially intercept phantom payments or create fraudulent phantom invoices. The shared key must be distributed securely during node setup and stored with the same level of protection as the node's primary key material. Organizations should use secure key distribution mechanisms such as HSMs or encrypted configuration management.

Receive-Only Functionality

Phantom invoices only work for receiving payments. The phantom node concept does not apply to sending: outbound payments always originate from a specific real node with real channels. Services that need load-balanced sending must implement their own routing logic at the application layer.

LDK-Specific Feature

As of 2026, phantom invoices are primarily an LDK feature. Other major Lightning implementations such as LND and Core Lightning do not natively support phantom invoices. This means operators must build their Lightning infrastructure on LDK to use this feature, which may limit choices for node management tooling and plugins.

Invoice Size

Each route hint in the invoice adds data to the encoded BOLT 11 payment request. A phantom invoice with many nodes produces a larger QR code and a longer invoice string, which can create usability issues for scanning or copy-pasting. Most deployments use 2 to 5 nodes to keep invoice size manageable.

Phantom Invoices vs. Other Multi-Node Approaches

Phantom invoices are not the only way to distribute Lightning payments across nodes. Other approaches include:

For most enterprise Lightning deployments, phantom invoices offer the best combination of transparency (no protocol changes needed), reliability (automatic sender retry), and simplicity (single invoice per payment). For a deeper look at Lightning scaling strategies, see the research article on Lightning Network scalability limits.

Why It Matters

As Lightning adoption grows, the infrastructure behind Lightning services needs to scale beyond single-node setups. Phantom invoices make it possible to build production-grade Lightning payment systems with the same reliability expectations as traditional payment infrastructure: no single point of failure, horizontal scaling, and graceful degradation under load.

Layer 2 solutions like Spark take a different approach to scalability by moving transactions off-chain entirely, but for services built directly on the Lightning Network, phantom invoices remain one of the most practical tools for operating at scale.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.