The short version. Running RGB assets on Liquid works, and we proved it with a small, non-breaking change and exercised it end to end. Moving an existing token between Bitcoin and Liquid can't be a native "teleport," but you get the same result two ways: a trustless atomic swap (no custodian), or a lock-and-mint bridge (one canonical token, but it trusts a federation).
What RGB is, in two layers
RGB is an asset protocol for Bitcoin. What makes it different is that an asset's whole history lives off-chain, held and checked by the people who own it. Only a tiny fingerprint ever touches the blockchain.
That fingerprint is the anchor: every transfer is bound to a real transaction by spending a single-use coin (a "seal") that carries a 32-byte commitment. The off-chain part doesn't care which blockchain it runs on; only the anchor does. That's the whole reason RGB can move to Liquid at all.
RGB runs natively on Liquid
The only thing tying RGB to Bitcoin was a single transaction type in the verification code. Abstracting it took a 207-line, non-breaking change. Every existing test still passes and the rest of the production RGB stack consumes it unchanged. With that in place, all of this works on a test network:
- Real asset transfers on Liquid, using the same tools wallets already run for Bitcoin RGB.
- Confidential transfers: amounts hidden by Liquid, on top of RGB's contract-level privacy.
- Cross-chain atomic swaps between a Bitcoin RGB asset and a Liquid one, with no custodian.
- Faster, cheaper settlement: one-minute blocks and low fees, still fully self-custodial.
What Liquid's smart contracts unlock
Because an RGB seal is just a coin, whatever spending rules the chain can express become rules on the asset. Liquid has Simplicity, a formally verifiable contract language live on mainnet, so the chain itself can enforce how an RGB asset is allowed to move. We demonstrated the first of these; the rest are designs the same primitive makes possible.
Minting LR-USDT, backed and auditable
One concrete use: a dollar on RGB rails, minted only against real backing. Every holder can verify that backing straight from the transaction, with no oracle, no attestation. We built the minting side two ways, and both run today:
Lock demonstrated
Mint by locking native USDt into a vault. The backing is held and redeemable in principle; reserves are the sum of the vault, public in real time.
Burn demonstrated
Mint by destroying the USDt instead of holding it. No vault, no key that can ever move it, so proof-of-reserves becomes proof-of-burn. The trade: a burn returns nothing, so it's a one-way migration.
Minting can even be made permissionless: a Simplicity covenant lets anyone mint, but only in a transaction that locks the backing and anchors the transfer. We proved that too, including the chain rejecting malformed mints. And the backing terms can live inside the contract itself: we built a schema that commits the vault, the asset, and the rate into the token's genesis, so anyone can audit the entire mint history against the chain. An over-mint the chain happily confirmed was caught by that audit, with no oracle anywhere.
Staking, and where it gets hard
The same idea, applied to a locked position. A time-locked staking covenant holds a staked asset until a maturity height and binds it to return to the staker. We built it: the chain refuses to unstake early, refuses to send the principal anywhere but back to the staker, and refuses a spend that skips the RGB anchor. Keyless, and enforced by consensus, not by us.
Time-locked staking demonstrated
Lock now, unstake only after maturity, principal always returns home. The reward for staking is issuance layered on top, the same machinery as minting.
On-chain AMM research
A swap pool is shared, constantly-updated state, which fights RGB's model where each holder validates their own history. It needs a data-availability layer and succinct validity proofs to scale. That is why KaleidoSwap uses a market-maker model instead: continuous liquidity, no shared pool to coordinate.
Can a token move to Liquid and back?
Not by moving the same token, that isn't how RGB works. A token is tied to the chain it was issued on, and a coin can only be spent on the one chain it lives on, so there is no native "teleport." You get the same outcome two ways, with different trust:
Atomic swap demonstrated, round trip
Swap your Bitcoin token for its Liquid twin, and swap back later. Either the trade completes fully or nothing happens, and no custodian. We ran the full round trip: a Bitcoin RGB token and a Liquid RGB token crossed owners and came back, both supplies conserved, every hop verified. This is the approach we ship.
Lock-and-mint needs trust
Lock the token on Bitcoin, mint a backed version on Liquid, reverse to return. Gives one canonical token across chains, but the Bitcoin side can't be covenant-enforced today, so it relies on a federation. A bridge with a trust assumption.
Questions people ask
Is running RGB on Liquid actually possible?
Yes. It's a working proof of concept, open source, run on a test network. The change needed upstream is small and non-breaking, and has been submitted to the RGB maintainers.
Can I take my RGB token from Bitcoin to Liquid and back?
Yes, in effect, via a trustless atomic swap (swap it for the Liquid twin and back, no custodian, needs a liquidity provider). A one-to-one canonical bridge is also possible but currently trusts a federation.
Does a token need two mints to exist on both chains?
With the swap model, yes: two separate tokens, each issued once on its own chain, kept 1:1 by swaps. With the bridge model, no: the token is minted once, and the Liquid version is only minted on demand against the originals you lock, then burned when you come back.
Is my money ever held by someone else?
With atomic swaps, never: the trade is all-or-nothing by construction. With the lock-and-mint bridge, the locked funds sit under a federation, which is the trust you accept for a canonical cross-chain token.
Can you do staking or a swap pool (AMM) on this?
Staking, yes, and it is built: a covenant locks the position until maturity and only ever returns it to the staker, all enforced by the chain. An automated market maker is much harder, because a swap pool is shared live state and RGB keeps state with each holder. It is a research problem that really wants succinct validity proofs. In the meantime a market-maker model gives the same continuous liquidity without a shared pool to coordinate.
Is this live for users?
Not yet. This is engineering R&D on test networks. Liquid and RGB on mainnet are already in the KaleidoSwap browser extension (closed beta); RGB-on-Liquid is a candidate to become one of the trading venues our maker network supports.