— A Coordinated Set of ERC Standards for On-Chain Security
Introduction
Smart contract security today is fragmented. Contract inventories to track deployment status are absent in many protocols. Protocols define privileged roles with inconsistent naming conventions. Emergency mechanisms lack a common interface across protocols. When incidents happen, responders improvise against contracts whose security behavior was never formally specified.
These are not independent problems. They share a common root cause, the absence of a coherent set of interoperable standards that cover the full security lifecycle of a smart contract, from how roles are defined and governed, to how emergencies are detected and resolved.
We introduce a coordinated set of ERCs that addresses these gaps. This post presents the framework as a whole and invites the community’s feedback.
What is PRCF?
PRCF is a coordinated set of composable ERC standards that govern smart contract privileged access from role definition through incident response.
Smart contract inventory: Organizations lack reliable visibility into their deployed contracts, leaving abandoned but callable contracts as permanent attack surface. A shared on-chain registry tracks deployed contracts through their lifecycle, providing the inventory foundation for organization-wide governance.
Defining and unifying role standards: Protocols currently define privileged roles with inconsistent naming and semantics, rendering cross-protocol monitoring and auditing impractical. PRCF standardizes how roles are named and what they mean, ensuring every compliant contract speaks the same access control language.
Restriction on roles: Key compromise currently results in immediate and permanent access with no defense window. PRCF introduces tier-level operation limits, time-bound role expiry, mandatory grant delays, and operation timelocks, ensuring no privilege is permanent, instant, or unmonitored.
Emergency response: Emergency mechanisms are currently contract-specific, requiring ad hoc response procedures during incidents. A pair of ERCs covers the full emergency lifecycle from observation to action to recovery, enabling predictable and standardized emergency response across any compliant contract.
These four areas form a connected system. Role standards define the expected permission model. Restrictions enforce temporal constraints on those defined roles. Emergency response acts when those constraints are breached. The shared registry unifies all three across contracts.
Each ERC is independently adoptable. Protocols can implement any subset. Together, they form a complete security foundation where every compliant contract speaks the same access control language and exposes the same emergency interface, making organization-wide governance possible without custom per-contract integration.
Framework Overview
ERC-8089: Smart Contract Lifecycle Registry
└── covers all contracts
└── Single Contract
├── Role Branch
│ ERC-XXXX-Naming: Contract Role Naming Standard
│ → ERC-XXXX-Semantics: Contract Role Semantics Standard
│ → ERC-XXXX-Restriction: Operation Restriction Policy for Tiered Permissions
│ ├── ERC-8083 Time-Bound Access Control Interface
│ ├── ERC-8305 Time-Delayed Access Control
│ └── ERC-8306 Role-Based Timelock Operation
└── Emergency Branch
ERC-8308: Smart Contract Emergency Response
→ ERC-8307: Smart Contract Emergency State
Pre-Incident — Prevent Key Compromise
- ERC-8089 tracks all deployed contracts so no forgotten contract becomes an unnoticed attack surface.
- ERC-XXXX-Naming and ERC-XXXX-Semantics define role privileges clearly, making unauthorized role usage detectable.
- ERC-8083 forces regular key rotation through expiry timestamps, reducing the window a stolen key remains valid.
- ERC-XXXX-Restriction applies operational limits per role, bounding what a compromised key can do.
Ongoing / Post-Incident — Reduce Impact of Key Compromise
- ERC-8305 delays role grants, giving time to detect and cancel unauthorized grants made with a compromised key.
- ERC-8306 delays high-impact operations, giving time to intercept malicious transactions before they settle.
- ERC-8308 enables rapid emergency response through a standardized interface, reducing time to contain the breach.
- ERC-8307 emits on-chain alerts that signal distress to all integrators, reducing cascading impact across protocols.
The EIPs
Layer 1 — Contract Inventory
ERC-8089: Smart Contract Lifecycle Registry
Before you can manage the security of your contracts, you need to know what contracts you have. ERC-8089 defines a standard on-chain registry interface where organizations register their deployed contracts and track their lifecycle status: Default, Active, Deprecated, Frozen, or Terminated.
This addresses a systemic gap. Security teams regularly lose track of deployed contracts, leaving abandoned but callable contracts as permanent attack surface. ERC-8089 provides the inventory layer that all other security work depends on.
Discussion: https://ethereum-magicians.org/t/erc-8089-smart-contract-lifecycle-registry/26641
Layer 2a — Role Management
Role management is the innermost concern of a single contract’s security posture. We propose a pipeline of ERCs that build on each other:
[ERC-XXXX-Naming]: Contract Role Naming Standard
Standardizes how privileged roles are named using hierarchical namespaces with deterministic hash derivation. All identifiers follow the role.{category}.{action} structure in lowercase, yielding consistent keccak256 hashes across all protocols. Auditors and monitoring tools no longer need to reverse engineer semantics from bespoke role names.
Discussion: https://ethereum-magicians.org/t/erc-xxxx-contract-role-naming-standard/28756
[ERC-XXXX-Semantics]: Contract Role Semantics Standard
Naming a role is not enough. This ERC derives security semantics directly from the standardized naming structure, including tier classification and authorization sources. It enables automated risk assessment by determining what tier a role occupies and whether a given combination of roles is safe to hold simultaneously.
Discussion: https://ethereum-magicians.org/t/erc-xxxx-contract-role-semantics-standard/28757
[ERC-XXXX-Restriction]: Operation Restriction Policy for Tiered Permissions
Existing access control standards define which addresses hold which roles, but provide no mechanism to manage security policies across roles. This ERC introduces Groups as a policy management layer. Roles bound to a Group inherit its default security requirements, such as time-bound expiry, grant delays, and operation timelocks. This enables organizations to define security policies once at the Group level and ensure consistent enforcement across all associated roles.
Discussion: https://ethereum-magicians.org/t/erc-xxxx-operation-restriction-policy-for-tiered-permissions/28793
With roles named, defined, and restricted, three further ERCs govern their lifecycle:
ERC-8083: Time-Bound Access Control Interface
Binds an expiryTimestamp to every role grant. When the timestamp passes, hasActiveRole() returns false automatically, requiring no manual revocation. This eliminates the silent accumulation of stale permanent roles from vendors, contractors, and former staff.
Discussion: https://ethereum-magicians.org/t/eip-8083-time-bound-access-control-interface/26516
ERC-8305: Time-Delayed Access Control
Introduces configurable waiting periods between when a role change is initiated and when it takes effect, applying to both grants and revocations. This creates a defense window against key compromise. If an attacker steals a privileged key and attempts to grant themselves a role, the delay gives the organization time to detect and cancel it before the grant becomes active.
Discussion: https://ethereum-magicians.org/t/erc-8305-time-delayed-access-control/28741
ERC-8306: Role-Based Timelock Operation
Extends the delay model to operations themselves. Even a legitimately held role should not be able to execute high-impact operations instantaneously. This ERC introduces per-role configurable delays on privileged operations, requiring them to be scheduled first and creating a response window before irreversible actions settle.
Discussion: https://ethereum-magicians.org/t/erc-8306-role-based-timelock-operation/28742
Layer 2b — Emergency Management
ERC-8308: Smart Contract Emergency Response
Standardizes the action interface for emergency response. triggerEmergency(uint8 emergencyState) and resolveEmergency(uint8 emergencyState) allow any monitoring system or automated responder that knows this interface to trigger or resolve an emergency on any compliant contract without needing to know the contract’s internals. Adopting this ERC ensures that every contract implements an emergency response function, guaranteeing the existence of a callable response mechanism at deployment time.
ERC-8307 and ERC-8308 are designed as a pair. triggerEmergency() sets the observable state that ERC-8307 exposes. resolveEmergency() resets it to 0. Together they cover the full emergency loop from observe to act to recover.
Discussion: https://ethereum-magicians.org/t/erc-8308-smart-contract-emergency-response/28750
ERC-8307: Smart Contract Emergency State
Standardizes the observation interface for emergency conditions. emergencyState() returns a uint8 (0 = normal, 1–255 = implementer-defined states), lastEmergencyStateUpdateAt() returns the timestamp of the most recent state change, and EmergencyStateChanged is emitted on every transition.
Today, contracts implement emergency state indicators in incompatible ways, or expose none at all. Without a standard interface, wallets cannot warn users, monitoring systems cannot query contract health, and cross-protocol risk detection is effectively impossible.
Discussion: https://ethereum-magicians.org/t/erc-8307-smart-contract-emergency-state/28748
Reference Implementation
Coming soon…
ERCs in This Framework
| ERC | Title | Description |
|---|---|---|
| ERC-8089 | Smart Contract Lifecycle Registry | On-chain registry tracking the existence and lifecycle status of deployed contracts |
| ERC-XXXX-Naming | Contract Role Naming Standard | Standardizes role naming with hierarchical namespaces for machine-parseable role identifiers |
| ERC-XXXX-Semantics | Contract Role Semantics Standard | Defines the meaning behind role names including authorized operations and tier boundaries |
| ERC-XXXX-Restriction | Operation Restriction Policy for Tiered Permissions | Enforces tier-level operation restrictions regardless of which roles a caller holds |
| ERC-8083 | Time-Bound Access Control Interface | Binds an expiry timestamp to every role grant, automatically invalidating stale roles |
| ERC-8305 | Time-Delayed Access Control | Introduces mandatory delays between role grants and when they take effect |
| ERC-8306 | Role-Based Timelock Operation | Enforces mandatory delays before high-impact privileged operations execute |
| ERC-8308 | Smart Contract Emergency Response | Standardizes the interface for triggering and resolving emergency stop-loss actions |
| ERC-8307 | Smart Contract Emergency State | Defines observable emergency states with standardized state transition events |
We’d Like Your Feedback
We are sharing this as a framework overview because we believe the value of these ERCs is greater as a coordinated set than as individual proposals. We welcome feedback on the framework as a whole and on each individual ERC. Whether you want to identify gaps, suggest improvements, or express interest in adopting these standards in your own protocols, we encourage you to comment on the threads linked above.
We are actively working through the review and submission process for the remaining ERCs. Feedback at this stage will directly shape the final proposals.
By Ant International Web3 Security
(@kennyk10, @77eff, @baishuo13)