RCP-250207A: Contracts linking protocol

[fedsten]

layer: schemata

As new RGB schemas are developed, there may be a desire for the issuer of an already circulating token to upgrade to a new schema with new more advanced features. To do so, would require to re-issue the asset and convince users to migrate, which is hard to coordinate and results in two non fungible assets representing the same economic object. This complexity could be abstracted by wallets if they would be able to provably demonstrate that those two assets are essentially the same thing (i.e. they give access to the same rights), and can therefore be displayed as a unified balance in the UI.

The only way to provide such proof is by having the issuer of the first asset to sign a message declaring the second asset as being equivalent to the first.

Proposal
To create a link between two assets, the asset schema should include the following (optional) fields:
1 - Issuer Public Key
2 - Previous Asset ID
3 - Signature of the current asset ID produced with the private key corresponding to the public key found in the pub key field of the previous asset

The first asset issuance should fill only 1, while the second asset needs to provide 2 and 3 to create a link with the first asset.

Verification flow
1 - A wallet imports a new asset
2 - The wallet checks if the Previous Asset ID field is present, if not the process terminates
3 - The wallet checks if the Previous Asset ID is of a known asset, if not the process terminates
4 - The wallet extracts the Public Key from the previous asset genesis
5 - The wallet verifies that the signature provided is produced by the correct key and it is signing the new Asset ID, if not the process terminates
6 - Optional: the wallet may want to verify that Asset Name, Ticker and other relevant metadata are the same in both assets
7 - The wallet associates the two assets and merges the balances in the UI.

Having this feature would be very useful in this phase, as it allows us to quickly deploy simple schemas without having to worry to make the perfect schema right away, as that work can be postponed without delaying production deployment of the first use cases, and upgrades can happen later on with reduced friction for the users.

[dr-orlovsky]

I think this is a very cool idea.

To implement it we need to (a) design an interface standard (we can reserve name RGB29 for it, or even RGB31 or RGB200 if you want) and (b) write a schema that enforces the fulfillment of the rules and acts made by a wallet, which you have described.

Also, instead of a public key we, indeed, can use UTXO-based single-use seal. Why it will be bettter? It will create a provably-singular event from the issuer of an asset update, and all wallets will know that there is a newer version of the asset. Also, this will align with pt 1-2, since in closing that seal the new asset contract Id will be specified.

[fedsten]

Thanks for the feedback. Regarding the use of the single-use seal instead of a public key I agree that this is a superior solution. Creating a new contract that is declared to be economically the same as the old one is equivalent to do a secondary issuance, so using single-use seals the issuer is forced to disclosed publicly that new tokens have been issued, and cannot do it secretly.

Regarding the new interface, my understanding is that interface should define an expected UI that the wallet displayed to the users (e.g. RGB20 shows a ticker, RGB21 shows a media attachment, etc), so in this feature doesn't seem to me that would affect the experience in using the asset for the end user. I see this feature as to be implemented in schemas under the existing interfaces.