Rapid Gossip Sync (RGS)

What Is Rapid Gossip Sync?

Rapid Gossip Sync (RGS) is a protocol developed by the Lightning Dev Kit (LDK) team that allows Lightning Network clients to synchronize the channel graph efficiently using a semi-trusted server. Instead of connecting to peers and processing every gossip message individually, a wallet downloads a single compressed binary snapshot containing only the changes since its last sync.

The Lightning Network relies on a gossip protocol to distribute information about available payment channels. Every node broadcasts channel announcements, channel updates (fee policies, disabled states), and node announcements. A fully synced node needs this data to find payment routes. For always-on routing nodes, processing gossip continuously is manageable. For mobile wallets that open intermittently, it is a serious bottleneck.

RGS solves this by moving the heavy processing to a server. The server maintains a full gossip database, validates all announcements against the blockchain, computes compact binary diffs, and serves them to clients on demand. The client gets an up-to-date network graph in a fraction of the time and bandwidth that peer-to-peer gossip sync would require.

How It Works

RGS operates as a client-server system with clearly separated responsibilities. The server handles validation and compression. The client handles deserialization and pathfinding.

Server-Side Processing

1. The RGS server connects to Lightning Network peers and continuously monitors all gossip messages: channel announcements, channel updates, and node announcements
2. Each gossip message is timestamped and persisted to a PostgreSQL database
3. The server validates channel announcements against the Bitcoin blockchain, confirming that the referenced UTXO actually exists
4. At regular intervals (typically every 24 hours), the server computes static delta snapshots covering all changes within that window
5. Cryptographic signatures are stripped from the data before serialization, since the server has already validated them

Client-Side Sync

1. The client sends a request with a last_sync_timestamp indicating the most recent snapshot it has applied
2. The server returns a compact binary payload containing only the changes since that timestamp
3. The client calls update_network_graph() with the binary data, which deserializes the snapshot and applies all updates to the local graph
4. The function returns a new timestamp for the next sync request

Binary Format

The RGS binary format is optimized for size through several techniques:

• Short channel IDs are sorted and expressed as incremental deltas from the previous ID, using variable-length integer encoding (CompactSize) so most IDs take fewer than 8 bytes
• Channel updates use server-calculated default values for common fields. Only non-default or changed fields are transmitted, with bit flags indicating which fields are present
• If a channel update only changes one property (such as the base fee), only that property is included in the delta
• Global properties like the genesis block hash are sent once rather than repeated per channel

A typical sync request to the reference server looks like this:

GET https://rapidsync.lightningdevkit.org/snapshot/<last_sync_timestamp>

# Response: compact binary blob
# Apply to the network graph:
let rgs = RapidGossipSync::new(network_graph, logger);
let last_sync = rgs.update_network_graph(&response_bytes)?;
# last_sync is a u32 timestamp for the next request

Trust Model

The RGS server is considered semi-trusted. Understanding what the server can and cannot do is important for evaluating the security tradeoffs.

What the Server Cannot Do

The server cannot fabricate channel announcements. Before stripping signatures, the server validates each channel announcement against the Bitcoin blockchain, confirming the referenced funding transaction exists at the claimed UTXO. Fabricating a channel would require creating a valid on-chain funding transaction, which costs real bitcoin. This means the graph data a client receives represents channels that actually exist (or existed) on-chain.

What the Server Can Do

A malicious or compromised RGS server can degrade the client's experience in several ways:

• Omit channels it has seen, giving the client an incomplete graph that may cause pathfinding failures or force payments through specific routes
• Omit channel updates, leaving the client with stale fee policies or capacity information that leads to failed payment attempts
• Include channels with contradictory information, potentially bloating the client's graph and consuming memory

These are denial-of-service attacks, not fund theft. The worst outcome is degraded routing, not lost funds. For most mobile wallet users, this tradeoff is acceptable compared to the alternative of not being able to route payments at all.

Why It Matters

Before RGS, mobile Lightning wallets faced a difficult choice. They could perform full gossip sync, which meant downloading approximately 53 MB of data and processing hundreds of thousands of messages on every app open. This took minutes on a good connection and drained battery. Or they could delegate routing entirely to a Lightning Service Provider (LSP), which meant the LSP could see payment destinations and amounts.

