Airdrop Campaign Bot

Run your own airdrop campaign: captcha-gated onboarding, verified channel-join and social tasks that pay points, referral deep links, per-network wallet collection with validation, an eligibility checker, reminder drips, admin stats, and a one-click endgame (freeze → snapshot announcement → claims) powered by operations.

A crypto/web3 project wants to run its OWN airdrop, points/quest campaign, whitelist or eligibility checker inside Telegram — building an audience it keeps afterwards, instead of renting a third-party airdrop platform.

• Which network will the airdrop be paid on — TON, an EVM chain, or Solana? (drives walletNetwork validation and prompts)
• Which Telegram channel must participants join, and is the bot an admin there?
• How many points per task and per credited referral?
• Will there be an eligibility snapshot to check against (allowlist or API)?
• Who ends the campaign and when — a fixed date or a manual decision?
• Set the botUsername variable (bot username WITHOUT @) — personal invite links are built from it.
• If you deferred them during setup, fill channelHandle (https://t.me/... link or @handle), xProfileUrl and siteUrl in Variables.
• Make the bot an admin of your campaign channel, or the join-task verification will always fail.
• Review pointsPerTask (default 100) and pointsPerReferral (default 50).
• On the Contacts page, open your own contact and set isAdmin = yes to unlock /stats.
• Deploy the bot and run through /start yourself: captcha → tasks → wallet.
• Be honest about token terms in your channel and messages — this template is for projects running their OWN campaign, with no fake-claim mechanics.
• Endgame: run the 🏁 End campaign operation (freezes points + snapshot announcement with a last-chance wallet CTA) → give stragglers a few days → set claimUrl → export the payout list (Contacts → walletAddress is not empty → Export) → distribute off-platform → run 📤 Open claims.
• After the campaign, keep the bot as your announcement channel — the audience you built stays with you.

• Pass the emoji captcha at /start, get enrolled in the reminder drip and see the menu
• Complete the join-channel task — membership is verified with the telegram check-member action — and earn points
• Complete the X-follow and website tasks (honor-confirm) and fire tasks_completed once all three are done
• Invite friends with the personal ref deep link; the inviter is credited pointsPerReferral after the friend completes a first task
• Submit a payout wallet — validated per network (TON/EVM/SOL) — and fire wallet_submitted, which stops the reminder drip
• When it is time, the owner runs the 🏁 End campaign operation: points freeze and the snapshot announcement goes out with a last-chance wallet CTA
• After distributing off-platform, the owner runs 📤 Open claims to notify every wallet holder with the claim link

Полезно знать

• The bot must be an ADMIN of the campaign channel — the join task uses Telegram getChatMember via the telegram check-member module action, which cannot verify membership otherwise.
• Referral crediting: both operands of a broadcast filter resolve in the candidate contact's own context, so the after-task flow publishes the inviter's id into the app-scoped pendingReferrerId first, and the "Credit the inviter" audience flow filters {{sysvar|platformId}} == {{var|var_pending_referrer_id}}. Do not "simplify" this into a direct referredBy comparison — it can never match.
• Referrals are credited only after the invitee passes the captcha AND completes a first task — this kills self-referral and bot farming. Crediting at /start would be trivially farmable.
• The X-follow and website tasks are honor-confirm: X has no public API to verify a follow, and that is the industry standard for airdrop task bots. The channel-join task is the one that is actually verified.
• Wallet addresses are validated per network with the walletNetwork variable (TON default, EVM, SOL). The bot never touches the chain — distribution happens off-platform from the exported contact list.
• The endgame is two one-time operations: 🏁 End campaign (guard → freeze campaignStatus → launch the snapshot announcement) and 📤 Open claims (guard → launch the claims broadcast to walletAddress-holders). Operations run without a contact, so their graphs only touch application-scoped variables — never add contact-variable writes there.
• The two endgame announcements are plain audience flows (Campaign endgame folder) launched BY the operations — each run clones the flow into a fresh broadcast, so there is nothing to schedule or send by hand.
• The eligibility checker compares the submitted wallet against the comma-separated eligibleWallets application variable. For a real snapshot, paste the list there, or replace the condition with an HTTP request / custom-code call against your snapshot API.
• Every point-paying flow checks campaignStatus == "active" at the top, so post-deadline task completions and referrals cannot mint points after the snapshot. Wallet submission intentionally stays open (grace period).
• Points and counters use atomic increase-mode SET_VARIABLE writes, so concurrent completions cannot lose increments.
• Campaign counters (totalParticipants, totalWallets) are application-scoped and shown by /stats, which is gated on the isAdmin contact variable — mark yourself on the Contacts page.
• To also track clicks on the website-task URL button, enable Track clicks in the button settings after install (Button settings popover) — click tracking is not pre-wired by the template.

Что важно помнить

• Do not credit referrals at /start — crediting must stay behind captcha + first real task, or the campaign is trivially farmable.
• Do not compare {{sysvar|platformId}} to {{var|var_referred_by}} in a broadcast filter — both operands resolve in the candidate contact's context, so it can never match. Keep the pendingReferrerId hand-off.
• Do not write contact-scoped variables inside the operation graphs — operations run without a contact and the write fails the run.
• Do not build fake-claim mechanics or auto-DM claim links to strangers — this template is for projects running their own campaign; state token terms honestly.
• Do not replace the CAPTCHA action with SET_VARIABLE/condition chains — the built-in action handles the whole challenge-verify-retry loop.
• Do not create Broadcasting drafts for the endgame — the 🏁 / 📤 operations launch the endgame audience flows directly, with the claims flow filtered to walletAddress-holders.