RGBDEX Integration with LSPS1 and LSPS2, and LSP Network Topology: A Learning Note

This article is a product-side integration record of how Stash Labs integrated the RLN LSPS1 and LSPS2 APIs provided by Bitlight Labs. It shares our product progress and some thoughts on future directions with the community. It is not a firm commitment for production delivery, only a learning note.

Introduction

For a user, the ideal Lightning experience is "scan, pay, receive", with no need to know the words channel, capacity, or lease term.

For an LSP, the ideal platform experience is "register a capability, set a price, take orders, settle", with no need to understand the complex protocol mechanics behind it.

RGBDEX's LSP feature turns both of these into the same clean interface.

1. Start With the Product: What an LSP Is on RGBDEX

The LSP page on RGBDEX is itself a liquidity marketplace, where users compare and buy directly.

• Providers register capabilities, set fees, and publish node information and rentable capacity.
• Users browse providers, compare fees, capacity, ratings, and success rates, then decide whom to rent a channel from or which provider to request a JIT invoice from.
• The platform handles registration, review, display, and order reconciliation.

This list is the product's front door. What users see here is "how much capacity this LSP has, what it charges, how it is rated, and whether it works right now"; the protocol specification stays behind the page. Try it: https://test.rgbdex.net/lsp.html

---

2. What Is the Value of Becoming an LSP? Our Conclusion: BTC and RGB Can Earn While Self-Custodied

Before Lightning, BTC had almost no yield-bearing product. There was no on-chain lending contract that could safely custody both sides of a reserve, and centralized yield products required handing over the asset. For most BTC, the only destination was a cold wallet: safe, but completely idle. The price holders paid for safety was return — the more reassuring the asset, the less cash flow it produced.

Lightning changed more than payment speed. It turned liquidity itself into a sellable resource:

• a receiver needs inbound capacity to be paid, and a payer needs outbound balance to pay;
• balances on each side of a channel are finite and directional, so whoever locks capital on the right side provides a path for someone else's payment;
• the party that provides that path charges routing fees and channel-opening fees, while the capital never leaves its own node.

The key point: this business does not require handing the principal to anyone. Unlike depositing BTC into a centralized yield product or an on-chain contract pool, an LSP keeps its assets in its own node channels. The income comes from providing liquidity services, and custody always stays with the holder. In other words, self-custody and liquidity income can hold at the same time for the first time — that is the change Lightning brings to BTC holders.

2.1 How Big Is the Potential of This Business?

Based on industry statistics and operating estimates, a technically capable LSP can reach roughly 2.5%–4% annualized revenue on its BTC capital through channel services, JIT channel opening, and liquidity pricing. For early-stage risk assets such as RGB, where asset supply is scarce, channels require the LSP to advance dedicated asset inventory, and the set of serviceable counterparties is smaller, estimates can reach 10%–30% annualized.

Three points need to be clear:

• These are estimates for reference only. Actual results depend on capital size, directional channel balance management, on-chain channel open/close costs, and real counterparty demand;
• The high RGB range corresponds to high risk and low liquidity: asset price volatility, asset roster and path constraints, and unstable demand can all push actual revenue noticeably above or below the range;
• Every return assumes someone actually needs that channel. Capacity nobody uses only turns into a cost.

The direction, however, is clear: on the RGB Lightning Network, BTC and RGB can no longer only be "stored" — they can keep generating cash flow while staying self-custodied.

2.2 Why the LSP Becomes the Most Important Layer of the Ecosystem

Put the two facts above together and the LSP's position becomes hard to replace:

• It is the entry point for all capital. To receive an RGB asset, a user first needs inbound capacity that carries that asset; without the LSP advancing the reserve on the other side, even a complete asset roster cannot be turned into a channel that can receive.
• It is where capital, pricing, and risk meet. Capacity is priced by time, JIT by payment, RGB by asset, and risk premium is also priced and diversified here, borne jointly by the market's many participants.
• It is where network effects come from. One LSP only serves its own counterparties; once several LSPs form a network, the value of a single channel can be reused by the whole ecosystem.

That is exactly why the LSP sits at the bottom of the RGB Lightning ecosystem, with the AMM and order book built on top of it. The channel market answers "can money get in"; only with money that can get in do the order book and AMM become meaningful.

2.3 The Goal: Let Non-Technical Users Capture This Return Too

