Skip to Content
Use CasesProgrammatic Token Launch

Programmatic Token Launch Distribution

Use this pattern when you are launching a new token on a short timeline and need to split distribution across direct contributor transfers and a broader public claim phase.

Typical Scenario

You are launching a token and need to coordinate three audiences:

  • A small contributor or partner set that should receive tokens immediately
  • An allowlist that can be processed as a batch
  • A broader public audience that should claim after launch

Goal

Move the token into the right wallets quickly without losing control over launch sequencing, public access, and market setup.

Why the CLI and SDK Fit

  • The Airdrop Studio CLI runs the public claim campaign — merkle mode for the broad audience, a generated claim site for the public-facing flow
  • The Airdrop SDK drives contributor and allowlist transfers from your own backend or CI job, signed by a dedicated keypair
  • You control liquidity timing separately from any Bonkit tool
  1. Decide the three audience splits and how each will be delivered.
  2. If the token will trade publicly, seed the official liquidity pool at the intended starting price before broad distribution.
  3. For the public claim campaign:
    • Run @bonkit/airdrop-studio and create a merkle campaign for the public audience.
    • Run Generate App and deploy the claim site.
  4. For contributor and allowlist transfers:
    • Use the SDK from a backend or script with a funded dedicated keypair.
    • Build and submit transfers programmatically. See Airdrop SDK Examples.
  5. Coordinate the announcement so the claim URL goes live after liquidity is seeded.

Example Setup

You are launching a token with three distribution groups:

  • 50 creators and contributors who should receive tokens immediately
  • 300 allowlist wallets that can be sent in a batch
  • A broader claim audience that should claim after launch

A practical setup is:

  1. Seed the official liquidity pool at the intended starting price.
  2. Use the SDK to run the 50 contributor transfers from a dedicated keypair.
  3. Use the SDK to process the 300-wallet allowlist batch.
  4. Use the CLI to run the public claim campaign in merkle mode and deploy the claim site.
  5. Announce the campaign and share the claim URL.

Launch Safety

  • Make the official liquidity pool live before public claim links go out.
  • Keep contributor, allowlist, and public claim datasets separate so launch logic does not mix.
  • Treat liquidity, direct sends, and public claims as one launch sequence, not three independent actions.
  • Confirm token metadata before any wallet first sees the mint.

Key Decisions

  • Use the SDK when speed and automation matter most and you already know the recipient wallets.
  • Use the CLI when you want a managed public claim flow with a deployable site.
  • Decide signing strategy in advance: dedicated keypair on the backend for SDK-driven transfers, browser wallet or local keypair for CLI campaign setup. See Signing Modes.

Common Mistakes

  • Treating every distribution group as one giant batch without reviewing the audience
  • Using a direct send when you actually need a public claim campaign
  • Letting tokens circulate publicly before the official liquidity pool is established
  • Forgetting to confirm the token metadata before the launch is visible
Last updated on
Reward Early UsersFAQ