[Originally written September 18, 2021]

Where’s my JPEG?

Since my first foray into the world of NFTs two weeks ago, I have wondered about the mechanics of how an NFT works. The token lives on the blockchain, but where is the JPEG stored? What is it that ensures a JPEG is indeed what is indicated in the smart contract? How do we know that the file will remain accessible?

I am far from the first to ask these questions, and there are numerous articles that address this very topic. I especially recommend Brady Dale’s article on NFT data storage and the need for standards as well as Kyle Tut’s article on data responsibility. However, I couldn’t come across a summary that includes both an explanation of the risk as well as how to check it for yourself. This article is my attempt in combining these two points.

When we buy ERC-721 JPEGs on OpenSea or any other NFT marketplace, what we are really purchasing is a smart contract on the blockchain that includes reference to metadata of a particular JPEG file. The contract and the content indicated in the metadata are generally located separately, as putting both on the blockchain would be cost prohibitive. What is holding these two pieces together is the TokenURI (Uniform Resource Locator), which is a link to the metadata saved outside of the blockchain. Only by ensuring this link stays the same can an NFT actually be immutable. Of course, there are exceptions such as the Cryptopunks being recently made fully on-chain.

There are two characteristics of a lasting NFT. The first one is what Brady Dale calls “persistence” in his article. An NFT is only a promise that the metadata was true at the time of minting, but if the metadata itself is not permanent, it may not be a promise that can extend into the future. The second characteristic is verifiability. Even if a JPEG referenced in the metadata is securely hosted somewhere, how can that link be truly trusted? The TokenURI is of utmost importance to ensure the immutability of the NFT. The question is, how can we ensure this link does not break?

The best answer to these questions so far seems to be the IPFS (InterPlanetary File System). The IPFS is a decentralized file system located on a peer-to-peer network. What differentiates the IPFS from other hosting methods is its ability to use content addressing. Once a file is put on IPFS, a unique hash called the CID (content identifier) is created for the file. This is not the same as a URL (uniform resource location) and can be understood as a link to the file itself and not to the location of where it is saved.

By using an IPFS CID in an NFT’s metadata, we can obtain both persistence and verifiability of the JPEG. The unique hash means only one JPEG on IPFS can match the CID that would be included in the metadata; uploading an altered file would create a different hash, and would not match the original metadata of the NFT. Justin Hunter’s article is a great walkthrough of the technical steps of how this is achieved.

The next question is, how can we be sure of where our own JPEGs are saved? Is our project using the IPFS? The following method explained in this reddit thread was quite effective, and I will walkthrough the steps below using OpenSea as an example. Please note this only works for ERC-721 tokens so far based on my own experience.

1. Open the page of the NFT you wish to check. Go to the details section and make note of the token type, the token ID, and the Etherscan address.

2. Click on the contract address to open Etherscan for the contract you wish to check, and scroll down and click on “Contract.” Then click “Read Contract.”

3. Go to the “tokenURI” and search using the token’s ID number and click Query.

4. The resulting string will be the link to the metadata JSON file. Check if the JSON is hosted on the IPFS. Also open the JSON in a different window to make sure the image data is saved on IPFS. Depending on your browser you may need to add a prefix http://ipfs.io/ipfs/ before the hash, which in the case of the example below starts with “Qme.”

If both JSON file and JPEG are on IPFS, then you can assume the ERC-721 NFT is immutable.

Through these steps if you see any cloud storage, or any static web address used in the tokenURI string, then questions may remain on the immutability of the NFT.

This article is a high-level summary of a complex topic. Alternatives such as ARweave may replace IPFS as the best practice, and I have not addressed the durability of pinning on the decentralized network (this is a topic for another day). As standards do not exist, DYOR (do your own research) cannot be more strongly advised.

Earlier this month, NFT art was being compared to buying Picasso in 1932. While I tend to agree with that statement, we must also critically assess the permanence and verifiability of NFTs to ensure they are truly immutable. Intentional and unintentional rug pulls will occur. A commercial cloud provider or a server owner may decide to shut down. Also ideologically, what does it mean if we are hosting symbols of Web 3.0 on Web 2.0 cloud servers? Hopefully it will not come to pass, but it is not very difficult to imagine a future where we have many NFTs that all show “invalid URL.”

