Adding support to etherscan-v2

[iainnash]

Motivation

Fixes #9196

For tests to pass and to merge this pr, an update to block-explorers is first required: foundry-rs/block-explorers#82.

Solution

Add case statements and proper flags for ev2 and etherscan-v2 for verifying with etherscan v2 API which sets the /mode for the backend contracts to use different URL structures and logic for interacting with the etherscan API.

Added one test, need to add more or update existing tests to handle new logic.

PR Checklist

• Added Tests
• Added Documentation
• Breaking changes

[grandizzy]

@iainnash there's a new 0.13.1 version of block-explorers released, with fix for foundry-rs/block-explorers#82 Thank you!

[grandizzy]

I think would be nice to have an optional version here in EtherscanOpts too, defaults to v1. @zerosnacks wdyt?

[iainnash]

Makes sense, I can add that.

Testing this it’s going to be nice to use one API key against all chains.

I made a tool called chains at zora which manages api keys and rpc urls globally. May be less useful now https://github.com/ourzora/chains-cli

[zerosnacks]

I'll get in touch with Etherscan to see whether switching to V2 by default and deprecating V1 support altogether makes sense. From the documentation it appears that V2 is available on all chains I would expect them to be and all the relevant RPC methods are available. If not I would agree that using an optional version field here defaulting to V1 would be a good idea.

[iainnash]

I think the transition should be gradual afaik the API key they accept is only the mainnet key and it will fail with other keys which need to hit the specific instances instead.

I can reach out and confirm with them.

[0xV4L3NT1N3]

we'd recommend teams to switch to V2 entirely, all other API methods are available as well for existing code to check if a contract is verified and so on

[sakulstra]

I'm all for using v2, but just to note sth that we noticed on migration from v1 to v2 on our internal services:
Etherscan has the same api limits on v2 vs v1. For us this caused some breakage as on v1 the limit is per chain and on v2 (given it's only one key) it is for all combined. Not sure if this can cause problems on multichain scripts.

[0xV4L3NT1N3]

good concern @sakulstra, it is something we're thinking about and monitoring as users adopt V2

for now we observe most users fare well with a few chains and retry/backoff mechanisms

[grandizzy]

@iainnash given the v1 will be eol at end of May, we should go for v2. Would you be able to wrap up this PR, becomes quite a priority now. thank you!

[iainnash]

Great, updated the underlying package and fixed parsing to support the toml config.

There seems to be an avalanche test failing after changing the default so looking into that now.

[grandizzy]

thank you! going to commit a change to point to required block explorers rev so CI to show exactly status of failed tests and continue from there

[iainnash]

Hi yes! I’m working on parsing the configs. Will push EOD once I finish some seralization.

…

On Tue, Apr 29, 2025 at 08:33 grandizzy ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In crates/verify/src/etherscan/mod.rs <#10298 (comment)>: > @@ -539,6 +550,86 @@ mod tests { assert!(format!("{client:?}").contains("dummykey")); } + #[test] + fn can_extract_etherscan_v2_verify_config() { + let temp = tempdir().unwrap(); + let root = temp.path(); + + let config = r#" + [profile.default] + + [etherscan] + mumbai = { key = "dummykey", chain = 80001, url = "https://api-testnet.polygonscan.com/" } @iainnash <https://github.com/iainnash> given the v1 will be eol at end of May, we should go for v2. Would you be able to wrap up this PR, becomes quite a priority now. thank you! — Reply to this email directly, view it on GitHub <#10298 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGMCOHJKLVILY55TQIUFML235WN7AVCNFSM6AAAAAB3B3VGD6VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDQMBTGE2DGOBVHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[iainnash]

This needs another update to block-explorers :/

The update setting V2 to the default is somewhat large as it requires more functions available on the enum for parsing along with changing the default api version.

foundry-rs/block-explorers#83

[iainnash]

Once this package is released, the tag should be removed.

[mattsse]

tysm for this,

some nits and qs

[mattsse]

should this also be just etherscanapiversion here?

[iainnash]

I wasn’t too sure what the pattern was for the __Resolved struct if it was recommended to be a string since the other fields were and it’d be parsed later. If this is the case I can switch it :). Went back and forth.

[grandizzy]

@iainnash wonder if we really need the extra EtherscanV2 variant of VerificationProviderType or better to have single --verifier etherscan with opts for API version (defaults to v2), something like

• in EtherscanConfig.resolve if api_version is None then set it to v2, otherwise use the version that is set
• add the version option in EtherscanOpts as well and load figment for (similar as we do for key)

For custom verifiers, use v1 as default but allow changing the version to v2:

• in VerifierArgs add a pub verifier_api_version: Option<EtherscanApiVersion>,
• in EtherscanVerificationProvider.client pass the verifier_api_version (same as we do for verifier_url and etherscan_key) and set version accordingly (if verifier_api_version is None and etherscan_key is set then means it is etherscan verifier and should be set to V2, otherwise it's custom verifier and should be set to V1)

wdyt, thanks!