Bonkit Architecture

Bonkit is a non-custodial distribution platform for Solana tokens.

This page explains the operating model behind token creation, campaign setup, deposits, claims, and direct distribution so users can understand what Bonkit controls, what stays in the wallet, and what is recorded onchain.

Core Principles

• Non-custodial execution
• Wallet-signed transactions
• Onchain campaign state
• Offchain dataset preparation

System Model

At the highest level, Bonkit works like this:

What this means in practice:

• the UI helps you prepare the action
• your wallet approves and signs the transaction
• Solana executes the state change
• the resulting campaign state is recorded onchain

Campaign Model

An airdrop campaign is a structured distribution object with a token, a vault, a recipient model, and a claim or distribution path.

You can think of a campaign as the coordination layer between token funding, recipient eligibility, and launch state.

Typical campaign state includes:

• which token is being distributed
• which vault holds the campaign funds
• how recipients are represented
• whether the campaign is draft, funded, active, or completed

Recipient Models

Bonkit supports two main recipient models.

Onchain List

With Onchain List, recipient entries are stored directly onchain.

• source of truth is stored directly onchain
• easier to inspect conceptually
• recommended for campaigns with 500 recipients or fewer

Claim-based (Merkle)

With Claim-based (Merkle), the full recipient dataset is prepared offchain and a Merkle root is stored onchain.

• compact commitment is stored onchain
• proofs are checked when claims happen
• recommended for campaigns with more than 500 recipients

Token Flow

The token movement model is separate from the recipient representation model.

The important distinction is:

• tokens begin in the creator-controlled wallet
• funding moves into the campaign vault through an approved transaction
• recipients receive tokens only through the campaign’s distribution logic

Offchain and Onchain Responsibilities

Bonkit intentionally splits work between offchain preparation and onchain execution.

This split is what allows Bonkit to stay non-custodial while still supporting larger distribution workflows.

End-to-End Mental Model

For a typical campaign, the flow looks like this:

1. Prepare the recipient dataset.
2. Choose Onchain List or Claim-based (Merkle).
3. Create the campaign draft.
4. Register recipients or Merkle roots.
5. Deposit tokens into the campaign vault.
6. Launch the campaign.
7. Let recipients claim or receive distribution.
8. Monitor campaign state and activity.

What Bonkit Does

• prepares transactions for user approval
• generates and manages Merkle datasets for claim-based campaigns
• manages campaign state in the UI
• shows funding, launch, claims, and activity status

What Bonkit Does Not Do

• custody your tokens by default outside the campaign actions you approve
• sign transactions for you
• control your wallet
• replace the need for wallet approval

Why This Matters

If a user understands this architecture, the product becomes easier to reason about:

• wallet approval means real onchain execution is about to happen
• campaign state is not just UI state
• recipient data may be stored directly onchain or represented by a root
• Bonkit coordinates the workflow, but the wallet remains the execution authority

Read Next

• What Is an Airdrop
• Transactions on Solana
• Create Airdrop