On a public blockchain an exploit can drain a protocol in minutes and nothing can be reversed afterwards, so the response has to be decided, staffed and rehearsed before the first alert. This playbook is a template that a protocol, DAO, wallet provider or exchange can adapt into its own incident response procedure for smart contract exploits, key and signer compromise, front-end and DNS hijacks and drained treasuries. It covers triggers, roles, war room set-up, pausing and other containment options, whitehat rescue under the SEAL Safe Harbor framework, coordination with exchanges and issuers, communication and the post-incident review. It builds on the response outline in the Web3 and Crypto Security Guide and draws on the Security Alliance (SEAL) incident management framework.
How to use this template
- Replace text in square brackets, such as [Organisation], [Incident Leader] and [Emergency multisig], with your own names, addresses and contacts.
- "Must" marks a mandatory step; "should" marks a recommended practice where a documented exception is acceptable.
- Fill in the contract-specific parts (pause functions, defensive scripts, recovery addresses) and test them on a testnet or fork before relying on them.
- Keep the completed playbook, contact sheet and runbooks somewhere reachable when your normal systems are down, such as an offline copy held by each role.
- Run a tabletop exercise at least twice a year and a live pause drill at least once a year, and update the playbook after every exercise and incident.
1. Scope and triggers
1.1 This playbook applies to security incidents affecting [Organisation]'s smart contracts, signer and admin keys, treasury wallets, front-ends, domains, build pipelines and the infrastructure that serves them.
1.2 Any of the following must trigger the playbook and an initial severity of P1 until shown otherwise:
- Unexpected outflows from protocol contracts, treasury or hot wallets.
- On-chain monitoring alerts on ownership, role, signer, threshold, implementation or oracle changes that were not scheduled.
- A signer or key holder reporting suspected compromise, or a successful social engineering attempt against one.
- Users reporting unexpected transaction or approval requests from the official site, or injected scripts in the page.
- Credible reports from researchers, SEAL 911, auditors, exchanges or analytics firms.
1.3 Severity levels (adapted from the SEAL incident response policy):
| Level | Definition | Response | Examples |
|---|---|---|---|
| P1 Critical | Loss of funds or active exploit | Immediate, full war room, Decision Makers involved | Active exploit, private key compromise, drainer on official front-end |
| P2 High | Potential loss under specific conditions | Immediate | Critical vulnerability not yet exploited, DNS hijack attempt |
| P3 Moderate | No fund loss likely | Within hours | Minor vulnerability, degraded service |
| P4 Low | No fund loss | Scheduled | Display bugs, non-urgent fixes |
1.4 When in doubt, choose the higher severity. A false P1 costs noise; a missed P1 costs funds.
1.5 Quick differentiation: funds moving to known addresses (treasury, multisig) are likely authorised; a single affected user is more likely phishing than a protocol exploit; a UI showing wrong values while chain state is correct points to a front-end incident.
2. Roles and contacts
2.1 Every incident must have the following roles filled, even if one person holds several:
| Role | Responsibility | Named holder and backup |
|---|---|---|
| Detector | Raises the alert and hands off; does not need to fix | Anyone |
| Incident Leader | Runs the war room, assigns tasks, makes or escalates decisions | [Name], [Backup] |
| Scribe | Keeps the incident log with UTC timestamps, decisions and rationale; does nothing else | [Name], [Backup] |
| Smart contract lead | Analyses the exploit path, prepares pause, rescue and patch transactions | [Name], [Backup] |
| Signer coordinator | Gathers emergency multisig signers and runs the verification steps | [Name], [Backup] |
| Front-end and infrastructure lead | Disables deposits, takes down or redirects the site, secures DNS and CDN | [Name], [Backup] |
| Communication Manager | Drafts and posts approved internal and public updates | [Name], [Backup] |
| Decision Makers | Approve high-stakes actions: pausing, negotiations, disclosures, law enforcement | [Founders, security lead, legal] |
2.2 [Organisation] must maintain a contact sheet, verified at least quarterly, covering: SEAL 911 (via its Telegram bot), auditors, incident response retainer, bug bounty platform, legal counsel, hosting, CDN and DNS providers with escalation routes, major exchanges and stablecoin issuers' security contacts, blockchain analytics partners, downstream protocols (bridges, lending markets) and the relevant law enforcement reporting routes, such as the FBI's IC3 in the US.
2.3 Small teams (two to five people) should name one or two default Incident Leaders and keep someone reachable at all times. Teams holding significant assets should run a formal on-call rotation regardless of size.
3. Detection and triage
3.1 Within the first 15 minutes, the Incident Leader must:
- Open the war room: a pre-created private channel with audio, limited to named responders, on a platform that does not depend on any possibly compromised account.
- Assign the Scribe and start the incident log.
- Notify SEAL 911 for active exploits or cross-protocol incidents, giving as much detail as possible to avoid duplicated work.
- Confirm any reported key compromise with the key holder over a channel the attacker cannot control.
3.2 The analysis lead must then establish and record: funds at risk; affected contracts and chains; whether the exploit is still running; the transactions involved, with block numbers; affected user and protocol addresses; attacker addresses and funding sources; and the movement of stolen funds.
3.3 Evidence must be preserved from the start: transaction hashes, block numbers, mempool data where available, front-end files and build artefacts, DNS and CDN change logs, cloud audit logs and chat history. Do not wipe or rebuild compromised devices until they have been imaged.
4. Containment
4.1 The goal is to stop further loss with the narrowest action available. Options in rough order of preference:
| Option | When to use | Prerequisites | Risks |
|---|---|---|---|
| Pause affected contracts | Exploit in progress and contracts are pausable | Pause role held by an emergency multisig (e.g. 2 of 4) with pause-only power; signers reachable 24/7 | Freezes legitimate users; pause must not also grant upgrade power |
| Disable deposits or withdrawals in the front-end, block addresses | Exploit routes through the UI, or as an extra layer | Feature flags and address blocklists ready | Attackers can call contracts directly |
| Take down or redirect the front-end | Drainer or injected script on the official site | Ability to point DNS to a maintenance page or disable the CDN | Registrar or DNS account may itself be compromised |
| Pre-made defensive scripts | Known emergency actions (withdraw to safe address, change parameters) | Scripts reviewed and tested on a fork | Untested scripts under pressure cause new losses |
| Rotate signers or transfer ownership | Key or signer compromise | Signer rotation runbook; fresh hardware wallets | Remaining signers may also be compromised; verify each |
| Whitehat rescue | No pause available and funds remain exploitable | Safe Harbor adopted in advance, or a vetted rescue team | Execution risk, legal exposure without Safe Harbor |
4.2 Every containment transaction must be verified by each signer against an independent hash and decoded calldata before signing, even under time pressure. Attackers have used incidents to push "emergency" transactions.
4.3 Within 30 minutes of a suspected key compromise, all non-emergency transactions must stop and the affected signers must be isolated from the signing process.
Whitehat rescue and Safe Harbor
4.4 [Organisation] should adopt the SEAL Whitehat Safe Harbor agreement before any incident. SEAL created it after the Nomad hack, where more than $190 million was drained over hours while willing whitehats lacked legal cover to act. Under the framework, whitehats may intervene only during an active or imminent exploit, must not initiate the exploit, must return rescued funds to the protocol's Asset Recovery Address within 72 hours and should contact the named Security Contact within 6 hours of a rescue. The bounty is predefined as the lower of a bounty percentage of recovered funds (10% is described as industry standard) and a cap in USD.
4.5 Record in advance: the Asset Recovery Address (a secure multisig able to receive large inflows), the Security Contact with several channels, the contracts and chains in scope (CAIP-2 chain identifiers, with scope set to All for factories and deployers), bounty terms and whether anonymous whitehats are accepted or KYC is required.
5. Eradication
5.1 The smart contract lead must identify the root cause and confirm that the same path is not exploitable on other deployments, chains or forks of the code.
5.2 For key and signer compromise, assume every credential reachable from the affected device or account is stolen. Rotate signer keys onto fresh hardware wallets, transfer ownership of admin roles to new addresses, and revoke cloud sessions, registry and CI tokens, DNS and registrar credentials.
5.3 For front-end compromise, identify the vector (DNS, CDN, dependency, build pipeline or hosting), remove the malicious code, rebuild from a known-good commit with locked dependencies and redeploy through the pipeline with integrity checks.
5.4 Patches must be reviewed by at least one party outside the immediate team, ideally the auditor, and simulated against a fork of current chain state before deployment.
6. Recovery
6.1 Unpause or re-enable functions in stages, with heightened monitoring and alerting thresholds for the first [72 hours].
6.2 Coordinate fund tracing and freezing: share attacker addresses with analytics partners, exchanges and token issuers that can freeze assets under their own terms, and ask block explorers to label them. After the Bybit hack, the FBI published laundering addresses and asked RPC node operators, exchanges, bridges and other services to block transactions derived from them; speed of sharing matters.
6.3 Report the theft to law enforcement (in the US, IC3) and keep the case reference with the incident log.
6.4 Where users were harmed, publish a clear plan for any reimbursement, migration or approval revocation, and provide a front-end path for users to revoke token approvals where needed.
6.5 Do not engage with an attacker's offers outside the agreed negotiation route set by Decision Makers and legal counsel, and check sanctions exposure before paying any bounty to an unknown party. See the Ransomware Payments and Sanctions Guide.
7. Communication and notification
7.1 Before each public post, the Communication Manager must get approval from the Incident Leader or a Decision Maker, check facts, avoid speculation on root cause, say what users should and should not do, and state when the next update will come.
7.2 Pre-approved building blocks:
- Acknowledgement: "We are aware of an issue affecting [service] and are actively investigating."
- Do not interact: "Do not interact with [contract or domain] or approve any transactions until further notice."
- Paused: "We have temporarily paused [feature] while we investigate."
- Funds safe: use only if confirmed true.
- Next update: "We will provide an update within [timeframe]."
7.3 Notify downstream protocols that integrate the affected contracts, partner exchanges, custodians and insurers through their security contacts. Assess regulatory notification duties with legal counsel, for example where [Organisation] is an authorised crypto-asset service provider; see the MiCA and DORA for Crypto-Asset Service Providers Guide.
7.4 Post only from official, verified accounts, and warn users that attackers often run fake "refund" or "migration" sites after incidents.
8. Post-incident review
8.1 Within [14 days], hold a blameless review and publish an internal post-mortem covering: timeline (UTC), detection source and time to detect, root cause, containment actions and their timing, funds lost and recovered, what worked, what failed and actions with owners and dates.
8.2 Publish an external post-mortem when users or partners were affected, with enough detail for others to defend themselves and without exposing unpatched issues.
8.3 Track and report: time to detect, time from alert to war room, time from war room to pause or containment, share of stolen funds frozen or recovered, and the number of review actions closed on time.
8.4 Update this playbook, the contact sheet, monitoring rules and defensive scripts with the lessons learned.
Implementation guidance
Before adopting the playbook, confirm that the capabilities it assumes actually exist:
- Inventory privileged roles. List every pause, upgrade, owner and treasury role and its holder; see the Multisig Treasury Operations Guide for Protocols and Companies.
- Build containment in. Make contracts pausable where appropriate, give pause power to a dedicated emergency multisig and keep upgrade power behind a timelock.
- Prepare scripts and channels. Write and fork-test defensive scripts, create the war room channel and paging, and store offline copies of the contact sheet.
- Adopt Safe Harbor. Define the recovery address, scope and bounty terms, and register the adoption.
- Monitor and rehearse. Run alert-only monitoring first, then tabletop and live pause drills; measure time from page to threshold signatures.
- Protect the people. Most large incidents begin with a developer or signer lure; see the Web3 Developer Operational Security Guide.
Further reading: SEAL: SEAL 911 War Room Guidelines · SEAL: Incident Response Policy template · SEAL: Whitehat Safe Harbor · SEAL: Safe Harbor Scope Terms · FBI IC3: North Korea Responsible for $1.5 Billion Bybit Hack · NIST: SP 800-61 Rev. 3 Incident Response Recommendations
Related NHI Mgmt Group resources: Web3 and Crypto Security Guide · Multisig Treasury Operations Guide for Protocols and Companies · Crypto Scam and Drainer Guide · Lazarus Group Threat Actor Profile