Token Airdrop
Distribution infrastructure for large recipient sets.
What it is
CSV ingest, validation, batch execution, retries, and a full campaign record. Built for operations, not one-off scripts.
Distribution infrastructure for large recipient sets — validated, batched, retryable, and recorded.
The public Console runs this module on fabricated data. Nothing there is signed or broadcast.
Who it is for
Community distribution
Large one-time distributions where list hygiene and reconciliation matter more than speed.
Contributor waves
Recurring smaller distributions to contributors, each with its own campaign record.
Migration snapshots
Distributing on a destination chain against a snapshot taken from the source.
Reward payouts
Programmatic reward distribution with a per-recipient audit trail.
How it works
- 01Select chain and tokenThe distribution target is the project's token on a chosen network.
- 02Add recipientsImport a CSV or enter addresses and amounts manually.
- 03Review validationDuplicates, invalid checksums, zero amounts, and bad rows listed for correction.
- 04Confirm totalsRecipient count, total tokens, batch count, and estimated gas before committing.
- 05Execute in batchesWatch each batch process and confirm, with failures isolated rather than fatal.
- 06Reconcile and exportPer-recipient status exported for accounting and holder support.
What it includes
CSV ingest
Address and amount parsing with per-row error reporting rather than a whole-file rejection.
Manual entry
Paste or type recipients for smaller distributions, through the same validation.
Validation gate
Invalid formats, duplicates, zero amounts, and malformed rows flagged before execution.
Pre-flight totals
Recipient count, total amount, batch count, and estimated gas confirmed up front.
Batched execution
Distribution runs in sized batches with live per-batch status.
Idempotent retry
Failed batches retry without re-sending transfers that already succeeded.
Campaign record
Per-recipient status persisted for reconciliation and export.
Project dashboard
Campaigns, tokens distributed, recipients, success rate, and distribution cost.
Boundaries
The public tool never holds a key, and validation runs before execution rather than after.
- No private key, signer, or wallet connection in the public interface
- Execution in the sandbox is simulated, including deliberate failure and retry paths
- Duplicate detection prevents the most common double-payment error
- Batches are idempotent so a retry cannot re-send a successful transfer
- Campaign records are the reconciliation source, not a block explorer search
Questions
What CSV format do you accept?
Address and amount per row. The parser reports errors per row rather than rejecting the whole file, so a list with twelve bad entries out of nine thousand is fixable in place instead of being re-exported.
What happens when a batch fails?
The failure is isolated to that batch and surfaced with a retry option. Because batches are idempotent, retrying cannot double-send transfers that already succeeded — which is the specific failure mode that makes hand-rolled scripts dangerous.
How do you handle duplicate addresses?
They are detected during validation and shown before execution, including duplicates that differ only in casing. You decide whether to merge amounts or drop rows; the tool will not silently pick one.
Can we estimate cost before running?
Yes. Recipient count, total tokens, batch count, and estimated gas are calculated at the review step, so an expensive distribution is a decision rather than a discovery.
Is the demo actually sending anything?
No. The public campaign executes against fabricated data and deliberately includes failures so the retry path can be evaluated. Nothing is broadcast and no key is held.