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 forge-std library.
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 delegatecalls to 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?
- Non-payable
- Payable
- Both, with the payable one being optional
0 voters
Is there already an EIP for the multicall with .call ?
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!
Cool
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?