Risk: A protocol can receive a valid critical report and still lose funds because intake, triage, emergency authority, signer execution, legal review, user communication, and recovery operate as separate functions.
Likelihood: Medium to high for any protocol holding meaningful value, relying on privileged roles, or depending on external infrastructure.
Impact: Direct loss, prolonged downtime, avoidable user harm, evidence destruction, regulatory exposure, and disputes over responsibility.
Control: Establish one tested chain from first signal to containment, recovery, restart, and post-mortem.
Residual risk: No process eliminates zero-day exploits, compromised insiders, unavailable signers, or irreversible on-chain actions. The objective is to reduce delay, ambiguity, and preventable loss.
Executive position
A bug bounty is an intake mechanism, not an incident-response capability.
A complete response chain begins when the first credible signal arrives. It ends only after exposure is contained, affected users are addressed, recovered assets are controlled, service is restored under explicit conditions, and remediation actions are independently verified.
The NIST incident-response recommendations place incident response inside ongoing cybersecurity risk management rather than treating it as an improvised technical exercise after detection. Crypto protocols should apply the same principle to governance, multisig operations, frontends, oracles, bridges, custodians, RPC providers, and communications infrastructure.
Primary research question
Across publicly documented protocol incidents, which pre-committed control most strongly predicts lower loss after the first credible signal, and at what time-to-containment threshold does loss begin to accelerate: 24/7 intake, a critical-severity service level, pre-authorized pause authority, or tested signer quorum?
This question is useful because it tests where preparedness creates the greatest marginal protection. It may show that faster detection matters less than authority to act, or that emergency powers provide little value when signer availability and transaction execution have not been rehearsed.
1. Build two distinct entry paths
A protocol needs one path for responsible disclosure and another for an active or imminent exploit.
The responsible-disclosure path should define:
- In-scope contracts, applications, infrastructure, and chains
- Permitted testing methods
- Prohibited actions, including user harm, privacy intrusion, extortion, and unnecessary fund movement
- Secure reporting channels and a backup channel
- Expected acknowledgement and triage times
- Severity and reward methodology
- Confidentiality expectations
- Evidence requirements
- Disclosure coordination
- Conditions for legal safe harbour
The emergency path should define:
- What qualifies as active or imminent exploitation
- Which contracts and assets may be protected
- Who can authorize intervention
- Approved recovery addresses
- Whitehat eligibility and return conditions
- Bounty or compensation rules
- KYC requirements, where applicable
- Immediate escalation contacts
The distinction is material. The Whitehat Safe Harbor framework is designed for qualifying intervention during an active or imminent exploit, while ordinary bug-bounty reporting is intended for vulnerabilities that can still be disclosed and remediated without emergency fund movement.
Control: A researcher should be able to determine, from one authoritative page, whether to submit a confidential report or invoke the emergency route. If that distinction requires private negotiation, the control is incomplete.
Safe-harbour language should be reviewed against the protocol’s governing law, operating structure, insurance, sanctions obligations, and actual technical capabilities. Legal wording that promises protection for actions the protocol cannot operationally recognize or settle creates a second layer of risk.
2. Classify severity by consequence, exploitability, and time
A familiar four-level scale can provide a common vocabulary. The crypto vulnerability severity model uses Critical, High, Medium, and Low categories and emphasizes the consequence of successful exploitation, while allowing exploit conditions to affect classification.
A protocol should add its own operational dimensions:
- Impact: Maximum credible loss, insolvency, permanent freeze, governance capture, unauthorized minting, data compromise, or user-signing manipulation
- Exploitability: Permissionless or privileged, single transaction or multi-step, capital required, oracle dependence, and reproducibility
- Exposure: Value currently reachable, affected users, chains, deployments, and integrations
- Attacker status: Theoretical report, confirmed proof of concept, probing, mempool activity, or successful exploitation
- Reversibility: Pause, upgrade, withdrawal limit, frontend block, oracle intervention, or migration available
- Time sensitivity: Whether delay increases loss, disclosure risk, or attacker capability
Critical status should trigger automatically when there is credible evidence of direct fund theft, permanent fund loss, protocol insolvency, governance takeover, privileged-key compromise, malicious transaction substitution, or active exploitation against a live deployment.
Severity should initially move upward on credible evidence and move downward only after technical validation. Confidence is not a substitute for exposure analysis. A report can be uncertain and still require critical handling when the downside is immediate and irreversible.
Risk: A severity label without an action clock becomes descriptive paperwork.
Control: Link each severity to acknowledgement time, incident-command activation, signer mobilization, containment authority, communication rules, and executive escalation.
3. Assign command before the incident
Every critical incident needs one incident commander with authority to coordinate decisions. Technical expertise alone is insufficient. The commander must control the response rhythm, assign owners, resolve conflicts, and preserve a decision record.
The minimum roles are:
- Incident commander
- Technical investigation lead
- On-chain intelligence and tracing lead
- Containment lead
- Signer coordinator
- Legal and compliance lead
- User communications lead
- Vendor and counterparty liaison
- Evidence custodian and timeline recorder
A small team may combine roles, but it should not combine accountability. Every action, decision, and external contact requires a named owner and backup.
The protocol should answer these questions before launch:
- Who may declare a critical incident?
- Who is liable for ordering a pause or upgrade?
- Who may move recovered funds?
- Who can contact exchanges, stablecoin issuers, custodians, insurers, and law enforcement?
- Who approves public statements?
- Who takes command if the primary incident commander is unreachable or conflicted?
Consensus governance may be appropriate for normal policy. It is often incompatible with minute-by-minute containment. Any delegated emergency authority should therefore be narrow, documented, time-limited, reviewable, and paired with transparent post-incident accountability.
4. Start the clock at the first credible signal
The response clock should start at the earliest credible external or internal signal, not when management finally acknowledges the incident.
An illustrative critical-incident service level could require:
- Within 5 minutes: Open a secure case, preserve the original report, and activate the backup channel if necessary
- Within 15 minutes: Assign provisional severity, name the incident commander, and establish a restricted war room
- Within 20 minutes: Confirm signer reachability, pause capability, gas availability, clean devices, and backup RPC access
- Within 30 minutes: Produce a containment recommendation and record the decision authority
- Within 60 minutes: Issue an initial user notice when users face continuing exposure, service disruption, or credible public speculation
These are design targets, not universal numbers. A protocol should set thresholds appropriate to its value at risk, governance architecture, and technical controls, then test whether the team can meet them at 03:00 UTC during a vendor outage.
Automatic escalation signals should include:
- A confirmed exploit transaction or hostile mempool activity
- A reproducible loss path against a live deployment
- Unexplained outflows above a defined value or velocity threshold
- Compromise of an admin, deployer, oracle, bridge, or signer credential
- Frontend behavior that changes transaction destinations or parameters
- Two independent high-confidence alerts indicating the same attack path
- Loss of monitoring at the same time as abnormal on-chain activity
Residual risk: False positives may cause an unnecessary pause. The control objective is not to eliminate false positives, but to define who accepts the cost of waiting when funds remain exposed.
5. Treat pauses as controlled emergency powers
A pause function is useful only when the protocol has defined what it stops, who can invoke it, how quickly it can execute, and how operations resume.
The pause runbook should specify:
- Contracts, functions, markets, chains, and user actions affected
- Whether deposits, borrowing, trading, bridging, liquidations, and withdrawals stop independently
- Required signer quorum
- Maximum expected execution time
- Transaction construction and independent verification steps
- Timelock or governance bypass conditions
- Monitoring that confirms the pause took effect
- User and counterparty communication
- Unpause authority and release criteria
Protocols without a global pause still need containment options. These may include disabling the frontend, revoking operator permissions, reducing caps, freezing an oracle, restricting a bridge, rotating credentials, upgrading a proxy, isolating an affected market, or migrating liquidity.
Emergency authority creates its own governance and custody exposure. The control should therefore be no broader than necessary. A global, indefinite pause controlled by one key is not mature incident response. It is an unbounded administrative risk.
Control: Test the pause after every material deployment and during scheduled exercises.
Residual risk: A pause key can be compromised, a timelock can be too slow, an upgrade can introduce new faults, and a supposedly immutable component may leave no containment path. These are board-level design choices, not details to discover during an exploit.
6. Measure signer readiness, not signer count
A multisig quorum on paper does not prove emergency availability.
The signer-readiness register should record:
- Primary and backup signers
- Time-zone coverage
- Secure contact methods
- Device and hardware-wallet readiness
- Independent key custody
- Chain and application familiarity
- Backup RPC and block-explorer access
- Gas funding
- Travel or jurisdictional constraints
- Conflicts of interest
- Replacement procedure
Reachability tests should occur regularly. Full emergency-signing drills should test transaction construction, simulation, human verification, signature collection, broadcast, confirmation, and rollback planning.
No critical response should depend on one messaging platform, one RPC provider, one cloud account, one custody vendor, or one country remaining available.
The relevant test is not, “Do we have five signers?” It is, “Can the required quorum safely execute the correct transaction if one signer is compromised, one is asleep, one is traveling, the primary RPC is degraded, and the custody vendor has suspended service?”
Vendor due diligence must address who is liable, where operational and identity data goes, what happens during an outage, which subcontractors are involved, and whether the vendor can continue through a regulatory or security shock.
7. Connect threat intelligence to executable decisions
Threat intelligence has value only when a signal changes an action.
The response plan should define who receives indicators, who validates them, and what each confidence level authorizes. A high-confidence attacker address may trigger enhanced monitoring. A confirmed exploit path may trigger a pause. A suspected compromised domain may trigger DNS isolation and a user warning.
During an incident, preserve:
- Original reporter messages and attachments
- Contract source, build artifacts, deployment hashes, and configuration
- Relevant transactions, traces, logs, mempool observations, and affected addresses
- Admin, signer, oracle, DNS, cloud, repository, and CI activity
- Frontend bundles and third-party dependency versions
- Vendor alerts and communications
- Decision timestamps, approvers, rejected options, and reasons
Access should be limited to those who need it. Evidence should be time-synchronized, hashed where practical, retained under a defined policy, and transferred with a recorded chain of custody.
Threat-intelligence providers should not become an unexamined single point of failure. The protocol should know where submitted wallet data, IP data, user identifiers, and incident details are processed; whether the provider can disclose them to affiliates or authorities; and how service continues if the provider is breached or legally restricted.
8. Prepare user communication before facts are complete
Silence can increase user harm, but premature technical detail can help an attacker.
Pre-approved communication templates should cover:
- Investigation in progress
- Frontend disabled
- Contract or market paused
- Specific user action required
- Warning against phishing and impersonation
- Confirmed scope and known limitations
- Recovery progress
- Service restart
- Post-mortem publication
Every message should state:
- What is known
- What is not yet known
- What users should do now
- What users should not do
- Which channels are authoritative
- When the next update will be issued
The protocol should use a canonical status page and authenticated social channels. It should predefine who can publish if the usual communications account is compromised.
Communications should avoid unsupported claims such as “funds are safe,” “the issue is fully contained,” or “no users are affected.” A more defensible statement identifies the evidence available at that time and the remaining uncertainty.
Control: Separate the technical war room from the public communication function, but keep both on the same verified timeline. Public statements must not outrun the evidence, and technical teams must not leave users without actionable instructions.
9. Predefine recovery routes and legal gates
Fund recovery can follow several routes:
- Whitehat rescue under published terms
- Voluntary return by an attacker
- Negotiated settlement
- Freeze or seizure assistance from an exchange, custodian, bridge, or stablecoin issuer
- Civil or criminal legal process
- Protocol-funded restitution
- Insurance recovery
Each route requires a named owner, legal basis, decision authority, financial ceiling, evidence standard, approved destination, accounting treatment, and disclosure rule.
Recovery addresses should be created in advance, independently verified, controlled by appropriate quorum, monitored, and segregated from operating treasury funds. The team should have transaction templates for receiving, screening, transferring, and safeguarding recovered assets.
For organizations subject to United States jurisdiction, the OFAC virtual-currency compliance guidance is a reminder that sanctions requirements and related procedures also apply in the virtual-currency context. Recovery urgency does not remove the need to assess counterparties, blocked property, reporting duties, and licensing questions.
The protocol should decide in advance:
- Whether anonymous whitehats are eligible
- When KYC is required
- Who may approve a bounty or settlement
- Whether a bounty cap differs from the normal bug-bounty cap
- How suspected attacker independence is assessed
- How sanctioned or high-risk exposure is handled
- Whether recovered assets may be used before legal status is resolved
- Who bears loss if a tracing provider, exchange, or issuer makes an incorrect determination
Risk: Mishandled recovery can convert a security incident into a sanctions, custody, accounting, or governance incident.
Control: Route all recovered assets through a pre-approved legal, compliance, custody, and accounting procedure. Operational urgency should accelerate review, not eliminate it.
10. Make restart a controlled release
Containment is not proof that the protocol is safe to reopen.
Minimum restart conditions should include:
- The exploit path is understood well enough to block recurrence
- Affected deployments and integrations have been scoped
- Compromised credentials and sessions have been revoked
- A patch, migration, or compensating control has been independently reviewed
- New monitoring covers the known attack path
- User balances and protocol accounting have been reconciled
- Recovered funds are segregated and controlled
- Frontend, DNS, API, oracle, bridge, and signing systems have been verified
- A rollback or re-pause path exists
- User communication is ready
- Decision authority and dissent are documented
A staged restart may use lower caps, restricted markets, rate limits, additional confirmations, or phased chain activation. Commercial pressure, token price, or social-media criticism should not substitute for release criteria.
A practical governance rule is dual approval: one technical sign-off confirming the control works, and one independent risk, legal, or governance sign-off confirming the residual exposure is accepted.
11. Use the post-mortem to close controls, not merely explain events
A useful post-mortem separates:
- Root cause
- Exploit path
- Contributing conditions
- Detection failure
- Triage failure
- Decision delay
- Signer or vendor delay
- Communication failure
- Recovery outcome
- User impact
- Regulatory and contractual consequences
The timeline should begin at the first credible signal, not the first internal meeting. It should record what was known at each decision point, which options were available, who was responsible, and why an action was taken or deferred.
A public version may require redaction for user privacy, active investigations, legal privilege, and future exploit risk. Redaction should not erase accountability for control failures.
Every remediation item needs:
- One accountable owner
- A completion date
- Evidence of implementation
- Independent validation
- A retest date
- A board or governance closure decision
“Blameless” should mean that analysis focuses on systems and incentives. It should not mean that decision rights, vendor failures, ignored alerts, or unperformed duties remain unexamined.
Minimum viable incident-response package
Before a protocol holds material user value, it should have:
- A public security contact and secure backup channel
- Responsible-disclosure and safe-harbour terms
- A protocol-specific severity matrix
- Critical-incident service levels
- A named incident commander and alternates
- A current escalation and counterparty directory
- A documented emergency-authority map
- Tested pause, upgrade, and isolation runbooks
- A verified signer-readiness register
- Approved recovery addresses
- Threat-intelligence and evidence-handling procedures
- User communication templates and a canonical status page
- Legal, sanctions, regulatory, insurance, and law-enforcement contacts
- Recovery, bounty, settlement, and restitution policies
- Restart criteria
- A post-mortem and remediation-closure process
- Recurring tabletop and live execution exercises
Board-level acceptance test
Run this scenario without advance notice:
At 03:17 UTC, a researcher reports a permissionless drain against a live contract. The main bounty platform is unavailable. One signer is traveling. The primary RPC provider is degraded. A small exploit transaction has already confirmed. The suspected attacker address has a possible sanctions nexus. Rumors are spreading publicly.
The exercise should demonstrate that the team can:
- Receive the report through a backup channel.
- Preserve the original evidence.
- Assign critical severity and an incident commander.
- Determine the exposed value and affected deployments.
- Reach the required signer quorum.
- Construct, verify, and broadcast the containment transaction through backup infrastructure.
- Issue an accurate user notice.
- Notify relevant vendors and counterparties.
- Segregate and screen any recovered assets.
- Record legal, sanctions, insurance, and regulatory decisions.
- Apply explicit restart conditions.
- Produce a remediation register with accountable owners.
Pass condition: No critical action depends on an unnamed owner, an untested signer, an unavailable vendor, an unknown recovery address, or a legal question first discovered during the exploit.
Failure condition: The team can describe what it intends to do but cannot demonstrate authority, access, execution, evidence preservation, or fallback capability.
Residual risk and board conclusion
Residual risk: Attackers may exploit faster than monitoring can detect, pause controls may fail, signers may be compromised, counterparties may refuse assistance, recovery may be legally constrained, and some losses may remain irreversible. These risks should be quantified, funded, insured where practical, and explicitly accepted rather than concealed inside technical assumptions.
The incident-response chain is only as strong as its weakest handoff.
A bounty without triage is a mailbox. Threat intelligence without decision authority is observation. A pause without available signers is theatre. Recovery without custody and compliance controls can create a second incident. A post-mortem without verified action closure is documentation, not remediation.
The correct time to resolve ownership, liability, data handling, outage fallback, signer availability, recovery authority, and vendor survivability is before a researcher or attacker forces those questions into the same hour.