Do you need a Discord, a Telegram, both, or neither?
Neither, if you cannot staff it. An unmoderated chat channel is not a neutral asset that quietly does nothing. It becomes a place where people impersonate your team, post links that drain wallets and answer support questions wrongly, all under your name and with your logo at the top. The default should be no chat channel until there is someone whose job it is, and a great many projects would be better off permanently without one.
What is each platform actually good at?
Discord is a structured forum pretending to be a chat app. Roles, permissions, threads, searchable history and token gating make it the right tool when the community has several distinct groups and conversations that need to persist. The cost is friction: newcomers face an unfamiliar interface, a verification step and thirty channels, and a meaningful share of them never post.
Telegram is a broadcast tool with a chat attached. It is faster, works well on a phone, and has almost no joining friction, which is why trading communities live there. The cost is that structure is optional rather than assumed. A supergroup out of the box is one flat stream, and a busy one is unreadable. The tools to fix that exist: Topics, the forum mode Telegram added in version 9.0 in November 2022 and later opened to groups of any size, gives each thread its own persistent history, pinned message and per-user notification settings, supergroup history is stored and searchable rather than scrolling away, and admin permissions are granted right by right, including who may create topics. What Telegram will not do is impose that structure for you, so a group only stays findable a month later if someone turns Topics on and keeps the list short.
The pattern that usually works is one place for announcements, chosen for where your audience already is, and at most one place for conversation, chosen for whether the conversation needs structure. Running both in full is a common decision and it doubles the moderation cost for a marginal gain.
| Channel | Best at | Worst at | Moderation burden |
|---|---|---|---|
| Discord | Structured community, roles, persistent discussion, gated access | First impressions, casual mobile users | High, continuous |
| Telegram group | Speed, mobile, low joining friction, searchable history | Structure unless Topics are turned on, impersonation resistance | High, and harder to automate |
| Telegram channel | One-way announcements to a large audience | Any two-way relationship | Low |
| Public forum | Proposals, long arguments, anything worth citing later | Momentum, casual chat | Moderate |
| Email list | Reaching people you would otherwise lose, and owning the list | Immediacy and conversation | Low |
| Public social replies | Discovery by people outside the community | Depth, support, anything sensitive | Moderate, and permanently visible |
What actually goes wrong in these servers?
Impersonation, overwhelmingly. Someone copies a moderator's display name and avatar, waits for a member to ask for help in public, then messages them privately with a link. The member believes they are talking to your team because the profile is identical, and the link takes their assets. This works constantly and it needs no technical skill at all.
Then compromise of announcement channels. A moderator account without two-factor authentication, a bot granted more permission than it needed, or a leaked webhook is enough to post a fake mint link to everyone, from an account members are trained to trust. Announcement compromise is the most damaging single incident type because the message carries your authority.
The mitigations are unexciting and effective. Enforce two-factor for anyone holding a role, audit bot permissions and remove anything unused, rotate and restrict webhooks, keep announcement posting rights to as few people as possible, put new joiners in a quarantine role until verification, run slow mode in busy channels, and state loudly and repeatedly that your team never sends the first direct message. That last one belongs in the channel description, not in a pinned post nobody opens.
How should a server be structured?
With far fewer channels than instinct suggests. Every empty channel is a visible signal that the project is dead, and thirty channels guarantees that most are empty. Start with three or four, let members complain that they need more, and add reluctantly. Consolidating a busy server is easy, reviving a sprawling quiet one is not.
Announcements should be read-only and should carry no links to anything other than your own domain. Support should have published hours rather than an implied promise of constant coverage, because a support channel that is unanswered at three in the morning is where the impersonators do their best work.
Token gating deserves restraint. Gating a small area for holders is sensible; gating the main conversation means prospective customers cannot see anything worth joining for, and it converts your community into a holders-only room that talks about price. Keep the front of the server open and interesting to someone who has bought nothing.
When should you not have a chat channel at all?
When you cannot cover the hours your audience is awake. Coverage is the deciding constraint, not headcount in total, and a global audience means overnight coverage or a channel that is closed overnight. Closing a channel overnight is entirely respectable and far better than leaving it open and unwatched.
Also when there is nothing to discuss between announcements. Products with a long build cycle and no ongoing use generate no natural conversation, so the room fills with speculation about timing, then with speculation about price, then with people who are angry. A newsletter and a support inbox serve that audience better and cost a fraction as much.
And when the audience is professional. Business buyers do not join a Discord to evaluate a supplier, and asking them to is a friction that reads as unserious. The web3 default of opening a public chat is a habit from consumer token projects and transfers badly to anything sold to a company.
Who owns the audience if the platform disappears?
Not you. Servers get banned, accounts get compromised, platforms change policy on crypto communities, and in every one of those cases the audience you spent a year building is unreachable within an hour. This is the structural weakness of chat-first community building and it is rarely planned for.
The mitigation is a mailing list, collected continuously and stored somewhere you control. It does not need to be used often. It needs to exist so that a platform incident is an inconvenience rather than the end of the relationship, and so that the members who quietly stopped opening the app can still be reached.
Run the test: if your main channel vanished tonight, how many of your community could you contact tomorrow? If the answer is a small fraction, that is the first thing to fix, and it is a week of work rather than a strategy.
Common questions
- Should a web3 project use Discord or Telegram?
- Discord suits communities with distinct groups and discussion that needs to persist and be searchable, at the cost of a harder first impression. Telegram suits fast mobile announcements and low-friction joining, at the cost of structure being optional: supergroup history is searchable and Topics give each thread its own history and pinned message, but a group stays one flat stream until an admin turns Topics on and maintains them. Most projects need one announcement channel where their audience already is, and at most one conversation space. Running both in full roughly doubles moderation cost for a marginal gain.
- How do crypto Discord scams work?
- Most begin with impersonation. Someone copies a moderator's display name and avatar, watches for a member asking for help publicly, then messages them privately with a link that drains their wallet. The second common route is announcement compromise, through a moderator account without two-factor authentication, an over-permissioned bot or a leaked webhook, which lets an attacker post a fake link with the project's authority behind it.
- How do you secure a project Discord server?
- Enforce two-factor authentication for everyone holding a role, audit bot permissions and remove anything unused, rotate and restrict webhooks, limit announcement posting rights to as few accounts as possible, hold new joiners in a quarantine role until verification, and use slow mode in busy channels. State in the channel description, not only in a pinned post, that the team never initiates direct messages.
- How many channels should a Discord server have?
- Fewer than instinct suggests, starting with three or four. Every empty channel signals publicly that a project is dead, and a server with thirty channels guarantees most of them are empty. Add channels reluctantly and only when members ask, because consolidating a busy server is straightforward while reviving a sprawling quiet one generally is not.
- When should a project not run a community chat?
- When it cannot cover the hours its audience is awake, since an unwatched channel is where impersonators operate most successfully. When there is nothing to discuss between announcements, as with long build cycles, because the room fills with speculation about timing and then about price. And when the buyers are businesses, who do not join chat servers to evaluate a supplier.
- Do you own your community if it lives on Discord or Telegram?
- No. Servers are banned, accounts are compromised and platform policy on crypto communities changes, and any of those makes an audience unreachable within an hour. The mitigation is an email list collected continuously and stored on infrastructure you control. A useful test is to ask how many community members you could contact tomorrow if the main channel disappeared tonight.
