Whitelist Automatization

Based on the options presented in the market, I will highlight the following options that are the most flexible and effective:

1. WL Bots for Discord Server (DS)

Based on the options presented in the market, I will highlight the following options that are the most flexible and effective:

The main functionality includes:

• Collecting user data for adding to the Whitelist (WL).
• Exporting all data of users added to the WL in the format: unique ID; DS nickname; wallet address.

Example:

• Ability to create multiple WLs for different categories of users.
• Creating a dedicated wallet validation channel to check its presence in the WL, relieving support from the need to manually validate it constantly.

Example:

There are several bot options available for creating and managing WL, here are some examples:

1. Lambda – $350 / 1000 slots in WL, one-time fee per server.
2. MindleIf WL bot – $800, one-time fee per server. This bot is from Sock DAO, and they have a specialized department for Discord servers and various features for it, including bots. The bot for NFT holder verification is their creation.

Pros:

• Quick setup; technical implementation is not required from us as the development team installs and configures the bot for us.
• Simple ways to validate WL for users, avoiding confusion on whether they are on the list or not.

Cons:

• WL collection only in Discord, limiting users’ choice of platforms and requiring them to join Discord.
• Since these bots are primarily designed for ETH and L2, where the same address is used for testnet and mainnet, there is no direct way to match testnet and mainnet addresses. However, in theory, two separate lists can be created for test and live environments, and addresses can be matched based on the user’s ID.
• Limited customization options as data export is not customizable, and there is only a specific set of data that can be collected from users.

Conclusion: This option has low resource costs, is easy to set up and moderate directly from Discord Server. However, manual matching of users based on testnet/mainnet addresses remains a challenge.

2. WL Management Platform

As an example, we can mention WenMint, which is an NFT launch platform with additional functionality for collecting WL and various DS bots that allow users to obtain information about the collection. Currently, the launch works only with ETH.

Based on this launchpad, a toolkit for collecting and managing WL has been created, with some features partially integrated with Discord Server.

Functionality:

• Allows distributing slots in WL and assigning roles to users in DS.
• Users can directly add addresses through Discord instead of having to go to an external platform.
• Addresses added to WL are stored off-chain on the platform.
• Allows creating a merkle tree from the data collected in the WL.

Currently, it is mainly associated with launchpads, i.e., WL + token/NFT launch. It suits us indirectly.

Pros:

• Convenient management of all data collected in WL.
• Easy data collection from users through Discord or the platform itself.
• Possibility of linking WL directly to token/NFT launches when needed.

Cons:

• Does not automatically match testnet and mainnet addresses.
• Limited by blockchain compatibility, as not all functions may be available to us since we are on NEAR.

Conclusion: This is a good solution for WL when it is associated with the launch of something like a token, NFT, etc., as it provides an ecosystem for launching and integrating WL directly into the minting smart contract, for example.

3. Google Forms + Google Docs + Macros

This involves creating a classic Google form and spreadsheet where all data from the WL is collected, but with macros written to automatically filter the table and keep only the necessary values.

For more convenient matching of addresses and to avoid the need for combining two tables, one option might be to add two address fields in the form: testnet and mainnet.

The key challenge in creating WL using Google forms lies in dealing with large volumes of irrelevant information, especially concerning addresses.

The steps are as follows:

1. Try to identify all problematic criteria for information that enters the WL.
2. Compile a list of these criteria: filter addresses based on character count, languages, specific characters, and determine if we can implement such filtering within Google spreadsheets.
3. Write and embed macros that will filter all incoming information based on the criteria described.

Example: All user information is added to the table on Sheet 1 through Google form entry -> The information is filtered by macros, and the remaining filtered users and their data go to Sheet 2 -> Upon completion of WL collection, we additionally check the information on Sheet 2 to avoid including any unexpected irrelevant data in the final WL.

Pros:

• Suitable for collecting any type of addresses/social media/other information, a flexible solution that allows us to collect practically any WL when necessary.
• Easy interaction with the service – many people are familiar with Google spreadsheets, so we can assign tasks related to WL to a broader audience without having to explain how a specific platform works.

Cons:

• With each WL collection, the necessary data will likely change, so we will have to gather the requirements list and rewrite macros again.

Conclusion: This option is suitable for collecting various WLs, and customization allows us to gather any information list within the capabilities of Google Forms. However, it only works if we can involve the technical department to write macros. Otherwise, it is not suitable due to the complexity of filtering incoming irrelevant data in large volumes.