Every project in this category has a bad hour eventually. An exploit, an outage, a withdrawal queue that stops moving, a key person leaving abruptly.
The incident is rarely what damages a project. The silence afterwards is.
The first hour decides the next month
There is a window at the start of an incident where your community is worried but not yet angry. In that window, a short, honest, imperfect statement does more than a polished one six hours later.
The first message does not need answers. It needs three things:
- Confirmation that you know — the single most reassuring thing you can say.
- What you are doing right now, even if that is investigating.
- When you will update next, and then actually doing it.
What fills the gap otherwise is speculation, and speculation is always worse than the truth. By the time you arrive with facts, the narrative has set and you are arguing against it rather than establishing it.
Acknowledge fast, detail carefully
These are different commitments and teams conflate them.
Acknowledge immediately. Detail once you understand what happened and once disclosing the mechanism will not help someone repeat it.
The rule that matters most: never state something you are not certain of. A correction costs far more credibility than an initial absence of detail. “We are still determining the cause” is a completely acceptable sentence. A wrong cause confidently stated is not.
One voice
Multiple people communicating during an incident produce contradictions, and contradictions are read as either incompetence or concealment.
Pick one named person — usually the founder or the most senior technical leader. Everything public comes from them or is explicitly attributed to them. Community managers route questions to that source rather than improvising under pressure, which is a genuinely difficult instruction to follow when a channel is on fire and worth rehearsing.
Prepare the scenarios you can foresee
You cannot predict the specific incident. You can predict its category.
For most crypto and fintech products the foreseeable set is short: a contract exploit, an infrastructure outage, a withdrawal delay, a partner or vendor failure, a security disclosure, a senior departure.
For each, draft a holding statement now. Not a full response — a first message that acknowledges, states what you are doing and commits to an update. Having those drafted removes the worst hour of an incident, which is the one spent arguing about wording while the community waits.
Decide who decides
The question that stalls real incidents is not what to say. It is who is allowed to say it.
Before anything happens, settle: who authorises a public statement, who can halt withdrawals or pause a contract, who speaks to press, who wakes whom at 3am, and what happens when the person who normally decides is unreachable.
Write it down. Then rehearse it.
The rehearsal is the artefact
Most projects have a crisis plan. Very few have run one.
Running it as a drill reveals what a document never will: that the on-call engineer cannot actually reach the circuit breaker, that nobody knows who authorises a halt, that the holding statement assumes facts you will not have for two hours, that the legal reviewer is in a different time zone.
Every one of those is cheap to fix in a drill and expensive to discover live.
After it is over
The post-incident write-up is worth more than the incident cost you, if it is honest.
What happened, why, what you have changed, and what you would do differently. Published, in your own words, with the uncomfortable parts included.
Projects that do this well come out with more trust than they started with, because they have demonstrated something no marketing can: that they tell you the truth when it is inconvenient.
Common questions
What should a crypto project do first during a crisis?
Acknowledge it publicly, quickly, even before you have the full picture. The first message does not need answers - it needs to confirm you know, state what you are doing, and say when you will update next. Silence in the first hours is what turns an incident into a reputational event, because the community fills the gap with speculation that is always worse than the truth.
How do you prepare for a crypto crisis before it happens?
Draft holding statements for the scenarios you can actually foresee, name a single point of contact for press, define who authorises a public statement and who can halt withdrawals, and then rehearse it as a drill. The rehearsal is the part most teams skip and the part that matters, because it reveals that nobody actually knows who makes the call.
Should you disclose the full details of an exploit immediately?
Acknowledge immediately, detail carefully. The first statement confirms what is happening and what you are doing. Technical specifics can follow once you understand them and once disclosing them will not help anyone repeat the attack. What you must not do is state things that turn out to be wrong, because a correction costs far more credibility than an initial gap in detail.
Who should speak for a project during a crisis?
One named person, usually the founder or the most senior technical leader, communicating consistently across every channel. Multiple voices produce contradictions, and contradictions during an incident are read as either incompetence or concealment. Community managers should route questions to the single source rather than improvising answers under pressure.
Does Corum8 handle crisis communications?
Yes. We build crisis readiness before it is needed - scenario statements, escalation paths, spokesperson preparation and a rehearsal - and we run the communications during an incident across press, community and social. Corum8 has been running PR and community for crypto and fintech since 2016.
