• Stars
    star
    173
  • Rank 220,196 (Top 5 %)
  • Language
    TypeScript
  • Created over 3 years ago
  • Updated over 2 years ago

Reviews

There are no reviews yet. Be the first to send feedback to the community and the maintainers!

Repository Details

Tutorial for hardhat + hardhat-deploy

Tutorial for hardhat-deploy based on https://hardhat.org/tutorial/

1. Setting up the environment

Most Ethereum libraries and tools are written in JavaScript, and so is Hardhat. If you're not familiar with Node.js, it's a JavaScript runtime built on Chrome's V8 JavaScript engine. It's the most popular solution to run JavaScript outside of a web browser and Hardhat is built on top of it.

Installing Node.js

You can skip this section if you already have a working Node.js >=12.0 installation. If not, here's how to install it on Ubuntu, MacOS and Windows.

Linux

Ubuntu

Copy and paste these commands in a terminal:

sudo apt update
sudo apt install curl git
curl -sL https://deb.nodesource.com/setup_12.x | sudo -E bash -
sudo apt install nodejs

MacOS

Make sure you have git installed. Otherwise, follow these instructions.

There are multiple ways of installing Node.js on MacOS. We will be using Node Version Manager (nvm).

Copy and paste these commands in a terminal:

curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.35.2/install.sh | bash
nvm install 12
nvm use 12
nvm alias default 12
npm install npm --global # Upgrade npm to the latest version

Windows

Installing Node.js on Windows requires a few manual steps. We'll install git, Node.js 12.x and npm.

Download and run these:

  1. Git's installer for Windows
  2. node-v12.XX.XX-x64.msi from here

Upgrading your Node.js installation

If your version of Node.js is older than 12.0 follow the instructions below to upgrade.

Linux

Ubuntu

  1. Run sudo apt remove nodejs in a terminal to remove Node.js.
  2. Find the version of Node.js that you want to install here and follow the instructions.
  3. Run sudo apt update && sudo apt install nodejs in a terminal to install Node.js again.

MacOS

You can change your Node.js version using nvm. To upgrade to Node.js 12.x run these in a terminal:

nvm install 12
nvm use 12
nvm alias default 12
npm install npm --global # Upgrade npm to the latest version

Windows

You need to follow the same installation instructions as before but choose a different version. You can check the list of all available versions here.

Installing yarn

For this tutorial we are going to use yarn

To install it do the following:

npm install -g yarn

2. Creating a new Hardhat project

We'll install Hardhat using the npm CLI. The Node.js package manager is a package manager and an online repository for JavaScript code.

Open a new terminal and run these commands:

mkdir hardhat-deploy-tutorial
cd hardhat-deploy-tutorial
yarn init --yes
yarn add -D hardhat

::: tip Installing Hardhat will install some Ethereum JavaScript dependencies, so be patient. :::

In the same directory where you installed Hardhat add a hardhat.config.ts (we are going to use typescript and the Solidity 0.7.6 compiler)

import {HardhatUserConfig} from 'hardhat/types';
const config: HardhatUserConfig = {
  solidity: {
    version: '0.7.6',
  }
};
export default config;

Hardhat's architecture

Hardhat is designed around the concepts of tasks and plugins. The bulk of Hardhat's functionality comes from plugins, which as a developer you're free to choose the ones you want to use.

Tasks

Every time you run Hardhat from the CLI you're running a task. e.g. npx hardhat compile is running the compile task. To see the currently available tasks in your project, run npx hardhat. Feel free to explore any task by running npx hardhat help [task].

::: tip You can create your own tasks. Check out the Creating a task guide. :::

Plugins

Hardhat is unopinionated in terms of what tools you end up using, but it does come with some built-in defaults, all of which can be overriden. Most of the time the way to use a given tool is by consuming a plugin that integrates it into Hardhat.

For this tutorial we are going to use the hardhat-deploy and hardhat-deploy-ethers plugins. They'll allow you to interact with Ethereum and to test your contracts. We'll explain how they're used later on. We also install ethers, chai, mocha and typescript and extra dependencies. To install them, run the following command in your project directory:

yarn add -D hardhat-deploy hardhat-deploy-ethers ethers chai chai-ethers mocha @types/chai @types/mocha @types/node typescript ts-node dotenv

Edit hardhat.config.ts so that it looks like this:

import {HardhatUserConfig} from 'hardhat/types';
import 'hardhat-deploy';
import 'hardhat-deploy-ethers';

const config: HardhatUserConfig = {
  solidity: {
    version: '0.7.6',
  },
  namedAccounts: {
    deployer: 0,
  },
};
export default config;

We also create the following tsconfig.json :

{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": true,
    "moduleResolution": "node",
    "forceConsistentCasingInFileNames": true,
    "outDir": "dist"
  },
  "include": [
    "hardhat.config.ts",
    "./deploy",
    "./test",
  ]
}

