Trampoline Routing: How Mobile Lightning Wallets Outsource Pathfinding

Sending a Lightning payment requires computing a route through a network of thousands of nodes and tens of thousands of channels. To do that, the sender needs the full network graph: a dataset that exceeds 50 MB of raw gossip data and continues growing as the network expands. For a server in a data center, this is trivial. For a phone on a cellular connection, it is a serious problem.

Trampoline routing solves this by letting lightweight wallets delegate pathfinding to well-connected intermediate nodes. Instead of computing the full route, the sender picks one or more trampoline nodes and says: “deliver this payment to node X.” The trampoline node, which maintains the complete graph, handles the actual route computation and forwarding.

Why Mobile Wallets Cannot Route Payments

Lightning’s source-based routing model requires the sender to construct the entire payment path before sending. This is a deliberate design choice: it preserves privacy through onion encryption, where each hop only learns the previous and next node in the chain. But it creates a fundamental tension for mobile devices.

The graph sync problem

The Lightning Network’s gossip protocol propagates channel announcements and updates across all connected nodes. According to measurements from the LDK team, a full gossip sync with approximately 80,000 channel announcements and 160,000 channel updates totals roughly 53 MB of uncompressed data. A mobile wallet opening for the first time must download and process this entire dataset before it can send a single payment.

The problem compounds over time. Channel updates arrive continuously as fee policies and balances shift. A wallet that was offline for 24 hours needs to process approximately 5.7 MB of gossip deltas just to catch up. On metered mobile connections, this bandwidth cost is significant, and the CPU and memory required to run pathfinding algorithms on a full graph can drain battery quickly.

Constraints unique to mobile

• Operating systems aggressively kill background processes, so nodes cannot maintain persistent connections or sync graphs passively
• Storage is limited and shared with other apps, making it impractical to keep a constantly-updated graph database
• Network connectivity is intermittent, so long gossip sync sessions may fail partway through and need to restart
• Users expect instant responsiveness: waiting 30 seconds to sync the graph before paying for coffee is unacceptable

How Trampoline Routing Works

The core idea, first proposed by Bastien Teinturier of ACINQ at the 2019 Lightning Conference, introduces a two-layer onion routing scheme. The sender constructs a small “trampoline onion” that identifies intermediate trampoline nodes by their public key. This trampoline onion is then embedded inside a standard BOLT 4 onion packet that routes to the first trampoline node.

Step-by-step payment flow

1. The sender knows its direct peers and a set of known trampoline nodes, but not the full network graph
2. The sender constructs an outer onion to reach the first trampoline node, embedding a trampoline onion in the final payload
3. The first trampoline node decrypts the trampoline onion, discovers the next trampoline node (or final recipient), and uses its full graph to compute a route to that next hop
4. The trampoline node builds a new outer onion for the computed route, embedding the peeled trampoline onion in the last hop’s payload
5. This process repeats at each trampoline hop until the payment reaches the destination
6. Non-trampoline intermediate nodes relay standard HTLC packets and are completely unaware of the trampoline infrastructure

Nested onions: Trampoline payloads identify the next node by node_id rather than short_channel_id. This means the trampoline destination does not need to be a direct peer of the current node. The trampoline node fills in the actual channel-level hops using its own graph knowledge.

What the sender needs to know

A trampoline-enabled wallet only needs to store its own channel state and a short list of known trampoline nodes (public keys and connection information). This reduces the required data from tens of megabytes to a few kilobytes. The wallet does not perform graph synchronization, does not run Dijkstra’s algorithm over thousands of edges, and does not need to track fee policy changes across the network.

The Privacy Model

Privacy is the critical tradeoff in trampoline routing. In standard source-routed Lightning payments, the sender knows the full path but each intermediate node only sees its immediate predecessor and successor. Trampoline routing changes this equation because trampoline nodes gain additional information about the payment.

Single-trampoline privacy

When a wallet routes through a single trampoline node (the simplest configuration), that node learns both the sender and the final recipient. ACINQ has acknowledged this directly: in this mode, the trampoline node has visibility comparable to a custodial wallet operator, minus the ability to steal funds.

