Thank you for pointing out the core of the issue! Now we are getting to the really interesting NFT interchain transfer issue.
The fact that a reserve chain S is already specified suggests A and B don’t trust each other to respect ownership semantics. So why would they possibly trust each other to modify the meaning of the assets?!
They don’t! Chain A can’t just tell Chain B directly that this particular asset has different metadata. Why? Because Chain B doesn’t know if Chain A is the owner of the asset in question. But the Reserve Chain S does know that Chain A is the owner and therefore, Chain A has a right to modify the metadata.
In this case, S should be the one to determine if a metadata-mutation is valid
And it does! The Reserve Chain relays the last good known state of the asset set by its owner (and no one else, the Reserve Chain guarantees that) to Chain B. The crucial point in the second proposal is in having a dedicated Staging Area and the metadata clearance procedure for NFTs.
Let’s revisit the core ‘elephant in the room’ question:
Should a chain that receives an NFT from another chain be allowed to create a derivative NFT and change it in any way?
The obvious answer seems to be ‘yes’ because we cannot expect the receiving chain to support the entire schema and feature set of the originating NFT chain. Also, there is no reason to limit how the destination chain can mutate the attributes it chooses to adopt or what new attributes it wishes to create. It might need to implement a new ‘feature’ that does not exist in the originating chain.
So what happens when a derivative NFT is returned to the originating chain or sent on to yet another chain?
The answer provided here addresses this issue, the role of the Reserve Chain S, and the necessity of the ‘Staging Area’ to practically implement the mechanism.
Yes, the destination chain should be able to create a derivative NFT and should be free to implement new or copy over existing metadata partially or completely however it chooses. The reserve chain’s role in the transfer of the derivative NFT is thus:
IF AND ONLY IF the Reserve Chain S is the destination of the transfer of the derivative NFT, THEN S should be the one to determine if a metadata-mutation is valid.
ELSE, its role is ONLY to be the authority of trust in a transaction between two chains guaranteeing that the chain that initiated the transaction is the actual owner of the NFT and testifying that the last good known state (the metadata hash) was provided by the owner and by no one else.
What is implied here is that it is SOLELY upon the destination chain to determine what constitutes a valid, or more properly stated, ‘acceptable’ metadata (the last good known state of the NFT) and decide if it wants to accept it.
Let’s view a journey of a single NFT according to the second proposal. We will start with the Reserve Chain since it is the originating chain, meaning that it is where the NFT was originally minted.
[The Preparation Stage]
First, we move the NFT into the Staging Area: a dedicated on-chain area (a dedicated pallet) where the NFT is located before being transferred to another chain.
In the process of moving the NFT into the Staging Area, we are computing the metadata hash – the representation of the last good known state of the NFT.
Note: when an NFT is moved into the Staging Area, it is removed from the business logic of the chain, i.e., neither the pallets nor the smart contracts of the chain can interact with the NFT while it is in the Staging Area. There are exactly two operations that can be performed on that NFT (described below).
With that in mind, the source chain can freely remove the metadata blob of the NFT. But how does the destination chain obtain that blob? Answer: the metadata blob (corresponding to the metadata hash) is still accessible in the previous blocks of the sender chain.
[The Transfer Stage]
Next, the owner of the NFT (the user of the Reserve Chain) initiates the XCM transfer to the Beneficiary (another user) on another chain, the destination chain. Let’s call the destination chain “Chain A”. The information sent to Chain A is only the following: 1) the NFT id; 2) the metadata hash.
Also, the Reserve Chain makes a record inside its Staging Area that this particular NFT is now owned by Chain A – the NFT id is placed under Chain A’s sovereign account.
Note: the metadata blob shall be transferred off-chain.
[The Customs Stage]
The NFT id and the metadata hash are received at the Staging Area on Chain A. This data remains in the Staging Area indefinitely until the Beneficiary (the current owner) decides to pass the NFT id and the metadata hash through the clearance procedure.
Note: there are exactly two mutually exclusive actions that can be done with an NFT id and the metadata hash in the Staging Area: 1) pass them through the clearance procedure or; 2) transfer them to another chain.
[The Clearance Procedure]
On the destination chain (Chain A), the NFT id and the metadata hash, and the metadata blob provided off-chain are being processed to decide if the NFT is acceptable on this particular chain according to its rules.
[OK – Accept the NFT]
Upon acceptance, Chain A mints the native representation of the NFT (also referred to as the ‘derivative NFT’). The received NFT id and the metadata hash are then removed from the Staging Area.
[REJECT the NFT]
If the destination chain decides that this NFT (in that particular state represented by the metadata hash + metadata blob provided off-chain) does not comply with the chain’s rules, then the NFT id and the metadata hash will remain in the Staging Area. As noted above, the Beneficiary can, at some point in time, decide what to do next – try to pass it through the clearance procedure again (maybe the chain’s rules got changed) or send it to another chain.
Note: the metadata blob shall eventually be uploaded to the destination chain via the pre-image pallet or some other way. The crucial step is computing the hash of the acquired off-chain metadata blob upon receipt because during the clearance procedure the destination chain compares this hash against the metadata hash provided by the Reserve Chain. This is the process of authentication of the metadata blob. The destination chain can do additional checks on the metadata hash/blob if necessary.
Now, let’s examine the NFT transfer from Chain A to Chain B via the Reserve Chain.
The Preparation Stage for Chain A is identical to the one described previously. In this first step, the NFT id and the newly computed metadata hash are stored in the Staging Area of Chain A.
Then, the owner of the NFT initiates the reserve transfer (the Transfer Stage). The new metadata hash is transferred to the Reserve Chain, and then the Reserve Chain transfers the NFT id from Chain A’s sovereign account to Chain B’s sovereign account and makes a record of it in the Staging Area. Finally, the Reserve Chain sends the metadata hash provided by Chain A (supplied in the SetTopic XCM command) to Chain B.
The crucial note: in the Transfer Stage, the NFT id and the metadata hash do not go through the Reserve Chain’s clearance procedure because the transfer action is performed only in the Staging Area. The only role the Reserve Chain has at this stage is to guarantee that the metadata hash it is relaying to Chain B is indeed the one that is provided by the previous owner of the NFT.
In the final step, Chain B (the destination chain) receives the NFT id and the metadata hash from the Reserve Chain. The NFT id and the metadata hash get placed in the Staging Area of Chain B (the Customs Stage) and enter the process identical to the Clearance Procedure described previously.
So, to be clear, destination chains do not accept arbitrary metadata of NFTs. They have a clearance procedure to verify metadata compliance. But they trust the Reserve Chain in that the metadata hash provided is indeed the one that was set by the previous owner of the NFT and no one else.