It is multi-level source routing: the sender builds an inner trampoline onion containing the destination, amount, fee budget and CLTV budget, carries it in an ordinary onion to the first trampoline node, and that node calculates the concrete intermediate path to the next trampoline hop or recipient; each delegated node knows only its part of the task.
Ordinary Lightning source routing assumes that the sender knows a usable network graph and selects every hop. For a phone that is often offline, this means downloading and pruning channel gossip and computing a route before payment; Trampoline Routing moves that work to several nodes with a fresher network view, not custody of keys or channels. [6]
The sender selects the first trampoline node, sets the amount, final destination, fee budget and CLTV budget, and creates a trampoline onion. An ordinary payment onion carries this smaller onion to the trampoline node; it reveals only the instruction for the next trampoline hop, finds a concrete path through ordinary nodes and rewraps the remaining onion for the next segment. [1]
Ordinary Lightning nodes may sit between two trampoline nodes without supporting the proposal: they process a standard onion and HTLC under BOLT #4. The trampoline node fills the route gap, but cannot alter the amount, time conditions or final payment secret without a later check failing. [2]
Delegation is not custody. A trampoline node receives no seed, private key or unilateral right to spend from the channel; it can nevertheless refuse or delay the payment, choose a bad or expensive path, and observe metadata for its segment. The wallet must enforce fee and CLTV budgets, the payment secret, encrypted errors and retry handling. [1]
At the beginning of October 2026, public BOLTs proposal #836 remains open, while Eclair and lightning-kmp already refer to implementing the newer proposed format and migrating from the older experimental protocol. That demonstrates real rollout, not completed network-wide interoperability; current Eclair configuration also separates general payment enablement from a prototype feature flag. [5]
Base BOLT #4 protects onion-layer contents and reveals only predecessor and successor to a hop, but does not automatically hide all metadata. A single trampoline provider may know the sending client and, when bridging to a recipient without trampoline support, the destination; multiple trampoline hops and a blinded path can split that knowledge, while timing, amount and reuse remain correlation signals. [2]
Route blinding can be combined with trampoline by putting outgoing_node_id instead of outgoing_channel_id in encrypted data. A trampoline node decrypts only the next trampoline node and computes a route to it; the recipient can hide its route segment while allowing the node to retry pathfinding during temporary liquidity shortages. [4]
Verifying a wallet requires checking whether it truly limits gossip, how it selects trampoline nodes, which feature bits and onion TLVs it uses, whether the format is legacy or proposed, how fee and CLTV budgets, failures and MPP are handled, and whether a destination without support reveals more to the trampoline node than the user expects. [3]
For the clearest picture, read this entry together with Lightning Network, Lightning Routing, Lightning Service Provider, HTLC, Payment Channel, Bitcoin Privacy.
01Can a trampoline node steal a Lightning payment?+
Delegating pathfinding alone gives it neither private keys nor a way around payment conditions. It can still refuse or delay a payment, try expensive paths or collect metadata. The wallet must bound fees and CLTV, validate the onion and payment secret, and be able to choose another node or attempt.
02Is Trampoline Routing the same as an LSP?+
No. An LSP is an operational role that may provide connectivity, a channel and liquidity; a trampoline node computes a delegated route segment. One operator can perform both roles, but they are different protocol roles and concentrating them in one service increases availability and privacy dependence.