What is ERC-4906?
The refresh-metadata button, turned into an event.
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
The standard, in one card.
- Standard
- ERC-4906 / EIP-4906
- Core events
- MetadataUpdate · BatchMetadataUpdate
- Extends
- ERC-721 metadata
- Canonical spec
- eips.ethereum.org / EIP-4906
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.
What ERC-4906 actually is.#
event MetadataUpdate(uint256 _tokenId);
event BatchMetadataUpdate(uint256 _fromTokenId, uint256 _toTokenId);
MetadataUpdate · BatchMetadataUpdate marketplaces · wallets · indexers The standard defines two events. MetadataUpdate names one token. BatchMetadataUpdate names a range. Clients watch logs and refresh their cached metadata.
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.
-
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-4906emit MetadataUpdate(id)LSP4setData(key, value)workarounds tried- refetch tokenURI
- custom events
- indexer diffs
-
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-721tokenURI -> JSONVerifiableURIhash-anchored metadataworkarounds tried- IPFS pinning
- Arweave
- data URIs
- redundant gateways
-
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.
eventlog onlyERC-725YgetData(key)workarounds tried- custom on-chain fields
- oracles
- indexer proofs
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.
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 |
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.