Error verifying on Etherscan: Unable to generate Contract ByteCode and ABI

Hi all,

I have been writing my ERC20 contract on remix sol.0.5.0. Finally the coin is deployable but I cant verify it on Etherscan.

When I try to verify and publish my contract, the following error appears:

Compiler debug log:

Error! Unable to generate Contract ByteCode and ABI (Expected library(ies) but one or more was not provided)

Found the following ContractName(s) in source code : BasicHARBOUR , BlackList , ERC20Interface , OwnableHKDT , Pausable , SafeMath , StandardERC20 , StandardHARBOUR , TESTHARBOURx

But we were unable to locate a matching bytecode (err_code_2)

Can someone please advise on what might be wrong and how to fix this issue?


1 Like

Hi @chloecarvalho220,

The recommended way is to convert your GitHub imports to npm imports and verify using Hardhat: Verify smart contract inheriting from OpenZeppelin Contracts

Alternatively, you can flatten your contract (you will still need to convert your GitHub imports to npm imports), encode your constructor parameters using:


I have followed your instructions and am now on my last step.

However, I have encounter an error while trying to run “npx hardhat verify --network (…)”.
My error was: “Error HH303: Unrecognized task verify”.

Would you be able to assist?

Thank you so much for your help again.

1 Like


Forgot to ask!
In the field where it says “accounts: {mnemonic: mnemonic}”, does mnemonic mean my wallet address used to deploy the contract? I am trying to verify on Rospten.

Thank you very much once again.

1 Like

Hi @chloecarvalho220,

It sounds like you don’t have the Etherscan plugin configured.

Do you have the following in your hardhat config?


See the instructions:

The mnemonic is stored in a secret, such as a .env file or secrets.json to an account on that network. As you aren’t doing transactions, this doesn’t need to have any funds.

:warning: I have deleted the screenshot. It included your Etherscan API key. I recommend deleting this API key and creating a new one. You should store secrets such as API keys in a secure way and ensure that you don’t commit them to version control. I tend to use either a secrets.json file or a .env file.