Airdrop
The Airdrop capability provides a Merkle-proof-based token distribution system with three strategies -- time-bound, vesting, and push -- each deployed through the factory pattern with pluggable claim tracking.
Purpose: Describe the Airdrop capability -- a token distribution system supporting three strategies with gas-efficient claim tracking and compliance integration.
- Doc type: Reference
What you'll find here
- Three airdrop strategy types and when to use each
- Claim tracking mechanisms (bitmap vs amount-based)
- Owned contracts and trust boundaries
- Configuration surface and dependencies
Boundary
The Airdrop capability handles token distribution from a funded airdrop contract to eligible recipients. It does not handle token issuance (that is the SMART Protocol's responsibility) or off-chain Merkle tree generation (handled by platform tooling before deployment).
Owned contracts
| Contract | Responsibility |
|---|---|
| DALPAirdrop | Base airdrop logic: Merkle verification, claim dispatch, owner withdrawal |
| DALPTimeBoundAirdropImplementation | Time-constrained distribution with start/end enforcement |
| DALPVestingAirdropImplementation | Progressive release via linear vesting schedule |
| DALPPushAirdropImplementation | Admin-initiated batch distribution, no user claiming |
| DALPBitmapClaimTracker | Binary claimed/unclaimed tracking, gas-efficient for large lists |
| DALPAmountClaimTracker | Partial claim tracking, records amounts per user |
| Factory + Proxy contracts | CREATE2 deployment and transparent upgradeability per strategy |
Airdrop strategies
| Strategy | Use case | Claim model | Key configuration |
|---|---|---|---|
| Time-Bound | Token launches, community rewards | User-initiated via Merkle proof | Start time, end time, expiration handling |
| Vesting | Team and investor distributions | Progressive release via linear vesting | Vesting period, cliff duration, vesting strategy |
| Push | Marketing campaigns, engagement rewards | Admin-initiated, no user action required | Batch size, recipient list |
Time-Bound Airdrop
Recipients claim tokens by submitting a Merkle proof within a configured time window. After expiration, unclaimed tokens can be withdrawn by the owner. This strategy suits large-scale distributions where recipients self-serve at their convenience.
Vesting Airdrop
Tokens release progressively according to a linear vesting schedule with an optional cliff period. Recipients claim their vested portion at any time after the cliff. The DALPLinearVestingStrategy contract enforces the release curve on-chain.
Push Airdrop
An administrator pushes tokens directly to recipient addresses in batches. No Merkle proof or user action is required. This strategy suits targeted campaigns where the distributor controls timing and recipient selection.
Claim tracking
Two pluggable claim tracker strategies prevent double-claiming:
- DALPBitmapClaimTracker -- stores a single bit per recipient. Optimal for simple all-or-nothing claims across large recipient lists. Gas cost is constant regardless of list size.
- DALPAmountClaimTracker -- stores the claimed amount per recipient. Supports partial claims where users may claim a fraction of their allocation over multiple transactions.
The claim tracker is selected at airdrop deployment and cannot be changed after initialization.
Roles
Airdrop contracts use token-centric access control through ISMARTTokenAccessManager. This means role assignments are governed by the same access manager that controls the underlying token, ensuring consistent permission boundaries across the asset lifecycle.
Trust boundaries
- Merkle proof verification -- eligibility is cryptographically verified against the on-chain Merkle root. No off-chain oracle trust is required at claim time.
- Reentrancy protection -- all claim and withdrawal operations use ReentrancyGuard.
- ERC-2771 meta-transaction support -- trusted forwarder enables gasless claiming without compromising sender identity verification.
- Time enforcement -- start and end timestamps are enforced on-chain; they cannot be bypassed by transaction ordering.
Dependencies
| Dependency | Role |
|---|---|
| DALP System infrastructure | Factory deployment, access control integration |
| Token contracts (SMART Protocol) | Token being distributed; must be funded to the airdrop contract |
| Merkle tree generation (off-chain) | Produces the root and per-recipient proofs before deployment |
Configuration surface
| Parameter | Scope | Mutability |
|---|---|---|
| Merkle root | All strategies | Immutable after deployment |
| Start / end timestamps | Time-Bound | Immutable after deployment |
| Vesting period and cliff | Vesting | Immutable after deployment |
| Claim tracker strategy | All strategies | Selected at deployment, immutable |
| Trusted forwarder | All strategies | Configured at deployment |
Smart contracts are deployed and available. The UI wizard for creating and managing airdrops is in development.
Related
- Airdrop distribution flow for the step-by-step claim and distribution sequence
- Capabilities layer overview for how capabilities extend the platform
- SMART Protocol integration (ERC-3643) for the compliance framework airdrops build on
- Component catalog for the full platform inventory
Overview
Capabilities are optional operational modules deployed through the factory pattern. Each capability adds specific functionality -- token distribution, treasury management, settlement, or token sales -- without modifying core platform services.
Vault
The Vault capability provides multi-signature treasury management for DAOs and corporate treasuries, with role-based access control, configurable confirmation thresholds, and support for ETH, ERC20, and general contract call transactions.