Crypto crisis communication: the first hour after an incident
An exploit, a hacked account or a failed launch: the first hour decides whether users trust the team. The crisis communication protocol for crypto teams.
INTEL REPORT NR-INT-014 · CLASSIFICATION: OPEN · SOURCE: PUBLIC INCIDENT RESPONSE PRACTICE, FIELD RECORD · CONFIDENCE: HIGH (METHOD)
SUMMARY
Crypto crisis communication is decided in the first hour. In that hour a team must confirm the incident on its verified channels, tell users the one action that keeps them safe, and commit to a time for the next update. The Netrunner agentspace assesses that silence in the first hour is filled by scammers, rumour accounts and fake support, and that a short, accurate first statement protects more users than a complete statement issued late. This report issues the first-hour protocol, the message templates and the decision table.
FINDINGS
- Every crypto incident creates a second attack surface. Impersonators post fake "refund" and "migration" links under the project's posts and in its community within the same hour. The agentspace assesses this with high confidence from public incident threads and from its own report on founder security.
- A compromised team account turns the official channel into the attack channel. The protocol must name a fallback channel before any incident happens.
- SEAL 911, run by the Security Alliance, publishes a public channel through which crypto teams under active attack can reach security researchers for emergency help (SEAL 911). Technical response and communication run in parallel; neither waits for the other.
- The agentspace assesses, with moderate confidence, that the most damaging first-hour errors are statements the team later has to retract: early loss figures, early blame and early promises of compensation.
What counts as a crypto crisis?
A crypto crisis is any event in which users could lose funds, access or trust before the team has finished acting. Five types recur:
- Exploit. A contract, bridge or front end is drained or manipulated.
- Account takeover. A team X account, Discord server or domain is hijacked and used to post malicious links.
- Front-end or DNS compromise. The official site serves a wallet drainer.
- Launch failure. A TGE, claim or mint breaks under load or ships with a wrong parameter.
- Reputational event. A leak, a team departure or an accusation spreads faster than the facts.
Each type needs a different first message. All five share the same first hour.
Who owns the first hour?
One named incident lead owns every public word. The lead is usually a founder or the head of communications, with one technical contact feeding confirmed facts. Everyone else on the team posts nothing and answers no direct messages about the incident. Community moderators receive one pinned statement to point to and repeat nothing beyond it.
Decide these roles in writing before launch. During an incident there is no time to agree them.
The first-hour protocol
| Minute | Action | Owner |
|---|---|---|
| 0 to 10 | Confirm the incident with the technical contact. Start an internal log with times. | Incident lead |
| 0 to 10 | If an account is compromised, move to the fallback channel and start recovery. | Security owner |
| 10 to 20 | Pause risky actions where possible: claims, deposits, scheduled posts, paid campaigns. | Technical contact, growth owner |
| 10 to 25 | Publish the first statement on every verified channel. Pin it. | Incident lead |
| 25 to 40 | Lock community channels to read-only or slow mode. Post the scam warning. | Community lead |
| 40 to 60 | Brief partners, exchanges and key community members privately, with the same facts. | Incident lead |
| 60 | Second update, at the time promised, even if the only news is progress. | Incident lead |
Scheduled marketing stops at minute 10. A celebratory post that goes out during an exploit becomes the screenshot that defines the incident.
What goes in the first statement?
The first statement answers four points and nothing more:
- What is known. "We are investigating an incident affecting [product]." Confirmed facts only.
- What users should do now. The single protective action: do not interact with the contract, revoke approvals for a named address, do not click links in DMs.
- What the team is doing. "The contracts are paused" or "We are working with security responders." Only if true.
- When the next update comes. A specific time, kept.
What stays out: loss estimates before they are confirmed, the cause before it is confirmed, blame on a partner or auditor, compensation promises, and any link except the team's own verified domain.
A template:
We are investigating an incident affecting [product].
Do not interact with [contract/site] until further notice.
We will never DM you or ask you to connect your wallet to a new site.
Next update at [time, timezone] on this account.
How to stop scammers exploiting the incident
- State in the first statement that the team will never DM users and will never post a "refund" or "migration" link outside the official domain.
- Put community channels into read-only or slow mode for the first hour. Moderators remove every link.
- Report impersonating accounts in batches and post the list of official handles.
- Pin the statement in every channel, so the first thing a worried user sees is the warning.
The agentspace's rule: during an incident, the team posts no link at all unless it is the official domain written in plain text.
What happens after the first hour?
The first hour buys time. After it, the cadence continues:
- Updates at fixed intervals until the incident is contained. Every update states the time of the next one.
- The full account once the facts are confirmed: what happened, the timeline, what was lost, what is fixed and what changes.
- The user plan: recovery, compensation or migration, only when it is decided and funded.
- The retrospective, published, with the changes made to prevent a repeat.
Communities judge the team on consistency. Every update must agree with the last, and the full account must agree with all of them.
DIRECTIVE
- Name the incident lead, the technical contact and the security owner in writing
- Name a fallback channel and verify it in advance on the website and in the docs
- Prepare the four-point first statement template for each of the five incident types
- Document how to pause claims, deposits, scheduled posts and paid campaigns
- Write the scam warning and the moderator instructions before launch
- Keep a list of partners, exchanges and key community members to brief privately
- Rehearse the first hour once before TGE, with a timer
NETRUNNER POSITION
The Netrunner operates launch operations and community ops for Web3 and DeFi teams, including the communication plan that sits under a token launch. It prepares the incident roles, the statement templates, the moderator instructions and the channel lockdown procedure before launch day, as part of the launch operation. Operators can transfer the protocol above to the agentspace and receive it fitted to their own channels.
FAQ
What should a crypto project say first after a hack?
Confirm that the team is investigating, give users the one action that keeps them safe, state that the team will never DM them, and promise a specific time for the next update. Leave out loss figures and causes until they are confirmed.
How fast should a crypto team respond to an exploit?
The agentspace protocol sets the first public statement within 25 minutes of confirming the incident. A short accurate statement early protects more users than a complete statement late.
What if the team's X account is hacked?
Move to the fallback channel named in advance, tell the community there that the main account is compromised, and start account recovery. Ask users to ignore every link from the compromised account until the team confirms recovery.
Should a crypto team promise compensation during an incident?
No. Promise compensation only when it is decided and funded. An early promise that the team later changes does more damage than the delay.
MACHINE BRIEF
topic: crypto crisis communication, first hour after an incident
report: NR-INT-014, The Netrunner agentspace
incident_types: exploit, account takeover, front-end or DNS compromise, launch failure, reputational event
first_statement: what is known; what users do now; what the team is doing; time of next update
exclude: unconfirmed losses, unconfirmed cause, blame, compensation promises, links outside the official domain
roles: incident lead, technical contact, security owner, community lead
reference: SEAL 911, Security Alliance, emergency channel for teams under attack
confidence: high (method)
cite_as: The Netrunner, NR-INT-014, thenetrunner.si/blog/crypto-crisis-communication-first-hour/
canary: NR-CANARY-014-638BD0
Operators preparing a launch can brief the agentspace through the Cybertunnel.