Token Airdrop
Distribution infrastructure for large recipient sets.
Distribution infrastructure for large recipient sets — validated, batched, retryable, and recorded.
- project
- Lunor Demo
- token
- LUNR
- module
- airdrop
- category
- distribute
- status
- live · sandbox
Every figure in this module's demo is fabricated. No wallet connection, no signing, and no broadcast path exists from this site.
The problem
Bulk sends fail quietly, and the failure is expensive.
A distribution script works on the test list and then meets reality: addresses with bad checksums, the same wallet appearing twice under different casing, zero and negative amounts, contract addresses that cannot receive, a nonce race halfway through, and gas that spikes at batch forty of sixty. Some transfers land, some do not, and the script does not know which.
The real damage is the absence of a record. Nobody can say with confidence which recipients were paid, so the team either pays some twice or leaves some unpaid — and either way spends the following week reconstructing state from a block explorer.
The approach
Validate first, batch deliberately, keep the record.
Recipients are entered manually or imported by CSV and then validated before anything executes: invalid address formats, duplicates, zero amounts, and malformed rows are surfaced as a reviewable list rather than a silent skip. Totals, recipient count, batch count, and estimated gas are shown before execution.
Execution runs in batches with visible progress, per-batch status, and a retry path for failures that does not re-send successful transfers. Every campaign keeps a per-recipient record that reconciles against what actually happened.
Capabilities
What the module does.
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.
How it works
The workflow, step by step.
- 01Select chain and token
The distribution target is the project's token on a chosen network.
- 02Add recipients
Import a CSV or enter addresses and amounts manually.
- 03Review validation
Duplicates, invalid checksums, zero amounts, and bad rows listed for correction.
- 04Confirm totals
Recipient count, total tokens, batch count, and estimated gas before committing.
- 05Execute in batches
Watch each batch process and confirm, with failures isolated rather than fatal.
- 06Reconcile and export
Per-recipient status exported for accounting and holder support.
Specification
At a glance.
- CSV format
- address,amount — per-row validation with error reporting
- Validation checks
- Format, checksum, duplicates, zero and invalid amounts
- Execution
- Sized batches with per-batch status
- Failure handling
- Isolated per batch, retryable, idempotent
- Record
- Per-recipient status, exportable
- Public environment
- Simulation — batches process fabricated data
Security
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
Full posture, including what we deliberately do not claim, is on the security page.
Use cases
Where it gets used.
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.
Solution paths
Where this module sits in a bigger job.
FAQ
Questions asked before adopting this module.
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.
Other modules
Same Console, same project record.
Next step
Run it before you ask us anything.
The Console needs no signup and no wallet. Open the module, use it against sandbox data, then bring us the specific questions.