Incident Post-Mortem Template for Crypto Hacks
Quick answer. A crypto hack post-mortem needs a summary, a UTC timeline with transaction hashes, the root cause, and funds lost and recovered. Add the response, the fixes, what users must do, and action items with owners.
Video transcript
After a hack, users, integrators and auditors all read your post-mortem. Here is a template for what it should include, and what to hold back.
Publish in stages. Post short factual updates during the incident, then an initial report if the investigation is still open. Publish the full post-mortem once the root cause is confirmed.
The template follows SEAL's format. Open with a summary and a UTC timeline, then the root cause and impact. Cover your response and fixes, what users should do, and action items with owners.
Record every time in UTC and back each row with evidence, usually a transaction hash. Readers will compare your times.
Keep the root cause short. Bunni's fit in one sentence, and it admitted its tests did not cover the scenario.
Cork Protocol, Bunni and Binance all published reports worth copying. Cork shows a timestamped UTC timeline, and Binance says plainly who bears the loss.
Keep it blameless and factual, with one apology. Hold back exploit details while any deployment, including forks, is unpatched, and scrub keys from screenshots.
A short timeline starts with fast detection. Guardian Managed Security monitors contracts on every block, and its global MDR team works to a fifteen minute SLA on Critical alerts.
Read the full template, then talk to Guardian about shortening the timeline in your next post-mortem.
After the war room closes, the post-mortem is what users, integrators and auditors read.
SEAL's incident response template holds the post-mortem meeting within a week of resolution. Every action item needs an owner and a deadline.
Below is a fill-in template, three published reports worth reading, and our advice on tone and what to hold back.
When to Publish
Publish in stages. During the incident, post short factual updates on a fixed schedule. SEAL counts "no new information" as a valid update.
Publish the full post-mortem once the root cause is confirmed. Bunni and Cork both did so while their fixes were still in progress, and said so.
If the investigation is still open, call it an initial report and give the date of the next update.
For scale: Bunni published two days after its exploit, Binance's initial report came five days after, and Cork's post-mortem a week after.
The Template
Copy the headings below and fill in each list. They follow SEAL's post-mortem template, adapted for a public report.
1. Summary
Two to four paragraphs that a reader new to the incident can follow, as SEAL's template puts it.
- What happened, in one plain sentence
- When it started and ended, in UTC
- Funds lost, and who bears the loss
- Status now: paused, patched or resumed
- Report status: initial or final, with its date
2. Timeline (UTC)
One row per event, each with evidence. Record every time in UTC, as SEAL's war room guidelines ask.
| Time (UTC) | Event | Evidence |
|---|---|---|
| [hh:mm] | First exploit transaction | Transaction hash |
| [hh:mm] | First alert, and its source | Alert or log entry |
| [hh:mm] | War room opened; SEAL 911 contacted | Internal log |
| [hh:mm] | Pause, freeze or key revoked | Transaction hash |
| [hh:mm] | First public statement | Link to the post |
| [hh:mm] | Last attacker transaction | Transaction hash |
| [date] | Fix deployed; functions resumed | Transaction hash |
Readers will compare your times. Our study of how fast crypto hacks are detected was built from records like these.
3. Root cause
- The primary cause, in one or two sentences
- Contributing factors: what turned a flaw into a loss
- Why audits, tests or monitoring missed it
- A "5 whys" chain, as in SEAL's template
4. Impact
- Assets lost, by token and chain, with amounts
- Funds frozen, returned or recovered so far
- Users and integrations affected, and for how long
- Who covers the loss, and how
5. Response
- How it was detected, by whom, and how fast
- Containment: pauses, freezes, revoked keys, blocked addresses
- Who helped: SEAL 911, auditors, monitoring vendors, tracing firms
- What went well, what went wrong, and where you got lucky
"Where we got lucky" is a section in SEAL's template, for breaks "we shouldn't rely on next time".
6. Fixes
- The code or configuration change, with a link
- Who reviewed the fix before deployment
- When paused functions resume, and in what order
7. What users should do
- Whether user funds are safe, and how to check
- Exact actions: withdraw, revoke approvals, claim, or "no action needed"
- The official channels for updates
- A warning to approve nothing from sites claiming to be you
8. What changes
- Action items, each with an owner and a deadline
- Runbook, monitoring and alert changes
- Access, key and signer changes
- New audits, bounties or tests
9. Appendix
- Exploit, attacker funding and team transactions
- Attacker addresses and where the funds went
- Affected contract addresses
- A proof of concept, once every affected deployment is patched
Three Reports Worth Reading
| Report | Published | What to copy |
|---|---|---|
| Cork Protocol | June 4, 2025 | A timestamped UTC timeline and an action plan |
| Bunni | September 4, 2025 | A one-line root cause and candor about the fix |
| Binance | November 3, 2026 | An initial report that says who bears the loss |
Cork Protocol
Cork lost 3,761 wstETH from one vault on May 28, 2025.
Its UTC timeline runs from the exploit at 11:39 to a Hypernative notification at 11:43 and the vault pause at 12:33.
Separate sections cover communications, lessons learned and an action plan. Its timeline also records contacting the Uniswap Foundation about the hook and responsible disclosure.
Bunni
Bunni lost about $8.4M on September 2, 2025, and linked the exploit transactions in its opening lines.
Its root cause fits in one sentence: "A rounding direction that's safe in the context of a single operation may not be safe in the context of multiple operations."
It is candid about limits. Its tests "did not cover the scenario", and it says it is unclear whether the rounding fix introduces new attack vectors.
Binance
Binance's November 3, 2026 report on its October 29 incident calls itself "our initial report". It gives UTC times for the drain.
It states plainly: "Binance will absorb the financial impact of the stolen funds, not our users."
It holds back what would help attackers, keeping "some technical details" confidential. Staff appear only as Engineers A, B and C, and for attribution it cites the FBI.
For exchange-specific steps, see our crypto exchange incident response plan.
Tone and What Not to Publish
Tone
- Confirmed facts only. Label what is still under investigation.
- No blame: not individuals, third parties or users, as SEAL advises.
- One apology is enough, as SEAL's communications template puts it.
- Plain words: many readers are users, not engineers.
- Every number with its evidence: a hash, an amount, a time.
What not to publish
SEAL's incident response policy defaults to sharing post-mortems publicly, "redacting sensitive details". Our advice on what to hold back:
- Exploit details or a proof of concept while any affected deployment, including forks, is unpatched
- Security measures that only work while private
- Names and personal details of staff
- A bug others share, before they have been told
- Secrets in screenshots and logs: keys, tokens, internal URLs
- Attribution you cannot source; cite investigators or law enforcement
How Guardian Helps
A short timeline starts with fast detection. Guardian Managed Security monitors your contracts on every block, and a Guardian engineer responds when something fires.
The global 24/7 MDR team works to a 15-minute SLA on Critical alerts.
When the fix ships, Guardian's security operations team reviews every deployment and configuration change as it lands.
Write the plan before you need the post-mortem: see our DeFi incident response plan.
Frequently Asked Questions
What should a crypto hack post-mortem include?
A summary, a UTC timeline with transaction hashes, the root cause and contributing factors, and funds lost and recovered. Then the response, the fixes, what users must do, action items with owners, and an appendix of transactions and addresses.
How soon should you publish a post-mortem?
Post short factual updates during the incident. Publish the full post-mortem once the root cause is confirmed: Bunni took two days, Cork a week, both before their fixes were final. If the investigation is still open, publish an initial report.
Should a post-mortem name the people responsible?
No. SEAL's template asks for a blameless review that focuses on learning. Describe the process that failed, not the person. Binance's initial report refers to the affected staff only as Engineers A, B and C.
Should you publish the proof of concept?
Only once every affected deployment, including forks and integrations, is patched, and after warning others who share the bug. Until then, publish enough for users and integrators to judge their exposure.
Sources
- SEAL Frameworks: Post-Mortem Template
- SEAL Frameworks: Incident Response Policy
- SEAL Frameworks: Lessons Learned
- SEAL Frameworks: Incident Response Template, Communications
- SEAL Frameworks: Communication Strategies
- SEAL Frameworks: SEAL 911 War Room Guidelines
- Cork Protocol: Post-mortem (June 4, 2025)
- Bunni: Exploit Post Mortem (September 4, 2025)
- Binance: 29 October 2026 Binance Security Incident, Initial Findings and Response Update (November 3, 2026)
- Guardian: Managed Security
- Guardian: How Fast Are Crypto Hacks Detected? Data From 30 Exploits
Shorten the timeline in your next post-mortem
Guardian Managed Security monitors your contracts on every block, with an engineer on every alert and a 15-minute SLA on Critical alerts.