0

While testing some deployment and verification scripts, we deployed a smart contract and verified it on testnet etherscan.

Then redeployed the smart contract again and tried to verify the new contract address on etherscan.

The verification failed with Reason: Already Verified.

Is verification not related to every new contract instance?

Grateful for any insight on this. Thank you!

3
  • I'm not sure why you're getting that reason because it can't be right. Changed contract code and different deployment address. Makes no sense. Wonder if the problem is on localhost preventing it from reverifying.
    – sola24
    Commented Jun 14, 2022 at 20:49
  • @sola Thanks for the response! It's not changed contract code. Same contract code on a different deployment address. Will this cause it to return already verified?
    – em_mutable
    Commented Jun 14, 2022 at 23:40
  • ah. yes. in that case yes it's fine. it's just another instance of the same. you should be able to see the contract source code at the new deployment address on etherscan
    – sola24
    Commented Jun 15, 2022 at 9:31

1 Answer 1

0

In many cases, Etherscan is able to match the newly deployed bytecode to contracts that were verified earlier (if the contract code didn't change). They do this "auto-verification" to expand the list of verified contracts even if developers didn't verify everything.

I've found that it doesn't always automatically verify duplicate contracts, especially when deploying to multiple networks. So it's still a good idea to include the verification step in your workflow, even if you'd expect it to get auto-verified.

To make verification an easy part of your workflow you should use either truffle-plugin-verify (created by me) or hardhat-etherscan / hardhat-deploy depending on which framework you use.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.