Skip to content
This repository has been archived by the owner on Feb 26, 2024. It is now read-only.

Add support for multicall3 to decoder interpretations #6137

Merged
merged 2 commits into from Jul 11, 2023
Merged

Conversation

haltman-at
Copy link
Contributor

Addresses #6079. This PR adds support for the new methods from Multicall v3 -- aggregate3 and aggregate3Value -- to the decoder's multicall interpretation support.

The aggregate3 method allows you to specify allowFailure for each call (in addition to the target and the data), and aggregate3Value allows both allowFailure and value. So, I added two new fields to the CallInterpretationInfo type, allowFailure (a boolean) and value (a BN).

When a simple aggregate is detected, these fields will be included in the decoding, with allowFailure set to false and value set to zero. When a tryAggregate is detected, allowFailure will be set to the negation of the requireSuccess field.

When aggregate3 or aggregate3Value is detected, these will be set as appropriate (with value always being zero in the former case). The thing to note here is that while I added fields to CallInterpretationInfo, I didn't add any new interpretations; I just had aggregate3 and aggregate3Value continue to use the aggregate interpretation, just with non-default values potentially for allowFailure and value. I think this should be fine, but let me know if it's not. It's not like you can't distinguish if you don't want to (just check the ABI in the decoding!). We already have other combined interpretations like this.

(I was originally going to make these changes in a breaking manner due to a misunderstanding on my part, but ultimately I did it in this non-breaking way instead.)

I also updated the inspectors to report this new information. I did not update codec-components, as it turns out that codec-components doesn't currently handle this stuff at all, so there was nothing to update.

As for how it's done, there's not a lot to say here, it's basically the same as the existing multicall handling. The one thing of note is that in order to avoid too much tedious repetition, I did factor some stuff into an interpretCallInAggregate method that is used for all of aggregate, tryAggregate, aggregate3, and aggregate3Value; although in the case of tryAggregate, the value of allowFailure is set separately afterward.

Testing instructions

I added tests for the new interpretations and upgraded the existing tests to test the new fields. I think that should suffice.

@haltman-at haltman-at merged commit 81c5ec2 into develop Jul 11, 2023
10 checks passed
@haltman-at haltman-at deleted the multicall3 branch July 11, 2023 21:44
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants