Self-hosted Community Airdrop

Use this pattern when you have a prepared recipient list and want a controlled, self-hosted claim flow.

Typical Scenario

You are running a campaign for existing community members — Discord contributors, governance participants, or event attendees. You already have a wallet list, and you want the claim page hosted on your own domain rather than a third-party app.

Goal

Send a defined amount of tokens to a known set of wallets through a claim page your team controls end-to-end.

Why the CLI Fits

@bonkit/airdrop-studio runs locally and creates the on-chain airdrop with your wallet
The studio generates a deployable Vite + React claim site you host yourself
Both onchain and merkle claim modes are supported — pick based on recipient count
Onchain mode works well for campaigns with 500 recipients or fewer

Recommended Workflow

Prepare the recipient list as CSV (address,amount). See Wallet List Format.
Launch the studio: npx @bonkit/airdrop-studio my-campaign.
Configure layout, theme, and brand to match your community.
In Create Airdrop, choose onchain for ≤ 500 recipients or merkle for larger sets. See Create Airdrop.
Complete Draft → Recipients → Deposit → Start.
Run Generate App and deploy. See Deploy.

Example Setup

Your team wants to reward 500 community members who joined a testnet event.

Every eligible wallet gets the same amount
The recipient list is available as CSV
The claim site should live on a subdomain you control

A practical setup is:

Run the studio on devnet first to validate the end-to-end flow.
Switch the studio to mainnet-beta with your own RPC endpoint.
Create the on-chain airdrop with onchain claim mode.
If the token will trade publicly, seed the official liquidity pool before announcing the claim URL.
Generate the app, deploy to your static host, and share the URL.

Launch Safety

If recipients are likely to trade the token, publish the claim URL only after the official liquidity pool is live.
Treat liquidity timing and claim release as one launch sequence, not two independent steps.
If the token is not meant to trade yet, keep the distribution private and avoid presenting it like a live market launch.

Key Decisions

Use onchain mode when the campaign has 500 recipients or fewer. Use merkle mode for larger sets.
Use a clean CSV with verified wallet addresses.
Decide signing mode in advance: browser wallet adapter for interactive sessions, or local keypair for large batches. See Signing Modes.

Common Mistakes

Mixing community wallets from multiple campaigns into one CSV without review
Starting the campaign before recipients and funding are complete
Letting the token reach recipients before an official liquidity pool exists when immediate trading is expected
Deploying the workspace .bonkit/ directory along with dist/