ERC-4841: Expandable Onchain SVG Images Storage

I’d like to know what you guys think about this and I am always happy to get to your feedback, such as the possibility of adopting the EIP and comments on further improvements :slight_smile:

I think this proposal is useful, but I don’t think it needs to be an ERC (or if it does, it needs to make the case for that better in the Motivation section.) Instead, I think it would be useful as a library or framework.

At minimum, I think it’ll need a way to indicate to NFT marketplaces that the image is available somewhere else. Could maybe be a special scheme in the return value of getURI?

1 Like

First of all, thank you for agreeing with our proposal.

After reading your feedback, we realized what we wrote didn’t fully explain what we were trying to explain. So, we are working on improvement the overall content now. (Please refer to the GitHub pull request comments :slight_smile:)

Based on your feedback, we improved on the Motivation section like below. (We are in the process of requesting proofreading, so we got help from Google. If there is something you do not understand, please feel free to leave a comment!)

Most NFT projects keep their NFT content on centralized servers, not on Ethereum. Although this method is the cheapest and easiest way to manage the content of an NFT, there is a risk of damage or loss. In addition, even in the case of IPFS, tampering can be prevented with the Content-addressing, but there is a possibility of data loss if there is no node storing the contents of the NFT.

One of the ideal ways to solve this problem is to store the content of the NFT on Ethereum in SVG image format. However, since the maximum size that can be distributed in one contract is about 24 kB, there is a problem that only small, simple SVG images can be saved.

Therefore, to solve this problem, we devised a storage model consisting of three hierarchical structures: Storage, Assemble, and Property.

With this storage model,

  • XML ​​tags composing SVG images are distributed and stored in multiple contracts, and when SVG images are needed later, saved tags can be combined to obtain large-capacity SVG images.
  • By dividing the storage into three independent tiers, you can ensure the ease of management and the flexibility of storage. For example, if the logic for assembling XML tags in the Assemble Layer needs to be changed, there is no need to re-record the values ​​stored in the Storage Layer or Property Layer in the block chain, only the contract of the layer that needs to be modified is newly distributed.
  • Extensibility can be secured based on an independent hierarchical structure. If you want to add the configuration of SVG, you just need to distribute the contract to the Storage Layer and connect it with the Assemble Layer.

We would like to propose a scalable storage model that stores large, high-quality SVG images on Ethereum.

Like Motivation above, we thought that this proposal could contribute to the Ethereum ecosystem based on three main advantages. Therefore, we would like to propose this proposal as a standard, and if there are any shortcomings to become a standard, we would be grateful if you could tell us what is it.

In addition, ERC is defined as below among the contents of EIP-1, so we judged that it is suitable for the ERC category even if the contents we want to propose are close to the framework. If we are misunderstood, please let us know :wink:

  • ERC: application-level standards and conventions, including contract standards such as token standards (EIP-20), name registries (EIP-137), URI schemes, library/package formats, and wallet formats.

Thanks for all always, guys.

Hey! Thanks for taking the time to write a detailed reply :slight_smile:

Like I said, I really do see the benefit of splitting up SVGs into multiple contracts. I’ve encountered the contract size limit before with my NFT projects.

What I’m asking is: why does the method of splitting up SVGs need to be standardized into an ERC? If my token splits them up using method A, and your token uses method B, is that a problem?

I can certainly see the case for standardizing a replacement interface for tokenURI that marketplaces (like OpenSea) can use to retrieve the assembled image, but the interface shouldn’t depend on how the image is stored. I would be happy to be convinced otherwise though!

1 Like


We apologize for the very late reply due to our original work.

After receiving the feedback, we’ve been thinking a lot about the EIP.

We sympathize with the content of the feedback, and we have recognized that the method of storing data is difficult to establish as a standard.

And we don’t have any special ideas to replace tokenURI, so we’re going to close this EIP and this thread.
(@everyone If anyone has a good idea, it would be great to develop this EIP together!)

Thanks a lot for your feedback and interest. And we will come back with better ideas for improving Ethereum :smile: