Incident Response Playbook

Purpose and scope

This playbook defines how 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

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

Roles

Role	Responsibility
Incident Lead (IL)	Single decision owner for the incident. Continuous 24/7 coverage from responders distributed across timezones. Declares severity, opens the war room, owns the timeline. Also owns the technical response — diagnosis, exploit analysis, containment actions, fix verification — and assembles the multisig quorum to execute pause, cancel, and signer-rotation transactions across all chains.
Communications Lead	Internal updates, public statements, disclosure log entries.
External partners	Hypernative (24/7 monitoring, war-room support), SEAL 911 (ecosystem emergency response), Doppel (domain/brand protection), auditors on retainer.

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 IL 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 IL. The IL 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

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:

Paused surface	Unpause SLA (false positive)	Auto-lift (backstop)
Tokens (eETH, weETH)	2 hours	8 hours
Core contracts	4 hours	24 hours
Non-core contracts	24 hours	48 hours
Blacklist (per address)	36 hours (review)	72 hours

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.