Add v2 verify routes

[iainnash]

• Fix existing verify integration tests
• Add standard-json-input integration tests
• Fix current single file test
• Add v2 integration tests
• Allow v2 setting on client with etherscan client

This is a prerequisite PR for foundry-rs/foundry#9196

Notes:

• Fantomscan test has no env var passed in and can be removed safely.
• Gas estimates now do not fail with even 1 passed in, so skipping the failure test because I couldn't find a failure test.

[mattsse]

ty, smol nits and suggestions

[iainnash]

@mattsse updated with suggestions

[mattsse]

sorry for the delay, last nits

[mattsse]

then this can just call new ad with_version(v2)

[iainnash]

A little confused as to where this would be called -- within the builder or skip the builder entirely and use with_version() rather than new_v2_from_env?

[sakulstra]

Hey, not sure if it#s the right place to comment, but i think there's currently a little bug in the etherscan verification that could be considered when migrating to v2.

If there's a similar match, it seems like foundry currently skips verification, but it should not.
I benchmarked etherscan a bit, and seems like the etherscan api is highly irregular (at least on v1).
Some networks(e.g. mainnet & base) will report SimilarMatch as part of the response, but also provide SourceCode.
Some networks(e.g. sonic) will throw an error.
Some networks(e.g. zksync) will just return SourceCode and not indicate anything.

Perhaps foundry should always try to verify and not even bother to check if it's verified or not.

[iainnash]

That’s a good point. I wonder if you just could try to verify and if it’s already verified the api fails is a better flow than checking first.

…

On Thu, Feb 27, 2025 at 08:52 Lukas ***@***.***> wrote: Hey, not sure if it#s the right place to comment, but i think there's currently a little bug in the etherscan verification. If there's a similar match, it seems like foundry currently skips verification, but it should not. I benchmarked etherscan a bit, and seems like the etherscan api is highly irregular (at least on v1). Some networks(e.g. mainnet & base) will report SimilarMatch as part of the response, but also provide SourceCode. Some networks(e.g. sonic) will throw an error. Some networks(e.g. zksync) will just return SourceCode and not indicate anything. Perhaps foundry should always try to verify and not even bother to check if it's verified or not. — Reply to this email directly, view it on GitHub <#73 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGMCOCHXVEBEXKVIMXCB4D2R4KDPAVCNFSM6AAAAABUWWM3SWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBYGAZDSOJYGA> . You are receiving this because you authored the thread.Message ID: ***@***.***> [image: sakulstra]*sakulstra* left a comment (foundry-rs/block-explorers#73) <#73 (comment)> Hey, not sure if it#s the right place to comment, but i think there's currently a little bug in the etherscan verification. If there's a similar match, it seems like foundry currently skips verification, but it should not. I benchmarked etherscan a bit, and seems like the etherscan api is highly irregular (at least on v1). Some networks(e.g. mainnet & base) will report SimilarMatch as part of the response, but also provide SourceCode. Some networks(e.g. sonic) will throw an error. Some networks(e.g. zksync) will just return SourceCode and not indicate anything. Perhaps foundry should always try to verify and not even bother to check if it's verified or not. — Reply to this email directly, view it on GitHub <#73 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGMCOCHXVEBEXKVIMXCB4D2R4KDPAVCNFSM6AAAAABUWWM3SWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBYGAZDSOJYGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[0xV4L3NT1N3]

Tracking this as well, happy to take any questions from Etherscan's end!

@sakulstra noted on the Similar Match case, this new field is being added to all chains and will be standardised

[mattsse]

ty!

terribly sorry for the delay here...

this lgtm! especially since this is opt-in, we can try experiment with this in foundry and see what we're missing