Airdrop distribution flow

System context

Airdrop distribution starts after an asset exists and the issuer funds an airdrop contract. DALP stores a Merkle root for the recipient allocation, verifies a submitted proof before each distribution, records claim state, and transfers tokens from the airdrop contract to eligible addresses.

Identity, claim topics, and trusted issuers are defined in the claims and identity model. Per-asset compliance checks are defined in asset policy.

Related

• Airdrop, contracts, roles, and configuration
• Signing flow, transaction signing and custody
• Compliance transfer, transfer validation for compliance-enabled tokens
• Asset issuance, how assets are created before distribution

---

Flow overview

The airdrop distribution flow moves tokens from a funded airdrop contract to eligible recipients. Eligibility is verified with Merkle proofs against the stored root, so the contract does not trust an off-chain oracle at claim time. The flow applies to time-bound, vesting, and push strategies. Each strategy adds a different timing, release, or distribution constraint.

Claim-based happy path

1. The admin deploys the airdrop contract with a Merkle root for the recipient list and allocations. Strategy-specific parameters, such as time windows or vesting schedules, are set at deployment.
2. The admin funds the contract address with enough tokens to cover the intended allocation.
3. The recipient generates a Merkle proof off-chain and calls claim(proof, amount).
4. The contract verifies the proof against the stored root. Invalid proofs revert with no distribution.
5. The contract checks the claim tracker to confirm the recipient has not exceeded the allocation.
6. The contract transfers tokens to the recipient address through ERC20 transfer.
7. The claim tracker records the claim so the same allocation cannot be claimed twice.

Strategy variants

Each strategy modifies the base flow with additional constraints:

Time-bound airdrop

• Claim window enforced. The contract checks that block.timestamp falls between the configured start and end times. Claims outside this window revert.
• Post-expiration withdrawal. After the end time, the contract owner can withdraw unclaimed tokens. Recipients can no longer claim.

Vesting airdrop

• Cliff period. No tokens release until the cliff duration elapses from the vesting start time.
• Progressive release. After the cliff, tokens unlock linearly over the vesting period. Recipients can claim their vested portion at any time.
• Multiple claims. Recipients call claim() repeatedly as more tokens vest. The amount tracker records cumulative claims against the total allocation.

Push airdrop

• Admin initiated. The administrator calls a distribution function, supplies the recipient allocation proof, and pushes tokens directly to recipient addresses. Recipients do not call claim().
• Owner controlled claim tracking. Distribution is controlled by the admin. The Merkle root still validates recipient eligibility, but the claim lifecycle is inverted.

Claim tracking strategies

The claim tracker is selected at deployment and cannot be changed. Bitmap tracking is the default for time-bound and push strategies. Amount tracking is required for vesting airdrops.

Failure modes

Related resources

• Airdrop, contracts, roles, and configuration
• Signing flow, how transactions are signed and broadcast
• Compliance transfer, transfer validation when tokens carry compliance rules
• Asset issuance, how assets are created before airdrops
• Capabilities overview, how capabilities extend the platform