ERC-4804: A New Shield Against Broken NFTs

As far as NFT metadata is concerned, the ghosts of the past will continue to haunt us.

Of course, there are a variety of ways to underpin the media of NFTs. For the sake of durability I've always gravitated toward onchain projects, of which there are many shades, like:

• Semi-onchain — i.e. when some metadata is stored onchain, but not all
• Hashed onchain — i.e. when NFT contracts host a cryptographic hash that permanently references offchain data
• Hybrid onchain — i.e. when a project deploys a separate onchain collection to archive an earlier offchain collection
• Fully onchain — i.e. when all the data needed to display an NFT lives within the collection's smart contract
• Inchain — i.e. when NFT visuals are generated live by fully onchain code at render time rather than stored as files

Naturally, there are pros and cons to each of the methods above. Yet broadly speaking, putting things onchain is costlier than offchain storage and requires more smart contract expertise.

As such, offchain storage, when only NFT tokens live onchain while their metadata is hosted on external platforms like IPFS or private servers, is the status quo for most NFT collections that have arrived over the past 5 years.

The problem here is that IPFS pinning often wanes with time, and many startups go bust and shutter their private servers. In these cases, only the tokens remain as worthless remnants that can no longer display their imagery.

There are plenty examples of lost NFTs from recent years I could cite, but you can see for yourself. For instance, the new NFTimeless app lets non-guest users get a condition report for their NFT collections. It will show which NFTs are offchain and broken.

For collections that are already broken, there's nothing to be done. But fortunately for projects with offchain storage that haven't been lost yet, they can employ a rising technique for retroactive durability that doesn't require deploying a second collection: ERC-4804.

This standard is like HTTP-style system for Ethereum, in that it introduces a new kind of URI web3:// that lets NFT metadata be fetched directly from smart contracts. The URI doesn't point offchain, but rather describes an onchain read.

In other words, when an NFT marketplace sees a web3:// URI, it can translate the provided ENS link into an eth_call, execute it against a smart contract, and treat the returned data as NFT metadata.

For example, imagine an NFT contract whose tokenURI(123) returns
web3://testcollection.eth/tokenURI/123 ... here’s what happens under the hood:

1. A marketplace resolves testcollection.eth via ENS to an Ethereum address
2. It calls tokenURI(uint256) on that contract with argument 123
3. The contract returns JSON metadata (e.g. name, description, image, attributes)
4. Finally, the marketplace renders the NFT using that data, just like it would with IPFS though without any offchain dependencies

All that said, this approach means metadata can be generated or stored entirely onchain, either in the same NFT contract or in a separate metadata resolver contract. The web3:// scheme makes calls here verifiable and independent of any gateway staying online.

This is a powerful capability. Why though?

Namely because it's a straightforward way for old NFT collections to keep their original token contracts untouched, deploy new onchain metadata contracts, and update their baseURIs to point to the relevant web3:// ENS link. Essentially it's just a new pointer system, so no NFT migrations are needed.

Accordingly, after any updates marketplaces would fetch metadata directly from Ethereum itself, and thanks to the URI anyone can reproduce the necessary calls for this forever.

This standard also matters because even projects that do store their art and metadata onchain have historically been forced to publish ipfs:// or https:// baseURIs as apps and wallets didn’t know how to read anything else. Now, though, these projects have a viable onchain alternative.

Another important wrinkle here is that OpenSea just added support for ERC-4804. It's a big validation for the standard and an indication that it can gain serious traction from here. I know the minting platform Carve is already planning on adding support, too, and more integrations will follow.

Thus as we look ahead at the possibilities of the new year, one thread I'll be watching is ERC-4804 adoption. It could quietly become one of the most important tools we’ve seen yet for NFT durability in the Ethereum ecosystem, and in short order as well.