> For the complete documentation index, see [llms.txt](https://etherfi.gitbook.io/etherfi/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://etherfi.gitbook.io/etherfi/security/security-and-risks/incident-management/incident-response-playbook.md).

# Incident Response Playbook

## Purpose and scope

This playbook defines how [ether.fi](http://ether.fi) detects, contains, and recovers from security incidents affecting: protocol smart contracts, admin keys and multisig signers, oracles, cross-chain bridge infrastructure, and user-facing infrastructure (domains, frontends). It is the published version of the internal incident response policy in effect since November 24, 2024 and most recently revised in July 2026, reorganized to follow the SEAL Incident Response Framework for Web3 protocols.

## Severity classification

<table><thead><tr><th width="107.7117919921875">Severity</th><th width="178.3646240234375">Definition</th><th width="399.6744384765625">Examples</th><th>Response SLA</th></tr></thead><tbody><tr><td>SEV-1</td><td>Active or imminent loss of user funds</td><td>Contract exploit in progress; admin key confirmed compromised; malicious transaction queued in a timelock; oracle feeding manipulated data</td><td>War room open within 15 min; containment action (pause, rate-limit zeroing) within 1 h</td></tr><tr><td>SEV-2</td><td>Compromise or critical vulnerability, no active loss</td><td>Critical Immunefi report; signer device compromise without on-chain misuse; bridge anomaly contained by rate limits</td><td>War room within 1 h; mitigation plan within 24 h</td></tr><tr><td>SEV-3</td><td>Degraded security posture</td><td>Signer availability below comfort margin; attempted frontend/DNS attack; critical dependency vulnerability</td><td>Triage within 24 h; remediation through normal operations</td></tr></tbody></table>

## Roles

<table><thead><tr><th width="245.4757080078125">Role</th><th>Responsibility</th></tr></thead><tbody><tr><td>Incident Commander (IC)</td><td>Single decision owner for the incident. Continuous 24/7 coverage from responders distributed across timezones. Declares severity, opens war room, owns the timeline.</td></tr><tr><td>Technical Lead</td><td>Diagnosis, exploit analysis, containment actions, fix verification.</td></tr><tr><td>Signer Coordinator</td><td>Assembles multisig quorum; executes pause, cancel, and signer-rotation transactions across all chains.</td></tr><tr><td>Communications Lead</td><td>Internal updates, public statements, disclosure log entries.</td></tr><tr><td>External partners</td><td>Hypernative (24/7 monitoring, war-room support), SEAL 911 (ecosystem emergency response), Doppel (domain/brand protection), auditors on retainer.</td></tr></tbody></table>

## Detection and escalation

* Hypernative monitors 24/7 with automated alerting. Pre-wired pause actions fire on critical invariant violations without waiting for a human.
* Immunefi bug bounty: critical-severity reports page the on-call IC on receipt.
* Community reports via \[security contact / Discord].
* Internal monitoring and signer reports (lost device, phishing attempt, anomalous signature request).

Whoever sees the signal escalates to the on-call IC. The IC makes the severity call within 15 minutes and opens a war room per the SLA table above.

The response loop is the same however an incident surfaces — an automated alert, an external or partner report, a SEAL 911 notification, or a team member noticing something wrong — including when automated monitoring did not fire. Alerts stay open until a human closes them; nothing auto-resolves.

## Runbooks

### Smart contract exploit (active)

1. Pause affected contracts. Hypernative auto-pause may already have fired; if it did not, or the signal came from outside automated monitoring, several independent human authorization paths can each order the pause on their own — pausing is deliberately low-bar, with no timelock in the path and no single point of failure.
2. Blacklist the addresses involved when a targeted freeze contains the threat without halting the protocol for everyone. On-chain pauses and blacklists are time-boxed; during a confirmed incident they are re-applied before each auto-lift so containment holds until resolution.
3. If cross-chain exposure exists, halt the OFT mesh.
4. Engage SEAL 911 and retained auditors; identify root cause.
5. Quantify exposure; notify affected integrators (lending markets, vaults) before public disclosure if front-running risk exists.
6. Unpause only per the unpause bar below: root cause documented as resolved, a 4-of-7 quorum, and security-lead sign-off.

### Admin key / signer compromise

Trigger threshold: any credible doubt about a key is treated as compromise.

1. Confirm the signal (unexpected signature request, device loss/theft, successful phishing).
2. Treat the key as hostile: immediately review every queued timelock operation and every pending Safe transaction across all chains for that signer's involvement.
3. Cancel any malicious queued operation inside its timelock window. The 10-day upgrade and 2-day operations windows leave time for this.
4. Remove and replace the signer. SLA: replacement transaction queued within \[24 h] of confirmed compromise, executed as soon as quorum allows.
5. Rotate any credentials the compromised party had access to; run a post-incident review of the compromise vector.

### Signer loss or unavailability

* Availability health check: maintain at least \[threshold + 2] reachable signers per multisig at all times, verified \[quarterly].
* Replacement SLA: \[7 days] from confirmed permanent loss (death, incapacity, departure, irrecoverable key).
* Every configuration change is recorded in the public changelog; [MultiSigs documentation](https://etherfi.gitbook.io/etherfi/security/multisigs)

### Oracle anomaly or compromise

1. Validate the suspect report against independent data sources.
2. Pause the rebase / rate-update path if incorrect data could propagate to eETH/weETH pricing.
3. Rotate the compromised oracle member; document the rotation publicly.

### Bridge / cross-chain anomaly

1. Hypernative detectors cover unexpected mint/release events on the weETH bridge mesh, with automatic pause wired.
2. Zero OFT rate limits on affected paths.
3. Verify L1/L2 supply invariants before resuming bridging.

## Pausing and unpausing: asymmetric by design

Pausing is easy and fast; unpausing is deliberately hard. Resuming into an unresolved attack is the dangerous failure mode, so the two actions have different bars:

* **Pause**: automated triggers or any one of several independent human authorization paths, instantly, with no timelock.
* **Unpause**: requires the root cause documented as resolved or confirmed false, a 4-of-7 multisig quorum, and security-lead sign-off.

A contract-level pause is a rare, catastrophic event — core contracts and tokens have never been paused. If a pause turns out to be a **false positive**, these are the restore commitments:

<table><thead><tr><th width="220">Paused surface</th><th>Unpause SLA (false positive)</th><th>Auto-lift (backstop)</th></tr></thead><tbody><tr><td>Tokens (eETH, weETH)</td><td>2 hours</td><td>8 hours</td></tr><tr><td>Core contracts</td><td>4 hours</td><td>24 hours</td></tr><tr><td>Non-core contracts</td><td>24 hours</td><td>48 hours</td></tr><tr><td>Blacklist (per address)</td><td>36 hours (review)</td><td>72 hours</td></tr></tbody></table>

The **unpause SLA applies only to false positives**: it is the hard commitment to actively restore service once a pause is confirmed to have fired on benign activity — deliberately tighter than the auto-lift so the backstop is never the plan. The detector that fired is tuned so it does not re-fire on the same benign pattern, and the false fire is post-mortemed like any incident.

For a **valid bug or active incident, no unpause clock applies**: the pause and any attacker blacklist are re-applied before each auto-lift and held for as long as resolution takes. Unpausing then happens only through the bar above — root cause documented as resolved, 4-of-7 quorum, security-lead sign-off — never on a timer. The **auto-lift** is the onchain expiry that lifts a pause on its own if no action is taken; it protects users from a stuck or forgotten pause, not attackers from a short one.

## Communications

* Internal: dedicated war-room channel; updates every \[30 min] during SEV-1.
* External: initial public acknowledgment within \[4 h] of a confirmed SEV-1; status updates at a stated cadence until resolution.
* Disclosure log: all incidents and material near-misses are recorded.

## Post-incident

Post-mortem published for every SEV-1 and SEV-2, covering: timeline, root cause, user impact, funds status and compensation path (with amounts), what worked and what failed in the response, and remediation items with owners and deadlines.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://etherfi.gitbook.io/etherfi/security/security-and-risks/incident-management/incident-response-playbook.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.