Sovereign Trading on RGB Lightning: Walter Maffione Demos the First KaleidoSwap MVP

This article is based on the talk “Sovereign Trading on Lightning Network,” given by Walter Maffione at Plan ₿ Forum 2024.

Before KaleidoSwap settled its first trade on Lightning mainnet, before Spark and Arkade support, there was a regtest demo running on Walter Maffione’s own laptop, showing sovereign trading on RGB Lightning for the first time. In this 2024 Plan ₿ Forum talk, Walter (open-source contributor, later lead developer of KaleidoSwap) walked through the first working prototype of a non-custodial exchange for RGB Protocol on Bitcoin assets: an RGB Lightning node, a modified Lightning Service Provider spec, and a maker-taker swap model streaming live prices over WebSocket.

KaleidoSwap MVP, in brief:

• Built on an RGB Lightning Node, a fork of LDK that adds RGB asset transfers and swaps to a standard Lightning node
• Uses a modified Lightning Service Provider (LSP) specification so an RGB LSP can offer inbound and outbound liquidity for both bitcoin and RGB assets
• Prices are streamed through a request-for-quotation (RFQ) model over WebSocket, not an automated market maker
• Swaps settle as ordinary Lightning HTLCs, so they inherit Lightning’s atomicity guarantees at no extra cost
• The demo ran entirely on regtest, with USDT and Tether Gold as placeholder assets minted by the KaleidoSwap team

Note: RGB Protocol on Bitcoin (rgb.info, v0.11.1) is the production-ready protocol supported by the RGB Protocol Association. It is distinct from RGB-WG (rgb.tech) and from RGB++ (a separate protocol on the CKB chain by Nervos).

Editorial note (2026): This talk documents the earliest public MVP of KaleidoSwap, running on regtest with demo assets and a single hardcoded maker. Much of what Walter described as a near-term plan has since shipped: the free-option problem he doesn’t mention here directly was later addressed through maker reputation, the peer-to-peer order book over Nostr moved from roadmap item to active development, and on September 30, 2025, KaleidoSwap executed its first RGB asset swap on Lightning mainnet, followed by a public launch. See KaleidoSwap: Building a Non-Custodial DEX for RGB Assets on Lightning for the fuller, later stage of the same project, including the mainnet milestone and the expansion to Spark and Arkade.

Key takeaways from this talk:

• KaleidoSwap runs on an RGB Lightning Node, a fork of LDK, exposing a REST API that third-party applications can also use
• An RGB Lightning Service Provider offers inbound and outbound liquidity for bitcoin and RGB assets, extending the standard LSP specification
• Swaps follow a maker-taker model: the maker streams a price, the taker accepts and whitelists the swap string, and the trade settles as a normal Lightning HTLC
• The 2024 build capped trade size at roughly 10% of channel capacity, a Lightning-level HTLC limit rather than an RGB-specific one
• Walter’s stated roadmap included peer-to-peer trading via Nostr, multiple makers, limit orders and stop-loss, and Tor support, all later pursued in some form
• The stated goal from the start: use Lightning not only as a payment layer, but as a trading layer, adding liquidity and connectivity that benefits Lightning users generally, RGB or not

What is KaleidoSwap, and how does it fit into RGB Protocol on Bitcoin?

KaleidoSwap is a decentralized trading application built on top of an RGB Lightning node, giving users a graphical interface to issue, hold, and swap RGB assets over the Lightning Network.

Walter introduced himself as an open-source contributor building KaleidoSwap on top of an RGB Lightning Node, a Lightning node built on a fork of LDK that adds transfer and swap support for RGB assets. At the time of the talk, that node implementation was maintained by the Phoenix and Tether teams, and open to outside contribution.

The node exposes a REST API that third-party applications, not only KaleidoSwap, can call directly. KaleidoSwap itself is described as an open-source desktop dashboard for that node: a user can run a local RGB Lightning node, or connect the desktop app to a remote node running in the cloud, useful since Lightning generally favors an always-online node over one running intermittently on a laptop.

