Settlement and recovery
Closing an RGB channel must preserve both the Bitcoin funds and the asset state carried by its outputs. A Bitcoin sweep that pays the correct key can still destroy RGB if it spends the asset’s seal without the required transition.
VOUT therefore retains RGB-related outputs and recovery evidence before attempting to spend them. Its recovery code checks the parent transaction, the recorded allocation, the spending conditions and the resulting anchor. Funds become available in the RGB wallet only after the resulting state has been validated and settled.
These are node responsibilities. A user withdrawing a custodial Lightning balance asks VOUT to send assets from its wallets; that user does not operate the node’s channel recovery process.
Cooperative close
When both peers agree to close, they construct a transaction that assigns the channel’s remaining RGB amounts to the closing outputs. Both peers must derive the same anchor and sign the same transaction.
Settlement checks the complete observed transaction and its funding input. Core independently resolves the chain confirmation and validates the RGB transition before promoting the recovered allocations. A supplied amount or a transaction identifier alone is insufficient evidence.
A public-network round trip demonstrated this path between two VOUT nodes: reviewed funding, payments in both directions, cooperative close and settlement on both sides. It did not exercise a public-chain force-close recovery.
Force close and retained outputs
A force close publishes a commitment without waiting for a cooperative close. Its direct balance outputs and pending HTLC outputs have different spending conditions. Some wait for a relative delay; others need a preimage or an expired absolute timeout.
An RGB-enabled node retains relevant spending descriptors instead of handing them to an ordinary BTC sweeper. That policy survives restarts and configuration changes. Retaining an output prevents an unsafe automatic spend; it does not itself recover the asset.
For a direct balance output, recovery matches the descriptor to the confirmed parent and its durable RGB allocation. It then constructs an anchored sweep to an owned wallet destination. Delayed outputs wait for their required maturity. Settlement also requires the confirmation depth used to protect canonical RGB state from shallow chain changes.
HTLC recovery
A holder HTLC can require two transactions before the asset returns to an ordinary wallet output. VOUT’s anchor-channel path preserves the peer-signed payout, adds an owned, uncoloured BTC fee input and appends an RGB anchor. The resulting delayed output must then mature before its final anchored sweep.
The peer’s signature uses SINGLE|ANYONECANPAY in this channel type. It allows the extra fee input and anchor while fixing the corresponding payout. Core validates that signature, derives the RGB amount from the parent allocation and retains the exact prepared transaction. A restart resumes those saved bytes rather than constructing a new payment under the same recovery record.
Success recovery needs the matching preimage. Timeout recovery waits for the required height. Confirming the second-stage transaction does not immediately make its delayed output spendable.
The implementation shares a recovery driver between the node worker and manual recovery paths. Automatic recovery remains bounded by retained evidence: a missing descriptor or an unavailable preimage cannot be replaced by a guessed allocation.
Revoked states and the anchor limit
Lightning’s revocation mechanism lets an honest peer claim certain outputs when its counterparty publishes an obsolete commitment. VOUT extends that recovery to RGB using retained channel evidence and validated transitions. Regtest runs cover direct revoked outputs and a revoked second-stage output that carried a valid RGB anchor.
That last condition matters. On an anchor channel, the peer’s HTLC signature does not require the appended RGB anchor. A dishonest counterparty can assemble a second stage without it. That transaction can spend the seal and destroy the in-flight RGB allocation. The demonstrated recovery of an anchored second stage does not protect against an omitted anchor.
An honest peer may compete to publish an anchored claim, but this is a transaction race rather than a guarantee. Waiting for confirmed parent state also constrains how soon RGB recovery can proceed. These limits must remain part of any assessment of production RGB channels.
Lost state and backups
A seed can derive keys. It cannot reconstruct all channel state or RGB history from Bitcoin’s commitments. The node needs current channel monitors, RGB state and recovery records; the service also needs a consistent copy of its custodial ledger. Restoring stale channel state can expose funds to a counterparty’s revocation claim.
VOUT implements peer-assisted close recovery based on bLIP-0072. A node asks the recorded channel peer for close information and a consignment, then validates and imports that proof. The responder restricts the information to the matching counterparty and funding transaction. Regtest demonstrated recovery into a wallet rebuilt from its seed, with the peer supplying the missing proof. That remains dependent on the peer retaining and serving the data.
Force-close recovery, HTLC recovery, justice and anchor-fee bumping currently have regtest evidence, with narrower public-chain evidence for cooperative settlement. Check Implementation status for the current boundary. Mobile wallet backup requirements are described separately in Backups.