Anatomy of an RGB Channel Open

Introduction: From Locking BTC to Loading Assets

Opening an ordinary Lightning channel is, at its core, two parties jointly locking up some BTC: build a funding transaction, lock the coins into a 2-of-2 multisig, wait for confirmation, and the channel is live.

Opening an RGB channel does all of that — and additionally loads an asset into the channel: the ownership state of an RGB asset moves from your on-chain wallet into the channel. That extra step brings three concepts that run through this entire article:

• RGB-UTXO: a Bitcoin UTXO that carries asset state;
• Witness transaction: the Bitcoin transaction that bears witness to an asset state transfer;
• Consignment: the evidence chain you hand to your counterparty so they can independently verify the asset's history.

Once the relationship between these three is clear, every rule and constraint in the RGB channel open flow falls into place.

1. Background: A Quick Refresher

RGB is a client-side validation protocol. The Bitcoin chain neither stores nor validates any RGB asset state — the chain only provides commitment anchoring and time ordering. The real asset state is kept by its holder; on every transfer, the full historical evidence is handed to the receiver, and the receiver verifies it all the way back to issuance. This is the most fundamental difference between RGB and other asset protocols.

A standard Lightning channel open takes four steps: the initiator proposes (open_channel) → the peer accepts (accept_channel) → the initiator builds and broadcasts the funding transaction → after confirmation, the channel goes live (channel_ready).

An RGB channel open = those four steps + the migration of asset state. Let's look at the full flow.

2. The Big Picture: A Complete RGB Channel Open

A few details worth noticing:

• Step ② already tells the peer everything — the asset ID, the amount, and where to fetch the evidence. Bob knows from the very first message that this is an RGB channel and what it will carry;
• Step ⑤, "coloring", is RGB's core move: while the funding transaction spends the asset-bearing UTXO, it also embeds a cryptographic commitment to the state change "this asset moves into the channel". This funding transaction is the witness transaction of the transfer;
• Step ⑧ happens before broadcast — Bob doesn't "trust that Alice has the asset". He takes the Consignment and verifies every transfer since issuance himself, and only hands over his signature once it all checks out. If Bob doesn't approve, the funding transaction never reaches the chain. Nobody on-chain does this for him — that is what client-side validation means.

This diagram is the map for the rest of the article. Now let's take the key mechanisms apart, layer by layer.

3. Dissecting an RGB-UTXO

First, a common mental-model correction: asset state does not hang off the UTXO — it hangs off allocations.

A single Bitcoin UTXO can carry multiple allocations. Each allocation records a portion of the asset and is bound to its own witness transaction — the Bitcoin transaction that originally moved that portion here.

This "one UTXO, several allocations, each with its own witness" situation is not exotic: for instance, someone sends you the same asset in two payments, and both land on the same receiving UTXO — the first confirmed long ago, the second still waiting to be mined.

Spending, however, follows the opposite rule: the unit of spending is the whole UTXO. When you spend a UTXO, every allocation on it must enter the state transition together — you cannot spend A and leave B behind.

State is recorded per allocation; spending happens per whole UTXO. Keep this tension in mind — it is the key to the next section and to every funding constraint that follows.

4. Two Layers of State: Two Ledgers for One UTXO

Now we can answer the question planted in Section 2: what does the preflight's "usable" actually check?

The answer: a UTXO must pass two independent gates, because an RGB-UTXO has two layers of state:

The RGB-layer witness lifecycle can be simplified into this state machine:

The two ledgers are kept independently, which produces two seemingly contradictory combinations — precisely the ones that confuse people most when opening RGB channels:

Combination one: the UTXO is unconfirmed, yet the RGB layer considers the asset "valid". This is not a bug; it is a natural consequence of client-side validation. RGB state transitions happen off-chain — the Bitcoin transaction is merely the anchor for a commitment. Whether a transfer is valid depends on the receiver's verification of the evidence chain, not on whether the anchor transaction has confirmed; confirmation merely nails the anchor down. So RGB's "off-chain" is not limited to Lightning: even an ordinary on-chain RGB transfer passes and verifies its asset state entirely between clients, with on-chain confirmation catching up afterwards. That is why chaining another transfer on top of an unconfirmed one is perfectly legal at the protocol level. A channel funding, however, is a different matter — it must not be built on a foundation that hasn't been nailed down yet.

Combination two: the UTXO confirmed long ago, yet the asset is still unusable. Remember Allocation B from the diagram in Section 3? The UTXO itself was mined three days ago, but B's witness transaction is still sitting in the mempool. Open a channel with this UTXO and — because spending is all-or-nothing — B gets dragged in, and the channel's asset foundation ends up standing on a transaction that can be replaced (RBF) at any moment. If that transaction is replaced, the channel's entire asset foundation collapses.

So the rule is: for a UTXO to serve as a channel's asset carrier (the funding anchor), every allocation of the target asset on it must have its witness transaction mined (or be an original issuance allocation). If even one allocation is unsettled, the whole UTXO is temporarily out.

A real case: fifty seconds of confusion

A tester reported: opening an RGB channel failed, even though the asset balance was clearly more than enough. The log had three key lines:

