TL;DR: FUD, meaning fear, uncertainty, and doubt about a project's team, contract, or treasury, does not damage a token sale on its own. The damage comes from a team that answers late, sounds defensive, or gives different answers on different channels. When a claim goes unanswered for hours, investors and allocators read silence as a sign of deeper problems and pull commitments. This article sets out a reputation plan built before TGE, the token generation event when the token goes live and becomes tradable: a response ladder that decides who answers and how fast, a proof library with verified contracts, audits, and wallets, one pinned page for official links, a named escalation owner, and statements worded for X, Telegram, Discord, and investors. It also covers the four steps for handling fake screenshots without spreading them further.
Buyers enter a token sale primed for fraud. The FBI's 2025 Internet Crime Report logged 181,565 crypto-related complaints, with losses of $11.4 billion, up 22% from 2024. A buyer who has seen those numbers walks away at the first unanswered accusation. The question for a founder is not whether FUD will appear before TGE, but whether the team can answer it within minutes, in one voice, across X, Telegram, and Discord.
Impersonation raises the stakes further. Chainalysis's 2026 Crypto Crime Report found impersonation scams grew roughly 1,400% year over year in 2025, which means a project does not have to do anything wrong to be accused. It only has to be worth copying. This is why a token sale needs a reputation process before the first claim lands, not after.
Why Is FUD Most Dangerous Before TGE?
In a token sale, FUD is any claim, true or false, that makes buyers question whether the team, the contract, or the treasury is what it says it is. It is most dangerous before TGE for four reasons.

Buyers Cannot Reverse a Mistake
According to the FTC, crypto payments are irreversible once confirmed on the blockchain, most platforms offer no dispute process, and no deposit insurance covers a wallet balance. A buyer who sends funds to a fake sale contract has no chargeback to fall back on. That makes the cost of trusting the wrong project permanent.
Buyers Are Trained to Leave, Not Investigate
The FTC advises buyers to treat pressure to act fast, unverified contracts, and unsolicited wallet addresses as reasons to walk away. A token sale under FUD triggers exactly those signals. The buyer does not weigh the accusation. They exit and move to the next sale.
Fake Presales Are Cheap to Build
Impersonation no longer needs skill. Malwarebytes has reported on turnkey kits sold for around $500 that produce ready-made sites designed to look like legitimate presales. Any project with attention is a target, and every clone feeds the next scam claim against the real one.
A Pre-TGE Project Has No Track Record
Before TGE, a project has little on-chain history to defend itself with. There is no trading record, no vesting unlock that has executed as promised, and often no live product. Every claim about the team, the treasury, and the contract rests on documents the project publishes itself. If those documents are missing or scattered, the accusation fills the gap.
What Are the Three Types of Pre-TGE Reputation Attacks?
Knowing why FUD is most dangerous before TGE is only half the picture. The other half is knowing what kind of FUD the project is facing, because each kind needs a different response. Below are the three types of pre-TGE reputation attacks and how to recognize each one.
1. Organic Doubt
Organic doubt is a real question from a real buyer. These are not attacks. They are the diligence buyers are told to do before committing. Left unanswered, organic doubt turns into FUD.
"Why is the team allocation 20 percent?"
"Where is the audit report?"
"Who is the legal entity behind the sale?"
"Why does the vesting schedule not match the deck?"
2. Coordinated FUD
Coordinated FUD is a repeated narrative pushed by accounts with a motive. That motive may be a competing launch, a planned short after listing, or a group seeking payment to stop. The main sign is repetition without new evidence.
The same "the team is dumping" claim posted by ten accounts within an hour
A thread that resurfaces every day at the same time with no new source
A "researcher" who offers to take down their post for a fee
Screenshots of a private chat with no way to verify the participants
3. Impersonation-Driven Scam Claims
Impersonation is the most damaging type because it produces the evidence that later claims rely on. Scammers clone logos, spoof domains, and create fake team profiles to collect deposits into their own wallets. When a buyer loses funds to a clone, the accusation is directed at the real project.
A cloned sale website with a different deposit address
A Telegram account using the founder's name and photo, DMing buyers first
A fake "claim" page that requests an unlimited token approval
A screenshot of a transaction from the fake contract, presented as the real team's wallet
Attack type | Typical signal | Response tier |
Organic doubt | Specific question, single account, open to an answer | Tier 2 reply with proof |
Coordinated FUD | Same narrative repeated across accounts, no new evidence | Tier 3 statement |
Impersonation | Fake site, wallet, or profile using project branding | Tier 4 takedown plus Tier 3 |
The response tiers in the table are explained in the next section. Teams that want to see the buyer's side of this classification can compare it against a token sale due diligence checklist, which lists what serious buyers check before they commit.
How Should a Token Sale Team Respond to FUD?
Once the team knows which type of attack it is facing, the next question is who answers, how fast, and with what. A token sale team should answer through a response ladder. The ladder removes the failures described at the start of this article. Nobody waits for a founder to become available, and nobody improvises a reply. Below are the four tiers, matched to the attack types from the previous section.