Because the whole stack sits on client-side validation, the desktop app functions as a normal Lightning wallet with RGB assets layered on top: users can open and request channels, generate invoices, send and receive payments, and back up the node to a local file, all standard Lightning functionality extended to carry RGB balances.

What is an RGB Lightning Service Provider, and why does KaleidoSwap need one?

An RGB Lightning Service Provider (LSP) extends the standard Lightning LSP specification so it can offer liquidity in both bitcoin and RGB assets, giving new users a channel that already holds the asset they want to trade.

Ordinary Lightning Service Providers help users join the network by opening channels and providing liquidity, using a common specification that keeps different LSPs interoperable with each other. Walter’s team modified that specification to add RGB asset support: an RGB LSP can offer inbound and outbound liquidity in bitcoin and RGB assets at once, and optionally provide swap services through a separate RGB Lightning DEX API the team built for this purpose.

Work was also underway, at the time of the talk, to unify the modified LSP specification across the different teams building on the RGB Lightning stack, so multiple providers could stay compatible with each other rather than fragmenting the ecosystem.

How do RGB Lightning swaps work?

RGB Lightning swaps follow a maker-taker model: the maker proposes a price and a swap string, the taker accepts and whitelists it, and the trade settles as an ordinary Lightning payment.

Walter walked through the flow step by step. A taker, meaning a KaleidoSwap user, connects to a maker, meaning an RGB LSP acting as liquidity provider, and picks the pair to trade. The maker proposes a price and shares an encoded swap string describing the trade’s conditions. If the taker accepts the price, the taker’s node whitelists that swap string; once whitelisted, the taker asks the maker to execute, and the payment settles as a normal Lightning payment across the two parties’ RGB Lightning channels.

Whitelisting matters here: it tells the taker’s node, in effect, “if an HTLC arrives matching this exact swap, move the corresponding satoshis and RGB assets between these channels; I already agreed to it.” That agreement, set in advance, is what lets the final settlement happen as an ordinary HTLC forward rather than a custom transaction type.

Walter flagged multiple possible transport layers for sharing swap strings between maker and taker: a public WebSocket or REST API (suited to professional market makers, who might eventually need KYC or compliance requirements attached), or direct peer-to-peer node communication, including protocols like Nostr.

How does KaleidoSwap price a swap?

Prices come from a request-for-quotation (RFQ) model, not an automated market maker: the LSP streams live quotes, and the user accepts or requests one directly.

The RGB LSP, acting as maker, streams prices for supported pairs to the client over a WebSocket, denominated in millisatoshis per unit of the RGB asset. Each price update carries an ID, used later to confirm that the price a user is accepting was in fact the one the maker sent. Two paths were available for getting a price: live streaming for lower latency, or a direct quote request to the maker.

Asked in Q&A whether this amounted to an automated market maker model, Walter drew a clear line: KaleidoSwap uses a request-for-quotation model, closer in spirit to an order book than to an AMM curve. The maker streams prices; the user decides whether a given price is acceptable and, if so, accepts it. Today that order book lives with a single maker. Walter described Nostr as the path toward a genuinely decentralized order book, where anyone could post an ask (for example, offering bitcoin at a chosen price) and other users could discover and take that offer, coordinating directly with the poster.

Fees followed ordinary Lightning economics: a base fee plus a percentage of the swapped amount, the same structure as routing fees elsewhere on the network.

What did the live demo show?

The 2024 demo ran on regtest with two RGB Lightning nodes on Walter’s own machine, demo assets minted by the KaleidoSwap team, and a working end-to-end swap of satoshis for a test USDT-like asset.

Walter’s local setup included two RGB Lightning nodes, an implementation of the RGB Lightning DEX API, a Bitcoin Core node, and an Electrum server connecting the RGB node to Bitcoin Core. Channels were already open on one demo account to make the walkthrough smoother.

Once connected to the maker, the app displayed live streamed prices for the supported pair, bitcoin against a placeholder USDT asset, minted locally for the demo rather than pegged to any real issuer (a stand-in, Walter noted, for what a real Tether-issued RGB asset would eventually look like). Supported demo assets were USDT and Tether Gold. The wallet view showed a standard RGB Lightning node: on-chain and Lightning deposits and withdrawals, channel management, and both outbound and inbound liquidity tracked per asset, exactly as with an ordinary Lightning channel’s satoshi balance.