The annualized ranges above carry an implicit precondition: you need to be able to run a node, manage directional channel balances, account for on-chain channel open/close costs, and close inefficient channels in time when demand disappears. That is a technical barrier, largely unrelated to capital size. Today this return belongs only to the very few who can operate their own nodes; the vast majority of holders are locked outside.

Stash Labs' goal is to remove that barrier:

• users should be able to let their BTC and RGB assets supply liquidity through LSP services without running a node or understanding channel directionality;
• providers should not need to understand the complex protocol mechanics or build their own operations backend — registering a capability, setting a price, and processing orders is enough;
• the platform custodies neither side's funds; it only turns "who has liquidity, who needs liquidity, and at what price" into an interface that is comparable, tradable, and accountable.

2.4 Why RGB Is Better Suited to an LSP Network

RGB uses client-side validation: asset state is maintained locally by holders, and only cryptographic commitments are left on-chain. It has no global contract state like Ethereum, so there is no "public pool" that can custody both sides of a reserve either.

This leads to a direct product conclusion:

Traditional LP: users deposit assets into an on-chain contract -> the on-chain contract controls the funds
LSP: the LSP provides liquidity from its own node and channels -> the platform matches and displays

So on RGBDEX, liquidity comes from a network of independent nodes, and the platform balance sheet does not play that role. The platform's value is making this network discoverable, comparable, and tradable, while leaving funds with their respective holders.

---

3. Where the Underlying Capability Comes From: Built on Bitlight Labs' RLN

LSPS1 and LSPS2 originate from the Lightning community (bLIP-51 / bLIP-52) and are implemented by Bitlight Labs in RLN in combination with the RGB protocol. RGBDEX's LSP product connects exactly to this capability layer and turns it into a service that can be registered, priced, and purchased inside RGBDEX.

Division of work in this article	Provided by	What it does
Protocol implementation and node capability	Bitlight Labs (RLN: RGB Lightning Network node)	LSPS0 transport, LSPS1 channel orders, LSPS2 JIT quotes and invoices, RGB channels and asset state
LSP marketplace and operations surface	Stash Labs / RGBDEX	Capability registration, pricing and review, public listings, order reconciliation, wallet-signed receipts, platform grants

LSPS0's transport layer runs over the peer-to-peer connections between Lightning nodes, and an HTTP request in a browser cannot do that job. This technical detail matters a lot to the product: the wallet itself has to be a Lightning node, or embed one, to send LSPS requests. RGBDEX's interface hides that complexity behind the wallet and the cloud node; users only click "buy" or "create invoice".

---

4. One Capability, Two Ways to Sell It: LSPS1 and LSPS2

On RGBDEX, a provider registers one capability called Channel Capacity, and LSPS1 and LSPS2 are two delivery modes under that same capability. Both can be enabled at the same time:

	LSPS1: rent a channel in advance	LSPS2: JIT instant channel
When the user pays	Pays first, then the LSP opens the channel	Invoice first; the channel opens only when payment arrives
Best for	Stable, predictable receiving	First-time receiving, low-frequency receiving, receive first and decide later
Pricing basis	Channel capacity + lease term	Per-payment amount (proportional fee + minimum fee)
Channel shape	Announceable, leased, configurable confirmation count	Zero-confirmation, unannounced, private
What the user gets	Deterministic inbound capacity for a period	An invoice that can be paid right now

They live in one capability because the provider is actually selling the same thing: inbound liquidity. Only the delivery time differs.

LSPS1: Rent Capacity Out by Time

The product language of LSPS1 is "rent". In the capability settings, providers set a capacity fee, a lease term, and the balance range this channel is allowed to hold; the system then decides whether the channel stays or goes based on whether the lease term has expired.

These settings eventually become the quote terms users see on the public LSP page. Users do not need to understand the internal channel parameters; they only need to know "how long this channel can be rented and how much it costs in total".

LSPS2: Push Channel Opening to the Moment Payment Arrives

The product language of LSPS2 is "invoice first, channel later". Providers mainly configure two things: what proportion of each payment they charge for opening the channel (including a minimum fee), and what range of payment amounts they are willing to accept.

The most easily misunderstood point here: creating an invoice does not open a channel immediately. When the user receives the invoice, the channel count is still 0; only when the payer's HTLC reaches the LSP does the LSP intercept the payment, open a zero-confirmation channel, and forward the funds to the payee. The SCID in the invoice points to a channel that has not been opened yet — it has only reserved an alias on the invoice.