Tier 1: Monitor and Log
Tier 1 is the starting point for every claim, before anyone replies. Its purpose is to capture the evidence while it still exists, because posts get deleted and accounts get renamed. The community team records each mention with a screenshot, the account, the channel, and the time. This is the same evidence scam guides tell victims to keep, and it is what every later tier acts on.
Owner: community team
Time target: continuous during sale hours
Permitted action: record only, no reply
Handles: every mention, before it is classified
Tier 2: Community Manager Reply With Proof
Tier 2 is the first visible response, and it handles organic doubt. Its purpose is to answer a real buyer's question before it turns into FUD. A moderator replies with a link to the relevant item in the proof library, such as the verified contract address or the audit report. The reply stays short and factual, with no comment on the poster's motive.
Owner: community manager
Time target: within 30 minutes
Permitted action: short factual reply with a proof-library link
Handles: organic doubt
Tier 3: Official Statement From the Escalation Owner
Tier 3 is the project's single official response, and it handles coordinated FUD. Its purpose is to replace scattered moderator replies with one statement that every channel repeats word for word. It is triggered when the same claim appears across channels or names a specific wrongdoing. The escalation owner writes it, posts it on the canonical channel first, and then copies it to the others.
Owner: escalation owner
Time target: within two hours
Permitted action: one official statement, mirrored across channels
Handles: coordinated FUD, and impersonation alongside Tier 4
Tier 4: Platform Report or Legal Takedown
Tier 4 is the removal step, and it handles impersonation. Its purpose is to shut down the fake site, wallet, or profile that is producing the evidence behind the scam claims. The escalation owner reports it to the platform's abuse process and to public scam registries such as Chainabuse. Where a clone is collecting funds, legal counsel is brought in and the domain host is contacted. Before the sale opens, the team identifies the most likely impersonation targets, such as the audit report, vesting schedule, and treasury wallet list, and pre-stages takedown requests with its registrar and hosting provider so Tier 4 does not start from a blank form.
Response times vary by platform and are rarely guaranteed, so the escalation owner logs the report time and follows up at set intervals. This is also why the Tier 3 statement runs alongside Tier 4. Buyers get the correction immediately, while the takedown works through the platform's own process.
Owner: escalation owner with legal counsel
Time target: same day
Permitted action: abuse report, registry report, takedown request to host
Handles: impersonation
What Belongs in a Pre-Launch Proof Library?
Every tier of the response ladder depends on one thing: proof the team can link to within minutes. That proof needs a home. A proof library is the single page the ladder points to, so a moderator never has to search for an answer while a claim is spreading. The reason it works is simple. Buyers are told to treat wallet addresses, transaction hashes, and verifiable records as evidence. Publishing that evidence before the sale opens removes the scam signals before an accusation can use them.

The library should hold, at minimum:
Verified sale and token contract addresses on every chain used, including Solana and Ethereum
Audit reports from recognized firms such as CertiK or OpenZeppelin, linked from the auditor's own site, not a hosted copy
The vesting schedule, with team and investor unlocks dated
Treasury and team wallet addresses, labeled
Team identities with a public record, or a stated reason for anonymity
The tokenomics document, versioned, with every change noted
Legal entity, jurisdiction, KYC provider, and MiCA compliance status where applicable
The last item overlaps with what exchanges and regulators will ask for. A token sale marketing compliance checklist covers what to prepare there.
All seven items are live and linked before the sale opens, not during it. Building the library in the middle of a crisis means publishing under pressure, and pressure produces errors that become new claims. Where an item cannot be complete, the gap gets a public explanation instead. If team identities cannot be public because of doxxing risk, the library names the KYC provider and the verification date. If an audit is pending, it shows the audit scope and expected completion date, with a commitment to publish the full report within 48 hours of receipt. Missing items create the gaps that FUD fills, so every gap is explained before a buyer asks.
How to Set an Official-Link Policy and an Escalation Owner
The proof library gives the team something to point to. The ladder tells the team when to point to it. Two gaps remain. First, buyers need a way to tell the project's real links from a clone's, or the proof library itself can be copied. Second, someone has to decide when a claim moves up the ladder, or replies come from whoever answers first. An official-link policy closes the first gap. A named escalation owner closes the second.
One Canonical Link Source, Pinned Everywhere
The policy names one page as the only source of truth for links: website, contracts, sale portal, and social accounts. That page is pinned in every channel, and every other post refers to it instead of repeating links. The policy also states, in plain words, that the team never sends a DM first and never shares a wallet address in a reply. Scam guides warn buyers that unsolicited wallet addresses and off-platform messages are fraud signals, so the project's own behavior must never look like them. For how fake links and drainers target claim pages, see this guide to claim safety during a token sale.
Who Approves What, and Within How Many Minutes
The escalation owner is one person with authority to publish a Tier 3 statement without a meeting. A backup is named for coverage. The role should have crisis communications or community management experience. A written rule states which claims moderators may answer alone, which go to the owner, and the time limit at each step. The owner can approve Tier 3 statements up to two hours after claim detection. Claims involving legal liability, regulatory risk, or potential fund loss go to legal counsel before posting. Without this rule, the fastest replier sets the narrative, and that person is rarely the best informed.
A moderator escalates from Tier 2 to Tier 3 when any of these signals appear: the same claim posted by five or more accounts within two hours, the same question appearing in both X and Telegram with identical wording, or a single account reposting the same accusation after a Tier 2 reply. The escalation owner is notified immediately with a screenshot of each instance. This prevents moderators from answering the same coordinated claim separately, which fragments the response and makes the project look unprepared.
What Should Founders Do When Fake Screenshots Spread?
Fake screenshots need their own steps because they arrive with their own "evidence." A screenshot of a wallet selling tokens looks like proof to a buyer, even when the wallet belongs to a clone. The answer is to replace fake evidence with real evidence, in this order.

