Extending NEP-171 Events Standard to include NFT `update` events


To extend the NEP-171 events standard to include nft_update events.


The existing events standard for NFTs as described in NEP-171 does not include any events to be logged when the metadata for an individual NFT is updated.

An increasing number of NFT projects (e.g. NEAR Future) are creating upgradable/evolving NFTs, where the individual NFT will change over time. A nft_update event would notify listeners of these updates, ensuring consistent rendering of the latest NFT data.

Some projects and marketplaces (e.g. TENK, Paras, NEAR Future) have implemented a solution for this and the purpose here is to discuss this implementation, iterate as necessary and move to standardize it.



Emitted by NFT contract when any field of TokenMetadata or its associated off-chain data (e.g. reference JSON) is updated.

Not sure if this should include the updated data in question - this could get large for multiple token_ids. Suggest instead that the receiver can then query nft_token() for the provided token_ids to get the updated data.

  "standard": "nep171",
  "version": "1.1.0",
  "event": "nft_update",
  "data": [{"token_ids": ["1", "2"]}]
  • Outside of listening for updates, I think there should be a way to check whether a NFT updates (is dynamic) vs static, so indexers + marketplaces can optimize which NFTs they are listening for. One of the things that I’m most skeptical about is NFT projects rugging on the art and updating it later when the buyer did not intend for this. Would appreciate it if nonupdatable static NFTs had a lock next to the URI and attributes on marketplaces to indicate this. Would also appreciate if this was indicated by a number_of_updates where
  • — 0 = static, 1-many (phased), and -1 meant this NFT can be updated forever (dynamic NFT)
    • With this, would appreciate And there was also a way to check the times a NFT has been updated
    • A use case for phased NFTs is like Pokemon, where you know a NFT has a certain number of levels, until it reaches its final form, where it becomes static again.
  • Would also appreciate it if this was combined with a rich media standard in development as we could tell if the update also changed with the file type, but an aggregation of all these features may result in greater chances of having standard denied

Great points @minorityprogrammers, thanks for the comment!

Re. the first point, this sounds like it could benefit from more robust conversation, but I would argue that the specific implementation details of these kinds of “dynamic” NFTs are beyond the scope of this specific standard addition. Ultimately, developers and project creators will make NFTs that have the functionality specific to their use case, and I imagine this could be a controversial topic. However, I believe a less controversial point is that if/when an update is made, NFT UI’s should reflect this update (at the very least so that the owner is aware that their NFT has updated/evolved), so I would propose that this basic event is implemented first; otherwise IMO we risk putting the cart before the horse and agreeing on nothing rather than making incremental progress. The reality to me is that NFTs are already evolving/updating (see NEAR Future), and as a marketplace we need to know about these updates.

However, if you and others feel that this standard shouldn’t be pushed through before these larger questions are answered, I should probably split these two events into separate proposals, as I think the contract_metadata_update event is less controversial and frankly that’s the one that we really need right now, as a marketplace.

Re. rich media metadata - perhaps this proposal would encompass what you are describing? E.g. according to this proposal, if the media changed (even a minimal change such as filetype), an nft_update event would be logged. Or perhaps I’m not quite understanding, in which case feel free to correct me!


For rich media however standard would still be needed to interpret file type even before a change or update occurred. I believe the rich media standard would optimize display different media types for static NFTs as well.

Good stuff, love to see the work TENK + Paras put in for NEAR Future Primal getting baked into standards everyone can benefit from!

The benefit of events is being able to efficiently listen to them from all assets.

Permanently locking a collection (so that the ART URI or other metadata can not change) can be done by removing all keys from the contract. Whether or not there are keys on a contract is publicly visible.

It would be beneficial for the community to agree on some definitions.

When I think of a dynamic NFT I think of something which doesn’t require events to update itself. Something that’s dynamically rendering itself with code on the client side which allows for data to be pulled from oracles or HCI inputs like webcams/kinect/etc.

There are a different class of dynamic NFTs that render themselves with code on a server and update the image sitting at the NFT art URI. This kind of NFT do benefit from events in case a marketplace or wallet has cached a previous render of the NFT image. Maybe the update standard can have a way for the NFT to indicate NOT to cache the image and always go to the URI (something like the suggested -1 forever updating proposed by @minorityprogrammers ). Otherwise the events channel will become full of spam from NFTs that are constantly re-rendering themselves.

1 Like

I have been under the impression the dynamic NFTs or dNFTs meant that NFTs were not static and could be changed. This may be from a data stream, on chain interactions, or predetermined phases or preuploaded URI links like in pokemon as Starpause is mentioning.

To the point of removing all keys, this seems not directly the same thing as the inability to change metadata. Would be interested to brainstorm on possibilities for creating a locked contract with the ability to still change NFT metadata. Also would be interested in brainstorming scenarios where a contract isn’t locked but NFTs can only remain static.

UPDATE: @lachlanglen will be separating this into general contract events as NFTs are adding complexity that may get the standard rejected

Updated to focus on individual NFT updates, moved contract metadata updates proposal here: Extending NEP-171 Events Standard to include contract metadata `update` events