Dynamic NFT (dNFT)

What Is a Dynamic NFT?

A dynamic NFT (often abbreviated dNFT) is a non-fungible token whose metadata is not permanently fixed at the time of minting. Instead, the underlying smart contract contains logic that allows metadata fields (such as the image, description, or attribute values) to be updated in response to predefined conditions. The token itself retains the same token ID and contract address on the blockchain: only the data it points to or generates changes.

This contrasts with static NFTs, where all metadata is set once and never modified. A static NFT representing digital artwork, for example, will always display the same image and description. A dynamic NFT representing the same artwork could evolve over time: changing colors based on the time of day, revealing new layers as holders complete tasks, or updating provenance records as the piece changes ownership.

Dynamic NFTs emerged because many real-world assets and digital experiences are inherently non-static. Tokenizing a property, a game character, or a financial instrument as a static NFT creates a snapshot that becomes stale. dNFTs solve this by encoding update logic directly into the token's contract, keeping the on-chain representation in sync with the reality it models.

How It Works

Dynamic NFTs are typically built on the ERC-721 or ERC-1155 token standards. The key mechanism is the tokenURI function defined in the ERC-721 metadata extension. When a wallet, marketplace, or application wants to display an NFT, it calls tokenURI(tokenId) on the contract. The contract returns a URI pointing to JSON metadata that includes the token's name, description, image, and attributes.

In a static NFT, this URI is set at mint time and never changes. In a dynamic NFT, the contract overrides tokenURI to return different metadata based on on-chain state, oracle data, or computed values. There are three primary technical approaches:

On-Chain SVG Rendering

The contract generates SVG artwork and JSON metadata entirely on-chain. The tokenURI function builds the SVG string in Solidity, base64-encodes it into the image field of a JSON object, then base64-encodes the entire JSON and returns it as a data:application/json;base64, URI. Because the rendering logic lives in the contract, the output can change based on any on-chain variable: block number, token ownership history, staking duration, or stored attribute values.

function tokenURI(uint256 tokenId)
    public view override returns (string memory)
{
    string memory svg = generateSVG(tokenId);
    string memory json = Base64.encode(
        bytes(string(abi.encodePacked(
            '{"name":"dNFT #', tokenId.toString(),
            '","image":"data:image/svg+xml;base64,',
            Base64.encode(bytes(svg)),
            '","attributes":', getAttributes(tokenId), '}'
        )))
    );
    return string(abi.encodePacked(
        "data:application/json;base64,", json
    ));
}

This approach guarantees that metadata is fully decentralized: no external server can disappear or be censored. The tradeoff is higher gas costs for complex artwork, since every byte of SVG increases deployment and rendering expense.

Oracle-Triggered Metadata Updates

When a dNFT needs to reflect off-chain data (sports scores, weather conditions, asset prices), an oracle bridges the gap between the external world and the blockchain. The contract stores the current metadata state and exposes an update function that only the oracle (or an authorized caller) can invoke.

A typical flow works as follows:

1. The oracle monitors an external data source (an API, a sports data feed, a property registry)
2. When relevant data changes, the oracle submits a transaction calling the contract's update function
3. The contract validates the oracle's data and updates stored attributes for the relevant token IDs
4. The contract emits an ERC-4906 MetadataUpdate event so marketplaces know to refresh the token's display
5. Subsequent calls to tokenURI reflect the new state

Oracle networks like Chainlink provide data feeds, verifiable randomness (VRF), and cross-chain interoperability (CCIP) that dNFT contracts can consume. VRF is particularly useful for gaming NFTs that need provably fair random trait generation.

Automation-Driven Changes

Some metadata updates need to happen on a schedule or when specific on-chain conditions are met, without manual intervention. Automation services (such as Chainlink Automation) monitor conditions and call contract functions when triggered. For example, a dNFT representing a time-locked vault could update its visual state each day as the unlock date approaches, with an automation service calling the update function at regular intervals.

Static vs. Dynamic NFTs

Use Cases

Gaming and Virtual Items

In blockchain-based games, characters and items often need to reflect player progress. A sword NFT could display increased damage stats as the player completes quests, or a character NFT could visually evolve as it levels up. Dynamic NFTs make this possible without minting new tokens for every state change. The contract stores the item's current level and attributes, and tokenURI renders the appropriate appearance. Chainlink VRF can add provably fair randomness for loot drops and trait generation.

