Web3 Reputational Risk Register: 12 Crises to Plan For

A reputational risk register is not a crisis plan. It is the document that makes a crisis plan possible. You build the register before anything happens, mapping each risk by likelihood and potential impact. Then you write holding statements, assign owners, and decide which channels carry which message. When something actually goes sideways, you are not starting from scratch at 2 a.m.

Most Web3 founders have neither. What they have is a vague understanding that hacks are bad and a commitment to "be transparent" that was never stress-tested.

I have run crisis communications across more than 50 Web3 protocols over six years. The projects that survived a bad event almost always had at least informal preparation. The ones that didn't survive often had the same fundamental problem: they treated the first hour as a technical problem and only remembered it was also a communications problem when the community was already spiraling.

This post is the register I build at the start of every client engagement. Fork it, customize it, and add the scenarios specific to your architecture, team composition, and investor base.

---

How to Read This Register

Each scenario entry has four fields:

• What it is: a one-line description of the trigger event
• Who it involves: the stakeholder tiers that need differentiated messaging
• Which channels: where the response lands first, second, and third
• Tone: the specific register your statement needs — and what to avoid

Severity ratings are approximate. Every project's risk profile is different.

---

Scenario 1: Smart Contract Exploit or Bridge Hack

Severity: Critical

The scenario everyone plans for — and still botches. Funds are at risk or already gone. On-chain sleuths are posting before you've finished reading the incident report.

Who it involves: Users with funds at risk, token holders, auditors, legal counsel, the security researcher community, tier-1 media.