[Originally written September 18, 2021]

Where’s my JPEG?

Since my first foray into the world of NFTs two weeks ago, I have wondered about the mechanics of how an NFT works. The token lives on the blockchain, but where is the JPEG stored? What is it that ensures a JPEG is indeed what is indicated in the smart contract? How do we know that the file will remain accessible?

I am far from the first to ask these questions, and there are numerous articles that address this very topic. I especially recommend Brady Dale’s article on NFT data storage and the need for standards as well as Kyle Tut’s article on data responsibility. However, I couldn’t come across a summary that includes both an explanation of the risk as well as how to check it for yourself. This article is my attempt in combining these two points.

When we buy ERC-721 JPEGs on OpenSea or any other NFT marketplace, what we are really purchasing is a smart contract on the blockchain that includes reference to metadata of a particular JPEG file. The contract and the content indicated in the metadata are generally located separately, as putting both on the blockchain would be cost prohibitive. What is holding these two pieces together is the TokenURI (Uniform Resource Locator), which is a link to the metadata saved outside of the blockchain. Only by ensuring this link stays the same can an NFT actually be immutable. Of course, there are exceptions such as the Cryptopunks being recently made fully on-chain.

There are two characteristics of a lasting NFT. The first one is what Brady Dale calls “persistence” in his article. An NFT is only a promise that the metadata was true at the time of minting, but if the metadata itself is not permanent, it may not be a promise that can extend into the future. The second characteristic is verifiability. Even if a JPEG referenced in the metadata is securely hosted somewhere, how can that link be truly trusted? The TokenURI is of utmost importance to ensure the immutability of the NFT. The question is, how can we ensure this link does not break?

The best answer to these questions so far seems to be the IPFS (InterPlanetary File System). The IPFS is a decentralized file system located on a peer-to-peer network. What differentiates the IPFS from other hosting methods is its ability to use content addressing. Once a file is put on IPFS, a unique hash called the CID (content identifier) is created for the file. This is not the same as a URL (uniform resource location) and can be understood as a link to the file itself and not to the location of where it is saved.

By using an IPFS CID in an NFT’s metadata, we can obtain both persistence and verifiability of the JPEG. The unique hash means only one JPEG on IPFS can match the CID that would be included in the metadata; uploading an altered file would create a different hash, and would not match the original metadata of the NFT. Justin Hunter’s article is a great walkthrough of the technical steps of how this is achieved.

The next question is, how can we be sure of where our own JPEGs are saved? Is our project using the IPFS? The following method explained in this reddit thread was quite effective, and I will walkthrough the steps below using OpenSea as an example. Please note this only works for ERC-721 tokens so far based on my own experience.

1. Open the page of the NFT you wish to check. Go to the details section and make note of the token type, the token ID, and the Etherscan address.

2. Click on the contract address to open Etherscan for the contract you wish to check, and scroll down and click on “Contract.” Then click “Read Contract.”

3. Go to the “tokenURI” and search using the token’s ID number and click Query.

4. The resulting string will be the link to the metadata JSON file. Check if the JSON is hosted on the IPFS. Also open the JSON in a different window to make sure the image data is saved on IPFS. Depending on your browser you may need to add a prefix http://ipfs.io/ipfs/ before the hash, which in the case of the example below starts with “Qme.”

If both JSON file and JPEG are on IPFS, then you can assume the ERC-721 NFT is immutable.

Through these steps if you see any cloud storage, or any static web address used in the tokenURI string, then questions may remain on the immutability of the NFT.

This article is a high-level summary of a complex topic. Alternatives such as ARweave may replace IPFS as the best practice, and I have not addressed the durability of pinning on the decentralized network (this is a topic for another day). As standards do not exist, DYOR (do your own research) cannot be more strongly advised.

Earlier this month, NFT art was being compared to buying Picasso in 1932. While I tend to agree with that statement, we must also critically assess the permanence and verifiability of NFTs to ensure they are truly immutable. Intentional and unintentional rug pulls will occur. A commercial cloud provider or a server owner may decide to shut down. Also ideologically, what does it mean if we are hosting symbols of Web 3.0 on Web 2.0 cloud servers? Hopefully it will not come to pass, but it is not very difficult to imagine a future where we have many NFTs that all show “invalid URL.”