Discussion: Propose a standard top-level field to support multiple image variants

[stein-f]

This ARC proposes a new optional top-level field in NFT metadata: image_variants. This would enable creators to define alternate visual representations of the same asset (e.g. seasonal variations, upgrade states, etc.) while preserving a single canonical token identity.

This is fairly common on other chains, where projects such as DeGods, Moonbirds and Claynosaurs have demonstrated strong community engagement through dynamic visual variations across “seasons.” Standardizing how these alternate images are presented will allow frontends to support user-friendly toggling between versions without relying on non-standard metadata conventions.

This change is backwards compatible and does not affect existing NFTs or render logic for platforms that do not opt into this feature.

Motivation

Creators increasingly want to offer evolving or selectable visual styles tied to the same NFT. Use cases include:
• Seasonal artwork (e.g., Season 1, Season 2)
• Evolution-based art (e.g., upgraded character visuals)
• Artistic variants (e.g., grayscale vs color modes)
• Story progression (e.g., dream stage visuals)

By standardizing image_variants, marketplaces and galleries can natively support toggling between these versions, improving UX and encouraging richer storytelling.

Example:

{
  "image_url": "ipfs://QmMainImageHash",
  "properties": {
    "Background": "Yellow"
  },
  "filters": {
    "stage": "N1"
  },
  "image_variants": [
    {
      "identifier": "Season 1",
      "image_url": "ipfs://QmSeason1ImageHash"
    },
    {
      "identifier": "Season 2",
      "image_url": "ipfs://QmSeason2ImageHash"
    }
  ]
}

NFT marketplace example usage