Cross-chain NFT transfer

[librelois]

Just an first draft about what the XCM messages could look like (pseudo-code):

From reserve to non-reserve

Message send by the reserve chain to the non-reserve chain:

Xcm([
  ReserveAssetDeposited(feeAssetAndNft)
  ClearOrigin
  BuyExecution { fees: feeAsset, weight_limit }
  SetTopic(metadataHash)
  DepositAsset(assets: all, beneficiary)
])

From non-reserve to reserve (without metadata mutation)

Message send by the non-reserve chain to the reserve chain:

Xcm([
  WithdrawAsset(feeAssetAndNft)
  ClearOrigin
  BuyExecution { fees: feeAsset, weight_limit }
  SetAppendix([ReportError({ destination: sender, query_id, max_weight})])
  DepositAsset(assets: all, beneficiary)
])

From non-reserve to reserve (with metadata mutation)

Message send by the non-reserve chain to the reserve chain:

Xcm([
  WithdrawAsset(feeAssetAndNft)
  DescendOrigin(userAccountOnSenderChain)
  BuyExecution { fees: feeAsset, weight_limit }
  SetErrorHandler([ReportError({ destination: sender, query_id, max_weight})])
  DepositAsset(assets: all, beneficiary: origin)
  Transact(xnft.mutateThenDeposit(nftAsset, newMetadataHash, destAccount, response: { sender, query_id }))
])

The call xnft.mutateThenDeposit can either:

1. Accept the new metadata hash direcly and deposit the NFT on the destAccount, in that case the call should send to the sender chain the XCM message Xcm([QueryResponse { queryi_id, response: DispatchResult(Success), .. }]).
2. Create a pending request and lock the NFT, waiting for whole metatada injection.
3. Reject the new metadata hash direcly and throw an XCM error

In case of 2, a response will be send back to the sender chain only at metadata injection on the reserve or call to xnft.mutateRequestExpire (by any signed origin) after the expiration delay.

This allow to send back a response to the sender chain only when the mutate request is finally accepted or rejected.

From non-reserve to non-reserve

Message send by the non-reserve sender chain to the reserve chain:

Xcm([
  WithdrawAsset(feeAssetAndNft)
  DescendOrigin(userAccountOnSenderChain)
  BuyExecution { fees: feeAsset, weight_limit }
  SetErrorHandler([ReportError({ destination: sender, query_id, max_weight})])
  DepositAsset(assets: all, beneficiary: origin)
  Transact(xnft.mutateThenSend(
    nftAsset,
    newMetadataHash,
    dest,
    fees: Some((feeAsset, weight_limit)),
    response: { sender, query_id }
    xcm: Xcm([
      DepositAsset(assets: all, beneficiary)]))
    ]),
  )), 
])

The call xnft.mutateThenSend can either:

1. Accept the new metadata hash direcly and forward the inner xcm message to the destination, in that case the call should:

• prepend the inner message with 3 instructions ([WidrawAsset(feeAssetAndNft),ClearOrigin,SetTopic(newMetadataHash)]) and send it to the destination chain.
• send to the sender chain the XCM message Xcm([QueryResponse { queryi_id, response: DispatchResult(Success), .. }]).
• move the NFT ownership to the sovereign account of the dest chain.

2. Create a pending request and lock the NFT, waiting for whole metatada injection.
3. Reject the new metadata hash direcly and throw an XCM error

In case of 2, a response will be send back to the sender chain only at metadata injection on the reserve or call to xnft.mutateRequestExpire (by any signed origin) after the expiration delay.

This allow to send back a response to the sender chain only when the mutate request is finally accepted or rejected.

All the call names can obviously be changed, the relevant part is not about the names but the structure of the process.

It seem’s that we need at least 3 calls in the common pallet (and probably a 4th to just mutate metadata without any cross-chain transfer), that can be the existing “xtokens” pallet but I’m afraid that the xtokens pallet will become too heavy.
It seem’s better to me to create a new dedicated pallet because transferring NTFs need a lot of specific stuff to handle metadata that will pollute the xtokens pallet for project that don’t need to handle NFTs transfers through XCM.

