Immutable X Metadata Strategies

with metadata for ImmutableX NFTs. This is a core part of being able to mint NFTs at scale on ImmutableX.

First and foremost, there are some key decisions that you need to make when you are deciding how you mint your NFT collection at scale.

First and foremost for the metadata itself. You need to decide if you want to use IPFS and leverage the immutability guarantees that it provides or you want to have a Web 2 API.

And then similarly for the media file or files that the metadata points to, you need to have a decision on whether or not you want to use IPFS

or a Web 2 API for that. And then finally, you need to decide whether or not your collection has static

versus generative versus dynamic metadata. These three key decisions will determine the approach that you would need

to take in order to implement your NFT collection and by association, how you can then mint at scale.

First and foremost, let's talk about how IPFS and ImmutableX interact with each other. If your metadata is known in its entirety ahead of time, i.e.

it is static metadata, then you can actually use IPFS for this and you can provide an immutability guarantee and b

you can leverage IPFS by itself. And you don't need to stand up or host any server or API, which is a much simpler hosting scenario.

First and foremost, you're going to need to upload all of your media to IPFS so that you

can generate all of the URLs for that media with the content ID or IDs. And then secondly, you can construct the metadata

and then upload it as an archive into IPFS. And as long as you make it so that each metadata file is represented by the token it say 1 to 3, etc., then

that would mean that your metadata is available at ipfs://{content id of your archive}/{token ID},

and this corresponds very nicely to the way that ImmutableX needs to have its metadata URL.

Now, if you implement this pattern, then you can make it so that the ERC-721

smart contract that you deploy to Ethereum can have a basic right that's hard coded to ipfs://{the content ID}

and the marketplaces on Ethereum have native support for IPFS, so this will work nicely. Then in addition to that, to make this work for ImmutableX, you

need to make sure that the API metadata URI is a https:// gateway that points to your IPFS content ID.

So as an example, if you're using IPFS IO, then you would set the API metadata URL to be https://ipfs.io/ipfs/{your

content ID} (of the archive that contains your metadata). And then what ImmutableX will do is it will append /{token ID} every

time it wants to make a HTTP request to load the metadata of a given NFT.

Next, let's talk about refresh of metadata on ImmutableX. As we've covered previously, ImmutableX caches metadata for performance. It doesn't do a live look up every single time someone tries to retrieve some

metadata about a given token. But what this means is if you have a project that has dynamic metadata that changes

and is not immutable, then you're going to need to trigger a refresh on ImmutableX any time you change that metadata.

Now, the way the metadata refresh service works is it concurrently requests metadata for each asset that you tell it to refresh and you can tell it to refresh multiple assets

at a time. There's a rule that the response time for each metadata request needs to be less than 3 seconds. And in terms of reliability, if there are file requests,

it will retry them several times within an hour period. If this fails persistently, then these failed assets will be marked as such.

After several failed rate tries and there's a key limitation worth keeping in mind, which is that for any given project, you can refresh up

to 20 metadata refreshes per hour. And for each metadata refresh, you can specify up to a thousand tokens

that can be refreshed. Now that we've covered the basic approaches. Next, it's worth looking at the three key metadata strategies that

are available to us. The first one is static metadata. This is where you have fixed information about your NFT collection.

That doesn't change over time. This data is immutable and it's known ahead of time. This means that you could store this metadata in IPFS, as we've talked

about, and it's easy to define it prior to the NFT collection being minted. Alternatively, maybe you have a need for generative metadata.

This is where you algorithmically or programmatically generate the metadata based on some sort of rule or event. An example of this might be the traits or attributes of some

sort of crypto collectable generative art piece that has different layers. Or maybe it's a game item that gets generated on the fly as you earn

that game item. The point here is that the metadata is defined at the time the NFT is first minted.

But then from that point on is immutable. Thirdly, there is the approach of dynamic metadata.

This is metadata that changes over time, potentially based on some sort of external data source. So this might be things like real time data like weather or financial data.

And this metadata that changes over time will change the properties of the NFT that they're associated with.

So now that we've covered these three strategies, let's talk through how you would implement each of the three. Firstly, we have static metadata.

Now, in this case, if you're using IPFS, we can follow the process that we talked about before where we have a single archive deployed to a content ID and we make sure that each token ID

is defined as a file within that archive so that you can append slash token ID to the IPFS URL and get the metadata for a single NFT.

In terms of the Web 2 API that ImmutableX needs as its metadata APIs URL. This can either be a HTTP gateway to your

IPFS content ID, or if you want, you can implement a traditional web two API if you don't want to be using IPFS.

Although our recommendation would be if you have static metadata, it makes sense to use IPFS because the data is already immutable and it's a best

practice in the industry to use IPFS for immutable metadata. In terms of the Ethereum Smart contract, you can use a standard NFT

ERC-721 smart contract with the base URL set to ipfs://{the content ID} as we've

gone through previously. In terms of the ImmutableX collection, we just need to set the API metadata URL to be the HTTP web 2 API gateway that we choose, be it

and IPFS Gateway, or a traditional Web 2 API in terms of minting and withdrawing the NFT.

There's no real differences here from what you would normally experience. If we want to implement a strategy for generative metadata, we can still use IPFS. But what we would do is at the point in time we're about to mint the NFT,

we would upload that metadata to IPFS and generate a specific content ID for that metadata.

We don't have much choice in terms of the API metadata URL for ImmutableX because the URL changes.

Given that we have to upload to IPFS on the fly rather than all at once as an archive at the start, we basically have to be using some sort

of API as a gateway that converts token ID to our request to the underlying IPFS or wherever we decide to store the metadata if we don't want to use IPFS.

In the Ethereum smart contract, we need to change the standard ERC-721 smart contract such that we set the token URI based on

what's passed through at minting time. In terms of the API metadata URL. This will have to be our custom API server.

When when minting on ImmutableX, we should set the blueprint on the token to be the IPFS URL with the content id of the metadata

for that NFT if we're using IPFS. Or alternatively, it could be our Web 2 API.

Finally, when withdrawing the NFT, we simply need to use the blueprint that was passed in at minting time and then set that as the token URI.

Finally, if we're dealing with dynamic metadata, we can't really use IPFS for this. IPFS is inherently immutable, and in this case the metadata

is mutable. So we basically need to create a traditional Web 2 API. We need to store the metadata in some sort of immutable database,

and we need to make sure that when that metadata changes that we trigger a metadata refresh on ImmutableX so that the cached metadata that it has is modified to update.

In terms of the Ethereum smart contract, it can be a fairly standard smart contract with the base URI set to our Web 2 API.

Similarly, the API metadata URL for the ImmutableX collection can be set to our web to API gateway in

terms of minting and withdrawal. There isn't really any changes that happen here. So now that we've covered how metadata and immutability and different metadata

strategies and approaches for metadata work in ImmutableX. From here you have all the tools that you need to mint at scale on ImmutableX.

In particular, if you take the code that you've been using in the previous labs in this course, then they provide you in combination with these metadata

strategies, all of the tools that you need to construct an automated minting process that would meet multiple items.

Thanks for joining me for this lesson.