Client-side validation

Also covering RGB, Taro, and Taproot Assets

Client-side validation protocols allow a Bitcoin transaction to commit to some data whose validity is determined separate from the validity of the transaction under Bitcoin’s consensus rules. The client-side validation can take advantage of consensus rules, such as only allowing an output to be spent once within a valid block chain, but it may also impose additional rules known only to those interested in the validation.

A conceptually simple client-side validation protocol might associate a token with a particular UTXO. Only the set of validators needs to know about that association; it does not need to be published to the block chain or anywhere else that is public. When the UTXO is spent, the spending transaction associates the token with a new UTXO. If Alice currently controls the UTXO associated with the token and Bob wants to buy it from her, she can provide him with evidence of the original association and then he can use his validated copy of the block chain plus client-side validation to verify the history of every transfer of the token leading up to Alice. He can also verify that a transaction created by Alice is correctly formatted to assign the token to a UTXO that Bob controls.

RGB is a client-side validation protocol that uses pay-to-contract to allow transactions to commit to additional data, such as transfers. The protocol has been designed to be highly flexible.

Taproot Assets, formerly called Taro, is a protocol heavily inspired by RGB that uses taproot’s commitment structure to allow transactions to commit to additional data. Taproot’s construction itself derives from pay-to-contract. As the name suggests, initial protocol development is specifically focused on the transfer of assets (that is, digital tokens that represent assets).

Both protocols are designed to be compatible with offchain transactions, such as LN payments. Similar to the lifecycle of an LN channel, an onchain setup transaction is published that commits the tokens to the mutual control of involved parties; a series of offchain transactions each commits to the current allocation of the tokens between the parties; and a transaction containing the final commitment is published onchain.

Only wallets that want to support RGB or Taproot Assets need to understand the protocol, and only a wallet that wants to send or receive a specific token or other client-side validation contract needs to know anything about that contract. To everyone else, transactions created with RGB and Taproot Assets look like regular Bitcoin transactions.

2023

2022

Taro transferrable token scheme

Optech newsletter and website mentions

See also