Lightning RGB: Building an LSP for RGB Assets

Introduction: The Barrier to Instant Receiving

Lightning gives RGB low-fee, instant payments, but it also introduces new concepts and hurdles. Every Lightning payment happens inside a channel: both parties first lock funds into the channel, and every payment afterwards simply moves balance between the two sides. How much you can receive therefore depends on how much balance sits on the other side, ready to move toward you. This is the unfamiliar prerequisite a new user meets the first time they try to receive over Lightning: inbound liquidity. And it is exactly what a new user lacks. They would need to find someone to open a channel with them and understand how channel funds work before they can start receiving over Lightning. Early Lightning BTC users were blocked by the same problem.

The Lightning community's answer is the LSP (Lightning Service Provider): professional nodes package liquidity into a service that can simply be purchased. Users place an order and skip the complexity.

We are bringing this answer to RGB assets.

LSP Is Already an Industry Standard

The Lightning community has standardized LSPs into a set of specifications, published as bLIPs:

• LSPS1 (bLIP-51): Channel Requests. The user places an order and pays; the provider opens the channel.
• LSPS2 (bLIP-52): JIT Channels. The user authorizes the provider to handle an incoming payment; the provider intercepts it, deducts the service fee, opens a channel just in time, and the user receives the payment through that channel.

LSPs have been serving BTC users in production for years, and these standards are distilled from that practice. A common standard makes it easy for users to choose among providers, and keeps the services interoperable.

But these standards currently only cover BTC. Once a channel carries RGB assets, there is no standard answer for pricing asset capacity or expressing asset orders. That is the gap we are filling.

RGB-LDK-Node 0.0.9: Bringing the LSP into RGB Lightning

Built on RGB v0.12, our RGB-LDK-Node 0.0.9 is implementing the LSP server side, starting with LSPS1, together with an RGB extension of the protocol. From the user's perspective, the whole flow is four steps:

Once this ships, users can:

Buy channels directly. Whether it is a BTC channel or one carrying RGB asset inbound capacity: from order and payment to an open channel, no channel-management concepts are required along the way.

Buy asset capacity with BTC. When purchasing inbound capacity for an RGB asset, the user always pays in sats. The LSP loads its own assets into the channel as your receiving capacity (essentially leasing them to you), so even with no assets in hand you can receive them over Lightning in seconds.

Fully automated orders and refunds. Every order has a clear deadline: if the channel is not opened within the agreed number of blocks, the payment is refunded automatically, with no human in the loop. Lightning-paid orders are even atomic — we use the HOLD invoice mechanism, so the payment is locked but never settled; it completes only when the channel opens successfully, and bounces straight back if it does not.

Real Channels, Real Exit

Design principle: what the LSP sells you must be a real on-chain channel.

The funding transaction is genuinely broadcast on-chain. Once the channel is confirmed, you hold every right the Lightning protocol grants, including a unilateral force-close at any time, with no one's cooperation required. Whatever state the LSP is in, your assets can still be recovered under on-chain rules.

Users get instant payments and self-custodial security at the same time.

Roadmap

Our planned route, ordered by dependency:

1. LSPS1 + RGB extension (in progress, v0.0.9): direct purchase of channels and asset inbound capacity;
2. Real-time asset quoting: asset capacity pricing moves from static provider price lists to per-order quotes with short validity windows. This is the pricing foundation for the next two steps;
3. LSPS2 + RGB extension (JIT channels): the provider opens the channel at the moment it receives a payment on the user's behalf; a new user can receive assets by simply presenting a payment QR code;
4. Asset purchase: beyond leasing capacity, users purchase the assets themselves from the LSP — still paying in sats.

Technical Overview

The implementation builds on LDK's lightning-liquidity. The RGB extension follows the protocol-extension rules defined by the bLIPs: it extends through new methods without changing any existing LSPS method, combined with standard capability discovery, staying interoperable with the existing ecosystem. The complete protocol proposal will be written up and published once the implementation stabilizes, with running code as the source of truth.

RGB's infrastructure is coming together piece by piece. With basic LN-RGB payment capability in place, the next step is removing the barrier to instant receiving. That is the problem our LSP work sets out to solve.