3. Writing and compiling smart contracts

We're going to create a simple smart contract that implements a token that can be transferred. Token contracts are most frequently used to exchange or store value. We won't go in depth into the Solidity code of the contract on this tutorial, but there's some logic we implemented that you should know:

  • There is a fixed total supply of tokens that can't be changed.
  • The entire supply is assigned to the address that deploys the contract.
  • Anyone can receive tokens.
  • Anyone with at least one token can transfer tokens.
  • The token is non-divisible. You can transfer 1, 2, 3 or 37 tokens but not 2.5.

::: tip You might have heard about ERC20, which is a token standard in Ethereum. Tokens such as DAI, USDC, MKR and ZRX follow the ERC20 standard which allows them all to be compatible with any software that can deal with ERC20 tokens. For simplicity's sake the token we're going to build is not an ERC20. :::

Writing smart contracts

While by default hardhat uses contracts as the source folder, we prefer to change it to src.

You then need to edit your hardhat.config.ts file with the new config:

import {HardhatUserConfig} from 'hardhat/types';
import 'hardhat-deploy';
import 'hardhat-deploy-ethers';

const config: HardhatUserConfig = {
  solidity: {
    version: '0.7.6',
  },
  namedAccounts: {
    deployer: 0,
  },
  paths: {
    sources: 'src',
  },
};
export default config;

Start by creating a new directory called src and create a file inside the directory called Token.sol.

Paste the code below into the file and take a minute to read the code. It's simple and it's full of comments explaining the basics of Solidity.

::: tip To get syntax highlighting you should add Solidity support to your text editor. Just look for Solidity or Ethereum plugins. We recommend using Visual Studio Code or Sublime Text 3. :::

// SPDX-License-Identifier: MIT
// The line above is recommended and let you define the license of your contract
// Solidity files have to start with this pragma.
// It will be used by the Solidity compiler to validate its version.
pragma solidity ^0.7.0;


// This is the main building block for smart contracts.
contract Token {
    // Some string type variables to identify the token.
    // The `public` modifier makes a variable readable from outside the contract.
    string public name = "My Hardhat Token";
    string public symbol = "MBT";

    // The fixed amount of tokens stored in an unsigned integer type variable.
    uint256 public totalSupply = 1000000;

    // An address type variable is used to store ethereum accounts.
    address public owner;

    // A mapping is a key/value map. Here we store each account balance.
    mapping(address => uint256) balances;

    /**
     * Contract initialization.
     *
     * The `constructor` is executed only once when the contract is created.
     */
    constructor(address _owner) {
        // The totalSupply is assigned to transaction sender, which is the account
        // that is deploying the contract.
        balances[_owner] = totalSupply;
        owner = _owner;
    }

    /**
     * A function to transfer tokens.
     *
     * The `external` modifier makes a function *only* callable from outside
     * the contract.
     */
    function transfer(address to, uint256 amount) external {
        // Check if the transaction sender has enough tokens.
        // If `require`'s first argument evaluates to `false` then the
        // transaction will revert.
        require(balances[msg.sender] >= amount, "Not enough tokens");

        // Transfer the amount.
        balances[msg.sender] -= amount;
        balances[to] += amount;
    }

    /**
     * Read only function to retrieve the token balance of a given account.
     *
     * The `view` modifier indicates that it doesn't modify the contract's
     * state, which allows us to call it without executing a transaction.
     */
    function balanceOf(address account) external view returns (uint256) {
        return balances[account];
    }
}

::: tip *.sol is used for Solidity files. We recommend matching the file name to the contract it contains, which is a common practice. :::

Compiling contracts

To compile the contract run yarn hardhat compile in your terminal. The compile task is one of the built-in tasks.

$ yarn hardhat compile
Compiling 1 file with 0.7.3
Compilation finished successfully

The contract has been successfully compiled and is ready to be used.

4. Deployment Scripts

Before you will be able to test or deploy your contract, you must set up the deployment process that can then be used both in testing as well as deployment to various live networks. This allow you to focus on what the contracts will be in their final form, setup their parameters and dependencies, and ensure your tests are running against the exact code that will be deployed.

This also removes the need to duplicate the deployment procedures. This is made possible thanks to the hardhat-deploy plugin.

Writing deployment scripts

Create a new directory called deploy in the project root, and in that directory create a new file called 001_deploy_token.ts.

Let's start with the code below. We'll explain it soon, but for now paste this code into 001_deploy_token.ts:

import {HardhatRuntimeEnvironment} from 'hardhat/types';
import {DeployFunction} from 'hardhat-deploy/types';

const func: DeployFunction = async function (hre: HardhatRuntimeEnvironment) {
  const {deployments, getNamedAccounts} = hre;
  const {deploy} = deployments;

  const {deployer, tokenOwner} = await getNamedAccounts();

  await deploy('Token', {
    from: deployer,
    args: [tokenOwner],
    log: true,
  });
};
export default func;
func.tags = ['Token'];

