Skip to content

Ditch whitelist in favor of opt-in #53

@gruvin

Description

@gruvin

Opportunity

Maintaining a whitelist amidst an unpredictable sea of DEXs and DEX aggregators seems untenable. It certainly isn't "decentralized" and also ties the contract creator to a responsibility they could do without in their lives.

Solution

Instead, why not allow or indeed require wallets to opt-in to NFT mint/burning aspect of 404's? This could be done prior to any engagement with the 404 contract or after-the-fact, minting as many NFTs as their current balance permits.

If opting in is a one-way process — not able to be reversed — then all other functionality and tokenomics are retained for all users.

Efficiency

There is a gas cost in having the contract maintain this list of opt-ins, which will in most cases be considerably larger in size than the existing whitelist scheme. (You could have both, I suppose, with opt-ins overriding the whitelist for security/trust reasons.) The extra SSTOR cost might be optimized by packing groups of 256 accounts into single bit binary boolean's — 256 opt-ins stored in a single storage slot — based on your now deterministic NFT token IDs — though that implies that a holder must have at least NFT to be opted in. Just a thought.

Conclusion

You're welcome. :p

gruv0r

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions