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:

  1. Sending Ether
  2. Deploying a smart contract
  3. 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.

  1. Sending Ether:
    • to: ETH receiver address
    • data: empty (there's no smart contract involved here)
  2. 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)
  3. Interacting with a smart contract
    • to: the smart contract address
    • data: the function selector followed by the input data to the function
Mainnet Deployment Meme

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

Truffling Meme

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

Deployment Meme

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

  1. A special migrations contract being deployed increases gas costs. And even though highly requested, it's still not possible to easily remove it.
  2. 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.

Remix Deploy

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.

Truffle Teams Deployments

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

More great blog posts from Markus Waas

  • Migrating from Truffle to Buidler

    And why you should probably keep both.

    Why Buidler? Proper debugging is a pain with Truffle. Events are way too difficult to use as logging and they don't even work for reverted transactions (when you would need them most). Buidler gives you a console.log for your contracts which is a game changer. And you'll also get stack traces...

    Read more

  • Contract factories and clones

    How to deploy contracts within contracts as easily and gas-efficient as possible

    The factory design pattern is a pretty common pattern used in programming. The idea is simple, instead of creating objects directly, you have an object (the factory) that creates objects for you. In the case of Solidity, an object is a smart contract and so a factory will deploy new contracts for...

    Read more

  • How to use IPFS in your Dapp?

    Using the interplanetary file system in your frontend and contracts

    You may have heard about IPFS before, the Interplanetary File System. The concept has existed for quite some time now, but with IPFS you'll get a more reliable data storage, thanks to their internal use of blockchain technology. Filecoin is a new system that is incentivizing storage for IPFS...

    Read more

  • Downsizing contracts to fight the contract size limit

    What can you do to prevent your contracts from getting too large?

    Why is there a limit? On November 22, 2016 the Spurious Dragon hard-fork introduced EIP-170 which added a smart contract size limit of 24.576 kb. For you as a Solidity developer this means when you add more and more functionality to your contract, at some point you will reach the limit and when...

    Read more

  • Using EXTCODEHASH to secure your systems

    How to safely integrate anyone's smart contract

    What is the EXTCODEHASH? The EVM opcode EXTCODEHASH was added on February 28, 2019 via EIP-1052. Not only does it help to reduce external function calls for compiled Solidity contracts, it also adds additional functionality. It gives you the hash of the code from an address. Since only contract...

    Read more

  • Using the new Uniswap v2 in your contracts

    What's new in Uniswap v2 and how to integrate Uniswap v2

    Note : For Uniswap 3 check out the tutorial here. What is UniSwap? If you're not familiar with Uniswap yet, it's a fully decentralized protocol for automated liquidity provision on Ethereum. An easier-to-understand description would be that it's a decentralized exchange (DEX) relying on external...

    Read more

  • Solidity and Truffle Continuous Integration Setup

    How to setup Travis or Circle CI for Truffle testing along with useful plugins.

    Continuous integration (CI) with Truffle is great for developing once you have a basic set of tests implemented. It allows you to run very long tests, ensure all tests pass before merging a pull request and to keep track of various statistics using additional tools. We will use the Truffle...

    Read more

  • Web3 1.2.5: Revert reason strings

    How to use the new feature

    A new Web3 version was just released and it comes with a new feature that should make your life easier. With the latest version 1.2.5, you can now see the the revert reason if you use the new handleRevert option. You can activate it easily by using web3.eth.handleRevert = true . Now when you use...

    Read more

  • Gaining back control of the internet

    How Ocelot is decentralizing cloud computing

    I recently came across an ambitious company that will completely redefine the way we are using the internet. Or rather, the way we are using its underlying infrastructure which ultimately is the internet. While looking at their offering, I also learned how to get anonymous cloud machines, you...

    Read more

  • Devcon 5 - Review

    Impressions from the conference

    I had a lot to catch up on after Devcon. Also things didn't go quite as planned, so please excuse my delayed review! This year's Devcon was certainly stormy with a big typhoon warning already on day 1. Luckily (for us, not the people in Tokyo), it went right past Osaka. Nevertheless, a lot of...

    Read more

  • Devcon 5 - Information, Events, Links, Telegram

    What you need to know

    Devcon 5 is coming up soon and there are already lots of events available, information about Osaka and more. Here is a short overview: Events Events Calendar Events Google Docs Events Kickback Most events are in all three, but if you really want to see all, you will have to look at all three...

    Read more

  • Design Pattern Solidity: Off-chain beats on-chain

    Why you should do as much as possible off-chain

    As you might have realized, Ethereum transactions are anything but cheap. In particular, if you are computing complex things or storing a lot of data. That means sometimes we cannot put all logic inside Solidity. Instead, we can utilize off-chain computations to help us. A very simple example...

    Read more

  • Design Pattern Solidity: Initialize Contract after Deployment

    How to use the Initializable pattern

    There are a few reasons why you might want to initialize a contract after deployment and not directly by passing constructor arguments. But first let's look at an example: contract MyCrowdsale { uint256 rate; function initialize(uint256 _rate) public { rate = _rate; } } What's the advantage over...

    Read more

  • Consensys Blockchain Jobs Report

    What the current blockchain job market looks like

    Consensys published their blockchain jobs report which you can checkout in their Blockchain Developer Job Kit. The most interesting aspects are Blockchain developer jobs have been growing at a rate of 33x of the previous year according to LinkedIns jobs report Typical salary is about...

    Read more

  • Provable — Randomness Oracle

    How the Oraclize random number generator works

    One particularly interesting approach by Provable is the usage of a hardware security device, namely the Ledger Nano S. It uses a trusted execution environment to generate random numbers and provides a Provable Connector Contract as interface. How to use the Provable Randomness Oracle? Use the...

    Read more

  • Solidity Design Patterns: Multiply before Dividing

    Why the correct order matters!

    There has been a lot of progress since the beginning of Ethereum about best practices in Solidity. Unfortunately, I have the feeling that most of the knowledge is within the circle of experienced people and there aren’t that many online resources about it. That is why I would like to start this...

    Read more

  • Devcon 5 Applications closing in one week

    Devcon 5 Applications closing

    Watch out for the Devcon 5 applications. You only have one week left to apply either as Buidler Student Scholarship Press Devcon is by far the biggest and most impressive Ethereum conference in the world. And it's full of developers! I am especially excited about the cool location this year in...

    Read more

  • Randomness and the Blockchain

    How to achieve secure randomness for Solidity smart contracts?

    Update 2023 : Ethereum transitioned to Proof of Stake! If you are interested in the randomness there, you can now use the updated info over at https://soliditydeveloper.com/prevrandao. When we talk about randomness and blockchain, these are really two problems: How to generate randomness in smart...

    Read more

© 2024 Solidity Dev Studio. All rights reserved.

This website is powered by Scrivito, the next generation React CMS.