ERC-4955 NFT Vendor Metadata Extension (Vendor Metadata Extension for NFTs)
Final · NFTs & multi-token · created 2022-03-29
A standard that adds a namespaces field to NFT metadata JSON so that project-specific data (such as 3D model information) can be kept in one place.
Why it is needed
NFT metadata standardizes only a name, a description, and an image. However, services such as metaverses and marketplaces need extra data, such as 3D models, to display an NFT within their own interface. Projects such as Decentraland, TheSandbox, and Cryptoavatars each use their own aesthetic style and data format, so a 3D model made for one project is not compatible elsewhere. Without a standard place for such project-specific data, each service has to store and look up data in its own way, and it is hard for a wallet or marketplace to read and use any NFT the same way. This standard solves the problem by adding namespaces, a project-specific space, to the existing metadata JSON.
In depth
Definition of the namespaces Property
A new property called namespaces is added to the metadata JSON schemas of EIP-721 and EIP-1155. Its type is object and its description is "Application-specific NFT properties". Inside this property, there is one object for each project (vendor). The existing fields name, description, and image are kept as they are, so this extends the existing schema without breaking it.
Two Ways: Embed Data Directly or Link by URI
The example shows two ways of writing entries. First, properties such as prop1 and prop2 are placed directly under each project name in namespaces. Second, only a single URI string is written for each project name, and the actual data is fetched from that address. The second approach can be used to reduce the size of the JSON response.
Why Namespaces Were Chosen Over a Common Style
Each metaverse uses its own armature (the skeleton of a 3D model) and aesthetic style, so even with the same GLB or GLTF extension, each platform needs a different model. Platform-specific representation files also differ, such as Decentraland's wearable item settings like replaces, hides, category, and bodyShapes. Because there is no common style standard shared by all platforms, such as a "Decentraland style", the design lets each vendor find and render the model it needs directly from the namespace under its own name, for example with fetch(metadata.namespaces["PROJECT_NAME"].uri), instead of classifying by a style field.
Why Extend Existing Metadata
Most projects on Ethereum use contracts that cannot be upgraded. A standard that required a new contract implementation would force existing projects to redeploy their contracts, which takes time and wastes money. Using the existing metadata fields of EIP-721 keeps the required changes to a minimum. The standard also explains that since metadata JSON already carries a representation of the asset in the image field, it is reasonable to keep all representations of an asset in the same place.
Handling Existing Projects That Cannot Modify Metadata
An existing project that cannot modify its metadata response (schema) can create a new smart contract that returns the updated metadata schema based on tokenId. However, each service must accept a contract linked this way as valid before it can fetch the metadata through the tokenURI function.
Things to watch out for
- Gateway Caution When Fetching tokenURI: When the tokenURI method uses an http gateway or IPFS, the same security considerations as EIP-721 apply as they are.