Walter also demoed ordering a new channel from the LSP, useful for a user with no RGB assets yet who wants a channel pre-funded with both bitcoin and a chosen asset. Amounts, asset choice, and even how many blocks the maker commits to keeping the channel open are all configurable at request time, following the LSP specification so the channel stays compatible with non-RGB-aware Lightning LSPs that only implement the base spec.

The trade itself, once channels were in place, executed in a few seconds: a swap of 10,000 satoshis for 6.7 USDT, followed by a second swap into the demo Tether Gold asset. One constraint Walter called out directly: the maximum trade size was capped at roughly 10% of channel capacity, a limit coming from LDK’s maximum HTLC size rather than from RGB itself.

What roadmap did Walter Maffione lay out in 2024?

Several items on the 2024 roadmap track closely to KaleidoSwap’s later development:

• Peer-to-peer trading via Nostr, removing the need to go through an RGB LSP at all, since RGB Lightning channels route like any other Lightning channel even without a direct connection
• Multi-maker RFQ, letting a user choose among several LSPs rather than depend on one
• Limit orders and stop-loss, described as only the beginning of what Walter called Bitcoin finance, built on sovereign, self-custodied keys
• Tor support, for node-level privacy and anonymity
• General UI and UX improvements

Why does this matter for the Lightning Network?

KaleidoSwap’s founding bet is that Lightning can become a trading layer, not only a payment layer, and that the liquidity this attracts benefits ordinary Lightning users whether or not they ever touch an RGB asset.

Walter framed the opportunity in scale terms: Bitcoin sees roughly $2 trillion in yearly volume on centralized exchanges. Routing even a fraction of that onto Lightning, he argued, turns the network into a trading layer as well as a payment layer. Because RGB Lightning channels are still ordinary Lightning channels underneath, they can carry and route payments for regular Lightning users too, increasing overall network connectivity even for people with no interest in RGB assets.

That growth, in turn, creates demand for better liquidity management: channel rebalancing and optimization tooling become more valuable as more capital and more asset types compete for the same channel space, an area Walter flagged as intended for open-source tooling going forward.

Questions to Walter from the audience

A few Q&A exchanges are worth preserving directly:

On the production timeline: Walter tied mainnet availability to two separate audits finishing: RGB Protocol on Bitcoin itself, then still being audited toward mainnet readiness, and the RGB Lightning Node implementation, which needed its own stabilization pass. His estimate at the time: “probably the next year will be the year of RGB lighting swaps,” with testnet first to surface bugs before any mainnet move.

On other asset standards: Asked whether KaleidoSwap would integrate non-RGB asset standards such as Taproot Assets, Walter left the door open in principle, while noting RGB and Taproot Assets are not natively interoperable with each other today.

On the likely trading pair: Asked whether USDT against bitcoin would dominate volume, Walter expected it to be the most common pair, while noting the actual mix depends on which LSPs choose to support which assets, and on what users actually want to issue and trade.

On the pricing model: Asked directly whether the design resembled an automated market maker, Walter clarified the distinction: KaleidoSwap runs a request-for-quotation model. Makers stream prices; users accept or decline them, an order-book-style interaction rather than a constant-product curve. A single maker’s book is the starting point, with Nostr identified as the path to a genuinely decentralized, multi-maker order book later on.

Where KaleidoSwap stands now

This 2024 demo, running on a single laptop with minted test assets, is the direct ancestor of the KaleidoSwap that later executed a real RGB asset swap on Lightning mainnet, launched publicly, and expanded into a multi-layer swap platform spanning Lightning, Spark, and Arkade. For the current state of the project: see KaleidoSwap: Building a Non-Custodial DEX for RGB Assets on Lightning, try the app at kaleidoswap.com, or explore the KaleidoSwap desktop app repository.

To see how RGB Protocol on Bitcoin integrates with Lightning more broadly: start with RGB Protocol on Bitcoin and the Lightning Network, check the current RGB wallets and infrastructure ecosystem, or go deeper in the full technical documentation at docs.rgb.info.

---