Route Blinding

Route Blinding introduces a cryptographic mechanism that allows a payment recipient to hide its node ID and the final segment of a payment path. Instead of the sender constructing a complete route to a known destination, the recipient provides a blinded path—a sequence of encrypted hops ending at an introduction point—and a blinded ephemeral public key. The sender uses this blinded path as the final segment of the route, appending its own path to reach the introduction point. Intermediate nodes forward the payment without learning whether the next hop is another intermediary or the final recipient, breaking the pervasive surveillance model where every routing node knows the ultimate destination of a payment.

The upgrade is specified across multiple BOLTs, primarily BOLT 4 (Onion Routing) for the blinded path construction and BOLT 7 (Gossip) for advertising blinded route capabilities. It relies on the blinded_path TLV extension in invoices and the encrypted_data field in onion payloads. Recipients construct a blinded path by recursively encrypting hop data for each node in the path using a shared secret derived from an ephemeral key. The sender then uses the final blinded node ID as the target for its own route construction, with the onion payload carrying both the standard forwarding instructions and the encrypted data blob that each blinded hop can decrypt and process. This design preserves the existing onion routing security model while adding recipient unlinkability.

For wallet teams, payment processors, and LSPs, Route Blinding represents a fundamental shift in how invoices are constructed and how payment reception is architected. Integration requires support for generating blinded paths, handling the new blinded_path invoice fields, and processing incoming payments that arrive via introduction points rather than directly to the node's public key. Node operators running introduction points must be prepared to forward payments where they cannot identify the final recipient. Chainscore Labs can assist teams with protocol impact assessment, integration review, and upgrade readiness planning to ensure that recipient privacy is implemented correctly without breaking existing payment flows or introducing new reliability risks.

Route blinding is a protocol upgrade that allows a Lightning Network payment recipient to hide their node ID and the final segment of the payment path from the sender and intermediate routing nodes. The recipient constructs a blinded path by selecting a sequence of introduction nodes and intermediate hops, then encrypting the path information using a series of ephemeral key pairs. This blinded path is embedded in a BOLT 11 invoice or BOLT 12 offer, enabling the sender to route a payment without ever learning the recipient's public key or the topology of the final hops. The mechanism fundamentally changes the privacy model from one where the recipient's node is a public routing endpoint to one where it is a hidden terminus reachable only through a cryptographic unblinding process.

The construction relies on a chain of ephemeral blinded node IDs and encrypted path_id data. The recipient generates a sequence of shared secrets using ECDH between a random initial key and each hop's public key. For each hop, the recipient derives a blinded_node_id and an encrypted payload containing the next hop's instructions. The sender uses the first blinded_node_id as the payment destination in the outer onion, and the first introduction node uses the path_id to unblind the next ephemeral key and forward the HTLC. Each hop in the blinded path can only decrypt its own payload and learn the next blinded node ID, ensuring that no single routing node can map the full path. This nested encryption is layered inside the standard Sphinx onion routing, preserving compatibility with the existing forwarding infrastructure while adding a recipient-controlled privacy shield.

For wallet developers and payment processors, integrating route blinding requires support for generating and parsing blinded paths in invoices, managing ephemeral key material, and handling the new blinded_path TLV fields in update_add_htlc and onion_routing_packet messages. Node operators acting as introduction points must be able to process the path_id to correctly forward to the next blinded hop without learning the final destination. The upgrade introduces new operational considerations: blinded paths can include multiple introduction nodes for redundancy, and the recipient must keep ephemeral keys available to decrypt the final payment preimage. Teams should audit their onion-processing implementations to ensure they correctly handle the nested encryption and do not leak timing or error information that could deanonymize the recipient.