the standard · since March 2022
// standard · nft metadata updates · event signal · ready

What is ERC-4906?

The refresh-metadata button, turned into an event.

ERC-4906 ·EIP-4906 ·by DoubleQ + emo + Shrug + 0xMaki

updated · 1 min read · by ercs-solved maintainers

ERC-4906 exists because dynamic NFTs need a standard refresh signal. Without it, marketplaces rely on manual refresh buttons, polling, or collection-specific adapters.

on this page
  1. What is ERC-4906?
  2. At a glance
  3. Origin story
  4. The spec
  5. What's broken
  6. It says refresh, not what changed
  7. It still depends on tokenURI infrastructure
  8. Contracts cannot reason about the metadata
  9. LUKSO alternative
  10. ERC-4906 vs LSP4
  11. When to use which
  12. FAQ
  13. Sources
  14. Keep reading
at a glance

The standard, in one card.

Standard
ERC-4906 / EIP-4906
Core events
MetadataUpdate · BatchMetadataUpdate
how the standard came to be

The origin story.#

As NFT metadata became mutable - reveals, evolving art, game state, traits, and redemption status - clients needed to know when tokenURI output should be fetched again.

the spec, end to end

What ERC-4906 actually is.#

ERC-4906 EIP-4906 interface solidity
event MetadataUpdate(uint256 _tokenId);
event BatchMetadataUpdate(uint256 _fromTokenId, uint256 _toTokenId);
ERC-4906 interface, grouped
events: MetadataUpdate · BatchMetadataUpdate
clients: marketplaces · wallets · indexers

The standard defines two events. MetadataUpdate names one token. BatchMetadataUpdate names a range. Clients watch logs and refresh their cached metadata.

the integration tax

What's broken about ERC-4906.#

An event is only a signal. It does not define the metadata schema, include the updated value, or protect off-chain media from disappearing or changing silently.

  1. It says refresh, not what changed.#

    The event tells clients that metadata should be refreshed. It does not include the changed field, new value, schema, or content hash.

    ERC-4906 emit MetadataUpdate(id)
    signal only
    LSP4 setData(key, value)
    typed update
    workarounds tried
    • refetch tokenURI
    • custom events
    • indexer diffs

    read the deep-dive

  2. It still depends on tokenURI infrastructure.#

    After the event, clients usually refetch the same tokenURI path. If the server, gateway, JSON schema, or media URL fails, the event cannot repair that dependency chain.

    ERC-721 tokenURI -> JSON
    off-chain
    VerifiableURI hash-anchored metadata
    integrity
    workarounds tried
    • IPFS pinning
    • Arweave
    • data URIs
    • redundant gateways
  3. Contracts cannot reason about the metadata.#

    The update signal is useful for off-chain clients, but downstream contracts still cannot read typed metadata fields from a tokenURI string.

    event log only
    off-chain consumption
    ERC-725Y getData(key)
    contract-readable
    workarounds tried
    • custom on-chain fields
    • oracles
    • indexer proofs
the LUKSO alternative

LUKSO designed it differently.#

LSP4 treats metadata as typed data under known keys. Updates can be read directly from ERC-725Y storage, and off-chain blobs can be hash-anchored with VerifiableURI.

spec to spec, at a glance

ERC-4906 vs LSP4 in one table.#

row ERC-4906 LSP4
metadata change event says refresh typed key data changes
new value included no yes, in ERC-725Y storage
content integrity not defined VerifiableURI can hash-anchor off-chain data
contract-readable no yes
be honest about scope

When to use which.#

people also ask

FAQ.#

  • What does ERC-4906 do? #

    It adds standard metadata update events so clients can know when to refresh token metadata.

  • Does ERC-4906 store metadata on-chain? #

    No. It only emits events. The underlying metadata can still live behind tokenURI or another off-chain path.

  • Which event updates one NFT? #

    MetadataUpdate(tokenId) signals that one token's metadata changed. BatchMetadataUpdate signals a range.

primary sources

Where this page draws from.#

  1. EIP-4906