Notice the mention of getNamedAccounts?

The plugin hardhat-deploy allows you to name your accounts. Here there are 2 named accounts:

  • deployer will be the account used to deploy the contract.
  • tokenOwner which is passed to the constructor of Token.sol and which will receive the initial supply.

These accounts need to be setup in hardhat.config.ts

Modifiy it so it looks like this:

import {HardhatUserConfig} from 'hardhat/types';
import 'hardhat-deploy';
import 'hardhat-deploy-ethers';

const config: HardhatUserConfig = {
  solidity: {
    version: '0.7.6',
  },
  namedAccounts: {
    deployer: 0,
    tokenOwner: 1,
  },
  paths: {
    sources: 'src',
  },
};
export default config;

deployer was already there and is setup to use the first account (index = 0).

tokenOwner is the second account.

Note that instead of index you can use hard-coded addresses or even references other named accounts. You can also have different addresses based on each network. See hardhat-deploy documentation here

In your terminal, run yarn hardhat deploy. You should see the following output:

Nothing to compile
deploying "Token" (tx: 0x259d19f33819ec8d3bd994f82912aec6af1a18ec5d74303cfb28d793a10ff683)...: deployed at 0x5FbDB2315678afecb367f032d93F642f64180aa3 with 592983 gas
Done in 3.66s.

Your contract was deployed to the in-memory Hardhat network and the output indicates that deployment was successful.

We can now write tests against this contract.

First we will add comments to the deploy script above to explain each line that matters:

import {HardhatRuntimeEnvironment} from 'hardhat/types'; // This adds the type from hardhat runtime environment.
import {DeployFunction} from 'hardhat-deploy/types'; // This adds the type that a deploy function is expected to fulfill.

const func: DeployFunction = async function (hre: HardhatRuntimeEnvironment) { // the deploy function receives the hardhat runtime env as an argument
  const {deployments, getNamedAccounts} = hre; // we get the deployments and getNamedAccounts which are provided by hardhat-deploy.
  const {deploy} = deployments; // The deployments field itself contains the deploy function.

  const {deployer, tokenOwner} = await getNamedAccounts(); // Fetch the accounts. These can be configured in hardhat.config.ts as explained above.

  await deploy('Token', { // This will create a deployment called 'Token'. By default it will look for an artifact with the same name. The 'contract' option allows you to use a different artifact.
    from: deployer, // Deployer will be performing the deployment transaction.
    args: [tokenOwner], // tokenOwner is the address used as the first argument to the Token contract's constructor.
    log: true, // Display the address and gas used in the console (not when run in test though).
  });
};
export default func;
func.tags = ['Token']; // This sets up a tag so you can execute the script on its own (and its dependencies).

Not as mentioned in the comment, the name of the deployed contract is set to be the same name as the contract name: Token. You can deploy different version of it by simply using a different name for it, like so:

await deploy('MyToken_1', { // name of the deployed contract
  contract: 'Token', // name of the token source
  from: deployer,
  args: [tokenOwner],
  log: true,
});

5. Testing contracts

Writing automated tests when building smart contracts is of crucial importance, as your user's money is what's at stake. For this we're going to use Hardhat Network, a local Ethereum network designed for development that is built-in and acts as the default network in Hardhat. You don't need to set anything up to use it. In our tests we're going to use ethers.js to interact with the Ethereum contract we built in the previous section, and Mocha will be our test runner.

Writing tests

Create a new directory called test in the project root directory and in that test directory, create a new file called Test.test.ts.

Let's start with the code below. We'll explain it shortly, but for now just paste the following code into Test.test.ts:

import {expect} from "./chai-setup";

import {ethers, deployments, getNamedAccounts} from 'hardhat';

describe("Token contract", function() {
  it("Deployment should assign the total supply of tokens to the owner", async function() {
    await deployments.fixture(["Token"]);
    const {tokenOwner} = await getNamedAccounts();
    const Token = await ethers.getContract("Token");
    const ownerBalance = await Token.balanceOf(tokenOwner);
    const supply = await Token.totalSupply();
    expect(ownerBalance).to.equal(supply);
  });
});

We also create a new file called chai-setup.ts in the test folder:

import chaiModule from 'chai';
import {chaiEthers} from 'chai-ethers';
chaiModule.use(chaiEthers);
export = chaiModule;

This will use chai matchers from chai-ethers but also allows you to easily add more.

Then in your terminal run npx hardhat test. You should see the following output:

$ npx hardhat test

  Token contract
    βœ“ Deployment should assign the total supply of tokens to the owner (654ms)


  1 passing (663ms)

This means the test passed sucessfully. Now Let's examine each line.

await deployments.fixture(["Token"]);

