The Ultimate Ethereum Mainnet Deployment Guide

All you need to know to deploy to the Ethereum mainnet

We all love Ethereum, so you've built some great smart contracts. They are tested intensely with unit-tests and on testnets. Now it's finally time to go to mainnet. But this is a tricky business...

1. What exactly is a deployment transaction?

First let's quickly discuss what a contract deployment is on a low level. Any Ethereum transaction itself consists of only a few properties and there are generally three types of transactions:

Sending Ether
Deploying a smart contract
Interacting with a smart contract

Some parts of a transaction are always the same for all three transactions: from, value, gas, gasPrice and nonce. The difference between them comes from the to and data parameter which stand for where the transaction is sent to and which data to send along with it.

Sending Ether:

to: ETH receiver address
data: empty (there's no smart contract involved here)

Deploying a smart contract

to: empty (we have no smart contract address yet, since we are only creating it just now)
data: the bytecode of the smart contract (the result of compiling your smart contract)

Interacting with a smart contract

to: the smart contract address
data: the function selector followed by the input data to the function

2. Considerations pre deployment

It should be no surprise by now that smart contract security is extremely important. And while you should follow best practices from the beginning, getting an audit before deploying to mainnet is the last and critical step. You can use https://www.smartcontractaudits.com/ to find a suitable auditor.

Secondly consider the security of your private keys. While for a testnet it's perfectly fine to just have a private key stored on your machine, this is not good enough for mainnet. Assuming you have some kind of access control, addresses with control over very critical aspects should be a multi-sig contract. This is its own smart contract which you can setup yourself. For example a 5 out of 7 multisig would require 5 addresses of a total of 7 to sign a transaction. You can use an app like Gnosis Safe to create one. And the private keys itself would all ideally be from hardware wallets like Ledger and Trezor.

3. How to do the actual deployment

In total what you'll need to deploy a contract is

Your contract's bytecode – this is generated through compilation.
A private key to an Ethereum address with enough ETH to pay for gas.
A deployment tool or script.
An Ethereum node service like Infura or QuikNode or simply by running your own node

Now there are some tools to help you with and I can tell you, some work better than others for mainnet.

a. Truffle

Truffle is still a very widely used tool especially for deployments. It can do many things from smart contract compilation to automated testing. But now we are interested in its migrations which are used for deployments.

Typical Truffle configuration

On the right you see a very typical truffle config. Here you can see how we solve a lot of the requirements for deploying a contract:

Compilation: We define our solc version in the compilers section. Truffle will automatically compile our contracts before any deployments.
Private key: We use the hdwallet-provider to create a private key from a mnemonic. This is also a good option for mainnet. However, remember to change ownership of contracts after deployment to something more secure. Or use a Trezor or Ledger provider directly with some extra work.
Infura: We pass our Infura endpoint here with our key. This can be changed to whatever endpoint service you're using or a url to your own node.

Migrations

The migrations are special scripts for you to define how to deploy a smart contract. This is particularly useful if you have multiple contracts to deploy which depend on each other or if you need to call functions on any contracts after the deployment.

Check out the migrations link here for the full documentation on how to use them.

require("dotenv").config();
const HDWalletProvider = require("@truffle/hdwallet-provider");

const { MNEMONIC, INFURA_API_KEY } = process.env;
const kovanUrl = `https://kovan.infura.io/v3/${INFURA_API_KEY}`;
const mainnetUrl = `https://mainnet.infura.io/v3/${INFURA_API_KEY}`;

module.exports = {
  networks: {
    development: {
      host: "127.0.0.1",
      port: 7545,
      network_id: "*",
    },
    mainnet: {
      provider: () => new HDWalletProvider(MNEMONIC, mainnetUrl),
      network_id: 1,
    },
    kovan: {
      provider: () => new HDWalletProvider(MNEMONIC, kovanUrl),
      network_id: 42,
    },
  },
  compilers: {
    solc: {
        version: "0.8.4",
        optimizer: { enabled: true, runs: 200 }
    },
  },
};

var MyContract = artifacts.require("MyContract");

module.exports = deployer => {
  deployer.then(async () => {
    await deployer.deploy(MyContract, param1, param2);
    const myContract = await MyContract.deployed();
    await myContract.changeOwnership(multiSigAddress);
  });
};

Here you can see a typical migrations script that utilizes the async/await syntax. After the deployment we transfer the ownership to an already deployed multisig contract.

Check out the migrations link here for the full documentation on how to use them.

Downsides of using Truffle for mainnet

It's worth mentioning that Truffle itself is far from optimal to deploy to mainnet for several reasons:

A special migrations contract being deployed increases gas costs. And even though highly requested, it's still not possible to easily remove it.
Long migrations in Truffle are very, very painful on mainnet.

Gas prices make mainnet deployments very hard. You can set a gas price in the Truffle config, but this will be one gas price for the whole period of your migrations. So if gas prices are increasing a lot during your deployment, good luck getting them included into a block by miners. If a transaction is not mined in a few minutes, Truffle will just stop your deployment. Your only option is to set a very high gas price and hope everything deploys quickly.
Your internet connection might cause problems. You better not loose your connection during long deployments or otherwise prepare to start from the beginning again.

At the least Truffle now does dry run simulations before the actual deployments. You can skip those on testnets using --skip-dry-run, but don't do this for mainnet. It will ensure you at least don't get any transaction reverts in the middle having to restart from the beginning.

All in all if you have the money to pay for the increased costs using Truffle go ahead and use it. Otherwise read on for alternatives.

b. Remix

Remix is my favorite tool for quick mainnet deployments. You have full control over what's happening, because you will do each step manually using MetaMask.

Once you have a compiled contract, deploying is as easy as typing the input parameters and clicking deploy. You can get deployable contracts for Remix from Truffle using truffle-flattener or for Hardhat using the built-in flatten command. Since you are using MetaMask, you will

be automatically connected to Infura
have the ability to deploy with hardware wallets
be able to choose an exact gas price for each transaction
be able to speed up or cancel pending transactions

Downsides of using Remix

It's not all roses and unicorns however. With Remix you have to do every step manually. That means entering every parameter manually. Deploying every contract manually. Calling every function manually. You can see how painful this would be for very long deployment procedures.

c. Hardhat

There's no direct support for deployments in Hardhat. However you can write a script that deploys a contract via ethers.js and call it from the hardhat command. An example on how to do this can be seen in the solidity-template.

You can see the example deploy script on the right. The script can be invoked using:

$ npx hardhat run scripts/deploy.ts

Alternatively, you can use the hardhat-deploy plugin which most interestingly adds capability to store finished deployments in files.

import { Contract, ContractFactory } from "ethers";
import { ethers } from "hardhat";

async function main(): Promise<void> {
  const Greeter: ContractFactory
      = await ethers.getContractFactory("Greeter");
  const greeter: Contract
      = await Greeter.deploy("Hello, Buidler!");
  await greeter.deployed();

  console.log("Greeter deployed to: ", greeter.address);
}

main()
  .then(() => process.exit(0))
  .catch((error: Error) => {
    console.error(error);
    process.exit(1);
  });

d. Web3

Of course you can always build your custom deployment logic directly using Web3 (or ethers.js). This is very useful when you are deploying contracts frequently and require custom logic for storing the deployment information. Web3 directly supports deployments using myContract.deploy().

const myContract = new web3.eth.Contract(jsonABI)
myContract.deploy({
    data: '0x12345...', // bytecode
    arguments: [123, 'My String'] // constructor arguments
}).send({
    from: '0x1234567890123456789012345678901234567891',
    gas: 1500000,
    gasPrice: '30000000000000'
}

e. Truffle Teams (Premium)

Remember the issues with deploying to mainnet with Truffle from above? Well there's a solution for them called Truffle Teams. It's free for open-source projects, but otherwise will cost a few dollars per month. But with it you get a project dashboard. This comes with a direct connection to Github and is running your tests as continuous integration. Any successful builds can then be deployed from the dashboard.

This allows you to connect MetaMask for your deployments, meaning full control of gas prices and speeding them up.

See the full documentation for the Truffle Teams deployments here.

4. Considerations post deployment

Right after the deployment to mainnet, you should verify the contract source code on Etherscan and Sourcify. This involves submitting the Solidity code to the service which will compile it and verify that it matches the deployed bytecode. After a successful verification users get more information in Etherscan, can directly interact with it on Etherscan or fetch the code from Sourcify from supporting tools like Remix.

You can verify your contracts manually on the Etherscan website. Alternatively there are plugins for automatic verification using Truffle, Hardhat and a direct Etherscan API.

For how to use Sourcify, check out my previous blog post here.

Markus Waas

Solidity Developer