Trampoline Node

What Is a Trampoline Node?

A trampoline node is a Lightning Network routing node that offers pathfinding as a service to other nodes. In standard Lightning routing, every sender must maintain a complete map of the network: every public channel, every fee policy, every node. This map is built from the gossip protocol and can consume tens of megabytes of bandwidth and storage. For a desktop node with a persistent connection, that is manageable. For a mobile wallet on a cellular connection, it is not.

Trampoline nodes solve this by letting lightweight clients delegate the pathfinding step. Instead of computing a complete route from sender to receiver, the mobile wallet only needs to find a path to a nearby trampoline node and include the final destination in a special inner onion payload. The trampoline node, which does maintain the full graph, calculates the remaining route and forwards the payment.

The concept was proposed by Bastien Teinturier of ACINQ in 2019 and formalized as a draft addition to the BOLT specifications. ACINQ's Phoenix wallet is the most prominent production implementation, routing all payments through ACINQ's trampoline infrastructure. The Electrum wallet has also implemented trampoline support using a hardcoded list of trampoline nodes.

How It Works

Trampoline routing modifies the standard Lightning payment flow by introducing a two-layer onion construction. In normal onion routing, the sender computes the entire route and wraps each hop's instructions in layers of encryption. The sender must know every channel along the path. With trampoline routing, the sender only needs to know how to reach the first trampoline node.

Nested Onion Construction

The sender creates two onion packets:

1. An outer onion that routes the payment from the sender to the trampoline node, using whatever channels the sender knows about locally
2. An inner (trampoline) onion embedded inside the outer onion's payload, containing the final destination and any intermediate trampoline hops

When the trampoline node receives the payment, it peels off its layer of the outer onion and discovers the inner trampoline onion. It decrypts its layer of the inner onion to learn the next trampoline node (or the final recipient). It then uses its own full graph to compute a route to that next hop and constructs a new outer onion for that leg of the journey, carrying the remaining inner onion as payload.

Step-by-Step Payment Flow

1. The sender's mobile wallet receives an invoice containing a payment hash
2. The wallet builds a trampoline onion specifying one or more trampoline hops and the final destination
3. The wallet wraps this trampoline onion inside a standard outer onion addressed to the first trampoline node
4. The first trampoline node receives the HTLC, decrypts its trampoline layer, and learns the next trampoline (or the recipient)
5. The trampoline node uses its pathfinding algorithm and full graph to compute a route to the next hop
6. It builds a new outer onion for this leg and forwards the HTLC with the remaining inner onion
7. The process repeats at each trampoline until the payment reaches the final recipient

Trampoline Fees and Timelocks

Trampoline nodes advertise their fees and CLTV delta requirements through a dedicated node_update message. Because the trampoline must estimate fees for the unknown intermediate route, it typically charges higher fees than a direct payment would cost. The trampoline also needs larger timelock margins to accommodate the additional hops it may use.

From the sender's perspective, the total cost of a trampoline payment is the sum of fees to reach the trampoline plus the trampoline's advertised fee. If the trampoline finds a cheaper route than it estimated, it keeps the difference.

Downgrade for Non-Trampoline Recipients

Not all recipients support trampoline routing. When the final destination is a standard Lightning node, the last trampoline in the chain converts the trampoline onion into a regular onion packet. The recipient sees a normal incoming payment and does not need to implement any trampoline logic.

Trampoline Routing vs. Full Graph Routing

Desktop Lightning nodes like LND, Core Lightning, and Eclair perform full source routing. They download the entire network graph via the gossip protocol, validate every channel announcement, and compute optimal paths locally. This approach offers maximum privacy (intermediate nodes learn nothing about the final destination) and the lowest possible fees (the sender picks the cheapest route).

Trampoline routing sacrifices some of these properties for mobile usability:

An alternative approach to solving the mobile graph problem is Rapid Gossip Sync, which serves compressed graph snapshots that can be applied in under a second. Rapid Gossip Sync preserves full source routing privacy but still requires the client to store and process the graph data locally.

Use Cases

Mobile Lightning Wallets

The primary use case for trampoline nodes is enabling mobile wallets to send Lightning payments without the overhead of maintaining a full routing table. Phoenix wallet routes all payments through ACINQ's trampoline node, allowing the app to start instantly and send payments without syncing any gossip data. Electrum's Lightning implementation similarly uses a hardcoded list of trampoline nodes.

Resource-Constrained Devices

Any device with limited CPU, memory, or bandwidth can benefit from trampoline routing. This includes IoT devices, embedded systems, and point-of-sale terminals that need to send or route Lightning payments but cannot dedicate resources to graph maintenance and pathfinding computation.

Privacy-Enhanced Multi-Hop Trampolines

Senders can chain multiple trampoline nodes to improve privacy. If the sender specifies two or three trampolines in the inner onion, each trampoline only learns the identity of the next trampoline, not the final destination. This approximates the privacy of standard onion routing, though at the cost of higher total fees and longer timelocks.

Risks and Considerations

Privacy Trade-offs

With a single trampoline hop, the trampoline node learns both the payment amount and the destination. For Phoenix users, this means ACINQ can observe the destination of every payment routed through its infrastructure. This is a significant departure from the privacy model of standard onion routing, where no intermediate node can determine both the sender and the receiver.

Two mitigations exist: chaining multiple trampoline nodes (so no single node sees both sender and receiver) and using BOLT 12 blinded paths to hide the recipient's identity from the last trampoline. Broader adoption of BOLT 12 would substantially reduce the privacy cost of trampoline routing.

Centralization Risk

If only a few nodes offer trampoline services, the network concentrates routing power and visibility in those operators. As of today, ACINQ operates the most widely used trampoline infrastructure, and Electrum maintains a small hardcoded list. A healthy trampoline ecosystem would require many independent operators advertising trampoline capability, which depends on the specification being finalized and adopted across implementations.

Higher Fees

Trampoline nodes must estimate routing fees for the path they have not yet computed. To avoid underpaying intermediate hops, they add a margin on top of the expected cost. Users pay these higher fees in exchange for the convenience of not maintaining a full graph. Over time, competition among trampoline providers could drive fees closer to the true routing cost.

Specification Status

Trampoline routing has not been merged into the core BOLT specifications as of 2026. It remains a draft proposal with production implementations in Phoenix (via Eclair) and Electrum. Other major Lightning implementations such as LND and Core Lightning do not yet support trampoline routing natively, which limits interoperability and the pool of available trampoline nodes.

Why It Matters

Lightning's vision as a global payment network depends on mobile accessibility. Most users will interact with Lightning through phones, not desktop nodes. Without solutions like trampoline routing, mobile wallets must either download the full gossip graph (impractical on cellular connections) or rely on centralized services to compute routes (sacrificing self-sovereignty). Trampoline nodes offer a middle path: the wallet remains a real Lightning node with its own channels and keys, while outsourcing only the computationally expensive pathfinding step.

For a deeper look at how trampoline routing fits into Lightning's mobile scaling strategy, see the research article on trampoline routing for mobile wallets. For related concepts, explore trampoline payments, lightweight clients, and routing nodes.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.