[BIP-667] Roles V2 Migration & New Treasury Permissions

General Chat Karpatkey Updates
4

permissions policy

tldr

  • adds:

    • direct approvals for a list of tokens to cow, uni and balancer
    • $aave: set delegate
    • aave: enable user reserve as collateral on pools
    • lido: request and claim withdrawals
    • univ3: request eth refund, unwrap weth, sweep token
    • univ3: collect a specific tokenid (430246) recipient address(0) (?)

  • removes:

    • compound: v2 components
    • sushi: remove router
    • stakewise: merkle distributor claims, pool stake
    • univ3: swapExactTokensForTokens, mint weth/stakewise, weth/wbtc lp (?)

questions

  • im guessing that if there is no entry in the zodiac roles ui for a given parameter, then it is basically callable without any restrictions? because in the case of signOrder for cowswap, i dont see any restrictions on neither feeAmountBP nor order.feeAmount. i still think that having both completely unbound opens the door to possible unwanted behaviour. not a show stopper per se, but would be nice to see a limit of for example 10% or even 20% total fee. i did mention this in the previous review already as well (ref)

  • why remove swapExactTokensForTokens?

  • why recipient address(0) for univ3 collect?

feedback

  • quite a heavy migration, but i am sure next iterations will go a lot easier with this new zodiac roles ui!

  • overall the ui is great help, would be nice to have an address book connected to it

  • note that a lot of function signatures in the ui (identifiers, parameters) are not decoding at all

  • ui can only display a diff of two policies by comparing an actual policy versus a hash (“saved version” of a policy?). how that hash is generated and how it relates to the actual policy is completely opaque

payload json

your payload json has raw calldata, opposed to actual method names:

{
    "to": "0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84",
    "data": "0x095ea7b3000000000000000000000000dc24316b9ae028f1497c275eb9192a3ea0f670220000000000000000000000000000000000000000000000000000000000000000",
    "value": "0"
}

vs

{
    "to": "0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84",
    "value": "0",
    "data": null,
    "contractMethod": {
    "inputs": [
        { "name": "_spender", "type": "address" },
        { "name": "_amount", "type": "uint256" }
    ],
    "name": "approve",
    "payable": false
    },
    "contractInputsValues": {
    "_spender": "0xDC24316b9AE028F1497c275EB9192a3Ea0f67022",
    "_amount": "0"
    }
}

i also noticed some data type mismatches in the payload you suggested on github, but we can discuss that there :slight_smile: