[BIP-XXX] Deploy kpk Sub-Roles architecture

General Chat Karpatkey Updates
1

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.

SubRoles1
SubRoles13000×1687 258 KB

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:

SubRoles2
SubRoles2759×276 5.33 KB

  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

2

Update for transparency:

We want to share the following Tenderly simulation using Virtual TestNets to showcase how Sub-Roles functions using a test EOA and Roles.

The simulation covers:

  1. Deployment and configuration of the Sub-Roles Modifier (first 8 transactions starting from the “deployModule” up; these are the same actions than the ones in the PR for this proposal).
  2. Assigning a sample EOA (0x5c0c7…ae43) to a new MANAGER role (9th txn).
  3. The following 2 transaction (10th and 11th) apply the policy to the MANAGER Role of the Sub-Roles Modifier, allowing the approval of wstETH with the Aave V3 Core Pool as spender.
  4. A successful transaction execution through the sub-role (approving wstETH with the Aave V3 Core Pool as spender).
  5. A failed transaction that correctly reverts due to insufficient permissions (attempting to approve USDC for the Aave V3 Core Pool, where only wstETH is allowed).

We hope these simulations help clarify the Sub-Roles architecture and its functionalities. As always, we’re happy to receive any questions or feedback.