We can start with this repository to move forward quickly, but it would be nice to be able to move it in the future under an organization managed by the community, it can be the
open-web3-stack organization or another one
Yes, it’s perfectly fine to quote/recommend the pre-image pallet in any documentation/examples/tutorials around the NFTs transfer, I’m just saying that it shouldn’t be integrated in the formal specifications.
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.
All these considerations are not specific to moonbeam, they are inherent to the “reserve based transfer” model.
It does not impose any, the derived chain can modify what it wants on its own network, but if it wants its changes to be taken into account by the reserve chain (and therefore by any other chain that derive this NFT), it needs the agreement of the reserve chain.
Yes, the NFT can have the old one + some extension, I agree. But a chain that has its own extension for NFTs metadata cannot force other chains to recognize this extension.
When the destination chain receives a message from the reserve chain, it trusts the reserve chain and considers as true everything the reserve chain sends. So the reserve chain can only send data that it has been able to verify itself.
If the destination chain wants to recognize an extension of the sending chain but this extension is not recognized by the reserve chain, then the 2 chains which are not reserve must define their own protocol to pass the data related to this extension.
Concerning Moonbeam in particular, it is possible to define some contract interfaces allowing to know if a smart contract supports such or such extension provided by such or such parachain/pallet or other, everything is possible, provided that it remains optional.
In the general case, a contract that only complies to ERC721 and nothing else does not allow to modify the metadata, so we must be able to handle this case.
I understand that this is frustrating, but it is necessary to preserve security and ensure that the rules defined by the designer of an NFT are respected.
We will do our best to support the NFT extensions you wish to provide, but we cannot force our users to accept these extensions in their smart contracts, especially since some ERC721 smart contracts are already deployed and not upgradeable.
The specifications for xc-NFTs must assume as little as possible if they are to be widely adopted, so they cannot assume support for this or that way of modifying metadata.
I think it is better for the user if the transfer fails as soon as possible in case of incompatibility, to avoid wasting time and money for nothing.
What the reserve chain can optionally do (but it doesn’t have to be mandatory) is to store a request for metadata modification while waiting for someone (basically any signed origin) to inject the whole new metadata, the reserve chain then checks if the state transition respects its rules, there are then 3 possible results:
- The metadata change is accepted: the reserve chain then performs 3 distinct operations (the reserve chain must first check that enough fees have been paid for all these operations):
- forward the XCM message in the request to the destination chain (with a topic that contains the new metadata hash)
- send back an XCM message to the initial sender chain (to unlock and burn the derivative on the sender chain)
- Move the NFT ownership from the sovereign account of the sender chain to the sovereign account of the destination chain
- The metadata change is not accepted: the reserve chain then perform one operation (the reserve chain must first check that enough fees have been paid for this operation):
- Send back an XCM message to the initial sender chain with the error, the initial sender chain can either unlock the NFT and cancel the transfer or still the NFT locked and rely on its governance or any other process to find a solution.
- Not enough costs have been provisioned by the user who initially requested the transfer or/and the user who injected the new metadata on the reserve chain: the metadata injection action/extrinsic must fail with an error like “TooExpensive”.
With such a system, what we could do on the Moonbeam side when we receive an “xc-NFT XCM message”, is to ask to the contract that handle this NFT if it support an interface (to be defined) to mutate the metadata in the “xc-NFT way” (we can do that thanks to EIP165).
If this is the case, we store the request and follow the process I described above, but if it’s not the case, we must throw an error and interrupt the NFT transfer.
Obviously, the reserve chain should first verify that the new hash is not the same as the old one, if it’s the same, the reserve chain should forward the transfer directly.
This imply 3 user actions for transfer from a non-reserve chain to a non-reserve chain, but I think we can’t do better.