Create a serialization mechanism to derive a URI compatible with EVM NFT platforms

[sisyphusSmiling]

Issue To Be Solved

Metadata bridging will be critical to NFT utility and interoperability across VMs.

As of now, Cadence NFTs most commonly store metadata onchain, resolving metadata to arbitrary views (though some more common than others), while EVM NFTs often store them offchain and resolve token and contract-level metadata via URIs (tokenURI(uint256) and contractURI()). The contents of the returned URI may be a pointer to an HTTP, IPFS, Arweave, etc. file or could be URL-encoded JSON which itself contains metadata and either a pointer to a media file or an encoded SVG.

(Optional): Suggest A Solution

The main takeaway from above is that EVM projects have a project-specified URI to commit to Cadence while Cadence projects do not have a URI to commit. The bridge must then do at least one of two things

1. Provide a mechanism for Cadence projects to specify the URI they want committed when bridging to EVM on a token & contract level (see Update standards, simplify COA bridging interface & intro project-specified URI view #14 and Add EVMBridgedMetadata & URI to MetadataViews flow-nft#203)
2. Serialize common NFT metadata views with attributes that overlap with common EVM NFT metadata formats (see OpenSea's metadata docs) in a manner that can be resolved by clients when requesting the bridged ERC721.tokenURI value.

These two are not mutually exclusive, however relying on 1/ alone will not be sufficient as it relies on projects to implement a reliable view returning a URI conforming with standards they are likely not familiar with.

The open question regarding 2/ then is the format that metadata should be serialized to. The most straightforward and lightest lift from the perspective of the bridge efforts is to serialize metadata into OpenSea's metadata format as URL-encoded JSON by attempting to resolve NFTCollectionDisplay and Display from a given NFT as well as its attributes from Traits.

Alternatively, the bridge could either derive some URL either via content-based addressing or appending metadata values into a URL which resolves to some proxy service that would serve the JSON from the URL or query escrow for the NFT's value and serialize on request.

See this thread for community discussion on the topic.

Regardless, it's clear that feedback points to the importance of not only bridging NFT metadata, but also doing so in a manner that conforms to ecosystem expectations in the bridged NFT's target VM and serialization. Since we cannot rely on project's specifying their metadata representation themselves, a metadata serialization mechanism will undoubtedly play some role in the finally aligned solution and thus deserves effort.