I ensured the build\contracts, cache, artifacts and .openzeppelin folders were deleted before the above steps. It seems that a simple contract is unable to be verified using Truffle. Is this a bug, or am I doing something wrong?
Code to reproduce
This is the contract:
pragma solidity ^0.8.0;
import "@openzeppelin/contracts-upgradeable/token/ERC20/presets/ERC20PresetMinterPauserUpgradeable.sol";
contract Foo is ERC20PresetMinterPauserUpgradeable {
function initialize() initializer public {
super.initialize("Foo", "FOO");
}
}
Hey @Neo! I’m not familiar with the truffle-plugin-verify, but my guess is there’s a good chance that it’s actually trying to verify the proxy contract using the implementation contract code. You can try running the verify step with --debug to find out whats happening under the hood.
If that’s the case, a workaround would be to explicitly set the implementation contract deployment address to the verify step. To do that, get the implementation address from your .openzeppelin/NETWORK.json file (it should be within the the impls entry), and run the verify step like:
npx truffle run verify Foo@ADDRESS --network rinkeby
Where ADDRESS should be the impl address you got from the .openzeppelin folder. Check the “Address Override” section in the verify plugin readme for more info.
Thanks for the reply, but no joy, unfortunately. I linked to the contract in my question, and the contract address is indeed the one I can see in .openzeppelin/rinkeby.json. So, this is the command I used:
npx truffle run verify Foo@0xdb170C5c84f2228425B1fbEc9B121AD77D8ef72D --network rinkeby
OK, crisis averted. I tried again, but this time deleting the .openzeppelin folder first, and it worked!
Thanks for your help with this, and I hope anyone searching for a similar problem finds this simple ‘solution’.
EDIT:
Hmm, it failed again later, despite deleting the .openzeppelin folder. However, adding the address as per @spalladino’s answer fixed it. Perhaps there were two issues, and deleting the .openzeppelin folder as well as adding the address to the verify command fixes either. In any case, all fixed, so all good!
Happy to hear it worked, Neo! Still, you should not delete the .openzeppelin folder, since it keeps track of the implementation contracts you have deployed. If you delete it, the plugins won’t be able to validate if a future upgrade is safe to execute or not, since the info on the older implementation is lost when you delete the folder.
I suspect that it was littered with lots of previous compilations of the same contracts and migration scripts due to lots of recompiles and migrates with --reset. So, it was possibly just a complete mess while I’ve been trying to get the whole thing working.
Btw, is it advisable, from what you said, to keep the contents of the .openzeppelin folder in source control?