Feat: Bundle multiple revoke transactions

[pcaversaccio]

I think bundling multiple revoke transactions via multicall would be a nice feature to have. It's important that allowFailure is always set to False. If you're interested in a separate Vyper implementation of multicall, I wrote a version here.

[rkalis]

Generally for multicall contracts, the multicall contract itself is the msg.sender in the context of the calls. So the multicall contract is only able to set its own allowances, rather than the user's allowances. So unless I'm missing something, I don't think this is possible.

[pcaversaccio]

There is multicall and multicall... You are referring to e.g. this multicall where you use CALL. But if you use DELEGATECALL like in my Vyper implementation or multicall the context (i.e. tx.origin and msg.sender) remains the EOA.

[pcaversaccio]

But let me think about whether the correct storage space is used - that might be a blocker indeed...

[rkalis]

But if you're using DELEGATECALL you're using the multicall contract's storage right? So you still can't revoke multiple allowances, because you can't write to the delegatecalled contracts storage.

[alex-ppg]

I think there might be some confusion here, in order to revoke a transaction you have to update the storage entries at the token level.

A multicall that performs delegatecall operations will execute external code (i.e. approve) as if it was local and solely affect local storage. As a result, this would not solve the issue of lingering approvals as the actual data points at each individual contract need to be updated.

It is currently impossible to bundle such calls on-chain (as it would be equivalent to an EOA executing multiple actions in a single transaction which is impossible), however, it may be in the future such as via AUTHCALL / AUTH (EIP-3074). This feat should be kept in mind for the future.

[rkalis]

Thanks @alex-ppg, that was also my understanding. Regardless, thanks for opening the issue @pcaversaccio. I definitely agree that this would be a super useful feature to have if it were possible.

[pcaversaccio]

yeap that makes sense even though I do not support EIP-3074 for various reasons :-D. Let's keep this issue open and maybe some day we will be able to find a proper solution.

[chiuzon]

Wouldn't be an alternative to use the RPC batch function ? https://geth.ethereum.org/docs/interacting-with-geth/rpc/batch

[crisog]

Wouldn't be an alternative to use the RPC batch function ? https://geth.ethereum.org/docs/interacting-with-geth/rpc/batch

In that case I think you'd still need to sign each tx independently despite them being able to be broadcasted at once. You still pay gas for each transaction within the batch too (unless I'm overlooking something)

[pcaversaccio]

Wouldn't be an alternative to use the RPC batch function ? https://geth.ethereum.org/docs/interacting-with-geth/rpc/batch

In that case I think you'd still need to sign each tx independently despite them being able to be broadcasted at once. You still pay gas for each transaction within the batch too (unless I'm overlooking something)

This is correct - the normal RPC is for broadcasting transactions and can't batch atomically transactions together. However, you could use the Flashbots RPC endpoint eth_sendBundle or mev_sendBundle to atomically batch together (individually signed) transactions (they run a modified Geth client to achieve this, but it's only supported on Ethereum mainnet and some test networks...)

[pcaversaccio]

FWIW EIP-3074 included in Pectra hard fork: https://twitter.com/TimBeiko/status/1778490341437681684

[rkalis]

FWIW EIP-3074 included in Pectra hard fork: twitter.com/TimBeiko/status/1778490341437681684

Very exciting! Will start preparing for it ahead of the hard fork. 🫡