banteg / multicall.py

aggregate results of multiple smart contract calls into one
MIT License
251 stars 108 forks source link

Making Multicall3 mapping naive #62

Open DefiDebauchery opened 1 year ago

DefiDebauchery commented 1 year ago

In previous versions of Multicall, when adding local support for new chains, I overrode utils.chainids, Constants.Network, and the MULTICALL_* structs. As Network is an Enum, I have to recreate the entire list -- granted, I only have to specify the chains I care about, this still gets a bit unwieldy since I periodically have to expand support within my own application.

Because Multicall3 doesn't deviate per network, would it make sense to allow for the execution to assume the address without requiring an explicit mapping, leaving it up to the user to determine whether it's available?

Since MC3 is backwards compatible with MC and MC2 and is included in every chain that MC/MC2 is (minus Kava, which we will fund mds to deploy shortly), which is therefore applied in multicall_map in multicall.py#L47-L52, I also feel like this should become the default operation, possibly obsoleting the need for any mapping at all.

Happy to take a stab at simplifying, but wanted to know if this would be a welcome change or not (and perhaps brainstorm a good implementation). Would be interested to hear whether anyone using a recent version of Multicall still relied on the