ERC721 Subset

This is about a small ERC721 contract I wrote, but let me give you the context first.

I think of NFTs as a new data pointer. Much like filesystems (file path + file name), and URLs (protocol + server + path + filename), NFTs (contract address + item Id) provide us with a way to point to data.

If you think of an ERC721 contract as a bucket of "files", we have developed ways to present, query and organise these "files": We can refer to a specific one by Id, but we also have tools like NFT marketplaces that allow us to filter by trait.

The problem is that filtering by trait is based on the decisions that the smart contract developer did: If the contract creator added a colour trait, we can easily filter by colour for example.

But what if we want to create a different grouping? What if I want to create a way to group together my favourite items of a NFT collection, or the ones that have a characteristic not explicitly described in the NFT metadata? The most common example of this is ENS clubs: .eth domains that follow a pattern that some users find valuable or interesting (all digits, 4 digits, palindromes, English names, Arabic numerals, all emojis, etc.) We do not have a tool to do this grouping on-chain.

This is where my smart contract comes in. I call it "ERC721 Subset" and I tried to implement it in a way that conforms with the ERC721 standard, but:

• It does not allow approvals and transfers (all related functions revert with an error.)
• All tokens are owned by the contract and (based on the above) can't be transferred or traded.
• The contractor needs a ERC721 contract address (the "original collection") to be passed to.
• There is an add(tokenId) and remove(tokenId) that add a token from the original collection to the subset. They are implemented as mint and burn functions to allow services like NFT marketplaces to track the addition and removal of tokens in a way that they understand.
• There is an exists(tokenId) function that allows an other service or contract to check if a token is part of the subset.
• tokenURI(tokenId) is proxied to the function of the original contract, so the sub collection NFT looks exactly like the original one.

To illustrate how this works, I created an ERC721 Subset of the OnChainBirds collection that contains what their community call "greyscales": These are birds that happen to use only black, white and grey traits. There is no specific trait that describes grayscales, but a user went through the whole collection and identified 17 of them.

So, I deployed A ERC721 Subset called "OnChainBirds: Grayscales". If you look at the etherscan page of the contract, you will see the contract creation and the add() calls to add the specific token Ids. If you go to the OpenSea page (or any other marketplace) you will get a nice gallery of these tokens.

This is a first take on the idea. There are probably ways to make the smart contract more efficient, or more secure or add some features that will make it more useful. It would be nice for example if there was a way to programmatically manifest that this is not a normal ERC721 contract. Or a more efficient way to add multiple items. What are the implications for services (wallets, marketplaces, etc) that deal with ERC721 tokens? Would it make sense to make this an ERC standard?

If you have any suggestions or ideas, ping me @vrypan.