# How to run an airdrop for my community on Cherry

> Run an airdrop for your community inside the chat: first-N or a time window, holder, whitelist and room rules, and a payout the claimant signs on Solana.


Search "how to run an airdrop for my community" and you get the same three steps everywhere: snapshot the holders, load a multisender, pay every fee yourself. This guide covers the other shape, for token teams. Cherry (cherry.fun) is a wallet-to-wallet messenger and community app for crypto where you sign in with a wallet, DM any address, and join or create token-gated, NFT-gated, and paid group chats. A Cherry airdrop campaign runs inside the room where your holders already talk: it pays SOL or an SPL token to wallets that pass a check at the moment they claim, one claim per wallet, and the claimant signs the payout. The concepts sit on the [airdrops page](https://cherry.fun/learn/features/airdrops-and-quests/).

## Before you start

- A Cherry group and its room id. The campaign attaches to a room, and its members see a pinned card at the top of the chat.
- A budget in SOL or one SPL mint, and a fresh keypair for the treasury, funded with the budget and nothing else. You give Cherry that keypair's secret key so the campaign can pay claimants, and Cherry keeps it encrypted.
- Campaign access from the Cherry team, who enable campaign creation for your wallet.
- Your rule set on paper: which checks define a holder, and whether every check must pass.

You know it worked when you have the room id to hand and the treasury shows the full budget on an explorer.

## Step 1: Choose first-N or a time window

Every campaign carries a cap and a clock, and the one that runs out first closes it. The campaign form's fields are "Max Claimants", "Start Time", and "End Time". A first-N drop sets a small cap and a wide window: 500 claims, open for a week, gone when the 500th wallet signs. A time-window drop sets a cap above your audience and a short window, so everyone eligible gets paid. Spending the budget also ends it.

You know it worked when the campaign card in your room shows the claimed count against the cap, as in "42/100 claimed", and a countdown.

## Step 2: Fund the treasury and set the amounts

Set "Asset Type" to SOL or SPL. An SPL campaign also takes a "Token Mint Address" and a "Token Ticker (e.g. USDC)". Then set "Amount per Claim" and "Total Budget": amount per claim times max claimants must stay at or below the budget, or the last wallets to claim hit a budget error.

Leave "Enable auto-withdraw" on. It hands the claimant a transaction to sign the second the claim lands, if their wallet holds the minimum SOL balance the campaign sets. Below that minimum the claim is recorded and the member gets a Withdraw button for after they top up. For an SPL payout, a claimant whose wallet has never held that mint also pays for the token account.

You know it worked when the campaign detail shows total and remaining budget as the same figure before the first claim.

## Step 3: Set the eligibility rules

Cherry checks the rules when a wallet presses Claim, never against a stored list. There are eight built-in checks, plus a custom one that asks your own server.

| Rule | What you set | Notes |
|---|---|---|
| Token balance | Mint, minimum balance | SPL tokens held in the wallet's standard token account for that mint |
| NFT holder | Collection, minimum count | Metaplex collections |
| Whitelist | Whitelist id | See step 4 |
| Domain | TLD and minimum count: `.sol` (also `.sns`), `.skr`, `.bonk`, any AllDomains TLD | Checks a name, not a balance |
| Messages sent | Room, minimum count (default 1), since date | Activity in Cherry |
| Room member | Room id | Active membership in that room |
| Wallet age | Minimum days | Age of the wallet on Solana |
| dApp Store review | App id, rating range 1 to 5 | Solana dApp Store apps |
| Custom | A check on your own server | Your server answers pass or fail for each wallet |

The "Policy" control decides how several rules combine: "All checks must pass" or "Any check can pass". A custom check that errors or answers slowly counts as a failure.

You know it worked when a test wallet sees the "Requirements" list with a tick or a cross per rule. Under the any policy the app prints "Only one requirement needs to be met" above the list.

## Step 4: Upload the whitelist

A whitelist is a separate list with its own id, so build it first. Give it an id such as `og-holders`, then paste entries into the "Add Wallets" box: wallet addresses or domains, separated by newlines or commas. Domains resolve to their owner wallet as you add them and the list stores that wallet, so a name that changes hands later still pays the address that held it.

Point the campaign at that list with a whitelist rule and the id. Because the check reads the list at claim time, you can keep adding wallets while the campaign is live, which is how you answer the "you missed me" replies after a drop.

You know it worked when the whitelist page shows an entry count equal to the unique wallets you pasted.

## Step 5: Attach the campaign to your room and set it live

Put your room id in the "Room ID (optional)" field, whose placeholder reads "Leave empty for public campaign", and write the "Description (optional)" field as the promise a member reads before signing; it renders in the claim modal. A campaign with a room id checks membership first, so non-members fail even under the any policy. A new campaign is created as a draft; switching its status to live starts it at the start time.

Members then see a pinned banner and a card in the stream with the reward, the claim progress, "Total Pool", and a Claim button. Pause is the kill switch: it stops new claims at once, and ending a campaign is final.

You know it worked when a second wallet in your room claims and the modal reads "Claimed Successfully!" with a "View transaction" link to the signature.

## Airdrop SOL to everyone in your group chat

Two rules cover this, and the difference is who you pay. A room member rule pays every wallet with an active membership, including people who joined the hour you announced. A messages sent rule scoped to that room with a minimum count pays only the wallets that posted, and a since date narrows it to the current cycle. Pair either with a wallet age rule and set the cap to your member count.

## Target Seeker owners and other verified audiences

A domain rule with the `.skr` TLD reaches verified Solana Seeker owners: a `.skr` name is soulbound, so it cannot be moved between wallets. Cherry hosts the largest Seeker owners community, [Seeker Club](https://cherry.fun/learn/guides/seeker-club/), which had 8,635 members and 58,180 messages as of 10 September 2026. As of September 2026, Cherry also runs targeted campaigns across its own communities, including verified Seeker audiences.

[Seeker Club on Cherry](https://chat.cherry.fun/@seekerclub)

## Keep farmers out

Each wallet gets one claim per campaign: a second attempt from the same account shows the first claim again, and the cap cannot be oversold however many wallets press Claim at once. The rest is your rule set: a minimum wallet age removes wallets created for the drop, a `.skr` rule reaches soulbound names, and a whitelist limits the audience.

The rules that bite are the ones nobody can buy in bulk: ten funded old wallets that each pass your rules claim ten times.

## Troubleshooting

- A member sees "Not Eligible". The Requirements list puts a cross next to the rule that failed. After they fix it, "Re-check eligibility" on the Requirements box runs the checks again.
- The button reads "Sold Out" or "Campaign Ended". The cap or the end time was reached, and both are terminal.
- A member claimed but holds nothing. The claim is recorded and unpaid, usually because the wallet was short of SOL for the network fee. They top up and press Withdraw.
- A wallet rejected the signature or closed the app mid-claim. The win was recorded before the wallet opened, so the slot is held for the campaign's "Claim Expiry Timeout", 5 minutes unless you change it, and a Withdraw inside that window builds a fresh transaction. After it expires the slot and the budget go back to the campaign.
- Every holder fails at once. Look at your custom check first: one that errors or answers late counts as a failure, and under the all policy it denies everyone.

## Related guides

- [Create a token-gated group chat](https://cherry.fun/learn/guides/create-a-token-gated-group-chat/): a room whose members already passed a holder check.
- [Reach token holders](https://cherry.fun/learn/guides/reach-token-holders/): holder rooms, wallet DMs, and announcements.
- [Token-gated chat](https://cherry.fun/learn/features/token-gated-chat/) and [NFT-gated chat](https://cherry.fun/learn/features/nft-gated-chat/): the rules Cherry checks on-chain.

When the rules are settled, ask the Cherry team to enable campaign creation for your wallet at [t.me/cherrydotfun](https://t.me/cherrydotfun).

## FAQ

### How do I run a whitelist airdrop?

Create a whitelist with its own id, paste wallet addresses or domains into it, then point the campaign at that id with a whitelist rule. The list is read at claim time, so late entries still pay out.

### Can I airdrop SOL to everyone in my group chat?

Yes. Set the payout to SOL and use a room member rule for every active member, or a messages sent rule with a room and a minimum count to pay only the wallets that talked.

### How do I airdrop to community members without taking a snapshot?

Eligibility runs at claim time, so there is no list to export. A holder who sold between your announcement and the claim fails the balance check, and a wallet that never opened your room never claims.

### What stops one person claiming with ten wallets?

A minimum wallet age, the soulbound .skr rule for Seeker owners, and a whitelist you control. One claim per wallet still means per wallet, so ten funded old wallets that each pass your rules claim ten times.

## Sources

- [Seeker Club on Cherry](https://chat.cherry.fun/@seekerclub)