NFT-Specific Protocol Improvements

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".

1 Like

Ahoi Kyle :wave:

Interesting thoughts, what problem is exactly being solved?

There is an opportunity to improve network usage (VeThor burn) in the form of data storage on-chain.

This makes it sound like the goal is for enforce a standard to use more resources instead of being careful with them. Gas fees are a way manage the network capacity. Having a gas efficient contract allows more throughput, less costs for user. Similar to a energy efficient electronic device :slight_smile:

I personally also like the base64 encoding in the URI, but there’s also a lot of arguments to use external URLs. Rewriting that standard is, in my opinion, a bit out of scope :slight_smile:

2 Likes

I definitely could have worded this better :sweat_smile:

The root thinking here was less around gas usage and more around shifting the cost and persistence of data storage onto the network.

I see a massive addition of value for a company looking to use VeChain as both a data store AND as an API, if all data is able to be stored on-chain and therefore referenced by any third party looking to consume said data.

In the licensing example, this would allow someone to be confident that the details and history of their license would all be accessible via VeChain regardless of the state of the external company or their CDN.

I say all of this because I currently work adjacent to the music licensing industry and it’s painfully old. There are a few companies that act as the clearinghouses for massive read-only APIs whose sole purpose is to handle distribution of songs and license info. I’ll spare all of the gory details but it is an archaic system that could greatly benefit from having a shared data store that did nothing more than serve up data and prove who is the legal rights holder. And these clearinghouses would pay handsomely to not have to maintain an API if they could offload it to a decentralized database.

1 Like