I am planning on submitting a grant application to develop a SNIP721 reference implementation, so I am creating this topic to get some community feedback.
My thoughts on implementation are that upon instantiation, the token creator would configure whether:
- Ownership is public/private (default: private)
- Additional private metadata is enabled/disabled (default: enabled)
- That private metadata is/is not sealed (default: disabled)
- Burn is enabled/disabled (default: disabled)
It will have public metadata, and the enabling of private metadata will be in additional to the public, so that a token creator can have a mix of public/private data. Enabling sealed metadata means that the private metadata is not viewable by anyone, not even the owner, until the owner calls a Reveal function. When the sealed metadata is Revealed, the private metadata will irreversibly be moved to the public metadata. This will simulate being able to buy/sell wrapped cards that can have different rarities, although the actual card purchased is unknown until you unwrap the card. To be clear, I don’t believe that Seal/Reveal should be in the SNIP721 spec, but I think it is a nice additional feature to put in place with the reference implementation.
The owner of a token will be able to whitelist addresses to have permission to:
- View the owner of the token
- View the token’s private metadata
- Transfer the token
When whitelisting addresses, the owner can choose whether an address has the specified permission on just a specific token or on all of the owner’s tokens.
An optional, private memo can be included with any mint, transfer, or burn transaction, and only addresses involved in the transaction will be able to view that transaction (and its memo) in their transaction history
Along with creating the reference implementation, I will create a SNIP721 toolkit package similar to what I’ve already created for SNIP20 (secret-toolkit/packages/snip20 at master · enigmampc/secret-toolkit · GitHub) so that contract devs can easily interact with SNIP721 contracts.
I will also rewrite the SNIP721 spec. The current spec is just copy/pasted pieces of the cw721 spec and the SNIP20 spec, so it is inconsistent in how it specifies parameters for different functions. And the pieces that are copied from the cw721 spec do not take into account the possibility of private ownership or metadata. I suspect as the initial snip721 implementation gets feedback, the requirements/features of the SNIP721 spec will evolve as well.
I’m not sure whether the following future work should be included in the same grant application as milestones or submitted as separate applications, but once the SNIP721 reference implementation/toolkit/spec is finished, I will update the auction contracts so that you will be able to auction SNIP721 NFTs, and I am considering adding the capability of creating a special type of an NFT auction where the auction creator can specify a specific NFT they want in return. So the auction can facilitate a swap of two different NFTs. I am also considering adding the ability to specify a set of NFTs that are wanted in the trade, which would not be completed unless the “bidder” is able to provide all the components. This would act like being able to trade one rare game-related NFT for several other NFTs in the game that aren’t as rare/powerful.
Also, because I expect there could be more bidders on NFT auctions than for SNIP20 auctions/OTC trades, I will probably want to update the auction contracts to overcome the gas-limit issue. Because SNIP20s don’t have a batch send function, each losing bid has to be returned with a separate message. I will probably update the auction contracts so that when an auction is closed, it will determine and lock-in the winning bid, but return the losing bids in blocks of 50-60. So besides active and closed auctions, I’ll need to add a pending state for auctions that have closed, but haven’t returned all the bids yet.
Another future task I would like to do is create a UI where someone can easily instantiate a new SNIP721 contract. The UI would also allow them to perform admin commands on their contract (disable transfers, whitelist minting addresses, etc…), as well as provide an easy way to mint new NFTs. Because most NFT creators won’t want to code their own contracts, the UI should have the ability to not only specify the metadata uri, but also help create the uri so that it has the different fields the user needs. It would probably be best if the UI also hosted the uri page for the creator, instead of the creator needing to host it themself, but if providing hosting service is will be part of the UI, the funding will need to reflect those costs. If the metadata uri information is formatted according to the UI’s specifications, the UI will also be able to display all the relevant token data, like name, description, image, attributes, etc…as well as handle the ability to display any of the private information authenticated by viewing key
Again I don’t know whether all of those should be considered different milestones in one application or if each should be a separate application. So I guess I’m hoping to get some feedback on what people like/dislike about the proposed implementation, whether only the reference implementation/toolkit package/spec update should be included in the (first) application, and also what people thought would be a fair asking amount for the work.
And thank you to anyone who read through all of that to get to this point!