Extending NEP-171 Events Standard to include contract metadata `update` events

Summary:

To extend the NEP-171 events standard to include contract_metadata_update event.

Motivation:

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

This results in situations where, for instance, a contract owner will update the contract’s base_uri after it is initially deployed, likely a reference to a dedicated IPFS gateway, but none of the contract consumers (wallets, marketplaces etc) are aware of this change and continue serving the NFT media from less reliable/available gateways. A contract_metadata_update event would alert listeners of any change to contract metadata and enable them to remain up-to-date.

Specification

contract_metadata_update

Emitted by NFT contract when any field of NFTContractMetadata is updated. Includes fields that have been updated

EVENT_JSON:{
  "standard": "nep171",
  "version": "1.1.0",
  "event": "contract_metadata_update",
  "data": [{ "metadata": { "base_uri": "..." }}]
}

I’m for this, want to know if this is more appropriate to put in “standards” section @ori-near

This makes sense! LGTM!

can we get to pushing this on github as a PR if its GTG (good to go)

Opened PR: add contract_metadata_update event by lachlanglen · Pull Request #423 · near/NEPs · GitHub

Olga replied with adding a dynamic NFT flag Support individual NFT metadata logs / dynamic NFTs · Issue #438 · near/NEPs · GitHub

FYI this has been implemented: add contract_metadata_update event by lachlanglen · Pull Request #423 · near/NEPs · GitHub

Related to my post in the token update event standard, let’s keep discussions split for now but hope to do a merged NEP once concerns have been addressed.

I think we should base the event on metadata NEP177, not on core NEP171, as this has obviously a lot more to do with the former. Other than than, it seems to me that the data field wouldn’t need to be an array (should only ever update the contract from which the event is emitted). Now for my draft I also removed the {metadata : {...}} nesting, which might actually useful in case non-metadata is updated along with it. Other than that, additional properties might always be present in the extensible metadata type, so it’s not strictly necessary:

EVENT_JSON:{
  "standard": "nep177", // use corresponding metadata NEP as event basis
  "version":" 1.0.0",
  "event": "nft_update_contract",
  "data": { "base_uri": "..." } // remove nesting and array
}

Regarding the naming, the currently standardized function nft_metadata yields contract-level metadata, so it would make sense for me to keep the nft_ prefix. I have named this consistently as nft_update_contract w.r.t nft_update_token on the token update discussion.