Airdrop Form: Collect Wallet Addresses, Filter Out Bots

This guide is for the team running the drop, not for people hunting airdrops. It covers the form, the checks, the snapshot and what the form must never promise. If you want a whole waitlist for a token or a crypto app, with a page, a place in line and launch emails, see our crypto waitlist software page. Sources were checked on November 10, 2026.

What an airdrop form should collect

Two fields are required, and two are worth considering:

Put one line right under the wallet field: "Your public wallet address only. We will never ask for your seed phrase or private key." Ethereum.org's security guide is plain about it: "No legitimate service, support agent, or website will ever ask you for these."

Why the email matters even though the drop is on chain

• The claim opens on a date. You cannot email a wallet address, so the email is how people hear it is open.
• People change wallets. Someone who lost access or moved to a new wallet can tell you before the snapshot, if you can write to them.
• Verification costs a farm something. Ask people to verify their email and every fake signup now needs a working inbox.

Email and wallet, or wallet only?

A wallet-only form has the fewest fields and collects no email address. It also gives you no way to reach anyone, nothing to verify, and no way to hold a referral until a person proves anything. Choose it only if your community already lives on a channel you control, such as a Discord server, and you are not running referrals. Otherwise, ask for both.

Wallet address form checks: format is not control

A wallet address form can check three things on entry:

• The shape. An EVM address is 0x followed by 40 hexadecimal characters, so ^0x[0-9a-fA-F]{40}$ catches a missing character or a pasted sentence. Solana addresses use a different alphabet and are case sensitive, so a check written for one chain rejects the other.
• The checksum, sometimes. EIP-55 puts a checksum in which letters of an address are capitals. An address typed all in lowercase or all in uppercase is also valid, so it carries no typo check, and whether a tool checks the mixed-case checksum at all depends on the tool.
• Exact repeats. Whether the same text is already on the list.

What a form cannot check is control. A form receives text, and anyone can type someone else's public address: a friend's, a famous wallet's, one copied from a block explorer. That includes registering an address before its real owner does, to take its place on your list. The only proof is a signature from the wallet itself. Sign-In with Ethereum (ERC-4361) is the standard for this: it "describes how Ethereum accounts authenticate with off-chain services" by having the wallet sign a standard message. Ask for that signature in your own app before you freeze eligibility and whenever someone asks to change their wallet, not only when people claim.

A signature proves control of one wallet. It does not tell you whether the person controls others, which is the sybil problem below.

Google Form wallet address collection: where it falls short

A Google Form works for a small list of people you know. To be precise about what it can and cannot do:

