The life of an RGB transfer

An on-chain RGB payment is complete only when the asset transfer and its Bitcoin anchor agree. A transaction ID, an uploaded proof, or a message from the sender describes part of that process. VOUT tracks the parts separately so it can resume the payment if the app closes or a service stops responding.

Create a receive request

The recipient selects the asset and exact amount, then creates a receive QR. Core binds the request to the wallet’s network, the Contract ID, and a beneficiary the wallet can recognize later. The saved request also has an expiry.

Share that request unchanged. Create a fresh request for each payment. If an unpaid request expires, give the sender a new one before they pay. Creating another request does not revoke an earlier request that is still payable.

Review and authorize the send

The sender’s wallet parses the invoice, checks its network and expiry, selects eligible inputs, and prepares the transfer. In VOUT, Core creates the review shown for approval. The review binds the intended payment and fee to the operation that will be signed.

Inputs are reserved while the operation is in progress. That prevents another payment from consuming them at the same time. An interrupted review can be resumed, but recovering its data does not count as the person’s approval. Signing still requires authorization for that operation.

Deliver the proof and broadcast the anchor

The signed operation produces a recipient consignment and a Bitcoin anchor transaction. VOUT records the operation before performing delivery or broadcast. It keeps the exact artifacts needed to retry a step whose result is uncertain.

This distinction matters when a network request times out. The relay might have stored a proof, or a Bitcoin backend might have accepted a transaction, even though the response never reached the wallet. VOUT resumes using the same operation and transaction rather than treating silence as permission to pay again.

A proof upload receipt means the transport accepted the package. A broadcast receipt means a backend accepted the transaction. Neither receipt establishes that the recipient has validated the asset.

Validate on the receiving device

VOUT retrieves the consignment and checks it against the saved request. Validation happens in an isolated candidate state so rejected data cannot become the wallet’s balance. Core checks the contract, beneficiary, amount, and Bitcoin anchor, then activates the validated state when its confirmation requirements are met.

The receive screen distinguishes the resulting states:

Transport errors and rejected proofs are different outcomes. An unavailable service may be retried. A contradictory or invalid proof must not be accepted simply because it was delivered successfully.

Acknowledge and settle

After local validation and confirmed activation, the recipient posts an acknowledgement, or ACK. The sender checks for that response. VOUT settles a send only with the matching positive acknowledgement and a valid current anchor observation; it then releases that operation’s input reservations.

A missing ACK leaves the sender waiting. A negative ACK after broadcast needs investigation because the Bitcoin transaction may already have moved. It cannot safely be treated as an ordinary unsent payment.

When the chain or the app changes

A Bitcoin reorganization can remove a previously confirming block. VOUT retains the operation and rechecks its anchor. A settled send can return to an unresolved state, with its input protections restored, until the same transaction is confirmed again.

For a stalled payment, keep the wallet data and open its existing activity or receive request. Refreshing or resuming that operation is safer than creating a second payment. Do not reinstall the app to clear a pending state. See troubleshooting and backup and recovery before moving to another device.