Minting Greenlist

[samepant]

We need a way to gate access to Minting NFTs. Currently we have a list of ~150 addresses of Greenlist members, and this list will be added to slowly over the life of the contract.

Previous discussion and proposals available on the discord (private for gnosis guild only):

From Jan

I’ve been thinking through the greenlist mechanism and the user flows of the two options we’ve discussed:

1) merkle tree: 🌲

• store valid three word incantations in a database
• hand out three word incantation to users
• users provide their addresses at https://portal.zodiac.wiki/
• we update the merkle root stored in the wand contract (periodically)
• we notify all newly greenlisted users and they can mint their wands

2) signed permit: 🎟️

• generate a set of permits (multi-signed messages) and store them in a database with a three word incantation assigned to each
• hand out three word incantation to users
• user submits three word incantation in minting app and mints wand

Assuming we want the Gnosis Guild Safe owners to be in control of the greenlist, the permit could be validated using the EIP-1271 isValidSignature function implemented in Gnosis Safe. Here’s a test case demonstrating how to generate a valid multi-signature: https://github.com/safe-global/safe-contracts/blob/main/test/handlers/CompatibilityFallbackHandler.spec.ts#L86-L94

[samepant]

I'm a fan of the second method, since it mimics the current process we have (handing out incantation phrases to join the greenlist).

The current ~150 members of the greenlist may or may not still have their incantation phrases, so ideally we could use both methods to support allowing the current addresslist to mint without an incantation.

[samepant]

@jfschwarz in the second, permitted approach, is there a way to invalidate a signature? Say our database of signatures got leaked somehow, could we mass void the signatures we were storing?

[jfschwarz]

@jfschwarz in the second, permitted approach, is there a way to invalidate a signature? Say our database of signatures got leaked somehow, could we mass void the signatures we were storing?

We could mint wands using the leaked permits ourselves (and burn them afterwards). Or we could include a mass invalidation mechanism (e.g. a nonce that we can increment on the wand contract to invalidate all permits signed for the earlier nonce).

In either case, we'd have to be faster than anyone using the leaked information. So it would be wise to not generate too many permits upfront but only keep a small buffer of permits. Whenever possible we should also include the recipient address in the signed permit so it is bound to that person right away.

Worth noting that also with the Merkle tree approach anyone getting access to the database with incantations could use them to mint wands. Yeah, we still need to manually add the supplied addresses to the tree, but we practically have no way to validate whether any supplied address comes from the intended recipient or from an attacker.

[samepant]

added in #91