Channels: X (project account, not founder's personal account) within 15 to 30 minutes. Discord/Telegram second. Blog post with technical detail within 2 to 4 hours. Media briefing under embargo if the dollar figure is above $5 million.

Tone: Factual and controlled. Acknowledge the incident. State what you know and what you don't. Give a timestamp for the next update. Do not say "all funds are safe" until you have verified it. The phrase has become a meme for a reason — it breaks trust the moment it turns out to be false.

---

Scenario 2: Rug Pull Allegation

Severity: Critical

Your project is not a rug pull. But a single influential account with 50,000 followers says it is, and the screenshot is already circulating in three Telegram groups.

Who it involves: Retail community, KOL network, journalists covering the story, on-chain analysts.

Channels: X first, then a dedicated blog post with the on-chain proof bundle (vesting contract links, audit links, wallet transparency). Discord/Telegram for community-direct reassurance. The founder on a Twitter Space or video call within 48 hours.

Tone: Direct and specific. Vague denials do not work. You need an on-chain proof bundle, not a feelings statement. Doxxed founders have a faster path to credibility recovery; pseudonymous founders need a trusted third-party co-signer.

The allegation has a long tail. Even after you survive the first news cycle, the screenshot resurfaces every few months with new community members. Build a permanent, linkable URL with the full forensics. You will reference it for years.

---

Scenario 3: Token Unlock Controversy

Severity: High

A team or investor unlock window approaches and the community notices. On-chain wallets show tokens moving to exchanges. Price starts dropping. Someone posts a graphic overlaying your unlock schedule with the price chart. The narrative writes itself.

Who it involves: Token holders, retail community, market makers, exchanges, investors whose unlocks are driving the concern.

Channels: Governance forum and project blog first. X thread with the data. Discord AMA within 48 hours.

Tone: Pre-emptive is infinitely better than reactive. Post your unlock schedule publicly before it becomes news. If large-wallet movements were legitimate (e.g., an investor exercising a planned exit), say so factually. If they were not communicated in advance, own that. The worst version of this scenario is silence while on-chain analysts fill the void with speculation.

---

Scenario 4: Co-Founder Departure

Severity: High

In a normal company, a co-founder leaving is a talent story. In Web3, during a fundraising round, a token unlock window, or a governance vote, it becomes a narrative crisis within hours. The departure often leaks on X before any official statement exists, and former team members make vague statements that read as dysfunction.

Who it involves: Investors, employees, media covering the beat, community moderators, KOL partners, potential hires.

Channels: Investors get a personal call before anything is public. Employees get a direct message or video call. X announcement and blog post go out simultaneously, same day.

Tone: Neutral and forward-looking. "Mutual decision," "pursuing a new chapter," "grateful for what we built together" are fine and true enough in most cases. What kills you is the asymmetric story — one party vague-posting on LinkedIn, the other saying nothing. Align the narrative before anyone speaks publicly. No subtweets. No thinly veiled "growth opportunities."

---

Scenario 5: Regulator Subpoena or Wells Notice

Severity: High to Critical (depends on jurisdiction and project type)

A regulatory letter arrives. Maybe it is an SEC Wells Notice. Maybe it is a CFTC subpoena. Maybe it is a foreign regulator inquiry from a market where your token trades. The story leaks — it always leaks.

Who it involves: Legal counsel (immediately), investors, exchange partners, board, then media.

Channels: No public statement until legal approves every word. Investor disclosure first. A terse, legally reviewed blog post if and when required. Media inquiries get a holding statement: "We are aware of the inquiry and are cooperating fully with regulators."

Tone: Spare and factual. Do not speculate. Do not explain the legal theory. Do not put your founder in front of a microphone without legal co-sign on every sentence. The investors you will lose by going dark are fewer than the ones you will lose by over-explaining on X.

---

Scenario 6: Exchange Delisting

Severity: Medium to High

A tier-1 or tier-2 exchange removes your token. The community interprets this as institutional rejection and a death signal. Price drops. Social sentiment goes negative fast.

Who it involves: Token holders, retail traders, current exchange partners, potential listing targets.

Channels: X from the project account, within 2 hours of the announcement. Telegram and Discord for community-direct. A short blog post with context.

Tone: Matter-of-fact and forward-looking. Explain what happened if you can (compliance update, volume thresholds, strategic decision). Name where the token still trades. Announce any new listings in the pipeline if they are confirmed. What the community needs is confidence that the project continues; give them the facts that justify it.

---

Scenario 7: KOL Betrayal or Token Dump

Severity: Medium to High

A KOL you paid in tokens promotes the project loudly, then dumps their allocation within 72 hours. On-chain analytics surfaces the wallet. The screenshots go everywhere. Your project is now associated with the word "paid shill."

Who it involves: Retail community, other KOL partners (who will be watching how you handle this), journalists, token holders.

Channels: X statement from the project account acknowledging the on-chain facts. Do not defend the KOL. Do not attack them publicly either.

Tone: Honest and clean. Say what the terms of the arrangement were. Say whether they violated them. If there was a lockup agreement and it was broken, state that and note any legal remediation. The community respects founders who name what happened — they don't respect founders who perform ignorance about a wallet that is publicly visible on Etherscan.

Prevention is better than any response: run on-chain wallet checks before committing to any KOL. Token compensation with short lockups is structurally misaligned with your project's interests.

---

Scenario 8: Validator Slashing Event (PoS / Restaking Protocols)

Severity: Medium to High (depends on user exposure)

If your protocol involves staking, restaking, or node operation, a slashing event is a foreseeable risk. A validator misconfiguration, a node provider outage, or a software bug causes slashing. Users lose a percentage of staked assets.

Who it involves: Stakers and delegators with direct financial exposure, node operators, developers who built integrations, auditors.

Channels: Technical status page first (within 30 minutes of confirmation). X thread with plain-English explanation. Discord for affected-user support. Blog post with root cause analysis and remediation plan within 24 hours.

Tone: Technical and accountable. Name the cause as specifically as you know it. State what percentage of stake was affected and what the total user exposure is. If you are compensating affected users, say how and when. Vague reassurance is worse than accurate bad news.

---

Scenario 9: Treasury Concern or Runway Alarm

Severity: Medium to High

A community member, an on-chain analyst, or a journalist notices that your treasury wallet has been declining. They post a thread. The narrative: "This project is going to run out of money." Price drops. Core contributors get DMs asking if they're still employed.

Who it involves: Community, existing investors, potential investors you are approaching, partners with revenue-share arrangements, media covering the beat.

Channels: Governance forum (if applicable) or a project blog post with a transparent treasury breakdown. X thread linking to it. AMA for community Q&A.

Tone: Proactive and specific. Post your runway data before you're forced to. If the runway concern is accurate, say what you're doing to extend it (grants, new funding, product revenue, cost reductions). Silence on a treasury concern reads as confirmation.

---

Scenario 10: DAO Governance Attack or Hostile Vote

Severity: Medium to High

A large token holder or a coordinated group acquires enough voting power to pass a governance proposal that redirects treasury funds, changes protocol parameters, or effectively seizes control. The attack may be partially or fully on-chain before your core team realizes what's happening.

Who it involves: Token holders and delegators, protocol partners, media covering DeFi governance, legal (if funds were misappropriated).

Channels: Governance forum immediately. X for community alert. Blog post with timeline and the team's position within 12 hours.

Tone: Urgent and transparent. Explain what happened, what the current state of the proposal is, and what governance mechanisms exist to respond. If you disagree with the vote, say so clearly and explain the reasoning. Do not go dark on your governance forum while an active attack is unfolding — silence will be read as complicity.

---

Scenario 11: Partnership Collapse or Integration Failure

Severity: Low to Medium

A flagship integration breaks, or a headline partnership falls apart before it delivered anything. The announcement was big; the silence afterward is noticeable. Community members start asking. Someone runs a thread titled "What happened to X?"

Who it involves: Community, integration partners, media who covered the original announcement, investors who cited the partnership in their thesis.

Channels: A brief, honest blog post or X thread. Investor update (private).

Tone: Factual and brief. If the partnership dissolved because of the partner's side (acquisition, product pivot, legal issues), say that with appropriate tact. If it dissolved because of your side, own it. Do not let the narrative sit unanswered for weeks — the community will fill the void.

---

Scenario 12: Founder Personal Controversy

Severity: Variable — potentially Critical

The founder's personal conduct becomes news. A past statement resurfaces. A sexual harassment allegation is made. A public argument on X escalates into a story about the project's culture. A founder from another project calls yours out by name.

Who it involves: Core team, investors, media, community, talent pipeline (anyone thinking of joining watches this closely).

Channels: Depends entirely on whether the conduct is separable from the brand. For most Web3 projects, it is not — the founder is the brand. That makes this scenario more dangerous than it would be at a mature company with institutional identity.

Tone: No improvised X responses. No quote-tweeting allegations with a defensive thread. If the allegation has merit, the response must include concrete action (step-back, third-party review), not just words. If it doesn't, a single, factual statement from the project account followed by silence is better than a running argument. Board or investor calls before anything public.

---

The Infrastructure Behind the Register

The register is only useful if you maintain four operational pieces alongside it:

1. Pre-drafted holding statements. For each scenario, draft a 3-sentence holding statement that can go out within 30 minutes. It acknowledges the situation, confirms you are investigating or responding, and gives a timestamp for the next update. Legal reviews these when nothing is happening — not during the incident.

2. A stakeholder contact tree. Who gets called first, second, and third? Investors before media. Employees before Twitter. Exchanges before community. The tree should have phone numbers, not just email.

3. A channel ownership map. Who posts to X? Who manages Discord? Who briefs journalists? Do not discover during a live incident that three people are drafting conflicting statements.

4. A 90-day rebuild plan template. Most PR thinking about crises stops at the initial response. The rebuild — the earned-media strategy, the governance transparency cadence, the community-trust work — is where reputation is actually repaired. Build a template for it before you need it.

---

How This Differs at Different Stages

Pre-seed / seed. Your risk register is shorter but not nonexistent. Rug pull allegation, co-founder departure, and KOL betrayal are your most likely scenarios. You probably don't have a validator slashing risk yet. Build a 4-scenario register and hold it in a shared doc.

Series A / post-TGE. Every scenario on this list is plausible. You have media relationships that can amplify a crisis and a community large enough to self-organize against you. Build the full register, pre-draft holding statements for all 12 scenarios, and add a named PR contact to the incident response tree.

Mature protocol. Add regulatory risk and governance attack as tier-1 priorities. These are not hypothetical at your scale.

---

The most expensive part of a crisis is not the legal fees or the consultant retainer you call in at 3 a.m. It's the two to four hours of silence at the start, while your team argues about what to say, while the community fills the void with the worst possible interpretation.

The register is the work that buys you those hours back.

If you want a session to map this to your specific architecture and team composition, book a 30-min teardown with Shilika.