OpenZeppelin project file with dynamic constructor arguments


I am trying to deploy multiple contracts using OpenZeppelin. The contracts deployed later have constructor arguments from the contracts deployed earlier.

A simplified deployment structure:

  • token1: ERC-20
  • token2: ERC-20
  • tokenSwap(token1.address, token2.address)
  • tokenFaucet(token1.address)
  • None of the contracts need any proxy of fancy features in this point, as it is a testnet deployment

I did not figure out how to write a OZ project file that has non-hardcoded constructor arguments? Is this possible? Are there any examples for this, or any other complex open source projects? The documentation here is a bit light:

1 Like

Hey @miohtama, I’m assuming you are using the OpenZeppelin CLI here. The CLI will output to stdout the deployment address whenever you run oz create. So you could use bash variables to capture the deployment addresses and reuse them in subsequent commands. Off the top of my head (beware for I have not tested this code), it would look more or less like this:

$ export OPENZEPPELIN_NON_INTERACTIVE=1 # optional for removing interactive prompts
$ TOKEN1=$(oz create ERC20 --network development)
$ TOKEN2=$(oz create ERC20 --network development)
$ TOKENSWAP=$(oz create ERC20 --network development --init --args "$TOKEN1,$TOKEN2")
1 Like

Hi @miohtama,

Were you able to give the above solution a try? Feel free to ask all the questions that you need.

No, I think using Bash scripting is little bit unrefined for this approach.

I wrote my own quick deployment script in JavaScript.

I will share it in upcoming days.


Here is now my example script:

The real world challenges are

  • A lot of contracts have constructor, initializer or other arguments that need to be specific somewhere

  • You want to have the smart contract deployment to be a repeatable automated process, not something you do by a hand on command line

  • Multiple different smart contracts, accounts and relationships like setting up parameters and contract linking (SafeMath) has to be done

  • All of these has to be verified on EtherScan

  • Everything must have an audit log and human readable record to be manually verified and stored

I have so far got to the point where I need to figure out how to programmatically verify OpenZeppelin deployed contracts on EtherScan. I will post another forum question on it.

1 Like