What Is an Airdrop

An airdrop is a way for projects to distribute tokens to many wallets, often used for community rewards, promotions, or initial token distribution.

In Bonkit

Bonkit supports two main ways to represent and verify those allocations:

• Onchain List
• Claim-based (Merkle)

Both models solve the same problem: assigning tokens to recipients. but they store and verify recipient data differently.

Onchain List

With Onchain List, recipient entries are stored directly onchain.

This makes the model easier to understand:

• the campaign stores the recipient list directly
• the list itself is the source of truth
• each claim is checked against that stored list

At a simple conceptual level:

onchain data = recipient list
claim check = "is this wallet and amount in the stored list?"

At a simple implementation level:

L = { (w1, a1), (w2, a2), ..., (wn, an) }

valid(w, a) = 1  if (w, a) ∈ L
valid(w, a) = 0  otherwise

This is usually the better choice when:

• the dataset is small enough that direct onchain storage is practical
• you want the most explicit and inspectable model
• your team prefers simpler setup over proof generation

Claim-based (Merkle)

With Claim-based (Merkle), the full recipient list is not stored directly onchain. Instead, the campaign stores a compact commitment to the dataset, and each claim is verified against that commitment.

A Merkle tree allows a large dataset to be represented by a single root hash that can be verified using proofs.

Most large airdrops today use Merkle-based distribution because it scales better for large recipient sets.

This means:

• onchain storage stays smaller
• large recipient sets are easier to support
• proof generation and dataset management move offchain

At a simple conceptual level:

onchain data = merkle root
claim check = "does this wallet and amount match the committed root?"

At a generic implementation level:

leaf_i = H(w_i || a_i)
root = MerkleRoot(leaf_1, leaf_2, ..., leaf_n)

valid(w, a, proof) = 1
  if VerifyProof(H(w || a), proof, root) = true
valid(w, a, proof) = 0
  otherwise

In practice, protocols may include extra fields in the hashed leaf, but the general idea is the same: a claim is accepted only if the submitted proof reconstructs the stored root.

If you want a general background on how Merkle trees work, see Merkle tree .

This is usually the better choice when:

• the dataset is large enough that storing every recipient onchain becomes expensive
• you want lower onchain storage overhead
• your team is comfortable preparing and managing merkle-based claim data

Practical Difference

At a high level:

Onchain List   -> store recipient data directly
Merkle         -> store a compact commitment to recipient data

The main trade-off is:

Onchain List   -> simpler and more explicit
Merkle         -> more scalable and more compact

Both models can support claim flows. The key difference is not whether users claim from a page, but whether the campaign stores raw recipient entries onchain or stores a compact proof-based commitment.

Onchain List

• store recipients onchain
• simple model
• higher storage cost

Merkle

• store merkle root
• scalable for large lists
• requires proof generation

Which One Should You Choose?

Choose Onchain List when:

• the campaign has 500 recipients or fewer
• you want the clearest operational model
• you prefer direct onchain recipient storage

Choose Claim-based (Merkle) when:

• the campaign has more than 500 recipients
• you want to reduce rent and onchain storage burden
• you are comfortable handling proof-based distribution data offchain

Read Next

• Create Airdrop
• Recipients and Deposit
• Claim Portal