RGB channels

An RGB channel assigns an RGB asset to a Lightning funding output and carries the asset’s allocations through successive channel commitments. The Bitcoin transaction enforces who can spend the output. RGB validation establishes which asset state that spend carries.

VOUT implements this in a patched Lightning Development Kit, connected to its RGB runtime through a signer boundary. LDK constructs channel transactions and handles the Lightning state machine. The RGB runtime computes the asset transitions and the commitments those transactions must contain.

This work is separate from transferring an RGB balance between VOUT accounts. An internal transfer changes the custodial ledger. A native RGB channel updates state held by two Lightning nodes. Mainnet currently runs BTC-only channels; the RGB channel implementation has its own test evidence and limitations.

Funding the channel

The opening node starts with an RGB allocation in its on-chain wallet. It builds a funding transaction that moves the selected channel amount onto the channel’s 2-of-2 output and preserves the remainder as change or untouched allocations.

BTC pays for channel capacity and transaction fees. The funding builder can add plain BTC inputs when the asset’s own output contains too few sats. It excludes outputs carrying unrelated RGB contracts from that top-up: spending such an output would move another asset as part of the channel open.

The funding consignment gives the accepting node the proof needed to learn and validate the contract, precision and amount. A URL carried in the opening context tells it where to fetch that consignment. Both nodes must establish the same asset binding before they can sign compatible commitments.

Funding has explicit safeguards because a failure after broadcast can leave assets locked in a channel that never finished opening. The implementation checks the proposed allocation selection, compares the built transaction with that plan, and requires a successful fetch of the published consignment before releasing funding. Public-chain funding passes through Core’s reviewed signing lifecycle.

Updating the asset balance

A channel binding records the contract, its precision and the total asset amount. Each commitment distributes that total among the channel’s outputs, including pending HTLCs. The allocations must conserve the channel amount.

The RGB runtime constructs each candidate transition in a temporary copy of state. It computes the RGB commitment without promoting that candidate into the canonical wallet. Most channel states will be replaced without reaching Bitcoin, so treating every candidate as an on-chain transition would corrupt the wallet’s view.

Before a commitment or cooperative-close signature is released, the runtime must retain an exact record of the transaction and its RGB allocation. The signer checks that durable record. Returning no RGB anchor is insufficient protection by itself: LDK can still construct a plain Bitcoin transaction, so the signing boundary must reject a missing or mismatched record.

Both peers need identical commitment bytes. A difference in asset allocation, output ordering or deterministic blinding changes the anchor and therefore the transaction being signed.

Payments need BTC as well as RGB

An RGB HTLC carries an asset amount alongside a BTC amount. Channel reserve, dust and HTLC limits therefore constrain RGB payments too. A node can hold sufficient RGB while lacking enough BTC in the required direction to send it.

The current service uses its own vln1 request format for RGB. It has no implemented multi-hop RGB forwarding path. BTC BOLT11 routing is a separate capability; support for it does not make RGB requests routable across ordinary Lightning peers.

VOUT-to-VOUT channel tests establish agreement between nodes running VOUT’s implementation. Third-party interoperability also requires agreement on the precise allocation, blinding, and output-encoding rules. VOUT has not established general channel compatibility with other RGB Lightning implementations.

What has been demonstrated

On Bitcoin Mainnet, VOUT Lightning is in use. RGB assets have been deposited into Lightning balances and credited, balances have moved between VOUT users by username, BTC Lightning invoices from other wallets have been paid, and BTC and RGB balances have been withdrawn to on-chain wallets. On Mainnet, RGB assets reach a Lightning balance through VOUT’s RGB custody wallet; the Mainnet node’s channels carry BTC.

Native RGB channels have run on Testnet4. There, two VOUT nodes opened an RGB channel with reviewed funding, paid in both directions, closed cooperatively and settled both balances back on chain. The asset’s total supply reconciled afterwards.

Force-close, holder and counterparty HTLC recovery, revoked-state recovery and peer-assisted close recovery have isolated regtest evidence. A later regtest run also demonstrated a Core-signed child transaction raising the fee of an RGB anchor-channel commitment. Those results do not establish public-chain force-close readiness or Mainnet RGB channel availability.

Channel type matters during recovery, especially for which outputs an HTLC signature commits to. Settlement and recovery explains the supported paths and the case where a counterparty can destroy an in-flight RGB allocation by spending its seal without a valid transition.