• It can check the format. On a short answer question, Response validation offers Regular expression with Matches, so the EVM pattern above works (Google's help).
• It limits Google accounts, not wallets. Limit to 1 response means people "must sign in to their Google Account" to fill the form in (Google's help). That stops one account answering twice. It does not stop two accounts, or ten, entering one wallet, or one person entering ten wallets.
• Repeats are cleaned up afterwards. No setting rejects a wallet address that was already submitted; you remove duplicates in the Sheet.
• Nothing checks the signup itself. There is no disposable email check, no device check and no way to hold a suspicious response for review.
• No referral links or place in line, if you want people to share.
• Size. Google lists a limit of 500,000 responses per form from September 2026, and says Sheets syncing can stop working above 100,000 responses (Google's help).

If you still want to start there, our guide to make a waitlist with Google Forms covers the settings that matter.

Sybil attacks on an airdrop: what a signup list can catch

A sybil is one person or one operator posing as many participants. In an airdrop, that means many wallets, often with many email addresses, run by the same hands to collect many allocations. Arbitrum's governance docs define sybil accounts as accounts "controlled by an entity trying to create the false appearance of being many entities." Sybil detection is the work of finding suspected clusters before tokens go out.

Some of that work can happen at signup. Each signal can catch something, and each can let something through:

A signal is evidence, not a verdict. LaunchList adds the signals into one score: a signup below the first line is accepted, one above it is held for you to review, and one above a higher line is refused. A throwaway address on its own raises the score without refusing the signup. Referral credit is a separate decision: a referral can be denied credit while the signup itself is accepted. Our waitlist spam protection page shows how the checks fit together.

What these signals can miss is one patient person with fifty real inboxes, fifty wallets and fifty signups spread over a week. Each of those signups can look like a real person, because each one is a person's work.

Sybil detection at the snapshot

That kind of sybil may show up on chain instead. The method behind Arbitrum's ARB airdrop is public in its sybil-detection repository:

• Remove what isn't a person. Exchanges, bridges and smart contracts come off the list first.
• Map the transactions as a graph. Each transfer of ether between two addresses is a link.
• Look at who funded whom. The repository calls the first ether transfer to an account its "funder" and the last transfer out its "sweep". Many wallets funded from one source, or swept to one, can point to one operator.
• Find dense groups. Its patterns are addresses moving funds within a cluster of more than 20 addresses, addresses funded from the same source, and addresses with similar activity.
• Collapse the cluster. Arbitrum's docs say the accounts within these clusters "were collapsed into a single recipient account for the airdrop."

This finds suspected related wallets, not proof. Arbitrum's own docs call the large, dense groups "likely Sybil clusters." Graph analysis can miss a careful farm, and it can flag real people, for example friends funded by the same person. Review each cluster before you exclude anyone, and record why.

Other teams use an identity score instead of, or beside, graph analysis. Human Passport, previously known as Gitcoin Passport, describes itself as "a Sybil resistance protocol and identity verification platform": people collect stamps, which "aggregate identity attestations from web2 and web3 authenticators."

Two habits can help either way. Say on the form that sybil filtering happens and that suspected clusters may be merged or removed after review, without publishing your thresholds. And think twice before giving more to people who refer more: a farm can refer itself.

From airdrop registration form to snapshot: dedupe, verify, freeze, export

1. Keep one row per address. Make the wallet address the field that tells one signup from another, so the exact same text cannot take two rows. Then look at the email column: two wallets on one email can be one person, or a shared inbox.
2. Make addresses comparable. Lowercase 0x addresses before you compare them, since their capitals are only a checksum. Resolve any ENS names to their addresses and dedupe again: name.eth and the 0x address it points to are different text, so they stay two rows until you do. Check every address for the chain you drop on in your own tooling.
3. Verify control before eligibility is final. Ask each wallet for a signature in your own app, so an address someone typed but does not control cannot hold a place. Do the same before you approve a change of wallet.
4. Freeze a snapshot time. Write the date, time and time zone on the form before you open it. Signups after that moment are out, and so are changes.
5. Run sybil analysis on the frozen list, as above, review the suspected clusters, and record which rows you merged or removed and why.
6. Export a CSV with one row per wallet to whatever does the drop: your claim contract's list, a distribution tool or your own script. Keep the file and your rules, so you can answer "why wasn't I included?"

What an airdrop form must never say

• No amounts, values or returns. "Join to hear when the claim opens" is fine. "Join to get 500 tokens" or "the earlier you join, the more you get" is a promise you may not be able to keep, and it reads as an offer.
• No tiers or multipliers for joining early or bringing friends.
• No seed phrase, no private key, no payment. A signup form has no reason to ask for any of them.

Promoting crypto is regulated in many places, and an airdrop form can count as a promotion. In the UK, the FCA's rules have applied since 8 October 2023 to all cryptoasset firms marketing to UK consumers, including firms based overseas, with specific risk warnings and "positive frictions (such as a 24-hour cooling off period)", and its policy statement PS23/6 includes a ban on incentives to invest. In the EU, MiCA sets out exemptions for some offers, including some crypto-assets offered for free, and rules for marketing communications in Article 7. Have counsel assess whether people must give personal data in exchange for your token, whether an exemption applies, and which marketing rules apply where your signups live; this is not legal advice.

Setting up an airdrop form in LaunchList

Disclosure: LaunchList is our product. It is pre-launch waitlist software for founders: it collects the list, filters bots out of it and gives you a CSV. It takes no payments, connects to no wallet, asks for no signature and does nothing on chain.

1. Add a Wallet field. In the form editor, choose Add field, then Wallet under More fields. By default it accepts address-like text, including ENS names, and turns away anything with spaces or stray symbols. To take addresses for one chain only, set its Address format to Ethereum and EVM chains (0x…) or Solana: the form then refuses text that is not shaped like an address on that chain, and ENS names with it. It never checks the EIP-55 checksum, so check the addresses in your own tooling before the drop.
2. Recognize signups by wallet. Under the form's More options in Properties, set Recognized by to Wallet address, so the same address cannot take two rows. Matching is on the text: 0x addresses are compared in lowercase, so a checksummed copy and a lowercase copy match; Solana and Bitcoin addresses are compared exactly as typed; and ENS names are not resolved, so name.eth and its 0x address are two signups. Keep an Email field on the form: the verification link and every email go to that address.
3. Keep "Ask people to verify their email" on. It is on by default, and referral credit waits for the click. On a form with no Email field there is nothing to verify, so referral credit lands at once: if you run referrals, keep the email.
4. Turn the checks up before you announce. In Project settings, Privacy & spam, add your own Turnstile, reCAPTCHA or hCaptcha keys in the CAPTCHA row, and set Referral checks anywhere from Off to Strict, which moves the lines where a signup is held or refused. Held signups wait behind Review on Audience, Signups. The spam and trust guide covers each check.
5. Treat points for follows as honor system. Actions such as following you on X give points when someone opens the link; we don't check that they followed. Points only move a place in line and never unlock a reward (how referrals work). They are on the Collect plan and up. Don't base allocations on them.
6. Export at the snapshot. Export on Audience, Signups gives a CSV with the wallet, the email, the trust tier, the time each person joined, referral counts and every form answer (import and export). Or send each signup to your backend as a signed webhook.

The Wallet field, the spam checks, your own CAPTCHA keys and CSV export are on every plan, including Free, which holds 100 contacts. Paid plans are sold by list size up to 100,000 contacts; for a bigger list, talk to us. Signups past your size are kept but hidden until you move up, never refused. The form builder itself is described in the form builder guide.

To try it, create a waitlist, add a Wallet field, and write your snapshot date on the form before you share the link.