Bot type
Every quest bot is attacked. This one is designed for it.
A Telegram airdrop and quest bot runs task campaigns, verifies completion, and computes allocations resistant to sybil farming. Sybil resistance is the entire engineering problem. A quest bot without it distributes your token to farm operators rather than to your community.
Airdrop and quest bots: price, timeline and limits
- Fixed price
- $7,100 USD
- Delivery
- 28 calendar days from kickoff
- Account age
- Not exposed by Telegram — only an increasing numeric user id
- Sybil detection
- A bot cannot tell that two accounts are one person
- Deep-link payload
- 64 characters, which constrains referral encoding
- Membership checks
- A user may join and leave immediately after verification
As of 2025-10-01, Telegram Bot API 13.4
The problem this solves
Quest campaigns exist because a token distribution ought to reward people who did something rather than people who were early to a link. The mechanic is sound. The execution almost always fails for the same reason: within hours of launch, professional farm operators are running hundreds or thousands of accounts through the tasks, and by the time the snapshot is taken most of your allocation belongs to a dozen people.
The failure is not detected at the time because the campaign metrics look excellent. Participation is high, tasks are completing, the channel is growing. Every one of those numbers is inflated by exactly the accounts you did not intend to pay. The realisation usually arrives after distribution, when the token is immediately sold by wallets that behave suspiciously like each other.
Designing against this changes what the tasks are, not just what checks run afterwards. Tasks that a script can complete will be completed by scripts. Tasks that require a chain interaction with a real cost, an account with genuine history, or a verified identity are dramatically harder to farm — and correspondingly less popular, which is a trade the project has to make consciously. The honest position is that sybil resistance is a spectrum with a cost on both ends, and that a campaign optimised for participation numbers is a campaign optimised for farmers.
How the build runs
Tasks are chosen for how hard they are to fake
A chain interaction with real cost, a wallet with prior history, an account older than the campaign. Joining a channel and clicking a button is free to farm and will be farmed, and including it should be a decision rather than a default.
commandsEvery completion is verified server-side
Chain state is read directly, channel membership is checked through the API, and nothing is accepted because the client said so. A client-reported completion is a request, not evidence.
webhookParticipants accumulate a risk score, not a pass or fail
Account age, join timing relative to the cohort, wallet funding source, interaction patterns. Binary classification is wrong here because the middle band is the largest and it contains real people.
webhookWallets are clustered by funding and timing
Farms fund their accounts from a small number of sources in tight time windows. That pattern is visible on-chain and is the single most reliable signal available.
webhookAllocation is weighted, not flat
A high-risk participant receives a reduced allocation rather than zero. Weighting degrades gracefully when the scoring is wrong; a hard cut-off turns every false positive into a public dispute.
commandsThe distribution is analysed and published
Concentration, cluster sizes, what proportion went to accounts scoring high risk. Publishing it is uncomfortable and it is the only way the community can judge whether the campaign did what it claimed.
webhook
What Telegram will and will not let you do
Telegram exposes no account creation date, only an increasing numeric user id.
Account age is inferred from id ordering — reliable as a relative signal, approximate as a date. Rules are written against recency bands rather than an exact age Telegram does not provide.
A bot cannot detect that two Telegram accounts belong to the same person.
Sybil detection is behavioural and on-chain, not identity-based. Wallet clustering does the heavy lifting because it is the only place a farm leaves a durable trace.
Channel membership can be checked, but a user may join and leave immediately after verification.
Verification is re-run at snapshot time, not only at completion. Otherwise the task rewards a join that lasted four seconds.
A `start` deep-link payload is limited to 64 characters, which constrains referral encoding.
Referral chains resolve server-side against short codes. That also makes a referral revocable, which matters when a tree turns out to be one operator.
On-chain verification costs an RPC call per participant per task.
A campaign with fifty thousand participants and six tasks is three hundred thousand calls. Verification is batched and cached against a snapshot block rather than run live per request.
When not to build this
- Your goal is participation numbers. Sybil resistance reduces headline participation by design, and if the metric you are judged on is sign-ups, this build will look like it failed.
- You cannot accept any false positives. Risk scoring is probabilistic; a campaign that must never wrongly reduce anyone's allocation cannot use it, and will instead pay farms in full.
- You have no on-chain component at all. Without wallet signals, the strongest sybil evidence is unavailable and the campaign rests on Telegram signals alone, which are weak.
- Your token has no distribution plan beyond the campaign. A quest bot allocates; it does not answer why anyone should hold what they receive.
What it runs on
| Component | Version | Why |
|---|---|---|
| grammY | 1.45 | Bot framework and the participant-facing quest flow. |
| Cloudflare Workers | current | Runtime, with batched verification jobs on cron. |
| Cloudflare D1 | current | Participants, task state, risk scores and the allocation ledger. |
| TON API | v2 | On-chain verification and wallet funding-graph queries. |
| TypeScript | 5.9 | Strict mode, with allocations as integer minor units. |
Questions people ask before committing
How much sybil farming should we actually expect?
On an unprotected campaign with a meaningful reward, a large majority of participation. Farm operators monitor for new campaigns and are running within hours. Assuming otherwise is the mistake that makes the rest of the design optional in the planner's mind.
What is the single most effective defence?
Wallet clustering by funding source and timing. Farms fund hundreds of accounts from a handful of wallets in tight windows, and that pattern is visible on-chain and expensive to disguise properly.
Why weight allocations instead of disqualifying?
Because the scoring is probabilistic and the middle band is large and full of real people. Weighting degrades gracefully when a score is wrong; a hard cut-off converts every false positive into a public argument you cannot win.
Can you tell whether two Telegram accounts are one person?
No. Telegram provides nothing that would establish it. Everything useful comes from behaviour and from on-chain funding graphs, which is why a campaign with no chain component has much weaker defences.
Should we publish the distribution analysis?
Yes, even though it is uncomfortable. Concentration figures and cluster sizes are the only way the community can judge whether the campaign rewarded them or a farm, and projects that publish build more credibility than those with better numbers and no disclosure.
Do quests that require a paid chain interaction still work?
They work far better against farms and convert worse overall, which is exactly the trade to make consciously. A small mandatory cost per account destroys farm economics while barely registering for a genuine participant.