Verify contract on Etherscan with OpenZeppelin Contracts imports

What is the good way to verify a contract that is importing OZ contract.

Do I have to change all the imports in each file??

I only compile with truffle and I deploy using Ethers

So my imports refer to OZ node modules contract.

But all the imports are not working when I try to validate.

So do i have to edit all OZ Contract and edit them to point to the current folder?

1 Like

Hi @madeindreams,

I recommend the following process on Hardhat: Verify smart contract inheriting from OpenZeppelin Contracts

The alternative is to flatten your contract but you need to ensure that you use an appropriate license.

Hello @abcoathup

This solution is good but I’m always the special case :grin:! Let me explain.
I deploy my contract using ethers. I only compile them whit truffle. Now for all the unique contract that I deploy myself, your solution is good.

But then when I release my app at large, the user will be able to deploy precompiled contract from there app. Technically they dont see the contract even if I provide them the source.
And I went to all the effort to make my app 0 dev knowledge friendly. The users can deploy an use contract within a few clicks. So I’m looking for a way to get these contract verified.
They will all be identical.

I don’t mind going the extra mile and save the trouble to all my users, this is the goal.

Should I start looking into etherscan api for that or do you have another solution for me?

Even if it mean’s I have some files that are deploy with my app only to validate the source code with import that are not conflicting.

1 Like

I’m trying out flattener but what am i excepting?

I can see all the contract in the console but there is now new file created is this going to create one file somewhere? Github doesn’t say much about it.

1 Like

Hi @madeindreams,

If I understand correctly, you have an app that generates smart contract code and you want to verify this for your users.

If the smart contract code is the same, then it will have the same bytecode, so verifying one contract will verify them all, even if the constructor parameters are different.

1 Like

Wow I did not know that! Thank you.

It’s kinda funny because my contracts interface each other. The main one I provided the encoded constructor and it got verified. When I came to verify the second one which take the address of the first contract as an argument. The encoded argument was already filled in for me.

1 Like