Skip to Content
Use CasesReward Early Users

Reward Early Users

Use this pattern when you want to reward wallets based on prior activity, loyalty, or product usage and the eligible set is large.

Typical Scenario

You have internal product or community data that tells you which wallets qualify. The list may come from app usage, staking activity, waitlist participation, or event attendance — typically thousands of wallets.

Goal

Turn your own eligibility data into a claim campaign that recipients trigger themselves, without asking them to trust a spreadsheet alone.

Why the CLI Fits

  • merkle claim mode stores only a Merkle root on-chain and verifies proofs at claim time — well suited to larger recipient sets
  • The studio handles dataset generation and root registration
  • The generated claim site verifies proofs client-side and submits the claim transaction
  1. Build the eligible wallet list with allocations from your own source data.
  2. Launch the studio and configure layout, theme, and brand.
  3. In Create Airdrop, set the Draft step to merkle claim mode. See Create Airdrop.
  4. Upload the CSV in the Recipients step — the studio generates the Merkle dataset and registers the root.
  5. Fund the campaign vault in the Deposit step.
  6. Activate the campaign in the Start step.
  7. Run Generate App and deploy the claim site. See Deploy.

Example Setup

You want to reward wallets that used your beta product in the first month.

  • Power users receive a larger amount
  • Light users receive a smaller amount
  • Users should claim from a public link after the announcement

In this case, your workflow is:

  1. Export the eligible wallets from your product data.
  2. Generate the final allocation table as CSV.
  3. Run the studio in merkle mode and let it build the dataset.
  4. Fund the campaign vault.
  5. If the token will trade publicly, seed the official liquidity pool before sharing the claim URL.
  6. Deploy the generated app and share the claim URL.

Embedding Instead of Hosting

If you prefer to embed the claim flow inside your existing dashboard rather than hosting a separate site, use the Airdrop SDK directly:

  • Read campaign and recipient state from the SDK client
  • Build the claim transaction with the Merkle proof helpers
  • Have your existing wallet adapter sign and submit

Launch Safety

  • If claimants may trade immediately after claiming, make the official liquidity pool live before the public claim link goes out.
  • When there is no reason to make the token tradable yet, keep the campaign focused on claims and delay market exposure.
  • Test the claim flow with a known eligible wallet before publishing the URL.

Key Decisions

  • Use merkle mode when the campaign has more than 500 recipients and you want compact on-chain storage.
  • Review allocation logic before generating the dataset — the Merkle root is fixed once registered.
  • Pick browser wallet signing for one-off campaign setup, or local keypair signing when running larger batches. See Signing Modes.

Common Mistakes

  • Changing reward rules after the eligibility list is already generated
  • Publishing the claim link before the campaign is funded and active
  • Sharing the claim link before the official liquidity pool exists when users are expected to trade right away
  • Forgetting to test the claim flow with a real eligible wallet
Last updated on
Self-hosted Community AirdropProgrammatic Token Launch