Skip to Content
Understand RGBAssets, identity and precision

Assets and ownership

Two assets can use the same name and ticker. In RGB, the Contract ID is the identifier that distinguishes them. Before accepting a payment or buying an asset, make sure you are dealing with the contract you intended to receive.

VOUT separates discovery from ownership. An asset can appear in a directory before your wallet has ever received it. Your balance comes from locally validated wallet state, rather than from that directory entry.

What an asset description tells you

The name and ticker help people recognize an asset. Precision controls how its integer base units are displayed: with two decimal places, 100 base units appear as 1.00. The Contract ID identifies the contract whose rules and history the wallet must validate.

Precision is consequential. Incorrect display metadata can turn an apparently small amount into a different quantity. VOUT treats metadata supplied for a new or privately saved asset as unverified until the actual contract is checked. If the validated precision differs, the receive flow asks you to review the amount instead of silently keeping the earlier display.

A directory listing is useful for finding a contract and starting a receive request. Listing an asset does not establish its value, backing, redemption terms, or the identity of its issuer. Those questions require information from the issuer. A matching ticker is not enough.

Adding an asset before receiving it

You can begin from an asset in the directory or save a Contract ID using the app’s asset flow. This lets the wallet prepare for a first payment without pretending you already own the asset.

An entry awaiting wallet verification should remain distinct from a holding. After a payment arrives, Core validates the real contract and transfer proof. Only validated state can become an available balance. Merely adding an asset cannot create a balance, and removing presentation metadata does not spend an asset.

For an asset from another wallet or issuer, check interoperability before sending. Agreement on the broad name “RGB” does not establish compatibility between two implementations.

Issuing a fungible asset

VOUT’s issuance path uses the supported RGB20 fungible contract model. The issuer chooses the asset name, ticker, precision, and supply, then reviews the operation in the wallet. Core checks those values and assigns the issued quantity to a wallet-controlled seal.

Issuance requires an eligible Bitcoin output. If one must be prepared, that funding action has its own Bitcoin review and network fee. A directory publication is a separate action from contract creation: failure to publish metadata must not cause the wallet to issue the asset a second time.

Once issuance completes, preserve the contract and ownership state with an encrypted backup. The existence of an issuance screen is not a claim that VOUT supports every RGB contract type. NFTs, arbitrary contract programs, and assets built with different issuer definitions need their own compatibility work.

Buying and selling whole lots

VOUT’s market model offers a fixed quantity for a total Bitcoin price. A buyer takes the complete lot; the displayed unit price is a convenience calculated from those terms. It does not turn the order into a partially fillable offer.

The seller prepares and signs the offer in advance. The buyer’s wallet validates its signatures, RGB proof, and current Bitcoin state before preparing settlement. This allows the seller to be offline while a buyer completes a valid purchase. Availability still depends on whether the offered output remains unspent.

The purchase review separates the seller’s price, the network fee, and Bitcoin retained in the buyer’s RGB output. Retained Bitcoin is not an extra payment to the seller. An asking price also does not prove a market valuation or a completed trade.

Cancellation has an on-chain consequence. Hiding a published offer cannot revoke a signature somebody already downloaded. The wallet must consume the offered lot through a conflicting, RGB-preserving transaction; until that result is established, the original offer can still be taken. Follow the operation’s status instead of assuming that disappearance from a list means cancellation is final.

Last updated on