HIP-412: NFT Token Metadata JSON Schema v2

Abstract

This specification provides a standard scheme for non-fungible token metadata on HTS. The intent is to provide a flexible specification which will serve as the base format for all NFT’s.

NFT’s minted to this specification will be able to be served by explorers, wallets and other applications, allowing those applications to display a minimum amount of information regardless of the use case of the NFT and providing a standardized format for specialized token types.

Motivation

Token creators often desire to include an image and supplemental metadata that is associated with tokens, including Non-Fungible Tokens (NFTs). This specification provides a recommended standard for referencing and processing token metadata stored outside HTS.

This standard has been developed by the community with the intent of providing a flexible and robust schema for NFT metadata to address the following points:

1. Define a standard that is robust and flexible to allow the wide variety of NFT projects to be able to use it.
2. Set a common ‘base set’ of fields that arbitrary token types can follow, which will allow wallets and galleries to be able to display a basic set of NFT data irregardless of the special features
3. Address the pitfalls of existing schemas which some projects have expressed problems with. For example, being able to serve data that isn’t an image, or multi-file data.
4. Provide a mechanism for projects to specify their specific schema (the ‘format’ parameter), to allow for sub-schemas to be developed.
5. Standardize using setMetadata() to set the pointer to the NFT’s JSON file which uses the METADATA field rather than the MEMO or SYMBOL field on the NFT asset.

Rationale

The token metadata has been developed with the input of over a dozen developers and projects in the NFT space. Many views and use cases were taken into consideration, such as:

1. Minimum required information to display any kind of NFT
2. Flexibility and Robustness
3. Compatibility with existing NFT standards (Ethereum and Solana’s Open Sea standard)
4. Non-Image NFTs - Documents, Videos, Music, 3D Models
5. Multi-file NFTs

Rationale for specific fields is provided in section Field Specific Rationale below.

Specification

Below is the human-readable schema, presented to maximize clarity. This document also includes a Formal JSON Schema definition to assist in data validation and describe the data in formal terms. See the Formal JSON Schema Definition section below.

{
	"name": "token Name - REQUIRED",
	"creator": "artist",
	"creatorDID": "DID URI",
	"description": "human readable description of the asset - RECOMMENDED",
	"image": "cid or path to the NFT's image file, or for non-image NFTs, a preview image for display in wallets - REQUIRED",
	"checksum": "SHA-256 digest of the file pointed by the image field - OPTIONAL",
	"type": "mime type - ie image/jpeg - REQUIRED",
	"files": [ // object array that contains uri, type and metadata
		{
			"uri": "uri to file - REQUIRED",
			"checksum": "cryptographic SHA-256 hash of the representation of the resource the author expects to load - OPTIONAL",
			"is_default_file": "(Type: boolean) indicates if the file is the main file for this NFT - OPTIONAL",
			"type": "mime type - REQUIRED",
			"metadata": "metadata object - OPTIONAL",
			"metadata_uri": "uri to metadata - OPTIONAL"
		},
		… multiple …
	],
	"format": "format designation - OPTIONAL",
	"properties": {
		// arbitrary json objects that cover the overarching properties of the token
	},
	"localization": {
		"uri": "uri to file, using format: <protocol>://<hash>/{locale}.json - REQUIRED",
		"default": "two-letter language code identifying default language for NFT specification - REQUIRED",
		"locales": "array containing two-letter language codes identifying other localized metadata specifications for this NFT - REQUIRED"
	}
	// additional fields defined per the format
}

Required, Optional and Conditionally Optional fields:

name, description, and image are the three basic fields in ERC721 NFT standards. name and image are required for all NFT’s as part of this HIP. The description field is optional, but recommended to enable apps to display them better.

The type field is required and must display the mime type of the image such as “image/jpeg” or “image/png”.

creator, creator DID, format, attributes, files, properties and localization are optional and do not need to be included in the metadata.

The checksum is also optional but recommended when using a file hosted at a centralized server. It allows NFT tooling to verify the image integrity, same for files where this property also applies.

Field Specific Rationale

creator

A string for the creator, or for multiple creators to be attributed use comma separated values.

Eg. “John Doe” or “John Doe, Jill Doe”

creatorDID

This is an optional field to carry a decentralized identifier for the creator. This would allow a creator to subsequently lay claim to a creation even if the current ownership is different.

