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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Addresses #6079. This PR adds support for the new methods from Multicall v3 --
aggregate3
andaggregate3Value
-- to the decoder's multicall interpretation support.The
aggregate3
method allows you to specifyallowFailure
for each call (in addition to the target and the data), andaggregate3Value
allows bothallowFailure
andvalue
. So, I added two new fields to theCallInterpretationInfo
type,allowFailure
(a boolean) andvalue
(a BN).When a simple
aggregate
is detected, these fields will be included in the decoding, withallowFailure
set tofalse
andvalue
set to zero. When atryAggregate
is detected,allowFailure
will be set to the negation of therequireSuccess
field.When
aggregate3
oraggregate3Value
is detected, these will be set as appropriate (withvalue
always being zero in the former case). The thing to note here is that while I added fields toCallInterpretationInfo
, I didn't add any new interpretations; I just hadaggregate3
andaggregate3Value
continue to use theaggregate
interpretation, just with non-default values potentially forallowFailure
andvalue
. 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 ofaggregate
,tryAggregate
,aggregate3
, andaggregate3Value
; although in the case oftryAggregate
, the value ofallowFailure
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.