---
slug: "/NIMDE_EXTENSIBLE_v1.0.0"
sidebar_position: 1
---

# NIMDE_EXTENSIBLE_v1.0.0

| <!-- --> | <!-- --> |
|-------------|-------------|
| Authors | Zack Pantely, Kavan Sikand |
| Contributors| Florian Uhde |
| Type | Metadata Standard |
| Standard Name | NIMDE_EXTENSIBLE_v1.0.0 |
| Created | 2022-06-06 |

## Table of contents
- [Summary](#summary)
- [Abstract](#abstract)
- [Motivation](#motivation)
- [Specification](#specification)
- [JSON Schema](#json-schema)
- [Top Level Data Types](#top-level-data-types)
- [`ExtensionName` Formatting](#extensionname-formatting)
- [Backwards Compatibility](#backwards-compatibility)
- [Security Considerations](#security-considerations)
- [Copyright](#copyright)

## Summary
NFTs have grown in popularity and complexity, but there currently exists no standard set of rules for understanding their associated metadata. Here, we propose a standard which allows NFT authors to define their metadata in a way which tells consumers what to expect, and provide a framework for extending the simple metadata specified in the ERC-721 and ERC-1155 standards with well-defined specifications. This enables content creators to use and contribute to a set of "extensions" which specify the structure of a token's metadata.

## Abstract
This standard seeks to enforce well-defined, yet flexible, constraints upon NFT metadata in order to allow reliable and deterministic interpretation.

This is achieved by solidifying and expanding upon the ERC-721 metadata guidelines to do the following:
- Decouple token standards (such as ERC-721) from the standard of their associated metadata (such as this standard)
- Set requirments for top-level metadata JSON keys
- Define which standard the metadata adheres to
- Allow extending the metadata by additively implementing other extension standards

## Motivation
As the popularity of NFTs has grown, they have outgrown the simple and loose metadata suggestions specified in ERC-721 and ERC-1155. Authors have added arbitrary sets of extra fields into the metadata associated with their tokens, but there has been no standardization of this process.

Some de-facto standards have arisen, but they are not formalized in any way, and authors often diverge from these standards in an ad-hoc manner, making it difficult for consumers to understand the assets.

An example of such a de-facto standard is the concept of adding `attributes` to an NFT's metadata, which often takes the form of an array of objects which look like `[
{ trait_type: string, value: string } ]`. However, not all NFTs have these fields, and there also exist assets which have `attributes` which take on a different form factor. For this example, we propose formalizing this standard as an "attributes" extension to the Extensible Metadata Standard to ensure consumers know exactly when to expect this attribute data and what form it will take.

As NFTs grow in popularity, additional use cases have arisen for which ther are *no* widely-used standards, such as NFTs which represent 3D models, or groups of assets all governed by a single token (such as a skin pack).

Some examples of motivation for specific extensions are given below.
[Now, continue to motivate the previews / assets extensions and link to those <- can we link these or will they not exist by the time this is published?]

## Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).

#### JSON Schema:

{
  "name": "My Cool NFT",
  "description": "A very cool NFT.",
  "image": "https://coolnfts.com/preview.mp4",
  "metadataStandard": "NIMDE_EXTENSIBLE_v1.0.0",
  "extensions": []
}

#### Top-Level Data Types:

| Field Name | Data Type | Inclusion |
| -------- | -------- | -------- |
| name | string | REQUIRED |
| description | string | OPTIONAL |
| image | string (url) | RECOMMENDED |
| metadataStandard | string | REQUIRED |
| extensions | string[] (ExtensionName) | REQUIRED |

The values of these fields MUST adhere to the data types listed.

The `image` field points to the preview or main 2D asset of the NFT (typically an image or video). This field SHOULD be populated and is included in order to provide compatibility with existing NFT consumer infrastructure at the time of writing. However, this field has evolved to be a misnomer with a limiting and confusing function; therefore, it has been marked as not required in hopes to phase it out in preference of a more well-defined preview-handling extension to this metadata standard.

The `metadataStandard` key allows a consumer to understand which metadata standard this JSON adheres to. The value is the technical name of the metadata standard, but no naming guidelines are specified here. If using version 1.0.0 of this standard, the value of this field would be "NIMDE_EXTENSIBLE_v1.0.0".

The `extensions` array specifies which metadata extensions this metadata adheres to. Extensions can specify additional keys to the top-level metadata JSON or add constraints and definitions to another extension. Metadata extensions are intentionally differentiated from EIPs because they are relevant only to NFT metadata and should be constructed and interpreted in a chain-agnostic manner (i.e. they are not bound to the Ethereum network).

#### `ExtensionName` Formatting:

The format of an `ExtensionName` is defined as:

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[*extension developer code*]_[*extension name/number*]_v[*version*]

With each piece defined as:
- **Extension developer code:** a unique code (which MUST NOT contain spaces or underscores) indicating the party or developer who originated the extension
- **Extension name or number:** a name or number (which MUST NOT contain spaces or underscores) which is unique per extension developer code
- **Version:** the version of the standard (which MUST follow Semantic Versioning 2.0.0)

For example, extending with the initial release of Nifty Island's [Multi-Asset Standard](NIMDE_MULTIASSET_v1.0.0#top-level-metadata) linked below would have "NIMDE_MULTIASSET_v1.0.0" as a value in the `extensions` array.

In alignment with [Semantic Versioning 2.0.0](https://semver.org/), an increment to the MAJOR version indicates breaking changes. This means that metadata interpreters must check at least the MAJOR version to determine compatibility with an extension standard. The MINOR version can be optionally checked to detect the presence of additional functionality.

## Backwards Compatibility
This change to the metadata standard is backwards compatible with existing metadata suggestions proposed in ERC-1155.

## Security Considerations
Because this standard only specifies metadata properties and does not involve a smart contract directly, there are no security concerns.

## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).