How lightweight mobile nodes route payments across the Lightning Network without storing the full 500MB+ channel graph — by delegating path computation to well-connected "trampoline" nodes.
To send a Lightning payment, a node must compute a route through the network. Route computation requires knowing the full channel graph — every channel, its capacity, fees, and CLTV parameters.
The Lightning Network channel graph contains 50,000+ active channels and grows by hundreds of channel_update messages per minute. Storing and indexing this data requires 500MB+ of gossip state.
Dijkstra or modified Bellman-Ford over 20,000+ nodes requires meaningful CPU. For battery-powered devices and browser contexts, this is expensive — especially repeated per payment.
To have a current graph, a node must process channel_announcement, channel_update, and node_announcement messages continuously. Offline nodes miss updates and hold stale routing tables.
Today's light clients solve the routing problem by asking a server to compute the route. The client sends the payment intent to the server, which returns a route. This works but has a critical flaw:
The server acts as a surveillance point. Every payment Alice makes is visible: who she pays, how much, and when. This defeats the privacy guarantees that Sphinx onion routing was designed to provide.
Limited RAM, background process restrictions, intermittent connectivity. Cannot maintain a live gossip connection or store 500MB of channel data.
Browser storage limits, no persistent TCP connections for gossip, no background processing. WebSocket gossip sync is technically infeasible at scale.
Raspberry Pi-class devices running payment processing with micro-controllers. Constrained RAM and flash storage make full graph storage impossible.
Trampoline routing solves the light-client routing problem by introducing a two-level routing architecture. Alice computes only a high-level route through a small set of well-connected "trampoline nodes" — and each trampoline node computes the detailed inner route for its segment.
Trampoline routing extends the existing Sphinx onion format with a new trampoline payload type. Alice constructs a nested onion: an outer trampoline onion with a small number of hops, and inside each trampoline payload, an encrypted blob that the trampoline uses to construct the inner Sphinx onion.
When T1 receives the payment, it decrypts its trampoline payload. It sees the next trampoline (T2) and an encrypted inner blob. T1 then:
From Dave's perspective, the payment arrives as a standard Sphinx onion from T2. Dave has no idea:
| Property | Standard Sphinx | Trampoline (1 hop) | Trampoline (2 hops) |
|---|---|---|---|
| Sender identity to routing nodes | Hidden | T1 knows Alice | T1 knows Alice |
| Recipient identity to routing nodes | Hidden | T1 knows Dave | T1 knows T2 only |
| Recipient identity to first trampoline | — | Fully exposed | Hidden behind T2 |
| Payment amount to routing nodes | Approximate only | T1 sees full amount | T1 sees T2 amount |
| Graph knowledge required by sender | Full graph (500MB+) | Trampoline list only | Trampoline list only |
| Approach | Storage | Privacy | Offline Support | Trust Needed | Example |
|---|---|---|---|---|---|
| Full Node | 500MB+ | Best (Sphinx) | Needs online | None | LND, CLN, Eclair |
| Trampoline | ~1MB | Good (2 trampolines) | Excellent | Trampoline nodes | Phoenix Wallet |
| Server Routing | ~0MB | Poor (server knows all) | Good | Routing server | Custodial apps |
| Neutrino + Server | ~50MB | Medium | Good | Block filter server | Breez (old) |
| Partial Graph Sync | ~5–20MB | Good | Partial | Gossip peers | LDK-based wallets |
Trampoline routing introduces a two-layer fee problem: Alice pays fees for both the outer trampoline hops and the inner routing hops that T1 computes. The challenge is that T1 doesn't know the exact inner route cost until it computes it at payment time.
T1 declares a trampoline fee rate (e.g. 500 ppm). Alice includes enough sats to cover T1's estimated inner route cost plus T1's declared fee.
MPP splits a payment across multiple routes to improve success rates and enable larger payments. For light nodes, MPP is even harder than single-path — you'd need to find multiple disjoint routes in the full graph. Trampoline makes MPP practical for light clients.
Traditional MPP requires Alice to:
All of these require graph knowledge — impossible for light nodes.
Alice creates multiple trampoline paths to different trampolines. Each trampoline independently routes its part to Dave. Dave sees normal MPP parts:
Phoenix by ACINQ is the most widely used mobile Lightning wallet and the primary real-world deployment of trampoline routing. It uses ACINQ's own infrastructure as the default trampoline node, enabling a seamless mobile experience without requiring users to sync any channel graph.
Instead of a single ACINQ trampoline, Alice routes through 2–3 trampolines from different operators:
T1 (ACINQ) learns only that Alice paid toward T2. T2 (Bitfinex) learns only that T1 paid toward Dave. Neither knows the full sender-receiver pair.
A group of trampoline nodes form an "anonymity set" — Alice addresses her payment to the group, and any member can process it. The selected member changes per payment.
Trampoline routing improves on server-assisted routing but introduces a new trusted party — the trampoline node. Understanding exactly what each party learns is critical for privacy-conscious users and wallet designers.
Alice adds extra (fake) trampoline layers before T1. T1 can't tell how many trampolines Alice originally included. This provides padding against timing and hop-count analysis.
Alice → T_dummy → T1 → T2 → Dave
T_dummy is actually T1 itself — it peels the dummy layer and sees T2 as next trampoline. T1 doesn't know it was the dummy target.
Alice constructs the onion as if she's connecting from a non-existent previous trampoline. T1 receives the payment thinking it came from a trampoline before Alice.
This confuses observers trying to correlate Alice's outgoing payments with their trampoline entry point.
Alice maintains a list of multiple trampoline nodes and rotates between them per payment:
No single trampoline builds a complete payment history. Similar to VPN provider rotation.
| Technique | Solves | Privacy Benefit | Requirement |
|---|---|---|---|
| Trampoline | Light client routing | Hides route from Alice's routing nodes | Trampoline node support |
| Route Blinding | Recipient identity protection | Hides Dave from Alice and routing nodes | Receiver-side support |
| Trampoline + Blinding | Both | Best of both worlds | Both sides must support |
| Standard Sphinx | Routing node privacy | Each node sees only prev+next | Full graph at sender |