When something goes wrong on-chain, the difference between a recoverable incident and a project-ending one is usually decided in the first hour. The teams that survive have rehearsed; the teams that improvise lose more value to the response than to the original exploit.
This piece is the first-hour playbook we run when we are paged for an Incident Response engagement. Not every step applies to every incident, but every step exists because we have seen it skipped and regretted.
Minute 0 to 5: Confirm and contain
The first instinct is always to communicate. The right instinct is to stop the bleeding.
Confirm the exploit is real, not a false alarm. A spike in withdrawals can be a panic, not an exploit. A funny-looking transaction can be MEV, not a drain. Look at the on-chain trace. Identify the function being called, the address calling it, and what value is leaving the protocol.
Pause if you can pause. Most well-designed protocols have an emergency pause function held by a multi-sig or a guardian. This is the moment it earns its keep. Get the threshold of signers on a call and execute the pause. Every block of delay is more value out the door.
Revoke if you cannot pause. If a wallet's been compromised, revoke active token approvals from that wallet, but only after the wallet's remaining assets have been moved to a clean address, because revocations cost gas and a drainer often racing transactions.
If your team does not know who has the authority to pause, who holds the keys, and how fast you can assemble the threshold, you do not yet have an incident response posture. We address that during a Wallet Setup engagement, before the first incident.
Minute 5 to 15: Assemble the team
A standing list of who you call when an incident happens is worth more than any tool.
The internal team:
- Engineering lead (technical assessment).
- Communications lead (drafts the first post).
- Legal counsel (if applicable jurisdiction).
- A board or investor representative (notification, not approval).
The external team:
- Your incident-response firm. (If you do not have one on retainer, this is the moment you wish you did. Emergency engagements are accepted when capacity allows but cost more and respond slower.)
- Counsel familiar with crypto-specific incident-response procedures.
- Your auditor (they may have context on the affected contracts).
The list lives in a shared document with phone numbers, not just emails. Email response times are not incident-response times.
Minute 15 to 30: Trace and document
Two activities run in parallel.
On-chain forensics:
- Identify the attacker address(es) and write them down.
- Trace the stolen funds. Where did they go in the first hop? The second?
- Identify whether funds went into Tornado, Railgun, a centralized exchange, a bridge, or a dormant address.
- Note any addresses that were funded by the same source as the attacker, they may be operational accounts of the same actor.
This trace becomes the foundation of any recovery, any law-enforcement engagement, and any insurance claim. Get it right early.
Internal documentation:
- Open an incident channel. Restrict access. All decisions go through it.
- Start a timeline. Who did what at what time. This document will be the basis of the post-mortem.
- Take screenshots of the on-chain state at the moment of the incident. State changes after this point.
Minute 30 to 45: Communicate
The first communication has three properties: it is honest, it is brief, and it does not commit to anything you cannot deliver.
A first post says: we are aware of an incident affecting [scope]. We have [actions taken]. We are investigating. The protocol is [paused / not paused]. Users should [specific actions, e.g., revoke approvals, do not interact with the front-end]. Updates will be posted here every [X] minutes.
That is it. No "we are confident", no "no funds are at risk" until you actually know. Bad communication turns a survivable incident into an unsurvivable one, usually because someone said something definitive that turned out to be wrong.
In our Incident Response engagement we draft these posts, the team approves and publishes. The drafting is tactical; the approving is yours.
Minute 45 to 60: Reach out
The recovery options outside your protocol now matter.
Centralized exchanges. If funds went to a CEX, they may freeze on request, if you reach the right person before the attacker withdraws to fiat. Most major exchanges have law-enforcement and security desks; reach them through your incident-response partner if you don't have a direct line.
Stablecoin issuers. USDC and USDT can blacklist addresses on request. Tether is faster than Circle in our experience, but both have process. The earlier you reach them, the better the outcome.
Bridges. Some bridges have emergency pause capability and are willing to use it. Others do not.
Mixers and privacy tools. Once funds enter Tornado Cash or similar, recovery options narrow but do not vanish. The trace remains useful for downstream actions.
Other protocols affected. If your incident has spillover risk to other protocols (say, you are the oracle source for someone), notify them. They will return the favor when the situation reverses.
Hours 1 to 24: Stabilize
Past the first hour, the work shifts:
- A more thorough on-chain trace, often crossing chains and mixers.
- A second public post with confirmed details, what happened, what was lost, what the immediate plan is.
- Engagement with law enforcement, where applicable. The trace document is the input.
- Initial decisions on remediation: hard fork, rollback, treasury reimbursement, governance vote.
These are governance decisions, not technical ones, and they are where projects most often make their reputation in the long run. A protocol that loses 10% of TVL but handles it transparently can recover trust. A protocol that loses 10% of TVL and lies about it does not.
What you need before the incident
You cannot draft a first-hour playbook in the first hour. You need it written before. The minimum:
- A pause path held by a multi-sig with documented signers.
- A signing rota, at least one signer awake in every major time zone.
- An incident contact list, internal and external, with phone numbers.
- A drafted "we are aware" template that just needs the specifics filled in.
- A retainer with an incident-response firm so the trace and the comms support start immediately, not after a sales call.
For DeFi protocols, exchanges, and DAO treasuries, this preparation is part of the cost of operating. It is significantly cheaper than not having it.
What we do, specifically
When a client pages us:
- Live incident commander on a call within the SLA.
- On-chain forensics running in parallel with the call.
- Drafted communications passed back to your team for approval.
- Coordination with exchanges, custodians, and counsel.
- A written post-mortem at the end, plus an internal lessons-learned document.
The first hour is the hardest. The work after is where the project's reputation is earned back. Both are easier with a team that has done this before.