The DID resolves to a DID document with a public key, and the creator would prove ownership of the corresponding key with a signature.

For example, a Hedera DID looks like ‘did:hedera:mainnet:7Prd74ry1Uct87nZqL3ny7aR7Cg46JamVbJgk8azVgUm;hedera:mainnet:fid=0.0.123’. The DID resolves to a JSON DID Document.

References: https://github.com/hashgraph/did-method/blob/master/did-method-specification.md https://w3c.github.io/did-core/

image

A URI pointing to a resource with mime type image/* representing the asset to which this token represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive. See [uri formatting] section for more details.

The image field is required. It can both serve as a preview image or the full resolution image for your NFT to ensure cross-platform compatibility. The image will be displayed in wallets and marketplaces by default. Some platforms may support displaying other file types such as 3D files, audio or video. Creators are recommended to point to a thumbnail in the image field, and put the high resolution image in the files array with the is_default_file boolean set to indicate that this file represents the default image for the NFT.

“image” is a standard field across other chains and is required for this standard. There was discussion to change this to a more generic name such as ‘file’ or ‘uri’, however this would break cross-chain compatibility of this standard.

checksum

The checksum property represents a SHA-256 digest of the file pointed by the image property. The checksum property contains a cryptographic hash of the representation of the resource the author expects to load.

For instance, an author may wish to load some image from a shared server. Specifying that the expected SHA-256 hash of https://example.com/image.jpeg is ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad means that the user agent can verify that the data it loads from that URL matches that expected hash before loading the NFT. This integrity verification significantly reduces the risk that an attacker can substitute malicious content.

The hashing method can be updated in the future according to W3C guidelines. SHA256 is deemed a safe option for verifying resource integrity. However, hashing functions that are not recommended include MD5 and SHA-1.

References: https://w3c.github.io/webappsec-subresource-integrity/

type

Mime type of the image file. See [mime formatting] section for more details.

“type” is required because the “image” field is required.

Including the mime type allows applications to properly handle the file and greatly simplifies the code required to display the data.

files

“files” is an array of objects with the following format:

{
	"uri": "uri to file - REQUIRED",
	"checksum": "cryptographic hash of the representation of the resource the author expects to load - OPTIONAL",
	"type": "mime type - REQUIRED",
	"is_default_file": true,
	"metadata": "metadata object - OPTIONAL",
	"metadata_uri": "uri to metadata - OPTIONAL"
}

“uri” is the uri to the file. See [URI Formatting]

“checksum” is an optional cryptographic SHA-256 hash of the representation of the resource the author expects to load.

“type” is required and is the mime-type of the file pointed to by the uri, see [Mime Formatting]

“is_default_file” is optional and allows the user to define which file is the default high resolution file for the NFT. It’s useful when you want to define another file as the default high resolution file your NFT than the one listed in the image field (recommended). It can also to indicate the main file for a multi-file NFT.

“metadata” is optional. This is a nested metadata object for the file, which follows the same metadata format as the root metadata. Files can be nested indefinitely in this way, but processed with the same metadata code.

“metadata_uri” is optional. There are situations (such as mutable metadata) where rather than including the “metadata” object it makes sense to point to a different file. Therefore this is a URI that points to a metadata json file for the file in question.

To avoid conflicts, if “metadata” is defined then “metadata_uri” should be ignored.

An NFT creator has the option of using either “metadata” or “metadata_uri”. Metadata should be considered the default behaviour as it minimizes the number of calls that need to be made. Metadata_uri should be used in specific situations where defining the metadata object within the base metadata file is inadequate.

format

For the optional fields of attributes and properties, as well as any additional fields above the required fields described in this schema, “format” defines the specific schema which is used by this NFT. This allows NFT creators, communities and platforms to explicitly define the schema that they are using, which simplifies implementation for other projects hoping to use the same definition.

To reduce errors, “format” should be lower-case. For robustness, galleries and viewers should interpret format in a case-insensitive way to account for mistakes.

The recommended schema for Hedera NFTs is [email protected]. You can find the reference implementation for the [email protected] standard here: https://nftstorage.link/ipfs/bafkreidcsqzr5su356thecwuyzrhsgekfdsqzuyuqxtsu4vh7oc34iv5oy or via this IPFS CID ipfs://bafkreidcsqzr5su356thecwuyzrhsgekfdsqzuyuqxtsu4vh7oc34iv5oy. This standard can evolve. Semantic versioning has been applied to the standard. The second version of the standard is represented by [email protected]. Version [email protected] refers to HIP10 which got replaced by HIP412.

properties

“properties” is defined as a collection of arbitrary fields and is the only optional field that is explicitly defined in the base schema.

The intention of “properties” is to provide a common place for information to be stored about the token. Future schema should use properties to include any additional information that is intended to be parsed by a generic text parser for display. For example, a “license” field could be defined with the value “Creative Commons Attribution 4.0 International”, and a gallery could parse through properties and display it dynamically without advance knowledge of the field.

It is not in the scope of this schema to define field naming standards or common fields. It is recommended for the community to create a standards body for this purpose.

Best Practice Recommendation: It is strongly recommended that information such as ‘supply’, ‘royalties’ and other properties which are recorded on ledger should not be defined in the metadata. This information is at best redundant and at worst can be factually incorrect.

localization

Localization is an optional object that points to language-specific metadata files for this NFT.

locales - (Required) An array containing two-letter language codes identifying the possible languages for this NFT specification. No need to further define subregion locales such as en-GB to keep things simple.

Type: string (two-letter language code according to ISO 639-1 standard)

default - (Required) Indicates the primary language for this NFT metadata specification. This locale should not be repeated in the locales array.

Type: string (two-letter language code according to ISO 639-1 standard)

uri - (Required) CID or path to the localized NFT’s metadata file. It’s recommended to host your file on IPFS and use a service like Pinata to easily pin your file. Your CID should look like this: ipfs://<hash>.

Alternatively, you can use Arweave, receiving a similar CID that looks like this: ar://<hash>.

The format of the uri should look like this <protocol>://<hash>/{locale}.json. The {locale} part references to a locale in the locales array. For instance, if you define the following locales locales: ["es", "fr"], you should upload the following files to IPFS (or Arweave): “ipfs://QmWS1VAdMD353A6SDk9wNyvkT14kyCiZrNDYAad4w1tKqT/es.json” and “ipfs://QmWS1VAdMD353A6SDk9wNyvkT14kyCiZrNDYAad4w1tKqT/fr.json”.

Formatting Notes

URI Formatting

URI’s shall follow the following format: protocol://resource_location

For resources that are on the world wide web, the standard https protocol is acceptable. Ie. http://www.example.org/image/file.jpg

For resources that are on IPFS, the protocol must be ipfs:// and the resource location must be the cid of the file. Ie. ipfs://bafkreibwci24bt2xtqi23g35gfx63wj555u77lwl2t55ajbfjqomgefxce

For resources that are on Arweave, the protocol must be ar:// and the resource location must be the cid of the file. Ie. ar://bafkreibwci24bt2xtqi23g35gfx63wj555u77lwl2t55ajbfjqomgefxce

The onus is placed on dApps to take the cid and access the file information through the method of their choosing.

CDN links such as Cloudflare and Infura are not acceptable. These are not primary sources. Ie. https://cloudflare-ipfs.com/ipfs/bafkreibwci24bt2xtqi23g35gfx63wj555u77lwl2t55ajbfjqomgefxce

IPFS CIDS may contain file paths or extensions as long as they adhere to best practices as described here: https://docs.ipfs.io/how-to/best-practices-for-nft-data/#persistence-and-availability

For resources that are on the hedera file service, the protocol is hedera://

A more complete list of URI’s can be found here: https://en.wikipedia.org/wiki/List_of_URI_schemes

Mime Formatting

Mime formatting shall follow the following format: type/subtype

As a rule, mime types are all lower case. However apps should be programmed to accept any case for robustness.

A list of common mime types can be found here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types

Note that mime types for directories are not uniformly defined. Some IPFS CIDs point to directories rather than files, so this type is useful. This standard shall define it using the format: text/directory

Reference Implementation

Default Schema: Collectibe Hedera NFTs (format: “[email protected]”)

This is a recommended reference implementation for collectible Hedera NFTs. The HIP412 standard has been designed to be used by all NFT tooling (wallets, explorers) and be mostly compatible with other existing standards.

Version [email protected] refers to the current, updated version for collectible Hedera NFTs while version [email protected] refers to HIP10 which got replaced by HIP412.

Here’s an example of a full implementation of the metadata schema described in this HIP412 specification for an image-based NFT. We are setting the image field to a URI and including the checksum field which represents a SHA-256 hash of the provided image.

The files array contains file objects (e.g. multi-file NFTs), also including an optional checksum for validation purposes. The image field can both serve as a preview image or the default image for your NFT to ensure cross-platform compatibility. The image will be displayed in wallets and marketplaces by default. Some platforms may support displaying other file types such as 3D files, audio or video. Use the is_default_file in your files array to mark a file as the one you would prefer to have displayed by default if the NFT tooling supports it. In this case, the image field serves as a preview image. The standard recommends using the image field as a preview image by marking another file in the files array as default.

Further, no additional properties are defined on the JSON object on root level. Any additional properties you want to define should go into the properties object.

You can optionally define attributes to calculate rarity scores. We’ve added the field display_type similar to the OpenSea standard which defines how the attribute should be displayed.

The standard also allows for localization. Each locale links to another metadata file that contains the localized metadata and files. This allows for a clean metadata structure. Don’t define another localization object for a localized metadata file to avoid infinite looping when parsing an NFT’s metadata file.

A JSON schema can be found here or via this IPFS CID ipfs://bafkreidcsqzr5su356thecwuyzrhsgekfdsqzuyuqxtsu4vh7oc34iv5oy. This is version v2.0.0, representing format [email protected].

{
	"name": "Example NFT 001",
	"creator": "Jane Doe, John Doe",
	"creatorDID": "did:hedera:mainnet:7Prd74ry1Uct87nZqL3ny7aR7Cg46JamVbJgk8azVgUm;hedera:mainnet:fid=0.0.123",
	"description": "This describes my NFT",
	"image": "https://myserver.com/preview-image-nft-001.png",
	"checksum": "ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad",
	"type": "image/png",
	"format": "[email protected]",
	"properties" : {
		"external_url": "https://nft.com/mycollection/001"
	},
	"files": [
		{
			"uri": "https://myserver.com/high-resolution-nft-001.png",
			"checksum": "9defbb6402d4bf39f2ea580099c73194647b24a659b6f6b778e3dd71755b8862",
			"is_default_file": true,
			"type": "image/png"
		},
		{
			"uri": "ipfs://yusopwpksaioposjfopiapnnjlsl",
			"type": "image/png"
		}
	],
	"attributes": [
		{
			"trait_type": "color",
			"display_type": "color",
			"value": "rgb(255,0,0)"
		},
		{
			"trait_type": "hasPipe",
			"display_type": "boolean",
			"value": true
		},
		{
			"trait_type": "coolness",
			"display_type": "boost",
			"value": 10,
			"max_value": 100
		},
		{
			"trait_type": "stamina",
			"display_type": "percentage",
			"value": 83
		}
		,
		{
			"trait_type": "birth",
			"display_type": "datetime",
			"value": 732844800
		}
	],
	"localization": {
		"uri": "ipfs://QmWS1VAdMD353A6SDk9wNyvkT14kyCiZrNDYAad4w1tKqT/{locale}.json",
		"default": "en",
		"locales": ["es", "fr"]
	}
}

Here’s a clarification for the most important fields for the [email protected] format.

image

(Required) The standard recommends using the image field as a preview image/’thumbnail’ by marking another file in the files array as the default high resoltion image using is_default_file.

attributes.trait_type

(Required) Name of trait.

attributes.display_type

(Optional) Indicates how the trait value should be displayed. Possible display types (but other types are allowed):

• text (default value representation)
• boolean (for boolean-based values -> It’s recommended to start the trait naming with is or has e.g. isAlive: true or hasPipe: true)
• percentage (for integer or number values)
• boost (for integer or number values)
• datetime (for a number which represents the unix timestamp in seconds)
• date (for a number which represents the unix timestamp in seconds)
• color (for a hexadecimal or rgb string color sequence such as #00ff44 or rgb(0,255,0))

attributes.value

(Required) Value for trait. To give an example, imagine an NFT with the trait_type: mouth. Possible values are bubblegum, smiling, braces, or trumpet.

Allowed types: string, integer, number, boolean

attributes.max_value

(Optional) Adding a max_value sets a ceiling for a numerical trait’s possible values. NFT tooling should default this value to the maximum value seen for a collection. Only use this property if you want to set a different value than the maximum value seen in the collection. Make sure the max_value is equal to or higher than the maximum value seen for your collection.

Allowed types: string, integer, number

Example Schema: Image NFT with no format defined

This is an example of a basic metadata as described by this schema. No specific format is used to indicate that this metadata does not adhere to any specific sub-schema. Note that all the fields in properties are arbitrary.

{
	"name": "Example NFT",
	"creator": "John Doe",
	"description": "This is an example NFT metadata",
	"image": "ipfs://bafkreibwci24bt2xtqi23g35gfx63wj555u77lwl2t55ajbfjqomgefxce",
	"type": "image/png",
	"properties": {
		"license": "MIT-0",
		"collection": "Generic Collection Name",
		"website": "www.johndoe.com"
	}
}

Example Schema: Video NFT with no format defined

This is an example of a video NFT with no format defined. Note that this NFT does not include an image, nor does it define any arbitrary properties.

{
	"name": "Example NFT",
	"creator": "Jane Doe, John Doe",
	"description": "This is an example NFT metadata",
	"image": "ipfs://bafkreibwci24bt2xtqi23g35gfx63wj555u77lwl2t55ajbfjqomgefxce",
	"type": "image/jpg",
	"files": [
		{
			"uri": "ipfs://bawlkjaklfjoiaefklankfldanmfoieiajfl",
			"type": "video/mp4",
			"metadata": {
				"name": "video name",
				"description": "nested file metadata",
				"image": "ipfs://bakcjlajeioajflakdjfneafoaeinovandklf",
				"properties": {
					"additional_description": "The image in this nested metadata is the video thumbnail."
				}
			}
		}
	]
}

Example Schema: localized multi-file NFT (video and PDF) with no format defined

An example similar to the above one. This metadata schema does not adhere to any specific sub-schema. The NFT does not contain a thumbnail. The localization attributes would point to localized metadata for the NFT specification

{
	"name": "Example NFT",
	"creator": "Jane Doe, John Doe",
	"creatorDID": "did:hedera:mainnet:7Prd74ry1Uct87nZqL3ny7aR7Cg46JamVbJgk8azVgUm;hedera:mainnet:fid=0.0.123",
	"description": "This is an example NFT metadata",
	"image": "https://myserver.com/preview-image-001.png",
	"checksum": "9defbb6402d4bf39f2ea580099c73194647b24a659b6f6b778e3dd71755b8862",
	"type": "image/png",
	"files": [
		{
			"uri": "ipfs://bawlkjaklfjoiaefklankfldanmfoieiajfl",
			"type": "video/mp4",
			"is_default_file": true,
			"metadata": {
				"name": "Example Video"
			}
		},
		{
			"uri": "ipfs://bawlkjaklfjoiaefklankfldanmfoieiajfl",
			"type": "application/pdf",
			"metadata": {
				"name": "Example second file",
				"description": "The description is recommended but optional. The image provided is an optional preview",
				"image": "ipfs://bawlkjaklfjoiaefklankflda1313ieiajfl",
				"type": "image/jpeg"
			}
		}
	],
	"localization": {
		"uri": "ipfs://QmWS1VAdMD353A6SDk9wNyvkT14kyCiZrNDYAad4w1tKqT/{locale}.json",
		"default": "en",
		"locales": ["es", "fr"]
	}
}

Formal JSON Schema Definition

The following is the formal definition of this schema using JSON Schema notation. JSON Schema assists in metadata validation and describes the data in the schema in more formal terms. Despite looking like JSON, this is NOT how actual metadata should look. If you are creating the metadata file for an NFT do not use this definition as a reference.

For more info see here: https://json-schema.org/

{
	"$schema": "http://json-schema.org/draft-07/schema#",
	"type": "object",
	"version": "2.0.0",
	"additionalProperties": false,
	"properties": {
		"name": {
			"type": "string",
			"description": "Identifies the asset to which this token represents."
		},
		"creator": {
			"type": "string",
			"description": "Identifies the artist name(s)."
		},
		"creatorDID": {
			"type": "string",
			"format": "uri",
			"description": "Points to a decentralized identifier to identify the creator."
		},
		"description": {
			"type": "string",
			"description": "Describes the asset to which this token represents."
		},
		"image": {
			"type": "string",
			"format": "uri",
			"description": "A URI pointing to a resource with mime type image/* representing the asset to which this token represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive."
		},
		"checksum": {
			"type": "string",
			"description": "Cryptographic SHA-256 hash of the representation of the 'image' resource."
		},
		"type": {
			"type": "string",
			"description": "Sets the MIME type for the 'image' resource."
		},
		"format": {
			"type": "string",
			"default": "[email protected]",
			"description": "Name of the format or schema used by the NFT. For this schema representing Hedera Collectible NFts, set 'format' to '[email protected]'."
		},
		"properties": {
			"type": "object",
			"description": "Holds any arbitrary properties. Values may be strings, numbers, booleans, objects or arrays."
		},
		"files": {
			"type": "array",
			"items": {
				"type": "object",
				"properties": {
					"uri": {
						"type": "string",
						"format": "uri",
						"description": "A URI pointing to a resource."
					},
					"checksum": {
						"type": "string",
						"description": "Cryptographic SHA-256 hash of the representation of the 'uri' resource."
					},
					"type": {
						"type": "string",
						"description": "Sets the MIME type for the 'image' resource."
					},
					"is_default_file": {
						"type": "boolean",
						"description": "Indicates if this file object is the main file representing the NFT."
					},
					"metadata": {
						"type": "object",
						"description": "Represents a nested metadata object for the file, which follows the same metadata format as the root metadata. Files can be nested indefinitely in this way, but processed with the same metadata code."
					},
					"metadata_uri": {
						"type": "string",
						"format": "uri",
						"description": "A URI pointing to a metadata resource, which follows the same metadata format as the root metadata. Files can be nested indefinitely in this way, but processed with the same metadata code."
					}
				},
				"required": [
					"uri",
					"type"
				],
				"additionalProperties": false
			}
		},
		"attributes": {
			"type": "array",
			"items": {
				"type": "object",
				"properties": {
					"trait_type": {
						"type": "string",
						"description": "Name of trait."
					},
					"display_type": {
						"type": "string",
						"description": "Sets the representation of the value of the trait."
					},
					"value": {
						"type": ["string", "integer", "number", "boolean"],
						"description": "Value for trait."
					},
					"max_value": {
						"type": ["string", "integer", "number"],
						"description": "Maximum value for trait."
					}
				},
				"required": [
					"trait_type",
					"value"
				],
				"additionalProperties": false
			}
		},
		"localization": {
			"type": "object",
			"required": ["uri", "default", "locales"],
			"properties": {
				"uri": {
					"type": "string",
					"description": "The URI pattern to fetch localized data from. This URI should contain the substring `{locale}` which will be replaced with the appropriate two-letter langauge code value before sending the request. Format: <protocol>://<hash>/{locale}.json"
				},
				"default": {
					"type": "string",
					"description": "Sets the two-letter language code that represents the default locale for this metadata file."
				},
				"locales": {
					"type": "array",
					"description": "The list of locales for which data is available.",
					"items": {
						"type": "string"
					}
				}
			},
			"additionalProperties": false
		}
	},
	"required": [
		"name",
		"image",
		"type"
	]
}

Backwards Compatibility

This HIP is entirely opt-in, and does not break any existing functionality. It simply provides standards to facilitate integratons for the display of metadata for HTS tokens.

Security Implications

No known security concerns.

How to Teach This

HTS implementations use this standard to provide additional metadata for their tokens.

Wallet and token explorer implementations interrogate HTS tokens using this standard to display additional metadata for tokens.

Note that the referenced URI must fit within the token metadata size restrictions.

Rejected Ideas

This proposal originally only discussed NFTs and the JSON Metadata described in [0]. After discussion with the community [6] it became clear that JSON Metadata that supported fields beyond image-only NFTs was required. The community further updated the HIP in February 2022 to address issues and further increase the flexibility and robustness of the specification.

Open Issues

N/A

References

1. https://github.com/hashgraph/did-method/blob/master/did-method-specification.md
2. https://w3c.github.io/did-core/
3. https://docs.metaplex.com/token-metadata/specification
4. https://docs.opensea.io/docs/metadata-standards
5. https://docs.ipfs.io/how-to/best-practices-for-nft-data/#persistence-and-availability
6. https://en.wikipedia.org/wiki/List_of_URI_schemes
7. https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types
8. https://json-schema.org/

Copyright/license

This document is licensed under the Apache License, Version 2.0 – see LICENSE or (https://www.apache.org/licenses/LICENSE-2.0)

Citation

Please cite this document as: