Plan the distribution step by step
0 / 7 done-
Write the three buckets down before announcing anything
Split the supply into what sits in the pool, what the app hands out, and what you keep. Put the numbers in writing now, while nothing is at stake. Every credible launch can answer "how much did you keep?" instantly; every failed one answers it afterwards, differently each time.
The owner bucket is the only one that can be dumped on the market. Vesting it, capping it or setting it to zero are all defensible — leaving it undefined is not.
-
Seed and lock the pool first, not last
Distribution without a pool hands out something nobody can sell. Seed the liquidity and lock the LP before the campaign opens, so the first person who earns a reward can actually do something with it and can verify that the reserve behind it cannot be pulled.
Where: Tokens → your token → Give it a price -
Choose the action that earns a reward
Pay for something you can verify, not for pressing Start. Joining a channel the bot checks by membership, completing a task, or inviting a user who themselves completed a first meaningful action. Verification is the whole difference between a distribution and a faucet for bots.
Where: Panel → Tasks🔒 To use this bot you must first join our channel(s). Join and then tap ✅ Verify. -
Set the reward and the campaign cap
Decide the amount per action and the ceiling for the whole campaign. A distribution with no cap is a liability with no cap: every token handed out is future selling pressure that your pool has to absorb when the holder decides to leave.
Where: Panel → Rewards100 TOKEN2,000,000 TOKEN -
Decide when the tokens unlock, per user
A single global unlock date is a cliff: everyone can sell the same morning. A clock that starts at each user's own claim spreads that pressure over weeks and rewards the people who arrived early without punishing the ones who arrived late.
State the rule before the campaign and do not reinterpret it afterwards. A distribution rule changed after people earned against it is when a community stops believing the rest of your numbers.
-
Publish what makes the campaign auditable
Post the contract address, the three buckets, the pool address with proof the LP is locked, the qualifying action, the reward, the cap and what happens to undistributed tokens. Publishing it before anyone asks is what separates a launch from a pitch.
Where: Panel → Broadcast -
Watch concentration before you pay out
Review the campaign for accounts that share a device or an IP, referral trees that branch too cleanly, and users who completed every task in seconds. Catching a farm before payouts is cheap; catching it after means the tokens are already on the market.
Where: Panel → Users
The campaign can be checked by anyone
Buckets published, pool locked, rewards tied to verified actions and a cap that bounds the liability. That is a distribution people can audit instead of trust.
Build an airdrop bot free ↗Decide the buckets before you announce anything
A distribution plan is three numbers and their rules: what sits in the pool, what the app hands out, and what the owner keeps. Publish them before the campaign starts. Every credible launch can answer "how much did you keep?" instantly, and every failed one answers it after the fact, differently each time.
The pool bucket is locked by the LP. The app bucket is restricted by purpose — it leaves through rewards and purchases, never to a market. The owner bucket is the one that needs an explicit rule, because it is the only one that can be dumped. Vesting it, capping it, or setting it to zero are all defensible; leaving it undefined is not.
| Bucket | How it is constrained | How anyone verifies it |
|---|---|---|
| Seed pool | LP locked at the null address | On an explorer |
| App inventory | Leaves only through rewards and purchases | The public balance of the wallet |
| Owner share | Vesting, a cap, or zero | Supply on-chain |
Every reward should come from a verified action
The fastest way to burn a distribution is to pay for pressing Start. Tie rewards to something that is checked: joining a channel the bot verifies by membership, completing a task, or inviting a user who themselves completed a first meaningful action. Verification is what separates a distribution from a faucet for bots.
Attribution has to be recorded once and never silently overwritten. A later link should not replace the original sponsor, a user should not be able to refer themselves, and a pending reward should say it is pending rather than looking like a payment that failed.
- Define the qualifying action
The first event that represents real value — not the click that precedes it.
- Verify it server-side
Channel membership rechecked on use, not only at start.
- Credit once, idempotently
A retried callback must not pay twice.
- Show the state honestly
Pending, qualified and rejected are three different messages.
- Cap the campaign
A distribution with no ceiling is a liability with no ceiling.
The economics nobody writes on the announcement
Every token handed out for free is future selling pressure that the pool pays for. That is not an argument against airdrops — distribution is how a token finds holders — but it is the reason the reserve and the pool depth have to be sized together. A generous campaign against a thin pool produces a chart that only goes one way.
Selling at a discount in exchange for a lock is the mechanism that changes this, because the buyer's GRAM enters the pool at the moment of purchase and the tokens cannot be resold until the lock expires. The discount is the incentive, the lock is what makes it safe to offer, and neither requires promising a return.
Sustainable distribution ≈ tokens that arrive with funding ≥ tokens given away against the same poolVesting is per user, not a single date
A global unlock date is a cliff: everyone who received tokens can sell on the same morning. A clock that starts at each user's own claim spreads that pressure across weeks and rewards people who arrived early without punishing the ones who arrived late.
Whatever you choose, state it before the campaign and do not reinterpret it afterwards. A distribution rule changed after people earned against it is the moment a community stops believing the rest of the numbers.
What to publish so the campaign can be audited
- The contract address, from the first announcement.
- The three buckets with their amounts and their constraints.
- The pool address and the proof that the LP is locked.
- The qualifying action and the reward per action.
- The campaign cap and what happens to undistributed tokens.
- Whether the mint key is renounced, and if not, who holds it.
Common questions
Do I need my own token to run an airdrop?
No. Many campaigns distribute an existing asset or points. But if the campaign promises a token, minting it first and publishing the contract is what makes the promise checkable.
How do I stop bots from farming the airdrop?
Require verified actions rather than clicks, recheck channel membership on use, record attribution once, and review concentration by device and IP before paying out.
Should the reward be claimable immediately?
Immediate rewards feel better and sell faster. A per-user lock with a discount is the usual compromise: the holder gets more value, the pool gets time.
What happens to tokens nobody claims?
Decide before launching. Burning the remainder is the cleanest answer because it cannot reappear on the market later.
Can I change the reward amount mid-campaign?
You can, but treat it as a public change with a reason. Silently lowering rewards after people earned against the old rule costs more trust than it saves in tokens.
Sources and further reading
Technical and product claims were checked against these primary sources.