Incident Response Plan

This document outlines the procedures for responding to security incidents in the Noderr Protocol.

Severity Levels

LevelDescriptionResponse TimeExamples
P0 - CriticalActive exploit, funds at riskImmediateSmart contract vulnerability being exploited
P1 - HighPotential exploit, no active attack< 1 hourVulnerability discovered, not yet exploited
P2 - MediumSecurity issue, limited impact< 24 hoursAccess control misconfiguration
P3 - LowMinor issue, no immediate risk< 1 weekDocumentation gap, minor bug

Response Procedures

P0 - Critical Incident

Immediate Actions (0-15 minutes):

  1. Pause Protocol

    Any Guardian node can execute emergency pause
    
  2. Alert Team

    • Page on-call engineer
    • Notify all core team members
    • Open incident channel
  3. Assess Damage

    • Identify affected contracts
    • Estimate funds at risk
    • Document attack vector

Containment (15-60 minutes):

  1. Isolate Affected Systems

    • Disable affected vault operations
    • Block malicious addresses if identified
    • Preserve evidence
  2. Communicate

    • Post status update on Discord
    • Update status page
    • Prepare user communication

Recovery (1-24 hours):

  1. Develop Fix

    • Create and test patch
    • Security review of fix
    • Deploy to testnet
  2. Deploy Fix

    • Multi-sig approval for upgrade
    • Deploy to mainnet
    • Verify fix effectiveness
  3. Post-Incident

    • Full incident report
    • User compensation plan if needed
    • Process improvements

P1 - High Severity

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

P2/P3 - Medium/Low Severity

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

Emergency Contacts

Core Team

RoleContactAvailability
Lead Developer[email protected]24/7
Security Lead[email protected]24/7
Operations[email protected]Business hours

External

ServiceContactPurpose
Chainlink[email protected]Oracle issues
Base[email protected]Network issues
Audit FirmTBDSecurity consultation

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]

Runbooks

Pause Protocol

# Any Guardian can pause
cast send $VAULT_ADDRESS"pause()" --private-key $GUARDIAN_KEY# Verify pause
cast call $VAULT_ADDRESS"paused()"

Block Malicious Address

# Add to blocklist (requires ADMIN_ROLE)
cast send $REGISTRY_ADDRESS"blockAddress(address)"$MALICIOUS_ADDRESS --private-key $ADMIN_KEY

Emergency Withdrawal

# Admin can withdraw to safe address in emergency
cast send $VAULT_ADDRESS"emergencyWithdraw(address)"$SAFE_ADDRESS --private-key $ADMIN_KEY

Post-Incident Review

After every P0/P1 incident:

  1. Timeline: Document exact sequence of events
  2. Root Cause: Identify underlying vulnerability
  3. Impact Assessment: Calculate affected users/funds
  4. Response Evaluation: What worked, what didn't
  5. Improvements: Process/code changes to prevent recurrence

Training

  • Quarterly incident response drills
  • New team member security onboarding
  • Annual security review with external auditors

Last Updated: December 2025

results matching ""

    No results matching ""