The ERC721 Metadata JSON Schema for Non-Fungible Tokens (NFTs) was initially designed to bridge Virtual Reality (VR) items to blockchain based exchanges.

With VR environments moving toward in-game monetization, unique virtual items with in-game value are ideally paired with unique (ie. non-fungible) tokens. The virtual item is utilizable only by the current NFT owner within the virtual reality or metaverse it was designed for. To support game evolution and continuous development models, no virtual item data was ever stored or protected on-chain beyond an item identifier and Universal Resource Identifier (URI) that connects the NFT to the online VR world. This URI is defined to reference a JSON metadata file that itself has ‘name’, ‘description’, ‘image’ and ‘attributes’ as needed to showcase the virtual item outside their virtual reality or metaverse.

The game creator maintains complete control to change the image, attributes and underlying algorithmic behavior of a game item. For example, an NFT representing a unique ancient sword could become a unique plow after an update. Technically speaking, everything about the virtual item is changeable with a metafile based NFT, except the token id. This is because the NFT (web3) has only a URI to the metadata (.json) file (web2). It is the metadata configuration file that truly defines the image and attributes of the item — and this metadata file can be changed at any time by whoever hosts the file (ie. VR/metaverse creator company). With game creators hosting the NFT metadata everyone was happy; the games/art/render engine could be improved, and creators had a vested interest in maintaining the integrity of the NFT game items and thus preserving the NFTs real world value.

It was at this point that the industry took a turn for the surreal. Artists and opportunists outside of virtual reality environs had a Fear of Missing Out moment, and whether misunderstanding the technology or not, began to release independent artistic NFTs that were not part of any Virtual Reality environment (ie. VR or metaverse). These NFTs were designed to be exchangeable on third party exchanges (OpenSea, Rarible, etc.) and included some notion of ownership (or not) of the artwork (pictures/textures/algo’s). Yet images had to be public or the NFT could not be displayed on these public exchanges. To legally represent independent artistic ownership requires an NFT be designed differently than a unique VR game item.

Creators of digital art NFTs that exist independent of any virtual world should carefully consider options for storing and referencing the metadata and image files. To better understand the problems, let us review the three (3) moving parts of a metadata NFT — the NFT on-chain, the metadata file and the image file. When minted, the NFT token id and metadata URI are stored immutably on-chain. The metadata.json configuration file contains the name/value pair of the final part of an NFT, the ‘image’ URI. To say another way, a web3 NFT contains a web2 link to a configuration file which contains another web2 link to an image file that is displayed by exchanges.

To walk through an example, most NFT viewers/exchanges first read the smart contract token name and token ids. Then for each token id, tokenURI() is read from the blockchain and with this URI the NFT viewer opens an HTTPS connection to read/parse the expected .json configuration file. This file contains a list of name/value pairs, one of which is “image” with a value of another URI. If the URI and .json file are valid and the “image” value pair is found, the NFT viewer opens another HTTPS connection to download the image file. NFT viewers then typically archive the image in a database/cloud for caching and serving to other NFT viewers around the world. What is of particular importance to independent artistic NFTs is how to use the URI and image storage for provenance and longevity.

IPFS is commonly leveraged for permanent storage and can help establish artistic provenance for independent art NFTs. A unique 1-way hash is legal proof of possession of a file or document, defined in this document to be a Proof of Existence (PoE) hash. IPFS stores a 1-way hash of each file data chunk, timestamped and signed in a transaction record on-chain. The first blockchain transaction of a file’s existence proves time of first possession and can be vital to demonstrating artistic provenance (ie. the original creator).

IPFS provides immutable date and creator provenance but does have a caveat. Artwork ownership provenance is far from guaranteed by IPFS, especially if transactions were not signed directly by the creator’s wallet address, and that same wallet used for the NFT minting. For example, if the artist used third party on-chain recording parties or services for IPFS and/or NFT minting, provenance would not be cryptographically deductible from on-chain transactions but would still require supplemental documentation.

Another challenge of IPFS is that the NFT tokenURI()function requires a web2 endpoint provider (HTTP to IPFS), such as Infura. If the IPFS provider of the web2 endpoint (URI) has bandwidth issues or changes their use terms, the NFT may no longer display reliably in-wallet or on exchanges. As such, a publicly exchangeable art NFT independent of any metaverse has technical limitations that limit NFT longevity. This is because the creator (ie. NFT minter) defines the immutable endpoint (web2 URI) that all subsequent owners must then depend on.

