A proof-of-concept for fair NFT drops
Github • Etherscan • Polygonscan
At 0xEssential we've been learning from other NFT collectible drops to determine the best way to release our collection Wrasslers. We appreciate that projects like ArtBlocks and Parallel are exploring different models to reduce the gas wars that happen on popular drops, and have been impressed by projects like Forgotten Runes Wizard's Cult who used and shared some best practices. Paradigm has written an excellent guide on Designing Effective NFT Launches that offers solutions for fairer launches all the way through metadata reveal. We think we can add something to the conversation by offering this idea and reference implementation to the community.
0xEssential builds developer tools for the borderless metaverse. We help NFT projects and metaverse developers work together to create positive sum outcomes. Our Solidity SDK offers inheritable contracts that provide metaverse capability - standards for types of objects that game and metaverse developers can use to integrate items users already own. We also offer other tooling and resources, like our guide on trustless metadata reveals and our MetaTransaction Middleware approach for building cross-chain games. FairDrop is another tool we hope you'll consider using to realize a more efficient and open approach to NFTs in the metaverse.
Our ideal NFT drop is average user first - no FOMO or failed transactions, fewer bots. No drama, no whales minting 30% of supply, for better or worse. These are the key aspects of a FairDrop:
- Efficient - no more gas wars, and no performance issues related to pageloads.
- Timezone agnostic - crypto is global, and timed drops inevitably put someone at a disadvantage, while launch dates are too frequently missed.
- Distributed randomly - being the quickest to click and pumping gas is not the best way to decide who gets an NFT.
- Decentralized and Trustless - we should strive not to use a centralized database or webserver to manage who can buy what, but recognize the tradeoff between centralization and Sybil-resistance.
We took all of those requirements and built a system that uses raffles with a right to buy reward. Random winners get to mint NFTs at a fair floor price, wherever they are in the world, without needing to submit transactions with exorbitant gas fees.
Address registers for drop on-chain
A user can register their interest in an NFT drop in a decentralized way. We use Polygon for registration to keep things cheap. A project can launch their list before release to build and gauge interest, while users know they have a fair chance to mint. An NFT developer can choose any number of approaches for registration - we provide some examples for using a metatransaction for registration, allowing the project to implement some KYC to be more Sybil-resistant. Project developers can also bulk-add addresses they collect off-chain.
Totally fair random selection
Once a project is ready for launch we use Chainlink VRF to select a random list of eligible minters. These addresses can each mint n tokens, where n x minters is equal to available tokens. Each eligible user can perform an L2 transaction to be checkpointed on L1 by the Polygon CheckpointManager contract.
Chilled out and cheap mints
Eligible minting addresses have 24 hours to mint their tokens. They mint on Ethereum mainnet without the need for gas wars or staying up all night to catch a drop. The minting flow takes a little bit of time as the user must wait for their claim transaction to be checkpointed on L1. Once the transaction is checkpointed, the user can then generate a proof in a dApp and submit the proof as a "mint pass" to the L1 contract.
After 24 hours a new batch of eligible minters is selected for minting. Previous minters become ineligible and we select a new set of minters relative to remaining tokens.
While there are certainly potential pitfalls and improvements to the implementation of this approach, we think these mechanics would be a huge win for NFT collectors without adding much of a burden to project developers. Note that this was hacked together quickly, and while we are testing it in production, this code is not audited or battle-tested at all.
One issue with this approach is that it does not prevent bots from signing up thousands of addresses. We could require at least a small payment for registration, which might help, but adds complexity and might not be accepted by users. It is true that the bot owner would need to check each of their registered addresses for eligibility, and purchase through eligible addresses, but this can be done pretty easily too, and captchas or other web-based tools of course cannot prevent interacting with the contracts directly. In some ways we are forced to choose between decentralization and fairness. Parallel used email registration with a centralized server - this makes it a lot easier to prevent bots, but also introduces trust and the potential of censorship. We do offer one approach where registration is still on-chain, but performed in a meta-transaction on behalf of an address after some KYC. In our demo we use Discord authentication to at least add some assurance we are not allowing individuals to register multiple times.
We don't have all of the answers but hope to kick off a conversation with the community! Thanks for reading, PRs welcome, and let us know your thoughts?