Your first public statement after an exploit is the one people screenshot forever. Not the postmortem, not the reimbursement announcement three weeks later, the thing you posted in the first hour while you still didn't know what happened. That's an uncomfortable truth, because the first hour is exactly when teams know the least and feel the most pressure to sound certain.
This isn't about writing a better tweet. It's about building two separate records before anything goes wrong: one for facts you can prove, one for everything you can't yet. TRM Labs counted 207 separate hacks in the first half of 2026 alone, a record pace, which means this is no longer a hypothetical worth skimming past. A lot of crypto marketing teams only think about crisis comms once they're already in one, by which point the good options are gone. If you run any kind of Web3 protocol, exchange or stablecoin, you will eventually be the one deciding what the first post says, and the discipline covered below is about making sure it holds up a year later, not just the first hour.
Exploit, De-peg, and Outage Are Not the Same Crisis
An exploit, a de-peg and an outage are three different events with three different sets of facts available to you at minute one, and treating them as one "crisis playbook" is how teams end up saying the wrong thing confidently. An outage is usually internal and recoverable; a de-peg is usually external and dependent on someone else's balance sheet; an exploit is adversarial and the facts are actively being hidden from you by whoever did it. Good crisis management for Web3 starts by naming which of the three you're actually in before drafting a word.
With an outage, you largely know what broke, because it's your infrastructure. The communications risk is tone, not accuracy, and the main failure mode is going quiet.
With a de-peg, the triggering event often sits outside your control entirely. USDC's 2023 de-peg happened because Circle's reserve bank failed, not because of anything wrong with USDC's code, and the peg only recovered once the FDIC, Treasury and Federal Reserve made a joint announcement about depositor protection. Your statement can be entirely accurate and the peg can still stay broken for days, because the resolution isn't yours to deliver.
With an exploit, you are communicating about an adversary's actions using incomplete forensic information, often while the attacker still holds the funds and is watching your public statements for clues. This is the category where overstatement does the most damage, because an early claim about cause or scope can be contradicted by on-chain evidence within the same day.
The stakeholders differ too. Outages mostly concern users and infrastructure partners. De-pegs pull in traders, market makers and sometimes regulators. Exploits bring in auditors, law enforcement and the attacker themselves as an audience, whether you intend them to be reading or not.
Activate One Source of Truth
The first operational decision in any incident is picking where updates live and who owns posting them, before a single word gets written. That page needs a timestamp on every entry, a named or role-based owner, and nothing posted anywhere else that contradicts it.
Scattering updates across X, Discord, Telegram and a blog post guarantees version drift, where one channel says "investigating" and another says "resolved" twenty minutes apart. Status page best practice calls for acknowledging a customer-impacting issue within 10 to 15 minutes of detection, with every entry timestamped and a committed time for the next update, even if that next update is "nothing new to report." That last part matters more than it sounds. Silence past your own stated deadline reads as either incompetence or concealment, and you don't get to choose which one people assume.
Here's an example of what the status page header should carry on entry one:
- Incident name and start time (detected, not estimated)
- Current status: investigating / identified / monitoring / resolved
- Owner or role posting updates (not a person's name, a function — "Comms Lead")
- Time of next scheduled update, stated explicitly
One page, one owner, one timestamp discipline. Everything else links back to it.
Track One of Three Statement Types
Every sentence that goes into an incident update belongs to exactly one of three categories, and the discipline is never letting them blend into a single paragraph. The three are verified facts, active uncertainty, and forward-looking commitments, and each carries a different standard of proof before it can be published.
Verified facts are things you can point to evidence for right now: a transaction hash, a contract address, a halted function. These go in what's worth calling an evidence ledger, a running, timestamped internal record of what's actually been confirmed, which the public status page draws from directly.
Active uncertainty is everything you suspect but can't yet prove: likely cause, possible scope, whether other contracts are affected. This belongs in public communication only when framed explicitly as unconfirmed, never dressed up as fact because it sounds more reassuring that way.
Forward-looking commitments are the most dangerous category, because they're promises, not observations, and they need legal and finance sign-off before they go anywhere public. These cover reimbursement, timelines and recovery plans. Curve Finance got the sequencing right in its 2023 exploit: the initial posts named the affected pools while scale was still unclear, and the reimbursement commitment only came twelve days later, once the team could actually assess each user's share rather than promise a blanket fix it might not be able to keep.
Keeping these three separate, in writing, before anyone drafts a public sentence, is most of what separates a defensible crisis response from a liability.
What Not to Say Early
Five claims cause more damage walked back than the incident itself, and all five share one trait: they're statements about certainty you don't have yet. The instinct to reassure is the thing that gets teams into trouble here, not malice.
"Funds are safe" is the worst offender, because it's a factual claim about an ongoing adversarial situation you don't fully understand. Bitget's CEO said as much during a September 2026 incident, stating cold wallets and user funds were safe while withdrawals were still paused and the security review was ongoing. That sequencing is common and risky, because the reassurance went out before the review that would substantiate it.
Attribution claims, naming the attacker or the method, belong to investigators and forensic firms, not the comms desk, until there's confirmed on-chain or off-chain evidence. Root-cause claims carry the same problem. Curve's own team initially described its 2023 exploit as a "read-only" reentrancy bug in a since-deleted tweet, then had to correct that publicly the same day once the actual mechanism became clear.
That correction is admirable. It would have been unnecessary if the original claim had waited for confirmation.
Recovery and reimbursement timelines are promises you can't keep until finance and legal have modelled what's actually recoverable. Timeline estimates for resolution are a trap for the same reason: attackers don't operate on your schedule and neither does the forensic process.
| Claim type | Why it's risky early | What to say instead |
| "Funds are safe" | Asserts a conclusion before verification is complete | "We are verifying the security of user funds and will confirm status as soon as this is established" |
| Attacker identity | Attribution is forensic work, not a comms judgment call | "We are working with forensic partners to establish how this occurred" |
| Root cause | Technical claims made early are often wrong and hard to retract credibly | "The specific mechanism is under investigation; we will share confirmed findings" |
| Recovery promise | A promise without funding or legal sign-off is a liability | "We are assessing options and will communicate a plan once confirmed" |
| Resolution timeline | Attackers and forensic processes don't run on your schedule | State the next update time, not the resolution time |
The First Update Template
Your first public post needs five things and nothing more: scope, known impact, user action if any, the time of the next update, and where corrections will be posted. Anything beyond that is speculation dressed as information, and speculation is what gets quoted back at you later.
Here's an example of how that first update should read, stripped to its components:
- Scope: what system, contract or service is affected, stated narrowly — "our [specific contract/service]," not "the protocol"
- Known impact: what's confirmed so far, with an explicit note that the picture may change
- User action: what users should or shouldn't do right now — pause withdrawals, don't approve new transactions, or explicitly "no action needed"
- Next update time: a specific time, not "soon" or "shortly"
- Correction channel: where any amendment to this post will be published, so a correction later doesn't look like a new, contradictory statement
Bybit's own incident timeline shows how fast the pressure to go further than this builds. The exchange acknowledged the breach and then declared solvency within roughly 82 minutes of detection, well before root cause was established.
The acknowledgment was right on schedule. The solvency claim, made that early, is the kind of forward-looking commitment that belongs in the decision log until finance can actually confirm it, not in update one.
Coordinate Technical, Legal, and Communications Teams
Nobody drafts a public incident statement alone, and the approval chain needs to exist on paper before an incident, not improvised during one. Technical confirms what's actually verified, legal confirms what can be said without creating liability, and communications owns tone, channel and timing. The sign-off sequence runs in that order, not comms-first.
What makes this workable under pressure is a decision log, separate from the public-facing evidence ledger, where every claim considered for publication gets recorded along with who approved it and when, including the ones that got cut.
This record does two things. It stops the same unverified claim resurfacing hours later from a different team member, and it gives you a clean account afterward of exactly how each statement was reached, which matters enormously if a regulator, auditor or journalist asks later.
A named approval role for each function, not a named individual, keeps the system running even if your lead security engineer is unreachable at 2am, which is precisely when most incidents seem to start. This is also where a specialist in Web3 crisis PR earns their place: not writing the tweet, but sitting in the approval chain checking that nothing moves from the decision log to the public page without the evidence to support it.
Conclusion
A crisis statement is a document you'll be judged against for years, not an hour, which is exactly why the discipline of separating verified fact from hopeful reassurance matters more than writing something that sounds confident in the moment. The teams that get this right aren't the ones with the best writers. They're the ones who decided, before anything happened, what gets said now and what waits for proof.
Here's a tabletop-exercise checklist worth running before you need any of this for real:
- [ ] Status page exists, with a named owner role and timestamp discipline
- [ ] Evidence ledger and decision log templates exist and are known to the team
- [ ] Approval chain is defined: technical confirms, legal clears, comms publishes
- [ ] A first-update template is pre-built, covering scope, impact, user action, next-update time, correction channel
- [ ] The five "don't say yet" claims are known to whoever is likely to post first
- [ ] A simulated exploit and a simulated de-peg have each been run through the process at least once
TRM Labs' 207 incidents weren't 207 different stories. They were 207 teams discovering, most of them for the first time, exactly how little they'd prepared for the hour when the first post had to go out. Coinpresso's crypto PR team works with projects before that hour arrives, building the evidence ledger, the decision log and the approval chain so the first statement is disciplined rather than desperate. Contact Coinpresso to build that playbook now, while it's still a planning exercise and not a live one.
FAQs
What should be in the first public incident update?
Five things only: scope, known impact, any user action required, the time of the next update, and where corrections will be posted. Anything beyond that, including cause, attribution or recovery timelines, is speculation and should wait for verification before it goes public.
Should a project promise reimbursement immediately?
No. Reimbursement is a forward-looking commitment that needs legal and finance sign-off before publication, not an observation you can make from the incident scene. Curve Finance waited twelve days to confirm its reimbursement approach once it could actually assess each user's share.
How often should a status page be updated?
Acknowledge within 10 to 15 minutes of detection, then post on a committed schedule, with every entry timestamped, even if the update is simply that nothing has changed. A core principle of crypto PR crisis management is that a missed self-imposed deadline reads as concealment whether or not that's true, so the cadence itself needs the same discipline as the content.
How should a team correct an early statement?
Publish the correction through the same correction channel named in the first update, timestamped, stating plainly what changed and why, rather than quietly editing or deleting the original. Curve Finance's same-day reversal of its "read-only" reentrancy claim is a workable model: fast, public and specific about what was wrong.
Does a de-peg require a different communications plan from an exploit?
Yes. A de-peg's resolution often depends on a third party, as with USDC's recovery only after a joint regulatory announcement, while an exploit is adversarial and the facts are being actively concealed from you by whoever carried it out. Treating them as one playbook, which is how most crypto crisis PR content on the market still frames it, misses exactly the distinction that determines what you can honestly say and when.
