Preparing for Mainnet

After running your project on a testnet for some time without issues, you will want to deploy it to the main Ethereum network (aka mainnet). However, the planning for going to mainnet should begin much earlier than your planned release date.

In this guide, we will go through Ethereum-specific considerations for taking your project to production, such as:

Remember that, while managing your contracts in a testnet and in mainnet is technically the same, there are important differences when on mainnet, since your project now manages real value for your users.

Auditing and Security

While security affects all of software development, security in smart contracts is particularly important. Anyone can send a transaction directly to your contracts with any payload, and all your contract code and state is publicly accessible. To make matters worse, in the event you are hacked, there is no recourse to reclaim the stolen funds - they are gone for good in a decentralized network.

With this in mind, security should be a primary concern at all stages of development. This means that security is not something that you sprinkle on your project a week before you release, but a guiding principle since day one of your project.

Review smart contract security best practices as you begin coding, join the security discussions in our forum, and make sure to go through our quality checklist to ensure your project is healthy.

Once you are done, it’s a good time to request an audit with one or more auditing firms. Here you can contact the OpenZeppelin Security team directly for an audit - we are an experienced team with a long track record.

Remember that audits do not ensure the absence of bugs, but having several experienced security researchers go through your code certainly helps.

Verifying your Source Code with the CLI

Right after you deploy your contracts to mainnet, you should verify their source code. This process involves submitting the Solidity code to a third-party, such as Etherscan or Etherchain, who will compile it and verify that it matches the deployed assembly. This allows any user to view your contract code in a block explorer, and know that it corresponds to the assembly actually running at that address.

You can verify your contracts manually on the Etherscan or Etherchain websites, or have the OpenZeppelin CLI do it for you.

To do this, run the oz verify command on your project:

$ oz verify
? Pick a contract: Box
? Pick a network: mainnet
? Was the optimizer enabled when you compiled your contracts? No
? Select an endpoint: etherscan
? Provide an etherscan API KEY: XYZ
Contract source code of Box verified and published successfully
You will need an Etherscan API key to use their service.

Remember that, when you deploy a contract via the OpenZeppelin CLI, both a logic and a proxy contract are deployed. This means that the contract that the user interacts with will be just a proxy, and the actual logic will be in a different one. Etherscan does have support for correctly showing OpenZeppelin proxies and their implementations, but other explorers may not.

Check out our Etherscan-verified proxy and implementation Box contracts to see how they look.

Key Management

When working on mainnet you need to take special care to secure your private keys. The accounts you use to deploy and interact with your contracts will hold real Ether, which has real value and is a tempting target for hackers. Take every precaution to protect your keys, and consider using a hardware wallet if necessary.

Unlike on a testnet, you cannot get mainnet Ether from a faucet. You will need to head to an exchange to trade in other coins or fiat to get real Ether for deploying your contracts.

Additionally, you may define certain accounts to have special privileges in your system - and you should take extra care to secure them.

Admin Accounts

An admin (short for administrator) account is one that has special privileges in your system. For example, an admin may have the power to pause a contract. If such an account were to fall in the hands of a malicious user, they could wreak havoc in your system.

A good option for securing admin accounts is to use a special contract, such as a multisig, instead of a regular externally owned account. A multisig is a contract that can execute any action, as long as a predefined number of trusted members agree upon it. Gnosis Safe is a good multisig to use.

Upgrades Admin

A special administrator account in an OpenZeppelin project is the account with the power to upgrade other contracts. This defaults to the externally owned account used to deploy the contracts: while this is good enough for a local or testnet deployment, in mainnet you need to better secure your contracts. An attacker who gets hold of your upgrade admin account can change any contract in your system!

With this in mind, it is a good idea to change the admin account after deployment - for example, to a multisig. To do this, you can use the set-admin command:

$ npx oz set-admin
? Pick a network: mainnet
? For which instances would you like to transfer ownership? All instances
? Enter an address of a new upgradeability admin: 0xffcf8fdee72ac11b5c542428b35eef5769c409f0
? Warning! If you provide a wrong address, you will lose control over your contracts. Please double check your address and type the last 4 characters of the new admin address. 09f0
✓ Proxy admin owner set to 0xffcf8fdee72ac11b5c542428b35eef5769c409f0
In a standard OpenZeppelin project, all proxies are actually managed by a central ownership contract named the ProxyAdmin, which is in turn owned by the deploying account. Running set-admin on all instances will change the owner of the ProxyAdmin on an atomic transaction. Alternatively, you can change the admin of individual proxies.

When you need to upgrade your contracts, you can transfer ownership back to a secure externally owned account, upgrade via oz upgrade, and then use set-admin to restore ownership to the multisig.

Project Governance

It can be argued that admin accounts reflect that a project is not actually decentralized. After all, if an account can single-handedly change any contract in the system, we are not exactly creating a trustless environment.

Here is where governance comes in. In many cases there will be some operations in your project that require special privileges, from fine-tuning system parameters, to running full contract upgrades. You will need to choose how those actions will be decided upon: whether it is by a small group of trusted developers, or by public voting of all project stakeholders.

There is no right answer here. Which governance scheme you pick for your project will largely depend on what you are building and who your community is.

Next Steps

Congratulations! You have reached the end of the development journey, from writing your first contract to deploying to production. But work is far from over. Now you have to start collecting live user feedback, adding new features to your system (made possible via contract upgrades!), monitoring your application, and ultimately scaling your project.

On this site, you have at your disposal detailed guides and reference for all the projects in the OpenZeppelin platform, so you can pick whatever you need to build your Ethereum application. Happy coding!