Crypto community FUD: a protocol for checking claims

Which details belong in the first community claim record?

A 5-field claim record gives the team a shared starting point. Capture the exact claim, its source, any evidence supplied, the review owner and the current status. Keep the wording neutral. A label such as FUD does not establish whether a message is accurate.

Use the record to preserve the question, not to judge the person who raised it. Add a link to the original post or save a permitted internal reference. Note when the team received it. If the claim refers to a transaction, contract or project announcement, attach the relevant public source rather than relying on a summary.

Classify the issue into 1 of 4 working groups:

• Answerable: existing public information addresses the question.
• Under review: a subject-matter owner must check facts first.
• Opinion: a prediction or view is not a verifiable project fact.
• Sensitive: security, legal, treasury or personal information needs restricted handling.

This classification helps moderators route a concern without making a premature public judgment. For community operations beyond incident handling, see the guide to growing a crypto Telegram community.

How can a team test a claim before it replies?

A source-to-claim comparison shows what the available evidence supports. Assign the check to someone with access to the relevant records. A moderator should not infer contract behavior, treasury decisions or roadmap commitments from incomplete information.

Use a 3-part review note:

• Claim: restate the assertion in plain, neutral terms.
• Evidence: list the public record or project document checked.
• Finding: mark what is confirmed, unresolved or contradicted.

Then add the next action and the person responsible. For an on-chain question, describe exactly what the cited record displays. Do not treat one transaction as proof of a wider explanation. For a project statement, compare the claim with the current official documentation and identify any differences.

Listing questions need a separate check against the project’s visible profile and verified details. The CoinGecko listing guide and CoinMarketCap listing guide cover those platform-specific tasks. Keep the public response within the evidence reviewed. If the source does not settle the point, say what remains open and who is checking it.

What should the first public reply contain?

A 4-part reply acknowledges the concern, states checked facts, identifies open points and names the next action. This structure lets the team respond without pretending that every detail is already settled.

Write the answer in this order:

1. Identify the issue without repeating inflammatory phrasing.
2. State the confirmed information and link its source.
3. Mark the detail that still needs verification.
4. Say who is checking it and where the next update will appear.

Use direct language. Avoid personal criticism, vague reassurance and assertions without a source. If the answer exists in a project document, link to the relevant passage. If the document caused confusion, revise it as well as answering the conversation.

The first reply does not need to contain every detail. It needs to show that the concern has an owner and a traceable review path. Make the next update point specific enough for moderators to repeat consistently. When new evidence changes the answer, publish a correction in the same place where practical and update the linked reference. That keeps the conversation tied to the current version rather than to an outdated reply.

How do Telegram, Discord and X responses stay aligned?

A shared fact note keeps the team’s 3 channels aligned. Store the confirmed points, unresolved questions, approval owner and canonical public update in one internal location. Moderators can adapt the wording to each conversation while keeping the underlying information consistent.

Give each channel a clear use:

• Telegram: answer within the active discussion and point to the source.
• Discord: route specialist questions to the right channel or owner.
• X: keep the public reply focused and link to fuller context.

These are practical communication choices, not separate versions of the facts. Tell moderators which statements they can make directly and which require approval. If the explanation changes, update the shared note first, then distribute the revised wording to the people responding publicly.

A useful internal note also identifies the canonical update location. That prevents different responders from linking to unrelated or outdated material. For server roles and channel setup, see the guide to setting up a crypto Discord server. For concerns that need broader public communications, review Crisis PR.

Which community concerns should moderators escalate?

A 2-level routing rule separates routine replies from decisions that need specialist authority. Moderators can answer from approved materials. They should escalate issues that require access, expertise or approval they do not hold.

Route a concern to a designated lead when it involves security, legal exposure, treasury actions or a material change to project plans. The lead should confirm the facts and approve any public statement that speaks for the project on those matters. Name a backup owner for cases when the usual decision-maker is unavailable.

Moderation rules should describe observable conduct, not whether a comment supports the project. A critical question is not, by itself, a reason to remove a message. Apply the published rules to repeated posting, personal information, impersonation and other stated violations. Record the reason for an intervention so another moderator can review the decision.

Before an incident, give moderators:

• Current project facts and links to source documents.
• A named contact for technical, legal and leadership questions.
• Clear rules for personal information and impersonation.
• A route for urgent reports and a backup contact.

This preparation lets community staff handle ordinary questions while directing higher-stakes issues to accountable owners.

What should an incident record preserve after each update?

A 6-item incident file makes the response traceable. Keep the original claim, evidence checked, review owner, approval notes, public reply and any later correction. This record helps the next responder understand what the team knew at each point.

Add a dated note when a confirmed fact changes. Keep internal material access limited when it contains sensitive information. Public replies should not expose personal details. If the evidence supports a correction, identify the inaccurate point plainly and link the new source.

Set an update cadence the responsible team can maintain. If review takes longer than expected, post a status note that identifies the unresolved question and next update location. Do not imply that an unanswered issue has been resolved. Tell moderators which version of the answer is current, and replace old links in project-controlled reference material.

Review the file after the issue closes. Check whether the source document was clear, the owner was reachable and the escalation route worked. Convert any gap into a specific playbook edit. That review makes the next response easier to route and reduces the chance of conflicting public statements.

Where do community response controls end?

A project can control its evidence, approvals and published wording; it cannot control how Telegram, Discord or X displays, moderates or distributes posts. Keep important explanations in a project-controlled public resource and link to them from community updates.

A process cannot make incomplete evidence conclusive. State what a public record shows, then identify what it does not establish. That distinction gives members enough context to assess the explanation without overstating the finding.

Before an incident, test the playbook against 3 sample cases: a routine question, a disputed project fact and a security concern. For each one, check the claim record, owner, approval route and public source. Then confirm moderators know where the current facts live and how to reach the backup decision-maker.

For an outside review, send GeoMarketing Experts the original claim, related links, current public documentation and the people authorized to approve a response. GeoMarketing Experts can review the evidence path and response roles, then return practical edits and escalation recommendations. Start with one current or representative concern and the documents your team already uses.

How it works

1. Capture the claimRecord its exact wording, source, time and supplied evidence. Keep the description neutral.
2. Route the fact checkAssign the person who can verify the relevant public record, project decision or technical detail.
3. Approve the wordingShare confirmed facts, identify open points and request approval from the relevant lead.
4. Publish with a sourceAnswer in the relevant conversation and link to the full public reference where useful.
5. Log and updateSave the reply and revise it if verified facts change. Tell moderators which version is current.