Let’s try to understand better what the root of the problem is. By default, OpenZeppelin’s industry standard implementation of ERC721 metadata defines the token URI to be immutable (ie. defined at minting and then unchangeable). If this web2 link ever fails, the NFT will no longer load/display correctly. Even if the files are still available somewhere on-line (IPFS), the NFT will never display correctly again if the tokenURI() is unchangeable and access to the resulting link is lost.

To solve these problems the Immutable Ecosystem can be used to mint independent art NFTs that store the PoE hash of the unique artwork in the NFT during minting (write-once). This establishes and maintains artistic provenance outside of IPFS, as well as introduces fraud detection and reverse lookup (by image) capabilities. While an NFT is a web3 link to web2, reverse lookup adds a web2 to web3 link to prove artistic provenance. By embedding the root of provenance into the NFT, it unlocks value for the future owners as the tokenURI() no longer needs to be immutable to prevent fraud.

Let us dive deeper and explain this in more detail. A Proof of Existence (PoE) hash is a provably unique 1-way computation upon file data used to validate and prove existence of a particular file. Only the exact same data, in the same order, can compute the same hash (ie. file is unchanged). When an artist records a PoE hash on-chain they establish the root provenance for their digital creation (blockchain time and signed transaction ownership). This provenance of ownership is desirable to prove the art image was in possession by the artist first (ie. it was their creation).

The PoE of the artwork is recorded with the NFT during minting and is unchangeable afterward. If the PoE hash matches the “image” file, the unique digital artwork is authentic, regardless of the metadata URI or image URI. With provenance outside of IPFS, the metadata URI can become changeable and use any cloud or hosting provider without loss of cryptographic provenance. Also, if the entire image is captured in a single PoE hash (instead of reconstructing from chunks on IPFS), then this hash can be used by 3rd parties (open exchanges, etc.) to uniquely identify and verify the authenticity of the image the NFT represents. With users able to reverse lookup the NFT from the provenance of the image file itself (SHA256 hash of), counterfeit items will be easily identified, reducing fraud by showcasing authenticity to consumers.

With PoE outside of IPFS, cloud hosted image URLs can be dynamically changed as file hosting options morph in the future. All the while the provenance of the artists’ original work stays immutably recorded in the NFTs PoE hash at the time of minting. With the 1-way hash uniquely identifying the digital artwork (ie. image file), the .json metadata file and the image storage location can be changed as desired by the current and future owners. As long as the metadata URI points to an image file with the same unique 1-way hash as stored in the NFT, the image, provenance and thus artistic ownership is provably authentic by 3rd parties.

Now NFT owners are truly free to utilize any private storage or cloud provider at any time during ownership, not just defined by the creator during minting. Auctioning and post-creation exchange and relisting all may have different privacy settings. On-chain PoE for art NFTs enables the token owner to safely call setTokenURI() to change the location of the metadata file of the NFT. NFT owners can then take their digital artwork private or to a hosting provider of their choice. All the while preserving provenance and the option of making the NFT public again prior to sale/auction at a later date.

Fundamentally the key improvement is to track provenance on-chain in the NFT itself instead of relying on IPFS for independent art NFTs.

This allows dynamic URIs to avoid locking the web2 endpoints (metadata and image file) of an NFT.

While it does not prevent or negate the benefits of IPFS, if PoE is established in the NFT itself, IPFS becomes an option and not a necessity. With IPFS endpoint providers including licensing terms that allow them to change terms at any time — your NFT and images are accessible under their terms.

The smart contracts require artists to mint each Creator NFT with a unique PoE hash and include an owner editable setTokenURI(). Independent artists can now mint premium NFTs that are owner manageable and include artistic provenance. NFTs are a one-way link from web3 to web2 — adding a PoE hash adds a link the other direction, from web2 to the web3 proof of authenticity and creator provenance. To summarize, the flexibility of owner-defined web2 endpoints can be unlocked by securing the provenance of the original artwork within the NFT itself.

Combined with ImmutableSoft NFTs minted with Ricardian contract transfer requirements, an NFT can be made to legally represent any asset. Most titled assets can only be transferred/exchanged with those who have also completed paperwork and have been approved by the NFT issuer or third-party intermediary. Follow any of the links above to learn how you can best leverage our smart contract solutions within your products.

Provenit (own provenance).