Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Making Multicall3 mapping naive #62

Open
DefiDebauchery opened this issue Feb 16, 2023 · 0 comments
Open

Making Multicall3 mapping naive #62

DefiDebauchery opened this issue Feb 16, 2023 · 0 comments

Comments

@DefiDebauchery
Copy link
Contributor

DefiDebauchery commented Feb 16, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant