Sending SPL tokens to hundreds or thousands of wallets seems simple — but in practice, even minor mistakes can break your airdrop.
Here’s a developer-focused breakdown of the top 5 mistakes, why they happen, and how to fix them.
1. Sending Everything in One Transaction
The Problem:
Solana transactions are not infinitely large:
- Max number of instructions per transaction is limited (~5–10 SPL transfers, depending on compute units and signatures)
- Oversized transactions fail silently or throw
TransactionTooLargeerrors
Why It Matters:
If a transaction fails mid-airdrop, all wallets in that batch may miss tokens, forcing manual retries.
How to Fix:
- Split recipients into manageable batches (e.g., 20–50 wallets per batch)
- Use an automated batching system that respects compute and instruction limits
2. Ignoring SPL Token Decimals
The Problem:
Every SPL token has a decimals field (e.g., 6, 8, 9). If your script ignores this:
-
100tokens might actually send0.0001 - Or the wrong amount per recipient
Why It Matters:
Sending tokens without decimal awareness leads to incorrect distributions or lost funds.
How to Fix:
- Query the token’s decimals property programmatically
- Adjust all transfer amounts:
amount_to_send = user_amount * (10 ** token.decimals)
3. Duplicate Wallets in Recipient List
The Problem:
CSV exports often contain duplicates. If a multisender blindly sends to all:
- Wallets may receive double rewards
- Or transactions may fail if the wallet is already “in use” in a batch
Why It Matters:
- Skews your airdrop metrics
- Creates community complaints
How to Fix:
- Deduplicate addresses before sending
- Build a wallet map to track which addresses have been processed
4. Retrying Failed Transactions Without Tracking State
The Problem:
Failures happen due to:
- RPC throttling
- Temporary network congestion
- Wallet conflicts (
AccountInUse)
Many developers retry blindly, resending tokens to all wallets in the batch.
Why It Matters:
- Creates duplicated payouts
- Makes debugging difficult
How to Fix:
- Track batch-level success/failure
- Retry only failed transactions
- Optionally, implement exponential backoff to avoid RPC overload
5. Not Using Snapshots for Eligibility
The Problem:
Without a token or NFT snapshot, you risk sending tokens to:
- Non-holders
- Ineligible wallets
- Duplicate or inactive addresses
Why It Matters:
- Wastes tokens
- Damages community trust
How to Fix:
- Take a token/NFT snapshot before distribution
- Feed the eligible wallet list into your multisender workflow
- Tools like Jumpbit handle CSV uploads directly from snapshots
Extra Developer Insights
- Batch Size Trade-offs: Larger batches = faster, but higher risk of failure; smaller batches = safer, but slower
- Network Considerations: Always consider RPC node type (public vs private) and concurrency limits
- Retries and Logging: Maintain a retry log to reconcile failed wallets and prevent duplicates
- Decimals & Precision: Be careful with tokens that have high precision; incorrect rounding can compound across hundreds of wallets
How Jumpbit Multisender Helps
Jumpbit Multisender takes all these issues off your plate:
- Automatic batch splitting respecting Solana limits
- Retry logic with state tracking
- Duplicate wallet detection
- Handles eligible snapshots for precise distributions
- Supports 1,000+ wallets, no CLI or scripts required
This means you can focus on strategy and not operational headaches.
Key Takeaways
- Large-scale Solana airdrops are not trivial; even small mistakes can be costly
- Batches, decimals, duplicates, and retry tracking are essential for reliability
- Snapshots ensure eligibility and prevent wasted tokens
- Developer awareness + proper tools = safe, scalable airdrops
Top comments (0)