sRFC 00005: An implementation of On-chain image storage to the current metaplex nft standard

An implementation of On-chain image storage to the current metaplex nft standard

This standard utilizes the existing fields of the metaplex nft program to be able to store an on-chain image

Implementation:

Creating this topic to discuss how I stored images on-chain on solana with the NFT project known as Blockrons as a proof of concept.

Intro:

Blockrons was built in december 2022, before there were much interest on on-chain solana nfts. The goal of the project is 2 fold, implement a true on-chain nft as well as educate the degen/twitter audience on why/how on-chain nfts are done on solana.

Image Data:

The image data is stored as a string directly to a solana address. The format is base 64 SVG, which is a great format to store pixel art. The idea was not to complicate things with advanced struct or json’s but rather simply store the data in an address in such a way that a simple data retrieval call on the solana address will return the image data without needing additional decoding or struct deserialization.

The string also uses a data URL header, this allows browsers to native read the string data into an image. Therefore all strings start with: “data:image/svg+xml;base64,(data here)”

Connection to the NFT token:

To connect this PDA image storage account to an existing metaplex NFT, we use 3 methods.

Method 1 is write the image storage account on the NFT description, however since the description itself is in a json stored off-chain, this is not a good implementation.

Method 2 is the fact that the image storage account is a PDA generated with the NFT token pubkey as a seed (the other half of the seed is the programID). This makes it easy to retrieve the image storage account knowing just the programID and the nft token pubkey.

Method 3 is writing the image storage account directly to the URI field. This is done by appending the solana account pubkey after the arweave (off-chain) link. Wallets and marketplace still resolve to the arweave link, we can keep the image storage account written there for manual image retrieval.


You can see the highlighted green area above to show how the image storage account was added to the URI field.

Testing:

If you would like to test how images are stored, visit this link: https://onchain-datagrabber-developerhamster.vercel.app/

This website was built to showcase to the audience how the images are stored and retrieved in a step by step process. If I were to automatically retrieve the image on-chain, then how can you illustrate/educate to the audience that the images are on-chain?

This proposal aims to introduce the “/?onchain=” append to the metaplex URI field as a standard way to store on-chain image accounts.

4 Likes

Hey Hamster!

Thank you for your proposal on writing Solana NFT images into Solana accounts. After reviewing your RFC, I think to highlight that it actually comprises two separate RFCs.

1. Writing & Reading SVG Images as PDAs of a Solana Program

This portion of the proposal discusses storing image data in base64 SVG format directly to a Solana address, using a data URL header to make it natively readable by browsers. The image storage account is a PDA generated with the NFT token pubkey as a seed, making it easy to retrieve the image knowing just the programID and the NFT token pubkey.

It’s very important that you attach a Proof of Concept implementation, or an existing program’s implementation to define this RFC.

2. URI Structure of Metaplex NFTs with Optional Fetching of Image Data

This part of the proposal outlines three methods to connect the PDA image storage account to an existing Metaplex NFT. The suggested approach is to append the Solana account pubkey after the Arweave (off-chain) link in the URI field, and introduce the “/?onchain=” append to the Metaplex URI field as a standard way to store on-chain image accounts.

I think it’d be awesome if you could rewrite #1 as a separate RFC, and #2 is fine as an RFC here, but I think it would need to be submitted to Metaplex separately as well, so they have some awareness.

Looking forward to hearing from you soon!

5 Likes

I appreciate the response. It seems like metaplex will be going their own direction with this as they are in full control of the standard currently.

I will still continue my sRFC proposal as they might be of use to any future developer looking to learn more or tackle this subject.

For RFC #2: URI Structure of Metaplex NFTs with Optional Fetching of Image Data

I used a solana account that directly contains an image but its better to follow the current standard of first pointing to solana account containing a .json struct, then inside that .json we can have another solana account containing the image.

So I propose we use 2 solana accounts, one for the json and one for the image, similar to how arweave is used now.

2 Likes