DALP airdrop token distribution capability

The Airdrop capability distributes funded tokens to eligible wallets through time-bound, vesting, or push strategies. Each strategy uses a Merkle root for eligibility and records claims on-chain so recipients cannot claim more than their allocation.

DALP airdrops move tokens from a funded distribution contract to eligible wallets. The capability supports three strategies: recipient claims within a time window, recipient claims against a vesting schedule, and administrator-pushed batch distributions.

Airdrops do not mint tokens, build the off-chain Merkle tree, or replace the identity and compliance rules on the underlying token.

Identity, claim topics, and trusted issuers are defined in the claims and identity model. Per-token transfer policy is defined in asset policy.

When to use an airdrop

Use an airdrop when the issuer already has a funded token balance and needs controlled distribution to a known recipient set. The Merkle root commits the recipient list and allocations at deployment. At claim or distribution time, the contract verifies the submitted proof against that root and records the claim before another transfer can reuse the same allocation.

Use the asset lifecycle to create or mint the token first. Then fund the airdrop contract with the amount available for distribution.

Strategy map

Strategy	Distribution model	Primary control	Typical use
Time-bound	Recipients claim their allocation with a Merkle proof	Start and end timestamps enforced on-chain	Token launches or campaign windows where recipients self-serve
Vesting	Recipients initialise vesting with a Merkle proof, then claim vested amounts	Initialisation deadline and vesting strategy	Team, investor, or staged distributions
Push	An administrator distributes batches to recipients with Merkle proofs	Batch distribution call and proof validation	Targeted distributions where the issuer controls timing

Contracts and responsibilities

Contract	Responsibility
`DALPAirdrop`	Shared Merkle verification, claim dispatch, claim tracking, and owner withdrawal logic
`DALPTimeBoundAirdropImplementation`	Adds start and end time checks for claim-based airdrops
`DALPVestingAirdropImplementation`	Adds vesting initialisation, vesting strategy lookup, and vested-amount claims
`DALPPushAirdropImplementation`	Adds administrator-driven single and batch distribution
Claim tracker contracts	Track claimed state so an allocation cannot be reused
Factory and proxy contracts	Deploy each strategy through the configured factory pattern

Claim and transfer flow

The base claim path has four checks before tokens leave the distribution contract. For the sequence view, see the airdrop distribution flow.

The submitted recipient, index, amount, and proof match the Merkle root stored on the airdrop contract.
The selected strategy accepts the current timing or vesting state.
The claim tracker confirms the allocation has not already been consumed beyond its allowed amount.
The contract transfers tokens from the funded airdrop contract to the recipient and records the claim state.

Strategy details

Time-bound airdrop

A time-bound airdrop accepts claims only between startTime and endTime. Claims before the start revert with AirdropNotStarted; claims after the end revert with AirdropEnded. The contract also exposes isActive() and getTimeRemaining() so callers can check the claim window before submitting a transaction.

Vesting airdrop

A vesting airdrop separates eligibility from release. The recipient first initialises vesting for an allocation before the initializationDeadline. After initialisation, the vesting strategy determines how much of the total allocation is currently claimable. The contract rejects uninitialised claims, duplicate initialisation for the same index, zero transferable amounts, and invalid vesting strategy addresses.

Push airdrop

A push airdrop moves tokens through administrator-initiated distribution calls. The caller supplies recipient, index, amount, and Merkle proof data. Batch distribution validates array shape and proof data before distributing multiple allocations in one transaction.

Trust boundaries

Boundary	What DALP verifies	What remains outside the contract
Eligibility	The submitted proof matches the on-chain Merkle root	Building and approving the recipient list before deployment
Allocation reuse	Claim tracker state prevents repeated consumption of the same allocation	Correctly selecting the tracker model for the distribution shape
Timing	Time-bound and vesting contracts enforce their configured timestamps	Choosing business dates and communicating them to recipients
Token transfer	Tokens are transferred from the funded airdrop contract	Funding the contract with enough balance before opening distribution
Compliance	The underlying token keeps its identity and transfer policy	Off-chain KYC, issuer governance, and evidence collection

Operational notes

Fund the airdrop contract before opening claims or running push distribution. The airdrop contract can only distribute tokens it already holds.
Treat the Merkle root as a deployment-time commitment. Changing the recipient list requires a new root and, depending on the deployment pattern, a new airdrop instance.
Keep proof generation deterministic. Recipients and administrators need proof data that matches the exact root stored on-chain.
Use the strategy-specific read functions to avoid avoidable reverted transactions, such as claims outside the time window or vesting claims before initialisation.
Indexer handlers record airdrop creation events and transfer events by chain and address, including the airdrop type, token address, Merkle root, recipient, and amount.

Airdrop distribution flow explains the claim and distribution sequence.
Claims and identity explains wallet identity, claim topics, and trusted issuers.
Asset policy explains compliance checks on the underlying token.
Capabilities layer overview shows how capabilities extend the platform.
SMART Protocol integration explains the compliance-aware token layer.

Airdrop

On this page