Fairness & anti-bot
transparent rules, explainable signals.
The Fairness Center shows players the rules, their own checks and what the anti-bot does to allocation. Behind it: explainable abuse signals, a review queue, versioned rules, re-verification before the snapshot, appeals, and a reduced reward instead of a ban when the evidence is weak.
01What players see: the Fairness Center
The Mini App's Airdrop tab is the Fairness Center. It shows the estimated allocation (only when a snapshot exists; otherwise an honest "not calculated yet"), a fair score ring with checks grouped by category, the rules and their change log, the vesting disclosure, the planned snapshot date, a re-verify button when a window is open, the appeal flow, the wallet and, later, the claim.
Checks shown to players: account in good standing, TON wallet connected, human play pattern, one account per person, genuine invites, wallet history, re-verified before the snapshot. Players never see other players, raw evidence (IP or device hashes, wallet funders) or admin notes. "Bots excluded" is an aggregate count. A player without a wallet is never shown as eligible.



02Rules versions
Airdrop → Fairness → Rules: write the rules in Markdown with a live preview. Start from template fills a template with this campaign's real thresholds and multipliers. Publishing creates a new version; after the first version a public change note is required. Old versions stay public in the change log. When you publish a snapshot, the latest rules version is frozen into it.

03Reduced reward instead of a ban
Fairness → Allocation & window (owner only). The effective multiplier of each player's allocation weight is:
| Verdict | Multiplier |
|---|---|
| clean | 1 |
| review | Players in review receive reviewMultiplier (default 50%) |
| excluded | 0 |
| override include / exclude | 1 / 0 (overrides always win) |
| did not re-verify (only when Require re-verification is on and a window was opened) | × unverifiedMultiplier (default 0) |
So weak evidence reduces a reward instead of banning the player, and the player can see why and appeal. Also here: the vesting / lock-up disclosure shown to players (up to 1000 characters), the planned snapshot date (UTC; leave empty until announced) and Accept appeals. The multipliers are stored in each snapshot's formula.
04Re-verification before the snapshot
Open window starts a re-verification window now. Players see "Confirm you're still here" in the Fairness Center and tap Re-verify now. This stops farms of abandoned accounts. The API only accepts it with a fresh Telegram login (at most 10 minutes old; otherwise init_data_stale, so the player reopens the Mini App) and only while the window is open and no snapshot is published.
Re-verification only affects allocation when Require re-verification is on. Players who verified before the window opened must verify again.
05Appeals
Players with a reduced or excluded verdict can appeal from the Fairness Center (one open appeal at a time, only while appeals are accepted). Anti-bot → Appeals: Decide with accept or reject and a response that is shown to the player. Accepting sets an anti-bot override to include by default; you can choose include, exclude or keep the computed verdict. Decisions and overrides are written to the audit log.
06Anti-bot signals
Anti-bot → Signals & clusters → Recompute scores (manager or owner) scores every player from server-side evidence. Each signal records why it fired (numbers, time windows, related players). Weights are added and capped to a 0–100 score. Defaults: review at 40, exclude at 70 (editable).
| Signal | Fires when | Weight |
|---|---|---|
tap_cadence | At least 30 tap batches and any of: ≥ 60% of batches at ≥ 95% of the rate cap (+15); a session ≥ 15 min and ≥ 60 batches with near-constant intervals and tap counts (+20); activity across ≥ 36 h with no 4 h gap (+15) | up to 35 |
referral_burst (inviter) | ≥ 10 invitees within 10 min (+20); ≥ 10 invitees older than 24 h with under 20% activated (+10); ≥ 5 invitees and ≥ 50% share an IP or device hash (+15) | up to 40 |
referral_burst (invitee) | Joined inside such a burst window | 8 |
shared_ip | Same salted IP hash as 2+ other players; 5 + 3·log₂(size) | up to 20 |
shared_device | Same IP + user-agent hash pair as 2+ others; 10 + 4·log₂(size) | up to 25 |
new_account | Telegram id in the newest 5% of the campaign (only with ≥ 50 players); a heuristic | 5 |
no_activity_after_referral | Invited player active only in the first 2 h, then idle ≥ 24 h | 12 |
wallet_fresh (toncenter key) | Linked wallet has no transactions, or its first one was under 7 days before linking | 10 |
wallet_shared_funder (toncenter key) | Wallet first funded by the same address as 2+ other players' wallets; 8 + 3·log₂(size) | up to 20 |
premium | Telegram Premium account that already has other signals | −10 |
Source: packages/airdrop/src/signals.ts (RULES). Without TONCENTER_API_KEY the two wallet signals are skipped and the page says Wallet checks skipped.
Shared IPs are often a mobile carrier or public Wi-Fi, and exchanges fund many unrelated wallets. The report says this next to those signals.
07Review queue and overrides
Anti-bot → Review queue: players between your review and exclude thresholds, with their evidence. Include or Exclude each (keyboard: J/K to move, I include, E exclude) or in bulk. Every decision is an audited override. Overrides (include, exclude, or auto = back to the computed verdict) always win over the score and survive recomputes.