Step 1: Verify On-Chain
A screenshot either matches a transaction hash on a public ledger or it does not. The team checks the explorer before saying anything.
Step 2: Publish the Real Record
The reply links to the explorer entry, or to the labeled treasury wallet in the proof library showing no such transfer. It names the claim, shows the record, and stops. No comment on the poster's motive.
Step 3: Report the Source
The account or site behind the fake goes to the platform's abuse process and, where funds were taken, to a scam registry. A cloned site is also reported to the registrar and host.
Step 4: Correct Without Amplifying
Quote-posting the fake shows it to followers who had not seen it. The correction goes out on the canonical channel with proof attached. The original is kept only in the internal log.
When a claim is partially true, the response must acknowledge the factual part before correcting the false part. For example, if a claim says the team allocation is 20 percent and the team is dumping, the reply confirms the allocation percentage from the proof library, then shows the vesting schedule proving no unlock has occurred yet. This approach rebuilds trust without appearing defensive. The team never argues the poster's motive, only the verifiable record.
How to Word Statements for X, Telegram, Discord, and Investors
Once a token sale team has its process and proof in place, the next step is deciding how each statement is worded for each audience. A buyer on X, a participant in Telegram, and a market maker reading a private note all need the same facts, but not the same framing. The rule is simple. Statements change detail by channel and never change facts.
Channel | Audience | Must include |
X | Public, buyers, press | The claim, the proof link, the canonical link page |
Telegram | Active sale participants | Same as X, plus a reminder that the team never DMs first |
Discord | Community and holders | Same as X, plus which moderators are authorized to answer |
Investors and exchanges | Allocators, market makers, listing teams | The claim, the proof, what the team did, expected impact |
The investor note goes out first. Allocators and exchanges should hear about a claim from the project, not from a screenshot forwarded to them. Most token sale marketing plans cover the public channels in detail and skip this step, and it is the one that protects allocation commitments.
Why the Best Time to Answer FUD Is Before It Starts
Every section above comes back to one point. FUD does not sink a token sale. The response does. A claim answered within 30 minutes with a link to proof is a non-event. The same claim answered a day later, with three different explanations, becomes the story of the launch.
That is why the plan is built before the sale opens. The ladder decides who answers and how fast. The proof library gives them something to link. The link policy and escalation owner keep every reply consistent. Channel-specific statements carry it to buyers, community, and investors in the words each expects. A team with these in place spends TGE week selling tokens. A team without them spends it explaining screenshots.
Who runs the plan is a separate decision from what the plan contains. An in-house team owns the ladder and proof library from the start, which keeps messaging consistent but means hiring or redeploying staff weeks before the sale. An agency runs the full process, which brings speed and experience at the cost of less direct control. A hybrid model keeps escalation and legal decisions with the project while an agency staffs moderators and builds the proof library, which splits the load but needs clear handoff rules. The right fit depends on the project's timeline, budget, and how much of the process the team can absorb.
Launch a Reputation Response Plan With TokenMinds
A token launch survives FUD when the proof and the process exist before the sale opens. The sections above show what that proof and process look like.
TokenMinds has run token sales end to end since 2016, including community management and pre-TGE communications. The work covers building the proof library, writing the official-link policy and response playbook before the sale opens, and staffing moderators who apply it consistently across X, Telegram, and Discord. Its launch reputation response plan reviews a project's channels, proof, and escalation setup in one pass. The team starts with a launch date and ends with a list of the gaps a buyer or an impersonator would find first, and a plan to close each one.
Launch a reputation response plan with TokenMinds.
FAQs
How should a crypto project respond to scam accusations before TGE?
Identify the type of claim first, then follow the response ladder. A real question gets a moderator reply with a proof link. A repeated claim gets one official statement from the escalation owner. Impersonation gets a platform report, a scam registry report where funds were taken, and legal counsel. The team never argues and always links to proof.
How do we handle FUD during a token sale?
Build the plan before the sale opens. That means a proof library with verified contracts, audits, vesting, and wallets, one pinned page for official links, a named escalation owner with time targets, and a written rule for what moderators may answer alone. During the sale, the job is to apply the plan, not create it.
What should founders say when fake screenshots spread?
Name the claim, show the on-chain record that contradicts it, and stop. Send a private note to investors and exchanges first, then publish on the canonical channel with the proof attached. Report the source through the platform's abuse process. Do not quote-post the fake.