[gavofyork]

@librelois

This is not how the reserve based model works. Your description corresponds more to a teleportation between two networks that totally trust each other.
In the reserve-based model, the reserve chain is the only source of truth, and the only one on which the “real” asset is located. The other chains only mint/burn derivatives representations.

This is why in all cases the reserve chain must keep the NFT metadata and check that any modifications to it comply with the business rules of the NFT concerned (defined by the smart contract that handle this NFT or by the runtime itself through a pallet).
The fact that a remote chain becomes the owner of the asset (via its sovereign account), does not mean that it can modify the design or operation rules of this asset.

Cannot agree enough with this reply. The whole premise of this conversation seems to be an exercise in broken understanding of the cross-chain trust model.

If A and B trust each other enough to allow each other to arbitrarily modify the meaning of common assets, then they don’t need a reserve - they should just pre-synchronise the metadata and teleport the asset. But would this trust model really extend to any other chain which would hold the asset too? Seems dangerous and unlikely. 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?! In this case, S should be the one to determine if a metadata-mutation is valid, and if so, store the ground-truth for metadata and provide a synchronisation service to allow these changes to be synced to A, B and any other chain which might want to know.

[librelois]

@gavofyork

In this case, S should be the one to determine if a metadata-mutation is valid, and if so, store the ground-truth for metadata and provide a synchronisation service to allow these changes to be synced to A, B and any other chain which might want to know.

Yes I totally agree with that, and it seems to me that this is what I have already explained with my own words

[mrshiposha]

Thank you for pointing out the core of the issue! Now we are getting to the really interesting NFT interchain transfer issue.

TL;DR

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.

The point

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.

In short:

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.

