Should this interface also include EIP-165 interface detection?
Is there any reason for not using the optimized
Multicall3 version in the EIP?
Multicall3 and predecessors batch external
calls to arbitrary addresses (i.e. many calls to many different contracts), while this multicall variant batches
address(this) (i.e. many calls only to one contract).
I’ll consider this. It does describe this better.
These multicalls serve different purposes. See the above comment by @hosefacts (well-explained, thanks!):
A question I had: Should the function be payable, and an option be added to allow the splitting of msg.value?
- Both, with the payable one being optional
Is there already an EIP for the multicall with
I voted “non-payable.”
delegatecall doesn’t accept a
value, so unfortunately it’s not possible to split up
msg.value the way I think you’re suggesting. (It would be nice if it were possible, though!) Instead, each
delegatecall will inherit the same
msg.value as the top level external call. As smarter people than I have discovered, that’s seriously dangerous.
It might be helpful to seek some feedback from the OZ team—I suspect they’ve thought about this in depth and might have suggestions.
I meant treating it as if msg.value were split up in that way (similar to how EIP-2771 treats msg.sender as not coming from the actual msg.sender)
I don’t think so. Please prove me wrong!