Remember the deploy script we wrote earlier? This line allow to execute it prior to the test. It also generates an evm_snapshot automatically so if you write many tests, and they all refer to that fixture, the deployment will not be reexecuted. Indeed, behind the scene it does not redeploy it again and again, instead it automatically reverts to a previous state, speeding up your tests significantly!

const {tokenOwner} = await getNamedAccounts();

This gives you access to the tokenOwner address, the same address that was used in the deploy script.

const Token = await ethers.getContract("Token");

Since we already ran the deploy script, we can easily access the deployed contract by name. This is what this line does, and thanks to hardhat-deploy-ethers plugin, you get an ethers contract ready to be invoked. If you needed that contract to be associated to a specific signer, you can pass the address as the extra argument like const TokenAsOwner = await ethers.getContract('Token', tokenOwner);

const ownerBalance = await Token.balanceOf(tokenOwner);

Now we can call contract methods on Token. To get the balance of the owner account, we can call balanceOf().

const supply = await Token.totalSupply();

Here we will again use our Contract instance to call a smart contract function. totalSupply() returns the token's supply amount.

expect(ownerBalance).to.equal(supply);

Finally we're checking that it's equal to ownerBalance, which it should be.

To do this we're using Chai which is an assertions library. These assertion functions are called "matchers", and the ones we're using here actually come from chai-ethers npm package (which itself is a fork of Waffle chai matchers without unecessary dependencies).

Using a different account

While testing your code, you may need to send a transaction from an account other than the default one. To do this you can use the second argument to getContract :

import {expect} from "./chai-setup";

import {ethers, deployments, getNamedAccounts, getUnnamedAccounts} from 'hardhat';

describe("Token contract", function() {
  it("Deployment should assign the total supply of tokens to the owner", async function() {
    await deployments.fixture(["Token"]);
    const {tokenOwner} = await getNamedAccounts();
    const users = await getUnnamedAccounts();
    const TokenAsOwner = await ethers.getContract("Token", tokenOwner);
    await TokenAsOwner.transfer(users[0], 50);
    expect(await TokenAsOwner.balanceOf(users[0])).to.equal(50);

    const TokenAsUser0 = await ethers.getContract("Token", users[0]);
    await TokenAsUser0.transfer(users[1], 50);
    expect(await TokenAsOwner.balanceOf(users[1])).to.equal(50);
  });
});

Full coverage

Now that we've covered the basics you'll need for testing your contracts, here's a full test suite for the token with a lot of additional information about Mocha and how to structure your tests. We recommend reading through.

But first we add some utility functions that we will use in the test suite.

Create a folder called utils in the test folder and inside it, create a file called index.ts with the following content:

import {Contract} from 'ethers';
import {ethers} from 'hardhat';

export async function setupUsers<T extends {[contractName: string]: Contract}>(
  addresses: string[],
  contracts: T
): Promise<({address: string} & T)[]> {
  const users: ({address: string} & T)[] = [];
  for (const address of addresses) {
    users.push(await setupUser(address, contracts));
  }
  return users;
}

export async function setupUser<T extends {[contractName: string]: Contract}>(
  address: string,
  contracts: T
): Promise<{address: string} & T> {
  // eslint-disable-next-line @typescript-eslint/no-explicit-any
  const user: any = {address};
  for (const key of Object.keys(contracts)) {
    user[key] = contracts[key].connect(await ethers.getSigner(address));
  }
  return user as {address: string} & T;
}

This approach will allow you to have succinct and easy to read tests as you can see from the following example.

Here is the test suite. Overwrite Test.test.ts with the following content:

// We import Chai to use its assertion functions here.
import {expect} from "./chai-setup";

// we import our utilities
import {setupUsers, setupUser} from './utils';

// We import the hardhat environment field we are planning to use
import {ethers, deployments, getNamedAccounts, getUnnamedAccounts} from 'hardhat';

// we create a setup function that can be called by every test and setup variable for easy to read tests
async function setup () {
  // it first ensures the deployment is executed and reset (use of evm_snapshot for faster tests)
  await deployments.fixture(["Token"]);

  // we get an instantiated contract in the form of a ethers.js Contract instance:
  const contracts = {
    Token: (await ethers.getContract('Token')),
  };

  // we get the tokenOwner
  const {tokenOwner} = await getNamedAccounts();

  // Get the unnammedAccounts (which are basically all accounts not named in the config,
  // This is useful for tests as you can be sure they have noy been given tokens for example)
  // We then use the utilities function to generate user objects
  // These object allow you to write things like `users[0].Token.transfer(....)`
  const users = await setupUsers(await getUnnamedAccounts(), contracts);
  // finally we return the whole object (including the tokenOwner setup as a User object)
  return {
    ...contracts,
    users,
    tokenOwner: await setupUser(tokenOwner, contracts),
  };
}

