You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
In previous versions of Multicall, when adding local support for new chains, I overrode
utils.chainids
,Constants.Network
, and theMULTICALL_*
structs. AsNetwork
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
The text was updated successfully, but these errors were encountered: