The attacker has already finished when you find out. By the time a monitoring alert fires, a user posts a screenshot, or a security researcher sends a direct message, the exploit transaction is confirmed, the funds are in an address you have never seen, and a script is probably already swapping them for assets that are harder to freeze. From here, the attacker's job is to launder and the defender's job is to limit what else can be lost. Everything that happens in the next 24 hours determines whether the incident is a bad day or the end of the protocol.
Teams that have rehearsed behave very differently from teams that have not. The rehearsed team knows who can pause, has the signers awake within minutes, preserves the evidence, and speaks to users before the speculation hardens. The unrehearsed team spends its first hour arguing about whether it is really a hack and its second hour looking for the hardware wallet. This article is for founders, engineering leads and the people who will be on the call. It walks through a realistic first day, the decisions that cannot wait, and the ones that should.
Hour zero: contain
The first fifteen minutes decide the size of the loss. The only questions that matter are whether the attack is still possible and how to stop it.
Confirm and assemble
Confirm that the event is real by looking at the chain, not at Twitter. One engineer pulls the suspicious transactions, identifies the contract and function involved, and checks whether the attacker's address is still active. At the same time, a single person opens the war room, a private channel on a platform that is not the team's compromised one if there is any doubt, and pages everyone who can sign.
The roles should be assigned before the incident, and the first act in the war room is to confirm who holds them tonight. An incident lead makes decisions and is the only person who can authorise external statements. A technical lead directs the investigation. A signer coordinator reaches the multisig members and tracks who is online. A communications lead drafts and publishes. A scribe records every decision with a timestamp, because the record will matter later. In a small team people hold several roles, but every role must have a name.
The pause decision
If the protocol has a pause or a kill switch, the question is whether to use it, and the answer is usually yes, within minutes, before the full picture is known. The trade-offs are real: pausing can strand user funds, halt liquidations and create bad debt, trigger integrations that depend on the protocol, and tell the attacker you have noticed. Not pausing lets a repeatable exploit be repeated, by the original attacker or by anyone who reads the transaction. Where the pause is granular, pause the affected component and the deposit path first, and keep withdrawals open if the exploit does not run through them.
The failure mode we see most often is a pause that exists on paper but cannot be executed in time because the signers are asleep, the threshold is too high, or nobody remembers which address holds the role. If reaching it takes longer than draining the rest, the switch is decoration.
Protect what is left
Beyond pausing, containment includes rotating any key that may be involved, taking down a compromised front-end, moving remaining funds to a safe address if the contracts allow it and the team is certain of the receiving address, and warning integrators whose contracts read from yours.
Hours one to four: assess what, how, and how much
With the bleeding stopped, the investigation starts, and it should be deliberate rather than frantic.
The technical lead reconstructs the exploit transaction by transaction: the entry point, the sequence of calls, the state before and after, and the precise reason the code did what it did. A forked-chain replay of the attack is the fastest way to be sure. The output is a written root cause that another engineer can verify, because speculation that gets published and later corrected damages trust more than silence.
Evidence preservation runs in parallel. Snapshot every server, log and database that may be relevant, including the front-end deployment history and DNS records if a phishing or supply-chain vector is possible. Export chat logs from the relevant channels. Record the attacker's addresses, every transaction hash, and the timeline as it is established. Do not wipe or rebuild compromised infrastructure before it has been imaged; the urge to clean up destroys the material a later investigation needs.
Quantify the loss precisely: which assets, how much of each, from which contracts, belonging to which users. The number will be public within hours whether or not you publish it, and a team that states it accurately is believed on everything else.
Hours two to twelve: trace the funds
Tracing begins as soon as the attacker's addresses are known, and the clock matters because the attacker's laundering is already underway.
Follow the funds across bridges, swaps and mixers; analytics firms will assist a victim protocol at short notice. The aim is to identify any point where the assets touch a party that can freeze them. Centralised exchanges can freeze deposits from flagged addresses if they are told in time, which means before the attacker withdraws. Stablecoin issuers can blacklist addresses holding their tokens, and most have a documented process for law-enforcement and victim requests. Every minute between identification and the request is a minute in which the funds move on.
Prepare the request properly: transaction hashes, addresses, a short description of the incident, and a contact who can answer questions. Send it through the exchange's security or compliance channel rather than general support, and follow up through any personal contact the team or its advisers have.
Talking to the attacker
Many incidents end with a negotiated return, and the negotiation starts with an on-chain message to the attacker's address. The message should be short, factual and unemotional: an offer to treat the event as a white-hat disclosure if a defined portion of the funds is returned within a defined time, a channel for contact, and a statement that the team is already working with exchanges and law enforcement.
The bounty offer is a business decision, not a moral one. A return of most of the funds in exchange for a bounty is almost always better for users than a long and uncertain recovery. The offer should be authorised by the incident lead, reviewed by counsel, and made once; repeated escalating offers teach the attacker that waiting pays. Keep every message public and consistent, because the attacker will compare what you say on-chain with what you say to users.
Be aware that the person answering may not be the person who attacked. Opportunists send messages to victim protocols claiming to be the attacker and asking for a payment to begin negotiations. Verify any claim with a signed message from the attacking address before engaging.
Law enforcement and legal counsel
Counsel should be in the war room from the first hour, because several decisions have legal weight: what to say publicly, whether to pay a bounty, what obligations exist towards users and regulators, and how to preserve privilege over the investigation.
File a report with law enforcement early. It rarely produces an immediate result, but it creates a record that exchanges and issuers will ask for before acting on a freeze, and it matters if the funds later surface somewhere that cooperates with courts. Choose the jurisdiction where the team or the affected users are concentrated, and expect to supply the same evidence package you prepared for the exchanges.
Communicate: truthfully and on time
Users will learn about the incident from someone within the first hour. The only question is whether the first thing they read is from the team.
The first statement should go out within the first hour and should say only what is known: that an incident is being investigated, which components are affected, that the protocol is paused if it is, what users should and should not do right now, and when the next update will come. It should not speculate about the cause, the amount or the attacker. It should be posted on every channel the team controls and pinned.
The second statement, within the first several hours, adds the confirmed loss, the root cause in plain terms, the state of containment and the status of any recovery efforts. The third, by the end of the day, describes the path to recovery and the timeline for a full post-mortem. Each statement should be signed off by the incident lead and reviewed by counsel, and each should correct any earlier error explicitly.
Write the templates before the incident, so that the first-hour statement needs only its blanks filled in.
Recover: carefully, not quickly
The pressure to resume operations will be intense, and it is the moment when a second incident becomes most likely.
The copycat risk
Once the exploit transaction is public, every searcher bot and every opportunist can read it. If the vulnerable code is still live, in your protocol or in any fork of it, it will be exploited again, often within minutes. This is why the pause decision cannot wait for the full investigation, and why the root cause should not be published until the vulnerable path is closed everywhere it exists.
Notify forks and integrators privately as soon as the root cause is understood. They share your bug and may not know it. Some teams run a white-hat rescue, draining the remaining funds through the same vulnerability to a safe address before an attacker does; this is defensible when the alternative is certain loss, but it must be executed from a verified address with signers who understand what they are approving.
Fix, review, unpause in stages
Fix the root cause, then have the fix reviewed by someone who did not write it, ideally an external auditor who already knows the codebase. Look beyond the exploited path for the same mistake elsewhere; a bug of one class usually has siblings. Deploy to a test environment, replay the original exploit against the fix, and run the full test suite. Only then unpause, and unpause in stages: withdrawals before deposits, limited caps before full capacity, with monitoring watching for anything unusual.
Decide how users will be made whole, and say so precisely: the source of funds, the amounts, the mechanism and the timeline. Vague promises of a plan are read as no plan.
Afterwards: learn out loud
A public post-mortem within a week or two is now the expected standard, and the teams that write good ones recover their reputation fastest. It should contain the full timeline, the root cause with code references, the amount lost and recovered, what was done well and what was done badly, the fixes shipped, and the structural changes made so that the class of failure cannot recur. It should name the auditors who reviewed the code and say whether the vulnerable path was in scope.
Internally, run a blameless review of the response itself: how long containment took and why, which roles were unfilled, which decision was made without the information it needed. The answers become the next version of the playbook.
Prepare now
Everything above is easier with preparation, and most of it is impossible without.
- Write the playbook, with named roles, a contact tree, the pause procedure including the exact addresses and signers, the evidence checklist, the communication templates, and the contact details for exchanges, issuers, analytics firms and counsel.
- Rehearse it on a test deployment at least twice a year, including waking the signers at an inconvenient hour.
- Verify the pause path works within minutes from a cold start; see our article on key management for how the signer set should be designed.
- Set up monitoring that alerts on privileged calls, large balance movements and oracle deviations, and route it to people who will answer at night.
- Pre-negotiate help. Retainer-based incident response gives you a team that already knows your contracts, your signers and your infrastructure, with a response commitment measured in minutes rather than a cold email during the worst hour of your year.
How we support incident response
Our incident response retainer starts with onboarding: we read the codebase, map the privileged roles and signers, review the playbook or write one with you, and run a tabletop exercise. From then on the team has a direct line to our engineers, with a committed response time, and we take part in the periodic rehearsals.
When an incident happens, we join the war room in the technical lead's seat or beside it: reconstructing the exploit on a fork, identifying the root cause and its siblings, advising on the pause and rescue decisions, preparing the evidence package for exchanges and law enforcement, drafting the on-chain message to the attacker, and reviewing the fix before it ships. Afterwards we help write the post-mortem and re-audit the changed code. Teams without a retainer can still reach us in an emergency, but the first hours go better when we already know where everything is.
Practical next steps
Write down who can pause and how, and test it this week. Write the first-hour statement template. Collect the security contacts for the exchanges and stablecoin issuers your users are most likely to touch. Schedule a rehearsal. Then read our audit checklist with the incident in mind, because the operational section is where most of this begins.
Retainer scope and emergency contact details are on the services page, and you can reach us on Telegram.