// `describe` is a Mocha function that allows you to organize your tests. It's
// not actually needed, but having your tests organized makes debugging them
// easier. All Mocha functions are available in the global scope.

// `describe` receives the name of a section of your test suite, and a callback.
// The callback must define the tests of that section. This callback can't be
// an async function.
describe("Token contract", function() {

  // You can nest describe calls to create subsections.
  describe("Deployment", function () {
    // `it` is another Mocha function. This is the one you use to define your
    // tests. It receives the test name, and a callback function.

    // If the callback function is async, Mocha will `await` it.
    it("Should set the right owner", async function () {
      // Expect receives a value, and wraps it in an Assertion object. These
      // objects have a lot of utility methods to assert values.

      // before the test, we call the fixture function.
      // while mocha have hooks to perform these automatically, they force you to declare the variable in greater scope which can introduce subttle errors
      // as such we prefers to have the setup called right at the beginning of the test. this also allow yout o name it accordingly for easier to read tests.
      const {Token} = await setup();


      // This test expects the owner variable stored in the contract to be equal to our configured owner
      const {tokenOwner} = await getNamedAccounts();
      expect(await Token.owner()).to.equal(tokenOwner);
    });

    it("Should assign the total supply of tokens to the owner", async function () {
      const {Token, tokenOwner} = await setup();
      const ownerBalance = await Token.balanceOf(tokenOwner.address);
      expect(await Token.totalSupply()).to.equal(ownerBalance);
    });
  });

  describe("Transactions", function () {
    it("Should transfer tokens between accounts", async function () {
      const {Token, users, tokenOwner} = await setup();
      // Transfer 50 tokens from owner to users[0]
      await tokenOwner.Token.transfer(users[0].address, 50);
      const users0Balance = await Token.balanceOf(users[0].address);
      expect(users0Balance).to.equal(50);

      // Transfer 50 tokens from users[0] to users[1]
      // We use .connect(signer) to send a transaction from another account
      await users[0].Token.transfer(users[1].address, 50);
      const users1Balance = await Token.balanceOf(users[1].address);
      expect(users1Balance).to.equal(50);
    });

    it("Should fail if sender doesn’t have enough tokens", async function () {
      const {Token, users, tokenOwner} = await setup();
      const initialOwnerBalance = await Token.balanceOf(tokenOwner.address);

      // Try to send 1 token from users[0] (0 tokens) to owner (1000 tokens).
      // `require` will evaluate false and revert the transaction.
      await expect(users[0].Token.transfer(tokenOwner.address, 1)
      ).to.be.revertedWith("Not enough tokens");

      // Owner balance shouldn't have changed.
      expect(await Token.balanceOf(tokenOwner.address)).to.equal(
        initialOwnerBalance
      );
    });

    it("Should update balances after transfers", async function () {
      const {Token, users, tokenOwner} = await setup();
      const initialOwnerBalance = await Token.balanceOf(tokenOwner.address);

      // Transfer 100 tokens from owner to users[0].
      await tokenOwner.Token.transfer(users[0].address, 100);

      // Transfer another 50 tokens from owner to users[1].
      await tokenOwner.Token.transfer(users[1].address, 50);

      // Check balances.
      const finalOwnerBalance = await Token.balanceOf(tokenOwner.address);
      expect(finalOwnerBalance).to.equal(initialOwnerBalance - 150);

      const users0Balance = await Token.balanceOf(users[0].address);
      expect(users0Balance).to.equal(100);

      const users1Balance = await Token.balanceOf(users[1].address);
      expect(users1Balance).to.equal(50);
    });
  });
});

This is what the output of yarn hardhat test should look like after running the full test suite:

$ yarn hardhat test

  Token contract
    Deployment
      βœ“ Should set the right owner
      βœ“ Should assign the total supply of tokens to the owner
    Transactions
      βœ“ Should transfer tokens between accounts (199ms)
      βœ“ Should fail if sender doesn’t have enough tokens
      βœ“ Should update balances after transfers (111ms)


  5 passing (1s)

Keep in mind that when you run yarn hardhat test, your contracts will be compiled if they've changed since the last time you ran your tests.

6. Debugging with Hardhat Network

Hardhat comes built-in with Hardhat Network, a local Ethereum network designed for development. It allows you to deploy your contracts, run your tests, and debug your code. It's the default network Hardhat connects to, so you don't need to set anything up for it to work, you just run your tests.

Solidity console.log

When running your contracts and tests on Hardhat Network you can print logging messages and contract variables calling console.log() from your Solidity code. To use it you have to import Hardhat'sconsole.log in your contract code.

This is what it looks like:

pragma solidity 0.7.6;

import "hardhat/console.sol";

contract Token {
  //...
}

Try adding some console.log statments to the transfer() function as if you were using it in JavaScript:

function transfer(address to, uint256 amount) external {
  console.log("Sender balance is %s tokens", balances[msg.sender]);
  console.log("Trying to send %s tokens to %s", amount, to);

  require(balances[msg.sender] >= amount, "Not enough tokens");

  balances[msg.sender] -= amount;
  balances[to] += amount;
}

The logging output will show when you run your tests:

$ yarn hardhat test

  Token contract
    Deployment
      βœ“ Should set the right owner
      βœ“ Should assign the total supply of tokens to the owner
    Transactions
Sender balance is 1000 tokens
Trying to send 50 tokens to 0xead9c93b79ae7c1591b1fb5323bd777e86e150d4
Sender balance is 50 tokens
Trying to send 50 tokens to 0xe5904695748fe4a84b40b3fc79de2277660bd1d3
      βœ“ Should transfer tokens between accounts (373ms)
      βœ“ Should fail if sender doesn’t have enough tokens
Sender balance is 1000 tokens
Trying to send 100 tokens to 0xead9c93b79ae7c1591b1fb5323bd777e86e150d4
Sender balance is 900 tokens
Trying to send 100 tokens to 0xe5904695748fe4a84b40b3fc79de2277660bd1d3
      βœ“ Should update balances after transfers (187ms)


  5 passing (2s)

Check out the documentation to learn more about this feature.

7. Deploying to a live network

Once you're ready to share your app with other people, you may want to deploy it to a live network! This way others can access an instance that's not running locally on your system.

The Ethereum network that deals with real money is called "mainnet", and then there are other live networks that don't deal with real money but do mimic the real world scenario well, and can be used by others as a shared staging environment. These are called "testnets" and Ethereum has several of them: Ropsten, Kovan, Rinkeby and Goerli.

At the software level, deploying to a testnet is the same as deploying to mainnet. The only difference is which network you connect to.

Since we use hardhat-deploy plugin and we already set up our deployment procedures for the tests, we are ready to deploy to a live network, we just need to add some configuration for the network we intend to deploy to.

As explained in our deployment section you can execute yarn hardhat deploy which will give you the following output, but does not actually deploy your contract anywhere except the default "in-memory" network (hardhat)

Nothing to compile
deploying "Token" (tx: 0x259d19f33819ec8d3bd994f82912aec6af1a18ec5d74303cfb28d793a10ff683)...: deployed at 0x5FbDB2315678afecb367f032d93F642f64180aa3 with 592983 gas
Done in 3.79s.

To deploy to a specific network, you need to add --network <network-name> like this:

yarn hardhat --network <network-name> deploy

Deploying to remote networks

To deploy to a remote network such as mainnet or any testnet, you need to add a network entry to your hardhat.config.js file. We’ll use Rinkeby for this example, but you can add any network.

To make it easier to handle the private keys and network configuration, we create a new folder at the root of your project utils

In it we create a file network.ts with the following content:

import 'dotenv/config';
export function node_url(networkName: string): string {
  if (networkName) {
    const uri = process.env['ETH_NODE_URI_' + networkName.toUpperCase()];
    if (uri && uri !== '') {
      return uri;
    }
  }

  let uri = process.env.ETH_NODE_URI;
  if (uri) {
    uri = uri.replace('{{networkName}}', networkName);
  }
  if (!uri || uri === '') {
    if (networkName === 'localhost') {
      return 'http://localhost:8545';
    }
    return '';
  }
  if (uri.indexOf('{{') >= 0) {
    throw new Error(
      `invalid uri or network not supported by node provider : ${uri}`
    );
  }
  return uri;
}

export function getMnemonic(networkName?: string): string {
  if (networkName) {
    const mnemonic = process.env['MNEMONIC_' + networkName.toUpperCase()];
    if (mnemonic && mnemonic !== '') {
      return mnemonic;
    }
  }

  const mnemonic = process.env.MNEMONIC;
  if (!mnemonic || mnemonic === '') {
    return 'test test test test test test test test test test test junk';
  }
  return mnemonic;
}

export function accounts(networkName?: string): {mnemonic: string} {
  return {mnemonic: getMnemonic(networkName)};
}

Then we can modifiy our hardhat.config.ts file to contain the following:

import {HardhatUserConfig} from 'hardhat/types';
import 'hardhat-deploy';
import 'hardhat-deploy-ethers';
import {node_url, accounts} from './utils/network';

const config: HardhatUserConfig = {
  solidity: {
    version: '0.7.6',
  },
  networks: {
    rinkeby: {
      url: node_url('rinkeby'),
      accounts: accounts('rinkeby'),
    },
  },
  namedAccounts: {
    deployer: 0,
    tokenOwner: 1,
  },
  paths: {
    sources: 'src',
  },
};
export default config;

Finally we need to setup the environment variable that utils/networks.ts reads automatically from .env

create a .env with the following content. This is where you write your own alchemy api key and mnemonic for rinkeby