02:39:38  an RGB transfer broadcast (its change became the asset's only UTXO)
02:47:35  channel open → rejected
02:48:25  that transfer confirmed

With the model above, the explanation takes thirty seconds: after that transfer, all of his asset units sat on the change output, and the change output's witness transaction — the transfer itself — was not yet confirmed. At 02:47 the asset was Tentative, so the rule blocked the open; at 02:48, after confirmation, the identical operation succeeded immediately. He did nothing wrong — he only needed to wait for one block.

The subtler variant is combination two: had his asset arrived on an already-confirmed UTXO via a blinded receive, nothing at the UTXO level would look wrong, and the RGB-layer witness check would be the only line of defense. This is why the rule must exist — what it blocks is not an inconvenience but a genuine asset-safety risk.

5. The Five Funding Constraints

Putting the mechanisms together, a valid RGB channel funding must satisfy all of the following:

1. Whole-UTXO spend — every allocation on a selected UTXO enters the state transition together; there is no partial spend;
2. Single asset — a UTXO carrying several different assets cannot anchor a channel: the channel holds one asset, and the others would be dragged along with nowhere to go;
3. Witness settled — for every allocation of the target asset, the witness transaction must be mined (or be an original issuance allocation);
4. Enough BTC face value — the funding transaction doesn't just move the asset; it must also lock real BTC for the channel capacity and pay miner fees. Enough asset units with too few sats still won't open a channel;
5. In-flight state is untouchable — asset state already involved in an unfinished operation (say, another channel currently opening) must never be double-spent.

The first four are checked synchronously the moment the open request is made — failing them returns an immediate, explicit error, rather than pretending to succeed and quietly closing the channel seconds later. The fifth is enforced by the wallet layer on every spending path.

6. The Four Funding Policies

The constraints are fixed, but which UTXOs the wallet picks to satisfy them is a matter of policy. The node offers four:

The default is the merge policy, for a practical reason: after a few rounds of sending and receiving, an asset tends to fragment across several small UTXOs — "no single one suffices, but together they do" is the norm, not the exception. The merge policy lets such a wallet open a channel in one shot, tidying up the UTXO set along the way.

Whichever policy you choose, the five constraints of Section 5 apply equally — the policy decides how to pick, never what qualifies.

7. The Consignment: Why Should Your Peer Believe You

To Bob, the funding transaction is just another string of Bitcoin inputs and outputs. How does he know the channel really holds 5,000 units of the asset?

The answer was planted back at step ②: when Alice proposed the channel, she included a consignment URL (a URL template keyed by the funding transaction ID). And before signing the funding transaction, Alice has already generated the Consignment against that transaction ID — a bundle containing every state transition of this asset from issuance genesis to entering this channel, along with the on-chain commitment proof for each step.

The timing is the crux: Bob fetches and verifies the Consignment during the handshake, before the funding transaction is broadcast. He checks the evidence chain link by link — was each transfer properly authorized, is each commitment genuinely anchored in its Bitcoin transaction, do the amounts conserve. Only when everything passes does he hand over his signature; if any link fails, he refuses to sign and the funding transaction never appears on-chain. Faking an asset to open a channel gets caught at step one, before a single satoshi of miner fees is spent. No oracle, no federation, no "trust the official explorer" — only math and Bob's own validator.

This also explains why RGB channel funding conventionally requires 6 confirmations before the channel goes live: the asset state is committed into that transaction, and if it were reorged or replaced at shallow depth, the channel's asset ledger would be uprooted. A few extra blocks buy an immovable foundation.

8. After the Open: Where Did the Asset Go

The moment the channel goes live, the asset turns from "an allocation in your on-chain wallet" into "a balance inside the channel" — it leaves the direct sight of Bitcoin blocks and enters the Lightning fast lane. From then on, every in-channel payment is an off-chain RGB state update: no broadcast, no confirmation, no miner fees, and still verified independently by both sides.

And when the channel reaches the end of its life — a cooperative close or a force close — that state makes the reverse journey, safely back onto the chain. That is another equally rigorous piece of machinery.

Quick FAQ

Q: My asset balance is clearly sufficient — why does the channel open report "insufficient funds"? A: Nine times out of ten, a witness transaction is unconfirmed — some allocation of your asset is still witnessed by a transaction that hasn't been mined yet. Most commonly you just sent a transfer and your units are in its change; but as Section 4 showed, the allocation may just as well sit on a long-confirmed UTXO whose witness is a separate, unconfirmed transaction. Either way, wait for it to confirm (usually one block) and retry.

Q: I just received some RGB assets. Can I open a channel with them right away? A: Wait for that transfer to confirm first. At the protocol level, RGB does allow chaining further transfers on top of an unconfirmed anchor (see "combination one" in Section 4) — but a channel's asset foundation must, without exception, stand on a confirmed witness transaction.

Q: What do the mined / tentative buckets in my balance mean? A: They are exactly the two-layer state model projected onto your balance — mined is the portion whose witness transactions are on-chain and ready for channel opening; tentative is the portion whose witness transactions are still unconfirmed and need to wait. Channel opening only counts the mined portion.