In a previous article I showed you at a high level what an NFT is: an entry on the blockchain that has the information of who owns the image and where the image is located. I depicted that relationship with the image below.
Notice how the image itself is not stored on the blockchain where the smart contract is. Storage space is extremely expensive on a smart contract blockchain. In the previous article I mentioned that this fact had profound consequences on the risks of owning an NFT. In this article we are going to explore those risks.
To explain the risks I’m going to continue the story I used before that involved Bob, Alice and Jim. To recap, Bob was the creator of the NFT, Alice bought it from Bob and Jim bought it from Alice. Bob is the creator of the NFT while Jim is the current owner.
Why is Bob relevant here if he doesn’t own the NFT anymore? Well, when you “mint” (create) an NFT you get to decide where the image referenced by the NFT is going to be stored. Bob could have decided to store that image on a server like Amazon AWS or even something simpler like his Dropbox and this is the crux of the problem. Even if the smart contract says that Jim is the owner of the NFT, the image is stored on a server under Bob’s control.
Before going any further I must confess that I over simplified things a little too much for the sake of clarity. The smart contract that defines the NFT does not directly point to the image location, it does it indirectly through a metadata file. Besides the image location, the metadata file has also information about the NFT like its name and description among other things. This information is displayed on NFT’s marketplaces like OpenSea as part of its listing.
To summarize, an NFT is a combination of a smart contract, a metadata file and an image. I’m going to refer to the metadata and its image as the assets of the NFT. Both of them are stored on Bob’s server as shown below.
What happens if one day Bob deletes the image of the NFT by mistake? Now Jim owns an NFT that has no image! You can imagine how upset Jim will be if that ever happens.
Bob could make a different type of mistake and instead of deleting the image, he could delete the metadata file. That’s even worse, not only the NFT has no image, now it has no name or description to be listed on an NFT marketplace. Jim’s face might be getting red with anger.
A third scenario could be that Bob forgets to pay for his server and now both the metadata and the image are unreachable. Poor Jim, things are not looking up for him. All the money he paid for the NFT is now worthless.
So far we have assumed that Bob is an honest individual that just happens to make mistakes but what if Bob is really a scammer or a troll? He could very well change the image referenced by the metadata with some other image.
Imagine Jim proudly showing his NFT to his friend only to find out that his expensive ape is now a poop emoji. At least his friends might have a good laugh. Jim, not so much.
An alternative way of pulling the same “joke” is by Bob modifying the metadata file to point to a new image. A blockchain is immutable but a server is not. Bob can modify anything he wants whenever he wants.
What can Jim do to protect himself from these problems? First of all Jim, don’t ever buy an NFT whose assets are stored on someone’s server. If you ever see a reference to AWS, Heroku, Dropbox or similar in the URL of the metadata or the image file that should be your first red flag. What Jim can do is to only buy NFTs whose assets are stored on a decentralized storage.
In the next article I’m going to explore IPFS + Pinata and Arweave as decentralized alternatives for storing NFT assets in a way that would give Jim peace of mind.
