Incident response

What happens when a security incident is found, by severity.

Severity levels

Who does what

1. Guardian nodes detect and assess the threat.
2. The 2-of-3 Safe can pause affected components.
3. The multisig approves emergency response actions.
4. The community is notified through official channels.
5. A post-mortem and remediation plan are published.

P0: critical incident

First 15 minutes

1. Pause the protocol. The 2-of-3 Safe holds the pauser role and can pause. A Guardian triggered pause is planned and not deployed.
2. Alert the team. Page the on-call engineer, notify all core team members and open an incident channel.
3. Assess the damage. Identify affected contracts, estimate funds at risk and document the attack vector.

15 to 60 minutes

1. Isolate affected systems. Disable affected vault operations, block malicious addresses if identified and preserve evidence.
2. Communicate. Post a status update on Discord, update the status page and prepare user communication.

1 to 24 hours

1. Develop the fix. Create and test a patch, run a security review of it and deploy it to testnet.
2. Deploy the fix. Get multisig approval for the upgrade, deploy to mainnet and verify the fix works.
3. Close out. Write a full incident report, a user compensation plan if needed and process improvements.

P1: high severity

1. Assess the scope of the vulnerability.
2. Prepare a mitigation plan.
3. Deploy a fix within 24 hours.
4. Monitor for exploitation attempts.

P2 and P3: medium and low severity

1. Document the issue.
2. Schedule the fix in the next release.
3. Update documentation if needed.

Runbooks

Pause protocol

# Only the 2-of-3 Safe holds the pauser role today. The call the Safe executes:
cast calldata "pause()"# Verify pause
cast call $VAULT_ADDRESS"paused()"

Block malicious address

# Add to blocklist (ADMIN_ROLE; ADMIN_ROLE is held by the protocol multi-sig)
cast send $REGISTRY_ADDRESS"blockAddress(address)"$MALICIOUS_ADDRESS --private-key $ADMIN_KEY

Emergency contacts

External:

Communication templates

Initial alert (Discord/Twitter)

SECURITY ALERT
We are investigating a potential security issue with [COMPONENT].
As a precaution, [ACTIONS TAKEN].
Your funds are [SAFE/AT RISK]. We will provide updates every [TIME].
DO NOT interact with [CONTRACTS] until further notice.

Status update

UPDATE - [INCIDENT NAME]
Status: [INVESTIGATING/CONTAINED/RESOLVED]
Impact: [DESCRIPTION]
Next Update: [TIME]
Actions taken:
- [ACTION 1]
- [ACTION 2]

Resolution notice

RESOLVED - [INCIDENT NAME]
The security issue has been resolved.
Summary:
- Root cause: [DESCRIPTION]
- Impact: [AFFECTED USERS/FUNDS]
- Resolution: [FIX DEPLOYED]
Full incident report: [LINK]

After a P0 or P1 incident

Every review covers five things:

1. Timeline: the exact sequence of events.
2. Root cause: the underlying vulnerability.
3. Impact: affected users and funds.
4. Response: what worked and what did not.
5. Improvements: process and code changes to prevent a repeat.

The team runs quarterly incident response drills and gives new members security onboarding.

Next

• Security model
• Report a vulnerability
• Audits