Smart contract exploits, particularly those involving key compromise, unauthorized privilege escalation, and other on-chain attacks, frequently complete within a single transaction or a handful of blocks. The response window is measured in seconds. Yet the current state of practice treats emergency response as an operational concern addressed after deployment: contracts implement emergency capabilities ad-hoc, with inconsistent function names, inconsistent event structures, and no shared interface for external systems to rely on.
This creates compounding failures across the smart contract development lifecycle:
At design time: Security architects cannot pre-design response procedures for an interface that does not yet exist.
At audit time: Auditors cannot verify emergency response behavior against a standard. They must reverse-engineer intent from bespoke implementations.
At operation time: Automated monitoring systems cannot trigger or observe pre-authorized responses through a known interface, because no known interface exists.
At incident time: Responders improvise under pressure, calling functions they may not have tested, against contracts whose emergency behavior was never formally specified.
The result is that organizations with sophisticated detection capabilities are still slow to respond, because the response path was never standardized.
In this ERC, we introduces a minimal standard interface for smart contracts that require on-chain emergency response capabilities. The interface mandates two external functions that implementing contracts must expose, each accepting a numeric parameter that selects which branch of response or recovery logic to execute, and a corresponding event that must be emitted each time those functions are called.
Please feel free to leave any suggestions or discussions.
Discussion 1: Relationship to Circuit Breaker ERCs (e.g., ERC-7265)
ERC-7265 defines a threshold-triggered, automated circuit breaker for protocols. It acts as a rate-limiting pass-through for token outflows: when the cumulative value of withdrawals exceeds a registered threshold within a cooldown window, the circuit breaker activates and either delays or reverts further outflows.
Our proposal addresses a fundamentally different concern. The two standards are complementary, not competing.
Key Differences
ERC-7265 solves the problem of automated, metric-driven protection: it reacts faster than any human can, but only to the specific threat pattern it was parameterized for (e.g., “if more than X tokens flow out in Y blocks, halt”).
Our proposal solves the problem of human-initiated, general-purpose emergency response: it provides a standardized interface through which authorized responders can invoke pre-defined response procedures against any threat, including those that no automated circuit breaker was designed to catch.
Dimension
ERC-7265 (Circuit Breaker)
This Proposal (Emergency Response)
Trigger mechanism
Automatic — activated when a metric threshold is breached
Manual — invoked by an authorized human or system operator
Scope
Narrow — rate-limits token outflows only
Broad — dispatches any implementer-defined response logic
Primary use case
DeFi protocol capital protection against drain attacks
General-purpose emergency response for any contract type
Who decides the response
The protocol parameters (threshold, cooldown, action)
The authorized caller, selecting a pre-defined response branch
The core motivation behind this ERC is to ensure the protocol has anticipated and prepared for the emergency response plan when they design and before they deploy their smart contracts. This aims to prevent irreversible financial losses, avoiding the pitfalls we have observed in many protocols that suffered attacks due to a lack of adequate response procedures.
This ERC deliberately defines only the response interface — the functions to trigger and resolve emergencies. It does not include functions for querying the current emergency state.
This is not an oversight. State querying capability is provided by a Emergency State Interface (to be cross-referenced once assigned an EIP number), which standardizes how contracts expose their internal state for external observation.
Rationale for Separation
Different audiences.
The emergency action interface serves responders and monitoring systems that need a known entry point to invoke protective actions. This interface must be extremely stable: changing function signatures in an emergency response standard would break every responder integration.
The state query interface serves external protocols, frontends, dashboards, indexers, and off-chain monitoring that need to observe contract state.
Minimal attack surface.
Every additional external function on a contract is a potential attack surface. By keeping the emergency response interface to exactly two functions (triggerEmergency and resolveEmergency), we minimize the review burden on auditors and reduce the surface area that must be access-controlled. State queries are read-only and carry different security properties; they belong in a separate interface.
Composability.
Contracts that implement this Emergency Response Interface can independently choose whether to also implement the Emergency State Interface. The standards compose without requiring either to depend on the other.
