Skip to content

Automatically support of all Etherescan-based block explorers #7559

@alcuadrado

Description

@alcuadrado

Describe the issue

We are getting multiple requests from people trying to use etherscan-based block explorers to very their chains and failing because they don't have the correct type descriptor.

We can improve this situations automatically for all of them, given that etherscan now has an api that lists all the chains they support, with a similar format than our type descriptors: https://api.etherscan.io/v2/chainlist

We should modify the hardhat-verify plugin to fallback to using that list when a chain doesn't have a chaindescriptor.

Design

I don't think this merits a design doc. What we should do is:

  • If there's a chain descriptor, use that.
  • If there isn't, download that list. Potentially caching it.
  • Find the chain by id in that list
  • If not found, go through the usual failure workflow. Maybe mentioning that the chain isn't supported by etherscan.
  • If found, use that data to verify.

Open question

  1. It's unclear what status and comment mean. I asked the etherscan team about it, and will fwd the answer here. I believe "status": 1 means operational.
  2. How would the caching relate to "status" != 1? If an explorer goes down, do they change the status? Will the cache prevents us from noticing that? Maybe let's not cache in the first iteration.

Update

Nic from Etherscan answered (1):

It’s not in use for now, we were thinking to post if the contract verification service is having issues

Which invalidates (2), but maybe we don't cache it just yet anyways.

Metadata

Metadata

Assignees

Projects

Status

Backlog

Relationships

None yet

Development

No branches or pull requests

Issue actions