RGS provides a middle path. The wallet downloads roughly 2 MB of compressed data and applies it in under 0.4 seconds. It then has enough graph information to compute routes locally, preserving onion routing privacy. The RGS server sees that the wallet synced, but it does not learn which payments the wallet sends or receives.

This approach makes self-custodial mobile Lightning wallets practical for everyday use. Without efficient graph sync, mobile nodes would either be too slow to use or would sacrifice the privacy guarantees that make Lightning's onion routing valuable. For a deeper look at how mobile wallets handle these constraints, see the research on Lightning mobile wallet architecture.

Use Cases

Mobile Lightning Wallets

The primary use case for RGS is mobile wallets built on LDK. These wallets run a lightweight Lightning node on the user's phone and need an up-to-date network graph to find payment routes. Wallets that have used or currently use RGS include Bitkit and Zeus (via LDK integration). Mutiny Wallet, which ceased operations in 2024, was a notable early adopter that modified the default sync interval from 24 hours down to 1 hour for faster updates.

Resource-Constrained Nodes

Any Lightning node that cannot maintain persistent peer connections benefits from RGS. This includes nodes running on low-power hardware, nodes behind restrictive firewalls, or embedded devices with limited bandwidth. Rather than maintaining gossip connections to multiple peers, these nodes can periodically fetch a snapshot and apply it.

Initial Node Bootstrap

Even nodes that will eventually switch to full peer-to-peer gossip sync can use RGS for initial bootstrap. A new node can download a single snapshot to populate its graph immediately, then transition to standard gossip for ongoing updates. This eliminates the long initial sync period that would otherwise prevent the node from routing payments.

Comparison to Alternatives

Full Peer-to-Peer Gossip Sync

Standard gossip sync, defined in BOLT 7, requires nodes to connect to peers and exchange gossip messages. The node must download and validate every channel announcement and update individually. For a desktop node running 24/7, this is fine: gossip arrives incrementally and the node stays current. For a mobile wallet opening after hours or days offline, the backlog can be tens of megabytes and take minutes to process.

Trampoline Routing

Trampoline routing takes a fundamentally different approach: instead of giving the client a full graph, it lets the client delegate pathfinding to intermediate "trampoline" nodes. The client only needs to know about nearby nodes and can specify high-level routing waypoints. This eliminates the need for graph sync entirely but requires trampoline-capable nodes along the route and reveals more routing information to those nodes.

RGS and trampoline routing are complementary rather than competing. RGS provides efficient graph sync for clients that want to compute routes locally. Trampoline routing eliminates the need for graph knowledge altogether. A wallet could use RGS when connectivity allows and fall back to trampoline routing when it cannot sync.

Risks and Considerations

Server Dependency

RGS introduces a dependency on a centralized server. If the RGS server goes offline, the client cannot sync its graph. While the wallet can still attempt payments using its last-known graph, stale data leads to higher failure rates as channels open, close, and update their fee policies. Running alternative RGS servers or falling back to peer-to-peer gossip mitigates this risk.

Graph Staleness

Because snapshots are computed at intervals (typically 24 hours), the graph data is on average 12 hours behind the current network state. Channels that opened or closed in the last few hours will not appear in the snapshot. For most payments this is acceptable, but for time-sensitive or high-value routing it can increase failure rates. Some implementations use shorter intervals: Mutiny Wallet used 1-hour snapshots at the cost of higher server load.

Privacy Considerations

The RGS server learns the client's IP address and sync frequency but does not learn payment details. This is a significant improvement over delegating routing to an LSP, where the service provider sees payment destinations. However, sync patterns could theoretically reveal when a user is about to make a payment. Using Tor or a VPN to connect to the RGS server mitigates IP-level tracking.

Stripped Signature Trust

Because the server strips signatures before sending data, the client cannot independently verify that the gossip messages were properly signed. The client trusts the server's prior validation. If the server software has a bug in its validation logic, malformed data could propagate to clients. This is the core tradeoff of the semi-trusted model: bandwidth efficiency in exchange for reduced verification at the client.

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.