A conventional NFT is often presented as a permanent digital object. Once the token is minted, buyers may expect its image, attributes and description to remain unchanged.

That expectation is not always technically correct.

The blockchain may permanently record the token’s contract address, token ID and ownership history while its associated metadata continues to evolve. An NFT can change appearance after a game achievement, update its membership status, display a completed product redemption or react to external information such as weather, sports results or verified business data.

These tokens are commonly called dynamic NFTs, or dNFTs.

Dynamic NFTs can create more useful and interactive products than static collectibles. They can also introduce significant trust and security risks. If an issuer retains unrestricted control over metadata, the NFT purchased by a user may later display completely different content.

The quality of a dynamic NFT therefore depends on more than whether it can change. It depends on what can change, who controls the update, which data source triggers it and whether users can verify the history.

What is a dynamic NFT?

A dynamic NFT is a non-fungible token whose metadata, visual representation, attributes, status or connected utility can change after minting.

The NFT normally retains the same:

• blockchain network;
• smart contract address;
• token ID;
• ownership history.

The information associated with that token may be updated.

For example, a game-character NFT may begin at level one and later display a higher level after the holder completes certain actions. A membership NFT may change from active to expired. A token linked to a physical product may show that the item has been redeemed or transferred out of custody.

The change can be initiated by:

• an authorised contract administrator;
• the NFT holder;
• another smart contract;
• a scheduled automated function;
• an oracle supplying external information;
• an event occurring inside a game or application;
• a predefined state transition.

Dynamic behaviour does not require the token itself to be replaced. The application retrieves the latest state or metadata associated with the existing token ID.

How NFT metadata works

ERC-721 provides the basic interface for tracking and transferring unique tokens. Its optional metadata extension includes a tokenURI function that applications can query to locate information about a particular token. The URI commonly resolves to a JSON document containing the NFT’s name, description, image and additional attributes.

A simplified metadata record may contain:

{
  "name": "Explorer #42",
  "description": "A dynamic game character",
  "image": "ipfs://example-image",
  "attributes": [
    {
      "trait_type": "Level",
      "value": 7
    }
  ]
}

The marketplace or wallet reads this information and decides how to display the NFT.

A dynamic NFT may change because:

1. The tokenURI begins pointing to a different metadata file.
2. The file at the existing URI is modified.
3. The smart contract generates new metadata from on-chain state.
4. A new metadata option becomes active.
5. An external application displays the token differently according to contract data.

The blockchain record and the displayed media are therefore related but separate components.

Static NFTs can still depend on mutable infrastructure

An NFT does not become immutable merely because it has been minted.

A collection may use a fixed token ID while storing metadata on a conventional server controlled by the project. The server owner could replace the image, edit the description or remove the file without changing the NFT contract.

This type of mutability may be intentional or accidental.

Intentional changes may support:

• reveal mechanics;
• game progression;
• membership updates;
• product status changes;
• corrected metadata.

Unintentional changes may result from:

• server failure;
• expired hosting;
• incorrect file replacement;
• compromised administrator access;
• broken external links.

Users should therefore distinguish between token permanence and metadata permanence.

The token may continue existing on-chain even when the associated media changes or becomes inaccessible.

Main types of dynamic NFT updates

Dynamic NFTs can be divided according to how their state changes.

Administrator-controlled updates

An authorised wallet or contract role can change the token URI, attributes or status.

This model is relatively straightforward to implement. It is also highly dependent on the issuer.

An administrator-controlled NFT may be appropriate for:

• correcting inaccurate data;
• updating a verified product record;
• maintaining a membership status;
• publishing a new software version;
• marking a token as disputed or redeemed.

The contract should restrict the update function to an authorised role. OpenZeppelin provides reusable access-control components and ERC-721 implementations that developers can extend for token-specific metadata storage.

The risk is that the same administrator may have enough authority to replace legitimate content with misleading or unwanted data.

A project should disclose:

• which wallet controls updates;
• whether control is held by one person or a multisignature account;
• whether the contract is upgradeable;
• whether updates can be paused;
• whether users can inspect previous versions.

Holder-triggered updates

The NFT holder may initiate a state change by calling a smart-contract function.

Examples include:

• upgrading a game character;
• selecting a preferred visual version;
• activating membership access;
• redeeming a physical product;
• choosing one of several available metadata records.

The contract must define whether the update is permanent, reversible or limited by eligibility conditions.

A holder-triggered system can reduce dependence on a central administrator, but the update logic may still rely on project-controlled data.

