Runbook: Smart Contract Exploit
This is an example runbook. Review and customize for your protocol before use. Fill in the placeholder commands, add your specific contracts and addresses, and test during a tabletop exercise.
Quick Reference
| Field | Value |
|---|---|
| Typical Severity | P1 |
| Primary Responder | Smart Contract SME |
| Last Updated | [Date] |
| Owner | [Name] |
Identification
Symptoms
- Unexpected fund movements
- On-chain monitoring alerts
- Unusual transaction patterns
- Community reports of lost funds
- Abnormal contract state changes
Alerts
- [Your on-chain monitoring tool]
- [Blockchain explorer alerts]
Differentiation
- If funds moving to known addresses (multisig, treasury) → likely authorized
- If single user affected → might be phishing, not protocol exploit
- If UI shows wrong values but chain is correct → frontend issue
Immediate Actions
Step 1: Assess Scope
Why: Understand what's at risk before acting
- Check total funds at risk
- Identify affected contracts
- Determine if exploit is ongoing
Step 2: Contact SEAL 911
Why: Get immediate expert support for active exploits
Step 3: Pause if Possible
Why: Stop the bleeding
If your contracts have pause functionality:
[Document your pause procedure here]If no pause function: Consider other containment options (front-running, rescue operations).
Step 4: Preserve Evidence
Why: Needed for investigation and potential recovery
- Screenshot/save relevant transactions
- Note block numbers
- Save mempool data if available
- Document attacker addresses
Investigation
Key Questions
- What vulnerability was exploited?
- How much was taken/at risk?
- Is the exploit still possible?
- Are other contracts affected?
- Was this reported via bug bounty first?
Information to Gather
| Data | Source |
|---|---|
| Exploit transactions | Block explorer |
| Attacker addresses | On-chain analysis |
| Vulnerability details | Code review |
| Affected user count | Contract state |
Mitigation
Option A: Pause Contracts
When: Pause functionality exists Impact: Users cannot interact until unpaused
- Execute pause function
- Verify pause is effective
- Communicate to users
Option B: Emergency Upgrade
When: Upgrade mechanism exists Impact: Requires governance or multisig action
- Prepare patched contract
- Execute upgrade
- Verify fix
Option C: Rescue Operation
When: Funds can be moved to safety before attacker Impact: Complex, requires coordination
- Coordinate with security researchers
- Prepare rescue transactions
- Execute with proper sequencing
Escalation
Contact immediately:
- Decision Makers
- Security Partners
- Legal if significant fund loss
Post-Exploit
- Determine fix approach
- Plan for affected users (if any)
- Prepare public communication
- Consider disclosure timeline
- Engage with law enforcement if appropriate
Common Root Causes
| Cause | Signs | Prevention |
|---|---|---|
| Reentrancy | Recursive calls in tx | CEI pattern, reentrancy guards |
| Access control | Unauthorized caller | Proper modifiers |
| Oracle manipulation | Price deviation before exploit | TWAP, multiple sources |