You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We suggest adding Blockscout as a verification provider to Hardhat. Technically, it is possible right now to verify contracts on blockscout Explorer via etherscan configuration. But we would like to propose adding an explicit blockscout option along with existing sourcify and etherscan providers.
Motivation
Using etherscan configuration requires specifying an API key even though blockscout does not need one. Users have to select any non-empty key to avoid that limitation. Having blockscout specified explicitly allows them to have blockscout support without any workarounds.
It also helps to integrate blockscout-specific features into the process in the future. For example, for enforcing smart contracts verification, added in #5164, it does not distinguish between partially and fully verified contracts, returning an error if the contract has already been fully verified. We may add that distinction to the usual verification process to avoid using the --force flag. Besides, we are currently working on a separate application that will allow us to verify the contracts on several blockscout chains (link). In the future, this could be used to prevent users from specifying the details for the most common chains at all.
We are witnessing an increasing number of users, in general, asking whether hardhat supports blockscout and how to use it for contract verification. And it would be nice if Hardhat could support blockscout as a separate option.
Suggestion
Our proposal involves creating a separate Blockscout class that would be integrated into the current Hardhat configuration. This class would share most of its methods with the existing Etherscan implementation, with the key difference being the absence of the api_key option requirement. Further enhancements can be discussed in separate issues.
If agreed upon, we may work on the corresponding PR with your guidance on how you see that implemented.
Search terms
No response
The text was updated successfully, but these errors were encountered:
We discussed this internally and it looks like something we'd be open to add to the hardhat-verify plugin. We don't have the bandwidth to do it ourselves right now. Will you be open to send a PR?
If so, I think we can start with you providing a list of changes that you think are needed, both at the product/functional level, and technical level. Then we can go through it, and provide feedback and technical guidance.
Describe the feature
We suggest adding Blockscout as a verification provider to Hardhat. Technically, it is possible right now to verify contracts on blockscout Explorer via etherscan configuration. But we would like to propose adding an explicit blockscout option along with existing sourcify and etherscan providers.
Motivation
Using etherscan configuration requires specifying an API key even though blockscout does not need one. Users have to select any non-empty key to avoid that limitation. Having blockscout specified explicitly allows them to have blockscout support without any workarounds.
It also helps to integrate blockscout-specific features into the process in the future. For example, for enforcing smart contracts verification, added in #5164, it does not distinguish between partially and fully verified contracts, returning an error if the contract has already been fully verified. We may add that distinction to the usual verification process to avoid using the
--force
flag. Besides, we are currently working on a separate application that will allow us to verify the contracts on several blockscout chains (link). In the future, this could be used to prevent users from specifying the details for the most common chains at all.We are witnessing an increasing number of users, in general, asking whether hardhat supports blockscout and how to use it for contract verification. And it would be nice if Hardhat could support blockscout as a separate option.
Suggestion
Our proposal involves creating a separate Blockscout class that would be integrated into the current Hardhat configuration. This class would share most of its methods with the existing Etherscan implementation, with the key difference being the absence of the
api_key
option requirement. Further enhancements can be discussed in separate issues.If agreed upon, we may work on the corresponding PR with your guidance on how you see that implemented.
Search terms
No response
The text was updated successfully, but these errors were encountered: