[RFC] Revoke SuperKeeper Roles Across All Networks

General Discussion Request for Comment [RFCs]
, , ,
1

1. Summary:

Revoke the global SUPER_KEEPER_ROLE on ProtocolAccessManager across all networks (Ethereum, Base, Arbitrum, Sonic, and HyperEVM), ensuring that legacy keeper addresses no longer retain un-scoped administrative or automated maintenance permissions across protocol contracts.

Execution will be performed via a set of revokeSuperKeeperRole(account) calls on each chain’s ProtocolAccessManager, bundled into a single cross-chain governance SIP using the established Base Hub Governor → LayerZero relay architecture.

2. Context & Motivation:

What the role does. SUPER_KEEPER_ROLE (0x0d186688925976bbe6755ae984501c8e3e2b103a7af59fd803ab9c6d891ae7e0) is a global, un-scoped role on ProtocolAccessManager. Unlike contract-specific keeper roles (which are scoped to individual Fleets or Arks), the SUPER_KEEPER_ROLE grants global execution privileges across all contracts managed by ProtocolAccessManaged.

Why it becomes vestigial. With the protocol transitioning to modular, contract-scoped access controls and the progressive neutralization of active rebalancing/curation components, global keeper authority is no longer required. Ongoing maintenance operations (where applicable) have moved to explicit, least-privilege contract-level scopes. Standing global super-keeper permissions have no remaining operational mandate.

Why revoke rather than leave dormant. As established during the security reviews and operational realignments, dormant-but-active roles represent unnecessary attack surfaces. Leaving global maintenance permissions assigned to historical addresses creates long-term risk. The desired end-state for DAO contracts is minimal privilege, retaining only deliberately scoped and actively monitored roles.

Why now. In alignment with recent governance initiatives (RFC: Revoke Curator Roles Across All Fleets and SIP0.4), revoking historical operational roles across all chains cleanly establishes the protocol’s hardened posture.

3. Proposal & Technical Details:

Role Holders to Revoke

On-chain and subgraph inspection across all active chains identifies two addresses holding SUPER_KEEPER_ROLE:

  1. 0x452487d71a4e94282bae30265aac9ca26a775f29
  2. 0xc2a8467a52fec8383c424149000cf384de9ba1b5

Execution Interface

On each network’s ProtocolAccessManager, the Governor will execute:

ProtocolAccessManager.revokeSuperKeeperRole(address account) // onlyGovernor

Networks and Target ProtocolAccessManagers

Network Chain ID ProtocolAccessManager Address Accounts Revoked
Base (Hub) 8453 0xf389BCEa078acD9516414F5dabE3dDd5f7e39694 0x4524...5f29, 0xc2a8...a1b5
Arbitrum 42161 0xf389BCEa078acD9516414F5dabE3dDd5f7e39694 0x4524...5f29, 0xc2a8...a1b5
Ethereum 1 0xf389BCEa078acD9516414F5dabE3dDd5f7e39694 0x4524...5f29, 0xc2a8...a1b5
Sonic 146 0xAFb8a8beA8F7CdB4b65437b0c5963dc7Cd270bC6 0x4524...5f29, 0xc2a8...a1b5
HyperEVM 999 0x38fB5a7fa70103dCd9e8A969f3975A77E0fE755f 0x4524...5f29, 0xc2a8...a1b5

Governance Mechanism

  • Base (Hub): Direct execution via Timelock Controller calling revokeSuperKeeperRole on Base ProtocolAccessManager.
  • Satellite Chains: Base SummerGovernorV2 calls sendProposalToTargetChain over LayerZero to dispatch the revocation calls to each satellite chain’s Timelock.

4. Next Steps:

  1. Collect feedback from @Recognized_Delegates and the community.
  2. Confirm no critical automated maintenance script strictly depends on un-scoped global SuperKeeper credentials.
  3. Promote to an on-chain SIP with pre-verified calldatas and simulations.

5. Informal Support Indicator:

  • YES - Revoke all global SuperKeeper roles across all networks
  • NO - Leave the roles granted
  • Abstain / Need more information
0 voters
2 Likes
2

Thanks for putting this together, @halaprix. I support this proposal with the protocol moving toward a more limited operational footprint, there is little reason to retain broad, un-scoped administrative permissions that are no longer required.

Are there any necessary actions that we should take before the revoke, or will the timelock remain in the role and be able e.g.: authorize an operator to claim Merkl rewards, conduct raft harvests, and shake all tip jars?

1 Like