Implementing Onchain Whitelists to prevent community front-runners

[jerryfane]

As we strive to continually enhance our Generative BRC-721 standard, one area of improvement we're considering revolves around the minting process within deployed collections. Currently, the protocol allows anyone to freely mint any deployed collection without limitations. While this underlines the open nature of blockchain, it may sometimes disadvantage genuine community members who might get outpaced in the minting race.

To further optimize the community's experience and ensure fair distribution, we're contemplating the incorporation of an on-chain whitelist. This would entail adding an optional new key in the deploy inscription, which would point to a separate inscription containing the whitelist details for claiming tokens.

Here's an illustrative example of the proposed whitelist inscription format:

[{'bc1perj...snatu9z': [583, 584, 585, 586]},
{'bc1pkjn...qqs2r3c': [587, 588, 589, 590]}]

In this arrangement, 'bc1perj...snatu9z' and 'bc1pkjn...qqs2r3c' would be the only wallets able to claim token_ids [583, 584, 585, 586] and [587, 588, 589, 590] respectively, until a specified Bitcoin block deadline is confirmed.

This modification would provide a more managed and fair distribution system for our GBRC721 collections, preventing front-runners for a set of token_ids.

[russanto]

As it is just an informative way to include such whitelist data, since there is not an actual on-chain constraint to enforce, wouldn't it be enough to just include a Merkle root of the Merkle tree containing the whitelist data ? Then the entire tree can be shared with the community and verified on-chain.

Moreover on the general level, my point can be extended also to: is it worth to inscribe an entire whitelist on-chain, which:

1. is throw-away data because it becomes useless once the mint is gone;
2. does not provide any on-chain constraint since it is up to the entity managing the mint to follow it ?

The Merkle root would provide an equivalent solution, so the community can verify the whitelist was followed.

[offerT]

Thank you Jerry for your contribution to GBRC721. Can the allocation mechanism of the whitelist learn from the allocation method of BRC-20? After the team deploys the token, they can mint all of it directly and then transfer it to whitelist users and public users through the launchpad.

For example: As a high-definition, paid NFT collection, the team can mint a whitelist number of NFTs after deployment and then wait for whitelist users to claim them. Then proceed with public minting. (With the existence of h(hash), other users cannot mint in advance without public JSON/Text inscription) Since the main cost of GBRC721 is on the deployer, minting a small number of additional whitelists does not increase the cost much.

If Jerry mints 100 bots before publicly releasing ordiBots JSON/Text inscription, it is equivalent to having 100 whitelists. Of course, as the founder of GBRC721 and ordiBots, I think if you like collecting ordiBots, the ordiBots community will send ordiBots to you.

[offerT]

GBRC-721 is a great innovation.

[jerryfane]

@russanto

As it is just an informative way to include such whitelist data, since there is not an actual on-chain constraint to enforce, wouldn't it be enough to just include a Merkle root of the Merkle tree containing the whitelist data ? Then the entire tree can be shared with the community and verified on-chain.

That's really an interesting point. That's definitely something that collection creators can do on their own, no need to actually insert any onchain data at this point. The cool thing about the approach I proposed, is that it can easily be used by on-chain listener to actually validate if the mint was inscribed by the correct wallet found on the whitelist or not (eg. Dune Dashboard). This allows collection creators to easily index which are the "valid" inscriptions of their collection if they decide to go with the FCFS + WL approach.

However, at the end of the day, with this standard, my goal is solely to make the inscriptions for ordinal collections more streamlined, not to dictate how creators should gather the official inscriptions that will form their collection. So they are actually free to choose which method they want to use to actually gather the inscriptions that will create their collections.

Moreover on the general level, my point can be extended also to: is it worth to inscribe an entire whitelist on-chain, which:

1. is throw-away data because it becomes useless once the mint is gone;
2. does not provide any on-chain constraint since it is up to the entity managing the mint to follow it ?

Regarding point 1: anyone will be able to re-use a WL inscription for their collection, but I agree, this is not the perfect way in terms of efficiency, it can be improved. I'm looking for suggestions here. Regarding point 2: yes that's exactly it. As I said above, I don't want to enforce creators to follow a specific method to collect their inscriptions.

[jerryfane]

@offerT

Thanks a lot for your support.

Can the allocation mechanism of the whitelist learn from the allocation method of BRC-20? After the team deploys the token, they can mint all of it directly and then transfer it to whitelist users and public users through the launchpad.

Absolutely, with the approach suggested above, the collection creator can whitelist their own address to mint the necessary supply for their team. As I noted in my prior response, they can still mint any inscription they wish without any on-chain restrictions, and share the list of inscriptions with marketplaces or ordinal platforms on their own terms, without really worrying about first-come-first-served scenarios and frontrunners. But this could perhaps lend more credibility to their own mint.

I expect GBRC721 launchpads coming, and not really caring about mints done outside the launchpad.