EIP4906: ERC-721/ERC-1155 Metadata Update Extension

eip: 4906
title: ERC-721/ERC-1155 Metadata Update Extension
description: Standard interface extension for ERC-721/ERC-115 metadata update
author: Anders (@0xanders)
status: Draft
type: Standards Track
category: ERC
created: 2022-03-13
requires: 721 or 1155


This specification defines standard metadata update event of ERC-721and ERC-1155. The proposal depends on and extends the existing ERC-721 and ERC-1155.


Many ERC-721 and ERC-1155 contracts emit their custom event when metadata changed.It is easy to update metadata of one NFT by specific event, but it is difficult for third-party platforms such as NFT marketplace to update metadata of many NFTs based on custom events.

Having a standard MetadataUpdate event will make it easy for third-party platforms to timely update metadata of many NFTs.


The keywords “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.

The metadata update extension is OPTIONAL for ERC-721/ERC-1155 contracts.

/// @title ERC-721/ERC-1155 Metadata Update Extension
interface IERC4906MetadataUpdate  {
    /// @dev This event emits when the metadata of a token is changed. 
    /// So that the third-party platforms such as NFT market could
    /// timely update the images and related attributes of the NFT
    event MetadataUpdate(uint256 indexed _tokenId);   

The MetadataUpdate event MUST be emitted when the metadata of a token is changed.


Different NFTs have different metadata, and metadata generally has multiple fields. bytes data could be used to represents the modified value of metadata. It is difficult for third-party platforms to identify various types of bytes data, so there is only one parameter uint256 indexed _tokenId in MetadataUpdate event.

After capturing the MetadataUpdate event, a third party can update the metadata with information returned from the tokenURI(uint256 _tokenId) of ERC721 or uri(uint256 _tokenId) of ERC1155.

Backwards Compatibility

No issues.


Copyright and related rights waived via CC0.

1 Like

Hi. I think this makes a lot of sense. I would however suggest that the event accept a range of consecutive token IDs. See ERC2309. My rationale is that you can tell a platform to update and entire collection of metadata using one event rather than one at a time. Emitting a single event for a collection of 10,000 NFTs is not financially reasonable.


I agree with this. There must be a way to signal that a range or whole collection is updated.

1 Like

I would like to propose the following two updates:

  1. Make the token id a range of consecutive ids, as already suggested in this thread.
  2. Many dynamic NFTs are time-based, so a way to instruct a marketplace whether or not to repeat the metadata query and the repeating details would be handy.
event MetadataUpdate(uint256 beginTokenId, uint256 endTokenId, uint256 repeatInterval)

For updates of a single token id, set beginTokenId and endTokenId to the same value.

A repeat interval of 0 means ‘do not repeat, this is a one-time update only’. Otherwise, the repeat interval would be specified in seconds.

Additionally, is there any reason to limit this to ERC-721 tokens? I feel like this can be applicable to ERC-1155 tokens as well.



Draft PR for review, if you think these suggestions are reasonable.

I’m the author of another draft EIP that is also about metadata “updates” but with different scope & motivation. Check EIP-5185: NFT Updatable Metadata Extension

EIP4906 proposal makes senses to help 3rd parties keep track of metadata URI, maybe the events should be named MetadataURIUpdate and BatchMetadataURIUpdate to better differentiate with updates taking place inside the metadata themselves such as eip-5185 is about.

1 Like

How about

interface IERCMetadataUpdate {
  event MetadataUpdate(uint256[] tokenIds);
  event MetadataUpdateRange(uint256 start, uint256 end);

would work with both ERC721 and 1155.

Passing an empty array could mean update all. Alternatively another method could be used to define ranges.

1 Like

@0xanders Sorry, I just realized that you talk about general updates.
We need more something like @Christophe proposal.
I will delete my comments, to avoid generating confusion. But, I agree with Christophe that MetadataURIUpdate would be definitely better.

1 Like