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?

Sending ETH, creating a contract and calling contract code are useful categories of activity, not the protocol’s transaction-type numbers. Ethereum also has typed transaction envelopes with different fee and other fields. For example, EIP-1559 transactions use maxFeePerGas and maxPriorityFeePerGas; RPC fields such as from can be derived from the signature.

A top-level contract-creation transaction has no destination address. Its data contains initcode, including encoded constructor arguments. Executing that initcode produces the deployed runtime code. A factory can instead create contracts within its own transaction.

A normal function call usually contains a four-byte selector followed by ABI-encoded arguments. Empty data sent to a contract can still invoke its receive or fallback logic, so an ETH transfer is not always free of contract execution.

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 one important part of the release process. You can use https://www.smartcontractaudits.com/ to find a suitable auditor.

Secondly consider the security of your private keys. Use separate test and production signing identities, and choose key custody appropriate to the authority at risk. Never reuse a test mnemonic for production. 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 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 a legacy hot-wallet example, not a recommendation to keep a production authority’s mnemonic in a project environment. 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.

javascript
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",
        settings: { optimizer: { enabled: true, runs: 200 } }
    },
  },
};
javascript
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.

changeOwnership is an example-specific method, not the OpenZeppelin Ownable API. Match the actual contract’s constructor and ownership-transfer methods, and verify any required acceptance by the intended owner.

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.

Historical Truffle dry runs can reveal failures for the simulated state, but do not guarantee that later transactions will succeed. State, fees, ordering and network conditions can change. Truffle and Ganache were sunset; the remaining comparison records the original tooling experience.

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

Hardhat now provides Hardhat Ignition for declarative, tracked deployments. Plain deployment scripts remain available. The snippet below is the original Hardhat 2 / ethers 5 example; current Hardhat 3 and ethers 6 use different connection and deployment APIs, documented in the script deployment guide.

Terminal / configuration
$ 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.

javascript
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().

This Web3.js example is historical; the project was sunset in 2025. The placeholder bytecode/address and gas limit must not be used as deployment values.

javascript
const myContract = new web3.eth.Contract(jsonABI)
myContract.deploy({
    data: '0x12345...', // bytecode
    arguments: [123, 'My String'] // constructor arguments
}).send({
    from: '0x1234567890123456789012345678901234567891',
    gas: 1500000,
    gasPrice: await web3.eth.getGasPrice() // legacy fee API; review before sending
}
);

e. Truffle Teams (Premium)

Truffle Teams was a hosted product described in the original article. Truffle was sunset, so the old pricing and dashboard instructions are not a current deployment recommendation.

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.

Source verification also depends on the exact compiler, settings, imports, linked libraries and relevant constructor data. A matching source build improves transparency; it is not an audit, a consensus requirement or proof that the deployed permissions are correct.