Multi-trampoline privacy

By chaining two or more trampoline nodes, the sender can break the information link. Each trampoline sees only the previous and next trampoline hop, not the full chain. The first trampoline knows the sender but not the final recipient. The last trampoline knows the recipient but not the original sender. This provides privacy properties closer to standard source routing.

The sender can also add dummy trampoline hops to increase the anonymity set, or include standard (non-trampoline) hops before the first trampoline node to further obscure the payment origin.

Blinded paths: a major improvement

The introduction of blinded paths through BOLT 12 Offers significantly improves trampoline privacy. When a recipient constructs a blinded path, even a single trampoline node cannot determine the final destination. The trampoline forwards the payment into the blinded route without knowing who is at the end. Phoenix wallet added BOLT 12 support in version 2.3.1 (July 2024), making this the default for Offers-based payments.

Privacy comparison: With BOLT 12 blinded paths, single-trampoline routing achieves privacy comparable to multi-trampoline chains for the recipient side. The trampoline still knows the sender, but the combination of blinded paths and trampoline routing closes the most significant privacy gap in the original design.

Implementation Status Across Lightning

Trampoline routing does not yet have a formal BOLT number. It exists as an open proposal in the lightning/bolts repository under PR #829, authored by Bastien Teinturier. Despite remaining unmerged as a formal specification, it is deployed in production by multiple implementations.

The limited adoption across implementations creates a bootstrapping problem. Multi-trampoline routing requires multiple independent trampoline nodes running different implementations. With only Eclair in production, ACINQ’s node is currently the sole trampoline relay, creating a temporary centralization point.

Phoenix Wallet: Trampoline in Practice

Phoenix, developed by ACINQ, is the primary consumer-facing wallet using trampoline routing. It runs a real Lightning node on the user’s phone (based on lightning-kmp, ACINQ’s Kotlin multiplatform Lightning implementation) but does not sync or store the network graph.

How Phoenix sends payments

When a Phoenix user initiates a payment, the wallet constructs a trampoline onion with ACINQ’s node as the designated trampoline. The payment may be split across multiple channels using multipath payments (MPP). ACINQ’s node aggregates the parts and computes the route to the final destination.

Fees follow a structure of 1 satoshi base plus 0.01% proportional, multiplied by an estimated hop count (worst case 10). Since version 1.2.0, Phoenix uses an adaptive fee strategy: it starts with low fees and retries with progressively higher fees on failure, avoiding overpayment on well-connected routes.

Phoenix also uses splicing for channel management, allowing it to resize channels on the fly without closing and reopening them. Combined with trampoline routing, this eliminates two of the biggest pain points in mobile Lightning: graph sync and channel lifecycle management.

Alternative Approaches for Mobile

Trampoline routing is not the only strategy for making Lightning work on mobile devices. Several alternative approaches address the graph sync problem from different angles.

Rapid Gossip Sync (LDK)

Rapid Gossip Sync (RGS) takes the opposite approach to trampoline routing: instead of delegating pathfinding, it compresses the graph data so that mobile clients can download and process it locally. A server pre-processes gossip data, strips cryptographic signatures (which account for roughly half the message size), deduplicates updates, and serves the result as a compact binary snapshot.

According to LDK’s measurements, this compression reduces the full graph from approximately 53 MB to about 4.7 MB uncompressed (roughly 2 MB after gzip). Incremental updates for a 2-hour gap are around 500 KB. The wallet performs pathfinding locally, meaning the server never learns payment destinations. The tradeoff is that the device still needs to run route computation, which consumes CPU and battery.

Server-assisted routing

Some wallets use a Lightning Service Provider (LSP) model where a server assists with or fully handles routing. Breez wallet originally operated this way, with its LSP handling channel creation, inbound liquidity, and route computation. Breez has since moved to a “Nodeless SDK” architecture that replaces Lightning channels entirely with Liquid submarine swaps, sidestepping the routing problem altogether.

LNsync (Blockstream)

Blockstream developed LNsync as a gossip synchronization tool for Core Lightning nodes. It uses a historian plugin to collect, deduplicate, and store gossip messages. Nodes query for changes since a specific timestamp, receiving only the delta. This reduces catch-up bandwidth significantly but still requires the client to store and process the full graph.

