I have a couple ideas on which I’d appreciate input. I don’t know if either of the following should happen as network-wide VIPs or if these are things that can be organically implemented and distributed by major dApps adopting the standards. Thanks in advance for the feedback!
Storing Data URLs On-Chain
There is an opportunity to improve network usage (VeThor burn) in the form of data storage on-chain. This would involve making an additive change on top of something like ERC-721 or ERC-1155 in order to encode data as a Data URL instead of linking to an external source like a CDN or Arweave.
As an example, take a standard ERC-721 token with this change adopted, the _baseURI
would return a Data URL "data:application/json;base64,"
contract ERC721Contract is ERC721, ERC721URIStorage {
function _baseURI() internal pure override returns (string memory) {
return "data:application/json;base64,";
}
}
With this in place, when the full URL is concatenated (i.e. you call ERC721Contract.tokenURI(1)
) it returns something like this:
data:application/json;base64,eyJmb28iOiJiYXIifQ==
The above string is universally recognized/supported in all modern browsers. You can even copy/paste it into your browser’s address bar and it will decode and display the data {"foo": "bar"}
.
It looks like this is in-spec for some of the existing standards set by OpenSea with respect to contract metadata, but it is ambiguous as to whether or not this is supported for token metadata.
For further reading on Data URLs see: Data URLs - URIs | MDN
NFT Metadata Linking Standard
It would be of significant technical benefit to have a standard way to link NFTs on-chain. This would be especially useful for things like creating NFT inheritance/precedence trees. As a practical example, the terms of an licensing agreement could be renegotiated and the renewal/update could be linked to the original license agreement via on-chain metadata.
This could occur either at the top level of an ERC-721 tokenURI JSON payload, or in the attributes array of said JSON payload.
The data structure could look something like this for a singular NFT link:
{
...,
“link”: {
"link_type": "nft",
"display_type": "Parent",
“address”: “<some-nft-contract-address>”,
“tokenId”: 1234
}
}
Or for multiple NFT links:
{
. . .,
“link”: [
{
"link_type": "nft",
"display_type": "Parent 1",
“address”: “<some-nft-contract-address>”,
“tokenId”: 1234
},
{
"link_type": "nft",
"display_type": "Parent 2",
“address”: “<some-nft-contract-address>”,
“tokenId”: 1235
}
]
}
In both cases the "link_type"
, "display_type"
, and "address"
keys would be optional as it could be inferred from the contract that the NFT is being linked from. As an example, this would be a valid link definition:
{
. . .,
“link”: {
“tokenId”: 1234
}
}
This would also allow for future expansion into other "link_type"
s like "transaction"
or "contract"
or even "external_network"
.