For users, this leads to two conclusions they can actually feel: JIT invoices have a validity window, so an expired one needs a fresh quote; and an unpaid invoice temporarily ties up liquidity the LSP has already set aside, so providers have to limit how many can be outstanding at once and reclaim the long-unpaid ones in time, in order to keep serving the next user.

The User Side: What Alice Sees

When Alice opens an LSP detail page, she sees one capability card and three kinds of actions:

• Rent BTC inbound channel / Rent RGB inbound channel: rent a channel through LSPS1;
• Open BTC JIT Invoice / Open RGB JIT Invoice: generate a JIT invoice through LSPS2;
• Connect node and Open channel: connect her own node to the LSP, or open a channel manually.

The LSPS1 purchase dialog first asks the user for capacity and lease term. The page states it plainly: browsing and quoting only read the LSP's seller configuration and never touch the user's node; Stash Wallet opens only when the order is confirmed.

The quote page breaks the cost into Fee, Channel starting balance, Amount to pay, lease term, and protection deadline. The product explicitly says "the starting balance belongs to the user's own channel balance and is not counted as a platform fee", so users do not mistake it for a platform charge.

RGB channel rental adds one more step: choosing the asset. The page explains that the LSP advances the asset on the other side of the channel and charges annual rent, and the quote lists both LSP-funded asset and Asset rent. This matches the product boundary: what the user rents is the right to use an asset channel for the lease term, while the asset itself still belongs to its holder.

LSPS2 is simpler: the user only enters how much they want to receive, and the page shows the estimated LSP fee and the invoice validity period. Only clicking Create JIT Invoice opens the wallet; the channel is still 0 at invoice time, and the LSP opens it only when payment arrives.

RGB JIT, by contrast, asks the user for the amount of the asset to receive; the system works out the BTC carrier amount and the channel fee cap automatically, and notes that the final quote is subject to the wallet.

Throughout this whole user flow, users never run into protocol-level terminology and do not have to care how a channel lease term is converted. The product translates protocol parameters into capacity, fee, lease term, and validity period, and leaves the signing action to the wallet.

---

5. Operating an LSP: From Configuration to Settlement

Entering the LSP Console in the personal center, a provider sees their own business dashboard: status, rating, earnings, node pubkey, plus capabilities, orders, liquidity, and channels, all managed in one place.

5.1 Configure the Capability

Clicking "Edit configuration" re-runs the review wizard. Changing prices, balance range, lease term, or JIT parameters always creates a new capability pending review first, and replaces the live quote only after it is approved.

5.2 View LSPS1 Orders

The LSPS1 order list maps directly to the RLN node's order states: completed, awaiting payment, opening channel, failed, and "undetermined".

"Undetermined" is a state that must be taken seriously in LSPS1: when the wallet does not return an order result, the platform keeps a record pending reconciliation, and settles the state only after the wallet receipt confirms it. Retrying an order can open two channels, and that is worse than being a little slow.

5.3 View the LSPS2 JIT Ledger

LSPS2 has no node-side order list, so RGBDEX records one ledger entry for every JIT payment and reconciles them one by one.

This table answers the questions providers care about most: how many JIT invoices have I issued, how many of them have been paid, how much opening fee did each one earn, and how long do the invoices remain valid.

5.4 Manage Liquidity and Channels

Below the capability list are the real asset and channel views. Liquidity comes from the LSP's own node balance; editing liquidity means re-declaring the serviceable amount.

5.5 Public Presentation

The provider's public page shows capabilities, prices, node information, ratings, and channel status together, and users can start a purchase right there.

---

6. Authorization Boundaries: What the Platform May Operate

RGBDEX divides nodes into two kinds:

• User nodes: the platform must not call them, and must not proxy operations on them. All reads and writes are initiated directly by Stash Wallet in the user's session, and the backend only receives wallet-returned data or signed receipts, then verifies, validates, and records them.
• LSP nodes: the platform may operate them within the scope of an authorization signed by the wallet. That authorization is limited to an API allowlist, has a validity period, can be revoked at any time, and only covers seller-side endpoints.

Operations that move money cannot be covered by long-lived authorization; every single one must be signed by the wallet on the spot. When placing an LSPS1 order, the wallet reads the buyer's node and produces a signed receipt; the platform checks that receipt against the LSP seller node's order ledger, and the read access to the buyer's node always stays with the user.

For users, this boundary comes down to one sentence: the platform can help you display and match, but the moment money moves or your node is read, it has to go through your wallet.

---