Recent Developments

Trampoline routing has seen significant implementation progress in 2024-2025, even as the formal specification remains unmerged.

2024 milestones

• Phoenix v2.3.1 (July 2024) added BOLT 12 Offers support, enabling blinded paths that prevent the ACINQ trampoline node from learning payment destinations
• Eclair PR #2811 enabled blinded paths for ultimate receivers in trampoline payments
• Eclair PR #2810 expanded trampoline routing information capacity beyond the previous 400-byte limit
• LDK PRs #2756 and #3446 added trampoline routing packet support and integrated trampoline flags into BOLT 12 invoices

2025 milestones

• Eclair PR #3109 extended attributable failure support to trampoline payments, allowing senders to identify which node caused a routing failure
• LDK PR #3670 added support for handling and receiving trampoline payments, a significant step toward cross-implementation compatibility
• Phoenix returned to the US App Store on April 8, 2025, after its removal in May 2024

Tradeoffs and Limitations

Centralization risk

The most significant concern with trampoline routing today is centralization. With ACINQ operating the only production trampoline node, Phoenix users depend entirely on a single entity for pathfinding. If ACINQ’s node goes offline, Phoenix payments stop working (though funds remain safe in user-controlled channels). This is not inherent to the design: it reflects limited cross-implementation adoption. As LDK and potentially LND add trampoline support, independent trampoline nodes can emerge.

Fee overhead

Trampoline nodes provide a service (pathfinding and forwarding) and charge for it. Since the sender does not know the actual route, it must reserve enough fees to cover worst-case scenarios. Phoenix mitigates this with adaptive fee strategies, but trampoline payments typically incur slightly higher fees than payments where the sender computes an optimal route directly. The convenience premium is the cost of not maintaining the graph.

Specification fragmentation

After more than six years, trampoline routing remains an unmerged proposal. The specification lives in BOLTs PR #829 with active discussion, but without formal BOLT status, other implementations have limited incentive to prioritize it. LND’s tracking issue has remained in “brainstorming” status since 2022. This creates a chicken-and-egg problem: multi-trampoline routing needs multiple implementations, but implementations wait for a finalized spec.

Beyond Routing: Eliminating the Problem Entirely

Trampoline routing, Rapid Gossip Sync, and LSP-assisted models all share a common assumption: that payments travel through a payment channel network requiring route computation. Spark challenges this assumption by eliminating routing altogether. Spark transfers do not traverse a network of channels. Instead, ownership of Bitcoin is transferred directly between users through key rotation on statechains, with operators facilitating the cryptographic handoff via FROST threshold signatures.

This architectural difference means a Spark wallet has no graph to sync, no routes to compute, and no routing fees to estimate. Payments settle instantly regardless of network topology because there is no network topology to navigate. For mobile wallets, this is a fundamentally different starting point: the complexity that trampoline routing works around simply does not exist.

Spark also maintains full Lightning compatibility. Users can send and receive Lightning payments from their Spark balance through Spark Service Providers, which handle the Lightning-side routing transparently. The mobile wallet experience remains simple while interoperability with the broader Lightning ecosystem is preserved.

Looking Ahead

The mobile Lightning problem is real, and the ecosystem is addressing it from multiple directions. Trampoline routing offers an elegant delegation model that keeps payments non-custodial while removing graph requirements from mobile clients. Rapid Gossip Sync preserves local pathfinding at the cost of some bandwidth and CPU. And newer protocols like Spark bypass the routing layer entirely.

For developers building mobile Lightning wallet experiences, the choice depends on priorities. Trampoline routing is battle-tested in Phoenix and ideal when zero graph storage matters most. RGS suits wallets that prioritize privacy and can tolerate a small download. Spark offers the simplest mobile integration for teams willing to adopt its statechain model. Developers can explore the Spark SDK documentation to evaluate whether a routing-free architecture fits their use case.

What all these approaches share is a recognition that the status quo of full-graph mobile nodes does not scale. The question is no longer whether mobile wallets need help with routing: it is which form of help best serves users.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.