rkalis/truffle-plugin-verify

Support for contracts deployed via a factory?

Closed this issue · 7 comments

julien51 commented

Hello! Thanks for your work on this! This is very exciting for us!

That said, we have a challenge because the contract we'd like to verify (this one for example) is deployed via another contract.

It looks like this causes 2 different issues:

  1. It needs an address inside of the PublicLock.json. This is one is easy, I just manually updated the json file to add one of an existing deployed contract
  2. It needs to find the input field on the transaction which instantiated the contract. This one is trickier, because that transaction was not tiggered by me and since this is an "internal" transaction we do not get to access the input field.

Any way you could support the factories?

rkalis commented

Have you been able to verify these contracts manually through Etherscan? If so, what were the steps you took?

gorgos commented

My latest info is that it's not yet supported by Etherscan, see https://www.reddit.com/r/etherscan/comments/9uzw8i/eip1167_clonefactory_support/.

ffarhanaamin commented

are there any plans to fix this ? as suggested on another thread can we add a CLI argument with ctor params? that would help

rkalis commented

I'll x-post the reply from #35 here as well:

To respond to the issue: there's not a very easy solution yet. I'm considering to add a flag to the CLI to manually provide constructor parameters so it doesn't need to retrieve them from Etherscan. An alternative solution is to potentially use the Truffle Debugger to see if we can trace back the constructor parameters that were used. But for now unfortunately there's no good workaround.

Probably the easiest thing would be add a CLI flag --args that takes in (preferably the unencoded) args, which then get ABI encoded and are used by the plugin instead of trying to retrieve it from Etherscan. I'm open to any PRs that add this functionality.

rkalis commented

thanks to PR #61 from @hellwolf it's now possible to provide the encoded constructor args as a force override with the --forceConstructorArgs option. I'll leave this issue open though since we might want to update this in the future to allow unencoded args or to figure out some automated process.

  • 🎉1
rkalis commented

Since Truffle is being sunset, I don't plan to add new features, so I'm closing this issue. The "manual" constructor arg passing will have to do.