7. Topology Evolution: From One Channel to a Network

LSPS1 and LSPS2 only define how "a user and an LSP" interact; they say nothing about how LSPs connect to each other. Once there is more than one LSP in the network, the question changes from "how do I open a channel" to "how does money reach the payee".

7.1 Four Stages

Stage	What it solves	Cost	When to move to the next stage
Direct links	Simple and controllable	Unmaintainable once counterparties grow	Channel count exceeds the team's operating capacity
Single ring	Fewer channels	One edge failure forces many paths to detour	Redundancy and failover are needed
Dual hub	Lower onboarding cost for small LSPs	Liquidity concentrated in the hubs	The hub becomes a traffic and liquidity bottleneck
Core mesh / hybrid	Less pressure on hubs, more redundancy	High capital and operational cost	Large-LSP traffic is enough to support direct links

Direct Links: A Channel Between Every Pair of LSPs

Four LSPs need six channels; generalizing to N LSPs gives N × (N - 1) / 2. The good part is short paths and controllable state; the bad part is that every extra counterparty pushes operations and tied-up capital up linearly.

Single Ring: Connect All LSPs Into a Loop

Four LSPs need only four channels, fewer than full direct links. But any two points can only travel around the ring, so when one edge goes bad, many paths have to switch to the other side, and capacity and latency get worse together.

Dual Hub: Small LSPs Connect Through Two Hubs

Small LSPs no longer connect to each other pairwise; joining a hub is enough. Onboarding cost comes down, but traffic and liquidity drift toward the hubs; the primary link between Hub-A and Hub-B decides whether failover means anything at all.

Core Mesh / Hybrid: Direct Links at the Core, Hubs at the Edge

Large LSPs keep direct links and redundancy through a Partial Mesh, while small LSPs keep connecting through hubs. This solves both "the core needs capacity and failover" and "the edge needs low onboarding cost" at once, at the price of the highest operational complexity.

7.2 Topology From a Product Perspective

Topology directly affects the product experience, and its value goes far beyond drawing a nice diagram:

• Discovery: can users find an LSP that has capacity and a suitable fee in the list?
• Quotes: can the capacity, lease term, and JIT fee of different LSPs be put side by side?
• Directionality: "has balance" does not mean "can pay in this direction"; every hop needs the right outbound balance and inbound capacity;
• Failover: when one hub runs out of money, the other path has to actually have usable balance; a line drawn on a diagram provides no liquidity by itself.

The shape that is stable in reality is usually the fourth: hubs at the edge to lower the onboarding barrier, and a Partial Mesh at the core to provide redundancy and capacity. For RGB there is one more constraint: every hop along the path must carry the corresponding asset, so "has BTC liquidity" does not mean "can complete an RGB payment".

7.3 The Real Difficulty of Dual Hubs

The key value of dual hubs is that the two hubs' liquidity states are not synchronized. If both are always drained on the same side by the same payees, the failover path still exists, but neither path has money.

The handling order goes from cheap to expensive:

1 reroute -> 2 rebalance -> 3 adjust capacity budget -> 4 close inefficient channels

This is also why the LSP Console shows "channels" and "liquidity" separately: channel count represents the scale of supply, while directional balance is what decides availability.

---

8. Next: From a Channel Market to a Trading Market

The LSP network is where RGBDEX's liquidity comes from, and the starting point toward a bigger product picture. The product roadmap moves forward along "form a market first, then connect the ecosystem":

1. FlashDEX order book: first let RGB assets form price and depth in an order book;
2. AMM Swap: once market liquidity is established, use curve pools to take on more continuous exchange demand;
3. Unified quote interface and RFQ adaptation: wrap the quotes of the FlashDEX order book and AMM Swap into a common interface and adapt it to the RFQ implemented by Bitlight Labs, so wallets, market makers, and other ecosystem applications can get quotes and execution paths through the same interface. Only then can Stash Labs' products move toward openness and supply liquidity for the whole ecosystem;
4. LSP capability as infrastructure: further study how to open LSP capability up from an internal RGBDEX product into ecosystem-accessible LSP liquidity infrastructure, so other wallets and trading scenarios can reuse it too.

---

References

• bLIP-50 / LSPS0: Transport Layer
• bLIP-51 / LSPS1: Channel Requests
• bLIP-52 / LSPS2: JIT Channel Negotiation
• Bitlight Labs: Lightning RGB: Building an LSP for RGB Assets
• Stash Labs: Lightning Network Service Providers