[BIP-XXX] Onboard Balancer DAO on karpatkey's Execution App

General Chat Karpatkey Updates
1

Abstract

The Execution App, developed by karpatkey, addresses the need for rapid, error-minimised execution in high-pressure situations such as hacks, exploits, and governance attacks. These time-sensitive and high-risk scenarios are common in DeFi and DAO governance. The Execution App supports treasuries that are managed via Zodiac Roles Modifier (ZRM) by enabling swift execution of disassembling strategies through a reliable user interface (UI).

The Execution App is a powerful infrastructure for emergency scenarios, but also serves as a powerful tool to streamline day-to-day operations.

Motivation

The Execution App is a Asset Management tool built to respond quickly to unexpected events. The DAO can choose to pre-approve any exit-strategies to interact with protocols used for Agile Execution, through which the Execution App can address the following pain points:

  • Minimising human error: With predefined actions in place, the Execution App significantly improves reaction time and reduces the likelihood of mistakes when constructing complex payloads in time-sensitive or high-stakes situations.
  • Reducing UI dependency: In unfortunate situations, protocol UIs often become overwhelmed by heavy user interactions, causing lag or even shutdowns. The Execution App mitigates these risks by moving execution tasks to a secure and consolidated app, reducing reliance on vulnerable UIs.
  • Bypassing Multisignature process: When time is of the essence, multisig execution can be slow and cumbersome. The Execution App enables Asset Managers to quickly and efficiently move funds out of DeFi positions.

DAOs currently using the Execution App; Gnosis & karpatkey.

Specification

Setup

The Execution App incorporates EOAs assigned specific agile roles, which are granted specific permissions through the Zodiac Module, in order to execute pre-designed strategies including:

  • Withdrawing funds.
  • Unstaking assets from liquidity pools or staking protocols.
  • Repaying any outstanding debt and subsequently withdrawing collateral.
  • Executing token swaps to convert assets into more desired or stable forms.

A selection of these strategies is proposed to the Balancer DAO for approval. Once approved, they can be executed by the designated Execution App address.

Execution

Once set up, execution is carried out through a UI available to AMs, which generates all necessary transaction payloads with simple, clear, and streamlined actions based on the configuration.

  1. Landing page:

executionapp
executionapp1882Ă—939 72.7 KB

  1. Choose position & the exit strategy:

strategybalancer
strategybalancer1888Ă—927 47.1 KB

  1. The Execution App delivers the payload & Tenderly simulations for execution:

executionbalancer
executionbalancer1902Ă—940 78.3 KB

Private Key Management

To bypass the multi-signature phase during execution, EOAs are configured with allowlisted strategies. This allows EOAs to execute transactions on behalf of the managed treasury at any time, but it is restricted to existing positions only.

Security is our top priority, and so is private key management. We use a vault infrastructure which generates private keys securely within the vault, ensuring they remain protected and never exposed. Additionally, the infrastructure includes a backup and restore strategy to handle disaster recovery scenarios efficiently.

We want to emphasise that keys are securely stored and cannot be accessed. Even in the unlikely event of a private key leak, the permissions policy will strictly limit execution to pre-approved swaps / strategies for disassembling or exiting DeFi positions, the keys cannot be used to transfer / withdraw the underlying assets.

Implementation

Given the Avatar’s current permissions policy we suggest adding the following disassembling strategies into the Execution App on behalf of the managed treasury.

  • Holdings (via the Swapper Role).
    • ETH-neutrality:
      • Swap any of [stETH, wstETH, rETH, WETH, oETH, osETH] for [ETH, WETH] on [CoW, Uniswap, Balancer, Curve].
    • USD-neutrality:
      • Swap any of [DAI, USDT, USDC, GYD, sDAI, GHO, stkGHO, USDS, sUSDS] for [DAI, USDT, USDC] on [CoW, Uniswap, Balancer, Curve].
    • Wrap and unwrap ETH.
  • DeFi positions (via the Disassembler Role).
    • Maker DSR
      • Withdraw DAI from the DSR Manager.
    • RocketPool
      • Unstake rETH for ETH.
    • Lido
      • Unstake stETH /wstETH for ETH.
    • Aave V3
      • Withdraw USDC / USDT / DAI from Aave market.
      • Redeem GHO from stkGHO contract.
    • Compound V3
      • Withdraw USDC from the comet.
    • Curve
      • Withdraw oETH & ETH from LP position.
    • Origin Protocol
      • Withdraw staked ETH via ARM and vault.
    • Spark
      • Withdraw USDS from Sky savings rate.
    • Stakewise
      • Withdraw staked ETH from Genesis Vault.
    • Uniswap V3 WETH-WBTC
      • Collect fees
    • Gygroscope
      • Redeem underlying GYD from the Savings contract.

Payloads

[Swapper Permission Policy Setup]

This payload executes the following actions, all at once, to setup the Swapper setup:

  • Create the SWAPPER Role.
  • Assign the Swapper EOA to the Swapper Role as a member.
  • Apply the Permission Policy to the SWAPPER Role.

Tenderly Simulation available here.

