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.
