# Solving NFT cross-chain transfers

Performing fungible cross-chain transfers via XCM holds significant utility within the Polkadot ecosystem and is a vital component of developing cross-chain applications. However, the same cannot be said for cross-chain non-fungible asset transfers at present. From the technical aspect, executing NFT transfers using XCM is feasible, but a critical issue remains unresolved: the transfer of metadata still remains a challenge.

## Motivation

Let's first understand why it's important to transfer NFT metadata across chains. The main purpose is to enable smart contracts and pallets on various chains to integrate with NFTs that originate from other chains. These applications are likely to base their logic on the metadata of the NFTs.

Although this document addresses a general problem within the ecosystem in an abstract manner, I'd like to present a compelling example of an application requiring NFT metadata: Coretime marketplace. In this scenario, NFTs represent 'Regions' (with each NFT representing a period of Bulk Coretime). Access to the metadata is crucial here, as it determines the value of the Region. For instance, Regions lasting one week are generally less valuable than those lasting two weeks.

There have been [solutions](https://forum.polkadot.network/t/cross-chain-nft-transfer/2080) proposed to address the metadata issue in cross-chain NFT transfers using XCM `Transact`. However, the paradigm introduced here aims to resolve this problem in a simpler manner that doesn't require the metadata to be transferred using XCM.

## Proposed paradigm

I propose a paradigm that avoids the need to transfer NFT metadata via XCM messages. Instead, this approach works on top of a basic XCM non-fungible reserve transfer.

So how do we actually get the metadata of an NFT to the destination chain?

The solution involves creating a Wrapper contract(the same principles would apply to a pallet, but for the purposes of this document, we will refer to this Wrapper as a contract) for the NFT collection whose items are subject to cross-chain transfer. This wrapper contract will implement the following interface, in addition to adopting an NFT interface such as [PSP34](https://github.com/w3f/PSPs/blob/master/PSPs/psp-34.md):

trait MetadataWrapper {
    fn init(&mut self, item_id: ItemId, metadata: Metadata) -> Result<(), Error>;

    fn remove(&mut self, item_id: ItemId) -> Result<(), Error>;

    fn get_metadata(&self, item_id: ItemId) -> Result<VersionedMetadata, Error>;
}

This interface provides three publicly accessible smart contract functions, each with an underlying implementation containing the following logic.

> It is important to note that in the case of a contract, the Wrapper would interact with the underlying NFT pallet of the given parachain, likely through a chain extension or `call_runtime`.

### `init`

A function for minting a non-fungible wrapped asset and initializing the metadata of it. It can only be called if the specified `item_id` exists within the given collection and the caller is the owner of the item.

### `remove`

A function for burning the wrapped token and removing the metadata associated with a non-fungible asset. This function is only callable by the wrapped token owner. Ultimately, this function will result in returning the underlying non-fungible asset to the owner.

### `get_metadata`

A function to read all the metadata associated with a specific item in the collection. The return type of this function is `VersionedMetadata` which is a wrapper around the `Metadata` type.

struct VersionedMetadata<T> {
    version: u32,
    metadata: T
}

The `version` field in the Wrapper contract is incrementally updated whenever the same item is initialized multiple times.

### Data validity

The Wrapper contract described earlier allows item owners to initialize their asset metadata with arbitrary information. However, there's no guarantee that the provided data is valid, so how is this any good?

One crucial characteristic of the Wrapper contract is that it stores the metadata version even after an asset is removed. Updating the metadata would require the asset to be removed and initialized again. Since the Wrapper contract maintains versions of the metadata for each item, such a maneuver would be conspicuous, making any change in metadata easily detectable.

This doesn't yet address the question of data validity, but it provides us with a foundation to build upon. The key point is that we are aware, from the perspective of the Wrapper contract, that the asset's metadata cannot be altered without that being noted in the contract.

All the code executed within a blockchain's runtime is placed in a constrained environment. Accessing data from outside this environment is possible; however, the requirement for appropriate proofs to verify the data's validity makes this a non-trivial problem to solve.

The approach I am proposing offloads this process to the 'external' world, specifically to clients executing contract functions. This implies that clients involved in these contract calls will bear the responsibility of verifying the data. Through this verification process, clients can then protect themself from executing transactions based on incorrect data.

### High-level overview

To better depict how this approach works we can split this process into two parts:
1. Cross-chain NFT transferring
2. Metadata verification

#### 1. Cross-chain NFT transferring

<p align="center">
<img width="400" src="https://i.postimg.cc/MHbXq56h/NFT-Transfers-5.png" />
</p>

The flow of this diagram should be easy to follow. We have a parachain that serves as a reserve for a specific collection, and a Para A that is capable of handling incoming non-fungible reserve transfers. The steps to transfer an NFT, along with its metadata, are as follows:

1. An item owner on the reserve chain initiates a reserve transfer of a specific item to Para A.
2. Para A receives a notification that an item has been deposited into its sovereign account, and then proceeds to mint a derivative item and deposit it to the beneficiary.
3. After receiving the item, the beneficiary can then initiate a call to the Wrapper contract to set the metadata associated with the NFT.

From the UI perspective this process can be easily abstracted away from the user. From their perspective they only have to sign two transactions:
1. One of them to perform the actual reserve transfer
2. The other transaction is to set the metadata, which should be automatically set by the frontend code, not entered by the user manually.

#### 2. Metadata verification

<p align="center">
<img width="800" src="https://i.postimg.cc/50F1cYbr/NFT-Transfers-8.png" />
</p>

In the above diagram, we have five key components:

1. Reserve Para, which serves as a reserve for a specific collection.
2. Para A, a parachain that supports smart contract deployment and incoming reserve transfers from the Reserve Para.
3. Wrapper contract, a smart contract that implements the previously described `MetadataWrapper` interface.
4. Contract A, an arbitrary smart contract that includes interactions with the Wrapper contract within its logic.
5. Client, an external actor. E.g. a UI frontend application.

The following description outlines the process of verifying metadata from the perspective of a client interacting with Contract A:

1. Fetch dependencies. This step involves the client determining the specific items that the client-initiated call depends upon. While it's up to the client and Contract A to decide on the implementation of this logic, it's likely we will see the following pattern implemented in contracts that depend on Wrapper contracts:

fn metadata_dependencies(&self, call: ContractCall, params: Params) -> Vec<ItemId> {
    match call {
        ContractCall::Foo => {
            // Returns a vector containing all the ItemIds of the items that 
            // the contract would depend on during the execution of this call.
            self.get_foo_dependencies(params)
        }
    }
}

2. Once all dependent items for the call are identified, the client retrieves the metadata for each item from both the Wrapper contract and the reserve chain.

3. Having fetched the metadata from both sources, the client's next step is straightforward: verify if the metadata matches. If there is any difference, the metadata in the Wrapper contract is incorrect, and proceeding with the originally intended call is not a good idea.

4. If the metadata is correct the client initiates the contract call, supplying the metadata version of each item as an argument. It's the responsibility of Contract A to ensure that the metadata version of all items remains unchanged. This check is crucial to prevent front-running attacks, where the item's metadata could be altered in the interval between the client fetching the metadata from the Wrapper and the actual transaction.

After successfully completing this four-step process, the client has confidently and securely made a call to Contract A 🥳