VOUT and the RGB ecosystem
An ecosystem becomes useful when people can complete an ordinary task through it. An issuer wants to distribute an asset. A recipient wants to know what arrived. A merchant wants to confirm a payment. A wallet developer wants another wallet to interpret the same request correctly.
VOUT’s aim is to connect those tasks in a product that people can use from a phone. Its role begins with the wallet, because every directory entry, payment flow, and marketplace eventually depends on someone being able to hold and transfer the actual asset.
The path from discovery to ownership
Imagine receiving an asset you have never held before. A logo and ticker help you recognize it, but several unrelated contracts can use the same name. You need the issuer’s Contract ID and enough information to decide whether that is the asset you intended to receive.
Next comes a receive request. The request tells the sender which contract and amount you expect, and provides the information needed to deliver the transfer. Your wallet must validate the resulting proof and its Bitcoin anchor. Only then can the asset become part of your usable wallet state.
These are separate steps with separate responsibilities. A directory helps discovery. The issuer explains the asset. The sender delivers the payment and its proof. Your wallet validates what it receives. VOUT keeps those roles visible so that a familiar-looking listing does not silently become evidence of ownership.
A place for issuers
Issuance starts a contract; it also starts the issuer’s responsibility to explain it. Holders need to understand the supply, precision, intended use, and any external promise attached to the asset. The contract’s technical validity cannot establish whether a business will honor that promise.
VOUT supports an issuance flow and public asset information alongside the wallet. That lets a project give recipients a contract they can inspect and a way to request it. For a distribution, begin with a small test between the actual wallet versions and networks involved. Preserve the resulting wallet state and recovery material before scaling the process.
Payments people can complete
On-chain RGB provides an ownership path anchored to Bitcoin. It involves proof delivery and confirmation, which affect when a recipient can use the funds. The sender and recipient need a clear view of progress when either part takes longer than expected.
VOUT Lightning offers another payment experience through a service balance. That can be useful for transfers between accounts and supported Lightning invoices. Its custody model is different from the on-chain wallet. The service must keep an accurate ledger and settle withdrawals correctly; the user depends on VOUT while funds remain there.
Native RGB channels are a further technical path. They need asset-aware channel state, proofs, commitment transactions, and recovery behavior. Their development should not be confused with the ability to move an RGB balance between two accounts on VOUT’s ledger. The RGB channel chapter explains that distinction and the remaining limits.
What builders should be able to rely on
VOUT’s integration work depends on exact contracts, explicit payment reviews, recoverable operations, and documented compatibility. A wallet should not have to guess what another wallet meant by a ticker or whether a transport response proves that a payment settled.
The practical route to a wider ecosystem is to document those interfaces, reproduce transfers, and publish compatibility results with their scope. Broad support cannot be inferred from a shared protocol name. See Wallet compatibility for the dimensions that need to match, and Build with RGB and VOUT for the questions to settle before an integration.