Configuring Metadata
Correctly configuring the metadata is an important part of constructing your NFTs on the Cardano blockchain

Metadata on NFTs

When an NFT is minted under a policy it also has metadata with various attributes attached to the transaction.
This ranges from things like the asset name, where the image/file is stored, what type of file it is, and more.
You have the ability to store not only what the Cardano NFT metadata standard defines but anything that you want that adheres to the specifications and limitations of the blockchain.
It is advisable to take some time to consider the metadata you want to add to your project before proceeding, this particular element is best implemented in one attempt, rather than iteratively.
When using NFT-MAKER, you can set up a metadata template which essentially tells the system what data it should expect to receive and thus keeps everything in alignment. The rest of this guide gives a flavour of the options available to you and continues here with a full guide.
Note - each metadata attribute has a maximum limit of 64 Characters

NFT metadata standardisation

The standard that we use to create and define the metadata that makes up the NFTs on Cardano is a community-driven effort.
You can read the CIP (Cardano Improvement Proposal) for the NFT Metadata Standard for Native Tokens and the associated documentation on GitHub.
The standardisation of royalties for NFTs on Cardano is still a work in progress. The CIP proposal outlines the suggestions but this is separate from the NFT metadata standard.

Breakdown of the metadata

The base structure for the metadata on any NFT that is minted can be seen below. It's structured as a JSON object that is stored with the transaction.
{
"721": {
"<policy_id>": {
"<asset_name>": {
"name": <string>,
"image": <uri | array>,
}
}
}
}
The root of the metadata is the 721 representing the transaction_metadatum_label that describes the type of data.
Next, the policy_id is the unique identifier for the minting of the NFTs.
The asset_name uniquely identifies your NFT under the policy. The asset_name should be unique for each NFT.
The remaining two fields are the base attributes that every NFT must contain. The name is a human-readable description of the NFT and image is a URI pointing to the resource.
NMKR Studio starts you off with a more robust foundation when it comes to the metadata on your NFTs.
Note - the default template includes 1 subfile
"721": {
"<policy_id>": {
"<asset_name>": {
"name": "<asset_name>",
"image": "<ipfs_link>",
"mediaType": "<mime_type>",
"description": "<description>",
"files": [
{
"name": "<asset_name>",
"mediaType": "<mime_type>",
"src": "<ipfs_link>"
}
]
}
},
"version": "1.0"
}
As you can see, it follows the standard but includes additional information such as mediaType , description, version, and files.
The mediaType is a way to represent the type of file that's contained in the image property of the metadata. It's structured as a mime type and commonly used values are image/jpeg , image/png , image/gif, and video/mp4.
The description property is optional and provides a way to describe your NFT in more detail outside of the name.
The version property defines the version of the metadata standard that it's using. This should always be 1.0 .
The files property an array that allows you to define more than one file associated with an NFT. An example of this could be an NFT that is a video but also has an image and gif of a portion of the video.

Metadata Placeholders

NMKR Studio allows you to set up placeholders to deal with the metadata for each specific NFT more easily.
You can define any placeholder you would like in the format <placeholder_name>.
The reason why this is helpful is that it allows you to define all of the common metadata attributes about all the NFTs in your NFT Project and then use the placeholders for the attributes which are individually unique.
It also ensures that you maintain a certain level of consistency instead of having to generate all of the metadata values for every NFT you want to set up in your NFT Project.
When you set up a new NFT on one of your NFT Projects via the web app or API (UploadNft), you can supply the values for the placeholders you set up. Creating your NFTs this way allows NMKR Studio to automatically generate the metadata based on the template and placeholder values.
You don't have to use placeholders, instead, you can send the entire JSON object of the metadata for each NFT that you set up under one of your NFT Projects.

Multiple Files (Subfiles)

As mentioned above, it is possible to add subfiles to your project.
You may want to do this for many reasons, for example if your project uses very high resolution images, it may be desirable to have the placeholder image be a smaller file, with the full resolution file added as an additional subfile. The same could be said for audio based media.
To use subfiles, you will first need to set up your metadata template so it is ready to handle them, a good example is given below (see lines 9-20 in particular).
Note - this example will accommodate 2 Subfiles, but you can see that by adding additional instances (duplicating lines 10-14), you can add more as needed.
{
"721": {
"<policy_id>": {
"<asset_name>": {
"name": "<display_name>",
"image": "<ipfs_link>",
"mediaType": "<mime_type>",
"description": "<description>",
"files": [
{
"name": "<display_name>",
"mediaType": "<mime_type_subfile_1>",
"src": "<ipfs_link_subfile_1>"
},
{
"name": "<display_name>",
"mediaType": "<mime_type_subfile_2>",
"src": "<ipfs_link_subfile_2>"
}
]
}
},
"version": "1.0"
}
}
Copy link
On this page
Metadata on NFTs
NFT metadata standardisation
Breakdown of the metadata
Metadata Placeholders
Multiple Files (Subfiles)