[BIP-473] Permissions Preset Update Request #2 (Revised version of BIP-442)

General Chat Karpatkey Updates
3

Due Diligence: Revised Version of BIP-442

Karpatkey did a self audit of this payload using my methodology of the initial due diligence report of BIP-442.

I went through their self audit and can confirm it matches their simulation of the proposed payload.

However, the only event that I cannot read properly is id 59. The function signature only has 12 parameters, but 14 are given. This probably has to do with the fact that some of the parameters are packed in a struct/tuple, but this then throws off the order of the parameters:

swap(
    (
        bytes32,
        uint8,
        address,
        address,
        uint256,
        bytes
    ) singleSwap,
    (
        address,
        bool,
        address,
        bool
    ) funds,
    uint256 limit,
    uint256 deadline
)

0:"0x00000000000000000000000000000000000000000000000000000000000000e0"
1:"0x0000000000000000000000000efccbb9e2c09ea29551879bd9da32362b32fc89"
2:"0x0000000000000000000000000000000000000000000000000000000000000000"
3:"0x0000000000000000000000000efccbb9e2c09ea29551879bd9da32362b32fc89"
4:"0x0000000000000000000000000000000000000000000000000000000000000000"
5:"0x"
6:"0x"
7:"0x"
8:"0x0000000000000000000000000000000000000000000000000000000000000000"
9:"0x"
10:"0x"
11:"0x"
12:"0x00000000000000000000000000000000000000000000000000000000000000c0"
13:"0x0000000000000000000000000000000000000000000000000000000000000000"

E.g. I am guessing that [1-4] are the values of the funds struct ((address,bool,address,bool)), but they are clearly not in the same place as in the swap signature. @kpk can you elaborate on how to match the parameter indices to the signature? Same then goes for events with id 60-62.

Conclusion

Events [59-62] need some more explanation from Karpatkey, given I cannot match indices to the corresponding function signature.

I would also be curious as to your reasoning behind making infinite approvals for the ERC20s, versus making them atomically? E.g. it would be possible to scope the approval functions on these ERC20s, so that you could sandwich your actions on the avatar with the necessary approve(inf) and approve(0) (or just approve(n)). This would minimise the risk vector of leaving inifite approvals open for an unforseen time (the SushiSwap RouterProcessor2 approval bug costing $3.3MM comes to mind for example).

Recommendations

Although the self audit you provide makes the payload a lot more readable and verifiable, it is still very time consuming on both sides (since the self audit has to be audited…). A programmatic and open source way of turning the payload into a report would be the solution here. I would be happy to discuss initiating or assisting with such a project, either as a pilot here with Balancer or elsewhere.