Discussion 2: Separation of Emergency Response Interface (this ERC) from Emergency State Interface
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.