Trampoline Payments

What Are Trampoline Payments?

Trampoline payments are a routing technique in the Lightning Network that allows lightweight clients to send payments without knowing the complete network topology. Instead of finding the full path from sender to recipient, the sender constructs a partial route to a well-connected "trampoline node" and delegates the remaining pathfinding to that node.

Standard Lightning routing requires the sender to have an up-to-date view of the network graph. This graph contains every public channel, its capacity, fee policies, and connection information. For a desktop node with constant connectivity, maintaining this graph is straightforward. For a mobile wallet that connects intermittently, syncing gigabytes of gossip data every time you open the app is impractical.

Trampoline solves this by letting mobile wallets outsource the hard work. The wallet only needs to know how to reach a few trampoline nodes. Those nodes handle pathfinding to the final destination. Think of it like giving directions to a taxi driver: you tell them the destination, and they figure out the best route.

How They Work

Trampoline routing uses a nested onion structure. The sender creates an outer onion that routes to the trampoline node, with an inner onion containing instructions for reaching the final destination.

Step-by-Step Flow

1. Sender identifies trampoline nodes: The wallet maintains a small list of well-connected nodes that support trampoline routing. These might be the wallet's LSP or public routing nodes.
2. Sender creates nested onion: The outer layer routes to the first trampoline node. Inside that layer is another encrypted payload containing the final destination and payment details.
3. First hop receives payment: The sender routes the HTLC to the trampoline node using whatever path they know (often a direct channel to their LSP).
4. Trampoline node unwraps: The trampoline node decrypts the outer layer and finds the inner trampoline payload. This reveals the next trampoline hop or the final destination.
5. Trampoline finds the route: Using its full network graph, the trampoline node calculates the optimal path to the next hop. It constructs a new onion for this leg of the journey.
6. Payment continues: The process repeats if there are multiple trampoline hops. Eventually, the payment reaches the final recipient through standard routing.

The Onion Structure

A trampoline payment contains onions within onions. The sender encrypts:

• An outer onion with hop data for reaching the first trampoline node
• An inner "trampoline onion" that only trampoline nodes can read, containing the next trampoline hop or final destination

Each trampoline node peels one layer of the trampoline onion, learns its next instructions, and builds regular routing onions for the path to the next trampoline. The final trampoline node routes directly to the recipient.

Why They Matter

Trampoline payments exist because mobile Lightning is hard. The constraints of mobile devices conflict with how Lightning routing traditionally works.

The Mobile Problem

A full Lightning node needs to:

• Store the complete channel graph (hundreds of megabytes)
• Sync gossip updates continuously
• Run pathfinding algorithms that consume CPU and memory
• Stay online to receive updates and route payments

Mobile devices have limited storage, intermittent connectivity, background process restrictions, and battery constraints. Running a full routing node on a phone drains battery, uses data, and slows down the user experience.

The Trampoline Solution

With trampoline routing, mobile wallets shift the burden:

• No graph storage: The wallet only stores information about a few trampoline nodes, not the entire network.
• No continuous sync: No need to process gossip messages or track channel updates across the network.
• Instant payments: Users can send payments immediately after opening the app, without waiting for sync.
• Lower resource usage: Pathfinding happens on powerful, always-online trampoline nodes instead of the phone.

Technical Implementation

Trampoline routing is defined in BOLT proposals and implemented in several Lightning clients. The key technical components include:

Trampoline Onion Format

The trampoline payload uses a TLV (Type-Length-Value) format inside the standard onion. Key fields include:

• next_trampoline: The public key of the next trampoline node or final recipient
• amt_to_forward: The amount to forward (may include fees for subsequent hops)
• outgoing_cltv_value: The timelock for the forwarded HTLC
• invoice_features: Feature bits from the recipient's invoice
• invoice_routing_info: Route hints from the invoice, if the recipient has private channels

Fee Handling

Trampoline nodes charge fees for their pathfinding service. The sender must include enough value to cover:

• The trampoline node's own fee
• Estimated routing fees for the path the trampoline will find

Since the sender doesn't know the exact route, they must overpay slightly. The trampoline node keeps the difference between what the sender provided and what the actual route costs. This creates an incentive for trampoline nodes to find efficient routes.

Multi-Hop Trampolines

A payment can bounce through multiple trampoline nodes before reaching the destination. This provides:

• Redundancy: If one trampoline can't find a route, the next might
• Privacy: Each trampoline only sees its immediate neighbors in the trampoline chain
• Load distribution: Pathfinding work spreads across multiple nodes

Use Cases

Mobile Lightning Wallets

The primary use case. Wallets like Phoenix and Breez use trampoline routing to deliver instant payments without requiring users to sync network data. When you open these apps, you can pay immediately because your LSP handles the routing complexity.

Browser-Based Wallets

Web wallets face similar constraints to mobile. They cannot store large amounts of data in the browser and need to minimize bandwidth usage. Trampoline routing lets browser wallets offer full Lightning functionality without heavyweight infrastructure.

IoT and Embedded Devices

Devices with minimal compute resources (point-of-sale terminals, vending machines, embedded systems) can use trampoline routing to send and receive Lightning payments without running full routing logic.

Privacy-Conscious Users

Counterintuitively, trampoline routing can enhance privacy in some scenarios. By using multiple trampoline hops, the sender obscures their payment pattern. No single node sees both the sender and final recipient. However, this requires trusting that trampoline nodes don't collude.

Limitations

Privacy Tradeoffs

The most significant limitation. In standard Lightning routing, intermediate nodes only learn their immediate predecessor and successor. They cannot determine the payment's origin or final destination.

With trampoline routing, the trampoline node learns the final destination. If you use a single trampoline, that node knows both who you are (you have a channel with them) and who you're paying. This is a meaningful privacy reduction.

Mitigations exist:

• Use multiple trampoline hops so no single node sees the full picture
• Choose trampoline nodes you trust
• Rotate between different trampoline nodes for different payments

Trampoline Node Availability

Not all Lightning nodes support trampoline routing. The sender must know which nodes offer this service. If trampoline nodes go offline or become congested, payments may fail or be delayed. Mobile wallets typically solve this by having their LSP serve as the trampoline.

Fee Estimation

Since senders don't know the actual route, they must estimate fees. Overestimate and you overpay. Underestimate and the payment fails. Wallets handle this with heuristics and retry logic, but it adds complexity compared to sender-side routing.

Not Universal

Trampoline routing requires support from both the sender's wallet and at least one intermediate node. It's not part of the base Lightning protocol that all nodes implement. Adoption is growing but not yet universal.

FAQ