Event-driven updates

The NFT can change after an on-chain event.

A game contract may increase an NFT’s level after a completed challenge. A membership token may change state after a payment. A product NFT may become marked as redeemed after a linked fulfilment contract records delivery.

Because the triggering event occurs on-chain, users can often inspect the transaction that caused the update.

The visual representation may still depend on external metadata, but the underlying state transition can be publicly reviewed.

Time-based updates

A token can change according to a timestamp or scheduled function.

Possible applications include:

• expiring passes;
• subscription periods;
• seasonal artwork;
• delayed reveals;
• vesting or access stages;
• time-limited product benefits.

Smart contracts do not continuously execute themselves. A transaction or automation service is normally needed to call the relevant function when the condition becomes true.

Chainlink Automation, for example, is designed to trigger eligible smart-contract functions through a decentralised automation network. Its documentation includes a dynamic-NFT example in which an automated contract updates an entirely on-chain SVG.

The project must consider what happens when the automation service is unavailable or insufficiently funded.

Oracle-driven updates

A smart contract cannot independently retrieve arbitrary information from a conventional website or external database.

An oracle connects the contract to off-chain data.

Chainlink defines an oracle as an entity that connects blockchain computations with off-chain resources. Its Functions service can retrieve public or protected API data and specifically identifies weather statistics and sports results as possible inputs for dynamic NFTs.

An oracle-driven NFT could react to:

• sports results;
• weather conditions;
• event attendance;
• product sensor information;
• verified market data;
• external game statistics;
• business-system records.

For example, a sports NFT might update after the represented athlete reaches a defined milestone. A physical-product token might display the latest authorised inspection status.

The blockchain can confirm which oracle result was supplied. It cannot independently guarantee that the original off-chain data was correct.

Randomly generated updates

Some dynamic NFTs change using verifiable randomness.

A game item may receive a random upgrade. A collection may reveal one of several traits. A token may generate changing visual components according to a random result.

Chainlink VRF provides a random value together with a cryptographic proof that is verified on-chain before the consuming contract uses the result. Its documentation specifically identifies blockchain games and NFTs as relevant applications.

Verifiable randomness can make the selection process auditable. It does not guarantee that the possible outcomes are fair or commercially appropriate.

The issuer still determines:

• the available outcomes;
• their rarity;
• which users may request a result;
• whether the process can be repeated;
• how the NFT changes afterward.

On-chain and off-chain dynamic NFTs

Dynamic NFT architecture differs according to where the changing information is stored.

Off-chain metadata

The smart contract points to a JSON file stored on a server, IPFS or another external storage system.

When the NFT changes, the project may update the file or change the URI.

Advantages include:

• lower blockchain storage costs;
• support for larger files;
• easier media updates;
• conventional content-management tools.

Risks include:

• unavailable storage;
• hidden file replacement;
• compromised hosting;
• inconsistent caching across marketplaces;
• dependence on external gateways.

IPFS content addressing can make a specific version identifiable, but changing the content normally produces a different content identifier. A project may therefore update the token URI to reference the new version.

On-chain metadata

The smart contract stores or generates the metadata directly from blockchain state.

An on-chain dynamic NFT may generate an SVG image based on values inside the contract. When the state changes, the application retrieves a newly generated representation.

Advantages include:

• public update logic;
• reduced dependence on an external media server;
• easier verification of state;
• continued availability while the blockchain remains accessible.

Limitations include:

• higher storage or execution costs;
• restricted media complexity;
• more complex contract development;
• increased consequences of coding errors.

On-chain storage does not guarantee that every update is decentralised. An administrator may still control the variables used to generate the image.

Hybrid architecture

A hybrid NFT stores important state on-chain while retrieving larger files from external storage.

For example:

• the blockchain stores the current level and status;
• the metadata server uses those values to select an image;
• the marketplace displays the resulting JSON record.

This approach can balance cost and verifiability, but it creates several dependencies that must remain synchronised.

How ERC-4906 supports dynamic NFT metadata

Marketplaces frequently cache NFT metadata to avoid retrieving the same files constantly.

When a token changes, the marketplace needs to know that its cached copy is outdated.

ERC-4906 standardises two events:

• MetadataUpdate for one token;
• BatchMetadataUpdate for a consecutive range of tokens.

A compatible contract must emit the relevant event when the JSON metadata changes. Third-party platforms can detect the event and retrieve the latest data from the token URI. ERC-4906 is an optional extension to ERC-721.

