# \[BIP-442\] Permissions Preset Update Request #2

**URL:** <https://forum.balancer.fi/t/bip-442-permissions-preset-update-request-2/5209>\
**Category:** Karpatkey Updates\
**Created:** [September 22, 2023, 1:48pm UTC](https://forum.balancer.fi/t/bip-442-permissions-preset-update-request-2/5209 "2023-09-22T13:48:01Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![kpk](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/kpk/32/3793_2.png) [@kpk](https://forum.balancer.fi/u/kpk)\
**Post date:** [September 22, 2023, 1:48pm UTC](https://forum.balancer.fi/t/bip-442-permissions-preset-update-request-2/5209/1 "2023-09-22T13:48:01Z")

</div>

### PR with Payload

[https://github.com/BalancerMaxis/multisig-ops/pull/528](https://github.com/BalancerMaxis/multisig-ops/pull/528)

# Abstract

This proposal introduces additional actions and strategies to the portion of the treasury managed by karpatkey (as per [BIP-103](https://forum.balancer.fi/t/bip-103-karpatkey-balancer-treasury-cu-proposal-update/3895)), aiming to enhance the treasury’s performance, adaptability, and diversification.

# Motivation

Permissions granted to karpatkey to manage the BalancerDAO treasury are not static, and require regular updates to effectively respond to evolving market conditions and to capitalise on emerging opportunities.

As it’s customary, any changes to the preset permissions must be executed by the DAO.

# Specification

Permissions that will be added in this proposal are:

1. Deposit USDC on Compound v3;
2. Deposit DAI on AAVE v3;
3. Deposit USDC on AAVE v3;
4. Deposit DAI on MakerDAO’s Dai Savings Rate (DSR) module;
5. Unstake stETH on Lido;
6. Stake (and unstake) ETH on Rocket Pool (rETH);
7. Swap on Cow Swap

Payload to be executed from the [Ethereum Avatar Safe](https://app.safe.global/home?safe=eth:0x0EFcCBb9E2C09Ea29551879bd9Da32362b32fc89)

### Audit considerations

We propose an updated version of the [Preset permissions - Balancer Treasury](https://docs.google.com/document/d/1QQjkn6DAqXhdqYag0KSIfqJvdkLilOb6dM4KqaiybXc/edit) document that shows all the permissions granted to karpatkey, including the ones that are being requested now, highlighted in green.

Reviewing and providing feedback on the preset update [payload](https://gist.github.com/santinomics/1f0d96856166d673551e2f316bace89d) would be a great service to the Balancer community. We welcome anyone who is willing to take the time to verify the content and encourage community members to share their feedback with us.

karpatkey’s tech team is diligently working on enhancing the auditing process. Our primary goal is to provide a clearer visual representation of potential Zodiac preset modifications before implementing any proposed payload. We are committed to keeping the community informed about our progress and developments.

# Additional references

Avatar Safe address: [0x0EFcCBb9E2C09Ea29551879bd9Da32362b32fc89](https://etherscan.io/address/0x0EFcCBb9E2C09Ea29551879bd9Da32362b32fc89)

Roles Modifier address: [0xd8dd9164E765bEF903E429c9462E51F0Ea8514F9](https://etherscan.io/address/0xd8dd9164E765bEF903E429c9462E51F0Ea8514F9)

Manager Safe address: [0x60716991aCDA9E990bFB3b1224f1f0fB81538267](https://etherscan.io/address/0x60716991aCDA9E990bFB3b1224f1f0fB81538267)

---

<div class="post-metadata">

**Author:** ![kpk](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/kpk/32/3793_2.png) [@kpk](https://forum.balancer.fi/u/kpk)\
**Post date:** [September 22, 2023, 1:48pm UTC](https://forum.balancer.fi/t/bip-442-permissions-preset-update-request-2/5209/2 "2023-09-22T13:48:34Z")

</div>

# Proposed Actions Overview

### 1. Deposit USDC on Compound v3

[Compound v3](https://docs.compound.finance/) is a streamlined protocol version emphasising security, capital efficiency, and user experience. Following a [proposal](https://compound.finance/governance/proposals/180) executed on September 18th, v2 is being phased out, with measures in place to transition users to v3. [OpenZeppelin](https://blog.openzeppelin.com/compound-iii-audit/) and [ChainSecurity](https://chainsecurity.com/security-audit/compound-iii/) have audited v3. As of the day of this writing, $319M USDC is deposited in v3, offering an APR of 4.3%, inclusive of COMP token rewards.

### 2. Deposit DAI on AAVE v3

This strategy aims to diversify stablecoin holdings via AAVE v3, a leading decentralised money market with a strong link to the Balancer DAO. [AAVE v3](https://governance.aave.com/t/introducing-aave-v3/6035) was officially [deployed on mainnet](https://aave.mirror.xyz/K9gQPsv-hAH-gO4oH2i0Oen8uQEHYL5q8x9xjN9XnmA) in January 2023 after being live across six networks [since March 2022](https://aave.mirror.xyz/2TnHYHQRnNhSG56Y4CcssulFArSVqrFbmAdYfU7Kxp0). This version introduces features for enhanced capital efficiency and decentralisation, coupled with new risk management tools. Comprehensive audits by firms like [Trail of Bits](https://github.com/aave/aave-v3-core/blob/master/audits/07-01-2022_TrailOfBits_AaveV3.pdf), [ABDK](https://github.com/aave/aave-v3-core/blob/master/audits/27-01-2022_ABDK_AaveV3.pdf), [Peckshield](https://github.com/aave/aave-v3-core/blob/master/audits/14-01-2022_PeckShield_AaveV3.pdf), OpenZeppelin, SigmaPrime, and formal verification by [Certora](https://github.com/aave/aave-v3-core/blob/master/Certora/certora/Verification_Report.pdf). Currently, [AAVE v3](https://app.aave.com/reserve-overview/?underlyingAsset=0x6b175474e89094c44da98b954eedeac495271d0f&marketName=proto_mainnet_v3) holds $51.6M DAI with an expected APY of 3.82%.

### 3. Deposit USDC on AAVE v3

Same logic as above but for USDC. As of the day of this writing, the total USDC supplied on [AAVE v3](https://app.aave.com/reserve-overview/?underlyingAsset=0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48&marketName=proto_mainnet_v3) is $299M, and the expected APY is 2.86%.

### 4. Deposit DAI on MakerDAO’s DAI Savings Rate (DSR) module

MakerDAO, renowned for creating DAI, is a leading DAO in the DeFi sector. A recent [DSR rate hike](https://forum.makerdao.com/t/stability-scope-parameter-changes-2-non-scope-defined-parameter-changes-may-2023/20981) in May and the [introduction of eDSR](https://vote.makerdao.com/executive/template-executive-vote-enhanced-dai-savings-rate-activation-spark-protocol-debt-ceiling-increase-rwa-vault-updates-avc-member-compensation-for-q2-2023-dao-resolution-for-monetalis-clydesdale-launch-project-funding-spark-proxy-spell-execution-august-2-2023) (enhanced DSR) in August make it an attractive strategy from a risk/reward perspective. Currently, eDSR offers an APR of 5%. By diversifying the Balancer treasury’s stablecoin allocation and capitalising on the higher yield offered by one of the most battle-tested protocols, the investment approach can be optimised.

### 5. Unstake stETH on Lido

Post the Shapella fork in April, users can now unstake or withdraw staked ETH from the different LST providers. This action was not part of the previous preset update request to the Balancer DAO due to its timing.

### 6. Stake (and unstake) ETH on Rocket Pool (rETH)

To diversify LST holdings, we suggest adding [RocketPool](https://rocketpool.net/) to the whitelist for ETH staking and unstaking. RocketPool ranks [third](https://dune.com/queries/2433350/3997605) in the liquid staking market, holding about 691,000 ETH, or 6% of the total market. In market share, Rocket Pool’s rETH trails Lido’s stETH (76%) and Coinbase’s cbETH (11%). Despite slightly lower liquidity for rETH to ETH swaps on major DEXes, Balancer DAO treasury’s allocated amount should face minimal slippage. For example, [DeFi Llama](https://defillama.com/liquidity) indicates a swap of ~5,700 rETH for ETH would have under 0.1% slippage. Currently, rETH offers an APR of 3.26%.

### 7. Swap on Cow Swap

Thanks to the efforts of the Gnosis Builders and the karpatkey tech team, Cow Swap can now be seamlessly integrated with the Zodiac Roles Modifier. This enhancement allows for the exclusive swapping of only those tokens that are included in the whitelisted strategies.

---

<div class="post-metadata">

**Author:** ![gosuto](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/gosuto/32/2014_2.png) [@gosuto](https://forum.balancer.fi/u/gosuto)\
**Post date:** [October 11, 2023, 2:10pm UTC](https://forum.balancer.fi/t/bip-442-permissions-preset-update-request-2/5209/3 "2023-10-11T14:10:49Z")

</div>

# Due Dilligence: BIP-442 Karpatkey Payload

## Tenderly Simulation

> **[Tenderly Dashboard](https://dashboard.tenderly.co/public/safe/safe-apps/simulator/d884b97f-2bd6-4bcc-8242-84bbdfdf46c0/logs)**
>
> Tenderly is a full-stack infrastructure for the entire dapp lifecycle, offering the only node RPC with built-in development environments and tools. Sign up now!

## Interpreting Events

The payload can in this case be intepreted through the events it emits on a successful (simulated) execution. This is possible because the only functions that are called are approvals on ERC20s or scope changes on the [`Roles` module](https://etherscan.io/address/0xd8dd9164e765bef903e429c9462e51f0ea8514f9#code). All these functions emit relevant and exhaustive events.

### `Approval`

`Approval` events are pretty straight forward to interpret:

```json
{
    "owner": "0x0efccbb9e2c09ea29551879bd9da32362b32fc89"
    "spender": "0x7f39c581f595b53c5cb19bd0b3f8da6c935e2ca0"
    "value": "115792089237316195423570985008687907853269984665640564039457584007913129639935"
}

```

The event is emitted from `0xae7ab96520de3a18e5e111b5eaab095312d7fe84`, which is stETH. On it, the [managed safe](https://app.safe.global/home?safe=eth:0x0EFcCBb9E2C09Ea29551879bd9Da32362b32fc89) (0x0efcc) approves the spender (wstETH) to spend infinite amount of tokens.

In all cases here, the owner is the managed safe and the amount of tokens is infinite. Mapping of tokens and spenders:

| token (symbol) | spender (label) |
| --- | --- |
| `0xae7ab96520de3a18e5e111b5eaab095312d7fe84` (stETH) | `0x7f39c581f595b53c5cb19bd0b3f8da6c935e2ca0` (wstETH) |
| `0xae7ab96520de3a18e5e111b5eaab095312d7fe84` (stETH) | `0x889edc2edab5f40e902b864ad4d7ade8e412f9b1` (unstETH) |
| `0x7f39c581f595b53c5cb19bd0b3f8da6c935e2ca0` (wstETH) | `0x889edc2edab5f40e902b864ad4d7ade8e412f9b1` (unstETH) |
| `0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48` (USDC) | `0xc3d688b66703497daa19211eedff47f25384cdc3` (cUSDCv3) |
| `0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48` (USDC) | `0x87870bca3f3fd6335c3f4ce8392d69350b4fa4e2` (Aave: Pool V3) |
| `0x6b175474e89094c44da98b954eedeac495271d0f` (DAI) | `0x87870bca3f3fd6335c3f4ce8392d69350b4fa4e2` (Aave: Pool V3) |
| `0xae78736cd615f374d3085123a210448e74fc6393` (rETH) | `0x16d5a408e807db8ef7c578279beeee6b228f1c1c` (RocketSwapRouter) |
| `0x6b175474e89094c44da98b954eedeac495271d0f` (DAI) | `0x373238337bfe1146fb49989fc222523f83081ddb` (DsrManager) |
| `0x7fc66500c84a76ad7e9c93437bfc5ac33e2ddae9` (AAVE) | `0xc92e8bdf79f0507f65a392b0ab4667716bfe0110` (GPv2VaultRelayer; CoW Swap) |
| `0xc00e94cb662c3520282e6f5717214004a7f26888` (COMP) | `0xc92e8bdf79f0507f65a392b0ab4667716bfe0110` (GPv2VaultRelayer; CoW Swap) |
| `0x6b175474e89094c44da98b954eedeac495271d0f` (DAI) | `0xc92e8bdf79f0507f65a392b0ab4667716bfe0110` (GPv2VaultRelayer; CoW Swap) |
| `0xae78736cd615f374d3085123a210448e74fc6393` (RETH) | `0xc92e8bdf79f0507f65a392b0ab4667716bfe0110` (GPv2VaultRelayer; CoW Swap) |
| `0x20bc832ca081b91433ff6c17f85701b6e92486c5` (rETH2) | `0xc92e8bdf79f0507f65a392b0ab4667716bfe0110` (GPv2VaultRelayer; CoW Swap) |
| `0xfe2e637202056d30016725477c5da089ab0a043a` (sETH2) | `0xc92e8bdf79f0507f65a392b0ab4667716bfe0110` (GPv2VaultRelayer; CoW Swap) |
| `0x889edc2edab5f40e902b864ad4d7ade8e412f9b1` (unstETH) | `0xc92e8bdf79f0507f65a392b0ab4667716bfe0110` (GPv2VaultRelayer; CoW Swap) |
| `0x48e5413b73add2434e47504e2a22d14940dbfe78` (INRM) | `0xc92e8bdf79f0507f65a392b0ab4667716bfe0110` (GPv2VaultRelayer; CoW Swap) |
| `0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48` (USDC) | `0xc92e8bdf79f0507f65a392b0ab4667716bfe0110` (GPv2VaultRelayer; CoW Swap) |
| `0xdac17f958d2ee523a2206206994597c13d831ec7` (USDT) | `0xc92e8bdf79f0507f65a392b0ab4667716bfe0110` (GPv2VaultRelayer; CoW Swap) |
| `0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2` (WETH) | `0xc92e8bdf79f0507f65a392b0ab4667716bfe0110` (GPv2VaultRelayer; CoW Swap) |
| `0x2260fac5e5542a773aa44fbcfedf7c193bc2c599` (WBTC) | `0xc92e8bdf79f0507f65a392b0ab4667716bfe0110` (GPv2VaultRelayer; CoW Swap) |
| `0x7f39c581f595b53c5cb19bd0b3f8da6c935e2ca0` (wstETH) | `0xc92e8bdf79f0507f65a392b0ab4667716bfe0110` (GPv2VaultRelayer; CoW Swap) |

**WARNING** : the approval of `0x48e5413b73add2434e47504e2a22d14940dbfe78` (INRM) seems unnecessary and is a bit puzzling to me. It is for example not whitelisted for the `CowswapOrderSigner.signOrder.sellToken` parameter (see `ScopeParameterAsOneOf` section). Is there something I am missing here, or is this a bug? How did this token get into this list?

### `ScopeFunction`

Besides the (more readable) approvals, this payload makes changes to the `Roles` module, which is currently enabled on the managed safe.

We can verify these permission changes made by checking the events emitted in the Tenderly simulation, e.g.:

```json
{
    "role": 1
    "targetAddress": "0x889edc2edab5f40e902b864ad4d7ade8e412f9b1"
    "functionSig": "0xd6681042"
    "isParamScoped": [
        0: false
        1: true
    ]
    "paramType": "AAA="
    "paramComp": "AAA="
    "compValue": [
        0: "0x"
        1: "0x0000000000000000000000000efccbb9e2c09ea29551879bd9da32362b32fc89"
    ]
    "options": 0
    "resultingScopeConfig": "3533694129556781213370065774847364703233814209084070120954101330654265344"
}

```

`role` here is the index of the `Role` struct, meaning in this case that there is a target type role change:

```solidity
struct Role {
    mapping(address => bool) members;
    mapping(address => TargetAddress) targets;
    mapping(bytes32 => uint256) functions;
    mapping(bytes32 => bytes32) compValues;
    mapping(bytes32 => bytes32[]) compValuesOneOf;
}

```

`target` and `functionSig` translate to the following:

```python
>>> target = Contract('0x889edc2edab5f40e902b864ad4d7ade8e412f9b1')
>>> target.name()
'Lido: stETH Withdrawal NFT'
>>> target.selectors['0xd6681042']
'requestWithdrawals'

```

This corresponds to point (5.) from karpatkey’s specs:

> 1. Unstake stETH on Lido;

The function’s full signature is `requestWithdrawals(uint256[] _amounts, address _owner)`, therefore:

- setting `isParamScoped` for the parameter with index `0` to `false` means any amount could be withdrawm, i.e. no limitation
- `isParamScoped` for the parameter for index `1` is set to `true` with value `0x0000000000000000000000000efccbb9e2c09ea29551879bd9da32362b32fc89`; the withdrawal can only take place to `0x0EFcCBb9E2C09Ea29551879bd9Da32362b32fc89` which is the managed treasury multisig address

`options` can give permission to send ether, use `delegate_call` or both:

```solidity
enum ExecutionOptions {
    None,
    Send,
    DelegateCall,
    Both
}

```

We can repeat this for all other scope type events emitted:

| contract | signature | scope |
| --- | --- | --- |
| `"Lido: stETH Withdrawal NFT"` | `requestWithdrawals(uint256[] _amounts, address _owner)` | ANY, 0x0efcc |
| `"Lido: stETH Withdrawal NFT"` | `requestWithdrawalsWstETH(uint256[] _amounts, address _owner)` | ANY, 0x0efcc |
| `"Aave: Pool V3"` | `supply(address asset, uint256 amount, address onBehalfOf)` | SCOPED\*, ANY, 0x0efcc |
| `"Aave: Pool V3"` | `withdraw(address asset, uint256 amount, address onBehalfOf)` | SCOPED\*, ANY, 0x0efcc |
| `"Compound USDC (cUSDCv3)"` | `supply(address asset, uint256 amount)` | USDC, ANY |
| `"Compound USDC (cUSDCv3)"` | `withdraw(address asset, uint256 amount)` | USDC, ANY |
| `"CometRewards"` | `claim(address comet, address src, bool shouldAccrue)` | cUSDCv3, 0x0efcc, ANY |
| `"DsrManager"` | `join(address dst, uint256 wad)` | 0x0efcc, ANY |
| `"DsrManager"` | `exitAll(address dst)` | 0x0efcc |
| `"RocketDepositPool"` | `deposit()` | SEND\_ETHER |
| `"Rocket Pool ETH"` | `burn(uint256 _rethAmount)` | ANY |
| `"RocketSwapRouter"` | `swapTo(uint256 _uniswapPortion, uint256 _balancerPortion, uint256 _minTokensOut, uint256 _idealTokensOut)` | ANY\*, SEND\_ETHER |
| `"RocketSwapRouter"` | `swapFrom(uint256 _uniswapPortion, uint256 _balancerPortion, uint256 _minTokensOut, uint256 _idealTokensOut, uint256 _tokensIn)` | ANY\* |
| `"CowswapOrderSigner"` | `signOrder(address sellToken, address buyToken, uint256 sellAmount, uint256 buyAmount, uint32 validTo, uint32 validDuration, uint256 feeAmount, uint256 feeAmountBP, bytes32 kind, bool partiallyFillable, bytes32 sellTokenBalance, bytes32 buyTokenBalance)` | SCOPED\*, SCOPED\*, ANY, ANY, ANY, ANY, ANY, ANY, ANY, ANY, ANY, ANY, SEND\_ETHER, DELEGATE\_CALL |

**WARNING** : deployer of `CowswapOrderSigner` does not look to be CoW DAO. Who deployed this contract?

**WARNING** : the `feeAmountBP` is not scoped, and can therefore be set to something like 99%. **There is a potential for malicious/griefing transactions here!**

### `ScopeParameterAsOneOf`

Some parameters do not get limited to a single value but to a list of values, as can be read from the `ScopeParameterAsOneOf` event:

```json
ScopeParameterAsOneOf{
    "role": 1
    "targetAddress": "0x87870bca3f3fd6335c3f4ce8392d69350b4fa4e2"
    "functionSig": "0x617ba037"
    "index": "0"
    "paramType": 0
    "compValues": [
        0: "0x0000000000000000000000006b175474e89094c44da98b954eedeac495271d0f"
        1: "0x000000000000000000000000a0b86991c6218b36c1d19d4a2e9eb0ce3606eb48"
    ]
    "resultingScopeConfig":"5300541194335184374258569435632574726429567728958937386142040924050423811"
}

```

So the parameter with index `0` (`"Aave: Pool V3".supply.asset`) can have two values:

- `0x6b175474e89094c44da98b954eedeac495271d0f` (DAI)
- `0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48` (USDC)

`"Aave: Pool V3".withdraw.asset` can be set to the same two addresses:

- `0x6b175474e89094c44da98b954eedeac495271d0f` (DAI)
- `0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48` (USDC)

The `CowswapOrderSigner.signOrder.sellToken` parameter gets scoped to the following whitelist:

- `0x7fc66500c84a76ad7e9c93437bfc5ac33e2ddae9` (AAVE)
- `0xc00e94cb662c3520282e6f5717214004a7f26888` (COMP)
- `0x6b175474e89094c44da98b954eedeac495271d0f` (DAI)
- `0xae78736cd615f374d3085123a210448e74fc6393` (rETH)
- `0x20bc832ca081b91433ff6c17f85701b6e92486c5` (rETH2)
- `0xfe2e637202056d30016725477c5da089ab0a043a` (sETH2)
- `0xae7ab96520de3a18e5e111b5eaab095312d7fe84` (stETH)
- `0x48c3399719b582dd63eb5aadf12a40b4c3f52fa2` (SWISE)
- `0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48` (USDC)
- `0xdac17f958d2ee523a2206206994597c13d831ec7` (USDT)
- `0x2260fac5e5542a773aa44fbcfedf7c193bc2c599` (WBTC)
- `0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2` (WETH)
- `0x7f39c581f595b53c5cb19bd0b3f8da6c935e2ca0` (wstETH)

And for `CowswapOrderSigner.signOrder.buyToken`:

- `0x6b175474e89094c44da98b954eedeac495271d0f` (DAI)
- `0xae78736cd615f374d3085123a210448e74fc6393` (rETH)
- `0xfe2e637202056d30016725477c5da089ab0a043a` (sETH2)
- `0xae7ab96520de3a18e5e111b5eaab095312d7fe84` (stETH)
- `0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48` (USDC)
- `0xdac17f958d2ee523a2206206994597c13d831ec7` (USDT)
- `0x2260fac5e5542a773aa44fbcfedf7c193bc2c599` (WBTC)
- `0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2` (WETH)
- `0x7f39c581f595b53c5cb19bd0b3f8da6c935e2ca0` (wstETH)

## Conclusion

The INRM token approval is puzzling but not necessarily a security issue.

For the CoW swap order signing however, I would recommend either (1) a scope on the `feeAmountBP` parameter or (2) a new (official) deployment of the signer contract which has a tighter sanity check on the fee ([ref](https://etherscan.io/address/0xdeb83d81d4a9758a7baec5749da863c409ea6c6b#code#F1#L79)) to prevent getting assets drained through unrealistic fees.

---

<div class="post-metadata">

**Author:** ![Tritium](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/tritium/32/2011_2.png) [@Tritium](https://forum.balancer.fi/u/Tritium)\
**Post date:** [October 11, 2023, 2:16pm UTC](https://forum.balancer.fi/t/bip-442-permissions-preset-update-request-2/5209/4 "2023-10-11T14:16:29Z")

</div>

Thank you very much for completing this review.

---

<div class="post-metadata">

**Author:** ![kpk](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/kpk/32/3793_2.png) [@kpk](https://forum.balancer.fi/u/kpk)\
**Post date:** [October 12, 2023, 7:23pm UTC](https://forum.balancer.fi/t/bip-442-permissions-preset-update-request-2/5209/5 "2023-10-12T19:23:20Z")

</div>

Hi @gosuto,

We deeply appreciate your time and effort in auditing the payload and offering invaluable insights to the community.

# Update on Cow Protocol

Firstly, we’d like to bring to everyone’s attention a [recent update](https://github.com/gnosis/cow-order-signer/pull/2) to the Cow protocol. This update renders the current version of the CowswapOrderSigner contract incompatible with the Zodiac Roles Modifier setup we employ for non-custodial management of Balancer’s treasury. As a result, we’re revising the payload to exclude all Cow-related elements.

# Addressing Your Points

While the removal of Cow from the payload renders some of your concerns moot, we believe it’s important to address the excellent points you’ve raised:

1. INRM Token Approval

The inclusion of the INRM token address (`0x48e5413b73add2434e47504e2a22d14940dbfe78`) was inadvertent. The intended token was SWISE (`0x48C3399719B582dD63eB5AADf12A40B4C3f52FA2`). It’s crucial to note that this was merely an approval action and, as it wasn’t whitelisted for the CowswapOrderSigner.signOrder.sellToken parameter, swaps involving this token would have been impossible. The whitelisting of the SWISE token in the said parameter clearly indicates our original intent.

1. CowSwapOrderSigner Deployment

The [CowswapOrderSigner](https://etherscan.io/address/0xdeb83d81d4a9758a7baec5749da863c409ea6c6b) contract was a collaborative effort between [Gnosis Guild](https://twitter.com/GnosisGuild) (the creators of Zodiac tools) and Cow developers. The contract, which is part of the [Gnosis repository](https://github.com/gnosis/cow-order-signer), has undergone rigorous auditing by Gnosis and was deployed by an [address](https://etherscan.io/address/0xa3b2ecbd5c62646620c311253b9334f5eeced545) owned by karpatkey.

1. Non-Scoping of feeAmountBP

Your observation regarding the non-scoping of feeAmountBP was astute. Post internal discussions between our Strategy & Ops and Tech teams, we concur that limiting this parameter would enhance the robustness of the preset. Once a future version of the CowswapOrderSigner contract is available and Cow can be reintegrated into the Zodiac environment, we will certainly consider scoping this parameter.

---

<div class="post-metadata">

**Author:** ![andy\_dev](https://avatars.discourse-cdn.com/v4/letter/a/c89c15/32.png) [@andy\_dev](https://forum.balancer.fi/u/andy_dev)\
**Post date:** [November 28, 2023, 3:36pm UTC](https://forum.balancer.fi/t/bip-442-permissions-preset-update-request-2/5209/6 "2023-11-28T15:36:08Z")

</div>

i think The inclusion of the INRM token address (`0x48e5413b73add2434e47504e2a22d14940dbfe78` ) was inadvertent. The intended token was SWISE (`0x48C3399719B582dD63eB5AADf12A40B4C3f52FA2` ). It’s crucial to note that this was merely an approval action and, as it wasn’t whitelisted for the CowswapOrderSigner.signOrder.sellToken parameter, swaps involving this token would have been impossible. The whitelisting of the SWISE token in the said parameter clearly indicates our original intent.