feat: add multicall handler

[mrice32]

This is a generic handler where the user can perform a series of calls (multicall) after their tokens are received in the contract.

User can specify a fallback address that is:

• Paid all remaining tokens whether the call succeeds or fails.

If the user doesn't specify a fallback address, the call must succeed.

The user can call drainLeftoverTokens on the handler in their calls to drain any remaining amount of any token or ETH in their calls. This is meant as a way to deal with calls where the amount of tokens they take isn't known a priori.

[nicholaspai]

How does this contract get value? Doesn't it receive WETH as a contract?

[mrice32]

You might unwrap the WETH in one of your calls, right?

[nicholaspai]

yeah fair

[james-a-morris]

Open question:

1. Should we create multiple versions of this contract with slight variants on the Call struct? For instance, one could exclude value and one could include a canFail boolean to allow some calls to fail without reverting. The idea behind multiple versions is that we might not want users who don't need these features to pay for the extra calldata (value and canFail will add 64 bytes total to the calldata for each call).

I think this makes sense. OOC could we also have a byte at the start of message determine what format we can expect Call[] to be? This way, we could unpack accordingly and only need the one contract

[james-a-morris]

Is there any validation we want to do here on converting message into Call[]

[mrice32]

What sort of validation would you suggest?

My understanding is that abi.decode will cause a revert if the format is wrong.

[bmzig]

1. Should we create multiple versions of this contract with slight variants on the Call struct? For instance, one could exclude value and one could include a canFail boolean to allow some calls to fail without reverting. The idea behind multiple versions is that we might not want users who don't need these features to pay for the extra calldata (value and canFail will add 64 bytes total to the calldata for each call).

From what I found, the price of deployment in gas scales by around $78 \times \text{byte}$, while the price of extra calldata scaled by 4 or 7 gas per byte, so if these contracts will have a lot of volume, which they presumably will, it probably will be worth it to pay the cost of a more expensive deployment for less expensive transactions.

2. Should we create two variants of the contract, one that uses tstore reentrancy guards and one that uses oldschool reentrancy guards? The latter will probably be required to support chains that don't yet have the Cancun EVM upgrade. The former will save gas for chains that do. This might be an overoptimization, though.

If it is a simple implementation, I'd say its a good idea.

[mrice32]

1. Should we create multiple versions of this contract with slight variants on the Call struct? For instance, one could exclude value and one could include a canFail boolean to allow some calls to fail without reverting. The idea behind multiple versions is that we might not want users who don't need these features to pay for the extra calldata (value and canFail will add 64 bytes total to the calldata for each call).

From what I found, the price of deployment in gas scales by around 78×byte, while the price of extra calldata scaled by 4 or 7 gas per byte, so if these contracts will have a lot of volume, which they presumably will, it probably will be worth it to pay the cost of a more expensive deployment for less expensive transactions.

Yep! I don't think the deployment costs are a big deal. I worry about the complexity. When people integrate, instead of saying "use contract 0x1234" we'll have to split by use case. We'll say "if you want to send value, use contract 0x1234, if you want to allow reverts, use contract 0x5678", etc.

2. Should we create two variants of the contract, one that uses tstore reentrancy guards and one that uses oldschool reentrancy guards? The latter will probably be required to support chains that don't yet have the Cancun EVM upgrade. The former will save gas for chains that do. This might be an overoptimization, though.

If it is a simple implementation, I'd say its a good idea.

Agreed. We'll probably have to upgrade the OZ library, but seems valuable enough to get both variants audited.

[mrice32]

Open question:

1. Should we create multiple versions of this contract with slight variants on the Call struct? For instance, one could exclude value and one could include a canFail boolean to allow some calls to fail without reverting. The idea behind multiple versions is that we might not want users who don't need these features to pay for the extra calldata (value and canFail will add 64 bytes total to the calldata for each call).

I think this makes sense. OOC could we also have a byte at the start of message determine what format we can expect Call[] to be? This way, we could unpack accordingly and only need the one contract

Yep, I thought a little about something like this. Downside is that it makes building the message more complex.

abi encoding your params is a common pattern, but appending extra bytes to the front to create a tagged-union-like structure isn't. So it would require more effort and would have more footguns than the alternative I think.