Why scammers and bots attack a crypto project's Telegram chat
While the chat is small, order is maintained by the attention of two or three admins: they know the nicknames and spot outsiders immediately.
At the growth stage, the audience increases tenfold, membership changes every day, and manual moderation of a crypto project's Telegram chat can no longer keep up with the flow — the chat turns from a project venue into a venue for scripts.
The first to activate are mass DMs: the member list of a public chat is scraped, and a request to verify a wallet or follow a link is sent on behalf of “support.” The second scenario is admin impersonation: clones with a similar username and the same avatar reply in DMs first, before the real admin has even seen the question.
Chat protection against bots runs up against the fact that some attacks are not messages at all — scammers in a project chat operate through DMs, where chat rules do not reach.
Then come fake giveaways requiring wallet connection or transaction signing, followed by funneling members into a “backup official chat,” where the same scam runs without your control.
The cost is the same: some newcomers leave after the first suspicious message, support drowns in complaints instead of working with the product, and reputation sags exactly where the project is recruiting people.
Telegram chat setup, permissions, filters, and a playbook for admins close most of these scenarios — let's break down how this is done.
The effect of managed moderation and participant protection
Moderation without a playbook relies on enthusiasm: while moderators are online, reaction is fast, but at night a scam link stays in the feed until morning and collects clicks.
Scheduled shifts and escalation to an internal section provide predictable incident response speed — minutes instead of hours, with a record of who took the request.
The main influx into a crypto project's Telegram chat is not people but disposable accounts. Entry captcha, a minimum profile age, and a delay before the first message cut off most of them before their first reply.
A small tail remains that is dealt with manually, and the rule “links only from verified domains” closes that too.
Next, the load on support decreases: pinned answers to frequent questions and templates for typical situations resolve requests right in the chat. Participants stop DMing moderators, and support handles complex cases instead of repetitive ones.
A separate effect of community protection is a class of attacks that disappears. Mass flooding with phishing links and fake “admins” who message first stop working when all official announcements come from a single channel.
This is measurable as follows: an incident log shows the number of triggers, the share of false bans, average moderator response time, and support request dynamics.
Moderation modes: manual, automatic, hybrid
The moderation mode is chosen based on the ratio of message flow to the number of people handling that flow.
While activity is measured in dozens of messages per day, manual community moderation is more accurate: a moderator sees the context and defuses a conflict before others join in. When the flow grows and membership changes daily, manual review can no longer keep up.
Automatic moderation handles volume: chat filters and rules cut off links to third-party resources, repeats, and messages from new accounts before participants see them.
The limitation is the lack of context: an ad and a quote in a discussion look the same, so an automated system without appeal review produces false bans.
| Option | When it fits | Limitations |
|---|---|---|
| Manual community moderation | Small flow, high cost of a reputational mistake, stable core of participants | Depends on people's shifts and workload, scales only by hiring |
| Automatic moderation | Large flow of similar violations, round-the-clock response needed | False positives and missed disguised spam |
| Hybrid moderation | Project is growing, flow exceeds shift capacity | Requires configured thresholds and review of the queue of disputed decisions |
Hybrid moderation is the default working option for a growing project: automation holds the flow, while a human reviews disputed triggers and appeals.
The modes are compatible with each other: filters, sensitivity thresholds, and role permissions carry over without being rebuilt from scratch — only the share of decisions going to a human changes.
How we set up a chat: stages of work
A crypto project's chat is both the entry point for the community and an attack surface. Scam bots, admin clones, spam invites, and attempts to lure a person into DMs for “wallet help” appear within the first day after an announcement.
That is why we start by recording the current state and target metrics, not by turning on filters at random.
-
Telegram chat audit. We collect statistics: deleted messages, bans, connected bots and their permissions, admin activity. We separately flag permissions granted “just in case.”
-
Role and permission map. We break participants down into owner, admins, moderators, bots, and newcomers. Each role gets only the actions it needs: a moderator should not be able to change chat settings or the admin list.
-
Filter and scenario setup. Entry captcha, anti-flood, restrictions on links and media for new participants, auto-deletion of invites. We define what automation handles and what goes to a human for escalation.
-
Moderation implementation. Shift playbook, response templates, escalation chain, and action log. A moderator sees the decision history for a participant and does not duplicate a colleague's work.
-
Chat protection testing. Simulated attacks: scam bots, fake admins, flooding, mass invites. We see what share of violations is caught automatically and adjust thresholds.
-
Handover of settings to the client. We provide bot configurations, the permission map, and playbooks, train moderators on live examples, and compare metrics with the baseline.
Documents, rules, and access that stay with the team
A chat outlives any individual moderator: people change, access remains in personal accounts, and rules exist only in correspondence with the founder.
We document everything needed for independent management in a set of documents — a new admin gets up to speed from them, not from someone else's memories.
What the team keeps after setup:
- Project chat rules — what is allowed in the general flow, what goes to DMs, what earns a warning and what leads to an immediate block, with an analysis of typical violations.
- Permission and role scheme — who sees deleted messages, who issues restrictions and bans, who changes bot settings; admin rights are not granted “just in case.”
- Moderator instructions — scenarios for everyday situations: a newcomer's question, a dispute about prices, a provocation, an attempt to lure participants into a third-party chat.
- Incident response playbook — procedure for mass spam, compromise of an admin account, and leakage of an invite link: who decides, who is notified, how the timeline is recorded.
- Moderation documentation — a decision log with reasons for bans and announcement templates so that tone and wording do not drift from shift to shift.
- Access handover procedure — a checklist for granting and revoking permissions, bot key rotation, and binding to service accounts instead of personal ones.
The documents live in the team's shared storage, not in chat threads, and are updated with every rule change. Before handover, we run a separate check against them: a new moderator must handle a training situation without asking clarifying questions.
Case study: how a community withstood a wave of attacks at launch
The project opened a public chat in Telegram an hour before the announcement — and within 15 minutes of launch it had about two thousand accounts.
Moderators could process only a few messages per minute: half the flow was ads for third-party projects, fake “support services,” and links to counterfeit bots.
Participants were DM'd on behalf of the team, and some people left the chat within the first day without waiting for a response from a real person.
What we changed
We built a permission scheme and automated checks instead of manual cleanup after the fact.
New participants were passed through a captcha and a message rate limit, links and domain mentions were allowed only through a whitelist, and accounts without activity history could not post in the general flow for a while.
Roles were separated: on-duty moderator, senior moderator with ban rights, incident escalation to a private channel, and every action was logged with a reason.
What happened
The share of spam in the flow fell from about 40% to less than 1%, and incident response time went from 20 minutes to 40–60 seconds. False bans remained below a fraction of a percent, and first-day churn decreased threefold.
Moderation stopped being a bottleneck at peak: the chat handled the announcement load without manual firefighting, and complaints moved to a private form.
“Previously we put out fires by hand and lost people at launch. After reconfiguration, the chat handled the load itself — all that remained was to review the log and handle isolated cases,” — project lead.
How moderation differs from protection against bots and mass mailings
Moderation works with message content, while perimeter protection works with signs of account behavior.
In Telegram these are two different circuits: the first reacts to what has already been published — the meaning of the text, a link, a competitor's ad; the second looks at how the message appeared: profile age, sending rate, identical texts from a dozen participants in a minute.
Hence the different measurement points. Moderation evaluates a single message in context — the author, participation history, the chat's reaction to similar remarks.
Protection against mass mailings calculates flow statistics: how many joins per interval, the share of accounts without history, a spike in forwards from one source.
The same phrase from a participant with years of history and from a profile created an hour ago is different signals for protection and identical for moderation.
Response scenarios also diverge. Moderation rules lead to deletion, a warning, or moving the author to read-only mode — a decision made by a human or their playbook.
Protection triggers by threshold: rate limiting, mandatory entry verification, slow mode, blocking the entire invite chain through which the violators arrived.
The contractor's responsibility boundaries run exactly here. We configure role permissions, filtering rules, entry checks, and the trigger log, provide the playbook, and hand over access to your team.
Disputed deletions, participant conflicts, and content complaints remain with you — these are management decisions, not a configuration task.
Common technical doubts about rules and access
Moderation rules are a set of thresholds and filters, not a single setting. When they are changed in a live chat with participants, it is important to understand in advance how the changes will affect people and the protection that is already working. Below are the technical doubts that most often arise before the start, and our answers to each.
How long does it take to switch to new rules?
We enable new filters in observation mode: the system writes triggers to the log but does not issue sanctions. This way we collect statistics on real violations and false reactions for 3–7 days, then enable bans. The rules are not applied retroactively to old messages.
What to do about false bans of participants?
Instead of an instant ban, quarantine: the message is hidden, the author receives a notification and can pass verification. Regular participants, partner accounts, and high-activity discussions go on the whitelist. We tune the sensitivity threshold based on the log, not by eye.
How to separate the permissions of several moderation teams?
Roles are divided by zones: anti-spam, support, complaint review. Each team sees only its own log and cannot lift a sanction imposed by another.
Full permissions remain with the owner, access is granted through a bot with an audit record — membership changes without handing over the master account.
We already have protection set up — will it have to be turned off?
No. First we review existing bots and filters, remove duplicates that cause double mutes and conflicts. We move the settings to a test duplicate of the chat, run violation scenarios, and only then switch the live chat — with no window when protection is down.
How to revise chat rules without chaos?
We keep rules versioned: each change has a date, reason, and owner. We announce edits in advance, test disputed wording on participants, and rolling back to the previous version takes one step.
Let's discuss the task: what data to prepare for the conversation
To come back with a task estimate and a moderation work plan, we need a minimum of inputs — without them, the calculation is based on guesses and extra stages end up in the estimate.
Below is what is worth preparing for a chat setup discussion: the list removes the first round of questions and immediately sets the project start scope.
- Size and stage of the community: total participants, daily active users, peak number of messages per hour, whether there are topic threads.
- Current rules and structure: where the rules are pinned, how roles and permissions are granted, what restrictions apply to new participants.
- Known incidents: waves of spam and fake engagement, attempts to lure people into DMs, past bans and what broke in the chat's operation afterward.
- Moderator team: how many people, in which time zones, how shifts overlap, who makes decisions on disputed cases.
- Access requirements: who owns the chat and the linked channel, what permissions have already been granted, whether there are restrictions on transferring admin access.
If some data is missing, that is not a problem; we will fill it in during the conversation: part of the picture can be reconstructed from logs and current settings.
Describe the task in any convenient form, and we will come back with an estimate, a moderation work plan, and a proposal for the implementation sequence.