1. Summary:
Revoke CURATOR_ROLE on every Fleet across all networks, so that once the Fleets are neutralized to withdrawal-only shells, no account retains discretionary allocation authority over them. Execution would be a set of revokeCuratorRole(fleetCommander, account) calls on each chain’s ProtocolAccessManager, promoted as a single-purpose SIP once the role holders are enumerated and the sequencing below is agreed.
2. Context & Motivation:
What the role does. CURATOR_ROLE is a contract-specific role on ProtocolAccessManager, scoped per FleetCommander, granting authority over allocation/rebalancing decisions for that Fleet. It is the operational counterpart to the risk-curation mandate.
Why it becomes vestigial. Under [RFC] Neutralize All Vaults to Withdrawal-Only Shells every Fleet is being reduced to a buffer-only, withdrawal-only ERC-4626 shell with all Arks removed. A Fleet with no Arks has nothing to allocate between: withdrawals are served from the buffer and are user-initiated. The curator mandate has no remaining function.
Why revoke rather than leave dormant. This is the same lesson as the Arks. The July 6 exploit worked because an Ark that was capped to zero was still registered. A dormant-but-granted role is the same shape of problem: a live permission that nothing is actively watching, on a protocol whose risk-management capacity is winding down and whose front-end sunsets on 31 August 2026. The end state the DAO wants is a set of contracts where the only remaining privileged surface is the one it deliberately keeps (the Guardian module, per SIP0.3).
Why now. With the Labs Co. winding down and the transition posture set by [RFC] Operational Realignment for the Transition Period, standing operational mandates should be closed deliberately rather than left granted by default. If the protocol is later relaunched or rebuilt, roles can be re-granted through a fresh SIP as RFC says of the other sunset programs, reinstatement should be a deliberate act, not an inheritance.
3. Proposal:
Step 1 - Enumerate role holders (first deliverable, blocking): Publish, per chain and per FleetCommander, every account currently holding CURATOR_ROLE. revokeCuratorRole takes both a FleetCommander address and an account, so one call is required per (Fleet, account) pair; the call list cannot be written without this enumeration.
Step 2 - Decide the scope: BA only, or all curator holders; curator role only, or other contract-specific roles too.
Step 3 - Execute as a single-purpose SIP:, one proposal per chain (or one batched relay per chain, matching the established Base-governor → LayerZero pattern), with fully-decoded calldata.
ProtocolAccessManager.revokeCuratorRole(
address fleetCommanderAddress,
address account
) // onlyGovernor
ProtocolAccessManager addresses (to verify before encoding)
| Network | ProtocolAccessManager |
|---|---|
| Ethereum | 0xf389BCEa078acD9516414F5dabE3dDd5f7e39694 |
| Base | 0xf389BCEa078acD9516414F5dabE3dDd5f7e39694 |
| Arbitrum | 0xf389BCEa078acD9516414F5dabE3dDd5f7e39694 |
| Sonic | 0xAFb8a8beA8F7CdB4b65437b0c5963dc7Cd270bC6 |
| HyperEVM | 0x38fB5a7fa70103dCd9e8A969f3975A77E0fE755f |
Sequencing:
removeArk is onlyGovernor and therefore executes through the Timelock, not the curator. But the divestment of each Ark to the Fleet buffer, and any rebalancing needed to exit a position cleanly, may run through curator-gated paths. Revoking the curator role before the cleanup completes could therefore leave the DAO unable to perform the exits its own cleanup depends on, and BA would be asked to finish terminal work after losing the permission to do it.
Proposed order: RFC / removals (SIP2.60.X) execute and are confirmed complete → any residual/deferred Arks resolved (e.g. Origin-weth, the Sonic Silo residues, LazyVault_HigherRisk_USDC) → then curator roles revoked. @BlockAnalitica should confirm it needs no curator authority for any remaining step before this executes.
4. Next Steps:
- Gather @Recognized_Delegates feedback and the poll below.
- @BlockAnalitica / @halaprix to publish the per-chain, per-Fleet
CURATOR_ROLEholder table in the discussion below. - @BlockAnalitica to confirm no curator authority is required for any remaining steps.
- Promote to a single-purpose SIP with decoded calldata and Guardian pre-review.
5. Informal Support Indicator:
- YES - revoke all curator roles across all Fleets, after the Ark cleanup completes
- YES - but BA’s curator role only, leaving other holders for a separate proposal
- YES - and extend it to other contract-specific operational roles in the same sweep
- NO - leave the roles granted
- Abstain / Need more information
Tagging @Recognized_Delegates, @BlockAnalitica for a checkup.
–jensei