Help for verify on BSCscan

Hello, i make a big detailed topic but " Sorry, new users can only mention 2 users in a post." :rofl:

so i make this simple

I have trouble verify my contract on bscscan, it’s been about 2 days I try everythings i can.

I used truffle, multi file, i try to flattened but i always have errors, the best try i have it’s with hardhat but:

when I use:

// hardhat.config.js
const { mnemonic, bscscanApiKey } = require(’./secrets.json’);

** * @type import(‘hardhat/config’).HardhatUserConfig**
** /*
module.exports = {

** networks: {**
** testnet: {**
** url:,**
** accounts: {mnemonic: mnemonic}**
** },**
** mainnet: {**
** url:,**
** accounts: {mnemonic: mnemonic}**
** }**
** },**

** etherscan: {**
** // Your API key for Etherscan**
** // Obtain one at**
** apiKey: bscscanApiKey**
** },**
** solidity: “0.8.1”**

it says he don’t find secret.json.

I tried to fix this but when i create my secret.json with my mnemonic seed phrase I have another error: Unexpected token C in JSON at position 0

so i modify the config.json and put:

const {mnemonic} = I put my seed phrase
const {bscscanApikey} = I put my api key

insteed of
const { mnemonic, bscscanApiKey } = require(’./secrets.json’);

it’s seems to work but i have an error like:
error in plugin @nomiclabse/hardhat-etherscan: the adress povided as argument contains a contract, but its bytecode doesn’t match any of your local contracts.
possible causes are:
-contract code changed after deployement was executed this includes codre for seemingly unrelated contracts.

  • A solidity file was added moved deleted or renamed after the deployement was executed…

I supposed it’s because I use" import @" insteed of “import https” so i switch in my contract but hardhat don’t support “import https”

EDIT I found how to make a corect secret.json file with the mnemonic but I have the error above error in plugin etc…

i don’t know what to do, if someone can help me please.
it’s always hard to verify a contract or it’s just me and my skill :stuck_out_tongue: ?

Sorry for my English i do my best but i’m not very good. Hope someone can help me

Hi, welcome! :wave:

I think it is ok to import contract with import "@openzeppelin/contracts/xxx";
Maybe you do not use the current code to deploy.

Hi and thanks for your answer @Skyge !

I deploy the token on Remix with:
import “”;

But when I verified with hardhat, hardhat dont’ support “import https”. but if I try to verify with :
import “@openzepplin/contracts/token/ERC20/ERC20.sol”;

I have the message error:
error in plugin @nomiclabse/hardhat-etherscan: the adress povided as argument contains a contract, but its bytecode doesn’t match any of your local contracts…

So I think it’s because I use “https” when i deploy the contract insteed of “@”, but i don’t know how can i do to verify this contract. I currently try with some other flattener, i hope it’s work.

Hey @Skyge , a relevant question, what contracts should be verified and what should not? Is there a basic requirement for that? If a DApp has 10+ contracts with various purposes, I suppose those that are token related should be verified, but it is OK not to verify contracts like SafeMath, what do you think?

Hi @maxaero I have to verify my contract to upgrade the social profile, put a logo, people are able to read the contract etc…
I don’t know if it answer your question but I think you need to verify if you want to see how it works.

If you deployed contracts with Remix, and now, you are trying to verify it, I think you can have a look at this tutorial

1 Like

For a single contract, yes, it should be verified. For a DApp with multiple contracts, whether all contracts are required to be verified is a question.

Waw it was so easy, it’s been 3 days I learned how to use truffle, truffle flattener, hardhat etc to verify my contract and the good guide was just in front of my eyes…

Mega big thanks @skyge !!! my contact is verified !

1 Like

For example:

contract A
contract B is A
contract C is B

If you deploy contract B and want to verify it, it will need contract A and contract B, and if you deploy contract C and want to verify it, it will need contract A, B, C. So when verify a contract, it needs all relative contracts. Have I made it clear?

1 Like

You’ve made that piece of logic clear. Here is another piece.

contract A
contract B (is calling A)
contract C (is calling A and B)

In this case, in order to verify B with interface to A, I suppose A is not necessarily verified. Likewise, if C can be verified without having A and B both verified. An experiment can be easily done, but thought it might be an interesting topic.

Actually, I always use tool to verify contracts rather than verify code manually. And I think if your contract like following:

interface A {
    function action() external;

contract B {
    function one() public {

you can not just upload B to verify, it will need both A and B,
Shortly, when you want to upload a file to verify, at least it should be compiled without errors.

Contract B does not have to know contract A to call A as long as the interface and contract address of A is given. I did a little modification. This is what I had in mind.

Also just to have this clarified, the motivation behind this mental experiment is someone may want to hide the logics in A and wish not to verify A, but verifying B and making it public is fine. I believe this is a very practical problem. It is not meant to be a challenge for the sake of being a challenge.

interface A {
    function action() external;

contract B {
    function one(address addr) public {