Permissions page: https://roles.gnosisguild.org/permissions/eth/s0m8BXPrrs4yg9fnmluqD6XfWuaVlXtSQxaXO7YoQ?annotations=false

Permissions diff page: https://roles.gnosisguild.org/eth:0x13c61a25DB73e7a94a244bD2205aDba8b4a60F4a/roles/SWAPPER/diff/s0m8BXPrrs4yg9fnmluqD6XfWuaVlXtSQxaXO7YoQ?annotations=false

[Disassembler Permission Policy Setup]

This payload executes the following actions, all at once, to setup the Disassembler setup:

  • Create the DISASSEMBLER Role.
  • Assign the Disassembler EOA to the DISASSEMBLER Role as a member.
  • Apply the Permission Policy to the DISASSEMBLER Role.

Tenderly Simulation available here.

Permissions page: https://roles.gnosisguild.org/permissions/eth/d1IYmypoi3riIdQO18t3Cg5jkl1GymkW4Z33RiI?annotations=false

Permissions diff page: https://roles.gnosisguild.org/eth:0x13c61a25DB73e7a94a244bD2205aDba8b4a60F4a/roles/DISASSEMBLER/diff/d1IYmypoi3riIdQO18t3Cg5jkl1GymkW4Z33RiI?annotations=false

*Note: because these are new roles, the permissions page and permissions diff page are the same, i.e. there is nothing on the left hand side of the permissions diff page.

2

Hey team, thanks for the proposal, could you explain a little bit more about how this would work with a practical example? I guess I’m wondering at what point do these exit strategies txs get executed. Is there monitoring tools looking out for certain on-chain events to signal someone to create a private key in order to start taking action or is Karpatkey waiting for someone(s) specifically to give an OK? Maybe there are multiple.

Also, in terms of the private key management piece, does it essentially work that someone on a whitelist can signal your vault to create a private key that can be used to take action? Can that one private key be used to exit all positions or is it one key per strategy? I assume it is the former but wanted to ask.

3

Bypassing Multisignature process

isnt the current setup already created in such a way that there is no multisignature process needed? for example the eth or usd swap permissions were reviewed in bip-748. what is the added value of giving these to another role/eoa? why cant the permissions currently in place be used for emergency actions as well?

this looks like a lot of (double) work; reviewing permissions which are technically already in place. what am i missing?

4

@zekraken @gosuto

Thank you for your feedback, we greatly value the insights and questions you’ve shared. The following should provide clarity on the structure and use cases for the Execution App.

Setup:

The managed Treasury, also known as the Avatar Safe, currently requires a 6/11 signer threshold to execute transactions and is solely owned by the BalancerDAO, with the same signature scheme as the Main Treasury. In contrast, the Manager Safe, the owner of the Avatar’s Manager Role, is solely owned by karpatkey and can execute transactions with a 2/8 threshold. Permission changes, such as those introduced by BIP-784, directly affect the permissions assigned to the Manager Role.

This proposal suggests implementing a parallel setup within the Avatar Safe. It introduces two new roles: Disassembler and Swapper. These roles will be assigned to an Externally Owned Account (EOA) that requires only a single signature to execute transactions on behalf of the Avatar Safe.

Use cases:

This setup is designed as a contingency measure for rare and critical scenarios. If an on-chain event triggers an alert in our risk system or a team member identifies a potential exploit, Asset Managers can take immediate action without relying on:

  • dApp interfaces.
  • Tools to construct complex payloads.
  • Availability of additional signers in a timely manner.

Transactions will be executed through a custom UI and signed using the EOA. As highlighted by @zekraken, allowlisted team members will have the ability to initiate necessary transactions via this EOA, which operates with a single private key (PK) for all actions included in the two new roles.

Considerations:

It is important to emphasize that the long-term goal for these new roles is to integrate them directly with our risk management system, eliminating the need for human intervention entirely. This represents an intermediate step that brings us closer to achieving our vision.

The permissions being added to the new roles are specifically designed to enable a faster and safer exit from riskier asset classes or positions. Even in the event of EOA compromise, its capabilities will be highly restricted to exit positions only, ensuring that no malicious actions can be executed. This safeguard will protect the Treasury’s Assets Under Management (AUM) from any adverse impact.

5

From what I can gather the downsides currently outweigh the upsides for following reasons:

  • duplication of work for zodiac roles modification reviews - they are already very time consuming as is
  • added risk vectors for having EOAs control actions, even if it is only withdrawals
  • Alternative Solutions Available: The stated goals could be achieved by optimizing existing processes:
    • The current 2/8 signer setup through the Manager Safe could be enhanced with better internal procedures for rapid response
    • Risk management system integration could be implemented using the existing permission structure without introducing new roles
  • Can you clarify more where this system is used in PROD? - while Gnosis and karpatkey are mentioned as current users, it’s unclear whether we would be among the first users
  • The argument for this as an “intermediate step” toward automated risk management seems unnecessary when the same automation goals could be achieved through the existing permission structure

Given these concerns and the availability of less complex alternatives, I cannot currently support implementing these changes. I would appreciate a more detailed explanation of why the existing permission structure and Manager Safe setup cannot meet the stated emergency response requirements.

2 Likes