How to Build a DeFi Incident Checklist
A calm response sequence for suspicious approvals, unexpected transfers and compromised interfaces.
This article may contain affiliate links. Commercial relationships are disclosed in the affiliate policy.
A DeFi incident checklist is not a document you write once. It is a short list you rehearse before you need it, because the first hour after an exploit is the only hour where a pre-written decision beats an improvised one.
What a DeFi incident checklist has to cover
The four facts you cannot afford to be unsure about. Which protocol and which chain. Which contract address. The block number or timestamp where the loss occurred. The transaction hash that started it. Every later decision — pause, move funds, warn users, publish an update — depends on these four being right. If a forum post gives you an address without a block explorer link, it does not count as a source.
Who pulls which lever. In practice one person moves funds, one person handles communication, and one person keeps the evidence log. If those are all you, say so explicitly in the checklist, because the failure mode of a solo operator is doing three things badly and none of them well.
What is reversible and what is not. A bridge deposit can sometimes be paused. A token approval already granted cannot be pulled back by you; only the counterparty can revoke it. A swap that has executed is final. Write these down beforehand so you are not deciding under pressure.
The order that actually works
- Stop the bleeding before investigating. If funds are still moving, wallet revocation and position exit come before root-cause analysis. Understanding an exploit while your own position drains is the wrong order.
- Capture evidence before anything changes. Export transaction logs, save the block explorer pages, screenshot the current state of the interface. Interfaces get deprecated and pages get edited.
- Then reconstruct. Follow the attacker addresses forward, not backward, to see where the funds went. A write-up that does not name a destination address has not told you anything you can act on.
- Decide what you publish and when. A holding statement that says “we are investigating, the affected contract is X, funds are not at risk” costs you little and buys you credibility for the harder message later.
The part people get wrong
Almost every team treats this as a post-mortem document and writes it afterwards. The value is entirely in the rehearsal. A checklist written during an incident encodes exactly the wrong knowledge, because you already know what happened. The checklist is worth writing on a quiet afternoon when the most recent thing that happened is nothing.
How to know your checklist is real
Test it against a scenario that is not your protocol’s usual failure mode. Consider a loss that happened through a governance vote rather than a bug, or a freeze that affected withdrawals only, or an oracle that was correct and still led to a bad settlement. If your list has a blank line for any of those, the rehearsal is incomplete.
Limits of this checklist
This covers self-custody and application-level incidents. It does not cover losses on a centralised exchange’s own books, issues with a hardware wallet supply chain, or anything involving a legal claim, where the relevant next step is a lawyer or a regulator rather than a block explorer. It is also not a security audit: nothing here tells you whether a contract contains a reentrancy bug.