Smart contracts implement emergency mechanisms in incompatible ways: some expose a binary paused flag, others use bespoke state variables with custom names and semantics, and many expose no observable emergency state at all. There is no standard interface for external systems to query whether a contract is in an emergency condition or how severe it is.
This creates concrete gaps:
Cross-Protocol Risk Management: Many contracts expose no observable emergency state. Those that do use incompatible approaches, making cross-protocol detection costly and automated response to third-party risk effectively impossible.
User Safety: Without a standard interface, wallets and frontends cannot generically detect emergency conditions. Users interact with distressed contracts with no warning.
Automated Monitoring: Security infrastructure cannot query emergency status across contracts in a uniform way. Monitoring systems must be individually configured for each protocol, increasing operational overhead and the chance of missed alerts.
This ERC is designed for observing smart contract emergency states, enabling interoperable detection across protocols. It defines a standard interface for observing emergency states in smart contracts, provides a multi-level emergency state indicator and a timestamp of the most recent state change.
Please feel free to leave any suggestions or discussions.
Hello,
Thank you for your proposal. Quick questions and feedbacks
Why use uint8 instead of uint256?
Using uint8 reduces the number of possible emergency states, and it may not provide any gas savings. Since the EVM operates on 256-bit words, using smaller integer types can sometimes introduce additional casting or masking operations, which may slightly increase runtime gas costs. Unless storage packing is a consideration, uint256 seems better
b) Naming of the emergency state
For the emergency state in this example, would Paused be a better name than Frozen? Paused is the more commonly used term across protocols for emergency-stop functionality, particularly due to the use of OpenZeppelinās Pausable pattern.
Regarding the first question, the reason we chose uint8 (256 states) is that limiting emergency operations is crucial and effective, preventing abuse or errors caused by the excessive complexity of state options.
As for question 2, we only provided this state definition as an example. However, you make a point, āPauseā is indeed more commonly used, and we will consider this suggestion. Thank you again.
Thanks for the question. We agree that pausing or shutting down a protocol are effective mechanisms, and in many scenarios, they may be sufficient.
However, consider a stablecoin system where only the minting key is compromised. Globally suspending all functionality (e.g., transfers and redemptions) could cause greater disruption ā and potentially pose a greater threat to business continuity ā than the original incident itself.
This brings us to the core motivations behind this EIP:
First, it encourages protocols to pre-define incident scenarios and proportionate response playbooks during the develop or design stage, rather than improvising a blanket shutdown during a crisis.
Second, and more importantly, it introduces an observation layer, allowing wallets, monitoring systems, and dependent protocols to detect emergencies through a common on-chain interface and apply their own policies.
The goal is not to introduce innumerous emergency states, but rather to support the smallest set of meaningful, documented states that are interoperably observable and that a protocol actually needs .
I hope this clarifies the motivation behind the proposal.
