An AI creator can sell a token that points to an image, voice clip or collectible character card, yet token ownership does not necessarily freeze the linked artwork. Buyers often discover this distinction only after a metadata service changes its response. ERC-721, created in January 2018, defines a standard interface for non-fungible tokens; ERC-4906, created in March 2022, adds an optional metadata update event. Neither standard automatically transfers a copyright license or guarantees permanent media storage. This analysis focuses on the operational and contractual boundary between a token, its mutable metadata and a creator’s permission to use underlying assets.

Start with the object the token actually identifies

An ERC-721 identifier is unique within a contract, but uniqueness is not the same as a unique or permanent file. Applications commonly resolve tokenURI to metadata containing media references and attributes. A creator may update a description, correct a broken URL, replace a preview or remove a licensed element. Before a purchaser pays, the marketplace should display the contract address, network, token identifier, metadata retrieval method and whether the reference can change. The buyer should be able to compare a snapshot of current metadata with any promise made in the sale. A static thumbnail alone is poor evidence because it can remain in browser caches after the authoritative metadata has changed. Treat the token and the content it points toward as separate records. [1]

What ERC-4906 standardizes, and what it does not

ERC-4906 defines MetadataUpdate and BatchMetadataUpdate events, enabling indexers to refresh token information when metadata changes. The standard requires a metadata update event when JSON token metadata changes under an implementation supporting the extension; it does not include the changed JSON fields in the event. A listener generally retrieves metadata again from tokenURI. The extension is optional for ERC-721 contracts, so an indexer must check support rather than assume it. Importantly, the event is not a signed statement about a creator’s license, the moral rights of a performer, or the continued availability of an off-chain file. Applications should label a refreshed image as a new observed version, not describe it as a new edition or a fresh proof of provenance unless independent evidence supports those claims. [2]

Build a before-and-after evidence record

When an indexer sees an update event, it should capture block number, transaction hash, contract, token identifier and retrieval timestamp. Fetch the JSON over a constrained and monitored network client, record the response digest, and compare normalized fields against the previously validated version. Store a safe thumbnail and metadata history where policy permits. Keep the source URI and fetched payload distinct because redirecting gateways, mutable HTTP endpoints and cache layers can yield different results from the same apparent URI. A buyer-facing history should identify which attributes changed and when they were observed, without asserting that the event alone proves the creator initiated the change. If a metadata fetch fails, show the prior snapshot with a stale warning rather than quietly substituting it as if it remained authoritative. [1]

Separate trading rights from image and voice permissions

An owner may be allowed to transfer the token without owning rights to commercially reproduce the linked face, voice or music. Licenses can have independent terms for promotion, modification, sublicensing and withdrawal. Creator agreements should explain whether the asset is a collectible, a membership entitlement, a commercial license or a combination. If a digital twin is based on a real person’s likeness, recording an NFT transfer does not eliminate consent and personality-right questions. Avoid making automated assertions such as ‘on-chain ownership proves authorized voice cloning.’ A useful marketplace displays a short rights summary, the detailed license version and a withdrawal or dispute contact. This makes permission understandable without pretending that ERC standards govern all off-chain law. [2]

Model buyer risk with a scenario table

Consider three hypothetical metadata policies. Policy A stores a frozen metadata digest and requires a new token for material changes. Policy B allows corrections but logs every changed field and sends a notice. Policy C allows silent replacement through a mutable endpoint. A collector who values the exact edition may reasonably assign the highest trust to A; a creator who needs to fix safety or licensing errors may need B. Price comparisons should disclose those trade-offs rather than use an arbitrary ‘rarity premium.’ Test a changed image, removed file, stale third-party cache and revoked rights claim under each policy. The outcome is an evidence-quality matrix, not an invented market price series or a recommendation to invest in a token. [1]

Test refresh, failure and rollback in a real client

Create a test collection under your control and verify ERC-165 extension detection before subscribing to metadata events. Exercise one single-token update and a batch update. Confirm that the indexer waits for adequate chain confirmation, fetches the new tokenURI result, logs differences and marks cache invalidation. Then simulate a gateway timeout and ensure the public page visibly signals that metadata cannot be verified. A rollback should preserve the historical observation rather than rewriting prior records. Keep privacy-sensitive media out of public test fixtures. If a marketplace advertises token permanence, its review must inspect contract-level mutability, gateway retention and license terms together. Passing an ERC-4906 event test alone does not settle those questions. [2]

The meaningful distinction is simple: ERC-721 identifies and transfers a token; ERC-4906 helps applications notice metadata updates; the creator’s media rights, content retention and buyer promises live in additional contracts and systems. Transparent version histories can reduce confusion without claiming that a blockchain guarantees rights it never defined.

Sources

  1. Ethereum ERC-721 Non-Fungible Token Standard (created 24 Jan 2018)
  2. Ethereum ERC-4906 Metadata Update Extension (created 13 Mar 2022)