NFT Collection Primitive Discussion

Proposals Brainstorming
1

Hi all!

A few of you may know me from a few hashmask tribes(mainly the voyager hashmask tribe(pay attention!)) or a few defi dev servers.

But I’m bringing it here because I think NFTX has become a bit of a focal point for the NFT space in general, and especially relevant for collections of NFTs. And the community seems active!
This is something I could(and would love to) do if it is a good idea, but here mostly to start the discussion.

It is hard today to agree on what a collection is on the NFT space unless it’s explicitly defined on the NFT metadata, has been determined as such by the market, or is in some index (like an NFTX specific trait fund).

This is I think a problem for several applications, and from the whole stack(from frontends trying to group NFTs) to automating NFT for NFT swaps(for instance saying something like "I would only trade my voyager mask for an alien punk), or even basic inclusion/exclusion features like just allowing alien punks into a server without ad hoc solutions for the particular NFT.

So there is no way that I know of to trustlessly agree on
new and arbitrary collections of NFTs at the smart contract level. So for example, no way to trustlessly agree(even if the agreement is incomplete) on an alien punks, voyager or green dot mask collections, or if the NFT owners approve of their NFTs being part of said collection.

I think I have a simple but working solution for collections of NFTs that can be enumerated, compliant or not with the NFT with the ERC721 enumerable extension, like punks or hashmasks.
And potentially more complicated “key” sets(via more general interfaces). The main idea though is that the collection primitive would just be 3 components: the NFT contract that the collection is of, (say hashmasks if it is the voyager hashmask collection), the set of ids that the collection creator thinks are part of the collection(say the numbers
of the voyager hashmasks), and a set of the ids from the set that have been “verified” by the owners of the NFTs.

Anyone can set up a collection by giving a set of ids and calling the contract, but only the owner of the particular NFT can choose whether their NFT is a “verified” item of the collection(without giving up control of the NFT). Then, even if spammers create many alien
punk collections(punk id sets they say are aliens) it will be obvious which collection is the most socially agreed on by alien punk owners as their collections would fail to show many “verified by owner” punks.

If the NFTs can be enumerated then solutions like EnumerableSets, from OpenZeppelin which are very cheap/fast for adding, removing, and checking for existence in O(1)
can be used, and this would be super cheap even on Ethereum L1, especially for the NFT owners at the detriment of the collection creators.

Best,

smallbraincatperson

2 Likes
2

Hey (owen from 0xmons here), this is a nice idea for a set of primitives that can allow for a lot of flexibility. I see it as a little like the on-chain version of tokenlists, but for NFTs.

I’m happy to jam on an MVP for this contract, as well as better set up the goals for what we’d like for it to do.

My understanding right now is something like:

  1. Anyone should be able to create a collection.
  2. A collection consists of 1 contract address. a set of IDs, and a subset of verified IDs from the owners.
  3. Owners of NFT IDs in a collection can verify if they want their item to be in the collection.

Some things to consider:

  1. If the NFT is transferred, presumably the new owners can add/remove it from existing collections?
  2. We may want to allow for the collections to be named in some way on-chain? Otherwise we’ll need social consensus / off-chain data so everyone knows that e.g. “collection 5 refers to alien punks”.
  3. Is it worth considering extending this to more than one contract at a time? EX: collections could be seen as curated collections of e.g. “high-quality pixel art NFTs” or something.
  4. More restrictive access control of a collection? Can the curator of a collection guarantee that no more IDs can be added after some condition is met? Maybe they revoke ownership?
3

Hi!

Yeah, token lists are the closest I’ve found to this idea. By the way, I left some conceptual
questions pursposely vague so as to not exclude potentially better or more interesting
implementations and too leave the solution space as open as possible.

About “things to consider”:

  1. Yeah, that is right.
  2. Yeah. I was considering a general metadata field. I’m not sure what the best solution
    for this might be, but I’m thinking a URI like the ERC721 metadata extension could do. Something like
    a URI pointing to something like this:

{
“title”: “Asset Metadata”,
“type”: “object”,
“properties”: {
“name”: {
“type”: “string”,
“description”: “Identifies the asset to which this NFT represents”
},
“description”: {
“type”: “string”,
“description”: “Describes the asset to which this NFT represents”
},
“image”: {
“type”: “string”,
“description”: “A URI pointing to a resource with mime type image/* representing the asset to which this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive.”
}
}
}
3. Yeah. And that’s the reason I want a general interface for non-enumerable NFTs(even non-ERC721s
like punks).

  1. I think I have to think more about it, but my initial opinion is that for a low level primitive
    you want the bare minimum and then build on top of it. You can create a higher level contract that
    creates a collection later with the access control you need. Like a contract for permanent(non changeable
    collections) that deploys a collection for someone and then calls revoke ownership for them, as you say.

Note: I’m starting to think collections may be good candidates for ERC721s. Then we
get safe transfers and the rest for free.

Thank you so much for responding!