ETH_NODE_URI_RINKEBY=https://eth-rinkeby.alchemyapi.io/v2/<alchmey api key>
MNEMONIC_RINKEBY=<mnemonic for rinkeby>

We're using Alchemy, but pointing url to any Ethereum node or gateway would work. Go grab your api key and come back.

To deploy on Rinkeby you need to send rinkeby-ETH into the address that's going to be making the deployment. You can get some ETH for testnets from a faucet, a service that distributes testing ETH for free. Here's the one for Rinkeby. You'll have to change Metamask's network to Rinkeby before transacting.

::: tip You can get some ETH for other testnets following these links:

Finally, run:

yarn hardhat --network rinkeby deploy

If everything went well, you should see something like:

Nothing to compile
deploying "Token" (tx: 0xb40879c3162e6a924cfadfc1027c4629dd57ee4ba08a5f8af575be1c751cd515)...: deployed at 0x8bDFEf5f67685725BC0eD9f54f20A2A4d3FEDA98 with 475842 gas

You will also see that some files have been created in the deployments/rinkeby folder.

Most notably you'll see deployments/rinkeby/Token.json which contains useful information about your deployed contract, including the address, abi, and the solidity input used to create it.

You can then verify it using sourcify or etherscan.

For sourcify you can execute the following:

yarn hardhat --network rinkeby sourcify

this should give you the following output (with different address) :

verifying Token (0x8bDFEf5f67685725BC0eD9f54f20A2A4d3FEDA98 on chain 4) ...
 => contract Token is now verified

For etherscan you can do the following:

(Note you can also specify the api key via the env variable ETHERSCAN_API_KEY)

yarn hardhat --network rinkeby etherscan-verify --api-key <api-key>

You should then see:

verifying Token (0x8bDFEf5f67685725BC0eD9f54f20A2A4d3FEDA98) ...
waiting for result...
 => contract Token is now verified

More Repositories

1

hardhat-deploy

hardhat deployment plugin
TypeScript
1,043
star
2

template-ethereum-contracts

Template to develop ethereum smart contracts
TypeScript
430
star
3

clones-with-immutable-args

Solidity
193
star
4

jolly-roger

Build and Deploy for Eternity. Jolly Roger is a production-ready template for decentralised applications.
TypeScript
192
star
5

forge-deploy

Rust
113
star
6

eip721-subgraph

JavaScript
78
star
7

hardhat-deploy-ethers

TypeScript
64
star
8

forge-exec

Execute programs from forge with an open 2-way communication channel between both
Solidity
56
star
9

openfl-stage3d

Stage3D API for openfl
Haxe
52
star
10

bleeps

Bleeps, The First Truly onchain sounds
TypeScript
25
star
11

mandalas

TypeScript
24
star
12

hardhat-preprocessor

An hardhat plugin to pre-process contract source code before compilation
TypeScript
24
star
13

stratagems

Stratagems is an Autonomous World where players are actual gods. They are literaly the one creating the world.
TypeScript
23
star
14

sveltejs-adapter-ipfs

JavaScript
21
star
15

rocketh

A tool to test and deploy ethereum smart contract
TypeScript
17
star
16

singleton-1776-meta-transaction

A Singleton MetaTx Processor using EIP-1776 that support all ERC20 tokens
JavaScript
17
star
17

erc721-lease

A contract to manage lease of NFT
Solidity
16
star
18

spriter

Spriter runtime for Haxe with 0 allocation for hxcpp
Haxe
15
star
19

khage

KHAGE stands for KHA Graphical Extension. It is a set of class/macro to make use of graphics in a sane and safe way
Haxe
15
star
20

web3w

TypeScript
14
star
21

hardhat-deploy-tenderly

plugin for hardhat that push hardhat-deploy's deployments to tenderly
TypeScript
14
star
22

embed-art

Embed your NFT art anywhere, generate preview for oldschool platforms
TypeScript
14
star
23

gcusage

haxe lib to gather gc usage via code. Also serve as live doc on how haxe/hxcpp deal with allocation for various types
Haxe
14
star
24

hxcpp-test

C++
11
star
25

transfer-gateway

Solidity
11
star
26

hardhat-deploy-test-uniswap

Solidity
10
star
27

blockies-nft

TypeScript
10
star
28

antarctica

TypeScript
10
star
29

hardhat-deploy-ts-test

A test of buidler + buidler-deploy using typescript
TypeScript
9
star
30

stage3d-glsl

Lib to deal with glsl on top of flash stage3d api
Haxe
9
star
31

spriterkha

kha renderer for spriter runtime
Haxe
9
star
32

solidity-kit

Solidity
8
star
33

fuzd

time-lock encrypted commit + reveal system using drand
TypeScript
8
star
34

loot-for-everyone

TypeScript
7
star
35

kit

A set of lib and tools to make cross platform games
Haxe
7
star
36

vending-machine