The event does not contain the full updated metadata. It acts as a notification.

ERC-4906 does not determine:

• who is authorised to make an update;
• which fields may change;
• whether the new information is correct;
• whether the old version remains available;
• whether the marketplace will refresh immediately.

It improves communication between contracts and indexing platforms, but the project still needs secure update logic.

Multiple metadata versions with ERC-7160

ERC-7160 allows one ERC-721 token to expose several metadata URIs. One of them can be pinned as the primary record.

The standard recommends using ERC-4906 when available metadata options change so that indexing platforms can refresh the token’s presentation.

A multi-metadata NFT might provide:

• several artwork versions;
• historical states;
• alternative language records;
• marketplace and verification views;
• different file formats;
• a holder-selected primary representation.

This model differs from silently replacing one file. The contract can maintain a visible set of recognised metadata records.

However, applications may not display every URI. Some may show only the pinned record, while others may not support the extension at all.

Dynamic NFTs and interactive standards

Dynamic NFTs may also respond to actions from other contracts or applications.

ERC-5050 proposes a system for interactive NFTs and modular environments. Its specification notes that interactive NFTs are likely to update metadata in response to actions and may use ERC-4906 events to communicate those changes.

An interactive NFT could react when:

• a character enters a game environment;
• an item receives an action;
• a connected asset changes state;
• another token performs an authorised interaction.

Such models can support richer digital products. They also require careful permission design to prevent arbitrary contracts from changing the NFT.

Dynamic NFT use cases

Gaming characters and items

Gaming is one of the most natural applications.

A character NFT may update its:

• level;
• appearance;
• experience points;
• equipment;
• achievements;
• status;
• rarity.

The token can retain the same identity throughout its development.

The game developer must explain which traits are controlled by gameplay, which can be edited administratively and whether the NFT remains meaningful outside the original game.

Memberships and access passes

A membership NFT may display:

• active or expired status;
• current membership tier;
• attendance history;
• unlocked benefits;
• renewal date.

The token may remain in the wallet after access expires.

Marketplaces should not continue displaying an inactive membership as though it provides the original benefits. The metadata and external service must remain aligned.

Certificates and credentials

A certificate NFT could be updated to show renewal, suspension, additional training or revocation.

This can help users review the current status rather than relying on a static document.

Credentials may contain sensitive information and are not always appropriate for a public transferable NFT. Personal data should be minimised, and non-transferable structures may be more suitable.

Physical-product records

A token linked to a physical product may update after:

• manufacture;
• inspection;
• repair;
• transfer;
• redemption;
• reported loss;
• removal from custody.

The NFT can support a product history, but each update depends on a trustworthy issuer, inspector, custodian or device.

A dynamic blockchain record cannot detect physical events without a secure reporting process.

Software and intellectual products

A dynamic NFT can represent an evolving software licence, publication or intellectual product.

The metadata may identify:

• current version;
• release date;
• update entitlement;
• licence status;
• file hash;
• verification state.

The protected product itself does not need to be stored publicly on-chain.

Token ownership still does not automatically transfer copyright or unrestricted access to source materials.

Event and sports NFTs

An event NFT may begin as a ticket and later become a commemorative record after entry.

A sports NFT may update according to verified results or player statistics.

Oracle-driven changes must use clearly documented sources. If a data provider corrects an earlier result, the project should explain whether the NFT will also be corrected.

Main risks of dynamic NFTs

Undisclosed mutability

A buyer may believe the artwork is permanent when the issuer can replace it at any time.

Projects should disclose mutability before sale, not only inside technical documentation.

Excessive administrator authority

A single compromised wallet could modify an entire collection.

Higher-value projects may use multisignature control, role separation, delays or restricted update functions.

Oracle manipulation or failure

An incorrect external data value may trigger an incorrect update.

Oracle design should consider data quality, source diversity, freshness and recovery procedures.

Broken automation

A scheduled change may not occur if the automation service is unfunded, misconfigured or unavailable.

The contract should define whether another authorised party can execute the update manually.

Marketplace caching

A contract may contain the correct new state while a marketplace continues showing the previous image or attributes.

ERC-4906 can signal an update, but individual platforms control when and how they refresh cached metadata.

Loss of historical versions

If a project overwrites a server-hosted JSON file, users may be unable to prove what the NFT displayed previously.

Versioned storage, event logs and content hashes can create a better audit trail.

Privacy exposure

Dynamic records may accumulate information about attendance, product ownership, activity or account status.

