RGB interoperability

An RGB transfer between two wallets needs agreement at several layers. Both wallets must understand the contract, interpret the invoice, deliver the proof, and reach compatible completion states. Sharing a Bitcoin network or displaying the same token name does not establish that agreement.

VOUT targets RGB v0.12. Its current on-chain implementation pins the runtime and standard library to 0.12.0-rc.3, with the supported RGB20 issuer definition. These are implementation coordinates for integration work. They should not be read as a promise that every application described as “RGB v0.12” has been tested with VOUT.

Start with the contract

The recipient needs the contract data and the issuer definition required to validate it. Compare the Contract ID, contract model, precision, and exact protocol versions before trying a transfer. A wallet can parse an invoice yet still be unable to validate the eventual asset.

VOUT rejects unsupported or inconsistent data rather than crediting a balance from a familiar ticker. Compatibility with older RGB releases should not be assumed. Upstream’s v0.12 release notes  distinguish the consensus layer from the standard library and applications; a consensus release does not certify a particular pair of wallets.

Preserve the invoice

A receive request contains more than a beneficiary. The network, requested asset and amount, expiry, and proof endpoint all affect processing. Pass the complete original invoice between wallets. Reordering or rewriting it can also change a transport identifier in implementations that derive their mailbox key from the original invoice bytes.

VOUT’s invoices advertise an endpoint using the RGB https+json-rpc URI form. The corresponding public HTTPS authorities are separated by network:

These are proof delivery services. They do not expose wallet keys, provide a signing API, or authorize a payment on somebody’s behalf.

Deliver the actual consignment

VOUT uses RGB proxy protocol 0.2 methods for service discovery, consignment delivery and retrieval, and acknowledgement: server.info, consignment.post, consignment.get, ack.post, and ack.get.

An integration must establish where the sending wallet actually uploads the consignment. A transaction may confirm while the receiving mailbox remains empty. In that situation, retrying a blockchain scan cannot supply the missing proof. The sender or its implementation needs to make the exact consignment available through a supported delivery path.

VOUT supports the recipient identifiers used by its own invoices and a compatibility lookup based on a hash of the original invoice. Both lookups remain at the same network’s configured endpoint. Conflicting proofs are rejected. This compatibility behavior is deliberately narrower than accepting arbitrary proxy addresses or searching unrelated services for a payment.

Check the acknowledgement path too

The recipient posts an ACK after validating and activating the received state. The sender must look in the corresponding mailbox to learn that the payment was accepted. If it instead queries a different service or derives a different recipient identifier, the recipient can have a validated asset while the sender continues waiting.

A useful interoperability test therefore checks both wallets. Record that the recipient obtained the exact requested asset and that the sender reached its completed state. Repeat in the other direction; one successful route does not establish bidirectional compatibility.

Scope an integration before real payments

Begin with an agreed Testnet4 asset and small, disposable test balances. Exercise a normal transfer, an app restart while pending, proof delivery failure, and delayed acknowledgement. Agree on how either party can recover the consignment if automatic delivery fails. Keep invoice capabilities and proof contents out of public support posts.

VOUT does not currently offer a documented public wallet SDK. The mobile application’s native bridge and service implementations are internal application boundaries. The public transport above is useful to wallet integrators, but it should not be treated as a general remote wallet API.

Until a particular wallet and version have passed the complete exchange, describe their compatibility as unverified. For users, the practical consequence is simple: confirm support with the receiving wallet before transferring an asset, and retain the existing payment record if either side remains pending.