Airdrop and claim

The claim surface collects wallets that held $BOTIFY at a snapshot and want the airdrop. It is a list of interested, eligible holders and nothing more: no amount is calculated, stored or promised, because distribution has not been decided and a number in the table would look like it had been.

Eligibility is decided at import

Eligibility is resolved once, when the snapshot is imported, not on every request. The importer reads the snapshot, applies a balance floor and a list of exclusions, and writes one holder row per wallet with eligibility already decided. The claim endpoints are then an indexed lookup rather than a scan of every holder.

Re-importing replaces the whole snapshot rather than merging into it. A snapshot is immutable, so a second run is either a no-op or a deliberate policy change (a new floor, a new exclusion), and only a full replace guarantees no stale eligibility is left behind.

Policy lives in code and committed data, not in environment variables. The snapshot is committed and the floor is a published rule, so both mean the same thing in every environment; changing either changes who is eligible and deserves review.

Proving ownership

Registration proves a wallet without moving any funds. It is three steps, all off chain, with no fees:

1. The browser requests a nonce. The server checks eligibility and issues a single-use nonce with a short time-to-live, returning the exact message to sign.
2. The browser asks the wallet to sign that message.
3. The browser submits the signature. The server rebuilds the message from the stored nonce, verifies the signature, and writes the claim.

Two properties matter, and both are easy to lose:

• The message is rebuilt server-side, never read from the request. A client that chose its own message text could have a user approve one thing and submit a signature over another.
• The nonce is burned in the same transaction that writes the claim. Otherwise two requests racing the same signature both pass, because verification is a pure function and nothing has been written yet.

No dependency for verification

Signature verification uses the platform's built-in cryptography for raw ed25519, so there is no third-party crypto dependency in the path that decides whether a claim is valid.