1. [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.

2. [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.

[librelois]

@mrshiposha

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.

It’s not just a question of who owns the asset, the owner is just one of the properties of the asset. It’s much deeper than that, the real asset only exists on the reserve chain, chains A and B only mint and burn derivatives representations of the assets, derivatives are not the real asset, they are different in essence.

Each chain is free to manipulate the derivatives it manages according to its rules, but the underlying asset always remains on the reserve chain and is subject only to the rules of the reserve chain.

@mrshiposha

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.

No, its role is not only to guarantee the ownership, its role is to manage all aspects of the concerned asset.

Being an owner of an NFT doesn’t mean you can do anything with it, just like owning your house doesn’t mean you can do anything with your house, you have to respect the local rules of your community, the urban plan, possible rules of neighborhoods, etc.

It is the creator/designer of an NFT collection that defines what can be done with that NFT collection, the future owners will only be able to perform actions in accordance with the rules defined by the creators/designer of the NFT.

As a creator, you have every right to decide that “anything can be done with your creations”, but you can’t force other creators to do the same.

In a smart contract chain like Moonbeam, the contract developers encode rules that specify what can be done with the assets managed by the contract, the fact that the assets in question are non-fungible does not change the fact that they will remain eternally managed by the contract, regardless of the owners (unless the contract decides to delegate the management of this asset to another contract or to burn the asset permanently).

For example, some NFTs are related to video games, and their properties/metadata can change depending on what the player does and what happens in the game. You understand that the game designers can’t allow the metadata used by the game to be modified by another unintended system.

More generally, on the Moonbeam side it is strictly impossible for us to implement what you are asking, even if we wanted to.

The best we can do is to propose to the creators of NFT collections a simple way to approve this or that extension/protocol of this or that chain to amend “extended metadata”.

For this it would be simpler if the “container format” used to calculate the hash was a map of (Protocol, arbitrary data). With each protocol defining its own format.
Thus, the reserve chain could see which protocols are added/modified (and by which chain), and automatically authorize the modifications or not according to the configuration indicated by the creators of the NFT collection (with default rejection if no configuration exists).

To avoid unnecessary XCM traffic (and scaling more), I think that the metadata modification request to the reserve chain only needs to be done during a cross-chain transfers (whether the destination is the reserve or not).

For more detailed steps I refer to my proposal in this post: Cross-chain NFT transfer - #22 by librelois

I can work on more precise specifications, but I prefer to make sure we agree on some essential rules and constraints first:

• The reserve chain always keeps the full control of the native NFT.
• Any changes to the native NFT metadata must be verified and approved by the reserve chain.
• The reserve chain can only send via XCM information that it has approved itself according to its own rules, this applies of course to the hash of the native NFT metadata.
• The metadata of the native NFT must be kept by the reserve chain, it cannot be deleted (unless the native NFT is permanently destroyed, but in this case any derivative of this NFT must also be destroyed).
• The destination chain must receive the new hash of the metadata from the reserve chain, because it is the only source of truth (if two chains choose to trust each other to exchange data that has not been attested by the reserve, then they can define their own protocol between them, this is outside the scope of this discussion).

[gz1]

Hi @librelois, nice to meet you! (I think we didn’t have a chance to chat before.)

I hear what you’re saying and I think I know where you’re coming from. Please correct me if I’m wrong.

In Moonbeam there might be ERC-721 contracts that are already deployed that may even implement some non-standard metadata logic. Let them stay in absolute control of the metadata if they wish, so if anybody wants to send this NFT to some other chain outside of Moonbeam and then back, they will need to send these NFTs back exactly as they were originally (so that the same metadata hash computes). Moonbeam contract (or runtime) can verify the metadata of returning NFT - that’s perfectly OK if that’s a concern (@librelois). Nonetheless there might be a stratum of projects who are more open to cross-chain interoperability or even cross-ecosystem interoperability who may desire to involve communities from Ethereum, Polygon, Tezos, Solana, and what not. The Staging Area and Clearance Procedure logic can easily be implemented in Solidity, there’s no need even to touch Moonbeam runtime code as we’re designing this protocol to be abstract enough and support pure EVM.

Getting to your house analogy, here is a simple answer:

As long as the house is on it’s home land, yes, we can only do as much as the local government allows us to. But if it takes off to another world far far away, there might be different rules, or no rules at all! All we have in the home land is the deed record of the property, but it may completely change in the outer world. Now if chain A and chain B use the same NFT metadata format, the Reserve Chain (home land) doesn’t need to interfere with their interoperability, otherwise we risk to centralize this particular NFT project. Remember the CryptoPunks project. It is old enough, yet still alive. There could be so many utilities for this nice collection only if LarvaLabs didn’t apply so restrictive license to it.

What we’re trying to do is allow cross-ecosystem decentralization and remove the centralized decision maker from the NFT interoperability as much as the safety allows. On the opposite side, if we were stuck to Reserve Chain entity as the main governance to control an NFT changes, we would remove the capacity for new chains (chain A and chain B) to form good cooperation independently.

[librelois]

Hi @gz1 , nice to meet you too

@gz1

there might be ERC-721 contracts that are already deployed that may even implement some non-standard metadata logic.

No it’s not a non-standard problem, even the contracts that perfectly respect the ERC721 standards can’t conform to the protocol that @mrshiposha proposes and that you seem to support

Moreover, your protocol does not respect at all the reserve-based model, and poses several problems that I exposed in my previous post.

@gz1

there might be a stratum of projects who are more open to cross-chain interoperability or even cross-ecosystem interoperability who may desire to involve communities from Ethereum, Polygon, Tezos, Solana, and what not.

And this is the case of the Moonbeam project, I don’t understand what makes you think otherwise.

Such interoperability is quite possible via the “reserve-based model”, which is how all bridges work, even if they do not explain it in these terms.

When you transfer an asset from Ethereum to Polygon for example, the asset is not really transferred to Polygon, it stays on Ethereum on an account controlled by the bridge, and the other part of the bridge on the Polygon side is a derivative, a derivative with sometimes the same name, but a derivative anyway in fact.

@gz1

The Staging Area and Clearance Procedure logic can easily be implemented in Solidity, there’s no need even to touch Moonbeam runtime code as we’re designing this protocol to be abstract enough and support pure EVM.

Certainly, but this protocol is not compatible with the ERC721 standard, that would require to define a new standard for the smart contracts which would want to support your protocol, what could have been conceivable if your protocol respected the reserve-based model, which is not the case.

@gz1

As long as the house is on it’s home land

And this is still the case, the real asset always stays on its native chain (also called reserve chain).

@gz1

But if it takes off to another world far far away, there might be different rules, or no rules at all!

Exactly, that’s why I’ve always said (if you read my previous messages) that each chain does what it wants with its derivatives, there is no limitation, as long as it remains only on the concerned derivative.

You seem to think that I am defending a model that limits freedom, when this is not the case, quite the contrary

@gz1

What we’re trying to do is allow cross-ecosystem decentralization and remove the centralized decision maker from the NFT interoperability as much as the safety allows.

The entity that creates the NFT does not have to be centralized, it can be a DAO, another contract, or anything else.
But in any case, it is impossible to go against the rules provided by the entity that created the NFT, just like you can’t change the rules that govern the DOT token, even in the name of freedom.

If you want to do things with an asset that were not intended by its creator, you can already do it on your derivative.

This is for example what we do on moonbeam with the xc-DOT, a derivative of the DOT (an xc-DOT is not a DOT). We add to our xc-DOT derivative features that are not allowed by the relay, like liquid staking. This works perfectly as long as the user does not want to switch back to a real DOT.

It’s the same with NFT, if you want to do things that were not planned/authorized by the creators of the NFT, you can do it on the derivative.

And if two chains want to share additional features that the creator of the NFT did not foresee, the best thing to do is to create your native NFT whose mint/burn rules are linked to the lock of a specific derivative on your chain. This way this new native NFT is managed by a new reserve chain that you control with your rules.

What you have to understand is that the reserve-based model already allows you to do everything you need to do, it has none of the limitations you think it has, you just need to think about things the right way.

Let’s take an example with two chains A and B that want to manipulate an NFT P42 whose reserve chain is R.

The reserve-based model indicates that chains A and B will each create a derivative P'42 and P''42 respectively.

What the chain A can do is to create a native NFT U42 which can only be mint if P'42 is locked (and burn if P'42 is unlocked), this new NFT U42 takes the metadata that you want to take from P42, and adds/modifies what you want.

Any chain that wants to support this extended/modified protocol (for example the chain B), just needs to create a U'42 derivative whose reserve chain is chain A.

Thus, the user is free to add features to his NFT that have not been foreseen, and to transfer these features between compatible chains.

Each metadata protocol/extension just needs at least one “wrapping” chain, you just have to go through this chain to “upgrade” your NFT in some way. The NFT owner can then go through this chain to “upgrade” his NFT.

[mrshiposha]

Éloïs, I want to highlight that we clearly don’t understand each other, and we are focusing on the wrong things. Let me prove that our proposals are compatible (moreover, I believe that your variant of usage of the reserve-based model is one of the special cases or a sub-case of what I am proposing).

But first, I have to address this point:

Moreover, your protocol does not respect at all the reserve-based model, and poses several problems that I exposed in my previous post.

This is not correct; let me explain why. In the proposed solution:

• The NFT id (the “real” asset) is always located on the Reserve Chain under the sovereign account of another chain inside the Staging Area; The Reserve Chain always has the record of the current owner of the NFT.
• No communication is happening between Chain A and Chain B directly. The Reserve Chain is an essential arbiter that testifies ownership over an asset, and only the Reserve Chain relays new metadata hash set by the previous owner.
  Chain A and Chain B do not ever need to trust each other. The only source of truth is the Reserve Chain.

As such, the proposed solution adheres to the reserve-based model as described on the Polkadot reference page.

However, according to comments in your replies, my variant of the usage of the reserve-based model lacks one critical aspect: the metadata verification process made by the Reserve Chain every time the “real” NFT is transferred.

First of all, I have to highlight the fact that in my proposal the Reserve Chain doesn’t have to, but can, verify everything being transferred through it. The Reserve Chain can require all the NFTs to go through the Clearance Procedure regardless of their destination. That would be the sub-case of strict control of an NFT collection imposed by the creator of the collection. In my solution this is just an option. It is not obligatory. A collection creator can lock down the NFT attributes to make the NFT unmodifiable or non-upgradeable in order to secure its pristine integrity by demanding such a clearance during transfer. As far as this solution is concerned - sure thing, why not! However, it is my opinion that NFTs have a much greater potential that is expressed exactly in their ability to adapt and evolve. I feel a solution is needed that can provide this future for NFTs. That is why I want to leave up to the NFT creators the possibility of allowing the unrestricted transfers of NFTs through a reserve chain.

But also, it should be possible to restrict the NFT metadata when it is returning to the original logic because the cross-chain transfer and the NFT collection internal logic are different contexts and can have different rules.

I’m not against your proposal because it is a version of the case described above, where the Reserve Chain does restrict NFT transfers with metadata modifications, which is perfectly fine if NFT creators want that. And that behavior can be the default if the Reserve Chain chooses it to be.

For example, some NFTs are related to video games, and their properties/metadata can change depending on what the player does and what happens in the game. You understand that the game designers can’t allow the metadata used by the game to be modified by another unintended system.

Forgive me if I’m wrong, but I have the impression that you completely ignored the Clearance Procedure that exists on each chain. It verifies if the received NFT (which is located in the Staging Area) is in compliance with this particular chain’s rules (including the chain’s internal consensus system’s rules).
But again, you can enable the Reserve Chain to verify everything (do an extra Clearance Procedure in between). This behavior can be the default, but it is up to the Reserve Chain.

An important note: since the Reserve Chain is free in making that choice, it should send the information about that to the destination chain to ensure that the destination chain is aware of whether the metadata was verified by the Reserve Chain. The destination chain may or may not require that some or all the received NFTs must comply with the Reserve Chain’s internal rules.

I didn’t propose sending this information originally, but I have to take this case into account.

Any chain that wants to support this extended/modified protocol (for example the chain B), just needs to create a U’42 derivative whose reserve chain is chain A.

Yes, it is possible. However, I believe it is not an optimal solution. In that case, Chain B has to trust Chain A in terms of ownership. There is no guarantee that Chain A will always hold the original “real” NFT on the Reserve Chain S. And Chain B has no way to determine if the foundation of its “derivative of a derivative” has been lost.

And what if we want to transfer the NFT from Chain B, retaining Chain B’s modifications not foreseen by Chain A (acting now as the reserve chain)? According to the above, we must recognize Chain B as the reserve chain now; hence we are creating a “derivative of a derivative of a derivative”. I think we might end up with a “derivative of a derivative of (…n times…) of a derivative” situation; it is a chain of trust.

To conclude:

• The proposed solution follows the reserve-based model closely
• No teleportation happens ever
• A never trusts B, B never trusts A, both trust the Reserve Chain S
• NFT collection creator on S determines restrictive boundaries for the collection modification, if any
• S can impose these restrictions if that is a desirable action during cross-transfer

I hope we can agree that there is no fundamental contradiction. I can write a more formal document in the repo where we can engage in discussions during the review process. In the repository, I can also describe several usage scenarios to be as straightforward as possible in providing unambiguous clarification through examples.

Note: I have not forgotten your suggestion to move this “standards” repository to some “community-governed” organization in the future, and I wholeheartedly agree. I’m only suggesting a place to start.

[amitrovich]

Proposed solution is actually all that you ask for, and more, and that can be confusing.
To quote conclusion of the post bellow:
" * The proposed solution follows the reserve-based model closely

• No teleportation happens ever
• A never trusts B, B never trusts A, both trust the Reserve Chain S
• NFT collection creator on S determines restrictive boundaries for the collection modification, if any
• S can impose these restrictions if that is a desirable action during cross-transfer"
  We are giving the option, rather then an obligation, to manage all aspects of the NFT by the creator. Main reasons is that we are seeing advanced use cases that do require different relationships between creators, admins and owners of the NFTs, and we accommodate for that. This approach allows to leave the opinionated structures behind.

The team will make a more structured document to clarify concerns noted here by all.

[kckyeung]

I don’t think what we’re discussing here is a matter of opinion, but a matter of definition of what it means to be a reserve asset or a derivative asset.

A derivative asset does not have any intrinsic value per se, and its value is completely derived from another asset.

A reserve asset is the actual, real asset from which a derivative asset derives its value.

No matter what kind of process or operations that one performs upon these two kinds of assets, these two definitions do not change.

We can thus reason as follows: if the derivative asset somehow gains a way to obtain any sort of value that is not related to its corresponding reserve asset, then it is not a derivative asset, and should never be considered as one right from the start. I have alluded to this before in a previous post:

@kckyeung

What you’re saying here is that over time, the derivatives are able to obtain value on their own, independent and divorced from the value of the reserve asset. If there is no mechanism in updating the metadata for the reserve asset, we can thus conclude that the reserve asset is no longer fit for being a reserve, and so the reserve-backed asset transfer model does not fit this use case.

I want this point to be very clear. It is not the case that a parachain has the freedom to modify the derivative asset however it wants – if it gains any sovereign value that isn’t transmitted or reflected back to its reserve asset, then you are no longer looking at a derivative asset, but a brand new asset altogether.

I hear that some have criticized that this is a point of centralization for the reserve, and my answer to that is absolutely yes, but the criticism is not valid as it seems to have stemmed from the lack of understanding of the reserve asset model:

• Firstly, every parachain has the freedom to pick and trust which chains get to be the reserve, i.e. parachains willingly trust the authenticity and value of reserve asset on the reserve chain, and as a result, they willingly mint derivative assets that are worthless per se and functions only as a reflection of the value of the reserve asset stored on another chain.
• Secondly, consider the case where chain A and chain B do not trust each other, yet they still have to somehow transfer meaningful messages with each other. They both trust chain R, so they use R as an intermediary to transfer messages between themselves. In other words, chain A and B willingly chose R as the point of centralization, and so the criticism should be lobbied against A and B, and not R.

As a result, any metadata that gets produced as a result of interactions with the derivative asset is a property of the reserve asset, and not the derivative, regardless of what the engineering limitations are, because we have defined the derivative to have no value other than a mere reflection of the reserve asset’s value. The role of the reserve isn’t simply to be a safeguard of the reserve asset – it is the actual issuer, minter and owner of it.

[mrshiposha]

if it gains any sovereign value that isn’t transmitted or reflected back to its reserve asset

It is reflected back to the Reserve Chain in the second proposal! I absolutely agree with the definitions you wrote!

Only the Reserve Chain can relay the new metadata hash to the destination chain. The Reserve Chain can reject new metadata hash. The Reserve Chain can require the whole blob to verify if the metadata modification is correct. But also, the Reserve Chain can allow any modification IF it is what the NFT creator wants (in that case, the Reserve Chain authorizes all the changes, which is a trivial case of verification).

The Clearance Procedure can be required during the transfer by the Reserve Chain, but it is up to the Reserve Chain.

[mrshiposha]

With Keith’s given approval, I would like to share a summary of the off-forum conversation between Keith and myself regarding the topic.

---

What actually I’m proposing is a new cross-consensus mechanism for updating NFT metadata. It is not the thing currently supported by the reserve-based model.

I may have to make a formal proposal on how exactly to extend or build on top of the reserve asset model to support metadata updates.

[Szegoo]

I would like to propose an alternative solution that relies solely on basic non-fungible reserve transfers, offloading the metadata transfer issue from XCM.

I have described this alternative approach in this Hackmd post. Would highly appreciate some feedback on the idea.