simple-nft-sale
TypeScript
7
star
37

hardhat-deploy-test-diamond

TypeScript
7
star
38

conquest-eth-player-handbook

Conquest's Player's Handbook, Everything a player needs to know to play conquest.eth
7
star
39

universal-forwarder

The only meta transaction forwarder you need
Solidity
7
star
40

the-bleep-machine

Onchain algorithmic Music
JavaScript
6
star
41

template-on-chain-art

TypeScript
6
star
42

template-foundry

A basic template that uses foundry-rs/forge and forge-deploy to deploy and test ethereum smart contracts
Solidity
6
star
43

vitest-solidity-coverage

TypeScript
6
star
44

docker-compose-blockchain-setup

A docker-compose setup for local blockchain with blockscout
JavaScript
6
star
45

Yoga

Yoga aims to be a tool like maven for Haxe with at first the functionality of dependency management and project setup.
Haxe
5
star
46

cosmos

A Type safe Entity Component System with minimum overhead + optional Types
Haxe
5
star
47

mystery-box

CSS
5
star
48

yakuza-revenge

Solidity
5
star
49

viem-chai-matchers

TypeScript
5
star
50

hardhat-deploy-ethers-old

buidler plugin for ethers v5
TypeScript
5
star
51

bomber-woman

TypeScript
4
star
52

eip-2585

EIP-2585 Minimal Native Meta transaction Forwarder
JavaScript
4
star
53

fungible-bonding-curve

fungible-bonding-curve
Solidity
4
star
54

svelte-wallet

JavaScript
4
star
55

catacombs

TypeScript
4
star
56

missiv

TypeScript
3
star
57

multi-165

Solidity
3
star
58

mixingloom-profiler

A profiler injected at runtime through MixingLoom and as3commons bytecode
ActionScript
3
star
59

duel-in-the-dark

TypeScript
3
star
60

ethereum_gas

Solidity
3
star
61

redstone-composability-hackathon

Solidity
3
star
62

gsn-playground

JavaScript
3
star
63

OpenFLStage3DTest

A test app for openfl stage3d
Haxe
3
star
64

hardhat-vitest-demo

hardhat + vitest
TypeScript
3
star
65

wighawag-game-utils

Game library code that is here temporarely waiting for a better place
Haxe
3
star
66

ethereum-lan-node

A node for LAN network
JavaScript
3
star
67

conquest-website

Svelte
3
star
68

vitalik-secret

A world scale puzzle
Solidity
2
star
69

template-hardhat-plugin

TypeScript
2
star
70

forge-deploy-proxy

Solidity
2
star
71

web3-html-provider

A provider that use an html iframe / popup to allow user to authorize transaction without having to enable CORS on ethereum nodes
HTML
2
star
72

js13k-on-chain

HTML
2
star
73

web3w-walletconnect-v2-loader

wallet connect v2 module for web3w
TypeScript
2
star
74

the_eternal_dungeon

JavaScript
2
star
75

imagesheet

spritesheet lib for kha
Haxe
2
star
76

glsl2agal-lib

simple wrapper to glsl2agal project to generatre a swf usable by NME for converting glsl to agal at runtime
ActionScript
2
star
77

conquest-basic-spaceship-market

TypeScript
2
star
78

ethereum-contracts-test-suite

A suite of test for your smart contracts
TypeScript
2
star
79

VirtualThread

Green Thread implementation in actionscript
ActionScript
2
star
80

javelin

A Tool to manage your haxelib library (update,test,build,install,deploy) using haxelib.json (a superset)
Haxe
2
star
81

template-ethereum-contracts-test

Solidity
2
star
82

spriter_test

test project for spriter runtime and kha renderer
Haxe
2
star
83

contract-tester

Solidity
2
star
84

bleeps-code

repo for the Bleeps
2
star
85

use-stores

React Hooks for Observable / Svelte Stores
TypeScript
2
star
86

ethereum-indexer

ethereum-indexer
TypeScript
2
star
87

chai-ethers

Chai Matchers for ethers type (copied from @ethereum-waffle/chai but without dependencies on ganache-core, etc...)
TypeScript
2
star
88

event-processor-eip721

TypeScript
1
star
89

forge-exec-ipc-server-js

forge-exec-ipc-server-js
TypeScript
1
star
90

ethereum-indexer-snapshots

1
star
91

web3-connection-viem

TypeScript
1
star
92

files

1
star
93

sratagems-wars

A game built on top of Stratagems
TypeScript
1
star
94

yooloot

JavaScript
1
star
95

jolly-roger-web

TypeScript
1
star
96

foam-svelte-kit

JavaScript
1
star
97

sveltore

svelte store package (copied from svelte)
TypeScript
1
star
98

wighawag-view

Entity Views used for game
Haxe
1
star
99

lootxp

Loot XP
TypeScript
1
star
100

hardhat-deploy-doc

1
star