The three attacks a referral program invites
These attacks are related but not identical. Blocking a user from referring themselves does not stop a farm of separate accounts. Delaying a withdrawal does not fix a duplicated ledger event. A durable program treats attribution, earning and transfer as separate trust boundaries.
| Attack | What the attacker wants | Primary defence |
|---|---|---|
| Attribution abuse | Credit the same or controlled account to a sponsor | One sponsor, self-referral rejection and qualification |
| Reward duplication | Trigger the same credit more than once | Event-level idempotency and an append-only ledger |
| Payout abuse | Turn suspicious balances into irreversible transfers | Limits, maturity periods, review and queue controls |
Make qualification more expensive than pressing Start
A bot start costs almost nothing and can be automated or repeated across controlled accounts. Reward an action that carries evidence of intent: completing a channel gate, returning on another day, finishing a verified task or performing the first useful product action. The exact event depends on the campaign, but it should be more valuable to the owner than the reward paid for it.
Avoid hidden mazes designed only to prevent withdrawals. Qualification should be published, finite and achievable for a legitimate participant. Anti-fraud protects the promise; it should not become a reason to deny earned rewards.
Use deterministic controls before probabilistic suspicion
These rules do not guess whether someone is fraudulent. They make impossible states impossible. Add behavioral risk scoring only after deterministic controls are correct; otherwise a sophisticated model will sit on top of duplicate credits and inconsistent balances.
- Reject a sponsor ID equal to the referred user ID.
- Record the original sponsor once and do not overwrite it with later links.
- Give every qualification event a unique ledger key.
- Do not credit until required channel membership is verified.
- Cap rewards per sponsor, user and time window where the budget requires it.
- Reject repeated withdrawal confirmations for the same request.
- Restore failed transfers through one idempotent refund event.
- Preserve the reason for every rejection or reversal.
Detect account farms by patterns, not nationality
Useful signals include impossible invite velocity, many accounts qualifying in the same sequence and interval, repeated payout destinations, synchronized task behavior, abnormal channel churn and clusters whose only activity is the minimum required for withdrawal. Evaluate combinations rather than treating one fast user or one shared network as proof.
Do not use geography, language or device type as a shortcut for fraud. Those attributes can correlate with legitimate acquisition sources and create unfair blocking. A risk score should produce a review state or additional verification proportional to the potential loss.
| Signal | Benign explanation | Safer response |
|---|---|---|
| High invite velocity | A real influencer campaign | Compare activation and source history before limiting |
| Shared payout address | A custodial wallet or family account | Review cluster and ask for clarification when value is high |
| Fast identical actions | A simple onboarding flow | Look for timing regularity and repeated account relationships |
| Channel leave after reward | Low product value, not necessarily fraud | Change qualification or retention incentive |
Protect the ledger and payout queue
A balance should be the sum of traceable events, not a number edited by several unrelated handlers. Credit the referral against a unique relationship and qualification event. When a withdrawal is requested, create one queue record and one corresponding debit or reservation. The final transfer or refund closes that exact record.
Separate automatic native-asset payouts from project-token requests that require manual handling. A queue worker must never interpret an arbitrary token amount as the native reward amount. Asset, payout mode, destination, status and owner decision belong on the request itself.
- Append-only reward history
- Unique event keys
- Atomic balance change
- Explicit asset
- Explicit payout mode
- One final status
- Traceable refund
- Owner-visible review notes
Design a review process before the first flag
- Freeze the risky transfer, not the entire account
Keep unrelated legitimate actions available where possible.
- Show a neutral pending state
Do not accuse the user while evidence is incomplete.
- Collect the relevant event history
Sponsor chain, qualification, ledger and payout destination should be visible together.
- Record the decision
Approve, deny or reverse with a reason and operator identity.
- Offer an appeal path
Legitimate users need a way to correct false positives.
- Feed the result back into rules
Fix the deterministic gap or adjust the risk threshold after repeated cases.
Watch these ratios every week
Fraud is not only the number of accounts banned. Monitor pending-to-qualified conversion, qualified-user retention, repeated payout destinations, reward reversals, failed withdrawals, channel churn and support appeals. A sudden improvement in referral volume paired with collapsing retention is often a budget warning even before a rule is technically violated.
Keep source cohorts separate. One partner may send fast but genuine users while another sends accounts that complete only the cheapest action. Pay partners and increase referral rewards based on retained or monetizable outcomes, not raw bot starts.
Net referral value = retained contribution − rewards − transfer costs − fraud loss − review and support costCommon questions
Can Telegram detect every fake account for my bot?
No. A bot receives limited account and interaction data. Use several product-level controls and review patterns rather than relying on a single “real user” flag.
Should I require a deposit before withdrawal?
Only if it is a genuine, clearly disclosed part of the product. A surprise deposit requirement is not anti-fraud; it damages trust and may create legal or platform risk.
How long should rewards remain pending?
Use the shortest delay that lets the qualifying action become meaningful and the transfer risk be reviewed. Publish the timing before participation.
What is the most important technical control?
Idempotency at the reward-event and payout-request level prevents repeated callbacks or retries from creating duplicate money movement.
Sources and further reading
Technical and product claims were checked against these primary sources.