Should this interface also include EIP-165 interface detection?
There are also improved versions of the original
Multicall contract, most notably the backward-compatible
Multicall3 contract from Matt Solomon which was also recently added to the
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).
The OZ contract is called Multicall, but I’ve also seen this version called “Multi delegatecall” before, which might be a clearer name.
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!
Also just FYI this proposal could include multicall, ERC-5247: Smart Contract Executable Proposal Interface
love to collaborate
Sure thing! Do you have any suggestions to improve the pre-draft as-is?