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.

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.

Image
Early user reward scenario

Claim-based recipient setup showing the eligibility dataset being prepared for a `Claim-based (Merkle)` campaign.

Goal

Turn your own eligibility data into a campaign that rewards early supporters without asking them to trust a spreadsheet alone.

Why This Fits Bonkit

  • Bonkit lets you bring your own wallet list and token
  • Claim-based (Merkle) is the recommended path when the eligible dataset has more than 500 recipients and you want proof-based verification
  • Launch and Monitoring gives you a way to track whether eligible users are actually claiming
  1. Build the eligible wallet list from your own source data.
  2. Decide whether the list should be a fixed onchain list or a public claim flow.
  3. Open Create Airdrop.
  4. Choose Claim-based (Merkle) if the campaign has more than 500 recipients. Use Onchain List only if the campaign has 500 recipients or fewer.
  5. Complete the setup in Recipients and Deposit.
  6. Launch and track results in Launch and Monitoring.

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.
  3. Create a claim-based airdrop draft.
  4. Upload the CSV, validate the Merkle files, and register the root.
  5. Fund the campaign vault.
  6. If the token will trade publicly, seed the official liquidity pool before sharing the claim URL.
  7. Launch the campaign and share the claim URL with the community.
Image
Early user reward flow

Live campaign state or claims monitoring view after the claim URL is ready to share.

Launch Safety

  • If claimants may trade immediately after claiming, make the official liquidity pool live before the public claim link is distributed.
  • This can reduce the chance that the first visible market is created by a third party at an unrealistic price or with liquidity designed to absorb claimants’ tokens cheaply.
  • When there is no reason to make the token tradable yet, keep the campaign focused on claims and delay market exposure until the launch plan is ready.

Key Decisions

  • Use Claim-based (Merkle) when the campaign has more than 500 recipients and you want to keep onchain storage compact.
  • Use Onchain List when the campaign has 500 recipients or fewer and you prefer explicit onchain recipient storage.
  • Review allocation logic before upload so the campaign matches the rules you announced.
  • If the token will have a public market, include liquidity timing in the campaign launch checklist.

Common Mistakes

  • Changing reward rules after the eligibility list is already generated
  • Publishing the claim link before the campaign is fully 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