Public blockchain data can be difficult to remove. Projects should avoid publishing unnecessary personal details.

Changing holder expectations

An update may reduce or remove utility that influenced the purchase decision.

Project terms should explain which benefits are fixed, which can evolve and under what conditions service may end.

How to evaluate a dynamic NFT

Before acquiring or integrating a dynamic NFT, review the following areas.

Update authority

Identify every role that can change metadata or contract state.

Update scope

Determine whether the issuer can change one field, several approved values or the entire token URI.

Data source

Confirm whether updates depend on the holder, administrator, game, oracle, device or external API.

Update history

Check whether previous values and triggering transactions remain reviewable.

Storage

Determine whether metadata is stored on-chain, on a conventional server, on IPFS or through another system.

Marketplace support

Verify whether common platforms recognise metadata-update events and specialised extensions.

Failure handling

Understand what occurs if the data provider, automation service or issuer becomes unavailable.

Holder rights

Review whether the project can remove utility, change licensing terms or alter the underlying asset reference.

An existing token can be submitted through the MekaVerse NFT verification service for review of its public contract, metadata and update structure.

How projects should design dynamic NFTs

A dynamic NFT should be designed around a legitimate product need.

The project should document:

1. Why the NFT needs to change.
2. Which exact fields are dynamic.
3. Which fields are permanent.
4. Who can authorise each change.
5. Which data source is used.
6. How incorrect updates can be corrected.
7. Whether users can inspect previous states.
8. Which marketplaces and wallets support the design.
9. What happens when an external dependency stops operating.
10. Whether the holder can opt out or select a version.

Projects should avoid retaining broader permissions than necessary.

A game-level function does not need authority to replace copyright information. A redemption system does not need permission to change the declared creator. Separate roles can reduce the impact of a compromised administrator.

Projects involving intellectual products, membership, verification or physical assets can define these requirements through the MekaVerse NFT tokenization request page.

Frequently asked questions about dynamic NFTs

Can an NFT change after it is minted?

Yes. The token ID and ownership record can remain the same while its metadata, image, attributes, status or utility changes.

Does a dynamic NFT create a new token after every update?

Not necessarily. Most dynamic models update the state or metadata associated with the existing token.

Are all NFT metadata files permanent?

No. Metadata may be stored on a mutable server, content-addressed storage or directly on-chain. The storage method and contract permissions determine how easily it can change.

What is ERC-4906?

ERC-4906 is an optional ERC-721 extension that standardises events notifying marketplaces and other applications that NFT metadata has changed.

Can a marketplace fail to show an NFT update?

Yes. Marketplaces may cache metadata or may not support the update standard used by the collection. The blockchain state and marketplace display can temporarily differ.

Can an NFT change according to weather or sports results?

Yes. An oracle can provide authorised off-chain information to a smart contract. Chainlink Functions documentation specifically lists weather and sports results as possible data sources for dynamic NFTs.

Can dynamic NFT updates be automated?

Yes. An automation service or another transaction can call the update function after time or state conditions are met. The system still needs sufficient funding and correctly configured logic.

Are dynamic NFTs less secure than static NFTs?

They can have a larger attack surface because they involve update permissions, external data or automation. A static NFT with mutable server-hosted metadata can also be insecure or misleading.

Can a dynamic NFT become a different artwork?

Technically, it may be possible if the contract or metadata server allows broad changes. Responsible projects should disclose this authority and limit it according to the product’s purpose.

Does a dynamic NFT guarantee that external data is accurate?

No. The blockchain can record the data supplied to the contract, but the reliability of the update depends on the oracle, API, device or authorised reporter.

Dynamic NFTs turn tokens into evolving records

Dynamic NFTs expand the meaning of token ownership.

Instead of representing one permanent image, the NFT can document progression, current access, product history, software status or another changing relationship.

This flexibility can make NFTs more useful for games, memberships, credentials, intellectual products and physical-to-digital systems.

It also weakens the assumption that the object purchased today will always look or function the same way.

A credible dynamic NFT should make its update rules as visible as its artwork. Users should be able to understand which data can change, who controls the process and what evidence remains after each update.

The most important feature of a dynamic NFT is not animation or changing traits.

It is a transparent state model that allows the token to evolve without making its meaning impossible to verify.

Risk notice: This article is provided for general educational and informational purposes. It is not technical, legal, financial or investment advice. Dynamic NFTs may depend on administrators, external storage, automation services and oracle data. These dependencies can fail, be compromised or produce inaccurate updates.