Build with RGB and VOUT
An integration with VOUT needs to agree on the asset, the network, the payment format, and the evidence that counts as completion. Start with those agreements before building a checkout or distributing tokens. A wallet showing an asset’s name does not establish that it can validate another wallet’s transfers.
VOUT uses a Rust core behind its mobile interface. These documents do not publish a supported VOUT SDK or grant access to internal service APIs. For a proposed integration, contact VOUT support with the workflow and protocol versions you need.
If you are issuing an asset
Decide the name, ticker, supply, and precision before confirming issuance. Give recipients the exact Contract ID and identify the Bitcoin network. Keep public descriptions separate from cryptographic facts: RGB validates the contract and transfers, while claims about reserves, redemption, or utility require their own evidence.
Keep a full-state backup after issuance and after subsequent transfers. An issuer’s recovery phrase cannot recreate missing contract data by scanning Bitcoin alone. An issuance saved in the wallet and a listing visible in a directory are also different events; allow your distribution process to handle a delayed listing.
For the first distribution, use a small amount and follow the recipient through completion. Verify the amount in base units as well as display units. With precision 2, a displayed 1.00 represents 100 base units. Do not infer precision from a familiar ticker.
If you are building a wallet
Write down the exact protocol and schema support on each side. Establish which invoice forms each wallet accepts, how it delivers proofs, and what acknowledgements mean. Include request expiry, a wrong network, a wrong contract, interrupted proof delivery, and a restart after signing in your compatibility work.
Separate the evidence you observe. A transport accepting bytes proves delivery to that transport. A Bitcoin node accepting a transaction proves neither confirmation nor recipient validation. An end-to-end test needs the receiver to validate the intended allocation and the sender to finish its own settlement checks.
VOUT’s transfer lifecycle describes that sequence. The compatibility page covers how to scope a result so another developer can reproduce it.
If you are accepting payments
Generate the request from the receiving wallet or service that will verify the payment. Record the intended asset and amount with your order. Expired or mismatched requests should require a new review, not an attempt to reinterpret the old one.
For on-chain RGB, design the order state to survive proof delivery and Bitcoin confirmation happening at different times. Show the customer the saved payment status if the result is uncertain. A checkout timeout should not cause your application to issue a second payment automatically.
For VOUT Lightning, decide whether the recipient is another VOUT account or an external Lightning invoice. The first can settle on the service ledger; the second depends on node and route behavior. A generic Bitcoin Lightning invoice cannot request an arbitrary RGB contract. Read Pay and receive before presenting these as interchangeable payment methods.
A useful integration request
Describe the sender and recipient implementations, network, asset contract, and intended payment flow. Explain how you want to create requests, deliver proofs, and detect completion. If a transfer has failed, include the app versions, visible status, and a public transaction ID when appropriate. Do not send seeds, private keys, backup passwords, or a live payment link containing access material.
VOUT can then assess a specific compatibility or product requirement. An API specification, authentication model, and support commitment need to be agreed before an internal endpoint becomes something your application depends on.