Trampoline Routing

Trampoline routing is a Lightning Network technique that lets a sending node delegate route calculation to a better-connected intermediary, called a trampoline node, instead of computing the entire path itself. The sender only needs to find a short route to a trampoline node and instructs it, in effect, to "deliver this payment to node X." That node then performs the heavy pathfinding and forwards the payment onward — optionally through further trampoline nodes — until it reaches the recipient.

Why it exists

Full source-routing on the Lightning Network requires the sender to hold an up-to-date view of the public network graph — megabytes of channel, capacity, and fee data that changes constantly. That is a poor fit for mobile wallets with limited storage, bandwidth, and battery, and it gets worse as the network grows. By outsourcing pathfinding and retry logic to a node with a complete, fresh graph, trampoline routing keeps lightweight clients viable: the phone computes a tiny route to the trampoline and lets professional infrastructure handle the rest. Payments often complete faster too, because the trampoline node can retry failed paths locally without round-tripping every attempt back to a device that may be on a weak connection.

How the onion stays sealed

Crucially, trampoline routing preserves Lightning's onion-encryption model rather than abandoning it. The sender wraps a smaller onion — the trampoline-to-trampoline hops — inside the standard per-hop onion, so each trampoline node learns only the next trampoline in the chain, not the sender's identity or the full path. The sender still constructs the cryptographic envelope end to end; what it delegates is the routing between waypoints, not the secrecy of the payload. Fees work by delegation too: the sender attaches a fee budget generous enough for the trampoline node to pay whatever the actual route costs and keep the difference, trading a little fee efficiency for not needing to know the route at all.

Trade-offs and adoption

The convenience has a privacy price: a trampoline node learns the payment's final destination (or at least the next waypoint), which plain source routing never reveals to any intermediary. Chaining multiple trampoline hops blunts this, since no single node then sees both origin and ultimate recipient — but casual configurations with one well-known trampoline concentrate real metadata in that operator's hands. There is also a centralization gravity worth naming honestly: if most mobile wallets lean on a handful of trampoline providers, those providers become chokepoints for fees, reliability, and surveillance — the familiar convenience-versus-sovereignty trade, appearing one layer up. ACINQ's Phoenix wallet is the best-known production user, relying on trampoline routing so the wallet never syncs the full graph. A node runner who self-hosts their Lightning stack sidesteps the question entirely — your own node is your pathfinder.

Questions to ask your wallet

If you run Lightning from a phone, it is worth knowing which model your wallet uses, because the answer shapes your privacy and your failure modes. Does it source-route from its own synced graph, lean on a single trampoline operator, or delegate everything to a hosted node? Can you point it at your own node at home instead — the configuration that keeps mobile convenience while returning pathfinding, and the metadata it generates, to infrastructure you control? None of these answers is disqualifying on its own; light clients exist because full participation is genuinely heavy. But the trade should be made knowingly. As with everything in this glossary, the pattern repeats: delegation buys convenience, self-hosting buys certainty, and the healthiest setups are explicit about which they chose and why.

Trampoline routing is one of several approaches to delivering Lightning payments. Compare it with our entries on Multi-Path Payments (MPP) and BOLT12 (Offers).