ZRC-6: Call for feedbacks

[bb111189]

We are seeking feedback for ZRC-6 before we formally standardize it. Please use this thread for discussion

[darthgus]

Hi Jun

I have read over the spec - looks great and feature rich compared to zrc-1.

I have 1 question though - in relation to a game with NFTs, is there in this spec the ability to change the metadata uri after creation?

The use case would be in the case of a game where you want to store temporary "boosts" on the metadata.
Or maybe stats for a NFT, but when you mint them, you havent finalised that metadata yet (Im thinking stats for the NFT, again more referencing the opensea metadata standard).

Also - is there any definition/standard for how the metadata should be laid out or any specification for that? More referencing something like the opensea metadata standard?

https://docs.opensea.io/docs/metadata-standards

EDIT - sorry I now read the bottom of the medium article, and it sounds like this will be covered with ZRC-7 thanks :)

I guess my questions on is the metadata editable after creation is still valid.

[bb111189]

That will depend on where the metadata is stored.

For immutable metadata, users can pick options such as

1. IPFS
2. Arweave

For mutable metadata, users can choose services such as

1. AWS S3

The token uri can contain any URI be it mutable or immutable storage

[Kannas24]

I feel more confident and positive after reading ZRC-6 standards, they look promising. KUDOS for that..!!

Three things where I need the community’s attention (or more clarity on)

1. ZRC-6 standardizes token URI with the concatenation of base token URI and token ID Token URI . This assumes contract owner to upload all the metadata files to the storage with {baseUrl}/{tokenid} path. This doesn't; go well with distributed storage where things are immutable i.e. you can never get a baseURI in case of IPFS or Arweave, as they generate content hash and transaction on each successful file upload, of course, we can use IPNS to create/upload a folder that will contain all our metadata files, which I don't think is useful when we are dynamically minting NFTs(hence metadata) and need to follow immutability(the core of distributed storage). It's just my opinion, I would be more than happy to be corrected.
2. Do you think we can add royalty at the token level also(I know we are targeting to have one address per contract to receive the royalty/reward, default to contract owner) like whosoever has minted the token will get the royalty on each successful token ownership transfer/buy. Usecase: I have recorded an audio/video, minted it as an NFT (the original creator will always hold the rights of the song), anyone can own/buy it, and then use/hold or sell it but every time they sell a small part of the amount they received will go to the original copyright holder to make the system more rewarding.
3. Unlockable NFTs: I know it's more of a off-chain thing(dApp and marketplace) but does anyone know a way to(or want to propose) restrict the actual NFT content metadata i.e. only the owner of the NFT can view it? We can completely ignore this question if it sounds irrelevant.

[ghost]

@Kannas24 Good point. For the token URI, we want to support the special cases with decentralized metadata URIs via #119. We can discuss more in the PR.

Here are references:

• OpenZeppelin Contracts 4.0 Beta
• Why doesn’t OpenZeppelin ERC721 contain setTokenURI?
• Function _setTokenURI() in ERC721 is gone with pragma ^0.8.0
• OpenSea - Metadata Standards

[ghost]

@Kannas24 For the royalty info, we want it to be very minimal and simple.

I think supporting royalty at the token level would overcomplicate this standard more than it needs to be.

I agree with the EIP-2981 Rationale: Simple royalty payments to a single address.
https://eips.ethereum.org/EIPS/eip-2981#simple-royalty-payments-to-a-single-address

This EIP does not specify the manner of payment to the royalty recipient. Furthermore, it is impossible to fully know and efficiently implement all possible types of royalty payments logic. With that said, it is on the royalty payment receiver to implement all additional complexity and logic for fee splitting, multiple receivers, taxes, accounting, etc. in their own receiving contract or off-chain processes. Attempting to do this as part of this standard, it would dramatically increase the implementation complexity, increase gas costs, and could not possibly cover every potential use-case. This ERC should be considered a minimal, gas-efficient building block for further innovation in NFT royalty payments. Future EIPs can specify more details regarding payment transfer and notification.

[csajedi]

Since the spec is already feature rich, perhaps we should also consider how to add metatransactions.
Metatransactions for NFTs are not a reach, especially for games it would be nice to have the option of giving users a fiat-free onramp that might include SaaS-style promotions like "first 5 days [or transactions] are free for new users". This requires fully authorized metatransactions that instead consume a fee token. Without modification, the existing zrc-2 and zrc-3 contracts could fulfill this role as a fee token if we had either a
contract-wide approved operator which would then be a smart contract shim that processes transfer authorizations (metatransactions) for users. This is still compatible with all security and decentralization benefits the Zilliqa network offers as long as this DefaultOperator is the safe shim smart contract. Alternatively a ZRC-6 variant could be produced that includes authorized transfers in the same manner as ZRC-3.

[bb111189]

We are thinking to have a variant similar to ZRC-3. It may take more time as we will like to spend extra effort to understand what are all the requirements for meta txn beyond just the default operator and see we can come up with any other new innovation or not

[Kannas24]

Do we have any plans to incorporate ERC1155 standards?

Multi token + Multiple owners

[bb111189]

Do we have any plans to incorporate ERC1155 standards?

Multi token + Multiple owners

We have intended this to be part of a future separate standard

[ABlanford]

Has the ZRC6 been formally accepted and is now the ZRC Standard?

[ghost]

Yes, we have finalized it.