Real-World Asset Tokenization

When real-world assets like property deeds are tokenized, the token should reflect current data: assessed value, maintenance history, zoning changes, or ownership transfers. A static token would require reissuing every time the underlying data changes. A dNFT can update automatically as oracles feed in new property data, keeping the on-chain representation accurate without disrupting ownership or marketplace listings.

Sports Collectibles

Sports-themed dNFTs update with live player statistics. A basketball collectible, for instance, can display current season averages for points, assists, and rebounds, with the metadata refreshing after each game via oracle feeds. One well-known example was the LaMelo Ball NFT collection, where token attributes changed based on the player's real performance data.

Loyalty and Membership Programs

A membership NFT can unlock new visual tiers as holders accumulate points or tenure. Rather than issuing separate tokens for Bronze, Silver, and Gold membership levels, a single dNFT upgrades its appearance and associated benefits as conditions are met. This is similar to how compressed NFT loyalty programs on Solana reduce issuance costs while maintaining per-user state.

Trust Implications of Mutable Metadata

The core value proposition of static NFTs is immutability: once minted, the metadata cannot be changed by anyone. Dynamic NFTs deliberately sacrifice this guarantee, which introduces trust considerations that buyers and builders must evaluate carefully.

Who Controls Updates?

The most critical question for any dNFT is: who has permission to change the metadata? Common models include:

• Owner-only: the current holder can update their own token (e.g., customizing an avatar). Trust risk is low since the owner controls their own asset.
• Contract-only: updates happen automatically via deterministic on-chain logic (e.g., a counter incremented by block number). Trust risk is minimal since the rules are auditable code.
• Oracle-dependent: an external oracle triggers updates based on off-chain data. Trust shifts to the oracle operator and the data source it reads.
• Admin-controlled: a contract owner or multisig can modify metadata at will. This is the highest-risk model: the admin could alter images, change rarity traits, or effectively "rug" holders by degrading their tokens.

Metadata Storage Risks

Even when update logic is on-chain, the metadata itself may be stored off-chain. If metadata lives on a centralized server, the server operator can change, censor, or remove it at any time. Decentralized storage networks like IPFS and Arweave reduce this risk but may still depend on pinning services for long-term availability. Fully on-chain metadata (as in SVG rendering) eliminates the storage risk entirely, at the cost of higher gas.

Risks and Considerations

Oracle Dependency

dNFTs that rely on oracle feeds inherit the oracle's failure modes. If the oracle delivers stale, incorrect, or manipulated data, the NFT's metadata will reflect that bad data. Oracle downtime can prevent updates from happening at all, leaving the token in a stale state. For high-value use cases like RWA settlement, oracle reliability is a critical infrastructure concern.

Smart Contract Complexity

Dynamic update logic adds complexity to the smart contract, increasing the attack surface. Bugs in update functions, access control misconfigurations, or reentrancy vulnerabilities in metadata-setting functions can be exploited. A thorough smart contract audit is especially important for dNFT contracts because the consequences of a flaw extend beyond financial loss to the integrity of every token's identity.

Gas Costs

On-chain metadata generation and frequent updates consume gas. Rendering complex SVGs in Solidity can cost significantly more than storing a simple IPFS hash. For collections with thousands of tokens requiring regular updates, gas costs can become a major operational expense. Layer 2 solutions and alternative chains with lower fees can mitigate this, but add their own trust and bridging considerations.

Legal and IP Uncertainty

Because dNFT metadata can change after purchase, questions arise about what the buyer actually owns. If a collectible's appearance can be altered by the issuer, traditional notions of digital ownership and intellectual property become harder to apply. Licensing terms that reference a specific image may not account for future mutations of that image.

Marketplace Compatibility

Not all NFT marketplaces and wallets handle dynamic metadata gracefully. Some cache metadata aggressively and only refresh on manual request. The ERC-4906 standard (MetadataUpdate events) helps by signaling when metadata has changed, but adoption is not universal. Buyers may see outdated versions of a dNFT until the platform re-fetches its metadata.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.