This proposal seeks BalancerDAO’s approval for updates, new actions, and strategies related to the permissions policy governing the karpatkey-managed treasury on Mainnet. These changes are part of a broader effort to optimise the treasury, with the goal of enhancing its performance, flexibility, and diversification.
Effective treasury management strategies need to be adjusted based on market conditions and protocol updates, such as migrations and the introduction of new pools. Protocols and pools that were once considered immature and unsuitable for the BalancerDAO’s risk appetite can become more viable as they prove their reliability over time. This proposal aims to integrate these new strategies into the existing Permissions Policy.
Changes to the Permissions Policy
This proposal outlines the following modifications to the permissions policy:
GHO Carry Trade
Deposit, sDAI, USDS, wstETH, osETH and WBTC on Aave v3 and allow it to be used as collateral.
why scope cow swap orders so granularly? eg why make it explicit that usds should be swappable to dai but not the other way around? i do not see the added value of this
why scope the tokens for every balancer pool?
why scope curve minter?
why remove permissions already granted, such as the uniswap eth methods?
for the amb bridge; expected value at shift 76 is 0101806401, which for me translates to:
srcChainIdLength: 01 == 1
dstChainIdLength: 01 == 1
dataType: 80 == 128
sourceChainId: 64 == 100
destinationChainId: 01 == 1
do i understand correctly these are thus payloads to bridge from gnosis chain to mainnet? should it not be the other way around? or is this the claiming of a bridge initiated on the gnosis chain side?
resources
to be able to continue doing proper reviews, without it costing us too much time, i suggest that going forward the zodiac roles ui is updated to at least have:
proper decoding for all function selectors
the option to use an (external) address book for labelling addresses (for example the same way the avatar is labelled as AVATAR). a tooltip or something like that could then show the original hex data
We greatly appreciate the effort involved in auditing these payloads. We recognise that they are intricate and require substantial time to evaluate thoroughly.
As for your concerns:
Unverified Maverick contract on Etherscan.
The deployer of this contract is aavechan.eth, who are a recognized member of the Aave community. However, we will do our best to reach out to them and have the contract verified.
Why scope tokens allowed to swap on CoW and Balancer.
2. We could remove restrictions on which tokens can be sold or purchased. However, this approach ensures the DAO has complete certainty that the managed treasury will never be exposed to undesired or illiquid assets.
Why scope curve minter?
3. oETH / ETH is the only Curve pool we have allowlisted thus far for the managed treasury. Providing transparency on the actions we, as Asset Managers, are authorised to execute—and being able to easily identify the available actions for each gauge when more are introduced—is simply a matter of structure.
Why remove permissions already granted.
4. Permissions are removed to streamline the payload, ensuring it reflects only the currently active permissions. As market conditions shift, contracts are upgraded, or the DAO decides to abandon a strategy, permissions are updated accordingly to simplify execution and auditing.
5. We’ve disabled native ETH deposits in Uniswap V3 Positions to avoid complications that the Zodiac Pilot was facing, WETH deposits remain available and avoids these issues.
You are correct, the Arbitrary Message Bridge (AMB) is indeed a contract that allows receiving assets from Gnosis Chain on Mainnet. As this proposal was launched at the same time as the PUR#6 [BIP 732] we thought it was prudent to add this functionality in both chains. You can read more about AMB contracts here.
We are collaborating closely with the Gnosis Guild team to ensure the Roles Modifier is both easy to audit and highly functional. The suggestion to toggle between labelled addresses and their original hex data is valuable feedback. However, decoding all function selectors may present technical challenges, especially for new strategies or contracts.
We aim to implement these improvements as quickly as possible and appreciate the suggestions.
We have updated the proposal by removing the Maverick pool from the permissions list. This change was necessary because the Maverick pool contract is not verified, which means we cannot ensure it meets our risk management standards.
The permissions diff page has been updated accordingly, and all related contracts have been removed from the payload.
We are duplicating the updated pages here for your convenience: