This repository manages SetProtocol V2 Strategies contract deployments using the hardhat-deploy plugin. Each deployment is tracked and recorded by network in a deployments/outputs file.
These deployments are peripheral to the core SetProtocol system and include things like SetToken strategy contracts, example SetToken instances and other helper contracts.
All proposed deployments should:
- deploy to HardhatEVM
- have unit tests which check the correctness of state variables set in the constructor
- be deployed to a testnet have its contract code verified on a block explorer like Etherscan
Several networks are supported and each one is managed in its own folder.
There are dedicated environments for:
- Ethereum (mainnet, kovan)
- Polygon (mainnet-polygon, mumbai, goerli)
- Optimism (mainnet, kovan)
- Arbitrum (mainnet, rinkeby)
- Avalanche (mainnet, fuji)
To run commands like test, deploy, navigate to the folder for the chain you're working with.
Run these commands in the project root.
cp .env.default .env
yarn
cd <chain_folder> // e.g ethereum, polygon, etc
We use the hardhat network forking feature to simulate and test deployments. You'll need a valid alchemy.com project id to run these.
yarn clean-dev-deployment
yarn deploy:local
yarn test
Fill in the following fields in your .env file:
KOVAN_DEPLOY_PRIVATE_KEY: An automated kovan faucet is here, or at myCrypto, hereINFURA_TOKEN: An Infura projectID. Available with an account at infura.ioETHERSCAN_API_KEY: Available with an account from etherscan.io/api
Run:
yarn deploy:kovan
yarn etherscan:kovan
(If etherscan fails, see the Etherscan section below).
New deployments have at least two (and sometimes 3) phases:
| Phase | Pull Request / Op | Pre-requisites |
|---|---|---|
| 1 | Deployment script PR with tests | Code merged at set-v2-strategies & published to npm |
| 2 | Executed deployment PR | Phase 1 complete |
| 3 | Activate new components via Gnosis multisig | Phase 2 complete & deployment is production |
Create the new files you'll need by running the create:deployment command.
This will generate files numbered for the latest stage in the deploy, deployments, and test folders.
$ yarn create:deployment my_deployment_name
New deployment files at:
> .../ethereum/deploy/001_my_deployment_name.ts
> .../ethereum/deployments/constants/001_my_deployment_name.ts
> .../ethereum/test/deploys/001_my_deployment_name.spec.tsThen, find the most recent scripts and tests which are suitable templates for your deployment and copy/paste them into the new files, adapting as necessary.
💡 Pro Tips 💡:
- Verify new contracts on Kovan to catch any contract verification issues early in the process.
- Useful helpers can be found in outputHelper.ts and deployUtils.ts
- Addresses for on-chain dependencies can be found in dependencies.ts
| Step | Action | Command |
|---|---|---|
| 1 | Checkout master, git pull, and run yarn |
|
| 2 | Checkout a new branch | git checkout -b alex/deploy_.... |
| 3 | Deploy to staging_mainnet |
yarn deploy:staging_mainnet |
| 4 | Verify deployment on Etherscan | yarn etherscan:staging_mainnet |
| 5 | Check contracts' read/write endpoints in Etherscan's UI | |
| 6 | Deploy to production |
yarn deploy:production |
| 7 | Verify deployment on Etherscan | yarn etherscan:production |
| 8 | Commit automated changes made to outputs logs | |
| 9 | Open PR documenting the addresses of new components |
When modules, integrations, and price oracles are added to Set in production, @asoong and @felix2feng enable them via multisig with Gnosis Safe wallets online.
Deployment scripts should save the tx data generated for these deferred transactions using a flow similar to that used in deployUtils#addIntegrationToRegistry.
Resources:
- Master list of pending and completed multisig operations (only accessible to SetProtocol engineers)
- Multisig transaction utilities in this repo.
This repository uses semantic-release to automatically publish in CI on merge to master. We
only publish metadata about staging and production deployments and releases are only necessary
when there are changes to the network/deployments/outputs production or staging files.
Use the following naming convention in your PR descriptions
- chore: no release:
chore(scripts): description- example:
chore(scripts): DelegatedBaseManager Optimism deploy scripts
- example:
- feature release (e.g 1.1.0 -> 1.2.0):
feat(deploy): description- example:
feat(deploy): Deploy DelegatedBaseManager to Optimism production
- example:
- Etherscan API keys
- Infura (for project ids)
- Kovan faucets:
- Polygon/matic docs
- Mumbai faucet
- Goerli faucet
- Matic mainnet bridge wallet (for moving mainnet funds w/ Metamask, WalletConnect)
Set ETHERSCAN_API_KEY to a valid Etherscan API key in .env
After deploying, run the command for your network:
yarn etherscan:kovan
yarn etherscan:staging_mainnet
yarn etherscan:production
When Etherscan fails...
Verification may fail because of solidity issue 9573 which causes Etherscan to generate different bytecode from a minimized contract set than what was generated locally with all contracts in the project. The error message says:
Compiling your contract excluding unrelated contracts did not produce identical bytecode.
...
NomicLabsHardhatPluginError: Source code exceeds max accepted (500k chars) length
To get around this, use the compile:one task to compile your target contract in isolation.
In a deployment script, right before the problematic contract is deployed:
// Compile in isolation for Etherscan verification bug
await bre.run("set:compile:one", { contractName: "GeneralIndexModule"});... or a the command line:
yarn compile:one GeneralIndexModule
yarn deploy:kovan
yarn etherscan:kovanThe create:deployment command creates standard files necessary for each new deployment. It takes a deployment name as an argument and automatically prefixes it with the next increment of the deployment sequence.
$ yarn create:deployment my_deployment_name
New deployment files at:
> .../ethereum/deploy/001_my_deployment_name.ts
> .../ethereum/deployments/constants/001_my_deployment_name.ts
> .../ethereum/test/deploys/001_my_deployment_name.spec.ts