-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Description
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
- It's unclear what
status
andcomment
mean. I asked the etherscan team about it, and will fwd the answer here. I believe"status": 1
means operational. - 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
Labels
Type
Projects
Status