ERC-721 metadata standards and IPFS
How BlockRocket & KnownOrigin utilises ERC-721 metadata & IPFS to build a digital assets marketplace
As engineers first, primarily we focused our energies in compliance with the emerging non-fungible token (NFTs) standard, ERC-721. One of the newest additions to this standard is an attempt to define a standardised set of metadata which can be attached to the a ERC-721 token, used for displaying things like a name, description and image of the digital asset. The EIP-721 documentation states the following:
The metadata extension is OPTIONAL for ERC-721 smart contracts. This allows your smart contract to be interrogated for its name and for details about the assets which your NFTs represent.
For example, the specification defines a “ERC721 Metadata JSON Schema”. The following JSON schema contract should be adhered to when the contract supports this metadata standard, being returned from the method tokenURI(uint256 _tokenId)
As you can see its a fairly simply standard and is optional by default i.e. a valid ERC721 token does not have to supply this.
How it’s used
When we mint() digital assets into the KODA platform we allow a tokenURI to be set defined on a per token basis, for example.
As part of the minting process we deploy the metadata and the associated data/images to InterPlanetary File System, also know as IPFS. This should provide us with a secure, transparent and public way to host asset metadata. We have incorporated this in to the minting process via some basic node scripts which utilise js-ipfs library.
As previously mentioned, at KnownOrigin we conform to the ERC-721 metadata standard but we also have extended this concept of metadata to include further custom asset information which we can use internally to the marketplace. One benefit of using this is that we reduce the size and ultimate the cost of minting assets. Below is an example of a KODA tokenURI metadata:
Notice the additional property of
meta which we have included, this allows us to attach other data to an asset which when then use within the marketplace. As you can see we also use infura.io as our primary IPFS provider but this in theory could change to our own hosted IPFS node if required.
Other points to mention Are that the
image also needs to be a valid URI according to currently agreed specifications, however in some discussions this has been limited in regards to the types of file that should be referenced e.g. PNG, JPEG, or SVG but this unfortunately wouldn't allow us to list GIFs on KnownOrigin and potentially other digital assets which may be able to be placed on the KODA marketplace.
Conceptually we have taken a simply and hopefully flexible path in regards to storing associated asset metadata, linking to IPFS hosted files, hosted by ifura over secure server over https.
Our hope is that with the standardisation of ERC-721 digital asset metadata, combined with the hosting power of IPFS, that the KnownOrigin marketplace can easily be integrated into external services and wallets such as OpenSea.io and TrustWallet. To a certain extent this has already been proven as OpenSea and TrustWallet were able to add KnowOrigin in a short period of time after some basic discussion with the dev teams. Time will tell if this is the case for all and as with all standards they can evolve over time.
The first official draft of ERC-721 has been accepted but you can still follow the open issue on Github — https://github.com/ethereum/eips/issues/721
This is part of a short series on some of the technical aspects and reasoning used to build the KnownOrigin marketplace. If you’d like to checkout the marketplace then visit knownorigin.io in any web3 enabled browser or mobile Ethereum wallet.
If you have enjoyed this article please show some love and give it a clap or ten!