PR with payload

https://github.com/BalancerMaxis/multisig-ops/pull/1892

Tenderly simulation available here.

Abstract

Following our initial post, we’re proposing to roll out a new feature that boosts both flexibility and security: the Sub-Roles Modifier architecture.

The core benefits for the DAO—enabling the Swapper and Disassembler roles—remain unchanged from our previous posts. This updated version proposes a change in how these roles are managed—introducing a modular architecture that separates role execution from governance-level permissioning.

Rather than requiring a separate governance proposal for every sub-role update, the proposed structure allows the existing Manager Safe to manage sub-role creation, setup and updates directly. However, any transaction initiated through these sub-roles must still pass through the existing Manager Roles Modifier, meaning that the change is purely for efficient management of existing permissions, rather than permission creation or amendment.

This setup reduces the need for future DAO interactions, whilst retaining our existing guarantee that any transaction or function call outside the defined Manager Role cannot be executed—making it easier for the DAO to monitor and audit operations with confidence.

Motivation

The sub-roles setup brings several operational benefits:

• Streamlined Operational Control Agile execution roles can be spun up, adding responsiveness for edge-case scenarios, without having to duplicate permissions that are already in the Manager Roles contract.
• Clear Separation of Duties With sub-roles, we can define tightly-scoped permissions for different agents (i.e. Disassembler, Swapper and/or Harvester agents) while still routing all transactions through the Manager Roles Modifier. This maintains all the existing permissions in one place, but without sacrificing flexibility in having to reset permissions from the Avatar Safe every time an agent is added or changed.
• Simplified Deployment & Management The Avatar Safe deploys a Sub-Roles Modifier as a module in the Manager Roles once. The target of the sub-roles will be the parent Manager Role, and the owner will be the Manager Safe. This way, the Manager Safe can handle maintenance on all sub-roles without the need to seek additional permissions from the Avatar Safe.

In the above flowchart you can see that any sub-role that is set up in the lower level can initiate a transaction through different agents. But regardless of how the transaction is initiated, the calldata’s arguments will need to fit within the previously-allowed/listed permissions granted to the existing Manager Role.

For example: a “Harvester EOA” could be automated to routinely claim all reward tokens on the managed treasury through the “Harvester Role”; subsequently, a “Swapper EOA” could be automated to routinely swap all claimed tokens for ETH using the “Swapper Role”. These actions will be executed on the Avatar Safe so long as the permissions exist on the Manager Role. The primary benefit is that these automations can then be configured, amended or even disabled independently with complete flexibility (within the scope of existing permissions), allowing for granular management of each operation.

These sub-roles can be configured as part of our internal execution app allowing greater flexibility and granular control with minimal effort and risk. The benefits were described in the first iteration of this proposal.

Technical implementation

The process involves deploying a new Sub-Roles Modifier, configuring it as a sub-role of the existing Roles contract, and assigning it the appropriate permissions. Here’s what happens under the hood:

1. Deploy ZRM B via ModuleProxyFactory.
2. Enable ZRM B as a module in ZRM A (existing Manager Roles).
3. Set the default role for ZRM B inside ZRM A.
4. Assign ZRM B to the MANAGER role in ZRM A.
5. Configure ZRM B to target ZRM A.
6. Transfer ownership of ZRM B from the Avatar Safe to the Manager Safe.

Upon execution of this payload, the Manager Safe will then have full power to create and amend sub-roles under ZRM B, within the existing permissions defined already under ZRM A. No further action is required to implement the sub-roles architecture beyond this payload.

Avatar Safe: 0x0EFcCBb9E2C09Ea29551879bd9Da32362b32fc89
Sub-Roles Modifier (ZRM B): 0xae7ee392Fd7C8aE7391b4Fc10fc4b942A994545C