1. Overview:
Grant GUARDIAN_ROLE and set a guardian expiration on HyperEVM, bringing it in line with the four chains covered by SIP0.2/SIP0.3. Two calls per guardian on HyperEVM’s ProtocolAccessManager, executed from the Base governor and relayed via LayerZero.
HyperEVM currently has no active guardians, so the two HyperEVM Fleets have no emergency pause capability, the only chain in that position.
2. Motivation:
HyperEVM was added after the Guardian Module was established and was not included in the SIP0.2 grant or the SIP0.3 renewal, which covered four chains. FleetCommander.pause() is onlyGuardianOrGovernor. With no active guardian, the only path is a full governance cycle 5 days today.
Two things are needed, and granting the role alone is not enough. isActiveGuardian requires hasRole(GUARDIAN_ROLE, account) && guardianExpirations[account] > block.timestamp. grantGuardianRole only sets the role; the expiration defaults to 0, leaving the guardian permanently inactive. A grant without a matching setGuardianExpiration is a no-op in practice.
3. Specification:
| Parameter | Value |
|---|---|
| Network | HyperEVM (chain ID 999) |
| Contract | ProtocolAccessManager — 0x38fB5a7fa70103dCd9e8A969f3975A77E0fE755f |
| Authority | onlyGovernor / onlyRole(GOVERNOR_ROLE) → executes via the HyperEVM Timelock |
| Execution | Base governor → LayerZero → HyperEVM timelock (0x244c6EFC140b9cC4D69d3bf4d9137Dc4195Be86c) |
| Risk level | Low–Medium (role grant; mirrors the existing guardian mandate) |
3.1 Call order: both calls, in this order, per guardian
Call 1: grant the role
| Parameter | Value |
|---|---|
| Function | grantGuardianRole(address account) |
| Target | 0x38fB5a7fa70103dCd9e8A969f3975A77E0fE755f |
| Account | 0x91E4482CF58aC14d8DC25290d828b2A4D9492BA4 |
Call 2: set the expiration (without this the guardian is inactive)
| Parameter | Value |
|---|---|
| Function | setGuardianExpiration(address account, uint256 expiration) |
| Target | 0x38fB5a7fa70103dCd9e8A969f3975A77E0fE755f |
| Account | 0x91E4482CF58aC14d8DC25290d828b2A4D9492BA4 |
| Expiratio | 1800000000 |
3.2 Choosing the expiration value
setGuardianExpiration validates expiration - block.timestamp against:
| Bound | Value |
|---|---|
MIN_GUARDIAN_EXPIRY |
7 days |
MAX_GUARDIAN_EXPIRY |
180 days |
The argument is an absolute unix timestamp, and the bound is checked against block.timestamp at execution, not at proposal time.
3.3 Verification after execution
On the HyperEVM ProtocolAccessManager:
hasRole(0x55435dd261a4b9b3364963f7738a7a662ad9c84396d64be3365284bb7f0a5041, <guardian>)→trueguardianExpirations(<guardian>)→ the intended timestampisActiveGuardian(<guardian>)→truethis is the one that matters
4. Risk Assessment:
- Technical. Two role-management calls on an existing contract. No funds move.
- Relay dependency. Execution depends on the Base → HyperEVM LayerZero path. This path has been exercised, SIP0.4 included HyperEVM revocations.
- Privilege expansion, bounded and intended. Guardians gain pause authority over the two HyperEVM Fleets. This is the same mandate the DAO already approved on four chains, with the same set and the same automatic expiry. Guardians cannot cancel guardian-expiry proposals at either the Governor or Timelock layer, so they cannot entrench themselves.
- Reversible.
revokeGuardianRole(address)(0x4b4b5389) via a fresh SIP; powers also lapse automatically at expiry.
5. Voting:
If YES - grant
GUARDIAN_ROLEand set a guardian expiration on HyperEVM for the confirmed SIP0.3 guardian set.
If NO - leave HyperEVM without an active guardian.
Tagging @Recognized_Delegates for a checkup as always.
–jensei