# Moonbeam Developer Documentation (LLMS Format)

This file contains documentation for Moonbeam (https://moonbeam.network/). Moonbeam is a smart contract platform that makes it easy to build natively interoperable applications on Polkadot and Ethereum.
It is intended for use with large language models (LLMs) to support developers working with Moonbeam. The content includes selected pages from the official docs, organized by section.

This file includes documentation related to the product: Tutorials

## AI Prompt Template

You are an AI developer assistant for Moonbeam (https://moonbeam.network/). Your task is to assist developers in understanding and using the product described in this file.
- Provide accurate answers based on the included documentation.
- Do not assume undocumented features, behaviors, or APIs.
- If unsure, respond with “Not specified in the documentation.

## List of doc pages:
Doc-Page: https://raw.githubusercontent.com/moonbeam-foundation/moonbeam-docs/refs/heads/master/tutorials/eth-api/batch-approve-swap.md [type: tutorials]
Doc-Page: https://raw.githubusercontent.com/moonbeam-foundation/moonbeam-docs/refs/heads/master/tutorials/eth-api/call-permit-gasless-txs.md [type: tutorials]
Doc-Page: https://raw.githubusercontent.com/moonbeam-foundation/moonbeam-docs/refs/heads/master/tutorials/eth-api/chat-gpt.md [type: tutorials]
Doc-Page: https://raw.githubusercontent.com/moonbeam-foundation/moonbeam-docs/refs/heads/master/tutorials/eth-api/foundry-start-to-end.md [type: tutorials]
Doc-Page: https://raw.githubusercontent.com/moonbeam-foundation/moonbeam-docs/refs/heads/master/tutorials/eth-api/hardhat-start-to-end.md [type: tutorials]
Doc-Page: https://raw.githubusercontent.com/moonbeam-foundation/moonbeam-docs/refs/heads/master/tutorials/eth-api/how-to-build-a-dapp.md [type: tutorials]
Doc-Page: https://raw.githubusercontent.com/moonbeam-foundation/moonbeam-docs/refs/heads/master/tutorials/eth-api/randomness-lottery.md [type: tutorials]
Doc-Page: https://raw.githubusercontent.com/moonbeam-foundation/moonbeam-docs/refs/heads/master/tutorials/eth-api/thirdweb.md [type: tutorials]
Doc-Page: https://raw.githubusercontent.com/moonbeam-foundation/moonbeam-docs/refs/heads/master/tutorials/eth-api/using-tenderly.md [type: tutorials]
Doc-Page: https://raw.githubusercontent.com/moonbeam-foundation/moonbeam-docs/refs/heads/master/tutorials/integrations/0xgasless.md [type: tutorials]
Doc-Page: https://raw.githubusercontent.com/moonbeam-foundation/moonbeam-docs/refs/heads/master/tutorials/integrations/local-subsquid.md [type: tutorials]
Doc-Page: https://raw.githubusercontent.com/moonbeam-foundation/moonbeam-docs/refs/heads/master/tutorials/integrations/nft-subsquid.md [type: tutorials]
Doc-Page: https://raw.githubusercontent.com/moonbeam-foundation/moonbeam-docs/refs/heads/master/tutorials/integrations/supra.md [type: tutorials]
Doc-Page: https://raw.githubusercontent.com/moonbeam-foundation/moonbeam-docs/refs/heads/master/tutorials/interoperability/cross-chain-dao.md [type: tutorials]
Doc-Page: https://raw.githubusercontent.com/moonbeam-foundation/moonbeam-docs/refs/heads/master/tutorials/interoperability/remote-batched-evm-calls.md [type: tutorials]
Doc-Page: https://raw.githubusercontent.com/moonbeam-foundation/moonbeam-docs/refs/heads/master/tutorials/interoperability/remote-staking-xcm.md [type: tutorials]
Doc-Page: https://raw.githubusercontent.com/moonbeam-foundation/moonbeam-docs/refs/heads/master/tutorials/interoperability/uniswapv2-swap-xcm.md [type: tutorials]
Doc-Page: https://raw.githubusercontent.com/moonbeam-foundation/moonbeam-docs/refs/heads/master/tutorials/interoperability/using-axelar-sdk.md [type: tutorials]

## Full content for each doc page

Doc-Content: https://docs.moonbeam.network/tutorials/eth-api/batch-approve-swap/
--- BEGIN CONTENT ---
---
title: Approve & Swap with the Batch Precompile
description: Learn how to use the Batch Precompile on Moonbeam to batch an approval and swap into a single call, so you can approve the exact amount of tokens for the swap.
categories: Tutorials, Precompiles
---

# Use the Batch Precompile to Approve and Swap Tokens in a Single Transaction

_by Erin Shaben_

## Introduction {: #introduction }

Token approvals are critical for interacting with smart contracts securely, preventing smart contracts without permission from accessing a user's tokens. When a smart contract is given approval to access a user's tokens, the amount of tokens it has access to is often an unlimited amount, depending on the DApp.

One of the reasons why many DApps use an unlimited amount is so that users don't need to continue to sign approval transactions every time they want to move their tokens. This is in addition to the second transaction required to actually swap the tokens. For networks like Ethereum, this can be expensive. However, if the approved smart contract has a vulnerability, it could be exploited and the users' tokens could be transferred at any time without requiring further approval. In addition, if a user no longer wants the DApp's contract to have access to their tokens, they have to revoke the token approval, which requires another transaction to be sent.

As a DApp developer on Moonbeam, you can avoid this process entirely, providing users with more control over their assets. This can be done using the [batch precompile](/builders/ethereum/precompiles/ux/batch/){target=\_blank} to batch an approval and swap into a single transaction, instead of the typical two transaction process. This allows for the approval amount to be the exact swap amount instead of having unlimited access to your users' tokens.

In this tutorial, we'll dive into the process of batching an approval and swap into one transaction using the `batchAll` function of the batch precompile contract. We'll create and deploy an ERC-20 contract and a simple DEX contract for the swap on the [Moonbase Alpha TestNet](/builders/get-started/networks/moonbase/){target=\_blank} using [Hardhat](/builders/ethereum/dev-env/hardhat/){target=\_blank} and [Ethers](/builders/ethereum/libraries/ethersjs/){target=\_blank}.

## Checking Prerequisites {: #checking-prerequisites }

For this tutorial, you'll need the following:

- An account with funds.
  You can get DEV tokens for testing on Moonbase Alpha once every 24 hours from the [Moonbase Alpha Faucet](https://faucet.moonbeam.network){target=\_blank}
- An empty Hardhat project that is configured for the Moonbase Alpha TestNet. For step-by-step instructions, please refer to the [Creating a Hardhat Project](/builders/ethereum/dev-env/hardhat/#creating-a-hardhat-project){target=\_blank} and the [Hardhat Configuration File](/builders/ethereum/dev-env/hardhat/#hardhat-configuration-file){target=\_blank} sections of our Hardhat documentation page
- 
  To test out the examples in this guide on Moonbeam or Moonriver, you will need to have your own endpoint and API key, which you can get from one of the supported [Endpoint Providers](/builders/get-started/endpoints/){target=\_blank}

### Install Dependencies {: #install-dependencies }

Once you have your [Hardhat project](/builders/ethereum/dev-env/hardhat/){target=\_blank}, you can install the [Ethers plugin](https://hardhat.org/hardhat-runner/plugins/nomicfoundation-hardhat-ethers){target=\_blank}. This provides a convenient way to use the [Ethers.js](/builders/ethereum/libraries/ethersjs/){target=\_blank} library to interact with the network.

You can also install the [OpenZeppelin contracts library](https://docs.openzeppelin.com/contracts){target=\_blank}, as we'll be importing the `ERC20.sol` contract and `IERC20.sol` interface in our contracts.

To install the necessary dependencies, run the following command:

```bash
npm install @nomicfoundation/hardhat-ethers ethers@6 @openzeppelin/contracts
```

## Contract Setup {: #contracts }

The following are the contracts that we'll be working with today:

- `Batch.sol` - one of the precompile contracts on Moonbeam that allows you to combine multiple EVM calls into one. For more information on the available methods, please refer to the [Batch Solidity Interface](/builders/ethereum/precompiles/ux/batch/#the-batch-interface){target=\_blank} documentation

- `DemoToken.sol` - an ERC-20 contract for the `DemoToken` (DTOK) token, which on deployment mints an initial supply and assigns them to the contract owner. It's a standard ERC-20 token, you can review the [IERC20 interface](https://docs.openzeppelin.com/contracts/2.x/api/token/erc20#IERC20){target=\_blank} for more information on the available methods

- `SimpleDex.sol` - a simple example of a DEX that on deployment deploys the `DemoToken` contract, which mints 1000 DTOKs, and allows you to swap DEV token for DTOKs and vice versa. **This contract is for demo purposes only**. The `SimpleDex` contract contains the following methods:
    - **token**() - a read-only method that returns the address of the `DemoToken` contract
    - **swapDevForDemoToken**() - a payable function that accepts DEV tokens in exchange for DTOK tokens. The function checks to make sure there are enough DTOK tokens held in the contract before making the transfer. After the transfer is made, a `Bought` event is emitted
    - **swapDemoTokenForDev**(*uint256* amount) - accepts the amount of DTOKs to swap for DEV tokens. The function checks to make sure the caller of the function has approved the contract to transfer their DTOKs before swapping the DTOKs back to DEV. After the transfer is made, a `Sold` event is emitted

If you don't already have a `contracts` directory in your Hardhat project, you can create a new directory:

```bash
mkdir contracts && cd contracts
```

Then, you can create a single file that we'll use to store the code for the `DemoToken` and `SimpleDex` contracts and another file for the batch precompile:

```bash
touch SimpleDex.sol Batch.sol
```

In the `SimpleDex.sol` file, you can paste in the following code for the `DemoToken` and `SimpleDex` contracts:

```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract DemoToken is ERC20 {
    constructor(uint256 initialSupply) ERC20("DemoToken", "DTOK") {
        // Assign 500 DTOK tokens to the SimpleDex contract
        _mint(msg.sender, initialSupply / 2);
        // Assign 500 DTOK tokens to the EOA that deployed the SimpleDex contract
        _mint(tx.origin, initialSupply / 2);
    }
}

contract SimpleDex {
    IERC20 public token;

    event Bought(uint256 amount);
    event Sold(uint256 amount);

    // Make constructor payable so that DEV liquidity exists for the contract
    constructor() payable {
        // Mint 1000 DTOK tokens. Half will be assigned to the SimpleDex contract 
        // and the other half will be assigned to the EOA that deployed the
        // SimpleDex contract
        token = new DemoToken(1000000000000000000000);
    }

    // Function to swap DEV for DTOK tokens
    function swapDevForDemoToken() payable public {
        // Verify the contract has enough tokens for the requested amount
        uint256 amountTobuy = msg.value;
        uint256 dexBalance = token.balanceOf(address(this));
        require(amountTobuy > 0, "You need to send some DEV");
        require(amountTobuy <= dexBalance, "Not enough tokens in the reserve");
        // If enough, swap the DEV to DTOKs
        token.transfer(msg.sender, amountTobuy);
        emit Bought(amountTobuy);
    }

    // Function to swap DTOK for DEV tokens
    function swapDemoTokenForDev(uint256 amount) public {
        // Make sure the requested amount is greater than 0 and the caller
        // has approved the requested amount of tokens to be transferred
        require(amount > 0, "You need to sell at least some tokens");
        uint256 allowance = token.allowance(msg.sender, address(this));
        require(allowance >= amount, "Check the token allowance");
        // Transfer the DTOKs to the contract
        token.transferFrom(msg.sender, address(this), amount);
        // Transfer the DEV tokens back to the caller
        payable(msg.sender).transfer(amount);
        emit Sold(amount);
    }
}
```

In the `Batch.sol` file, you can paste in the Batch Precompile contract.

??? code "Batch.sol"

    ```solidity
    // SPDX-License-Identifier: GPL-3.0-only
pragma solidity >=0.8.3;

/// @dev The Batch contract's address.
address constant BATCH_ADDRESS = 0x0000000000000000000000000000000000000808;

/// @dev The Batch contract's instance.
Batch constant BATCH_CONTRACT = Batch(BATCH_ADDRESS);

/// @author The Moonbeam Team
/// @title Batch precompile
/// @dev Allows to perform multiple calls through one call to the precompile.
/// Can be used by EOA to do multiple calls in a single transaction.
/// @custom:address 0x0000000000000000000000000000000000000808
interface Batch {
    /// @dev Batch multiple calls into a single transaction.
    /// All calls are performed from the address calling this precompile.
    ///
    /// In case of one subcall reverting following subcalls will still be attempted.
    ///
    /// @param to List of addresses to call.
    /// @param value List of values for each subcall. If array is shorter than "to" then additional
    /// calls will be performed with a value of 0.
    /// @param callData Call data for each `to` address. If array is shorter than "to" then
    /// additional calls will be performed with an empty call data.
    /// @param gasLimit Gas limit for each `to` address. Use 0 to forward all the remaining gas.
    /// If array is shorter than "to" then the remaining gas available will be used.
    /// @custom:selector 79df4b9c
    function batchSome(
        address[] memory to,
        uint256[] memory value,
        bytes[] memory callData,
        uint64[] memory gasLimit
    ) external;

    /// @dev Batch multiple calls into a single transaction.
    /// All calls are performed from the address calling this precompile.
    ///
    /// In case of one subcall reverting, no more subcalls will be executed but
    /// the batch transaction will succeed. Use batchAll to revert on any subcall revert.
    ///
    /// @param to List of addresses to call.
    /// @param value List of values for each subcall. If array is shorter than "to" then additional
    /// calls will be performed with a value of 0.
    /// @param callData Call data for each `to` address. If array is shorter than "to" then
    /// additional calls will be performed with an empty call data.
    /// @param gasLimit Gas limit for each `to` address. Use 0 to forward all the remaining gas.
    /// If array is shorter than "to" then the remaining gas available will be used.
    /// @custom:selector cf0491c7
    function batchSomeUntilFailure(
        address[] memory to,
        uint256[] memory value,
        bytes[] memory callData,
        uint64[] memory gasLimit
    ) external;

    /// @dev Batch multiple calls into a single transaction.
    /// All calls are performed from the address calling this precompile.
    ///
    /// In case of one subcall reverting, the entire batch will revert.
    ///
    /// @param to List of addresses to call.
    /// @param value List of values for each subcall. If array is shorter than "to" then additional
    /// calls will be performed with a value of 0.
    /// @param callData Call data for each `to` address. If array is shorter than "to" then
    /// additional calls will be performed with an empty call data.
    /// @param gasLimit Gas limit for each `to` address. Use 0 to forward all the remaining gas.
    /// If array is shorter than "to" then the remaining gas available will be used.
    /// @custom:selector 96e292b8
    function batchAll(
        address[] memory to,
        uint256[] memory value,
        bytes[] memory callData,
        uint64[] memory gasLimit
    ) external;

    /// Emitted when a subcall succeeds.
    event SubcallSucceeded(uint256 index);

    /// Emitted when a subcall fails.
    event SubcallFailed(uint256 index);
}
    ```


### Compile & Deploy Contracts {: #compile-deploy-contracts }

To compile the contracts, we'll go ahead and run the following Hardhat command:

```bash
npx hardhat compile
```

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>npx hardhat compile</span>
    <span data-ty>Compiled 6 Solidity files successfully (evm target: paris).</span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>

After compilation, an `artifacts` directory is created: it holds the bytecode and metadata of the contract, which are `.json` files. It’s a good idea to add this directory to the `.gitignore` file.

Next, we can deploy the `SimpleDex` contract, which upon deployment will automatically deploy the `DemoToken` contract and mint 1000 DTOKs and assign half of them to the `SimpleDex` contract and the other half to the address that you're initiating the deployment from.

We'll also add some initial liquidity to the contract by passing in a `value` when calling `deploy`. Since the value needs to be in Wei, we can use `ethers.parseEther` to pass in a value such as `"0.5"` DEV and it will convert the value to Wei for us.

Before deploying the contract, we'll need to create the deployment script. We'll create a new directory for the script and name it `scripts` and add a new file to it called `deploy.js`:

```bash
mkdir scripts && touch scripts/deploy.js
```

In the `deploy.js` script, you can paste in the following code, which will deploy the `SimpleDex` contract and print the address of the contract to the terminal upon successful deployment:

```js
async function main() {
  // Liquidity to add in DEV (i.e., '.5') to be converted to Wei
  const value = ethers.parseEther('INSERT_AMOUNT_OF_DEV');

  // Deploy the SimpleDex contract, which will also automatically deploy
  // the DemoToken contract and add liquidity to the contract
  const SimpleDex = await ethers.getContractFactory('SimpleDex',);
  const simpleDex = await SimpleDex.deploy({ value })
  
  // Wait for the deployment transaction to be included in a block
  await simpleDex.waitForDeployment();

   // Get and print the contract address
  const myContractDeployedAddress = await simpleDex.getAddress();
  console.log(`SimpleDex deployed to ${myContractDeployedAddress}`);
}

main().catch((error) => {
  console.error(error);
  process.exitCode = 1;
});
```

Now we can deploy the `SimpleDex` contract using the `run` command and specifying `moonbase` as the network:

```bash
npx hardhat run --network moonbase scripts/deploy.js
```

!!! note
    If you want to run the script in a standalone fashion using `node <script>`, you'll need to require the Hardhat Runtime Environment explicitly using `const hre = require('hardhat');` in the `deploy.js` file.

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>npx hardhat run --network moonbase scripts/deploy.js</span>
    <span data-ty>SimpleDex deployed to 0xA467EB6C80D4Dae4c45C5d31Ead341c34cdD1b5e</span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>

After a few seconds, the contract will be deployed, and you should see the address in the terminal. We'll need to use the address in the following sections to interact with the contract, so make sure you save it.

## Swap Tokens {: #swapping-tokens }

With the contract deployed, now we can create a script that will enable us to get started by swapping DEV tokens for DTOK tokens. Once we have the DTOKs, we can get into the approval and swap. We'll take a quick look at how the approval and swap work normally before diving into using the batch precompile to batch these transactions.

For simplicity, we'll create a single script to handle all of the logic needed to swap DEV to DTOKs and back, called `swap.js`. We'll add this file to the `scripts` directory:

```bash
touch scripts/swap.js
```

### Create Contract Instances {: #create-contract-instances }

We'll need to create contract instances for each of our contracts so that we can access each contract's functions. For this, we're going to use the `getContractAt` helper function of the Hardhat plugin.

For this step, we're going to need the contract address of the `SimpleDex` contract. Then we'll be able to use the `SimpleDex` contract instance to retrieve the `DemoToken` contract address through the `token` function.

We'll also need to add a contract instance for the batch precompile, which is located at `{{ networks.moonbase.precompiles.batch }}`.

You can add the following code to the `swap.js` file:

```js
const simpleDexAddress = 'INSERT_ADDRESS_OF_DEX';

async function main() {
  // Create instance of SimpleDex.sol
  const simpleDex = await ethers.getContractAt(
    'SimpleDex',
    simpleDexAddress
  );

  // Create instance of DemoToken.sol
  const demoTokenAddress = await simpleDex.token();
  const demoToken = await ethers.getContractAt(
    'DemoToken',
    demoTokenAddress
  );

  // Create instance of Batch.sol
  const batchAddress = '{{ networks.moonbase.precompiles.batch }}';
  const batch = await ethers.getContractAt('Batch', batchAddress);
}
main();
```

### Add Check Balances Helper Function {: #add-function-to-check-balances }

Next, we're going to create a helper function that will be used to check the balance of DTOK tokens the DEX and the signer account has. This will be particularly useful to see balance changes after the swaps are complete.

Since the `DemoToken` contract has an ERC-20 interface, you can check the balance of DTOKs an account has using the `balanceOf` function. So, we'll call the `balanceOf` function, passing in the address of the signer and the DEX, and then print the formatted results in DTOKs to the terminal:

```js
async function checkBalances(demoToken) {
  // Get the signer
  const signers = await ethers.getSigners();
  const signer = signers[0];
  const signerAddress = signer.address;

  // Get the balance of the DEX and print it
  const dexBalance = ethers.formatEther(
    await demoToken.balanceOf(simpleDexAddress)
  );
  console.log(`Dex ${simpleDexAddress} has a balance of: ${dexBalance} DTOKs`);

  // Get the balance of the signer and print it
  const signerBalance = ethers.formatEther(
    await demoToken.balanceOf(signer)
  );
  console.log(
    `Account ${signerAddress} has a balance of: ${signerBalance} DTOKs`
  );
}
```

### Approve & Swap Tokens for DEV using the Batch Precompile {: #add-logic-to-swap-dtoks }

At this point, you should already have some DTOKs in your signing account, and the `SimpleDex` contract should have some DEV liquidity. If not, you can use the `simpleDex.swapDevForDemoToken` function to acquire some DTOKs and add liquidity to the DEX.

Now, we can approve the DEX to spend some DTOK tokens on our behalf so that we can swap the DTOKs for DEVs. On Ethereum, for example, we would need to send two transactions to be able to swap the DTOKs back to DEVs: an approval and a transfer. However, on Moonbeam, thanks to the batch precompile contract, you can batch these two transactions into a single one. This allows us to set the approval amount for the exact amount of the swap.

So instead of calling `demoToken.approve(spender, amount)` and then `simpleDex.swapDemoTokenForDev(amount)`, we'll get the encoded call data for each of these transactions and pass them into the batch precompile's `batchAll` function. To get the encoded call data, we'll use Ether's `interface.encodeFunctionData` function and pass in the necessary parameters. For example, we'll swap .2 DTOK for .2 DEV. In this case, for the approval, we can pass in the DEX address as the `spender` and set the `amount` to .2 DTOK. We'll also set the `amount` to swap as .2 DTOK. Again, we can use the `ethers.parseEther` function to convert the amount in DTOK to Wei for us.

Once we have the encoded call data, we can use it to call the `batchAll` function of the batch precompile. This function performs multiple calls atomically, where the same index of each array combine into the information required for a single subcall. If a subcall reverts, all subcalls will revert. The following parameters are required by the `batchAll` function:

- ***address[]* to** - an array of addresses to direct subtransactions to, where each entry is a subtransaction
- ***uint256[]* value** - an array of native currency values to send in the subtransactions, where the index corresponds to the subtransaction of the same index in the *to* array. If this array is shorter than the *to* array, all the following subtransactions will default to a value of 0
- ***bytes[]* callData** - an array of call data to include in the subtransactions, where the index corresponds to the subtransaction of the same index in the *to* array. If this array is shorter than the *to* array, all of the following subtransactions will include no call data
- ***uint64[]* gasLimit** - an array of gas limits in the subtransactions, where the index corresponds to the subtransaction of the same index in the *to* array. Values of 0 are interpreted as unlimited and will have all remaining gas of the batch transaction forwarded. If this array is shorter than the *to* array, all of the following subtransactions will have all remaining gas forwarded

So, the first index of each array will correspond to the approval and the second will correspond to the swap.

After the swap, we'll check the balances using the `checkBalances` function to make sure the balances have changed as expected.

We'll update the `main` function to include the following logic:

```js
async function main() {
  // ...

  // Parse the value to swap to Wei
  const amountDtok = ethers.parseEther('INSERT_AMOUNT_OF_DTOK_TO_SWAP');

  // Get the encoded call data for the approval and swap
  const approvalCallData = demoToken.interface.encodeFunctionData('approve', [
    simpleDexAddress,
    amountDtok,
  ]);
  const swapCallData = simpleDex.interface.encodeFunctionData(
    'swapDemoTokenForDev',
    [amountDtok]
  );

  // Assemble and send the batch transaction
  const batchAll = await batch.batchAll(
    [demoTokenAddress, simpleDexAddress], // to address
    [], // value of the native token to send 
    [approvalCallData, swapCallData], // call data
    [] // gas limit
  );
  await batchAll.wait();
  console.log(`Approve and swap DTOK tokens for DEV tokens: ${batchAll.hash}`);

  // Check balances after the swap
  await checkBalances(demoToken);
}
```

So, if you set the amount to swap to be .2 DTOK, the DEX balance will increase by .2 DTOK, and the signing account's balance will decrease by .2 DTOK. The transaction hash for the swap will also be printed to the terminal, so you can use [Moonscan](https://moonbase.moonscan.io){target=\_blank} to view more information on the transaction.

??? code "View the complete script"

    ```js
    const simpleDexAddress = 'INSERT_ADDRESS_OF_DEX';

async function checkBalances(demoToken) {
  // Get the signer
  const signers = await ethers.getSigners();
  const signer = signers[0];
  const signerAddress = signer.address;

  // Get the balance of the DEX and print it
  const dexBalance = ethers.formatEther(
    await demoToken.balanceOf(simpleDexAddress)
  );
  console.log(`Dex ${simpleDexAddress} has a balance of: ${dexBalance} DTOKs`);

  // Get the balance of the signer and print it
  const signerBalance = ethers.formatEther(
    await demoToken.balanceOf(signer)
  );
  console.log(`Account ${signerAddress} has a balance of: ${signerBalance} DTOKs`);
}

async function main() {
  // Create instance of SimpleDex.sol
  const simpleDex = await ethers.getContractAt('SimpleDex', simpleDexAddress);

  // Create instance of DemoToken.sol
  const demoTokenAddress = await simpleDex.token();
  const demoToken = await ethers.getContractAt('DemoToken', demoTokenAddress);

  // Create instance of Batch.sol
  const batchAddress = '0x0000000000000000000000000000000000000808';
  const batch = await ethers.getContractAt('Batch', batchAddress);

  // Parse the value to swap to Wei
  const amountDtok = ethers.parseEther('INSERT_AMOUNT_OF_DEV_TO_SWAP');

  // Get the encoded call data for the approval and swap
  const approvalCallData = demoToken.interface.encodeFunctionData('approve', [
    simpleDexAddress,
    amountDtok,
  ]);
  const swapCallData = simpleDex.interface.encodeFunctionData(
    'swapDemoTokenForDev',
    [amountDtok]
  );

  const batchAll = await batch.batchAll(
    [demoTokenAddress, simpleDexAddress], // to address
    [], // value of the native token to send
    [approvalCallData, swapCallData], // call data
    [] // gas limit
  );
  await batchAll.wait();
  console.log(`Approve and swap demo tokens for dev tokens: ${batchAll.hash}`);

  // Check balances after the swap
  await checkBalances(demoToken);
}
main();
    ```

To run the script, you can use the following command:

```bash
npx hardhat run --network moonbase scripts/swap.js
```

In the terminal, you should see the following items:

- The transaction hash for the batch approval and swap
- The DEX's DTOK balance after the batch approval and swap
- Your account's DTOK balance after the batch approval and swap

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>npx hardhat run --network moonbase scripts/swap.js</span>
    <span data-ty>Approve and swap demo tokens for dev tokens: 0x56cd9777f10e76b5b98a9ff57f7db44c5c847a615955202148e56aa6221168d6</span>
    <span data-ty>Dex 0x462830eC426E617D8DB8e3c36de34d85A7b60a2 has a balance of: 500.2 DTOKS</span>
    <span data-ty>Account Oxf24FF3a9CF04c71Dbc94D0b566f7A27B94566cac has a balance of: 499.8 DTOKs</span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>

And that's it! You've successfully used the batch precompile contract to batch an approval and swap into a single transaction, allowing for the approval amount to be the exact swap amount.

## Uniswap V2 Implementation {: #uniswap-v2-implementation }

If we had a Uniswap V2-style DEX, the typical process for a swap would involve the router, which provides methods to safely swap assets, including the `swapExactTokensForETH` function. This function can be compared to the `swapDemoTokenForDev` function of the SimpleDex contract in the example above, where it swaps tokens in exchange for the native asset.

Before using the `swapExactTokensForETH` function, we would first need to approve the router as the spender and specify the approved amount to spend. Then, we could use the swap function once the router has been authorized to move our assets.

Like our previous example, this two-transaction process can be modified to batch the approval and the `swapExactTokensForETH` function into a single transaction using the batch precompile.

This example will be based off the [Uniswap V2 deployment on Moonbase Alpha](https://github.com/papermoonio/moonbeam-uniswap){target=\_blank}. We'll approve the router to spend ERTH tokens and then swap ERTH for DEV tokens. Before diving into this example, make sure you swap some DEV for ERTH tokens on the [Moonbeam-swap DApp](https://moonbeam-swap.netlify.app/#/swap){target=\_blank}, so that you have some ERTH to approve and swap back to DEV.

Again, we'll use the `batchAll` function of the batch precompile. So, we'll need to get the encoded call data for the approval and the swap. To get the encoded call data, we'll use Ether's `interface.encodeFunctionData` function and pass in the necessary parameters.

For the `approve(spender, amount)` function, we'll need to pass in the Uniswap V2 router contract as the `spender`, as well as the amount of ERTH tokens approved to spend for the `amount`.

For the `swapExactTokensForETH(amountIn, amountOutMin, path, to, deadline)` function, we'll need to specify the amount of tokens to send, the minimum amount of output tokens that must be received so the transaction won't revert, the token addresses for the swap, the recipient of the native asset, and the deadline after which the transaction will revert. To swap ERTH to DEV, the path will be ERTH to WETH, so the path array will need to include the ERTH token address and the WETH token address: `[0x08B40414525687731C23F430CEBb424b332b3d35, 0xD909178CC99d318e4D46e7E66a972955859670E1]`.

In addition to the ERTH and WETH addresses, to create a contract instance of the router contract, you'll also need the [router address](https://github.com/papermoonio/moonbeam-uniswap/blob/f494f9a7a07bd3c5b94ac46484c9c7e6c781203f/uniswap-contracts-moonbeam/address.json#L14){target=\_blank}, which is `0x8a1932D6E26433F3037bd6c3A40C816222a6Ccd4`.

The code will resemble the following:

```js
// Define contract addresses
const erthTokenAddress = '0x08B40414525687731C23F430CEBb424b332b3d35';
const routerAddress = '0x8a1932D6E26433F3037bd6c3A40C816222a6Ccd4';
const wethTokenAddress = '0xD909178CC99d318e4D46e7E66a972955859670E1';

async function main() {
  // Create contract instances for the ERTH token, the Uniswap V2 router contract,
  // and the batch precompile
  // ...

  // Access the interface of the ERTH contract instance to get the encoded 
  // call data for the approval
  const amountErth = ethers.parseEther('INSERT_AMOUNT_OF_ERTH_TO_SWAP');
  const approvalCallData = earth.interface.encodeFunctionData('approve', [
    routerAddress,
    amountErth,
  ]);

  // Access the interface of the Uniswap V2 router contract instance to get
  // the encoded call data for the swap
  const swapCallData = router.interface.encodeFunctionData(
    'swapExactTokensForETH',
    [
      amountErth, // amountIn
      'INSERT_AMOUNT_OUT_MIN', // amountOutMin
     [
      erthTokenAddress, // ERTH token address
      wethTokenAddress // WETH token address
      ], // path 
     'INSERT_YOUR_ADDRESS', // to
     'INSERT_DEADLINE' // deadline
    ]
  );

  // Assemble and send the batch transaction
  const batchAll = await batch.batchAll(
    [erthTokenAddress, routerAddress], // to address
    [], // value of the native token to send 
    [approvalCallData, swapCallData], // call data
    [] // gas limit
  );
  await batchAll.wait();
  console.log(`Approve and swap ERTH tokens for DEV tokens: ${batchAll.hash}`);
}
main();
```

!!! note
    If you need the ABI to create a contract instance for any of the contracts in this example, all of the contracts are verified on [Moonscan](https://moonbase.moonscan.io){target=\_blank}. So, you can search for the contract addresses on Moonscan and head to the **Contract** tab to get the **Contract ABI**.

This will result in the approval and swap being batched into a single transaction and the transaction hash will be printed to the console. You can now adapt and apply this logic to your Uniswap V2-style application!

<div class="page-disclaimer">
    This tutorial is for educational purposes only. As such, any contracts or code created in this tutorial should not be used in production.
</div>
<div class="page-disclaimer">
  The information presented herein has been provided by third parties and is made available solely for general information purposes. Moonbeam does not endorse any project listed and described on the Moonbeam Doc Website (https://docs.moonbeam.network/). Moonbeam Foundation does not warrant the accuracy, completeness or usefulness of this information. Any reliance you place on such information is strictly at your own risk. Moonbeam Foundation disclaims all liability and responsibility arising from any reliance placed on this information by you or by anyone who may be informed of any of its contents. All statements and/or opinions expressed in these materials are solely the responsibility of the person or entity providing those materials and do not necessarily represent the opinion of Moonbeam Foundation. The information should not be construed as professional or financial advice of any kind. Advice from a suitably qualified professional should always be sought in relation to any particular matter or circumstance. The information herein may link to or integrate with other websites operated or content provided by third parties, and such other websites may link to this website. Moonbeam Foundation has no control over any such other websites or their content and will have no liability arising out of or related to such websites or their content. The existence of any such link does not constitute an endorsement of such websites, the content of the websites, or the operators of the websites. These links are being provided to you only as a convenience and you release and hold Moonbeam Foundation harmless from any and all liability arising from your use of this information or the information provided by any third-party website or service.
</div>
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/tutorials/eth-api/call-permit-gasless-txs/
--- BEGIN CONTENT ---
---
title: Gasless Transactions with the Call Permit Precompile
description: Enable gas-less transactions in your DApp with Moonbeam's Call Permit Precompile! Learn how to implement the Call Permit Precompile to improve user experience.
categories: Tutorials, Precompiles
---

# Use the Call Permit Precompile to Send Gasless Transactions

_by Erin Shaben_

## Introduction {: #introduction }

To interact with dApps on Moonbeam, users typically need to hold GLMR, Moonbeam's native token, in order to pay for transaction fees. This requirement creates an obstacle for dApps in terms of user experience, as a user needs to ensure they keep a balance of the native token to interact with the dApp.

One solution to this problem is gasless transactions, also known as meta transactions. Gasless transactions are a type of transaction that does not require the user to pay for the gas required to execute the transaction. The gas for these transactions can be covered by a third-party service or it can be deducted from the user's balance of a different token, depending on the implementation. For example, a user could simply sign a message that represents the transaction to be submitted to the network, and then a third-party could submit the transaction and pay the transaction fees for the user.

A regular transaction may have the following flow:

![Flow of a transaction](/images/tutorials/eth-api/call-permit-gasless-txs/gasless-1.webp)

Whereas a gasless transaction may look something like this:

![Flow of a gasless transaction](/images/tutorials/eth-api/call-permit-gasless-txs/gasless-2.webp)

Gasless transactions can be especially beneficial for users that make small transactions frequently, as is the case with gaming dApps like [Damned Pirates Society](https://damnedpiratessociety.io){target=\_blank} (DPS). In DPS, users go on voyages in search of treasure and with the goal of growing their fleet. There are two in-game currencies that are used in DPS: Treasure Maps (TMAP) and Doubloons (DBL). TMAP are used to buy voyages, and DBL are used to maintain flagships and buy support ships and can be earned while on voyages. Currently, if a user wants to start a voyage, they'll need TMAP to buy the voyage and GLMR to pay for transaction fees. Wouldn't it be ideal to lower the barrier to entry by implementing gasless transactions so users wouldn't need to worry about keeping a GLMR balance on top of their TMAP and DBL balances? From a dApp's perspective, it would keep users on their platform, as their users wouldn't need to leave the dApp to fund their GLMR balance; they could keep on gaming.

Gasless transactions can be implemented using Moonbeam's [Call Permit Precompile](/builders/ethereum/precompiles/ux/call-permit/){target=\_blank}, which is a Solidity interface that allows a user to sign a permit, an [EIP-712](https://eips.ethereum.org/EIPS/eip-712){target=\_blank} signed message, that can then be dispatched by your dApp. The Call Permit Precompile can be used to execute any EVM call. **The best part is that you don't need to modify your existing contracts!**

In this tutorial, we'll walk through the process of implementing gasless transactions in a dApp. More specifically, we'll take a closer look at how we can implement gasless transactions to buy a voyage in DPS, as an example. We'll go over building an EIP-712 signed message, signing it, and dispatching it with the Call Permit Precompile.

## What are EIP-712 Signed Messages? {: #eip-712-signed-messages }

An [EIP-712](https://eips.ethereum.org/EIPS/eip-712){target=\_blank} signed message is a message that is structured, hashed, and signed in a standardized way. The benefit of the EIP-712 standardization is that message data can be displayed in a much more human-readable way for users signing these messages, so they can better understand what exactly they're signing. Before this standardization existed, users had to sign off on unreadable and difficult-to-decode hexadecimal strings, which made it easy for users to misplace their trust and sign off on messages with malicious data.

The EIP-712 standard specifies how the message data should be structured by requiring developers to define a JSON structure of the message data that users will sign off on and specifying a domain separator. The main goal of the domain separator is to prevent replay attacks. We'll cover both of these requirements in the following sections.

## Checking Prerequisites {: #checking-prerequisites }

For this tutorial, you'll need the following:

- An account with funds.
  You can get DEV tokens for testing on Moonbase Alpha once every 24 hours from the [Moonbase Alpha Faucet](https://faucet.moonbeam.network){target=\_blank}
- A project with [Ethers](/builders/ethereum/libraries/ethersjs/){target=\_blank} installed:

    ```bash
    npm i ethers
    ```
- 
 To test out the examples in this guide on Moonbeam or Moonriver, you will need to have your own endpoint and API key, which you can get from one of the supported [Endpoint Providers](/builders/get-started/endpoints/){target=\_blank}

## Configure your Project {: #configure-your-project }

To get started, make sure you have a project with Ethers installed, as specified in the [prerequisites](#checking-prerequisites). To configure Ethers for Moonbeam, you'll need to:

1. Import `ethers`
2. Define the network configurations
3. Create an `ethers` provider

=== "Moonbeam"

    ```js
    // 1. Import ethers
    import { ethers } from 'ethers';

    // 2. Define network configurations
    const providerRPC = {
      moonbeam: {
        name: 'moonbeam',
        rpc: '{{ networks.moonbeam.rpc_url }}', // Insert your RPC URL here
        chainId: {{ networks.moonbeam.chain_id }}, // {{ networks.moonbeam.hex_chain_id }} in hex,
      },
    };
    // 3. Create ethers provider
    const provider = new ethers.JsonRpcProvider(providerRPC.moonbeam.rpc, {
      chainId: providerRPC.moonbeam.chainId,
      name: providerRPC.moonbeam.name,
    });
    ```

=== "Moonriver"

    ```js
    // 1. Import ethers
    import { ethers } from 'ethers';

    // 2. Define network configurations
    const providerRPC = {
      moonriver: {
        name: 'moonriver',
        rpc: '{{ networks.moonriver.rpc_url }}', // Insert your RPC URL here
        chainId: {{ networks.moonriver.chain_id }}, // {{ networks.moonriver.hex_chain_id }} in hex,
      },
    };
    // 3. Create ethers provider
    const provider = new ethers.JsonRpcProvider(providerRPC.moonriver.rpc, {
      chainId: providerRPC.moonriver.chainId,
      name: providerRPC.moonriver.name,
    });
    ```

=== "Moonbase Alpha"

    ```js
    // 1. Import ethers
    import { ethers } from 'ethers';

    // 2. Define network configurations
    const providerRPC = {
      moonbase: {
        name: 'moonbase-alpha',
        rpc: '{{ networks.moonbase.rpc_url }}',
        chainId: {{ networks.moonbase.chain_id }}, // {{ networks.moonbase.hex_chain_id }} in hex,
      },
    };
    // 3. Create ethers provider
    const provider = new ethers.JsonRpcProvider(providerRPC.moonbase.rpc, {
      chainId: providerRPC.moonbase.chainId,
      name: providerRPC.moonbase.name,
    });
    ```

=== "Moonbeam Dev Node"

    ```js
    // 1. Import ethers
    import { ethers } from 'ethers';

    // 2. Define network configurations
    const providerRPC = {
      dev: {
        name: 'moonbeam-development',
        rpc: '{{ networks.development.rpc_url }}',
        chainId: {{ networks.development.chain_id }}, // {{ networks.development.hex_chain_id }} in hex,
      },
    };
    // 3. Create ethers provider
    const provider = new ethers.JsonRpcProvider(providerRPC.dev.rpc, {
      chainId: providerRPC.dev.chainId,
      name: providerRPC.dev.name,
    });
    ```

As previously mentioned, there are several ways to set up gasless transactions. For the purposes of this tutorial, we'll assume that there is a third-party account that pays the fees. As such, you'll need to have a signer for the user of the dApp, which is connected to your user's wallet, and a signer for the third-party account paying for the transaction fees. This tutorial assumes that you already have these signers in place, but if needed, you can set up the following generic signers for testing purposes:

```js
const userSigner = new ethers.Wallet('INSERT_PRIVATE_KEY', provider);
const thirdPartyGasSigner = new ethers.Wallet('INSERT_PRIVATE_KEY', provider);
```

!!! remember
    Never store your private keys in a JavaScript or TypeScript file.

Now that we've set up the initial configurations, let's dive into building the EIP-712 signed message.

## Build an EIP-712 Typed Message {: #build-an-eip-712-signed-message }

There are three components that we'll need to build an EIP-712 typed message: the domain separator, the typed data structure for the data that users will sign, and the actual message data.

The domain separator and the typed data structure will be based on the [Call Permit Precompile](/builders/ethereum/precompiles/ux/call-permit/){target=\_blank}. The steps to build both of these components will always be the same, regardless of the data that is being signed. The actual message data will change depending on your individual use case.

### Define the Domain Separator {: #define-domain-separator }

We'll first start off with the domain separator, which will define the Call Permit Precompile as the signing domain. Permits will get dispatched by calling the `dispatch` function of the Call Permit Precompile, which is why the Call Permit Precompile is always going to be the signing domain. As previously mentioned, the goal of the domain separator is to avoid replay attacks. 

The domain separator is defined in the [EIP-712 standard](https://eips.ethereum.org/EIPS/eip-712){target=\_blank} and is calculated as:

```text
keccak256(PERMIT_DOMAIN, name, version, chain_id, address)
```

The parameters of the hash can be broken down as follows:

 - **PERMIT_DOMAIN** - is the `keccak256` of `EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)`
 - **name** - is the name of the signing domain and must be `'Call Permit Precompile'` exactly
 - **version** - is the version of the signing domain. For this case **version** is set to `1`
 - **chainId** - is the chain ID of the network
 - **verifyingContract** - is the address of the contract that will verify the signature. In this case, the Call Permit Precompile address

We're using Ethers in this example, which requires the domain separator to be in the format specified by the [`TypedDataDomain` interface](https://docs.ethers.org/v6/api/hashing/#TypedDataDomain){target=\_blank}, but if desired, you could generate the domain separator as a *bytes32* representation using the [`DOMAIN_SEPARATOR()` function of the Call Permit Precompile](/builders/ethereum/precompiles/ux/call-permit/#:~:text=DOMAIN_SEPARATOR()){target=\_blank}.

The domain separator for each Moonbeam network is as follows:

=== "Moonbeam"

    ```js
    const domain = {
      name: 'Call Permit Precompile',
      version: '1',
      chainId: {{ networks.moonbeam.chain_id }},
      verifyingContract: '{{ networks.moonbeam.precompiles.call_permit}}',
    };
    ```

=== "Moonriver"

    ```js
    const domain = {
      name: 'Call Permit Precompile',
      version: '1',
      chainId: {{ networks.moonriver.chain_id }},
      verifyingContract: '{{ networks.moonriver.precompiles.call_permit}}',
    };
    ```

=== "Moonbase Alpha"

    ```js
    const domain = {
      name: 'Call Permit Precompile',
      version: '1',
      chainId: {{ networks.moonbase.chain_id }},
      verifyingContract: '{{ networks.moonbase.precompiles.call_permit}}',
    };
    ```

=== "Moonbeam Dev Node"

    ```js
    const domain = {
      name: 'Call Permit Precompile',
      version: '1',
      chainId: {{ networks.development.chain_id }},
      verifyingContract: '{{ networks.moonbase.precompiles.call_permit}}',
    };
    ```

### Define the Typed Data Structure {: #define-typed-data-structure }

Next, we'll need to define the typed data structure. The typed data structure defines the acceptable types of data that our users will be signing. We'll go into detail on the actual data in the following section.

If you take a look at the [`dispatch` function of the Call Permit Precompile](/builders/ethereum/precompiles/ux/call-permit/#the-call-permit-interface){target=\_blank}, you'll see that the data that we need to send, along with the associated types, is as follows:

```solidity
function dispatch(
    address from,
    address to,
    uint256 value,
    bytes memory data,
    uint64 gaslimit,
    uint256 deadline,
    uint8 v,
    bytes32 r,
    bytes32 s
) external returns (bytes memory output);
```

We'll need to add each of the above parameters to our typed data structure, with a couple of modifications. We don't need to include the signature-related parameters, but we do need to include a parameter for the `nonce` of the `from` account, which will be a *uint256*. The signature-related parameters aren't needed at this point because we're building the message data for the users to sign. We'll circle back to the signature-related parameters after we've finished building the message and requested the signature.

So, if we grab the rest of the parameters, we can start to build our data structure. Some implementations of EIP-712 require a type for `EIP712Domain` to be specified, but this is not the case when using Ethers as it computes it for you! For our implementation, the only type we'll need is the `CallPermit` type. The `CallPermit` type will be an array of objects that correspond to each of the parameters and define the `name` and `type` for each one:

```js
const types = {
  CallPermit: [
    { name: 'from', type: 'address' },
    { name: 'to', type: 'address' },
    { name: 'value', type: 'uint256' },
    { name: 'data', type: 'bytes' },
    { name: 'gaslimit', type: 'uint64' },
    { name: 'nonce', type: 'uint256' },
    { name: 'deadline', type: 'uint256' },
  ],
};
```

### Define the Message Data {: #define-message-data }

Since we are going to implement gasless transactions for buying a voyage, we're going to be interacting with the [Cartographer V1 contract](https://moonscan.io/address/0xD1A9bA3e61Ac676f58B29EA0a09Cf5D7f4f35138#code){target=\_blank}, which is located at this address: `0xD1A9bA3e61Ac676f58B29EA0a09Cf5D7f4f35138` on Moonbeam.

So, let's start by going over the arguments required to build the message data:

- `from` - your user's address, which you can easily get from your user's Ethers signer using `signer.address`
- `to` - the contract address that you want to interact with. For this example, we'll use the address of DPS's Cartographer V1 contract
- `value` - the value to be transferred from the `from` account. This will be `0` as TMAP are used to buy voyages, not GLMR
- `data` - the calldata to be executed, which we'll calculate in the following steps
- `gaslimit`- the gas limit the call requires
- `nonce` - the nonce of the `from` account. This isn't your standard nonce, but the nonce for permits dispatched through the Call Permit Precompile specifically. To get this nonce, you can call the Call Permit Precompile's `nonces` function and pass in the address of the `from` account
- `deadline` - the deadline in UNIX seconds after which the permit will expire and no longer be valid

The message will resemble the following:

```js
const message = {
  from: userSigner.address,
  to: '0xD1A9bA3e61Ac676f58B29EA0a09Cf5D7f4f35138', // Cartographer V1 contract
  value: 0,
  data: 'TODO: Calculate the data that will buy a voyage',
  gaslimit: 'TODO: Estimate the gas',
  nonce: 'TODO: Use the Call Permit Precompile to get the nonce of the from account',
  deadline: '1714762357000', // Randomly created deadline in the future
};
```

Now, let's dig a little bit deeper and tackle the `TODO` items.

#### Get the Encoded Call Data for Buying a Voyage {: #encoded-call-data-buying-voyage }

We'll start off by calculating the `data` value. We can programmatically calculate the `data` value with [Ethers](/builders/ethereum/libraries/ethersjs/){target=\_blank} by creating an interface of the Cartographer V1 contract and using the `interface.encodeFunctionData` function.

If you take a look at the [`DPSCartographer.sol` contract's code](https://moonscan.io/address/0xD1A9bA3e61Ac676f58B29EA0a09Cf5D7f4f35138#code){target=\_blank}, you'll see the [`buyVoyages` function](https://moonscan.io/address/0xD1A9bA3e61Ac676f58B29EA0a09Cf5D7f4f35138#code#F1#L75){target=\_blank}. The `buyVoyages` function accepts three parameters:

- *uint16* `_voyageType` - specifies the type of voyage to buy, i.e., easy, medium, hard, etc. This value corresponds to the index of the voyage in the [`VOYAGE_TYPE` enum](https://moonscan.io/address/0x72a33394f0652e2bf15d7901f3cd46863d968424#code){target=\_blank}. For this example, we'll do an easy voyage, so we'll pass in `0` as the value
- *uint256* `_amount` - corresponds to the number of voyages to buy. We'll buy one voyage
- *DPSVoyageIV2* `_voyage` - represents the address of the `DPSVoyageV2.sol` contract, which is: `0x72A33394f0652e2Bf15d7901f3Cd46863d968424` on Moonbeam

To create an interface using Ethers, we'll need to get the ABI of the Cartographer V1 contract. You can retrieve it in full from [Moonscan](https://moonscan.io/address/0xD1A9bA3e61Ac676f58B29EA0a09Cf5D7f4f35138#code){target=\_blank}, or for simplicity, you can use the following snippet, which is the part of the ABI we need for this example:

```js
const cartographerAbi = [
  {
    inputs: [
      { internalType: 'uint16', name: '_voyageType', type: 'uint16' },
      { internalType: 'uint256', name: '_amount', type: 'uint256' },
      {
        internalType: 'contract DPSVoyageIV2',
        name: '_voyage',
        type: 'address',
      },
    ],
    name: 'buyVoyages',
    outputs: [],
    stateMutability: 'nonpayable',
    type: 'function',
  },
];
```

Then we can create the interface using the ABI and get the encoded data using the values we specified for each of the parameters of the `buyVoyages` function:

```js
const cartographerInterface = new ethers.Interface(cartographerAbi);
const data = cartographerInterface.encodeFunctionData('buyVoyages', [
  0n, // Voyage type: Easy
  1n, // Number of voyages to buy
  '0x72A33394f0652e2Bf15d7901f3Cd46863d968424', // Voyage V2 contract
]);
```

This will provide us with the following value for `data`:

```js
'0xdb76d5b30000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000072a33394f0652e2bf15d7901f3cd46863d968424'
```

#### Estimate the Gas Required to Buy a Voyage {: #estimate-gas-buy-voyage }

Now that we have the encoded call data for buying a voyage, we can use it to estimate the gas required for the transaction. We'll use the `estimateGas` method and pass in the user's address, the address of the Cartographer V1 contract, and the encoded call data:

```js
const gasEstimate = await provider.estimateGas({
  from: userSigner.address,
  to: '0xD1A9bA3e61Ac676f58B29EA0a09Cf5D7f4f35138', // Cartographer V1 contract
  data,
})
```

!!! note
    For this example, you'll need to have a balance of at least 1 TMAP to be able to estimate the gas. Otherwise, you'll get a `'VM Exception while processing transaction: revert'` error.

We'll add a little bit of a buffer to the `gasEstimate` value and set it as the `gaslimit`:

```js
const message = {
  ...
  gaslimit: gasEstimate + 50000n,
  ...
}
```

We'll get the nonce in the next section, and then put all of the arguments together, and the message data will be complete.

#### Get the Signer's Nonce Using the Call Permit Precompile {: #get-signers-nonce }

Lastly, we'll need to get the `nonce` of the `from` account. As previously mentioned, we can use the `nonces` function of the Call Permit Precompile to get this value. To do so, you'll need to create a contract instance for the Call Permit Precompile:

1. Create a new file in your project that contains the ABI of the Call Permit Precompile. You can find the [ABI on GitHub](https://raw.githubusercontent.com/moonbeam-foundation/moonbeam-docs/master/.snippets/code/builders/ethereum/precompiles/ux/call-permit/abi.js){target=\_blank}
2. Import the ABI into your Ethers file
3. Create an instance of the Call Permit Precompile using the precompile's address and the ABI of the precompile. You can use either a provider or a signer. Since we are dispatching the permit later on in this tutorial, we'll use the signer associated with the third-party account for transaction fees, but if you only needed to access the `nonces` function, you could use a provider instead
4. Call the `nonces` function and pass in the `signer.account` of the user, which is the same as the `from` account

```js
...
import abi from './callPermitABI.js'

...

const callPermit = new ethers.Contract(
  '{{ networks.moonbeam.precompiles.call_permit }}', 
  abi, 
  thirdPartyGasSigner,
);

const nonce = await callPermit.nonces(userSigner.address);
```

??? code "View the script so far"

    ```js
    import { ethers } from 'ethers';
    import abi from './callPermitABI.js'
    import cartographerAbi from './cartographerAbi.js'

    const providerRPC = {
      moonbeam: {
        name: 'moonbeam',
        rpc: '{{ networks.moonbeam.rpc_url }}', // Insert your RPC URL here
        chainId: {{ networks.moonbeam.chain_id }}, // {{ networks.moonbeam.hex_chain_id }} in hex,
      },
    };
    const provider = new ethers.JsonRpcProvider(providerRPC.moonbeam.rpc, {
      chainId: providerRPC.moonbeam.chainId,
      name: providerRPC.moonbeam.name,
    });

    // Insert your own signer logic or use the following for testing purposes
    const userSigner = new ethers.Wallet('INSERT_PRIVATE_KEY', provider);
    const thirdPartyGasSigner = new ethers.Wallet('INSERT_PRIVATE_KEY', provider);

    const domain = {
      name: 'Call Permit Precompile',
      version: '1',
      chainId: {{ networks.moonbeam.chain_id }},
      verifyingContract: '{{ networks.moonbeam.precompiles.call_permit}}',
    };

    const types = {
      CallPermit: [
        { name: 'from', type: 'address' },
        { name: 'to', type: 'address' },
        { name: 'value', type: 'uint256' },
        { name: 'data', type: 'bytes' },
        { name: 'gaslimit', type: 'uint64' },
        { name: 'nonce', type: 'uint256' },
        { name: 'deadline', type: 'uint256' },
      ],
    };

    const cartographerInterface = new ethers.Interface(cartographerAbi);
    const data = cartographerInterface.encodeFunctionData('buyVoyages', [
      0n, // Voyage type: Easy
      1n, // Number of voyages to buy
      '0x72A33394f0652e2Bf15d7901f3Cd46863d968424', // Voyage V2 contract
    ]);

    const gasEstimate = await provider.estimateGas({
      from: userSigner.address,
      to: '0xD1A9bA3e61Ac676f58B29EA0a09Cf5D7f4f35138', // Cartographer V1 contraact
      data,
    })

    const callPermit = new ethers.Contract(
      '{{ networks.moonbeam.precompiles.call_permit }}', 
      abi, 
      thirdPartyGasSigner,
    );

    const nonce = await callPermit.nonces(userSigner.address);

    const message = {
      from: userSigner.address,
      to: '0xD1A9bA3e61Ac676f58B29EA0a09Cf5D7f4f35138', // Cartographer V1 contract
      value: 0,
      data,
      gaslimit: gasEstimate + 50000n,
      nonce,
      deadline: '1714762357000', // Randomly created deadline in the future
    };
    ```

    !!! remember
        Never store your private keys in a JavaScript or TypeScript file.

So far, we've created the domain separator, defined the data structure of our EIP-712 message, and assembled the data for the message. Next, we'll need to request the signature for our EIP-712 typed message!

## Get Signature for EIP-712 Typed Messages {: #use-ethers-to-sign-eip712-messages }

For this next step, we're going to use our Ethers signer and the `signer.signTypedData` function to prompt our users to sign the EIP-712 typed message we've assembled. This signature will allow the third-party account for transaction fees to call the `dispatch` function of the Call Permit Precompile. The third-party account will pay the transaction fees for us, and a voyage will be bought on our behalf!

The `signTypedData` function will calculate a signature for our data using the following calculation:

```text
sign(keccak256("\x19\x01" ‖ domainSeparator ‖ hashStruct(message)))
```

The components of the hash can be broken down as follows:

- **\x19** - makes the encoding deterministic
- **\x01** - the version byte, which makes the hash compliant with [EIP-191](https://eips.ethereum.org/EIPS/eip-191){target=\_blank}
- **domainSeparator** - the 32-byte domain separator, which was [previously covered](#define-the-domain-separator) and can be easily retrieved using the `DOMAIN_SEPARATOR` function of the Call Permit Precompile
- **hashStruct(message)** - the 32-byte data to sign, which is based on the typed data structure and the actual data. For more information, please refer to the [EIP-712 specification](https://eips.ethereum.org/EIPS/eip-712#definition-of-hashstruct){target=\_blank}

Now that we have an understanding of what the `signTypedData` function does, we can go ahead and pass in the data we've assembled in the previous sections:

```js
const signature = await signer.signTypedData(
  domain, // The domain separator
  types, // The typed data structure
  message, // The message data
);
console.log(`Signature hash: ${signature}`);
```

A hash of the signature will print to the terminal. We'll use the user's signature to dispatch the permit from the third-party account using the Call Permit Precompile's `dispatch` function in the next section.

## Dispatch a Signed EIP-712 Message {: #dispatch-eip712-message }

Before an EIP-712 signed message can be dispatched, we'll need to get the signature-related parameters, `v`, `r`, and `s`, from the signed message. The `signTypedData` function returned a hex string that contains each of these values, but to easily get these values individually, we're going to use Ethers' `Signature.from` function. This will create a new instance of Ether's [Signature class](https://docs.ethers.org/v6/api/crypto/#Signature){target=\_blank}, which will allow us to easily grab the `v`, `r`, and `s` values that we need in order to use the `dispatch` function.

```js
const formattedSignature = ethers.Signature.from(signature);
```

Now that we can individually access the `v`, `r`, and `s` arguments needed to dispatch the permit, we can call the `dispatch` function of the Call Permit Precompile. The arguments passed to the `dispatch` function must be the exact same arguments that were passed in for the `value` parameter of the `signTypedData` function. You'll send the following function using an account associated with your dApp as the signer (not the signer associated with the user), and it will dispatch the permit that the user signed:

```js
const dispatch = await callPermit.dispatch(
  message.from,
  message.to,
  message.value,
  message.data,
  message.gaslimit,
  message.deadline,
  formattedSignature.v,
  formattedSignature.r,
  formattedSignature.s,
);

await dispatch.wait();
console.log(`Transaction hash: ${dispatch.hash}`);
```

??? code "View the complete script"

    ```js
    import { ethers } from 'ethers';
import abi from './callPermitABI.js';
import cartographerAbi from './cartographerAbi.js';

const providerRPC = {
  moonbeam: {
    name: 'moonbeam',
    rpc: 'INSERT_RPC_API_ENDPOINT', // Insert your RPC URL here
    chainId: 1284, // 0x504 in hex,
  },
};
const provider = new ethers.JsonRpcProvider(providerRPC.moonbeam.rpc, {
  chainId: providerRPC.moonbeam.chainId,
  name: providerRPC.moonbeam.name,
});

// Insert your own signer logic or use the following for testing purposes.
// For demo purposes only. Never store your private keys in a JavaScript file
const userSigner = new ethers.Wallet('INSERT_PRIVATE_KEY', provider);
const thirdPartyGasSigner = new ethers.Wallet('INSERT_PRIVATE_KEY', provider);

const domain = {
  name: 'Call Permit Precompile',
  version: '1',
  chainId: 1284,
  verifyingContract: '0x000000000000000000000000000000000000080a',
};

const types = {
  CallPermit: [
    { name: 'from', type: 'address' },
    { name: 'to', type: 'address' },
    { name: 'value', type: 'uint256' },
    { name: 'data', type: 'bytes' },
    { name: 'gaslimit', type: 'uint64' },
    { name: 'nonce', type: 'uint256' },
    { name: 'deadline', type: 'uint256' },
  ],
};

const cartographerInterface = new ethers.Interface(cartographerAbi);
const data = cartographerInterface.encodeFunctionData('buyVoyages', [
  0n, // Voyage type: Easy
  1n, // Number of voyages to buy
  '0x72A33394f0652e2Bf15d7901f3Cd46863d968424', // Voyage V2 contract
]);

const gasEstimate = await provider.estimateGas({
  from: userSigner.address,
  to: '0xD1A9bA3e61Ac676f58B29EA0a09Cf5D7f4f35138', // Cartographer V1 contract
  data,
});

const callPermit = new ethers.Contract(
  '0x000000000000000000000000000000000000080a', // Call Permit contract
  abi,
  thirdPartyGasSigner
);

const nonce = await callPermit.nonces(userSigner.address);

const message = {
  from: userSigner.address,
  to: '0xD1A9bA3e61Ac676f58B29EA0a09Cf5D7f4f35138', // Cartographer V1 contract
  value: 0,
  data,
  gaslimit: gasEstimate + 50000n,
  nonce,
  deadline: '1714762357000', // Randomly created deadline in the future
};

const signature = await userSigner.signTypedData(domain, types, message);
console.log(`Signature hash: ${signature}`);

const formattedSignature = ethers.Signature.from(signature);

// This gets dispatched using the dApps signer
const dispatch = await callPermit.dispatch(
  message.from,
  message.to,
  message.value,
  message.data,
  message.gaslimit,
  message.deadline,
  formattedSignature.v,
  formattedSignature.r,
  formattedSignature.s
);

await dispatch.wait();
console.log(`Transaction hash: ${dispatch.hash}`);
    ```

    !!! remember
        Never store your private keys in a JavaScript or TypeScript file.

Once the transaction goes through, the gas fees will be deducted from the GLMR balance of the third-party account, 1 TMAP will be deducted from the user's balance, and a voyage will be purchased on behalf of the user. As you can see, the user doesn't need to worry about having a GLMR balance!

You can view the transaction for the example that we covered in this guide on [Moonscan](https://moonbeam.moonscan.io/tx/0x2c16f1257f69eaa14486f89cedf600c25c0335086b640f2225468a244f10588a){target=\_blank}. You'll notice the following:

- The `from` account is the third-party account: `0xd0ccb8d33530456f1d37e91a6ef5503b5dcd2ebc`
- The contract interacted with is the Call Permit Precompile: `{{ networks.moonbeam.precompiles.call_permit }}`
- A TMAP has been deducted from the user's account: `0xa165c7970886d4064b6cec9ab1db9d03202bda37`
- A voyage with ID 622646 has been sent to the user's account

![Review the transaction details](/images/tutorials/eth-api/call-permit-gasless-txs/gasless-3.webp)

And that's it! Congrats! You've learned how to implement gasless transactions using the Call Permit Precompile on Moonbeam. You can now adapt the logic in this tutorial for your own dApp!

<div class="page-disclaimer">
    This tutorial is for educational purposes only. As such, any contracts or code created in this tutorial should not be used in production.
</div>
<div class="page-disclaimer">
  The information presented herein has been provided by third parties and is made available solely for general information purposes. Moonbeam does not endorse any project listed and described on the Moonbeam Doc Website (https://docs.moonbeam.network/). Moonbeam Foundation does not warrant the accuracy, completeness or usefulness of this information. Any reliance you place on such information is strictly at your own risk. Moonbeam Foundation disclaims all liability and responsibility arising from any reliance placed on this information by you or by anyone who may be informed of any of its contents. All statements and/or opinions expressed in these materials are solely the responsibility of the person or entity providing those materials and do not necessarily represent the opinion of Moonbeam Foundation. The information should not be construed as professional or financial advice of any kind. Advice from a suitably qualified professional should always be sought in relation to any particular matter or circumstance. The information herein may link to or integrate with other websites operated or content provided by third parties, and such other websites may link to this website. Moonbeam Foundation has no control over any such other websites or their content and will have no liability arising out of or related to such websites or their content. The existence of any such link does not constitute an endorsement of such websites, the content of the websites, or the operators of the websites. These links are being provided to you only as a convenience and you release and hold Moonbeam Foundation harmless from any and all liability arising from your use of this information or the information provided by any third-party website or service.
</div>
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/tutorials/eth-api/chat-gpt/
--- BEGIN CONTENT ---
---
title: Use GPT-4 to Develop Smart Contracts
description: Learn how you can use OpenAI's ChatGPT (GPT-4) generative AI LLM to write, debug, and deploy Solidity smart contracts on the Moonbeam network.
categories: Tutorials
---

# Using GPT-4 to Write and Debug Solidity Smart Contracts

_by Kevin Neilson_

## Introduction {: #introduction }

Today, it's near impossible to walk down the street and not overhear a conversation about the transformative impact of generative AI. Of course, this applies to both the physical and virtual world (e.g., Twitter). You've probably heard by now that artificial intelligence tools like ChatGPT can plan your vacation, draft an essay, and tell you a joke. But did you know that ChatGPT can even write working Solidity code for you? And, it doesn't just return a `.sol` file to you without any context. It can actually explain to you how the code is structured, walk you through deployment steps, and, *drumroll*, even write your test files for you. Yup, that's right. No more excuses for a lack of test coverage when ChatGPT can take care of that for you.

In this tutorial, we'll look at how ChatGPT can help you write, deploy, and debug Solidity smart contracts. But first, let's dive a bit more into what ChatGPT is exactly.

## An Overview of ChatGPT {: #an-overview-of-chatgpt }

### What is ChatGPT? {: #what-is-chatgpt }

[ChatGPT](https://chatgpt.com/){target=\_blank} is a text-based Large Language Model (LLM) created by the company OpenAI. According to OpenAI, *"The dialogue format makes it possible for ChatGPT to answer followup questions, admit its mistakes, challenge incorrect premises, and reject inappropriate requests."* ChatGPT can hold a conversation with you and remember your chat history until a new session is started. To learn more about ChatGPT, check out [this introduction to ChatGPT on the OpenAI Blog](https://openai.com/index/chatgpt){target=\_blank}.

### GPT-4 vs. ChatGPT {: #gpt-4-vs-chatgpt }

As of the time of writing, GPT-4 was the latest version offered as part of the ChatGPT Plus subscription service, available at a cost of $20 USD per month. While GPT-4 is a paid service, you can follow this same tutorial using the free tiers of service available in earlier versions. GPT-4 is a significantly more advanced model, so you may notice differences in response quality from earlier versions, particularly in the model's reasoning at the debugging steps.

### Limitations {: #limitations }

- At the time of writing, ChatGPT is in a research preview state
- ChatGPT can sometimes hallucinate, that is, output convincing and plausible-sounding answers that are factually incorrect. In such cases, it typically will not warn you of the inaccuracy
- ChatGPT's knowledge date cutoff is approximately September 2021. It does not have access to current events or other data after this date
- Code produced by ChatGPT is not audited, reviewed, or verified and may contain errors
- Prompting GPT-4 with the exact inputs specified in this tutorial will likely produce different outputs - that is expected due to ChatGPT's architecture as a language model

![Limitations](/images/tutorials/eth-api/chatgpt/chatgpt-1.webp)

**Please note that the contracts we'll be creating today are for educational purposes only and should not be used in a production environment**.

## Checking Prerequisites {: #checking-prerequisites }

For this tutorial, you'll need the following:

- A free [OpenAI account to access ChatGPT](https://chatgpt.com/){target=\_blank}
- An account funded with DEV tokens to be used on the Moonbase Alpha TestNet if you'd like to deploy any resulting contracts.
  You can get DEV tokens for testing on Moonbase Alpha once every 24 hours from the [Moonbase Alpha Faucet](https://faucet.moonbeam.network){target=\_blank}

## Sign up for an OpenAI Account {: #sign-up-for-an-openai-account }

You can sign up for a free account to access ChatGPT by heading to [OpenAI's website.](https://chatgpt.com/auth/login){target=\_blank} You'll need to provide both an email address and a phone number. A subscription to ChatGPT Plus is not required to complete this tutorial.

![Sign up for OpenAI account](/images/tutorials/eth-api/chatgpt/chatgpt-2.webp)

## Create an ERC-20 Token Contract {: #create-an-erc-20-token-contract }

To start interacting with [ChatGPT](https://chatgpt.com/?model=gpt-4){target=\_blank}, take the following steps:

1. Press **New Chat** in the upper left hand corner
2. Select the model you would like to use. Either model is suitable for this tutorial
3. Enter your prompt and at the input box and press enter when ready

![Prompt chatGPT](/images/tutorials/eth-api/chatgpt/chatgpt-3.webp)

For our first prompt, we'll ask ChatGPT to create an ERC-20 token, specifying the name of the token, the token symbol, and an initial supply. Your prompt doesn't need to match the one below - feel free to tailor it to suit your preferences.

```text
I would like to create an ERC-20 token called "KevinToken" 
with the symbol "KEV" and an initial supply of 40000000.
```

![ChatGPT's 1st response](/images/tutorials/eth-api/chatgpt/chatgpt-4.webp)

This is a great start. ChatGPT has produced for us a simple yet functional ERC-20 token that meets all of the parameters that we have specified. It also clarified how it created the ERC-20 token contract using the [OpenZeppelin standard](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol){target=\_blank} and where the initial token supply is directed. Finally, it reminds us that this is just a start, and there may be other considerations we wish to implement, like minting and burning.

!!! note
    If you don't get the output you're expecting, you can always press **Regenerate Response** or re-phrase your request.

ChatGPT is perfectly happy to revise and expand upon the contract that was created. As long as you stay within the same chat window (i.e., don't click new chat), ChatGPT will be aware of its prior output. As an example, let's now ask ChatGPT to revise our token to be both mintable and burnable:

```text
This looks great, but I'd really like my ERC-20 to be both mintable and burnable. 
```

ChatGPT is happy to oblige. Notice how it maintains the parameters we specified originally, namely the token name and symbol.

![ChatGPT's 2nd response](/images/tutorials/eth-api/chatgpt/chatgpt-5.webp)

## Preparing Deployment Instructions {: #preparing-deployment-instructions }

This section is named carefully to avoid implying that ChatGPT will be doing the deployment for us. ChatGPT does not have internet access and cannot interact with blockchain networks directly, but it can give us detailed instructions explaining how we can do so ourselves. Let's ask ChatGPT for instructions on deploying the recently created ERC20 contract. For this example, let's ask ChatGPT for [Hardhat deployment instructions](/builders/ethereum/dev-env/hardhat/){target=\_blank}:

```text
I would like to use Hardhat to compile and deploy
 this smart contract to the Moonbase Alpha network.  
```

![ChatGPT's 3rd response](/images/tutorials/eth-api/chatgpt/chatgpt-6.webp)

And to no surprise, ChatGPT provides us with a detailed series of deployment steps, from installation instructions to a full deployment script. Note that it even remembers a detail in our first prompt that wasn't important until now. In our initial prompt, we asked for our token to have an initial supply of `400000000`, and ChatGPT included this parameter in the deployment script it generated.

Another observation is that the RPC URL it generated is outdated, although still functional. This oversight is due to ChatGPT's knowledge cutoff date of September 2021, before the updated RPC URL was published. The current RPC URL for Moonbase Alpha is:

```text
{{ networks.moonbase.rpc_url }}
```

!!! note
    ChatGPT's knowledge date cutoff is approximately September 2021. It does not have access to current events or other data after this date.

Code snippets of ChatGPT's output are intentionally omitted to encourage you to try this on your own! And remember, prompting it with the exact same instructions will yield at least slightly different results - this is [an inherent quality of LLMs](https://www.dataiku.com/stories/detail/generative-ai/){target=\_blank}.

## Writing Test Cases {: #writing-test-cases }

By now, you're nearly a ChatGPT savant. So it should come as no surprise that ChatGPT's capabilities extend to writing test cases for your smart contracts, and all you need to do is ask:

```text
Hey GPT4 can you help me write some tests for the smart contract above?  
```

![ChatGPT's 4th response](/images/tutorials/eth-api/chatgpt/chatgpt-7.webp)

ChatGPT provides us with a slew of test cases, especially surrounding the mint and burn functionality. While it's busy writing test cases, it appears to trail off and stop without its typical summary remarks at the end. This interruption stems from ChatGPT's 500-word limit. Although the 500-word limit is a hard stop, ChatGPT's train of thought continues, so you can simply ask it to continue, and it will happily oblige. Note that for subscriptions with limited messages, this will count as an additional message from your allocation.

!!! note
    ChatGPT has a response limit of approximately 500 words or 4,000 characters. However, you can simply ask it to continue in a follow up message.

![ChatGPT's 5th response](/images/tutorials/eth-api/chatgpt/chatgpt-8.webp)

And Voila! ChatGPT finishes writing its test cases for us and wraps up by telling us how we can run them.

## Debugging {: #debugging }

So far, we've covered that ChatGPT can write smart contracts for you AND help you deploy and test them. What's more, it can also help you debug your smart contracts. You can share your problems with ChatGPT, and it will help you find what's wrong.

If the problem is clear, ChatGPT will typically tell you exactly what's wrong and how to fix it. In other cases, where there could be multiple underlying reasons for the issue you're facing, ChatGPT will suggest a list of potential fixes.

If you try all of the steps it recommends and your issue persists, you can simply let ChatGPT know, and it will continue to help you troubleshoot. As a follow-up, it may ask you to provide code snippets or system configuration information to better help you solve the problem at hand.

[A reentrancy bug](https://web.archive.org/web/20221121064906/https://consensys.github.io/smart-contract-best-practices/attacks/reentrancy/){target=\_blank} was the root of the flaw that brought down the [original DAO on Ethereum in 2016](https://en.wikipedia.org/wiki/The_DAO){target=\_blank}. Let's prompt ChatGPT with a buggy function that includes a reentrancy vulnerability and see if ChatGPT is able to spot the problem. We'll go ahead and copy and paste the below insecure code snippet into ChatGPT and ask if there is anything wrong with it.

```solidity
// INSECURE
mapping (address => uint) private userBalances;

function withdrawBalance() public {
    uint amountToWithdraw = userBalances[msg.sender];
    (bool success, ) = msg.sender.call.value(amountToWithdraw)(""); // At this point, the caller's code is executed, and can call withdrawBalance again
    require(success);
    userBalances[msg.sender] = 0;
}
```

![ChatGPT's 6th response](/images/tutorials/eth-api/chatgpt/chatgpt-9.webp)

ChatGPT spots the exact error, explains the source of the problem, and lets us know how to fix it.

## Advanced Prompt Engineering {: #advanced-prompt-engineering }

[Prompt engineering](https://learn.microsoft.com/en-us/azure/ai-foundry/openai/concepts/prompt-engineering?tabs=chat){target=\_blank} is both an art and a science, and mastering it can help you get the most out of generative AI tools like ChatGPT. While not an exhaustive list, here are some general concepts that can help you write better prompts:

- Be specific and parameterize your request. The more detail you can provide to ChatGPT, the more closely the actual output will match what you desire
- Don't be afraid of revisions! You don't need to repeat the whole prompt, you can ask for just the change and ChatGPT will revise its prior output accordingly
- Consider repeating or rephrasing critical parts of the prompt. Some research has indicated that LLMs will emphasize components that you repeat. You can always finish a prompt by reiterating the most important concepts you'd like addressed

For more information, be sure to check out this post on [advanced prompt engineering](https://learn.microsoft.com/en-us/azure/ai-foundry/openai/concepts/advanced-prompt-engineering?pivots=programming-language-chat-completions){target=\_blank} from Microsoft.

## Conclusion {: #conclusion }

As you can see, ChatGPT can help you with just about every step of the smart contract development process. It can help you write, deploy, and debug your Solidity smart contracts for Moonbeam. Despite the powerful capabilities of LLMs like ChatGPT, it's clear that this is only the beginning of what the technology has to offer.

It's important to remember that ChatGPT can only act as an aid to a developer and cannot fulfill any sort of audit or review. Developers must be aware that generative AI tools like ChatGPT can produce inaccurate, buggy, or non-working code. Any code produced in this tutorial is for demonstration purposes only and should not be used in a production environment.  

<div class="page-disclaimer">
    This tutorial is for educational purposes only. As such, any contracts or code created in this tutorial should not be used in production.
</div>

<div class="page-disclaimer">
  The information presented herein has been provided by third parties and is made available solely for general information purposes. Moonbeam does not endorse any project listed and described on the Moonbeam Doc Website (https://docs.moonbeam.network/). Moonbeam Foundation does not warrant the accuracy, completeness or usefulness of this information. Any reliance you place on such information is strictly at your own risk. Moonbeam Foundation disclaims all liability and responsibility arising from any reliance placed on this information by you or by anyone who may be informed of any of its contents. All statements and/or opinions expressed in these materials are solely the responsibility of the person or entity providing those materials and do not necessarily represent the opinion of Moonbeam Foundation. The information should not be construed as professional or financial advice of any kind. Advice from a suitably qualified professional should always be sought in relation to any particular matter or circumstance. The information herein may link to or integrate with other websites operated or content provided by third parties, and such other websites may link to this website. Moonbeam Foundation has no control over any such other websites or their content and will have no liability arising out of or related to such websites or their content. The existence of any such link does not constitute an endorsement of such websites, the content of the websites, or the operators of the websites. These links are being provided to you only as a convenience and you release and hold Moonbeam Foundation harmless from any and all liability arising from your use of this information or the information provided by any third-party website or service.
</div>
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/tutorials/eth-api/foundry-start-to-end/
--- BEGIN CONTENT ---
---
title: Foundry Development Life Cycle from Start to End
description: Follow a step-by-step tutorial on how to use Foundry to build a project on Moonbeam, from writing smart contracts and tests to deploying on TestNet and MainNet.
categories: Tutorials, Dev Environments
---

# Using Foundry Start to End with Moonbeam

_by Jeremy Boetticher_

## Introduction {: #introduction }

Foundry has become an increasingly popular development environment for smart contracts because it requires only one language: Solidity. Moonbeam offers [introductory documentation on using Foundry](/builders/ethereum/dev-env/foundry/){target=\_blank} with Moonbeam networks, which is recommended to read to get an introduction to using Foundry. In this tutorial, we will dip our toes deeper into the library to get a more cohesive look at properly developing, testing, and deploying with Foundry.  

In this demonstration, we will deploy two smart contracts. One is a token, and the other will depend on that token. We will also write unit tests to ensure the contracts work as expected. To deploy them, we will write a script that Foundry will use to determine the deployment logic. Finally, we will verify the smart contracts on Moonbeam's blockchain explorer.

## Checking Prerequisites {: #checking-prerequisites }

To get started, you will need the following:

 - Have an account with funds.
  You can get DEV tokens for testing on Moonbase Alpha once every 24 hours from the [Moonbase Alpha Faucet](https://faucet.moonbeam.network){target=\_blank}
 - 
To test out the examples in this guide on Moonbeam or Moonriver, you will need to have your own endpoint and API key, which you can get from one of the supported [Endpoint Providers](/builders/get-started/endpoints/){target=\_blank}
 - Have [Foundry installed](https://getfoundry.sh/introduction/installation/){target=\_blank}
 - Have an [Etherscan API Key](/builders/ethereum/verify-contracts/api-verification/#generating-an-etherscan-api-key){target=\_blank}

## Create a Foundry Project {: #create-a-foundry-project }

The first step to start a Foundry project is, of course, to create it. If you have Foundry installed, you can run:

```bash
forge init foundry && cd foundry
```

This will have the `forge` utility initialize a new folder named `foundry` with a Foundry project initialized within it. The `script`, `src`, and `test` folders may have files in them already. Be sure to delete them, because we will be writing our own soon.  

From here, there are a few things to do first before writing any code. First, we want to add a dependency to [OpenZeppelin's smart contracts](https://github.com/OpenZeppelin/openzeppelin-contracts){target=\_blank}, because they include helpful contracts to use when writing token smart contracts. To do so, add them using their GitHub repository name:  

```bash
forge install OpenZeppelin/openzeppelin-contracts
```

This will add the OpenZeppelin git submodule to your `lib` folder. To be sure that this dependency is mapped, you can override the mappings in a special file, `remappings.txt`:  

```bash
forge remappings > remappings.txt
```

Every line in this file is one of the dependencies that can be referenced in the project's smart contracts. Dependencies can be edited and renamed so that it's easier to reference different folders and files when working on smart contracts. It should look similar to this with OpenZeppelin installed properly:

```text
ds-test/=lib/forge-std/lib/ds-test/src/
forge-std/=lib/forge-std/src/
openzeppelin-contracts/=lib/openzeppelin-contracts/
```

Finally, let's open up the `foundry.toml` file. In preparation for Etherscan verification and deployment, add this to the file:

```toml
[profile.default]
src = 'src'
out = 'out'
libs = ['lib']
solc_version = '0.8.20'

[rpc_endpoints]
moonbase = "{{ networks.moonbase.rpc_url }}"
moonbeam = "{{ networks.moonbeam.rpc_url }}"

[etherscan]
moonbase = { key = "${MOONSCAN_API_KEY}" }
moonbeam = { key = "${MOONSCAN_API_KEY}" }
```

The first addition is a specification of the `solc_version`, underneath `profile.default`. The `rpc_endpoints` tag allows you to define which RPC endpoints to use when deploying to a named network, in this case, Moonbase Alpha and Moonbeam. The `etherscan` tag allows you to add Etherscan API keys for smart contract verification, which we will review later.  

## Add Smart Contracts {: #add-smart-contracts-in-foundry }

Smart contracts in Foundry destined for deployment by default belong in the `src` folder. In this tutorial, we'll write two smart contracts. Starting with the token:

```bash
touch src/MyToken.sol
```

Open the file and add the following to it:

```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

// Import OpenZeppelin Contract
import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.sol";

// This ERC-20 contract mints the specified amount of tokens to the contract creator
contract MyToken is ERC20 {
    constructor(uint256 initialSupply) ERC20("MyToken", "MYTOK") {
        _mint(msg.sender, initialSupply);
    }

    // An external minting function allows anyone to mint as many tokens as they want
    function mint(uint256 toMint, address to) external {
        require(toMint <= 1 ether);
        _mint(to, toMint);
    }
}
```

As you can see, the OpenZeppelin `ERC20` smart contract is imported by the mapping defined in `remappings.txt`.

The second smart contract, which we'll name `Container.sol`, will depend on this token contract. It is a simple contract that holds the ERC-20 token we'll deploy. You can create the file by executing:  

```bash
touch src/Container.sol
```

Open the file and add the following to it:

```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

// Import OpenZeppelin Contract
import {MyToken} from "./MyToken.sol";

enum ContainerStatus {
    Unsatisfied,
    Full,
    Overflowing
}

contract Container {
    MyToken token;
    uint256 capacity;
    ContainerStatus public status;

    constructor(MyToken _token, uint256 _capacity) {
        token = _token;
        capacity = _capacity;
        status = ContainerStatus.Unsatisfied;
    }

    // Updates the status value based on the number of tokens that this contract has
    function updateStatus() public {
        address container = address(this);
        uint256 balance = token.balanceOf(container);
        if (balance < capacity) {
            status = ContainerStatus.Unsatisfied;
        } else if (balance == capacity) {
            status = ContainerStatus.Full;
        } else if (_isOverflowing(balance)) {
            status = ContainerStatus.Overflowing;
        }
    }

    // Returns true if the contract should be in an overflowing state, false if otherwise
    function _isOverflowing(uint256 balance) internal view returns (bool) {
        return balance > capacity;
    }
}
```

The `Container` smart contract can have its status updated based on how many tokens it holds and what its initial capacity value was set to. If the number of tokens it holds is above its capacity, its status can be updated to `Overflowing`. If it holds tokens equal to capacity, its status can be updated to `Full`. Otherwise, the contract will start and stay in the `Unsatisfied` state.  

`Container` requires a `MyToken` smart contract instance to function, so when we deploy it, we will need logic to ensure that it is deployed with a `MyToken` smart contract.  

## Write Tests {: #write-tests }

Before we deploy anything to a TestNet or MainNet, however, it's good to test your smart contracts. There are many types of tests:

- **Unit tests** — allow you to test specific parts of a smart contract's functionality. When writing your own smart contracts, it can be a good idea to break functionality into different sections so that it is easier to unit test
- **Fuzz tests** — allow you to test a smart contract with a wide variety of inputs to check for edge cases
- **Integration tests** — allow you to test a smart contract when it works in conjunction with other smart contracts, so that you know it works as expected in a deployed environment
    - **Forking tests** - integration tests that allows you to make a fork (a carbon copy of a network), so that you can simulate a series of transactions on a preexisting network

### Unit Tests in Foundry {: #unit-tests-in-foundry}

To get started with writing tests for this tutorial, make a new file in the `test` folder:  

```bash
cd test
touch MyToken.t.sol
```

By convention, all of your tests should end with `.t.sol` and start with the name of the smart contract that it is testing. In practice, the test can be stored anywhere and is considered a test if it has a function that starts with the word *"test"*.

Let's start by writing a test for the token smart contract. Open up `MyToken.t.sol` and add:  

```solidity
pragma solidity ^0.8.0;

import "forge-std/Test.sol";
import "../src/MyToken.sol";

contract MyTokenTest is Test {
    MyToken public token;

    // Runs before each test
    function setUp() public {
        token = new MyToken(100);
    }

    // Tests if minting during the constructor happens properly
    function testConstructorMint() public {
        assertEq(token.balanceOf(address(this)), 100);
    }
}
```

Let's break down what's happening here. The first line is typical for a Solidity file: setting the Solidity version. The next two lines are imports. `forge-std/Test.sol` is the standard library that Forge (and thus Foundry) includes to help with testing. This includes the `Test` smart contract, certain assertions, and [forge cheatcodes](https://getfoundry.sh/forge/tests/cheatcodes/){target=\_blank}.  

If you take a look at the `MyTokenTest` smart contract, you'll see two functions. The first is `setUp`, which is run before each test. So in this test contract, a new instance of `MyToken` is deployed every time a test function is run. You know if a function is a test function if it starts with the word *"test"*, so the second function, `testConstructorMint` is a test function.  

Great! Let's write some more tests, but for `Container`.  

```bash
touch Container.t.sol
```

And add the following:  

```solidity
// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.0;

import "forge-std/Test.sol";
import {MyToken} from "../src/MyToken.sol";
import {Container, ContainerStatus} from "../src/Container.sol";

contract ContainerTest is Test {
    MyToken public token;
    Container public container;

    uint256 constant CAPACITY = 100;

    // Runs before each test
    function setUp() public {
        token = new MyToken(1000);
        container = new Container(token, CAPACITY);
    }

    // Tests if the container is unsatisfied right after constructing
    function testInitialUnsatisfied() public {
        assertEq(token.balanceOf(address(container)), 0);
        assertTrue(container.status() == ContainerStatus.Unsatisfied);
    }

    // Tests if the container will be "full" once it reaches its capacity
    function testContainerFull() public {
        token.transfer(address(container), CAPACITY);
        container.updateStatus();

        assertEq(token.balanceOf(address(container)), CAPACITY);
        assertTrue(container.status() == ContainerStatus.Full);
    }
}
```

This test smart contract has two tests, so when running the tests, there will be two deployments of both `MyToken` and `Container`, for four smart contracts. You can run the following command to see the result of the test:  

```bash
forge test
```

When testing, you should see the following output:  

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>forge test</span>
    <span data-ty>[⠊] Compiling...</span>
    <span data-ty>No files changed, compilation skipped</span>
    <br>
    <span data-ty>Ran 1 test for test/MyToken.t.sol:MyTokenTest</span>
    <span data-ty>[PASS] testConstructorMint() (gas: 10651)</span>
    <span data-ty>Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 361.83µs (39.46µs CPU time)</span>
    <br>
    <span data-ty>Ran 2 tests for test/Container.t.sol:ContainerTest</span>
    <span data-ty>[PASS] testContainerFull() (gas: 73204)</span>
    <span data-ty>[PASS] testInitialUnsatisfied() (gas: 18476)</span>
    <span data-ty>Suite result: ok. 2 passed; 0 failed; 0 skipped; finished in 422.00µs (128.67µs CPU time)</span>
    <span data-ty>Ran 2 test suites in 138.17ms (783.83µs CPU time): 3 tests passed, 0 failed, 0 skipped (3 total tests)</span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>

### Test Harnesses in Foundry {: #test-harnesses-in-foundry }

Sometimes you'll want to unit test an `internal` function in a smart contract. To do so, you'll have to write a test harness smart contract, which inherits from the smart contract and exposes the internal function as a public one.  

For example, in `Container`, there is an internal function named `_isOverflowing`, which checks to see if the smart contract has more tokens than its capacity. To test this, add the following test harness smart contract to the `Container.t.sol` file:  

```solidity
contract ContainerHarness is Container {
    constructor(MyToken _token, uint256 _capacity) Container(_token, _capacity) {}

    function exposed_isOverflowing(uint256 balance) external view returns(bool) {
        return _isOverflowing(balance);
    }
}
```

Now, inside of the `ContainerTest` smart contract, you can add a new test that tests the previously unreachable `_isOverflowing` contract:  

```solidity
// Tests for negative cases of the internal _isOverflowing function
function testIsOverflowingFalse() public {
    ContainerHarness harness = new ContainerHarness(token , CAPACITY);
    assertFalse(harness.exposed_isOverflowing(CAPACITY - 1));
    assertFalse(harness.exposed_isOverflowing(CAPACITY));
    assertFalse(harness.exposed_isOverflowing(0));
}
```

Now, when you run the test with `forge test`, you should see that `testIsOverflowingFalse` passes!  

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>forge test</span>
    <span data-ty>[⠊] Compiling...</span>
    <span data-ty>[⠒] Compiling 1 files with 0.8.20</span>
    <span data-ty>[⠢] Solc 0.8.20 finished in 1.06s</span>
    <span data-ty>Compiler run successful</span>
    <br>
    <span data-ty>Ran 1 test for test/MyToken.t.sol:MyTokenTest</span>
    <span data-ty>[PASS] testConstructorMint() (gas: 10651)</span>
    <span data-ty>Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 498.00µs (48.96µs CPU time)</span>
    <br>
    <span data-ty>Ran 3 tests for test/Container.t.sol:ContainerTest</span>
    <span data-ty>[PASS] testContainerFull() (gas: 73238)</span>
    <span data-ty>[PASS] testInitialUnsatisfied() (gas: 18510)</span>
    <span data-ty>[PASS] testIsOverflowingFalse() (gas: 192130)</span>
    <span data-ty>Suite result: ok. 3 passed; 0 failed; 0 skipped; finished in 606.17µs (183.54µs CPU time)</span>
    <span data-ty>Ran 2 test suites in 138.29ms (1.10ms CPU time): 4 tests passed, 0 failed, 0 skipped (4 total tests)</span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>

### Fuzzing Tests in Foundry {: #fuzzing-tests-in-foundry}

When you write a unit test, you can only use so many inputs to test. You can test edge cases, a few select values, and perhaps one or two random ones. But when working with inputs, there are nearly an infinite amount of different ones to test! How can you be sure that they work for every value? Wouldn't you feel safer if you could test 10000 different inputs instead of less than 10?  

One of the best ways that developers can test many inputs is through fuzzing, or fuzz tests. Foundry automatically fuzz tests when an input in a test function is included. To illustrate this, add the following test to the `MyTokenTest` contract in `MyToken.t.sol`.  

```solidity
// Fuzz tests for success upon minting tokens one ether or below
function testMintOneEtherOrBelow(uint256 amountToMint) public {
    vm.assume(amountToMint <= 1 ether);

    token.mint(amountToMint, msg.sender);
    assertEq(token.balanceOf(msg.sender), amountToMint);
}
```

This test includes `uint256 amountToMint` as input, which tells Foundry to fuzz with `uint256` inputs! By default, Foundry will input 256 different inputs, but this can be configured with the [`FOUNDRY_FUZZ_RUNS` environment variable](https://getfoundry.sh/config/reference/testing/#runs){target=\_blank}.  

Additionally, the first line in the function uses `vm.assume` to only use inputs that are less than or equal to one ether since the `mint` function reverts if someone tries to mint more than one ether at a time. This cheatcode helps you direct the fuzzing into the right range.  

Let's look at another fuzzing test to put in the `MyTokenTest` contract, but this time where we expect to fail:  

```solidity
// Fuzz tests for failure upon minting tokens above one ether
function testFailMintAboveOneEther(uint256 amountToMint) public {
    vm.assume(amountToMint > 1 ether);
    
    token.mint(amountToMint, msg.sender);
}
```

In Foundry, when you want to test for a failure, instead of just starting your test function with the world *"test"*, you start it with *"testFail"*. In this test, we assume that the `amountToMint` is above one ether, which should fail!  

Now run the tests:  

```bash
forge test
```

You should see something similar to the following in the console:

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>forge test</span>
    <span data-ty>[⠊] Compiling...</span>
    <span data-ty>[⠊] Compiling 1 files with 0.8.20</span>
    <span data-ty>[⠒] Solc 0.8.20 finished in 982.65ms</span>
    <span data-ty>Compiler run successful</span>
    <br>
    <span data-ty>Ran 3 tests for test/Container.t.sol:ContainerTest</span>
    <span data-ty>[PASS] testContainerFull() (gas: 73238)</span>
    <span data-ty>[PASS] testInitialUnsatisfied() (gas: 18510)</span>
    <span data-ty>[PASS] testIsOverflowingFalse() (gas: 192130)</span>
    <span data-ty>Suite result: ok. 3 passed; 0 failed; 0 skipped; finished in 446.25µs (223.67µs CPU time)</span>
    <br>
    <span data-ty>Ran 3 tests for test/MyToken.t.sol:MyTokenTest</span>
    <span data-ty>[PASS] testConstructorMint() (gas: 10651)</span>
    <span data-ty>[PASS] testFailMintAboveOneEther(uint256) (runs: 256, μ: 8462, ~: 8462)</span>
    <span data-ty>[PASS] testMintOneEtherOrBelow(uint256) (runs: 256, μ: 37939, ~: 39270)</span>
    <span data-ty>Suite result: ok. 3 passed; 0 failed; 0 skipped; finished in 10.78ms (18.32ms CPU time)</span>
    <span data-ty>Ran 2 test suites in 138.88ms (11.23ms CPU time): 6 tests passed, 0 failed, 0 skipped (6 total tests)</span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>

### Forking Tests in Foundry {: #forking-tests-in-foundry}

In Foundry, you can locally fork a network so that you can test out how the contracts would work in an environment with already deployed smart contracts. For example, if someone deployed smart contract `A` on Moonbeam that required a token smart contract, you could fork the Moonbeam network and deploy your own token to test how smart contract `A` would react to it.  

!!! note
    Moonbeam's custom precompile smart contracts currently do not work in Foundry forks because precompiles are Substrate-based whereas typical smart contracts are completely based on the EVM. Learn more about [forking on Moonbeam](/builders/ethereum/dev-env/foundry/#forking-with-anvil){target=\_blank} and the [differences between Moonbeam and Ethereum](/learn/features/eth-compatibility/){target=\_blank}.

In this tutorial, you will test how your `Container` smart contract interacts with an already deployed `MyToken` contract on Moonbase Alpha

Let's add a new test function to the `ContainerTest` smart contract in `Container.t.sol` called `testAlternateTokenOnMoonbaseFork`:

```solidity
// Fork tests in the Moonbase Alpha environment
function testAlternateTokenOnMoonbaseFork() public {
    // Creates and selects a fork, returns a fork ID
    uint256 moonbaseFork = vm.createFork("moonbase");
    vm.selectFork(moonbaseFork);
    assertEq(vm.activeFork(), moonbaseFork);

    // Get token that's already deployed & deploys a container instance
    token = MyToken(0x359436610E917e477D73d8946C2A2505765ACe90);
    container = new Container(token, CAPACITY);

    // Mint tokens to the container & update container status
    token.mint(CAPACITY, address(container));
    container.updateStatus();

    // Assert that the capacity is full, just like the rest of the time
    assertEq(token.balanceOf(address(container)), CAPACITY);
    assertTrue(container.status() == ContainerStatus.Full);
}
```

The first step (and thus first line) in this function is to have the test function fork a network with `vm.createFork`. Recall that `vm` is a cheat code provided by the Forge standard library. All that's necessary to create a fork is an RPC URL, or an alias for an RPC URL that's stored in the `foundry.toml` file. In this case, we added an RPC URL for "moonbase" in [the setup step](#create-a-foundry-project), so in the test function we will just pass the word `"moonbase"`. This cheat code function returns an ID for the fork created, which is stored in an `uint256` and is necessary for activating the fork.  

On the second line, after the fork has been created, the environment will select and use the fork in the test environment with `vm.selectFork`. The third line just demonstrates that the current fork, retrieved with `vm.activeFork`, is the same as the Moonbase Alpha fork.  

The fourth line of code retrieves an already deployed instance of `MyToken`, which is what's so useful about forking: you can use contracts that are already deployed.  

The rest of the code tests capacity like you would expect a local test to. If you run the tests (with the `-vvvv` tag for extra logging), you'll see that it passes:  

```bash
forge test -vvvv
```

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>forge test</span>
    <span data-ty>[PASS] testIsOverflowingFalse() (gas: 192130)</span>
    <span data-ty>Traces:</span>
    <span data-ty>  [192130] ContainerTest::testIsOverflowingFalse()</span>
    <span data-ty>    ├─ [151256] → new ContainerHarness@0xF62849F9A0B5Bf2913b396098F7c7019b51A820a</span>
    <span data-ty>    │   └─ ← [Return] 522 bytes of code</span>
    <span data-ty>    ├─ [421] ContainerHarness::exposed_isOverflowing(99) [staticcall]</span>
    <span data-ty>    │   └─ ← [Return] false</span>
    <span data-ty>    ├─ [0] VM::assertFalse(false) [staticcall]</span>
    <span data-ty>    │   └─ ← [Return]</span>
    <span data-ty>    ├─ [421] ContainerHarness::exposed_isOverflowing(100) [staticcall]</span>
    <span data-ty>    │   └─ ← [Return] false</span>
    <span data-ty>    ├─ [0] VM::assertFalse(false) [staticcall]</span>
    <span data-ty>    │   └─ ← [Return]</span>
    <span data-ty>    ├─ [421] ContainerHarness::exposed_isOverflowing(0) [staticcall]</span>
    <span data-ty>    │   └─ ← [Return] false</span>
    <span data-ty>    ├─ [0] VM::assertFalse(false) [staticcall]</span>
    <span data-ty>    │   └─ ← [Return]</span>
    <span data-ty>    └─ ← [Stop]</span>
    <span data-ty>Suite result: ok. 4 passed; 0 failed; 0 skipped; finished in 2.07s (2.07s CPU time)</span>
    <span data-ty>Ran 2 test suites in 2.44s (2.08s CPU time): 7 tests passed, 0 failed, 0 skipped (7 total tests)</span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>

That's it for testing! You can find the complete `Container.t.sol` and `MyToken.t.sol` files below:

??? code "Container.t.sol"

    ```solidity
    // SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.0;

import "forge-std/Test.sol";
import {MyToken} from "../src/MyToken.sol";
import {Container, ContainerStatus} from "../src/Container.sol";

contract ContainerTest is Test {
    MyToken public token;
    Container public container;

    uint256 constant CAPACITY = 100;

    function setUp() public {
        token = new MyToken(1000);
        container = new Container(token, CAPACITY);
    }

    function testInitialUnsatisfied() public {
        assertEq(token.balanceOf(address(container)), 0);
        assertTrue(container.status() == ContainerStatus.Unsatisfied);
    }

    function testContainerFull() public {
        token.transfer(address(container), CAPACITY);
        container.updateStatus();

        assertEq(token.balanceOf(address(container)), CAPACITY);
        assertTrue(container.status() == ContainerStatus.Full);
    }

    function testIsOverflowingFalse() public {
        ContainerHarness harness = new ContainerHarness(token , CAPACITY);
        assertFalse(harness.exposed_isOverflowing(CAPACITY - 1));
        assertFalse(harness.exposed_isOverflowing(CAPACITY));
        assertFalse(harness.exposed_isOverflowing(0));
    }

    function testAlternateTokenOnMoonbaseFork() public {
        // Creates and selects a fork
        uint256 moonbaseFork = vm.createFork("moonbase");
        vm.selectFork(moonbaseFork);
        assertEq(vm.activeFork(), moonbaseFork);

        // Get token that's already deployed & deploys a container instance
        token = MyToken(0x93e1e9EC6c1A8736266A595EFe97B5673ea0fEAc);
        container = new Container(token, CAPACITY);

        // Mint tokens to the container & update container status
        token.mint(CAPACITY, address(container));
        container.updateStatus();

        // Assert that the capacity is full
        assertEq(token.balanceOf(address(container)), CAPACITY);
        assertTrue(container.status() == ContainerStatus.Full);
    }
}

contract ContainerHarness is Container {
    constructor(MyToken _token, uint256 _capacity) Container(_token, _capacity) {}

    function exposed_isOverflowing(uint256 balance) external view returns(bool) {
        return _isOverflowing(balance);
    }
}
    ```

??? code "MyToken.t.sol"

    ```solidity
    // SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.0;

import "forge-std/Test.sol";
import "../src/MyToken.sol";

contract MyTokenTest is Test {
    MyToken public token;

    function setUp() public {
        token = new MyToken(100);
    }

    function testConstructorMint() public {
        assertEq(token.balanceOf(address(this)), 100);
    }

    function testMintOneEtherOrBelow(uint256 amountToMint) public {
        vm.assume(amountToMint <= 1 ether);

        token.mint(amountToMint, msg.sender);
        assertEq(token.balanceOf(msg.sender), amountToMint);
    }

    function testFailMintAboveOneEther(uint256 amountToMint) public {
        vm.assume(amountToMint > 1 ether);
        
        token.mint(amountToMint, msg.sender);
    }
}
    ```

## Deploy in Foundry with Solidity Scripts {: #deploy-in-foundry-with-solidity-scripts }

Not only are tests in Foundry written in Solidity, the scripts are too! Like other developer environments, scripts can be written to help interact with deployed smart contracts or can help along a complex deployment process that would be difficult to do manually. Even though scripts are written in Solidity, they are never deployed to a chain. Instead, much of the logic is actually run off-chain, so don't worry about any additional gas costs for using Foundry instead of a JavaScript environment like Hardhat.  

### Deploy on Moonbase Alpha {: #deploy-on-moonbase-alpha }

In this tutorial, we will use Foundry's scripts to deploy the `MyToken` and `Container` smart contracts. To create the deployment scripts, create a new file in the `script` folder:  

```bash
cd script
touch Container.s.sol
```

By convention, scripts should end with `s.sol` and have a name similar to the script they relate to. In this case, we are deploying the `Container` smart contract, so we have named the script `Container.s.sol`, though it's not the end of the world if you use a more suitable or descriptive name.  

In this script, add:  

```solidity
// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

import "forge-std/Script.sol";
import {MyToken} from "../src/MyToken.sol";
import {Container} from "../src/Container.sol";

contract ContainerDeployScript is Script {
    // Runs the script; deploys MyToken and Container
    function run() external {
        vm.startBroadcast();

        // Make a new token
        MyToken token = new MyToken(1000);

        // Make a new container
        new Container(token, 500);

        vm.stopBroadcast();
    }
}
```

Let's break this script down. The first line is standard: declaring the solidity version. The imports include the two smart contracts you previously added, which will be deployed. This includes additional functionality to use in a script, including the `Script` contract.  

Now let's look at the logic in the contract. There is a single function, `run`, which is where the script logic is hosted. In this `run` function, the `vm` object is used often. This is where all of the Forge cheatcodes are stored, which determines the state of the virtual machine that the solidity is run in.  

In the first line within the `run` function, `vm.startBroadcast` starts a broadcast, which indicates that the following logic should take place on-chain. So when the `MyToken` and the `Container` contracts are instantiated with the `new` keyword, they are instantiated on-chain. The final line, `vm.stopBroadcast` ends the broadcast.  

Before we run this script, you'll need to set up your keystore by importing your private key. You can do this using the cast wallet import command as follows:

```bash
cast wallet import deployer --interactive
```

This will prompt you to:

1. Enter your private key
2. Enter a password to encrypt the keystore

The account will be saved as "deployer" in your keystore. You can then use this account name in the deployment commands. You'll be prompted for your keystore password when deploying contracts or sending transactions.

Now, your script and project should be ready for deployment! Use the following command to do so:  

```bash
forge script Container.s.sol:ContainerDeployScript --broadcast --verify -vvvv --legacy --rpc-url moonbase --account deployer
```

This command runs the `ContainerDeployScript` contract as a script. The `--broadcast` option tells Forge to allow broadcasting of transactions, the `--verify` option tells Forge to verify to Moonscan when deploying, `-vvvv` makes the command output verbose, and `--rpc-url moonbase` sets the network to what `moonbase` was set to in `foundry.toml`. The `--legacy` flag instructs Foundry to bypass EIP-1559. While all Moonbeam networks support EIP-1559, Foundry will refuse to submit the transaction to Moonbase and revert to a local simulation if you omit the `--legacy` flag. The `--account deployer` flag tells Foundry to use the "deployer" account from your keystore.

You should see something like this as output:  

<div id="termynal" data-termynal>
    <span data-ty>Script ran successfully.</span>
    <span data-ty>Setting up 1 EVM.</span>
    <span data-ty>Simulated On-chain Traces:</span>
    <span data-ty>  [488164] → new MyToken@0xAEe1a769b10d03a6CeB4D9DFd3aBB2EF807ee6aa</span>
    <span data-ty>    ├─ emit Transfer(from: 0x0000000000000000000000000000000000000000, to: 0x3B939FeaD1557C741Ff06492FD0127bd287A421e, value: 1000)</span>
    <span data-ty>    └─ ← [Return] 1980 bytes of code</span>
    <span data-ty>  [133238] → new Container@0xeb1Ff38A645Eae4E64dFb93772D8129F88E11Ab1</span>
    <span data-ty>    └─ ← [Return] 432 bytes of code</span>
    <span data-ty>Chain 1287</span>
    <span data-ty>Estimated gas price: 0.03125 gwei</span>
    <span data-ty>Estimated total gas used for script: 1670737</span>
    <span data-ty>Estimated amount required: 0.000208842125 ETH</span>
    <span data-ty>Sending transactions [0 - 0].</span>
    <span data-ty>⠁ [00:00:00] [#############################################################>-------------------------------------------------------------] 1/2 txes (0.7s)</span>
    <span data-ty>Waiting for receipts.</span>
    <span data-ty>⠉ [00:00:22] [#######################################################################################################################] 1/1 receipts (0.0s)</span>
    <span data-ty>moonbase</span>
    <span data-ty>✅  [Success]Hash: 0x2ad8994c12af74bdcb04873e13d97dc543a2fa7390c1e194732ab43ec828cb3b</span>
    <span data-ty>Contract Address: 0xAEe1a769b10d03a6CeB4D9DFd3aBB2EF807ee6aa</span>
    <span data-ty>Block: 6717135</span>
    <span data-ty>Paid: 0.000116937 ETH (935496 gas * 0.03125 gwei)</span>
    <span data-ty>Sending transactions [1 - 1].</span>
    <span data-ty>⠉ [00:00:23] [###########################################################################################################################] 2/2 txes (0.0s)</span>
    <span data-ty>Waiting for receipts.</span>
    <span data-ty>⠉ [00:00:21] [#######################################################################################################################] 1/1 receipts (0.0s)</span>
    <span data-ty>moonbase</span>
    <span data-ty>✅  [Success]Hash: 0x3bfb4cee2be4269badc57e0053d8b4d94d9d57d7936ecaa1e13ac1e2199f3b12</span>
    <span data-ty>Contract Address: 0xeb1Ff38A645Eae4E64dFb93772D8129F88E11Ab1</span>
    <span data-ty>Block: 6717137</span>
    <span data-ty>Paid: 0.000035502 ETH (284016 gas * 0.03125 gwei)</span>
    <span data-ty>ONCHAIN EXECUTION COMPLETE & SUCCESSFUL.</span>
    <span data-ty>Total Paid: 0.000152439 ETH (1219512 gas * avg 0.03125 gwei)</span>
</div>

You should be able to see that your contracts were deployed, and are verified on Moonscan! For example, this is where my [`Container.sol` contract was deployed](https://moonbase.moonscan.io/address/0xe8bf2e654d7c1c1ba8f55fed280ddd241e46ced9#code){target=\_blank}.  

The entire deployment script is available below:  

??? code "Container.s.sol"

    ```solidity
    // SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

import "forge-std/Script.sol";
import {MyToken} from "../src/MyToken.sol";
import {Container} from "../src/Container.sol";

contract ContainerDeployScript is Script {
    // Runs the script; deploys MyToken and Container
    function run() external {
        vm.startBroadcast();

        // Make a new token
        MyToken token = new MyToken(1000);

        // Make a new container
        new Container(token, 500);

        vm.stopBroadcast();
    }
}
    ```

### Deploy on Moonbeam MainNet {: #deploy-on-moonbeam-mainnet }

Let's say you're comfortable with your smart contracts and want to deploy on the Moonbeam MainNet! The process isn't too different from what was just done, you just have to change the command's rpc-url from `moonbase` to `moonbeam`, since you've already added Moonbeam MainNet's information in the `foundry.toml` file:

```bash
forge script Container.s.sol:ContainerDeployScript --broadcast --verify -vvvv --legacy --rpc-url moonbeam --account deployer
```

That's it! You've gone from nothing to a fully tested, deployed, and verified Foundry project. You can now adapt this so that you can use Foundry in your own projects!

<div class="page-disclaimer">
    This tutorial is for educational purposes only. As such, any contracts or code created in this tutorial should not be used in production.
</div>

<div class="page-disclaimer">
  The information presented herein has been provided by third parties and is made available solely for general information purposes. Moonbeam does not endorse any project listed and described on the Moonbeam Doc Website (https://docs.moonbeam.network/). Moonbeam Foundation does not warrant the accuracy, completeness or usefulness of this information. Any reliance you place on such information is strictly at your own risk. Moonbeam Foundation disclaims all liability and responsibility arising from any reliance placed on this information by you or by anyone who may be informed of any of its contents. All statements and/or opinions expressed in these materials are solely the responsibility of the person or entity providing those materials and do not necessarily represent the opinion of Moonbeam Foundation. The information should not be construed as professional or financial advice of any kind. Advice from a suitably qualified professional should always be sought in relation to any particular matter or circumstance. The information herein may link to or integrate with other websites operated or content provided by third parties, and such other websites may link to this website. Moonbeam Foundation has no control over any such other websites or their content and will have no liability arising out of or related to such websites or their content. The existence of any such link does not constitute an endorsement of such websites, the content of the websites, or the operators of the websites. These links are being provided to you only as a convenience and you release and hold Moonbeam Foundation harmless from any and all liability arising from your use of this information or the information provided by any third-party website or service.
</div>
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/tutorials/eth-api/hardhat-start-to-end/
--- BEGIN CONTENT ---
---
title: Hardhat Developer Workflow
description: Learn how to develop, test, and deploy smart contracts with Hardhat and how to take your contracts from a local development node to Moonbeam MainNet.
categories: Tutorials, Dev Environments
---

# Hardhat Developer Workflow

_by Kevin Neilson & Erin Shaben_

## Introduction {: #introduction }

In this tutorial, we'll walk through the [Hardhat development environment](https://hardhat.org){target=\_blank} in the context of launching a [pooled staking DAO contract](https://github.com/moonbeam-foundation/moonbeam-intro-course-resources/blob/main/delegation-dao-lesson-one/DelegationDAO.sol){target=\_blank}. We'll walk through the typical developer workflow in detail from start to finish.

We'll assemble the components of the staking DAO and compile the necessary contracts. Then, we'll build a test suite with a variety of test cases relevant to our staking DAO, and run it against a local development node. Finally, we'll deploy the staking DAO to both Moonbase Alpha and Moonbeam and verify the contracts via the [Hardhat Etherscan plugin](/builders/ethereum/verify-contracts/etherscan-plugins/#using-the-hardhat-etherscan-plugin){target=\_blank}. If this is your first time exploring Hardhat, you may wish to start with [the introduction to Hardhat guide](/builders/ethereum/dev-env/hardhat/){target=\_blank}.

<div class="intro-disclaimer">
  The information presented herein is for informational purposes only and has been provided by third parties. Moonbeam does not endorse any project listed and described on the Moonbeam docs website (https://docs.moonbeam.network/).
</div>

## Checking Prerequisites {: #checking-prerequisites }

To get started, you will need the following:

 - A Moonbase Alpha account funded with DEV.
  You can get DEV tokens for testing on Moonbase Alpha once every 24 hours from the [Moonbase Alpha Faucet](https://faucet.moonbeam.network){target=\_blank}
 - An [Etherscan API Key](/builders/ethereum/verify-contracts/etherscan-plugins/#generating-an-etherscan-api-key){target=\_blank}
 - For the [Testing section](#running-your-tests), you'll need to have [a local Moonbeam node up and running](/builders/get-started/networks/moonbeam-dev/){target=\_blank}
 - 
  To test out the examples in this guide on Moonbeam or Moonriver, you will need to have your own endpoint and API key, which you can get from one of the supported [Endpoint Providers](/builders/get-started/endpoints/){target=\_blank}

## Creating a Hardhat Project {: #creating-a-hardhat-project }

You will need to create a Hardhat project if you don't already have one. You can create one by completing the following steps:

1. Create a directory for your project

    ```bash
    mkdir stakingDAO && cd stakingDAO
    ```

2. Initialize the project which will create a `package.json` file

    ```bash
    npm init -y
    ```

3. Install Hardhat

    ```bash
    npm install hardhat@3.0.0-next.5
    ```

4. Create a project

    ```bash
    npx hardhat --init
    ```

    !!! note
        `npx` is used to run executables installed locally in your project. Although Hardhat can be installed globally, installing it locally in each project is recommended so that you can control the version on a project-by-project basis.

5. You'll be prompted with a series of questions to set up your project:

    - Choose where to initialize the project (default is current directory)
    - Confirm converting to ESM (required for Hardhat v3)
    - Select the type of project to initialize:
        - A TypeScript Hardhat project using Node Test Runner and Viem
        - A TypeScript Hardhat project using Mocha and Ethers.js

    For this example, you can choose either option based on your preference. If you choose the Mocha and Ethers.js option, you'll get a project structure with:
    
    - A sample contract in `contracts/Counter.sol`
    - A test file in `test/Counter.ts`
    - TypeScript configuration
    - Mocha and Ethers.js dependencies

    The project will be set up with all necessary dependencies and configurations for you to start developing.

<div id="termynal" data-termynal>
  <span data-ty="input"><span class="file-path"></span>npx hardhat init</span>
  <span data-ty>888&nbsp;&nbsp;&nbsp;&nbsp;888&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;888&nbsp;888&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;888</span>
  <span data-ty>888&nbsp;&nbsp;&nbsp;&nbsp;888&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;888&nbsp;888&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;888</span>
  <span data-ty>888&nbsp;&nbsp;&nbsp;&nbsp;888&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;888&nbsp;888&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;888</span>
  <span data-ty>8888888888&nbsp;&nbsp;8888b.&nbsp;&nbsp;888d888&nbsp;.d88888&nbsp;88888b.&nbsp;&nbsp;&nbsp;8888b.&nbsp;&nbsp;888888</span>
  <span data-ty>888&nbsp;&nbsp;&nbsp;&nbsp;888&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"88b&nbsp;888P"&nbsp;&nbsp;d88"&nbsp;888&nbsp;888&nbsp;"88b&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"88b&nbsp;888</span>
  <span data-ty>888&nbsp;&nbsp;&nbsp;&nbsp;888&nbsp;.d888888&nbsp;888&nbsp;&nbsp;&nbsp;&nbsp;888&nbsp;&nbsp;888&nbsp;888&nbsp;&nbsp;888&nbsp;.d888888&nbsp;888</span>
  <span data-ty>888&nbsp;&nbsp;&nbsp;&nbsp;888&nbsp;888&nbsp;&nbsp;888&nbsp;888&nbsp;&nbsp;&nbsp;&nbsp;Y88b&nbsp;888&nbsp;888&nbsp;&nbsp;888&nbsp;888&nbsp;&nbsp;888&nbsp;Y88b.</span>
  <span data-ty>888&nbsp;&nbsp;&nbsp;&nbsp;888&nbsp;"Y888888&nbsp;888&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"Y88888&nbsp;888&nbsp;&nbsp;888&nbsp;"Y888888&nbsp;&nbsp;"Y888</span>
    <br>
  <span data-ty>👷 Welcome to Hardhat v3.0.0-next.5 👷‍</span>
    <br>
  <span data-ty="input" data-ty-prompt="✔">&nbsp;Where would you like to initialize the project?</span>
  <span data-ty="input" data-ty-prompt="Please provide either a relative or an absolute path:">&nbsp;.</span>
  <span data-ty="input" data-ty-prompt="✔">&nbsp;Hardhat only supports ESM projects. Would you like to change "package.json" to turn your project into ESM? (Y/n) · true</span>
  <span data-ty="input" data-ty-prompt="?">&nbsp;What type of project would you like to initialize? …</span>
  <span data-ty>&nbsp;&nbsp;A TypeScript Hardhat project using Node Test Runner and Viem</span>
  <span data-ty="input" data-ty-prompt="❯">&nbsp;A TypeScript Hardhat project using Mocha and Ethers.js</span>
</div>


## Add Smart Contracts {: #add-smart-contracts }

The smart contract featured in this tutorial is more complex than the one in the [Introduction to Hardhat](/builders/ethereum/dev-env/hardhat/){target=\_blank} but the nature of the contract means it's perfect to demonstrate some of the advanced capabilities of Hardhat. [`DelegationDAO.sol`](https://github.com/moonbeam-foundation/moonbeam-intro-course-resources/blob/main/delegation-dao-lesson-one/DelegationDAO.sol){target=\_blank} is a pooled staking DAO that uses [`StakingInterface.sol`](/builders/ethereum/precompiles/features/staking/){target=\_blank} to autonomously delegate to a [collator](/learn/platform/glossary/#collators){target=\_blank} when it reaches a determined threshold. Pooled staking contracts such as [`DelegationDAO.sol`](https://github.com/moonbeam-foundation/moonbeam-intro-course-resources/blob/main/delegation-dao-lesson-one/DelegationDAO.sol){target=\_blank} allow delegators with less than the protocol minimum bond to join together to delegate their pooled funds and earn a share of staking rewards.

!!! note
    `DelegationDAO.sol` is unreviewed and unaudited. It is designed only for demonstration purposes and not intended for production use. It may contain bugs or logic errors that could result in loss of funds.

To get started, take the following steps:

1. Change to the contracts directory

    ```bash
    cd contracts
    ```

2. Create a new file called `DelegationDAO.sol`

    ```bash
    touch DelegationDAO.sol
    ```

3. Copy and paste the contents of [DelegationDAO.sol](https://raw.githubusercontent.com/moonbeam-foundation/moonbeam-intro-course-resources/main/delegation-dao-lesson-one/DelegationDAO.sol){target=\_blank} into `DelegationDAO.sol`

    ??? code "DelegationDAO.sol"
        ```solidity
        // SPDX-License-Identifier: GPL-3.0-only
// This is a PoC to use the staking precompile wrapper as a Solidity developer.
pragma solidity >=0.8.0;

import "./StakingInterface.sol";
import "@openzeppelin/contracts/access/AccessControl.sol";
import "@openzeppelin/contracts/utils/Address.sol";


contract DelegationDAO is AccessControl {

    // Role definition for contract members
    bytes32 public constant MEMBER = keccak256("MEMBER");

    // Auto-compounding percentage (100%)
    uint8 public constant AUTOCOMPOUNDING_PERCENT = 100;

    // Possible states for the DAO to be in:
    // COLLECTING: the DAO is collecting funds before creating a delegation once the minimum delegation stake has been reached
    // STAKING: the DAO has an active delegation
    // REVOKING: the DAO has scheduled a delegation revoke
    // REVOKED: the scheduled revoke has been executed
    enum daoState {
        COLLECTING,
        STAKING,
        REVOKING,
        REVOKED
    }

    // Current state that the DAO is in
    daoState public currentState;

    // Member stakes (doesnt include rewards, represents member shares)
    mapping(address => uint256) public memberStakes;

    // Total Staking Pool (doesnt include rewards, represents total shares)
    uint256 public totalStake;

    // The ParachainStaking wrapper at the known pre-compile address. This will be used to make
    // all calls to the underlying staking solution
    ParachainStaking public staking;

    // Minimum Delegation Amount
    uint256 public constant minDelegationStk = 5 ether;

    // Moonbeam Staking Precompile address
    address public constant stakingPrecompileAddress =
        0x0000000000000000000000000000000000000800;

    // The collator that this DAO is currently nominating
    address public target;

    // Event for a member deposit
    event deposit(address indexed _from, uint _value);

    // Event for a member withdrawal
    event withdrawal(address indexed _from, address indexed _to, uint _value);

    // Initialize a new DelegationDao dedicated to delegating to the given collator target.
    constructor(address _target, address admin) {
        // Directly grant roles
        _grantRole(DEFAULT_ADMIN_ROLE, admin);
        _grantRole(MEMBER, admin);

        //Sets the collator that this DAO nominating
        target = _target;

        // Initializes Moonbeam's parachain staking precompile
        staking = ParachainStaking(stakingPrecompileAddress);

        //Initialize the DAO state
        currentState = daoState.COLLECTING;
    }

    // Simple getter to return the target collator of the DAO
    function getTarget() public view returns (address) {
        return target;
    }

    // Grant a user the role of admin
    function grant_admin(
        address newAdmin
    ) public onlyRole(DEFAULT_ADMIN_ROLE) onlyRole(MEMBER) {
        grantRole(DEFAULT_ADMIN_ROLE, newAdmin);
        grantRole(MEMBER, newAdmin);
    }

    // Grant a user membership
    function grant_member(
        address newMember
    ) public onlyRole(DEFAULT_ADMIN_ROLE) {
        grantRole(MEMBER, newMember);
    }

    // Revoke a user membership
    function remove_member(
        address payable exMember
    ) public onlyRole(DEFAULT_ADMIN_ROLE) {
        revokeRole(MEMBER, exMember);
    }

    // Increase member stake via a payable function and automatically stake the added amount if possible
    function add_stake() external payable onlyRole(MEMBER) {
        if (currentState == daoState.STAKING) {
            // Sanity check
            if (!staking.isDelegator(address(this))) {
                revert("The DAO is in an inconsistent state.");
            }
            memberStakes[msg.sender] = memberStakes[msg.sender] + msg.value;
            totalStake = totalStake + msg.value;
            emit deposit(msg.sender, msg.value);
            staking.delegatorBondMore(target, msg.value);
        } else if (currentState == daoState.COLLECTING) {
            memberStakes[msg.sender] = memberStakes[msg.sender] + msg.value;
            totalStake = totalStake + msg.value;
            emit deposit(msg.sender, msg.value);
            if (totalStake < minDelegationStk) {
                return;
            } else {
                //initialiate the delegation and change the state
                staking.delegateWithAutoCompound(
                    target,
                    address(this).balance,
                    AUTOCOMPOUNDING_PERCENT,
                    staking.candidateDelegationCount(target),
                    staking.candidateAutoCompoundingDelegationCount(target),
                    staking.delegatorDelegationCount(address(this))
                );
                currentState = daoState.STAKING;
            }
        } else {
            revert("The DAO is not accepting new stakes in the current state.");
        }
    }

    // Function for a user to withdraw their stake
    function withdraw(address payable account) public onlyRole(MEMBER) {
        require(
            currentState != daoState.STAKING,
            "The DAO is not in the correct state to withdraw."
        );
        if (currentState == daoState.REVOKING) {
            bool result = execute_revoke();
            require(result, "Schedule revoke delay is not finished yet.");
        }
        if (
            currentState == daoState.REVOKED ||
            currentState == daoState.COLLECTING
        ) {
            //Sanity checks
            if (staking.isDelegator(address(this))) {
                revert("The DAO is in an inconsistent state.");
            }
            require(totalStake != 0, "Cannot divide by zero.");
            //Calculate the withdrawal amount including staking rewards
            uint amount = address(this).balance * memberStakes[msg.sender] / totalStake;
            require(
                check_free_balance() >= amount,
                "Not enough free balance for withdrawal."
            );
            Address.sendValue(account, amount);
            totalStake = totalStake - (memberStakes[msg.sender]);
            memberStakes[msg.sender] = 0;
            emit withdrawal(msg.sender, account, amount);
        }
    }

    // Schedule revoke, admin only
    function schedule_revoke() public onlyRole(DEFAULT_ADMIN_ROLE) {
        require(
            currentState == daoState.STAKING,
            "The DAO is not in the correct state to schedule a revoke."
        );
        staking.scheduleRevokeDelegation(target);
        currentState = daoState.REVOKING;
    }

    // Try to execute the revoke, returns true if it succeeds, false if it doesn't
    function execute_revoke() internal onlyRole(MEMBER) returns (bool) {
        require(
            currentState == daoState.REVOKING,
            "The DAO is not in the correct state to execute a revoke."
        );
        staking.executeDelegationRequest(address(this), target);
        if (staking.isDelegator(address(this))) {
            return false;
        } else {
            currentState = daoState.REVOKED;
            return true;
        }
    }

    // Check how much free balance the DAO currently has. It should be the staking rewards if the DAO state is anything other than REVOKED or COLLECTING.
    function check_free_balance()
        public
        view
        onlyRole(MEMBER)
        returns (uint256)
    {
        return address(this).balance;
    }

    // Change the collator target, admin only
    function change_target(
        address newCollator
    ) public onlyRole(DEFAULT_ADMIN_ROLE) {
        require(
            currentState == daoState.REVOKED ||
                currentState == daoState.COLLECTING,
            "The DAO is not in the correct state to change staking target."
        );
        target = newCollator;
    }

    // Reset the DAO state back to COLLECTING, admin only
    function reset_dao() public onlyRole(DEFAULT_ADMIN_ROLE) {
        currentState = daoState.COLLECTING;
    }

    // Override _setupRole to use grantRole as _setupRole does not exist in AccessControl anymore
    function _setupRole(bytes32 role, address account) internal virtual {
        grantRole(role, account);
    }
}
        ```

4. Create a new file called `StakingInterface.sol` in the `contracts` directory

    ```bash
    touch StakingInterface.sol
    ```

5. Copy and paste the contents of [StakingInterface.sol](https://raw.githubusercontent.com/moonbeam-foundation/moonbeam/master/precompiles/parachain-staking/StakingInterface.sol){target=\_blank} into `StakingInterface.sol`

    ??? code "StakingInterface.sol"

        ```solidity
        // SPDX-License-Identifier: GPL-3.0-only
pragma solidity >=0.8.3;

/// @dev The ParachainStaking contract's address.
address constant PARACHAIN_STAKING_ADDRESS = 0x0000000000000000000000000000000000000800;

/// @dev The ParachainStaking contract's instance.
ParachainStaking constant PARACHAIN_STAKING_CONTRACT = ParachainStaking(
    PARACHAIN_STAKING_ADDRESS
);

/// @author The Moonbeam Team
/// @title Pallet Parachain Staking Interface
/// @dev The interface through which solidity contracts will interact with Parachain Staking
/// We follow this same interface including four-byte function selectors, in the precompile that
/// wraps the pallet
/// @custom:address 0x0000000000000000000000000000000000000800
interface ParachainStaking {
    /// @dev Check whether the specified address is currently a staking delegator
    /// @custom:selector fd8ab482
    /// @param delegator the address that we want to confirm is a delegator
    /// @return A boolean confirming whether the address is a delegator
    function isDelegator(address delegator) external view returns (bool);

    /// @dev Check whether the specified address is currently a collator candidate
    /// @custom:selector d51b9e93
    /// @param candidate the address that we want to confirm is a collator andidate
    /// @return A boolean confirming whether the address is a collator candidate
    function isCandidate(address candidate) external view returns (bool);

    /// @dev Check whether the specifies address is currently a part of the active set
    /// @custom:selector 740d7d2a
    /// @param candidate the address that we want to confirm is a part of the active set
    /// @return A boolean confirming whether the address is a part of the active set
    function isSelectedCandidate(
        address candidate
    ) external view returns (bool);

    /// @dev Total points awarded to all collators in a particular round
    /// @custom:selector 9799b4e7
    /// @param round the round for which we are querying the points total
    /// @return The total points awarded to all collators in the round
    function points(uint256 round) external view returns (uint256);

    /// @dev Total points awarded to a specific collator in a particular round.
    /// A value of `0` may signify that no blocks were produced or that the storage for that round has been removed
    /// @custom:selector bfea66ac
    /// @param round the round for which we are querying the awarded points
    /// @param candidate The candidate to whom the points are awarded
    /// @return The total points awarded to the collator for the provided round
    function awardedPoints(
        uint32 round,
        address candidate
    ) external view returns (uint32);

    /// @dev The amount delegated in support of the candidate by the delegator
    /// @custom:selector a73e51bc
    /// @param delegator Who made this delegation
    /// @param candidate The candidate for which the delegation is in support of
    /// @return The amount of the delegation in support of the candidate by the delegator
    function delegationAmount(
        address delegator,
        address candidate
    ) external view returns (uint256);

    /// @dev Whether the delegation is in the top delegations
    /// @custom:selector 91cc8657
    /// @param delegator Who made this delegation
    /// @param candidate The candidate for which the delegation is in support of
    /// @return If delegation is in top delegations (is counted)
    function isInTopDelegations(
        address delegator,
        address candidate
    ) external view returns (bool);

    /// @dev Get the minimum delegation amount
    /// @custom:selector 02985992
    /// @return The minimum delegation amount
    function minDelegation() external view returns (uint256);

    /// @dev Get the CandidateCount weight hint
    /// @custom:selector a9a981a3
    /// @return The CandidateCount weight hint
    function candidateCount() external view returns (uint256);

    /// @dev Get the current round number
    /// @custom:selector 146ca531
    /// @return The current round number
    function round() external view returns (uint256);

    /// @dev Get the CandidateDelegationCount weight hint
    /// @custom:selector 2ec087eb
    /// @param candidate The address for which we are querying the nomination count
    /// @return The number of nominations backing the collator
    function candidateDelegationCount(
        address candidate
    ) external view returns (uint32);

    /// @dev Get the CandidateAutoCompoundingDelegationCount weight hint
    /// @custom:selector 905f0806
    /// @param candidate The address for which we are querying the auto compounding
    ///     delegation count
    /// @return The number of auto compounding delegations
    function candidateAutoCompoundingDelegationCount(
        address candidate
    ) external view returns (uint32);

    /// @dev Get the DelegatorDelegationCount weight hint
    /// @custom:selector 067ec822
    /// @param delegator The address for which we are querying the delegation count
    /// @return The number of delegations made by the delegator
    function delegatorDelegationCount(
        address delegator
    ) external view returns (uint256);

    /// @dev Get the selected candidates for the current round
    /// @custom:selector bcf868a6
    /// @return The selected candidate accounts
    function selectedCandidates() external view returns (address[] memory);

    /// @dev Whether there exists a pending request for a delegation made by a delegator
    /// @custom:selector 3b16def8
    /// @param delegator the delegator that made the delegation
    /// @param candidate the candidate for which the delegation was made
    /// @return Whether a pending request exists for such delegation
    function delegationRequestIsPending(
        address delegator,
        address candidate
    ) external view returns (bool);

    /// @dev Whether there exists a pending exit for candidate
    /// @custom:selector 43443682
    /// @param candidate the candidate for which the exit request was made
    /// @return Whether a pending request exists for such delegation
    function candidateExitIsPending(
        address candidate
    ) external view returns (bool);

    /// @dev Whether there exists a pending bond less request made by a candidate
    /// @custom:selector d0deec11
    /// @param candidate the candidate which made the request
    /// @return Whether a pending bond less request was made by the candidate
    function candidateRequestIsPending(
        address candidate
    ) external view returns (bool);

    /// @dev Returns the percent value of auto-compound set for a delegation
    /// @custom:selector b4d4c7fd
    /// @param delegator the delegator that made the delegation
    /// @param candidate the candidate for which the delegation was made
    /// @return Percent of rewarded amount that is auto-compounded on each payout
    function delegationAutoCompound(
        address delegator,
        address candidate
    ) external view returns (uint8);

    /// @dev Join the set of collator candidates
    /// @custom:selector 1f2f83ad
    /// @param amount The amount self-bonded by the caller to become a collator candidate
    /// @param candidateCount The number of candidates in the CandidatePool
    function joinCandidates(uint256 amount, uint256 candidateCount) external;

    /// @dev Request to leave the set of collator candidates
    /// @custom:selector b1a3c1b7
    /// @param candidateCount The number of candidates in the CandidatePool
    function scheduleLeaveCandidates(uint256 candidateCount) external;

    /// @dev Execute due request to leave the set of collator candidates
    /// @custom:selector 3867f308
    /// @param candidate The candidate address for which the pending exit request will be executed
    /// @param candidateDelegationCount The number of delegations for the candidate to be revoked
    function executeLeaveCandidates(
        address candidate,
        uint256 candidateDelegationCount
    ) external;

    /// @dev Cancel request to leave the set of collator candidates
    /// @custom:selector 9c76ebb4
    /// @param candidateCount The number of candidates in the CandidatePool
    function cancelLeaveCandidates(uint256 candidateCount) external;

    /// @dev Temporarily leave the set of collator candidates without unbonding
    /// @custom:selector a6485ccd
    function goOffline() external;

    /// @dev Rejoin the set of collator candidates if previously had called `goOffline`
    /// @custom:selector 6e5b676b
    function goOnline() external;

    /// @dev Request to bond more for collator candidates
    /// @custom:selector a52c8643
    /// @param more The additional amount self-bonded
    function candidateBondMore(uint256 more) external;

    /// @dev Request to bond less for collator candidates
    /// @custom:selector 60744ae0
    /// @param less The amount to be subtracted from self-bond and unreserved
    function scheduleCandidateBondLess(uint256 less) external;

    /// @dev Execute pending candidate bond request
    /// @custom:selector 2e290290
    /// @param candidate The address for the candidate for which the request will be executed
    function executeCandidateBondLess(address candidate) external;

    /// @dev Cancel pending candidate bond request
    /// @custom:selector b5ad5f07
    function cancelCandidateBondLess() external;

    /// @dev Make a delegation in support of a collator candidate
    /// @custom:selector 4b8bc9bf
    /// @param candidate The address of the supported collator candidate
    /// @param amount The amount bonded in support of the collator candidate
    /// @param autoCompound The percent of reward that should be auto-compounded
    /// @param candidateDelegationCount The number of delegations in support of the candidate
    /// @param candidateAutoCompoundingDelegationCount The number of auto-compounding delegations
    /// in support of the candidate
    /// @param delegatorDelegationCount The number of existing delegations by the caller
    function delegateWithAutoCompound(
        address candidate,
        uint256 amount,
        uint8 autoCompound,
        uint256 candidateDelegationCount,
        uint256 candidateAutoCompoundingDelegationCount,
        uint256 delegatorDelegationCount
    ) external;

    /// @dev Request to revoke an existing delegation
    /// @custom:selector 1a1c740c
    /// @param candidate The address of the collator candidate which will no longer be supported
    function scheduleRevokeDelegation(address candidate) external;

    /// @dev Bond more for delegators with respect to a specific collator candidate
    /// @custom:selector 0465135b
    /// @param candidate The address of the collator candidate for which delegation shall increase
    /// @param more The amount by which the delegation is increased
    function delegatorBondMore(address candidate, uint256 more) external;

    /// @dev Request to bond less for delegators with respect to a specific collator candidate
    /// @custom:selector c172fd2b
    /// @param candidate The address of the collator candidate for which delegation shall decrease
    /// @param less The amount by which the delegation is decreased (upon execution)
    function scheduleDelegatorBondLess(
        address candidate,
        uint256 less
    ) external;

    /// @dev Execute pending delegation request (if exists && is due)
    /// @custom:selector e98c8abe
    /// @param delegator The address of the delegator
    /// @param candidate The address of the candidate
    function executeDelegationRequest(
        address delegator,
        address candidate
    ) external;

    /// @dev Cancel pending delegation request (already made in support of input by caller)
    /// @custom:selector c90eee83
    /// @param candidate The address of the candidate
    function cancelDelegationRequest(address candidate) external;

    /// @dev Sets an auto-compound value for a delegation
    /// @custom:selector faa1786f
    /// @param candidate The address of the supported collator candidate
    /// @param value The percent of reward that should be auto-compounded
    /// @param candidateAutoCompoundingDelegationCount The number of auto-compounding delegations
    /// in support of the candidate
    /// @param delegatorDelegationCount The number of existing delegations by the caller
    function setAutoCompound(
        address candidate,
        uint8 value,
        uint256 candidateAutoCompoundingDelegationCount,
        uint256 delegatorDelegationCount
    ) external;

    /// @dev Fetch the total staked amount of a delegator, regardless of the
    /// candidate.
    /// @custom:selector e6861713
    /// @param delegator Address of the delegator.
    /// @return Total amount of stake.
    function getDelegatorTotalStaked(
        address delegator
    ) external view returns (uint256);

    /// @dev Fetch the total staked towards a candidate.
    /// @custom:selector bc5a1043
    /// @param candidate Address of the candidate.
    /// @return Total amount of stake.
    function getCandidateTotalCounted(
        address candidate
    ) external view returns (uint256);
}
        ```

6. `DelegationDAO.sol` relies on a couple of standard [OpenZeppelin](https://www.openzeppelin.com){target=\_blank} contracts. Add the library with the following command:

    ```bash
    npm install @openzeppelin/contracts
    ```

## Hardhat Configuration File {: #hardhat-configuration-file }

When setting up the `hardhat.config.js` file, we'll need to import a few plugins that we'll use throughout this guide. So to get started, we'll need the [Hardhat Toolbox plugin](https://hardhat.org/hardhat-runner/plugins/nomicfoundation-hardhat-toolbox){target=\_blank}, which conveniently bundles together Hardhat plugins that can be used to deploy and interact with contracts using Ethers, test contracts with Mocha and Chai, verify contracts with Etherscan, and more. You can run the following command to install the plugin:

```bash
npm install --save-dev @nomicfoundation/hardhat-toolbox 
```

If you're curious about additional Hardhat plugins, here is [a complete list of official Hardhat plugins](https://hardhat.org/hardhat-runner/plugins){target=\_blank}.

Hardhat 3 includes an encrypted secrets manager that makes handling sensitive information like private keys and API keys easier. This ensures you don't have to hardcode secrets in your source code or store them in plain text.

!!! note
    The encrypted secrets manager is only available in Hardhat 3 or higher. As of writing this guide, Hardhat 3 is in alpha. You can install the latest alpha version with:

    ```bash
    npm install hardhat@3.0.0-next.5
    ```

    For the latest releases and updates, check the [Hardhat releases page](https://github.com/NomicFoundation/hardhat/releases/).

To use encrypted secrets, you'll need to:

1. Install Hardhat 3 or later:
```bash
npm install hardhat@3.0.0-next.5
```

2. Set up your secrets using the keystore:

=== "Moonbeam"

    ```bash
    npx hardhat keystore set MOONBEAM_RPC_URL
    npx hardhat keystore set MOONBEAM_PRIVATE_KEY
    ```

=== "Moonriver"

    ```bash
    npx hardhat keystore set MOONRIVER_RPC_URL
    npx hardhat keystore set MOONRIVER_PRIVATE_KEY
    ```

=== "Moonbase Alpha"

    ```bash
    npx hardhat keystore set MOONBASE_RPC_URL
    npx hardhat keystore set MOONBASE_PRIVATE_KEY
    ```

=== "Moonbeam Dev Node"

    ```bash
    npx hardhat keystore set DEV_RPC_URL
    npx hardhat keystore set DEV_PRIVATE_KEY
    npx hardhat keystore set ALICE_PRIVATE_KEY
    npx hardhat keystore set BOB_PRIVATE_KEY
    ```

Then, update your configuration file to use the encrypted secrets:

=== "Moonbeam"

    ```js
    module.exports = {
      solidity: '0.8.20',
      networks: {
        moonbeam: {
          type: "http",
          chainType: "generic",
          url: configVariable("MOONBEAM_RPC_URL"),
          chainId: {{ networks.moonbeam.chain_id }}, // (hex: {{ networks.moonbeam.hex_chain_id }}),
          accounts: [configVariable("MOONBEAM_PRIVATE_KEY")],
        },
      },
    };
    ```

=== "Moonriver"

    ```js
    module.exports = {
      solidity: '0.8.20',
      networks: {
        moonriver: {
          type: "http",
          chainType: "generic",
          url: configVariable("MOONRIVER_RPC_URL"),
          chainId: {{ networks.moonriver.chain_id }}, // (hex: {{ networks.moonriver.hex_chain_id }}),
          accounts: [configVariable("MOONRIVER_PRIVATE_KEY")],
        },
      },
    };
    ```

=== "Moonbase Alpha"

    ```js
    module.exports = {
      solidity: '0.8.20',
      networks: {
        moonbase: {
          type: "http",
          chainType: "generic",
          url: configVariable("MOONBASE_RPC_URL"),
          chainId: {{ networks.moonbase.chain_id }}, // (hex: {{ networks.moonbase.hex_chain_id }}),
          accounts: [configVariable("MOONBASE_PRIVATE_KEY")],
        },
      },
    };
    ```

=== "Moonbeam Dev Node"

    ```js
    module.exports = {
      solidity: '0.8.20',
      networks: {
        dev: {
          type: "http",
          chainType: "generic",
          url: configVariable("DEV_RPC_URL"),
          chainId: 1281, // 0x501 in hex
          accounts: [
            configVariable("DEV_PRIVATE_KEY"),
            configVariable("ALICE_PRIVATE_KEY"), // Alice (Alith) account
            configVariable("BOB_PRIVATE_KEY")    // Bob (Baltathar) account
          ],
        },
      },
    };
    ```

For this example, you'll need to add your private keys for your two accounts on Moonbase Alpha. Since some of the testing will be done on a development node, you'll also need to add the private keys of two of the pre-funded development node accounts, which, for this example, we can use Alice and Bob. In addition, you'll add your Etherscan API key, which can be used for both Moonbase Alpha and Moonbeam.

```js
// 1. Import the Hardhat Toolbox plugin
require('@nomicfoundation/hardhat-toolbox');
require('@nomicfoundation/hardhat-ignition-ethers');

module.exports = {
  // 2. Specify the Solidity version
  solidity: '0.8.20',
  networks: {
    // 3. Add the Moonbase Alpha network specification
    moonbase: {
      type: "http",
      chainType: "generic",
      url: configVariable("MOONBASE_RPC_URL"),
      chainId: {{ networks.moonbase.chain_id }}, // {{ networks.moonbase.hex_chain_id }} in hex
      accounts: [configVariable("MOONBASE_PRIVATE_KEY")],
    },
    dev: {
      type: "http",
      chainType: "generic",
      url: configVariable("DEV_RPC_URL"),
      chainId: 1281, // 0x501 in hex
      accounts: [
        configVariable("DEV_PRIVATE_KEY"),
        configVariable("ALICE_PRIVATE_KEY"), // Alice (Alith) account
        configVariable("BOB_PRIVATE_KEY")    // Bob (Baltathar) account
      ],
    },
    moonbeam: {
      type: "http",
      chainType: "generic",
      url: configVariable("MOONBEAM_RPC_URL"),
      chainId: {{ networks.moonbeam.chain_id }}, // {{ networks.moonbeam.hex_chain_id }} in hex
      accounts: [configVariable("MOONBEAM_PRIVATE_KEY")],
    },
  },
  // 4. Set up your Etherscan API key for contract verification
  // Moonbeam and Moonbase Alpha use the same Etherscan API key
  etherscan: {
    apiKey: {
      moonbaseAlpha: configVariable("ETHERSCAN_API_KEY"),
      moonbeam: configVariable("ETHERSCAN_API_KEY"),
    },
  },
};
```

!!! note
    Any real funds sent to the Alice and Bob development accounts will be lost immediately.Take precautions never to send MainNet funds to exposed development accounts. The private keys for these accounts are:
    
    - Alice (Alith): `0x5fb92d6e98884f76de468fa3f6278f8807c48bebc13595d45af5bdc4da702133`
    - Bob (Baltathar): `0x8075991ce870b93a8870eca0c0f91913d12f47948ca0fd25b49c6fa7cdbeee8b`
    
    These accounts should only be used on the local development node and never on Moonbeam MainNet or Moonbase Alpha.

You're now ready to move on to compilation and testing.

## Compiling the Contract {: #compiling-the-contract }

Now that you have your Hardhat project set up with the encrypted secrets manager, you can proceed with compilation and testing. The project comes with a sample contract and test file that you can use to verify your setup.

### Compiling the Contract {: #compiling-the-contract }

To compile the sample contract, run:

```bash
npx hardhat compile
```

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>npx hardhat compile</span>
    <span data-ty>Compiled 8 Solidity files successfully (evm target: paris).</span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>

After compilation, an `artifacts` directory is created: it holds the bytecode and metadata of the contract, which are `.json` files. Adding this directory to your `.gitignore` is a good idea.

## Testing {: #testing }

A robust smart contract development workflow is complete with a testing suite. Hardhat has a number of tools that make it easy to write and run tests. In this section, you'll learn the basics of testing your smart contracts and some more advanced techniques.

Hardhat tests are typically written with Mocha and Chai. [Mocha](https://mochajs.org){target=\_blank} is a JavaScript testing framework and [Chai](https://www.chaijs.com){target=\_blank} is a BDD/TDD JavaScript assertion library. BDD/TDD stands for behavior and test-driven development respectively. Effective BDD/TDD necessitates writing your tests *before* writing your smart contract code. The structure of this tutorial doesn't strictly follow these guidelines, but you may wish to adopt these principles in your development workflow. Hardhat recommends using [Hardhat Toolbox](https://hardhat.org/hardhat-runner/docs/advanced/migrating-from-hardhat-waffle){target=\_blank}, a plugin that bundles everything you need to get started with Hardhat, including Mocha and Chai.

Because we will initially be running our tests on a local Moonbeam node, we need to specify Alice's address as the address of our target collator (Alice's account is the only collator for a local development node):

```text
0xf24FF3a9CF04c71Dbc94D0b566f7A27B94566cac
```

If instead you prefer to run your tests against Moonbase Alpha, you can choose the below collator, or [any other collator on Moonbase Alpha](https://apps.moonbeam.network/moonbase-alpha/staking){target=\_blank} you would like the DAO to delegate to:

```text
{{ networks.moonbase.staking.candidates.address1 }}
```

### Configuring the Test File {: #configuring-the-test-file }

To set up your test file, take the following steps:

1. Create a `tests` directory

    ```bash
    mkdir tests
    ```

2. Create a new file called `Dao.js`

    ```bash
    touch tests/Dao.js
    ```

3. Then copy and paste the contents below to set up the initial structure of your test file. Be sure to read the comments, as they can clarify the purpose of each line

    ```javascript
    // Import Ethers
    const { ethers } = require('hardhat');

    // Import Chai to use its assertion functions here
    const { expect } = require('chai');

    // Indicate Alice's address as the target collator on local development node
    const targetCollator = '0xf24FF3a9CF04c71Dbc94D0b566f7A27B94566cac';
    ```

### Deploying a Staking DAO for Testing {: #deploying-a-staking-dao-for-testing }

Before we can run any test cases we'll need to launch a staking DAO with an initial configuration. Our setup here is relatively simple - we'll be deploying a staking DAO with a single administrator (the deployer) and then adding a new member to the DAO. This simple setup is perfect for demonstration purposes, but it's easy to imagine more complex configurations you'd like to test, such as a scenario with 100 DAO members or one with multiple admins of the DAO.

Mocha's `describe` function enables you to organize your tests. Multiple `describe` functions can be nested together. It's entirely optional but can be useful, especially in complex projects with many test cases. You can read more about constructing tests and [getting started with Mocha](https://mochajs.org/#getting-started){target=\_blank} on the Mocha docs site.

We'll define a function called `deployDao` containing the setup steps for our staking DAO. To configure your test file, add the following snippet:

```javascript
// The describe function 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('Dao contract', function () {
  let wallet1, wallet2;

  before(async function () {
    // Get signers we defined in Hardhat config
    const signers = await ethers.getSigners();
    wallet1 = signers[0];
    wallet2 = signers[1];
  });

  async function deployDao() {
    const delegationDaoFactory = await ethers.getContractFactory(
      'DelegationDAO',
      wallet2
    );

    // Deploy the staking DAO and wait for the deployment transaction to be confirmed
    try {
      const deployedDao = await delegationDaoFactory.deploy(
        targetCollator,
        wallet2.address
      );
      await deployedDao.waitForDeployment(); // Wait for the transaction to be mined
      return { deployedDao };
    } catch (error) {
      console.error('Failed to deploy contract:', error);
      return null; // Return null to indicate failure
    }
  }
  // Insert additional tests here
}); 
```

### Writing your First Test Cases {: #writing-your-first-test-cases }

First, you'll create a subsection called `Deployment` to keep the test file organized. This will be nested within the `Dao contract` describe function. Next, you'll define your first test case by using the `it` Mocha function. This first test checks to see that the staking DAO correctly stores the address of the target collator.

Add the snippet below to the end of your `Dao contract` function.

```javascript
// You can nest calls to create subsections
describe('Deployment', function () {
  // Mocha's it function is used to define each of your tests. It receives the test name, and a callback function. If the callback function is async, Mocha will await it. Test case to check that the correct target collator is stored
  it('should store the correct target collator in the DAO', async function () {
    const deployment = await deployDao();
    if (!deployment || !deployment.deployedDao) {
      throw new Error('Deployment failed; DAO contract was not deployed.');
    }
    const { deployedDao } = deployment;

    // The expect function receives a value and wraps it in an assertion object.
    // This test will pass if the DAO stored the correct target collator
    expect(await deployedDao.getTarget()).to.equal(
      '0xf24FF3a9CF04c71Dbc94D0b566f7A27B94566cac'
    );
  });
  // The following test cases should be added here
});
```

Now, add another test case. When a staking DAO is launched, it shouldn't have any funds. This test verifies that is indeed the case. Go ahead and add the following test case to your `Dao.js` file:

```javascript
// Test case to check that the DAO has 0 funds at inception
it('should initially have 0 funds in the DAO', async function () {
  const { deployedDao } = await deployDao();
  // This test will pass if the DAO has no funds as expected before any contributions
  expect(await deployedDao.totalStake()).to.equal(0);
});
```

### Function Reverts {: #function-reverts }

Now, you'll implement a more complex test case with a slightly different architecture. In prior examples, you've verified that a function returns an expected value. In this one, you'll be verifying that a function reverts. You'll also change the caller's address to test an admin-only function.

In the [staking DAO contract](https://github.com/moonbeam-foundation/moonbeam-intro-course-resources/blob/main/delegation-dao-lesson-one/DelegationDAO.sol){target=\_blank}, only admins are authorized to add new members to the DAO. One could write a test that checks to see if the admin is authorized to add new members but a more important test is to ensure that *non-admins* can't add new members. To run this test case under a different account, you will ask for another address when you call `ethers.getSigners()` and specify the caller in the assertion with `connect(member1)`. Finally, after the function call you'll append `.to.be.reverted` to indicate that the test case is successful if the function reverts. And if it doesn't revert, it's a failed test!

```javascript
// Test case to check that non-admins cannot grant membership
it('should not allow non-admins to grant membership', async function () {
  const { deployedDao } = await deployDao();
  // Connect the non-admin wallet to the deployed contract
  const deployedDaoConnected = deployedDao.connect(wallet1);
  const tx = deployedDaoConnected.grant_member(
    '0x0000000000000000000000000000000000000000'
  );

  // Check that the transaction reverts, not specifying any particular reason
  await expect(tx).to.be.reverted;
});
```

### Signing Transactions from Other Accounts {: #signing-transactions-from-other-accounts }

For this example, you'll verify whether the newly added DAO member can call the `check_free_balance()` function of staking DAO, which has an access modifier such that only members can access it.

```javascript
// Test case to check that members can access member only functions
it('should only allow members to access member-only functions', async function () {
  const { deployedDao } = await deployDao();

  // Connect the wallet1 to the deployed contract and grant membership
  const deployedDaoConnected = deployedDao.connect(wallet2);
  const grantTx = await deployedDaoConnected.grant_member(wallet1.address);
  await grantTx.wait();

  // Check the free balance using the member's credentials
  const checkTx = deployedDaoConnected.check_free_balance();

  // Since check_free_balance() does not modify state, we expect it not to be reverted and check the balance
  await expect(checkTx).to.not.be.reverted;
  expect(await checkTx).to.equal(0);
});
```

And that's it! You're now ready to run your tests!

### Running your Tests {: #running-your-tests }

If you've followed all of the prior sections, your [`Dao.js`](https://raw.githubusercontent.com/moonbeam-foundation/moonbeam-intro-course-resources/main/delegation-dao-lesson-one/Dao.js){target=\_blank} test file should be all set to go.

??? code "Dao.js"

    ```js
    // Import Ethers
const { ethers } = require('hardhat');
// Import Chai to use its assertion functions here
const { expect } = require('chai');

// Indicate the collator the DAO wants to delegate to
// For Moonbase Local Node, use: 0xf24FF3a9CF04c71Dbc94D0b566f7A27B94566cac
// For Moonbase Alpha, use: 0x12E7BCCA9b1B15f33585b5fc898B967149BDb9a5
const targetCollator = 'INSERT_COLLATOR_ADDRESS';

// The describe function 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('Dao contract', function () {
  let wallet1, wallet2;

  before(async function () {
    // Get signers we defined in Hardhat config
    const signers = await ethers.getSigners();
    wallet1 = signers[0];
    wallet2 = signers[1];
  });

  async function deployDao() {
    const delegationDaoFactory = await ethers.getContractFactory(
      'DelegationDAO',
      wallet2
    );

    // Deploy the staking DAO and wait for the deployment transaction to be confirmed
    try {
      const deployedDao = await delegationDaoFactory.deploy(
        targetCollator,
        wallet2.address
      );
      await deployedDao.waitForDeployment(); // Correct way to wait for the transaction to be mined
      return { deployedDao };
    } catch (error) {
      console.error('Failed to deploy contract:', error);
      return null; // Return null to indicate failure
    }
  }

  describe('Deployment', function () {
    // Test case to check that the correct target collator is stored
    it('should store the correct target collator in the DAO', async function () {
      const deployment = await deployDao();
      if (!deployment || !deployment.deployedDao) {
        throw new Error('Deployment failed; DAO contract was not deployed.');
      }
      const { deployedDao } = deployment;
      expect(await deployedDao.getTarget()).to.equal(
        '0xf24FF3a9CF04c71Dbc94D0b566f7A27B94566cac'
      );
    });

    // Test case to check that the DAO has 0 funds at inception
    it('should initially have 0 funds in the DAO', async function () {
      const { deployedDao } = await deployDao();
      expect(await deployedDao.totalStake()).to.equal(0);
    });

    // Test case to check that non-admins cannot grant membership
    it('should not allow non-admins to grant membership', async function () {
      const { deployedDao } = await deployDao();
      // Connect the non-admin wallet to the deployed contract
      const deployedDaoConnected = deployedDao.connect(wallet1);
      const tx = deployedDaoConnected.grant_member(
        '0x0000000000000000000000000000000000000000'
      );

      // Check that the transaction reverts, not specifying any particular reason
      await expect(tx).to.be.reverted;
    });

    // Test case to check that members can access member only functions
    it('should only allow members to access member-only functions', async function () {
      const { deployedDao } = await deployDao();

      // Connect the wallet1 to the deployed contract and grant membership
      const deployedDaoConnected = deployedDao.connect(wallet2);
      const grantTx = await deployedDaoConnected.grant_member(wallet1.address);
      await grantTx.wait();

      // Check the free balance using the member's credentials
      const checkTx = deployedDaoConnected.check_free_balance();

      // Since check_free_balance() does not modify state, we expect it not to be reverted and check the balance
      await expect(checkTx).to.not.be.reverted;
      expect(await checkTx).to.equal(0);
    });
  });
});
    ```

Since our test cases encompass mostly configuration and setup of the staking DAO and don't involve actual delegation actions, we'll be running our tests on a Moonbeam development node (local node). Remember that Alice (`0xf24FF3a9CF04c71Dbc94D0b566f7A27B94566cac`) is the only collator on a local development node. You can use the flag `--network moonbase` to run the tests using Moonbase Alpha. In that case, ensure your deployer address is sufficiently funded with DEV tokens.

!!! challenge
    Try to create an additional test case that verifies the staking DAO successfully delegates to a collator once `minDelegationStk` is met. You must test this on Moonbase Alpha rather than a local development node.

First, make sure that your local Moonbeam node is running by following the [instructions for launching a local development node](/builders/get-started/networks/moonbeam-dev/){target=\_blank}. Take precautions because you could inadvertently send real funds to the Alice and Bob development accounts, resulting in a loss of those funds.  

You can run your tests with the following command:

```bash
npx hardhat test --network dev tests/Dao.js
```

If everything was set up correctly, you should see output like the following:

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>npx hardhat test --network dev tests/Dao.js</span>
    <br>
    <br>
    <span data-ty>Dao contract</span>
    <span data-ty>     Deployment</span>
    <span data-ty> ✅ The DAO should store the correct target collator (1624ms)</span>
    <span data-ty> ✅ The DAO should initially have 0 funds in it</span>
    <span data-ty> ✅ Non-admins should not be able to grant membership (150ms)</span>
    <span data-ty> ✅ DAO members should be able to access member only functions (132ms)</span>
    <br>
    <br>
    <span data-ty> ✅ 4 passing (2s)</span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>

## Deploying to Moonbase Alpha {: #deploying-to-moonbase-alpha }

In the following steps, we'll deploy the `DelegationDAO` to the Moonbase Alpha TestNet. Before deploying to Moonbase Alpha or Moonbeam, double-check that you're not using the Alice and Bob accounts, which should only be used on a local development node.

As a side note, `DelegationDAO` relies on [`StakingInterface.sol`](/builders/ethereum/precompiles/features/staking/){target=\_blank}, which is a Substrate-based offering unique to Moonbeam networks. The Hardhat Network and forked networks are simulated EVM environments which do not include the Substrate-based precompiles like `StakingInterface.sol`. Therefore, `DelegationDAO` will not work properly if deployed to the local default Hardhat Network or a [forked network](/builders/ethereum/dev-env/hardhat/#forking-moonbeam){target=\_blank}.

To deploy `DelegationDAO`, you'll use Hardhat Ignition, a declarative framework for deploying smart contracts. Hardhat Ignition is designed to make managing recurring tasks surrounding smart contract deployment and testing easy. For more information about Hardhat Ignition and its architecture, be sure to check out the [Hardhat Ignition docs](https://hardhat.org/ignition/docs/getting-started#overview){target=\_blank}.

To set up the proper file structure for your Ignition module, change to the ignition directory and create the DelegationDao.js file:

```sh
cd ignition/modules && touch DelegationDao.js
```

Next, you can write your Hardhat Ignition module. To get started, take the following steps:

1. Import the `buildModule` function from the Hardhat Ignition module
2. Export a module using `buildModule`
3. Specify the target collator candidate for the DAO to delegate to
4. Use the `getAccount` method to select the deployer account
5. Deploy `DelegationDAO.sol`
6. Return an object from the module. This makes the `DelegationDao` contract accessible for interaction in Hardhat tests and scripts

When all is said and done your deployment script should look similar to the following:

```javascript
// 1. Import the required function from the Hardhat Ignition module
import { buildModule } from '@nomicfoundation/hardhat-ignition/modules';

// 2. Define and export your deployment module using `buildModule`
const DelegationDAOModule = buildModule('DelegationDAOModule', (m) => {
  // 3. Specify the target collator address for the DAO
  const targetCollator = '0x12E7BCCA9b1B15f33585b5fc898B967149BDb9a5';
  
  // 4. Use the `getAccount` method to select the deployer account
  const deployer = m.getAccount(0);
  
  // 5. Deploy the `DelegationDAO` contract
  const delegationDao = m.contract(
    'DelegationDAO',
    [targetCollator, deployer],
    {
      from: deployer,
    }
  );
  
  // 6. Return an object from the module including references to deployed contracts, allowing the contract to be accessible for interaction in Hardhat tests and scripts
  return { delegationDao };
});

// Export the module as default
export default DelegationDAOModule;
```

To run the script and deploy the `DelegationDAO.sol` contract, use the following command, which requires you to specify the network name as defined in your `hardhat.config.js`. If you don't specify a network, Hardhat will deploy the contract to a local Hardhat network by default. 

```sh
npx hardhat ignition deploy ./DelegationDao.js --network moonbase --deployment-id INSERT_YOUR_NAME
```

You'll be prompted to confirm the network you wish to deploy to. After a few seconds after you confirm, the contract is deployed, and you'll see the contract address in the terminal.

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span> npx hardhat ignition deploy ./DelegationDao.js --network moonbase --deployment-id INSERT_YOUR_NAME</span>
    <br>
    <span data-ty>✅ Confirm deploy to network moonbase (1287)? … yes</span>
    <span data-ty>Hardhat Ignition 🚀</span>
    <br>
    <span data-ty>Deploying [ DelegationDAOModule ]</span>
    <br>
    <span data-ty>Batch #1</span>
    <span data-ty>Executed DelegationDAOModule#DelegationDAO</span>
    <br>
    <span data-ty>[ DelegationDAOModule ] successfully deployed 🚀</span>
    <br>
    <span data-ty>Deployed Addresses</span>
    <br>
    <span data-ty>DelegationDAOModule#DelegationDAO - 0x69c555fE1A8D0916E6dab0629bd7530D4d2Be4D1</span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>

Congratulations, your contract is live on Moonbase Alpha! Save the address, as you will use it to interact with this contract instance in the next step.

## Verifying Contracts on Moonbase Alpha {: #verifying-contracts-on-moonbase-alpha }

Contract verification is an essential step of any developer's workflow, particularly in the theoretical example of this staking DAO. Potential participants in the DAO need to be assured that the smart contract works as intended - and verifying the contract allows anyone to observe and analyze the deployed smart contract.

While it's possible to verify smart contracts on the [Moonscan website](https://moonscan.io/verifyContract){target=\_blank}, the Hardhat Etherscan plugin enables us to verify our staking DAO in a faster and easier manner. It's not an exaggeration to say that the plugin dramatically simplifies the contract verification process, especially for projects that include multiple Solidity files or libraries.

Before beginning the contract verification process, you'll need to [acquire an Etherscan API Key](/builders/ethereum/verify-contracts/etherscan-plugins/#generating-an-etherscan-api-key){target=\_blank}. Note that Moonbeam, Moonriver, and Moonbase Alpha all use the same unified [Etherscan](https://etherscan.io){target=\_blank} API key.

To verify the contract, you will run the `ignition verify` command and pass the name of your deployment you set in the prior step.

```bash
npx hardhat ignition verify INSERT_YOUR_NAME
```

!!! note
    If you're deploying `DelegationDAO.sol` verbatim without any changes, you may get an `Already Verified` error because Moonscan automatically recognizes and verifies smart contracts that have matching bytecode. Your contract will still show as verified, so there is nothing else you need to do. However, if you'd prefer to verify your own `DelegationDAO.sol`, you can make a small change to the contract (such as changing a comment) and repeating the compilation, deployment and verification steps.

In your terminal, you should see the source code for your contract was successfully submitted for verification. If the verification was successful, you should see **Successfully verified contract** and there will be a link to the contract code on [Moonscan for Moonbase Alpha](https://moonbase.moonscan.io){target=\_blank}. If the plugin returns an error, double check that your API key is configured correctly and that you have specified all necessary parameters in the verification command. You can refer to the [guide to the Hardhat Etherscan plugin](/builders/ethereum/verify-contracts/etherscan-plugins/){target=\_blank} for more information.

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span> npx hardhat ignition verify INSERT_YOUR_NAME</span>
    <br>
    <span data-ty>Nothing to compile</span>
    <span data-ty>Successfully submitted source code for contract
contracts/DelegationDAO.sol:DelegationDAO at 0x5D788B98E4A90F9642352B0b32694998e77cF4d7 for verification on the block explorer. Waiting for verification result...</span>
    <br>
    <span data-ty>Successfully verified contract DelegationDAO on Etherscan.</span>
    <br>
    <span data-ty>https://moonbase.moonscan.io/address/0x5D788B98E4A90F9642352B0b32694998e77cF4d7#code</span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>


## Deploying to Production on Moonbeam Mainnet {: #deploying-to-production-on-moonbeam-mainnet }

!!! note
    `DelegationDAO.sol` is unreviewed and unaudited. It is designed only for demonstration purposes and not intended for production use. It may contain bugs or logic errors that could result in loss of funds.

In the following steps, we'll be deploying the `DelegationDAO` contract to the Moonbeam MainNet network. Remember to add the Moonbeam network to your [`hardhat.config.js`](#hardhat-configuration-file) and update the private keys of your accounts on Moonbeam if you haven't done so already. Before deploying `DelegationDAO` to Moonbeam, we need to change the address of the target collator, since our target collator on Moonbase Alpha does not exist on Moonbeam. Head to your deploy script and change the target collator to `{{ networks.moonbeam.staking.candidates.address1 }}` or [another Moonbeam collator](https://apps.moonbeam.network/moonbeam/staking){target=\_blank} of your choice. Your deployment script, named `DelegationDao.js`, should thus look like the following:

```javascript
// 1. Import the required function from the Hardhat Ignition module
import { buildModule } from '@nomicfoundation/hardhat-ignition/modules';

// 2. Define and export your deployment module using `buildModule`
const DelegationDAOModule = buildModule('DelegationDAOModule', (m) => {
  // 3. Specify the target collator address for the DAO
  const targetCollator = '0x1C86E56007FCBF759348dcF0479596a9857Ba105';
  
  // 4. Use the `getAccount` method to select the deployer account
  const deployer = m.getAccount(0);
  
  // 5. Deploy the `DelegationDAO` contract
  const delegationDao = m.contract(
    'DelegationDAO',
    [targetCollator, deployer],
    {
      from: deployer,
    }
  );
  
  // 6. Return an object from the module including references to deployed contracts, allowing the contract to be accessible for interaction in Hardhat tests and scripts
  return { delegationDao };
});

// Export the module as default
export default DelegationDAOModule;

```

To run the script and deploy the `DelegationDAO.sol` contract, use the following command, which requires you to specify the network name as defined in your `hardhat.config.js`. If you don't specify a network, Hardhat will deploy the contract to a local Hardhat network by default. 

```sh
npx hardhat ignition deploy ./ignition/modules/DelegationDao.js --network moonbeam --deployment-id INSERT_YOUR_NAME
```

You'll be prompted to confirm the network you wish to deploy to. After a few seconds after you confirm, the contract is deployed, and you'll see the contract address in the terminal.

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span> npx hardhat ignition deploy ./DelegationDao.js --network moonbeam --deployment-id INSERT_YOUR_NAME</span>
    <br>
    <span data-ty>✅ Confirm deploy to network moonbeam (1284)? … yes</span>
    <span data-ty>Hardhat Ignition 🚀</span>
    <br>
    <span data-ty>Deploying [ DelegationDAOModule ]</span>
    <br>
    <span data-ty>Batch #1</span>
    <span data-ty>Executed DelegationDAOModule#DelegationDAO</span>
    <br>
    <span data-ty>[ DelegationDAOModule ] successfully deployed 🚀</span>
    <br>
    <span data-ty>Deployed Addresses</span>
    <br>
    <span data-ty>DelegationDAOModule#DelegationDAO - 0x6D895A55F5ba31e582bCEe71cae394266F240e9b</span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>

Congratulations, your contract is live on Moonbeam! Save the address, as you will use it to interact with this contract instance in the next step.

## Verifying Contracts on Moonbeam {: #verifying-contracts-on-moonbeam }

In this section, we'll be verifying the contract that was just deployed on Moonbeam. Before beginning the contract verification process, you'll need to [acquire an Etherscan API Key](/builders/ethereum/verify-contracts/etherscan-plugins/#generating-an-etherscan-api-key){target=\_blank}. Note that Moonbeam, Moonriver, and Moonbase Alpha all use the same unified [Etherscan](https://etherscan.io){target=\_blank} API key.

To verify the contract, you will run the `ignition verify` command and pass the name of your deployment you set in the prior step.

```bash
npx hardhat ignition verify INSERT_YOUR_NAME
```

!!! note
    If you're deploying `DelegationDAO.sol` verbatim without any changes, you may get an `Already Verified` error because Moonscan automatically recognizes and verifies smart contracts that have matching bytecode. Your contract will still show as verified, so there is nothing else you need to do. However, if you'd prefer to verify your own `DelegationDAO.sol`, you can make a small change to the contract (such as changing a comment) and repeating the compilation, deployment, and verification steps.

In your terminal you should see the source code for your contract was successfully submitted for verification. If the verification was successful, you should see **Successfully verified contract** and there will be a link to the contract code on [Moonbeam Moonscan](https://moonscan.io){target=\_blank}. If the plugin returns an error, double check that your API key is configured correctly and that you have specified all necessary parameters in the verification command. You can refer to the [guide to the Hardhat Etherscan plugin](/builders/ethereum/verify-contracts/etherscan-plugins/){target=\_blank} for more information.

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span> npx hardhat ignition verify INSERT_YOUR_NAME</span>
    <br>
    <span data-ty>Nothing to compile</span>
    <span data-ty>Successfully submitted source code for contract
contracts/DelegationDAO.sol:DelegationDAO at 0x6D895A55F5ba31e582bCEe71cae394266F240e9b for verification on the block explorer. Waiting for verification result...</span>
    <br>
    <span data-ty>Successfully verified contract DelegationDAO on Etherscan.</span>
    <br>
    <span data-ty>https://moonbeam.moonscan.io/address/0x6D895A55F5ba31e582bCEe71cae394266F240e9b#code</span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>

And that's it! We covered a lot of ground in this tutorial, but there's more resources available if you'd like to go deeper, including the following:

- [Hardhat guide to Testing Contracts](https://hardhat.org/hardhat-runner/docs/guides/test-contracts){target=\_blank}
- [Writing tasks and scripts](https://hardhat.org/hardhat-runner/docs/guides/tasks){target=\_blank}

<div class="page-disclaimer">
    This tutorial is for educational purposes only. As such, any contracts or code created in this tutorial should not be used in production.
</div>

<div class="page-disclaimer">
  The information presented herein has been provided by third parties and is made available solely for general information purposes. Moonbeam does not endorse any project listed and described on the Moonbeam Doc Website (https://docs.moonbeam.network/). Moonbeam Foundation does not warrant the accuracy, completeness or usefulness of this information. Any reliance you place on such information is strictly at your own risk. Moonbeam Foundation disclaims all liability and responsibility arising from any reliance placed on this information by you or by anyone who may be informed of any of its contents. All statements and/or opinions expressed in these materials are solely the responsibility of the person or entity providing those materials and do not necessarily represent the opinion of Moonbeam Foundation. The information should not be construed as professional or financial advice of any kind. Advice from a suitably qualified professional should always be sought in relation to any particular matter or circumstance. The information herein may link to or integrate with other websites operated or content provided by third parties, and such other websites may link to this website. Moonbeam Foundation has no control over any such other websites or their content and will have no liability arising out of or related to such websites or their content. The existence of any such link does not constitute an endorsement of such websites, the content of the websites, or the operators of the websites. These links are being provided to you only as a convenience and you release and hold Moonbeam Foundation harmless from any and all liability arising from your use of this information or the information provided by any third-party website or service.
</div>
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/tutorials/eth-api/how-to-build-a-dapp/
--- BEGIN CONTENT ---
---
title: How to Build a DApp
description: Learn about the frontend, smart contracts, and storage system of Decentralized Applications (DApp) by dissecting an entire example project.
categories: Tutorials
---

# How to Build a DApp: Complete DApp Architecture

_by Jeremy Boetticher_

## Introduction {: #introduction }

Decentralized applications, or DApps, have redefined how applications are built, managed, and interacted with in Web3. By leveraging blockchain technology, DApps provide a secure, transparent, and trustless system that enables peer-to-peer interactions without any central authority. At the core of a DApp's architecture are several main components that work in tandem to create a robust, decentralized ecosystem. These components include smart contracts, nodes, frontend user interfaces, and more.  

![DApp Architecture Diagram](/images/tutorials/eth-api/how-to-build-a-dapp/how-to-build-a-dapp-1.webp)

In this tutorial, you'll come face-to-face with each major component by writing a full DApp that mints tokens. We'll also explore additional optional components of DApps that can enhance user experience for your future projects. You can view the complete project in its [monorepo on GitHub](https://github.com/jboetticher/complete-example-dapp){target=\_blank}.  

![DApp End Result](/images/tutorials/eth-api/how-to-build-a-dapp/how-to-build-a-dapp-2.webp)

## Checking Prerequisites {: #checking-prerequisites }

To get started, you should have the following:

 - A Moonbase Alpha account funded with DEV. 
  You can get DEV tokens for testing on Moonbase Alpha once every 24 hours from the [Moonbase Alpha Faucet](https://faucet.moonbeam.network){target=\_blank}
 - [Node.js](https://nodejs.org/en/download/package-manager){target=\_blank} version 16 or newer installed
 - [VS Code](https://code.visualstudio.com){target=\_blank} with Juan Blanco's [Solidity extension](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity){target=\_blank} is a recommended IDE
 - Understanding of JavaScript and React
 - Novice familiarity with Solidity. If you are not familiar with writing Solidity, there are many resources out there, including [Solidity by Example](https://solidity-by-example.org){target=\_blank}. A 15-minute skim should suffice for this tutorial
 - A wallet like [MetaMask installed](/tokens/connect/metamask/){target=\_blank}

## Nodes and JSON-RPC Endpoints {: #nodes-and-json-rpc-endpoints }

Generally speaking, a JSON-RPC is a remote procedure call (RPC) protocol that utilizes JSON to encode data. For Web3, they refer to the specific JSON-RPCs that DApp developers use to send requests and receive responses from blockchain nodes, making it a crucial element in interactions with smart contracts. They allow frontend user interfaces to seamlessly interact with the smart contracts and provide users with real-time feedback on their actions. They also allow developers to deploy their smart contracts in the first place!  

To get a JSON-RPC to communicate with a Moonbeam blockchain, you need to run a node. But that can be expensive, complicated, and a hassle. Fortunately, as long as you have *access* to a node, you can interact with the blockchain. Moonbase Alpha has a [handful of free and paid node options](/learn/platform/networks/moonbase/#network-endpoints){target=\_blank}. For this tutorial, we will be using the Moonbeam Foundation's public node for Moonbase Alpha, but you are encouraged to get your own [private endpoint](/builders/get-started/endpoints/#endpoint-providers){target=\_blank}.  

```text
{{ networks.moonbase.rpc_url }}
```

So now you have a URL. How do you use it? Over `HTTPS`, JSON-RPC requests are `POST` requests that include specific methods for reading and writing data, such as `eth_call` for executing a smart contract function in a read-only manner or `eth_sendRawTransaction` for submitting signed transactions to the network (calls that change the blockchain state). The entire JSON request structure will always have a structure similar to the following:  

```json
{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_getBalance",
    "params": ["0xf24FF3a9CF04c71Dbc94D0b566f7A27B94566cac", "latest"]
}
```

This example is getting the balance (in DEV on Moonbase Alpha) of the `0xf24FF3a9CF04c71Dbc94D0b566f7A27B94566cac` account. Let's break down the elements:  

- `jsonrpc` — the JSON-RPC API version, usually "2.0"
- `id` — an integer value that helps identify a response to a request. Can usually just keep it as 1
- `method` — the specific method to read/write data from/to the blockchain. You can see many of the [RPC methods on our docs site](/builders/ethereum/json-rpc/eth-rpc/){target=\_blank}
- `params` — an array of the input parameters expected by the specific `method`  

There are also additional elements that can be added to JSON-RPC requests, but those four will be seen the most often.  

Now, these JSON-RPC requests are pretty useful, but when writing code, it can be a hassle to create a JSON object over and over again. That's why there exist libraries that help abstract and facilitate the usage of these requests. Moonbeam provides [documentation on many libraries](/builders/ethereum/libraries/){target=\_blank}, and the one that we will be using in this tutorial is [Ethers.js](/builders/ethereum/libraries/ethersjs/){target=\_blank}. Just understand that whenever we interact with the blockchain through the Ethers.js package, we're really using JSON-RPC!  

## Smart Contracts {: #smart-contracts }

Smart contracts are self-executing contracts with the terms of the agreement directly written into code. They serve as the decentralized backend of any DApp, automating and enforcing the business logic within the system.  

If coming from traditional web development, smart contracts are meant to replace the backend with important caveats: the user must have the native currency (GLMR, MOVR, DEV, etc.) to make state-changing requests, storing information can be expensive, and **no information stored is private**.  

When you deploy a smart contract onto Moonbeam, you upload a series of instructions that can be understood by the EVM, or the Ethereum Virtual Machine. Whenever someone interacts with a smart contract, these transparent, tamper-proof, and immutable instructions are executed by the EVM to change the blockchain's state. Writing the instructions in a smart contract properly is very important since the blockchain's state defines the most crucial information about your DApp, such as who has what amount of money.  

Since the instructions are difficult to write and make sense of at a low (assembly) level, we have smart contract languages such as Solidity to make it easier to write them. To help write, debug, test, and compile these smart contract languages, developers in the Ethereum community have created developer environments such as [Hardhat](/builders/ethereum/dev-env/hardhat/){target=\_blank} and [Foundry](/builders/ethereum/dev-env/foundry/){target=\_blank}. Moonbeam's developer site provides information on a [plethora of developer environments](/builders/ethereum/dev-env/){target=\_blank}.

This tutorial will use Hardhat for managing smart contracts.

### Create a Hardhat Project {: #create-hardhat-project }

You can initialize a project with Hardhat using the following command:  

```bash
npx hardhat init
```

When creating a JavaScript or TypeScript Hardhat project, you will be asked if you want to install the sample project's dependencies, which will install Hardhat and the [Hardhat Toolbox plugin](https://hardhat.org/hardhat-runner/plugins/nomicfoundation-hardhat-toolbox#hardhat-toolbox){target=\_blank}. You don't need all of the plugins that come wrapped up in the Toolbox, so instead you can install Hardhat, Ethers, and the Hardhat Ethers plugin, which is all you'll need for this tutorial:

```bash
npm install --save-dev hardhat @nomicfoundation/hardhat-ethers ethers@6
```

Before we start writing the smart contract, let's add a JSON-RPC URL to the config. Set the `hardhat.config.js` file with the following code, and replace `INSERT_YOUR_PRIVATE_KEY` with your funded account's private key.

!!! remember
    This is for testing purposes, **never store your private key in plain text with real funds**.  

```javascript
require('@nomicfoundation/hardhat-ethers');
module.exports = {
  solidity: '0.8.20',
  networks: {
    moonbase: {
      url: '{{ networks.moonbase.rpc_url }}',
      chainId: {{ networks.moonbase.chain_id }},
      accounts: ['INSERT_YOUR_PRIVATE_KEY']
    }
  }
};
```

### Write Smart Contracts {: #write-smart-contracts }

Recall that we're making a DApp that allows you to mint a token for a price. Let's write a smart contract that reflects this functionality!  

Once you've initialized a Hardhat project, you'll be able to write smart contracts in its `contracts` folder. This folder will have an initial smart contract, likely called `Lock.sol`, but you should delete it and add a new smart file called `MintableERC20.sol`.  

The standard for tokens is called ERC-20, where ERC stands for "*Ethereum Request for Comment*". A long time ago, this standard was defined, and now most smart contracts that work with tokens expect tokens to have all of the functionality defined by ERC-20. Fortunately, you don't have to know it from memory since the OpenZeppelin smart contract team provides us with smart contract bases to use.  

Install [OpenZeppelin smart contracts](https://docs.openzeppelin.com/contracts/4.x){target=\_blank}:  

```bash
npm install @openzeppelin/contracts
```

Now, in your `MintableERC20.sol`, add the following code:  

```solidity
// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract MintableERC20 is ERC20, Ownable {
    constructor(address initialOwner) ERC20("Mintable ERC 20", "MERC") Ownable(initialOwner) {}
}
```

When writing smart contracts, you're going to have to compile them eventually. Every developer environment for smart contracts will have this functionality. In Hardhat, you can compile with:  

```bash
npx hardhat compile
```

Everything should compile well, which should cause two new folders to pop up: `artifacts` and `cache`. These two folders hold information about the compiled smart contracts.  

Let's continue by adding functionality. Add the following constants, errors, event, and function to your Solidity file:  

```solidity
    uint256 public constant MAX_TO_MINT = 1000 ether;

    event PurchaseOccurred(address minter, uint256 amount);
    error MustMintOverZero();
    error MintRequestOverMax();
    error FailedToSendEtherToOwner();

    /**Purchases some of the token with native currency. */
    function purchaseMint() payable external {
        // Calculate amount to mint
        uint256 amountToMint = msg.value;

        // Check for no errors
        if(amountToMint == 0) revert MustMintOverZero();
        if(amountToMint + totalSupply() > MAX_TO_MINT) revert MintRequestOverMax();

        // Send to owner
        (bool success, ) = owner().call{value: msg.value}("");
        if(!success) revert FailedToSendEtherToOwner();

        // Mint to user
        _mint(msg.sender, amountToMint);
        emit PurchaseOccurred(msg.sender, amountToMint);
    }
```

??? code "MintableERC20.sol file"

    ```solidity
    // SPDX-License-Identifier: UNLICENSED
    pragma solidity ^0.8.20;

    import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
    import "@openzeppelin/contracts/access/Ownable.sol";

    contract MintableERC20 is ERC20, Ownable {
        constructor(address initialOwner) ERC20("Mintable ERC 20", "MERC") Ownable(initialOwner) {}

        uint256 public constant MAX_TO_MINT = 1000 ether;

        event PurchaseOccurred(address minter, uint256 amount);
        error MustMintOverZero();
        error MintRequestOverMax();
        error FailedToSendEtherToOwner();

        /**Purchases some of the token with native gas currency. */
        function purchaseMint() external payable {
            // Calculate amount to mint
            uint256 amountToMint = msg.value;

            // Check for no errors
            if (amountToMint == 0) revert MustMintOverZero();
            if (amountToMint + totalSupply() > MAX_TO_MINT)
                revert MintRequestOverMax();

            // Send to owner
            (bool success, ) = owner().call{value: msg.value}("");
            if (!success) revert FailedToSendEtherToOwner();

            // Mint to user
            _mint(msg.sender, amountToMint);
            emit PurchaseOccurred(msg.sender, amountToMint);
        }
    }
    ```

This function will allow a user to send the native Moonbeam currency (like GLMR, MOVR, or DEV) as value because it is a payable function. Let's break down the function section by section.  

1. It will figure out how much of the token to mint based on the value sent
2. Then it will check to see if the amount minted is 0 or if the total amount minted is over the `MAX_TO_MINT`, giving a descriptive error in both cases
3. The contract will then forward the value included with the function call to the owner of the contract (by default, the address that deployed the contract, which will be you)
4. Finally, tokens will be minted to the user, and an event will be emitted to pick up on later  

To make sure that this works, let's use Hardhat again:  

```bash
npx hardhat compile
```

You've now written the smart contract for your DApp! If this were a production app, we would write tests for it, but that is out of the scope of this tutorial. Let's deploy it next.  

### Deploy Smart Contracts {: #deploying-smart-contracts }

Under the hood, Hardhat is a Node project that uses the [Ethers.js](/builders/ethereum/libraries/ethersjs/){target=\_blank} library to interact with the blockchain. You can also use Ethers.js in conjunction with Hardhat's tool to create scripts to do things like deploy contracts.  

Your Hardhat project should already come with a script in the `scripts` folder, called `deploy.js`. Let's replace it with a similar, albeit simpler, script.

```javascript
const hre = require('hardhat');

async function main() {
  const [deployer] = await hre.ethers.getSigners();

  const MintableERC20 = await hre.ethers.getContractFactory('MintableERC20');
  const token = await MintableERC20.deploy(deployer.address);
  await token.waitForDeployment();

  // Get and print the contract address
  const myContractDeployedAddress = await token.getAddress();
  console.log(`Deployed to ${myContractDeployedAddress}`);
}

main().catch((error) => {
  console.error(error);
  process.exitCode = 1;
});
```

This script uses Hardhat's instance of the Ethers library to get a contract factory of the `MintableERC20.sol` smart contract that we wrote earlier. It then deploys it and prints the resultant smart contract's address. Very simple to do with Hardhat and the Ethers.js library, but significantly more difficult using just JSON-RPC!  

Let's run the contract on Moonbase Alpha (whose JSON-RPC endpoint we defined in the `hardhat.config.js` script earlier):  

```bash
npx hardhat run scripts/deploy.js --network moonbase
```

You should see an output that displays the token address. Make sure to **save it for use later**!

!!! challenge
    Hardhat has a poor built-in solution for deploying smart contracts. It doesn't automatically save the transactions and addresses related to the deployment! This is why the [hardhat-deploy](https://www.npmjs.com/package/hardhat-deploy#1-hardhat-deploy){target=\_blank} package was created. Can you implement it yourself? Or can you switch to a different developer environment, like [Foundry](https://github.com/foundry-rs/foundry){target=\_blank}?

## Create a DApp Frontend {: #creating-a-dapp-frontend }

Frontends provide an interface for users to interact with blockchain-based applications. React, a popular JavaScript library for building user interfaces, is often used for developing DApp frontends due to its component-based architecture, which promotes reusable code and efficient rendering. The [useDApp package](https://github.com/TrueFiEng/useDApp){target=\_blank}, an Ethers.js based React framework for DApps, further simplifies the process of building DApp frontends by providing a comprehensive set of hooks and components that streamline the integration of Ethereum blockchain functionality.  

!!! note
    Typically, a larger project will create separate GitHub repositories for their frontend and smart contracts, but this is a small enough project to create a monorepo.

### Create a React Project with useDapp {: #create-react-project-with-usedapp }

Let's set up a new React project and install dependencies, which we can create within our Hardhat project's folder without much issue. The `create-react-app` package will create a new `frontend` directory for us:  

```bash
npx create-react-app frontend
cd frontend
npm install ethers@5.6.9 @usedapp/core @mui/material @mui/system @emotion/react @emotion/styled
```

If you remember, [Ethers.js](/builders/ethereum/libraries/ethersjs/){target=\_blank} is a library that assists with JSON-RPC communication. The useDApp package is a similar library that uses Ethers.js and formats them into React hooks so that they work better in frontend projects. We've also added two [MUI](https://mui.com){target=\_blank} packages for styling and components.

Let's set up the `App.js` file located in the `frontend/src` directory to add some visual structure:

```javascript
import { useEthers } from '@usedapp/core';
import { Button, Grid, Card } from '@mui/material';
import { Box } from '@mui/system';

const styles = {
  box: { minHeight: '100vh', backgroundColor: '#1b3864' },
  vh100: { minHeight: '100vh' },
  card: { borderRadius: 4, padding: 4, maxWidth: '550px', width: '100%' },
  alignCenter: { textAlign: 'center' },
};

function App() {
  return (
    <Box sx={styles.box}>
      <Grid
        container
        direction='column'
        alignItems='center'
        justifyContent='center'
        style={styles.vh100}
      >
        {/* This is where we'll be putting our functional components! */}
      </Grid>
    </Box>
  );
}

export default App;
```

You can start the React project by running the following command from within the `frontend` directory:

```bash
npm run start
```

!!! note
    At this point, you may see a couple compilation warnings, but as we continue to build the DApp, we'll make changes that will resolve the warnings.

Your frontend will be available at `http://localhost:3000`.

At this point, our frontend project is set up well enough to start working on the functional code!  

### Providers, Signers, and Wallets {: #providers-signers-and-wallets }

The frontend communicates with the blockchain using JSON-RPC, but we will be using Ethers.js. When using JSON-RPC, Ethers.js likes to abstract degrees of interaction with the blockchain into objects, such as providers, signers, and wallets.  

Providers are the bridge between the frontend user interface and the blockchain network, facilitating communication and data exchange. They abstract the complexities of interacting with the blockchain, offering a simple API for the frontend to use. They are responsible for connecting the DApp to a specific blockchain node, allowing it to read data from the blockchain, and essentially contain the JSON-RPC URL.  

Signers are a type of provider that contain a secret that can be used to sign transactions with. This allows the frontend to create transactions, sign them, and then send them with `eth_sendRawTransaction`. There are multiple types of signers, but we're most interested in wallet objects, which securely store and manage users' private keys and digital assets. Wallets such as MetaMask facilitate transaction signing with a universal and user-friendly process. They act as a user's representation within the DApp, ensuring that only authorized transactions are executed. The Ethers.js wallet object represents this interface within our frontend code.

Typically, a frontend using Ethers.js will require you to create a provider, connect to the user's wallet if applicable, and create a wallet object. This process can become unwieldy in larger projects, especially with the number of wallets that exist other than MetaMask.  

??? code "Example of unwieldy MetaMask handling"

    ```javascript
    // Detect if the browser has MetaMask installed
    let provider, signer;
    if (typeof window.ethereum !== 'undefined') {
      // Create a provider using MetaMask
      provider = new ethers.BrowserProvider(window.ethereum);

      // Connect to MetaMask
      async function connectToMetaMask() {
        try {
          // Request access to the user's MetaMask account
          const accounts = await window.ethereum.request({
            method: 'eth_requestAccounts',
          });

          // Create a signer (wallet) using the provider
          signer = provider.getSigner(accounts[0]);
        } catch (error) {
          console.error('Error connecting to MetaMask:', error);
        }
      }

      // Call the function to connect to MetaMask
      connectToMetaMask();
    } else {
      console.log('MetaMask is not installed');
    }

    // ... also the code for disconnecting from the site
    // ... also the code that handles other wallets
    ```

Fortunately, we have installed the useDApp package, which simplifies many of the processes for us. This simultaneously abstracts what Ethers is doing as well, which is why we took a bit of time to explain them here.  

#### Create a Provider {: #create-provider }

Let's do a bit of setup with the useDApp package. First, in your React frontend's `index.js` file, which is located in the `frontend/src` directory, add a `DAppProvider` object and its config. This essentially acts as the Ethers.js provider object, but can be used throughout your entire project by useDApp hooks:  

```javascript
import React from 'react';
import ReactDOM from 'react-dom/client';
import App from './App';
import { DAppProvider, MoonbaseAlpha } from '@usedapp/core';
import { getDefaultProvider } from 'ethers';

const config = {
  readOnlyChainId: MoonbaseAlpha.chainId,
  readOnlyUrls: {
    [MoonbaseAlpha.chainId]: getDefaultProvider(
      '{{ networks.moonbase.rpc_url }}'
    ),
  },
};

const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(
  <React.StrictMode>
    <DAppProvider config={config}>
      <App />
    </DAppProvider>
  </React.StrictMode>
);
```

#### Connect to a Wallet {: #connect-to-a-wallet }

Now in your `App.js` file, let's add a button that allows us to connect to MetaMask. We don't have to write any code that's wallet-specific, fortunately, since useDApp does it for us with the `useEthers` hook.  

```javascript
function App() {
  const { activateBrowserWallet, deactivate, account } = useEthers();

  // Handle the wallet toggle
  const handleWalletConnection = () => {
    if (account) deactivate();
    else activateBrowserWallet();
  };

  return (
    <Box sx={styles.box}>
      <Grid
        container
        direction='column'
        alignItems='center'
        justifyContent='center'
        style={styles.vh100}
      >
        <Box position='absolute' top={8} right={16}>
          <Button variant='contained' onClick={handleWalletConnection}>
            {account
              ? `Disconnect ${account.substring(0, 5)}...`
              : 'Connect Wallet'}
          </Button>
        </Box>
      </Grid>
    </Box>
  );
};
```

Now there should be a button in the top right of your screen that connects your wallet to your frontend! Next, let's find out how we can read data from our smart contract.  

### Read Data from Smart Contracts {: #reading-from-contracts }

Reading from contracts is quite easy, as long as we know what we want to read. For our application, we will be reading the maximum amount of tokens that can be minted and the number of tokens that have already been minted. This way, we can display to our users how many tokens can still be minted and hopefully invoke some FOMO...  

If you were just using JSON-RPC, you would use `eth_call` to get this data, but it's quite difficult to do this since you have to [encode your requests](https://docs.soliditylang.org/en/latest/abi-spec.html){target=\_blank} in a non-straightforward method called ABI encoding. Fortunately, Ethers.js allows us to easily create objects that represent contracts in a human-readable way, so long as we have the ABI of the contract. And we have the ABI of the `MintableERC20.sol` contract, `MintableERC20.json`, within the `artifacts` directory of our Hardhat project!

So let's start by moving the `MintableERC20.json` file into our frontend directory. Every time you change and recompile the smart contract, you'll have to update the ABI in the frontend as well. Some projects will have developer setups that automatically pull ABIs from the same source, but in this case we will just copy it over:  

```text
|--artifacts
    |--@openzeppelin
    |--build-info
    |--contracts
        |--MintableERC20.sol
            |--MintableERC20.json // This is the file you're looking for!
            ...
|--cache
|--contracts
|--frontend
    |--public
    |--src
        |--MintableERC20.json // Copy the file to here!
        ...
    ...
...
```

Now that we have the ABI, we can use it to create a contract instance of `MintableERC20.sol`, which we'll use to retrieve token data.

#### Create a Smart Contract Instance {: #create-a-contract-instance }

Let's import the JSON file and the Ethers `Contract` object within `App.js`. We can create a contract object instance with an address and ABI, so replace `INSERT_CONTRACT_ADDRESS` with the address of the contract that you copied [back when you deployed it](#deploying-smart-contracts):

```javascript
// ... other imports
import MintableERC20 from './MintableERC20.json'; 
import { Contract } from 'ethers';

const contractAddress = 'INSERT_CONTRACT_ADDRESS';

function App() {
  const contract = new Contract(contractAddress, MintableERC20.abi);
  // ...
}
```

??? code "App.js file"

    ```js
    import { useEthers } from '@usedapp/core';
    import { Button, Grid, Card } from '@mui/material';
    import { Box } from '@mui/system';
    import { Contract } from 'ethers';
    import MintableERC20 from './MintableERC20.json'; 

    const styles = {
      box: { minHeight: '100vh', backgroundColor: '#1b3864' },
      vh100: { minHeight: '100vh' },
      card: { borderRadius: 4, padding: 4, maxWidth: '550px', width: '100%' },
      alignCenter: { textAlign: 'center' },
    };

    const contractAddress = 'INSERT_CONTRACT_ADDRESS';

    function App() {
      const contract = new Contract(contractAddress, MintableERC20.abi);
      const { activateBrowserWallet, deactivate, account } = useEthers();

      // Handle the wallet toggle
      const handleWalletConnection = () => {
        if (account) deactivate();
        else activateBrowserWallet();
      };

      return (
        <Box sx={styles.box}>
          <Grid
            container
            direction='column'
            alignItems='center'
            justifyContent='center'
            style={styles.vh100}
          >
            <Box position='absolute' top={8} right={16}>
              <Button variant='contained' onClick={handleWalletConnection}>
                {account
                  ? `Disconnect ${account.substring(0, 5)}...`
                  : 'Connect Wallet'}
              </Button>
            </Box>
          </Grid>
        </Box>
      );
    }

    export default App;
    ```

#### Interact with the Contract Interface to Read Supply Data {: #interact-with-contract-interface }

And let's create a new `SupplyComponent` within a new `SupplyComponent.js` file, which will use the contract interface to retrieve the token supply data and display it:  

```javascript
import { useCall } from '@usedapp/core';
import { utils } from 'ethers';
import { Grid } from '@mui/material';

export default function SupplyComponent({ contract }) {
  const totalSupply = useCall({ contract, method: 'totalSupply', args: [] });
  const maxSupply = useCall({ contract, method: 'MAX_TO_MINT', args: [] });
  const totalSupplyFormatted = totalSupply
    ? utils.formatEther(totalSupply.value.toString())
    : '...';
  const maxSupplyFormatted = maxSupply
    ? utils.formatEther(maxSupply.value.toString())
    : '...';

  const centeredText = { textAlign: 'center' };

  return (
    <Grid item xs={12}>
      <h3 style={centeredText}>
        Total Supply: {totalSupplyFormatted} / {maxSupplyFormatted}
      </h3>
    </Grid>
  );
}
```

Notice that this component uses the `useCall` hook provided by the useDApp package. This call takes in the contract object we created earlier, a string method, and any relevant arguments for the read-only call and returns the output. While it required some setup, this one-liner is a lot simpler than the entire `use_call` RPC call that we would have had to do if we weren't using Ethers.js and useDApp.  

Also note that we're using a utility format called `formatEther` to format the output values instead of displaying them directly. This is because our token, like gas currencies, is stored as an unsigned integer with a fixed decimal point of 18 figures. The utility function helps format this value into a way that we, as humans, expect.  

Now we can spice up our frontend and call the read-only functions in the contract. We'll update the frontend so that we have a place to display our supply data:

```javascript
// ... other imports
import SupplyComponent from './SupplyComponent';

function App() {
  // ...

  return (
    {/* Wrapper Components */}
      {/* Button Component */}
      <Card sx={styles.card}>
        <h1 style={styles.alignCenter}>Mint Your Token!</h1>
        <SupplyComponent contract={contract} />
      </Card>
    {/* Wrapper Components */}
  )
}
```

??? code "App.js file"

    ```javascript
    import { useEthers } from '@usedapp/core';
    import { Button, Grid, Card } from '@mui/material';
    import { Box } from '@mui/system';
    import { Contract } from 'ethers';
    import MintableERC20 from './MintableERC20.json'; 
    import SupplyComponent from './SupplyComponent';

    const styles = {
      box: { minHeight: '100vh', backgroundColor: '#1b3864' },
      vh100: { minHeight: '100vh' },
      card: { borderRadius: 4, padding: 4, maxWidth: '550px', width: '100%' },
      alignCenter: { textAlign: 'center' },
    };
    const contractAddress = 'INSERT_CONTRACT_ADDRESS';

    function App() {
      const { activateBrowserWallet, deactivate, account } = useEthers();
      const contract = new Contract(contractAddress, MintableERC20.abi);

      // Handle the wallet toggle
      const handleWalletConnection = () => {
        if (account) deactivate();
        else activateBrowserWallet();
      };

      return (
        <Box sx={styles.box}>
          <Grid
            container
            direction='column'
            alignItems='center'
            justifyContent='center'
            style={styles.vh100}
          >
            <Box position='absolute' top={8} right={16}>
              <Button variant='contained' onClick={handleWalletConnection}>
                {account
                  ? `Disconnect ${account.substring(0, 5)}...`
                  : 'Connect Wallet'}
              </Button>
            </Box>
            <Card sx={styles.card}>
              <h1 style={styles.alignCenter}>Mint Your Token!</h1>
              <SupplyComponent contract={contract} />
            </Card>
          </Grid>
        </Box>
      );
    }

    export default App;
    ```

Our frontend should now display the correct data!  

![Displaying data](/images/tutorials/eth-api/how-to-build-a-dapp/how-to-build-a-dapp-3.webp)

!!! challenge
    There's additional information that could be helpful to display, such as the amount of tokens that the connected account currently has: `balanceOf(address)`. Can you add that to the frontend yourself?

### Send Transactions {: #sending-transactions }

Now for the most important part of all DApps: the state-changing transactions. This is where money moves, where tokens are minted, and value passes.  

If you recall from our smart contract, we want to mint some tokens by calling the `purchaseMint` function with some native currency. So we're going to need:  

1. A text input that lets the user specify how much value to enter  
2. A button that lets the user initiate the transaction signature

Let's create a new component called `MintingComponent` in a new file called `MintingComponent.js`. First, we'll tackle the text input, which will require us to add the logic to store the number of tokens to mint and a text field element.

```javascript
import { useState } from 'react';
import { useContractFunction, useEthers, MoonbaseAlpha } from '@usedapp/core';
import { Button, CircularProgress, TextField, Grid } from '@mui/material';
import { utils } from 'ethers';

export default function MintingComponent({ contract }) {
  const [value, setValue] = useState(0);
  const textFieldStyle = { marginBottom: '16px' };

  return (
    <>
      <Grid item xs={12}>
        <TextField 
          type='number'
          onChange={(e) => setValue(e.target.value)}
          label='Enter value in DEV'
          variant='outlined'
          fullWidth
          style={textFieldStyle} 
        />
      </Grid>
      {/* This is where we'll add the button */}
    </>
  );
}
```

Next, we'll need to create the button to send the transaction, which will call the `purchaseMint` of our contract. Interacting with the contract will be a bit more difficult since you're likely not as familiar with it. We've already done a lot of setup in the previous sections, so it doesn't actually take too much code:  

```javascript
export default function MintingComponent({ contract }) {
  // ...

  // Mint transaction
  const { account, chainId, switchNetwork } = useEthers();
  const { state, send } = useContractFunction(contract, 'purchaseMint');
  const handlePurchaseMint = async () => {
    if (chainId !== MoonbaseAlpha.chainId) {
      await switchNetwork(MoonbaseAlpha.chainId);
    }
    send({ value: utils.parseEther(value.toString()) });
  };
  const isMining = state?.status === 'Mining';

  return (
    <>
      {/* ... */}
      <Grid item xs={12}>
        <Button
          variant='contained' color='primary' fullWidth
          onClick={handlePurchaseMint}
          disabled={state.status === 'Mining' || account == null}
        >
          {isMining? <CircularProgress size={24} /> : 'Purchase Mint'}
        </Button>
      </Grid>
    </>
  );
}
```

??? code "MintingComponent.js file"

    ```js
    import { useState } from 'react';
    import { useContractFunction, useEthers, MoonbaseAlpha } from '@usedapp/core';
    import { Button, CircularProgress, TextField, Grid } from '@mui/material';
    import { utils } from 'ethers';

    export default function MintingComponent({ contract }) {
      const [value, setValue] = useState(0);
      const textFieldStyle = { marginBottom: '16px' };

      const { account, chainId, switchNetwork } = useEthers();
      const { state, send } = useContractFunction(contract, 'purchaseMint');
      const handlePurchaseMint = async () => {
        if (chainId !== MoonbaseAlpha.chainId) {
          await switchNetwork(MoonbaseAlpha.chainId);
        }
        send({ value: utils.parseEther(value.toString()) });
      };
      const isMining = state?.status === 'Mining';

      return (
        <>
          <Grid item xs={12}>
            <TextField 
              type='number'
              onChange={(e) => setValue(e.target.value)}
              label='Enter value in DEV'
              variant='outlined'
              fullWidth
              style={textFieldStyle} 
            />
          </Grid>
          <Grid item xs={12}>
            <Button
              variant='contained' color='primary' fullWidth
              onClick={handlePurchaseMint}
              disabled={state.status === 'Mining' || account == null}
            >
              {isMining? <CircularProgress size={24} /> : 'Purchase Mint'}
            </Button>
          </Grid>
        </>
      );
    }
    ```

Let's break down the non-JSX code a bit:  

1. The user's account information is being retrieved via `useEthers`, which can be done because useDApp provides this information throughout the entire project
2. The `useContractFunction` hook from useDApp is used to create a function, `send`, that will sign and send a transaction that calls the `purchaseMint` function on the contract defined by the `contract` object
3. Another function, `handlePurchaseMint`, is defined to help inject the native gas value defined by the `TextField` component into the `send` function. It first checks if the user has their wallet connected to Moonbase Alpha, and if not, it prompts the user to switch networks
4. A helper constant will determine whether or not the transaction is still in the `Mining` phase, that is, it hasn't finished

Now let's look at the visual component. The button will call the `handlePurchaseMint` on press, which makes sense. The button will also be disabled while the transaction happens and if the user hasn't connected to the DApp with their wallet (when the account value isn't defined).  

This code essentially boils down to using the `useContractFunction` hook in conjunction with the `contract` object, which is a lot simpler than what it does under the hood! Let's add this component to the main `App.js` file.  

```javascript
// ... other imports
import MintingComponent from './MintingComponent';

function App() {
  // ...

  return (
    {/* Wrapper Components */}
      {/* Button Component */}
      <Card sx={styles.card}>
        <h1 style={styles.alignCenter}>Mint Your Token!</h1>
        <SupplyComponent contract={contract} />
        <MintingComponent contract={contract} />
      </Card>
    {/* Wrapper Components */}
  )
}
```

??? code "App.js file"

    ```javascript
    import { useEthers } from '@usedapp/core';
    import { Button, Grid, Card } from '@mui/material';
    import { Box } from '@mui/system';
    import { Contract } from 'ethers';
    import MintableERC20 from './MintableERC20.json';
    import SupplyComponent from './SupplyComponent';
    import MintingComponent from './MintingComponent';

    const styles = {
      box: { minHeight: '100vh', backgroundColor: '#1b3864' },
      vh100: { minHeight: '100vh' },
      card: { borderRadius: 4, padding: 4, maxWidth: '550px', width: '100%' },
      alignCenter: { textAlign: 'center' },
    };
    const contractAddress = 'INSERT_CONTRACT_ADDRESS';

    function App() {
      const { activateBrowserWallet, deactivate, account } = useEthers();
      const contract = new Contract(contractAddress, MintableERC20.abi);

      // Handle the wallet toggle
      const handleWalletConnection = () => {
        if (account) deactivate();
        else activateBrowserWallet();
      };

      return (
        <Box sx={styles.box}>
          <Grid
            container
            direction='column'
            alignItems='center'
            justifyContent='center'
            style={styles.vh100}
          >
            <Box position='absolute' top={8} right={16}>
              <Button variant='contained' onClick={handleWalletConnection}>
                {account
                  ? `Disconnect ${account.substring(0, 5)}...`
                  : 'Connect Wallet'}
              </Button>
            </Box>
            <Card sx={styles.card}>
              <h1 style={styles.alignCenter}>Mint Your Token!</h1>
              <SupplyComponent contract={contract} />
              <MintingComponent contract={contract} />
            </Card>
          </Grid>
        </Box>
      );
    }

    export default App;
    ```

![DApp with the Minting section](/images/tutorials/eth-api/how-to-build-a-dapp/how-to-build-a-dapp-4.webp)  

If you try entering a value like **0.1** and press the button, a MetaMask prompt should occur. Try it out!  

### Read Events from Contracts {: #reading-events-from-contracts }

A common way of listening to what happened in a transaction is through events, also known as logs. These logs are emitted by the smart contract through the `emit` and `event` keywords and can be very important in a responsive frontend. Often, DApps will use toast elements to represent events in real-time, but for this DApp, we will use a simple table.  

We created an event in our smart contract: `event PurchaseOccurred(address minter, uint256 amount)`, so let's figure out how to display its information in the frontend.  

Let's create a new component `PurchaseOccurredEvents` within a new file `PurchaseOccurredEvents.js` that reads the last five logs and displays them in a table:  

```javascript
import { useLogs, useBlockNumber } from '@usedapp/core';
import { utils } from 'ethers';
import {
  Grid,
  Table,
  TableBody,
  TableCell,
  TableContainer,
  TableHead,
  TableRow,
} from '@mui/material';

export default function PurchaseOccurredEvents({ contract }) {
  return (
    <Grid item xs={12} marginTop={5}>
      <TableContainer >
        <Table>
          <TableHead>
            <TableRow>
              <TableCell>Minter</TableCell>
              <TableCell align='right'>Amount</TableCell>
            </TableRow>
          </TableHead>
          <TableBody>
            {/* This is where we have to inject data from our logs! */}
          </TableBody>
        </Table>
      </TableContainer>
    </Grid>
  );
}
```

This component so far creates an empty table, so let's use two new hooks to read those logs:  

```javascript
export default function PurchaseOccurredEvents({ contract }) {
  // Get block number to ensure that the useLogs doesn't search from 0, otherwise it will time out
  const blockNumber = useBlockNumber();

  // Create a filter & get the logs
  const filter = { args: [null, null], contract, event: 'PurchaseOccurred' };
  const logs = useLogs(filter, { fromBlock: blockNumber - 10000 });
  const parsedLogs = logs?.value.slice(-5).map(log => log.data);

  // ... 
}
```

Here's what happens in this code:  

1. The block number is received from the `useBlockNumber` hook, similar to using the JSON-RPC method `eth_blockNumber`
2. A filter is created to filter for all events with any arguments on the contract injected into the component with the event name `PurchaseOccurred`
3. Logs are queried for via the `useLogs` hook, similar to using the `eth_getLogs` JSON-RPC method. Note that we're only querying the last 10,000 blocks because otherwise the entire history of the blockchain would be queried and the RPC would timeout
4. The resultant logs are parsed, and the most recent five are selected

If we want to display them, we can do it like so:  

```javascript
export default function PurchaseOccurredEvents({ contract }) {
  // ...
  return (
    <Grid item xs={12} marginTop={5}>
      <TableContainer >
        <Table>
          {/* TableHead Component */}
          <TableBody>
            {parsedLogs?.reverse().map((log, index) => (
              <TableRow key={index}>
                <TableCell>{log.minter}</TableCell>
                <TableCell align='right'>
                  {utils.formatEther(log.amount)} tokens
                </TableCell>
              </TableRow>
            ))}
          </TableBody>
        </Table>
      </TableContainer>
    </Grid>
  );
}
```

??? code "PurchaseOccurredEvents.js file"

    ```js
    import { useLogs, useBlockNumber } from '@usedapp/core';
    import { utils } from 'ethers';
    import {
      Grid,
      Table,
      TableBody,
      TableCell,
      TableContainer,
      TableHead,
      TableRow,
    } from '@mui/material';

    export default function PurchaseOccurredEvents({ contract }) {
      // Get block number to ensure that the useLogs doesn't search from 0, otherwise it will time out
      const blockNumber = useBlockNumber();

      // Create a filter & get the logs
      const filter = { args: [null, null], contract, event: 'PurchaseOccurred' };
      const logs = useLogs(filter, { fromBlock: blockNumber - 10000 });
      const parsedLogs = logs?.value.slice(-5).map((log) => log.data);
      return (
        <Grid item xs={12} marginTop={5}>
          <TableContainer>
            <Table>
              <TableHead>
                <TableRow>
                  <TableCell>Minter</TableCell>
                  <TableCell align='right'>Amount</TableCell>
                </TableRow>
              </TableHead>
              <TableBody>
                {parsedLogs?.reverse().map((log, index) => (
                  <TableRow key={index}>
                    <TableCell>{log.minter}</TableCell>
                    <TableCell align='right'>
                      {utils.formatEther(log.amount)} tokens
                    </TableCell>
                  </TableRow>
                ))}
              </TableBody>
            </Table>
          </TableContainer>
        </Grid>
      );
    }
    ```

This too should be added to `App.js`.

```javascript
// ... other imports
import PurchaseOccurredEvents from './PurchaseOccurredEvents';

function App() {
  // ...

  return (
    {/* Wrapper Components */}
      {/* Button Component */}
      <Card sx={styles.card}>
        <h1 style={styles.alignCenter}>Mint Your Token!</h1>
        <SupplyComponent contract={contract} />
        <MintingComponent contract={contract} />
        <PurchaseOccurredEvents contract={contract} />
      </Card>
    {/* Wrapper Components */}
  )
}
```

??? code "App.js file"

    ```js
    import { useEthers } from '@usedapp/core';
    import { Button, Grid, Card } from '@mui/material';
    import { Box } from '@mui/system';
    import { Contract } from 'ethers';
    import MintableERC20 from './MintableERC20.json'; 
    import SupplyComponent from './SupplyComponent';
    import MintingComponent from './MintingComponent';
    import PurchaseOccurredEvents from './PurchaseOccurredEvents';

    const styles = {
      box: { minHeight: '100vh', backgroundColor: '#1b3864' },
      vh100: { minHeight: '100vh' },
      card: { borderRadius: 4, padding: 4, maxWidth: '550px', width: '100%' },
      alignCenter: { textAlign: 'center' },
    };
    const contractAddress = 'INSERT_CONTRACT_ADDRESS';

    function App() {
      const { activateBrowserWallet, deactivate, account } = useEthers();
      const contract = new Contract(contractAddress, MintableERC20.abi);

      // Handle the wallet toggle
      const handleWalletConnection = () => {
        if (account) deactivate();
        else activateBrowserWallet();
      };

      return (
        <Box sx={styles.box}>
          <Grid
            container
            direction='column'
            alignItems='center'
            justifyContent='center'
            style={styles.vh100}
          >
            <Box position='absolute' top={8} right={16}>
              <Button variant='contained' onClick={handleWalletConnection}>
                {account
                  ? `Disconnect ${account.substring(0, 5)}...`
                  : 'Connect Wallet'}
              </Button>
            </Box>
            <Card sx={styles.card}>
              <h1 style={styles.alignCenter}>Mint Your Token!</h1>
              <SupplyComponent contract={contract} />
              <MintingComponent contract={contract} />
              <PurchaseOccurredEvents contract={contract} />
            </Card>
          </Grid>
        </Box>
      );
    }

    export default App;
    ```

And, if you've done any transactions, you'll see that they'll pop up!  

![Finished DApp](/images/tutorials/eth-api/how-to-build-a-dapp/how-to-build-a-dapp-5.webp)

Now you've implemented three main components of DApp frontends: reading from storage, sending transactions, and reading logs. With these building blocks as well as the knowledge you gained with smart contracts and nodes, you should be able to cover 80% of DApps.

You can view the complete [example DApp on GitHub](https://github.com/jboetticher/complete-example-dapp){target=\_blank}.

## Conclusion {: #conclusion }

In this tutorial, we covered a wide range of topics and tools essential for successful DApp development. We started with Hardhat, a powerful development environment that simplifies the process of writing, testing, and deploying smart contracts. Ethers.js, a popular library for interacting with Ethereum nodes, was introduced to manage wallets and transactions.  

We delved into the process of writing smart contracts, highlighting best practices and key considerations when developing on-chain logic. The guide then explored useDApp, a React-based framework, for creating a user-friendly frontend. We discussed techniques for reading data from contracts, executing transactions, and working with logs to ensure a seamless user experience.

Of course, there are more advanced (but optional) components of DApps that have popped up over time:

- Decentralized storage protocols — systems that store websites and files in a decentralized way
- [Oracles](/builders/integrations/oracles/){target=\_blank} — third-party services that provide external data to smart contracts within blockchains
- [Indexing protocols](/builders/integrations/indexers/){target=\_blank} — middleware that processes and organizes blockchain data, allowing it to be efficiently queried

An excellent [Web2 to Web3 blogpost](https://moonbeam.network/news/web2-vs-web3-development-here-s-what-you-need-to-know-to-make-the-leap-to-blockchain){target=\_blank} is available if you are interested in hearing about them in depth.  

Hopefully, by reading this guide, you'll be well on your way to creating novel DApps on Moonbeam!

<div class="page-disclaimer">
    This tutorial is for educational purposes only. As such, any contracts or code created in this tutorial should not be used in production.
</div>

<div class="page-disclaimer">
  The information presented herein has been provided by third parties and is made available solely for general information purposes. Moonbeam does not endorse any project listed and described on the Moonbeam Doc Website (https://docs.moonbeam.network/). Moonbeam Foundation does not warrant the accuracy, completeness or usefulness of this information. Any reliance you place on such information is strictly at your own risk. Moonbeam Foundation disclaims all liability and responsibility arising from any reliance placed on this information by you or by anyone who may be informed of any of its contents. All statements and/or opinions expressed in these materials are solely the responsibility of the person or entity providing those materials and do not necessarily represent the opinion of Moonbeam Foundation. The information should not be construed as professional or financial advice of any kind. Advice from a suitably qualified professional should always be sought in relation to any particular matter or circumstance. The information herein may link to or integrate with other websites operated or content provided by third parties, and such other websites may link to this website. Moonbeam Foundation has no control over any such other websites or their content and will have no liability arising out of or related to such websites or their content. The existence of any such link does not constitute an endorsement of such websites, the content of the websites, or the operators of the websites. These links are being provided to you only as a convenience and you release and hold Moonbeam Foundation harmless from any and all liability arising from your use of this information or the information provided by any third-party website or service.
</div>
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/tutorials/eth-api/randomness-lottery/
--- BEGIN CONTENT ---
---
title: Create a Lottery with the Randomness Precompile
description: Looking to create a lottery smart contract? Follow this step-by-step tutorial on using Moonbeam's Randomness Precompile (a Solidity interface) to get started.
categories: Tutorials, Precompiles
---

# Create a Lottery Contract using the Randomness Precompile

_by Erin Shaben_

## Introduction {: #introduction }

Moonbeam utilizes verifiable random functions (VRF) to generate randomness that can be verified on-chain. A VRF is a cryptographic function that takes some input and produces random values, along with a proof of authenticity that these random values were generated by the submitter. The proof can be verified by anyone to ensure the random values generated were calculated correctly.

There are two available sources of randomness that provide random inputs based on block producers' VRF keys and past randomness results: [local VRF](/learn/features/randomness/#local-vrf){target=\_blank} and [BABE epoch randomness](/learn/features/randomness/#babe-epoch-randomness){target=\_blank}. Local VRF is determined directly within Moonbeam using the collator of the block's VRF key and the last block's VRF output. On the other hand, [BABE](https://docs.polkadot.com/polkadot-protocol/architecture/polkadot-chain/pos-consensus/#block-production-babe){target=\_blank} epoch randomness is based on all the VRF produced by the relay chain validators during a complete [epoch](https://wiki.polkadot.com/general/glossary/#epoch){target=\_blank}.

For more information on the two sources of randomness, how the request and fulfillment process works, and security considerations, please refer to the [Randomness on Moonbeam](/learn/features/randomness/){target=\_blank} page.

Moonbeam provides a [Randomness Precompile](/builders/ethereum/precompiles/features/randomness/){target=\_blank}, which is a Solidity interface that enables smart contract developers to generate randomness via local VRF or BABE epoch randomness using the Ethereum API. Moonbeam also provides a [Randomness Consumer Solidity contract](/builders/ethereum/precompiles/features/randomness/#randomness-consumer-solidity-interface){target=\_blank} that your contract must inherit from in order to consume fulfilled randomness requests.

This guide will show you how to use the Randomness Precompile and Randomness Consumer contract to create a lottery where the winners will randomly be selected.

## Checking Prerequisites {: #checking-prerequisites }

For this tutorial, you'll need the following:

- Create or have three accounts on Moonbase Alpha to test out the lottery contract
- All of the accounts will need to be funded with `DEV` tokens.
 You can get DEV tokens for testing on Moonbase Alpha once every 24 hours from the [Moonbase Alpha Faucet](https://faucet.moonbeam.network){target=\_blank}
- An empty Hardhat project that is configured for the Moonbase Alpha TestNet. For step-by-step instructions, please refer to the [Creating a Hardhat Project](/builders/ethereum/dev-env/hardhat/#creating-a-hardhat-project){target=\_blank} and the [Hardhat Configuration File](/builders/ethereum/dev-env/hardhat/#hardhat-configuration-file){target=\_blank} sections of our Hardhat documentation page
- Install the [Hardhat Ethers plugin](https://hardhat.org/hardhat-runner/plugins/nomicfoundation-hardhat-ethers){target=\_blank}. This provides a convenient way to use the [Ethers.js](/builders/ethereum/libraries/ethersjs/){target=\_blank} library to interact with the network from your Hardhat project:

    ```bash
    npm install @nomicfoundation/hardhat-ethers ethers@6
    ```

!!! note
    To test out the examples in this guide on Moonbeam or Moonriver, you will need to have your own endpoint and API key, which you can get from one of the supported [Endpoint Providers](/builders/get-started/endpoints/){target=\_blank}.

## Contract Setup {: #contracts }

The following are the contracts that we'll be working with today to create our lottery:

- `Randomness.sol` - the [Randomness Precompile](/builders/ethereum/precompiles/features/randomness/){target=\_blank}, which is a Solidity interface that allows you to request randomness, get information about randomness requests, fulfill requests, and more
- `RandomnessConsumer.sol` - the [Randomness Consumer](/builders/ethereum/precompiles/features/randomness/#randomness-consumer-solidity-interface){target=\_blank}, which is an abstract Solidity contract that is used to interact with the Randomness Precompile. This contract is responsible for validating the origin of randomness requests, ensuring the Randomness Precompile is always the origin, and fulfilling requests
- `Lottery.sol` - an example lottery contract that we'll be building in this guide together. It will rely on the Randomness Precompile and Consumer to request random words that will be used to select a winner for our lottery

If you don't already have a `contracts` directory in your Hardhat project, you can create a new directory:

```bash
mkdir contracts && cd contracts
```

Then you can create the following three files, one for each of the aforementioned contracts:

```bash
touch Randomness.sol RandomnessConsumer.sol Lottery.sol
```

In the `Randomness.sol` file, you can paste in the Randomness Precompile contract.

??? code "Randomness.sol"

    ```solidity
    // SPDX-License-Identifier: GPL-3.0-only
pragma solidity >=0.8.3;

/// @dev The Randomness contract's address.
address constant RANDOMNESS_ADDRESS = 0x0000000000000000000000000000000000000809;

/// @dev The Randomness contract's instance.
Randomness constant RANDOMNESS_CONTRACT = Randomness(RANDOMNESS_ADDRESS);

/// @dev Maximum number of random words being requested
uint32 constant MAX_RANDOM_WORDS = 100;
/// @dev Minimum number of blocks before a request can be fulfilled for Local VRF Request
uint32 constant MIN_VRF_BLOCKS_DELAY = 2;
/// @dev Maximum number of blocks before a request can be fulfilled for Local VRF Request
uint32 constant MAX_VRF_BLOCKS_DELAY = 2000;
/// @dev The deposit amount needed to request random words. There is 1 deposit per request
uint256 constant REQUEST_DEPOSIT_AMOUNT = 1000000000000000000;

/// @author The Moonbeam Team
/// @title Pallet Randomness Interface
/// @dev The interface through which solidity contracts will interact with Randomness
/// @custom:address 0x0000000000000000000000000000000000000809
interface Randomness {
    /// @notice Event emitted when the request has been successfully executed
    event FulFillmentSucceeded();
    /// @notice Event emitted when the request has failed to execute fulfillment
    event FulFillmentFailed();

    /// @notice The status of the request
    /// @param DoesNotExist The request doesn't exist
    /// @param Pending The request cannot be fulfilled yet
    /// @param Ready The request is ready to be fulfilled
    /// @param Expired The request has expired
    enum RequestStatus {
        DoesNotExist,
        Pending,
        Ready,
        Expired
    }

    /// @notice The type of randomness source
    /// @param LocalVRF Randomness VRF using the parachain material as seed
    /// @param RelayBabeEpoch Randomness VRF using relay material from previous epoch
    enum RandomnessSource {
        LocalVRF,
        RelayBabeEpoch
    }

    /// @notice The request details
    /// @param id The id of the request (is always < 2**64)
    /// @param refundAddress The address receiving the left-over fees after the fulfillment
    /// @param contractAddress The address of the contract being called back during fulfillment
    /// @param fee The amount to set aside to pay for the fulfillment
    /// @param gasLimit The gas limit to use for the fulfillment
    /// @param salt A string being mixed with the randomness seed to obtain different random words. This should be as unique as possible; using the same salt will lead to same randomness result.
    /// @param numWords The number of random words requested (from 1 to MAX_RANDOM_WORDS)
    /// @param randomnessSource The type of randomness source used to generate the random words
    /// @param fulfillmentBlock The parachain block number at which the request can be fulfilled (for LocalVRF only)
    /// @param fulfillmentEpochIndex The relay epoch index at which the request can be fulfilled (for RelayBabeEpoch)
    /// @param expirationBlock The parachain block number at which the request expires (for LocalVRF only)
    /// @param expirationEpochIndex The relay epoch index at which the request expires (for RelayBabeEpoch)
    /// @param status The current status of the request
    struct Request {
        uint256 id;
        address refundAddress;
        address contractAddress;
        uint256 fee;
        uint256 gasLimit;
        bytes32 salt;
        uint32 numWords;
        RandomnessSource randomnessSource;
        uint32 fulfillmentBlock;
        uint64 fulfillmentEpochIndex;
        uint32 expirationBlock;
        uint64 expirationEpochIndex;
        RequestStatus status;
    }

    /// Return the current relay epoch index
    /// @dev An epoch represents real time and not a block number
    /// @dev Currently, time between epoch changes cannot be longer than:
    /// @dev  - Kusama/Westend/Rococo: 600 relay blocks (1 hour)
    /// @dev  - Polkadot: 2400 relay blocks (4 hours)
    /// @custom:selector 81797566
    function relayEpochIndex() external view returns (uint64);

    /// Return the deposit required to perform a request
    /// @dev Each request will need a deposit.
    /// @custom:selector fb7cfdd7
    function requiredDeposit() external view returns (uint256);

    /// @notice Returns the request status
    /// @param requestId The id of the request to check (must be < 2**64)
    /// @return status Status of the request
    /// @custom:selector d8a4676f
    function getRequestStatus(uint256 requestId)
        external
        view
        returns (RequestStatus status);

    /// @notice Returns the request or revert
    /// @param requestId The id of the request to check (must be < 2**64)
    /// @return request The request
    /// @custom:selector c58343ef
    function getRequest(uint256 requestId)
        external
        view
        returns (Request memory request);

    /// @notice Request random words generated from the parachain VRF
    /// @dev This is using pseudo-random VRF executed by the collator at the fulfillment
    /// @dev Warning:
    /// @dev The collator in charge of producing the block at fulfillment can decide to skip
    /// @dev producing the block in order to have a different random word generated by the next
    /// @dev collator, at the cost of a block reward. It is therefore economically viable to use
    /// @dev this randomness source only if the financial reward at stake is lower than the block
    /// @dev reward.
    /// @dev In order to reduce the risk of a collator being able to predict the random words
    /// @dev when the request is performed, it is possible to increase the delay to multiple blocks
    /// @dev The higher the delay is, the less likely the collator will be able to know which
    /// @dev collator will be in charge of fulfilling the request.
    /// @dev Fulfillment is manual and can be executed by anyone (for free) after the given delay
    /// @param refundAddress The address receiving the left-over fees after the fulfillment
    /// @param fee The amount to set aside to pay for the fulfillment
    /// @param gasLimit The gas limit to use for the fulfillment
    /// @param salt A string being mixed with the randomness seed to obtain different random words
    /// @param numWords The number of random words requested (from 1 to MAX_RANDOM_WORDS)
    /// @param delay The number of blocks until the request can be fulfilled (between MIN_DELAY_BLOCKS and MAX_DELAY_BLOCKS)
    /// @return requestId The id of the request requestLocalVRFRandomWords
    /// @custom:selector 9478430c
    function requestLocalVRFRandomWords(
        address refundAddress,
        uint256 fee,
        uint64 gasLimit,
        bytes32 salt,
        uint8 numWords,
        uint64 delay
    ) external returns (uint256);

    /// @notice Request random words generated from the relaychain Babe consensus
    /// @dev The random words are generated from the hash of the all the VRF provided by the
    /// @dev relaychain validator during 1 epoch.
    /// @dev It requires a delay of at least 1 epoch after the current epoch to be unpredictable
    /// @dev at the time the request is performed.
    /// @dev Warning:
    /// @dev The validator (on the relaychain) of the last block of an epoch can decide to skip
    /// @dev producing the block in order to choose the previous generated epoch random number
    /// @dev at the cost of a relaychain block rewards. It is therefore economically viable to use
    /// @dev this randomness source only if the financial reward at stake is lower than the relaychain
    /// @dev block reward.
    /// @dev (see https://crates.parity.io/pallet_babe/struct.RandomnessFromOneEpochAgo.html)
    /// @dev Fulfillment is manual and can be executed by anyone (for free) at
    /// @dev the beginning of the 2nd relay epoch following the current one
    /// @param refundAddress The address receiving the left-over fees after the fulfillment
    /// @param fee Amount to set aside to pay for the fulfillment. Those fees are taken from the contract
    /// @param gasLimit Gas limit for the fulfillment
    /// @param salt Salt to be mixed with raw randomness to get output
    /// @param numWords Number of random words to be returned (limited to MAX_RANDOM_WORDS)
    /// @return requestId The id of the request
    /// @custom:selector 33c14a63
    function requestRelayBabeEpochRandomWords(
        address refundAddress,
        uint256 fee,
        uint64 gasLimit,
        bytes32 salt,
        uint8 numWords
    ) external returns (uint256);

    /// @dev fulFill the request which will call the contract method "fulfillRandomWords"
    /// @dev Fees of the caller are refunded if the request is fulfillable
    /// @param requestId Request to be fulfilled (must be < 2**64)
    /// @custom:selector 9a91eb0d
    function fulfillRequest(uint256 requestId) external;

    /// @param requestId Request receiving the additional fees (must be < 2**64)
    /// @param feeIncrease Amount to increase
    /// @custom:selector d0408a7f
    function increaseRequestFee(uint256 requestId, uint256 feeIncrease)
        external;

    /// @param requestId Request to be purged (must be < 2**64)
    /// @custom:selector 1d26cbab
    function purgeExpiredRequest(uint256 requestId) external;
}
    ```

Similarly, in the `RandomnessConsumer.sol` file, you can paste in the Randomness Consumer contract. 

??? code "RandomnessConsumer.sol"

    ```solidity
    // Inspired by: https://raw.githubusercontent.com/smartcontractkit/chainlink/8e8a996fd882c0861bdc9824c1ca27c857c87d03/contracts/src/v0.8/VRFConsumerBaseV2.sol
// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.8.3;

/// @dev The Randomness contract's address.
address constant RANDOMNESS_ADDRESS = 0x0000000000000000000000000000000000000809;

/** ****************************************************************************
 * @notice Interface for contracts using VRF randomness
 * *****************************************************************************
 * @dev PURPOSE
 *
 * @dev The purpose of this contract is to make it easy for contracts to talk to
 * @dev the Randomness Precompile. It ensures 2 things:
 * @dev 1. The fulfillment came from the Randomness Precompile
 * @dev 2. The consumer contract implements fulfillRandomWords.
 * *****************************************************************************
 * @dev USAGE
 *
 * @dev Calling contracts must inherit from RandomnessConsumer
 *
 * @dev Call one of the randomness request functions:
 * @dev 1. requestLocalVRFRandomWords(refundAddress, fee, gasLimit, salt
 * @dev numWords, delay),
 * @dev 2. requestRelayBabeEpochRandomWords(refundAddress, fee, gasLimit, salt
 * @dev numWords),
 * @dev see (Randomness.sol for a description of each function and their arguments).
 *
 * @dev Once the request has been registered and the minimum delay is passed, the
 * @dev request then can be executed (for 0 fee) by anyone. it will call your
 * @dev contract's fulfillRandomWords method.
 *
 * @dev The randomness argument to fulfillRandomWords is a set of random words
 * @dev generated from your requestId.
 *
 * @dev If your contract could have concurrent requests open, you can use the
 * @dev requestId returned from requestRandomWords to track which response is associated
 * @dev with which randomness request.
 * @dev See "SECURITY CONSIDERATIONS" for principles to keep in mind,
 * @dev if your contract could have multiple requests in flight simultaneously.
 *
 * @dev Colliding `requestId`s are cryptographically impossible as long as seeds
 * @dev differ.
 *
 * *****************************************************************************
 * @dev SECURITY CONSIDERATIONS
 *
 * @dev A method with the ability to call your fulfillRandomness method directly
 * @dev could spoof a VRF response with any random value, so it's critical that
 * @dev it cannot be directly called by anything other than this base contract
 * @dev (specifically, by the RandomnessConsumer.rawFulfillRandomness method).
 *
 * @dev For your users to trust that your contract's random behavior is free
 * @dev from malicious interference, it's best if you can write it so that all
 * @dev behaviors implied by a VRF response are executed *during* your
 * @dev fulfillRandomness method. If your contract must store the response (or
 * @dev anything derived from it) and use it later, you must ensure that any
 * @dev user-significant behavior which depends on that stored value cannot be
 * @dev manipulated by a subsequent VRF request.
 *
 * @dev Similarly, the collators have some influence over the order in which
 * @dev VRF responses appear on the blockchain, so if your contract could have
 * @dev multiple VRF requests in flight simultaneously, you must ensure that
 * @dev the order in which the VRF responses arrive cannot be used to manipulate
 * @dev your contract's user-significant behavior.
 *
 * @dev Since the output of the random words generated for
 * @dev *requestLocalVRFRandomWords* is dependant of the collator producing the
 * @dev block at fulfillment, the collator could skip its block forcing the
 * @dev fulfillment to be executed by a different collator, and therefore
 * @dev generating a different VRF.
 * @dev However, such an attack would incur the cost of losing the block reward to
 * @dev the collator.
 * @dev It is also possible for a collator to be able to predict some of the
 * @dev possible outcome of the VRF if the delay between the request and the
 * @dev fulfillment is too short. It is for this reason that we allow to provide
 * @dev a higher delay
 *
 * @dev Since the output of the random words generated for
 * @dev *requestRelayBabeEpochRandomWords* is dependant of the relaychain
 * @dev validator producing the blocks during an epoch, it is possible for
 * @dev the last validator of an epoch to choose between 2 possible VRF
 * @dev outputs by skipping the production of a block.
 * @dev However, such an attack would incur the cost of losing the block reward to
 * @dev the validator
 * @dev It is not possible for a parachain collator to predict nor influence
 * @dev the output of the relaychain VRF, not to censor the fulfillment as long as
 * @dev there is one honest collator.
 */
abstract contract RandomnessConsumer {
    error OnlyRandomnessPrecompileCanFulfill(address have, address want);

    /**
     * @notice fulfillRandomness handles the VRF response. Your contract must
     * @notice implement it. See "SECURITY CONSIDERATIONS" above for important
     * @notice principles to keep in mind when implementing your fulfillRandomness
     * @notice method.
     *
     * @dev RandomnessConsumer expects its subcontracts to have a method with this
     * @dev signature, and will call it once it has verified the proof
     * @dev associated with the randomness. (It is triggered via a call to
     * @dev rawFulfillRandomness, below.)
     *
     * @param requestId The Id initially returned by requestLocalVRFRandomWords or requestRelayBabeEpochRandomWords
     * @param randomWords The VRF output expanded to the requested number of words
     */
    function fulfillRandomWords(uint256 requestId, uint256[] memory randomWords)
        internal
        virtual;

    // rawFulfillRandomness is called by Randomness Precompile when the executeFulfillement
    // is called. rawFulfillRandomness then calls fulfillRandomness, after validating
    // the origin of the call
    function rawFulfillRandomWords(
        uint256 requestId,
        uint256[] memory randomWords
    ) external {
        if (msg.sender != RANDOMNESS_ADDRESS) {
            revert OnlyRandomnessPrecompileCanFulfill(
                msg.sender,
                RANDOMNESS_ADDRESS
            );
        }
        fulfillRandomWords(requestId, randomWords);
    }
}
    ```


We'll start adding the functionality to the `Lottery.sol` contract in the following section.

## Create the Lottery Smart Contract {: #write-the-lottery-contract }

At a high level, the lottery contract we're creating will define the rules of the lottery, enable participation, and use randomly generated words to select winners fairly. We'll be requesting the random words via the Randomness Precompile. Then we'll use the Randomness Consumer interface to consume the results of the fulfilled request so that our contract can use the randomly generated words to select the winners and pay them out. We'll break down each step of the process as we build the lottery contract, but for now, you can review the following diagram for an overview of the process.

![Diagram of the Lottery process.](/images/tutorials/eth-api/randomness-lottery/lottery-1.webp)

**This contract is for educational purposes only and is not meant for production use.**

To get started, let's set up our lottery contract. We'll need to:

- Import the `Randomness.sol` precompile and `RandomnessConsumer.sol` interface
- Inherit the Randomness Consumer interface
- Create a variable for the Randomness Precompile so we can easily access its functions later on

```solidity
// SPDX-License-Identifier: GPL-3.0-only
pragma solidity >=0.8.0;

import "./Randomness.sol";
import {RandomnessConsumer} from "./RandomnessConsumer.sol";

contract Lottery is RandomnessConsumer {
    // Randomness Precompile interface
    Randomness public randomness =
        Randomness(0x0000000000000000000000000000000000000809);
}
```

### Define Parameters for the Lottery and Randomness Request {: #define-parameters }

Next we're going to need to define the rules of our lottery, such as:

- The participation fee
- The minimum and maximum number of participants
- The minimum length of the lottery
- The number of winners

Inside of the `Lottery` contract, you can add these parameters:

```solidity
// The number of winners. This number corresponds to how many random words
// will be requested. Cannot exceed MAX_RANDOM_WORDS (from the Randomness
// Precompile)
uint8 public NUM_WINNERS = 2;

// The number of blocks before the request can be fulfilled (for Local VRF
// randomness). The MIN_VRF_BLOCKS_DELAY (from the Randomness Precompile) 
// provides a minimum number that is safe enough for games with low economical
// value at stake. Increasing the delay slightly reduces the probability 
// (already very low) of a collator being able to predict the pseudo-random number
uint32 public VRF_BLOCKS_DELAY = MIN_VRF_BLOCKS_DELAY;

// The minimum number of participants to start the lottery
uint256 public MIN_PARTICIPANTS = 3;

// The maximum number of participants allowed to participate. It is important 
// to limit the total jackpot (by limiting the number of participants) to
// guarantee the economic incentive of a collator to avoid trying to influence
// the pseudo-random. (See Randomness.sol for more details)
uint256 public MAX_PARTICIPANTS = 20;

// The fee needed to participate in the lottery. Will go into the jackpot
uint256 public PARTICIPATION_FEE = 100000 gwei;
```

We will also need to define some parameters specifically related to requesting randomness:

- The gas limit for the transaction that fulfills a randomness request
- The minimum fee needed to start the lottery and request the random words. Each request for randomness requires a fulfillment fee. The purpose of this fee is to pay for the fulfillment of a randomness request, which allows anyone to fulfill a request since the request will already have been paid for. When submitting a randomness request, a refund account can be specified, where any excess fees will be returned to. Our contract will be set up so that the owner of the lottery contract will receive the refund
- A salt prefix and the global request count, both of which will be used to generate unique randomness requests

You can go ahead and add these parameters:

```solidity
// The gas limit allowed to be used for the fulfillment, which depends on the
// code that is executed and the number of words requested. Test and adjust
// this limit based on the size of the request and the processing of the 
// callback request in the fulfillRandomWords() function
uint64 public FULFILLMENT_GAS_LIMIT = 100000;

// The minimum fee needed to start the lottery. This does not guarantee that 
// there will be enough fee to pay for the gas used by the fulfillment. 
// Ideally it should be over-estimated considering possible fluctuation of 
// the gas price. Additional fee will be refunded to the caller
uint256 public MIN_FEE = FULFILLMENT_GAS_LIMIT * 150 gwei;

// A string used to allow having different salt than other contracts
bytes32 public SALT_PREFIX = "my_demo_salt_change_me";

// Stores the global number of requests submitted. This number is used as a
// salt to make each request unique
uint256 public globalRequestCount;

```

Aside from these parameters, we'll need to create some variables which will be used to keep track of the current lottery:

- The current request ID
- The list of current participants
- The jackpot
- The owner of the lottery contract. This is necessary because only the owner of the contract will be allowed to start the lottery
- The source of randomness (local VRF or BABE epoch) that is being used

```solidity
// The current request id
uint256 public requestId;

// The list of current participants
address[] public participants;

// The current amount of token at stake in the lottery
uint256 public jackpot;

// the owner of the contract
address owner;

// Which randomness source to use. This correlates to the values in the
// RandomnessSource enum in the Randomness Precompile
Randomness.RandomnessSource randomnessSource;
```

### Create the Constructor {: #create-constructor }

Now that we have completed the initial set up of all of the variables required for the lottery, we can start to code the functions that will bring the lottery to life. First, we'll start off by creating a constructor function.

The constructor will accept a *uint8* as the randomness source, which corresponds to the index of the type of randomness defined in the [`RandomnessSource` enum](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/randomness/Randomness.sol#L44-L47){target=\_blank}, located in the Randomness Precompile. So, we can either pass in `0` for local VRF or `1` for BABE epoch randomness. It will also be `payable`, as we'll submit the deposit at the time of deployment and will be used to perform the randomness request later on.

The [deposit](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/randomness/Randomness.sol#L17){target=\_blank} is defined in the Randomness Precompile and is required in addition to the fulfillment fee. The deposit will be refunded to the original requester, which in our case is the owner of the contract, after the request has been fulfilled. If a request never gets fulfilled, it will expire and need to be purged. Once it is purged, the deposit will be returned.

```solidity
constructor(
    Randomness.RandomnessSource source
) payable RandomnessConsumer() {
    // Because this contract can only perform one randomness request at a time,
    // we only need to have one required deposit
    uint256 requiredDeposit = randomness.requiredDeposit();
    if (msg.value < requiredDeposit) {
        revert("Deposit too Low");
    }
    // Update parameters
    randomnessSource = source;
    owner = msg.sender;
    globalRequestCount = 0;
    jackpot = 0;
    // Set the requestId to the maximum allowed value by the precompile (64 bits)
    requestId = 2 ** 64 - 1;
}
```

### Add Logic to Participate in the Lottery {: #participate-logic }

Next we can create the function that will allow users to participate in the lottery. The `participate` function will be `payable` as each participant will need to submit a participation fee.

The `participate` function will include the following logic:

- Check that the lottery hasn't started yet using the [`getRequestStatus` function](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/randomness/Randomness.sol#L96-L99){target=\_blank} of the Randomness Precompile. This function returns the status as defined by the [`RequestStatus` enum](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/randomness/Randomness.sol#L34-L39){target=\_blank}. If the status is anything other than `DoesNotExist`, then the lottery has already been started
- Check that the participation fee meets the requirement
- If both of the above are true, then the participant will be added to the list of participants and their participation fee will be added to the jackpot

```solidity
function participate() external payable {
    // We check that the lottery hasn't started yet
    if (
        randomness.getRequestStatus(requestId) !=
        Randomness.RequestStatus.DoesNotExist
    ) {
        revert("Request already initiated");
    }

    // Each player must submit a fee to participate, which is added to
    // the jackpot
    if (msg.value != PARTICIPATION_FEE) {
        revert("Invalid participation fee");
    }
    participants.push(msg.sender);
    jackpot += msg.value;
}
```

!!! challenge
    In the above function, we check that the lottery hasn't started yet, but what if we want to know the exact status of the lottery? Create a function that solves this problem and returns the status of the lottery.

### Add Logic to Start the Lottery and Request Randomness {: #start-lottery-logic }

The logic for starting the lottery contains a crucial component: requesting randomness. As previously mentioned, only the owner of the lottery contract will be able to start the lottery. As such, the owner will need to submit the fulfillment fee for the request.

The `startLottery` function will include the following logic:

- Check that the lottery hasn't started yet, as we did in the `participate` function
- Check that there is an acceptable number of participants
- Check that the fulfillment fee meets the minimum requirements
- Check that the balance of the contract is enough to pay for the deposit. Remember how the constructor accepts the request deposit? That deposit is stored in the contract until this function is called
- If all of the above are true, we submit the randomness request via the Randomness Precompile along with the fulfillment fee. Depending on the source of randomness, either the [`requestLocalVRFRandomWords` or the `requestRelayBabeEpochRandomWords` function](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/randomness/Randomness.sol#L110-L167){target=\_blank} of the Randomness Precompile will be called along with the following parameters:
    - The address where excess fees will be refunded to
    - The fulfillment fee
    - The gas limit to use for the fulfillment
    - The salt, which is a string that is mixed with the randomness seed to obtain different random words. The `globalRequestCount` is used to ensure uniqueness
    - The number of random words requested, which is based off the number of winners that will be selected
    - (For local VRF only) The delay, which is the number of blocks that must pass before the request can be fulfilled

Since the lottery function should only be called by the owner, we'll also add in an `onlyOwner` modifier that requires the `msg.sender` to be the `owner`.

```solidity
function startLottery() external payable onlyOwner {
    // Check we haven't started the randomness request yet
    if (
        randomness.getRequestStatus(requestId) !=
        Randomness.RequestStatus.DoesNotExist
    ) {
        revert("Request already initiated");
    }
    // Check that the number of participants is acceptable
    if (participants.length < MIN_PARTICIPANTS) {
        revert("Not enough participants");
    }
    if (participants.length >= MAX_PARTICIPANTS) {
        revert("Too many participants");
    }
    // Check the fulfillment fee is enough
    uint256 fee = msg.value;
    if (fee < MIN_FEE) {
        revert("Not enough fee");
    }
    // Check there is enough balance on the contract to pay for the deposit.
    // This would fail only if the deposit amount required is changed in the
    // Randomness Precompile.
    uint256 requiredDeposit = randomness.requiredDeposit();
    if (address(this).balance < jackpot + requiredDeposit) {
        revert("Deposit too low");
    }

    if (randomnessSource == Randomness.RandomnessSource.LocalVRF) {
        // Request random words using local VRF randomness
        requestId = randomness.requestLocalVRFRandomWords(
            msg.sender,
            fee,
            FULFILLMENT_GAS_LIMIT,
            SALT_PREFIX ^ bytes32(globalRequestCount++),
            NUM_WINNERS,
            VRF_BLOCKS_DELAY
        );
    } else {
        // Requesting random words using BABE Epoch randomness
        requestId = randomness.requestRelayBabeEpochRandomWords(
            msg.sender,
            fee,
            FULFILLMENT_GAS_LIMIT,
            SALT_PREFIX ^ bytes32(globalRequestCount++),
            NUM_WINNERS
        );
    }
}

modifier onlyOwner() {
    require(msg.sender == owner);
    _;
}
```

### Add Logic to Fulfill the Randomness Request {: #fulfill-randomness-logic }

In this section, we'll be adding in two functions required to request fulfillment and handle the result of the fulfillment: `fulfillRequest` and `fulfillRandomWords`.

Our `fulfillRequest` function will call the [`fulfillRequest` method](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/randomness/Randomness.sol#L173){target=\_blank} of the Randomness Precompile. When this method is called, under the hood the [`rawFulfillRandomWords` method](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/randomness/RandomnessConsumer.sol#L114-L125){target=\_blank} of the Randomness Consumer is called, which will verify that the call originated from the Randomness Precompile. From there, the [`fulfillRandomWords` function](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/randomness/RandomnessConsumer.sol#L107-L109){target=\_blank} of the Randomness Consumer contract is called and the requested number of random words are computed using the block's randomness result and a given salt, and then it is returned. If the fulfillment was successful, the `FulfillmentSucceeded` event will be emitted; otherwise, the `FulfillmentFailed` event will be emitted.

For fulfilled requests, the cost of execution will be refunded from the request fee to the caller of `fulfillRequest`. Then any excess fees and the request deposit are transferred to the specified refund address.

Our `fulfillRandomWords` function defines a callback, the `pickWinners` function, that is responsible for handling the fulfillment. So, in our case, the callback will use the random words to select a winner and payout the winnings. The signature of our `fulfillRandomWords` function must match the signature of the Randomness Consumer's `fulfillRandomWords` function.

```solidity
function fulfillRequest() public {
    randomness.fulfillRequest(requestId);
}

function fulfillRandomWords(
    uint256 /* requestId */,
    uint256[] memory randomWords
) internal override {
    pickWinners(randomWords);
}
```

We'll create the logic for the `pickWinners` function in the next section.

!!! challenge
    What if gas prices change significantly before we request the fulfillment, and as a result this function fails? Currently, we wouldn't be able to increase the fulfillment fee. Create a function that solves this problem and allows us to increase the fulfillment fee.

### Add Logic to Pick the Lottery Winners {: #pick-winners-logic }

The last step for our lottery contract will be to create the `pickWinners` function, which, as previously mentioned, is responsible for using the random words to select a winner of the lottery.

The `pickWinners` function contains the following logic:

- Determine the number of winners. This is only necessary if you happened to change either the `NUM_WINNERS` or the number of `MIN_PARTICIPANTS`, so that the `NUM_WINNERS` is greater than the `MIN_PARTICIPANTS`
- Calculate the amount to be awarded to the winners based on the amount in the jackpot and the total number of winners
- Determine the winners by using the random words
- Distribute the winnings to each of the winners, making sure to deduct the winnings from the jackpot before transferring them

```solidity
// This function is called only by the fulfillment callback
function pickWinners(uint256[] memory randomWords) internal {
    // Get the total number of winners to select
    uint256 totalWinners = NUM_WINNERS < participants.length
        ? NUM_WINNERS
        : participants.length;

    // The amount distributed to each winner
    uint256 amountAwarded = jackpot / totalWinners;
    for (uint32 i = 0; i < totalWinners; i++) {
        // This is safe to index randomWords with i because we requested
        // NUM_WINNERS random words
        uint256 randomWord = randomWords[i];

        // Using modulo is not totally fair, but fair enough for this demo
        uint256 index = randomWord % participants.length;
        address payable winner = payable(participants[index]);
        delete participants[index];
        jackpot -= amountAwarded;
        winner.transfer(amountAwarded);
    }
}
```

Congratulations! You've gone through the entire process of creating the `Lottery.sol` contract! You can view the completed version below. Remember, **this contract is for educational purposes only and is not meant for production use.**

??? code "Lottery.sol"

    ```solidity
    // SPDX-License-Identifier: GPL-3.0-only
pragma solidity >=0.8.0;

import "./Randomness.sol";
import {RandomnessConsumer} from "./RandomnessConsumer.sol";

contract Lottery is RandomnessConsumer {
    // Randomness Precompile interface
    Randomness public randomness =
        Randomness(0x0000000000000000000000000000000000000809);

    // The number of winners. This number corresponds to how many random words
    // will be requested. Cannot exceed MAX_RANDOM_WORDS (from the Randomness
    // Precompile)
    uint8 public NUM_WINNERS = 2;

    // The number of blocks before the request can be fulfilled (for Local VRF
    // randomness). The MIN_VRF_BLOCKS_DELAY (from the Randomness Precompile)
    // provides a minimum number that is safe enough for games with low economical
    // value at stake. Increasing the delay slightly reduces the probability
    // (already very low) of a collator being able to predict the pseudo-random number
    uint32 public VRF_BLOCKS_DELAY = MIN_VRF_BLOCKS_DELAY;

    // The minimum number of participants to start the lottery
    uint256 public MIN_PARTICIPANTS = 3;

    // The maximum number of participants allowed to participate. It is important
    // to limit the total jackpot (by limiting the number of participants) to
    // guarantee the economic incentive of a collator to avoid trying to influence
    // the pseudo-random. (See Randomness.sol for more details)
    uint256 public MAX_PARTICIPANTS = 20;

    // The fee needed to participate in the lottery. Will go into the jackpot
    uint256 public PARTICIPATION_FEE = 100000 gwei;

    // The gas limit allowed to be used for the fulfillment, which depends on the
    // code that is executed and the number of words requested. Test and adjust
    // this limit based on the size of the request and the processing of the
    // callback request in the fulfillRandomWords() function
    uint64 public FULFILLMENT_GAS_LIMIT = 100000;

    // The minimum fee needed to start the lottery. This does not guarantee that
    // there will be enough fee to pay for the gas used by the fulfillment.
    // Ideally it should be over-estimated considering possible fluctuation of
    // the gas price. Additional fee will be refunded to the caller
    uint256 public MIN_FEE = FULFILLMENT_GAS_LIMIT * 150 gwei;

    // A string used to allow having different salt than other contracts
    bytes32 public SALT_PREFIX = "INSERT_ANY_STRING_FOR_SALT";

    // Stores the global number of requests submitted. This number is used as a
    // salt to make each request unique
    uint256 public globalRequestCount;

    // The current request id
    uint256 public requestId;

    // The list of current participants
    address[] public participants;

    // The current amount of token at stake in the lottery
    uint256 public jackpot;

    // the owner of the contract
    address owner;

    // Which randomness source to use. This correlates to the values in the
    // RandomnessSource enum in the Randomness Precompile
    Randomness.RandomnessSource randomnessSource;

    constructor(
        Randomness.RandomnessSource source
    ) payable RandomnessConsumer() {
        // Because this contract can only perform one randomness request at a time,
        // we only need to have one required deposit
        uint256 requiredDeposit = randomness.requiredDeposit();
        if (msg.value < requiredDeposit) {
            revert("Deposit too Low");
        }
        // Update parameters
        randomnessSource = source;
        owner = msg.sender;
        globalRequestCount = 0;
        jackpot = 0;
        // Set the requestId to the maximum allowed value by the precompile (64 bits)
        requestId = 2 ** 64 - 1;
    }

    function participate() external payable {
        // We check that the lottery hasn't started yet
        if (
            randomness.getRequestStatus(requestId) !=
            Randomness.RequestStatus.DoesNotExist
        ) {
            revert("Request already initiated");
        }

        // Each player must submit a fee to participate, which is added to
        // the jackpot
        if (msg.value != PARTICIPATION_FEE) {
            revert("Invalid participation fee");
        }
        participants.push(msg.sender);
        jackpot += msg.value;
    }

    function startLottery() external payable onlyOwner {
        // Check we haven't started the randomness request yet
        if (
            randomness.getRequestStatus(requestId) !=
            Randomness.RequestStatus.DoesNotExist
        ) {
            revert("Request already initiated");
        }
        // Check that the number of participants is acceptable
        if (participants.length < MIN_PARTICIPANTS) {
            revert("Not enough participants");
        }
        if (participants.length >= MAX_PARTICIPANTS) {
            revert("Too many participants");
        }
        // Check the fulfillment fee is enough
        uint256 fee = msg.value;
        if (fee < MIN_FEE) {
            revert("Not enough fee");
        }
        // Check there is enough balance on the contract to pay for the deposit.
        // This would fail only if the deposit amount required is changed in the
        // Randomness Precompile.
        uint256 requiredDeposit = randomness.requiredDeposit();
        if (address(this).balance < jackpot + requiredDeposit) {
            revert("Deposit too low");
        }

        if (randomnessSource == Randomness.RandomnessSource.LocalVRF) {
            // Request random words using local VRF randomness
            requestId = randomness.requestLocalVRFRandomWords(
                msg.sender,
                fee,
                FULFILLMENT_GAS_LIMIT,
                SALT_PREFIX ^ bytes32(globalRequestCount++),
                NUM_WINNERS,
                VRF_BLOCKS_DELAY
            );
        } else {
            // Requesting random words using BABE Epoch randomness
            requestId = randomness.requestRelayBabeEpochRandomWords(
                msg.sender,
                fee,
                FULFILLMENT_GAS_LIMIT,
                SALT_PREFIX ^ bytes32(globalRequestCount++),
                NUM_WINNERS
            );
        }
    }

    function fulfillRequest() public {
        randomness.fulfillRequest(requestId);
    }

    function fulfillRandomWords(
        uint256 /* requestId */,
        uint256[] memory randomWords
    ) internal override {
        pickWinners(randomWords);
    }

    // This function is called only by the fulfillment callback
    function pickWinners(uint256[] memory randomWords) internal {
        // Get the total number of winners to select
        uint256 totalWinners = NUM_WINNERS < participants.length
            ? NUM_WINNERS
            : participants.length;

        // The amount distributed to each winner
        uint256 amountAwarded = jackpot / totalWinners;
        for (uint32 i = 0; i < totalWinners; i++) {
            // This is safe to index randomWords with i because we requested
            // NUM_WINNERS random words
            uint256 randomWord = randomWords[i];

            // Using modulo is not totally fair, but fair enough for this demo
            uint256 index = randomWord % participants.length;
            address payable winner = payable(participants[index]);
            delete participants[index];
            jackpot -= amountAwarded;
            winner.transfer(amountAwarded);
        }
    }

    modifier onlyOwner() {
        require(msg.sender == owner);
        _;
    }
}
    ```

!!! challenge
    To make the contract easier to work with, add some events for when a lottery has started, a winner has been chosen, and a winner has been awarded.

## Interact with the Lottery Contract {: #interact-with-lottery-contract }

Now that we've gone through and created our lottery contract, let's deploy it and start a lottery!

### Compile & Deploy the Lottery Contract {: #compile-deploy-lottery-contract }

To compile our contracts, you can simply run:

```bash
npx hardhat compile
```

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>npx hardhat compile</span>
    <span data-ty>Compiled 3 Solidity files successfully</span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>

After compilation, an `artifacts` directory is created: it holds the bytecode and metadata of the contracts, which are `.json` files. It’s a good idea to add this directory to your `.gitignore`.

Before we can deploy the `Lottery.sol` contract, we'll need to create a deployment script.

You can create a new directory for the script and name it `scripts` and add a new file to it called `deploy.js`:

```bash
mkdir scripts && 
touch scripts/deploy.js
```

Now to write the deployment script we can use [`ethers`](/builders/ethereum/libraries/ethersjs/){target=\_blank}. Because we'll be running it with Hardhat, we don't need to import any libraries. We can simply take the following steps:

1. Create a local instance of the lottery contract with the `getContractFactory` method
2. Get the deposit required for a randomness request using the `requiredDeposit` function of the Randomness Precompile
3. Use the `deploy` method that exists within this instance to instantiate the smart contract. You can pass in `0` to use local VRF randomness or `1` for BABE epoch randomness. For this example, we'll use local VRF randomness. We'll also need to submit the deposit upon deployment
4. Wait for the deployment by using `waitForDeployment`
5. Once deployed, we can fetch the address of the contract using the contract instance

```js
async function main() {
  // 1. Get the contract to deploy
  const Lottery = await ethers.getContractFactory('Lottery');

  // 2. Get the required deposit amount from the Randomness Precompile
  const Randomness = await ethers.getContractAt(
    'Randomness',
    '0x0000000000000000000000000000000000000809'
  );
  const deposit = await Randomness.requiredDeposit();

  // 3. Instantiate a new Lottery smart contract that uses local VRF
  // randomness and pass in the required deposit
  const lottery = await Lottery.deploy(0, { value: deposit });
  console.log('Deploying Lottery...');

  // 4. Waiting for the deployment to resolve
  await lottery.waitForDeployment();

  // 5. Use the contract instance to get the contract address
  console.log('Lottery deployed to:', lottery.target);
}

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

```

To deploy our lottery contract, we'll use the `run` command and specify `moonbase` as the network:

```bash
npx hardhat run --network moonbase scripts/deploy.js
```

If you're using another Moonbeam network, make sure that you specify the correct network. The network name needs to match how it's defined in the `hardhat.config.js`.

After a few seconds, the contract is deployed, and you should see the address in the terminal. Save the address, as we will use it to interact with this contract instance in the next step.

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>npx hardhat run --network moonbase scripts/deploy.js</span>
    <span data-ty>Deploying Lottery...</span>
    <span data-ty>Lottery deployed to: 0xc20F6c3dd46fBf83fe484AD80E3EffDb26108A12</span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>

### Create Scripts to Interact with the Lottery Contract {: #participate-in-lottery }

We can continue to work with our Hardhat project and create additional scripts to interact with our lottery contract and call some of it's functions. For example, to participate in the lottery, we can create another script in our `scripts` directory:

```bash
touch participate.js
```

Then we can add the following code, which will create an instance of the lottery contract using the name of the contract and the contract address. Then we can obtain the participation fee directly from the contract and call the contract's `participate` function:

```js
async function participate() {
  const lottery = await ethers.getContractAt(
    'Lottery',
    'INSERT_CONTRACT_ADDRESS'
  );

  const participationFee = await lottery.PARTICIPATION_FEE();
  const tx = await lottery.participate({ value: participationFee });
  console.log('Participation transaction hash:', tx.hash);
}

participate()
  .then(() => process.exit(0))
  .catch((error) => {
    console.error(error);
    process.exit(1);
  });
```

To run this script, you can use the following command:

```bash
npx hardhat run --network moonbase scripts/participate.js
```

The transaction hash will be printed to the console. You can use the hash to look up the transaction on [Moonscan](https://moonbase.moonscan.io){target=\_blank}.

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>npx hardhat run --network moonbase scripts/participate.js</span>
    <span data-ty>Participation transaction hash: 0xc16cb530ea6a29eb50a0f05b2328b53fc271cc342391af2c10f3da329c587326</span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>

And that's it! You can feel free to continue creating additional scripts to perform the next steps of the lottery, such as starting the lottery and picking the winners.

<div class="page-disclaimer">
    This tutorial is for educational purposes only. As such, any contracts or code created in this tutorial should not be used in production.
</div>

<div class="page-disclaimer">
  The information presented herein has been provided by third parties and is made available solely for general information purposes. Moonbeam does not endorse any project listed and described on the Moonbeam Doc Website (https://docs.moonbeam.network/). Moonbeam Foundation does not warrant the accuracy, completeness or usefulness of this information. Any reliance you place on such information is strictly at your own risk. Moonbeam Foundation disclaims all liability and responsibility arising from any reliance placed on this information by you or by anyone who may be informed of any of its contents. All statements and/or opinions expressed in these materials are solely the responsibility of the person or entity providing those materials and do not necessarily represent the opinion of Moonbeam Foundation. The information should not be construed as professional or financial advice of any kind. Advice from a suitably qualified professional should always be sought in relation to any particular matter or circumstance. The information herein may link to or integrate with other websites operated or content provided by third parties, and such other websites may link to this website. Moonbeam Foundation has no control over any such other websites or their content and will have no liability arising out of or related to such websites or their content. The existence of any such link does not constitute an endorsement of such websites, the content of the websites, or the operators of the websites. These links are being provided to you only as a convenience and you release and hold Moonbeam Foundation harmless from any and all liability arising from your use of this information or the information provided by any third-party website or service.
</div>
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/tutorials/eth-api/thirdweb/
--- BEGIN CONTENT ---
---
title: Build an NFT Marketplace DApp with thirdweb
description: Learn how to build an NFT marketplace DApp with thirdweb, including both frontend and smart contract components, in an end-to-end fashion.
categories: Tutorials
---

# How to Build an NFT Marketplace DApp with thirdweb

_by Kevin Neilson_


[thirdweb](https://thirdweb.com/explore){target=\_blank} is a powerful development platform that simplifies building and deploying Web3 applications on the blockchain. It provides pre-built smart contracts and tools, enabling developers to quickly launch applications that interact with NFTs, tokens, and more with less coding and configuration effort.  

In this guide, we'll go step by step through the process of building an NFT marketplace DApp with thirdweb on Moonbeam. We'll deploy all of the associated contracts, including an ERC-721 NFT contract and a marketplace smart contract to Moonbase Alpha with thirdweb, and then we'll integrate them into the DApp.

For a more nuts and bolts approach to thirdweb with information about available methods, the thirdweb CLI and deployment tools, be sure to check out the [thirdweb guide in the Builders section](/builders/ethereum/dev-env/thirdweb/). 

## Clone the Template {: #clone-the-template }

thirdweb has an [NFT marketplace template](https://github.com/thirdweb-example/marketplace-template){target=\_blank} that is a perfect starting point for our needs. We'll only need to make minor customizations to it. Please note, thirdweb frequently updates their templates and tutorials, so ensure that you're using the latest and greatest, which may be located in another repository.

1. In your CLI run the following command:

    ```bash
    git clone https://github.com/thirdweb-example/marketplace-template
    ```

2. Navigate to your project directory and install dependencies with your preferred package manager:

    === "npm"

        ```bash
        npm install
        ```

    === "yarn"

        ```bash
        yarn
        ```

    === "pnpm"

        ```bash
        pnpm install
        ```

Next, you'll need to create a client ID for your thirdweb project and specify it in a `.env` file. 

## Specify Client ID {: #specify-client-id }

Before you launch your dApp (locally or publicly deployed), you must have a thirdweb Client ID associated with your project. A thirdweb Client ID is synonymous with an API key. You can create a free API key by [signing into your thirdweb account and navigating to **Settings** then click on **API Keys**](https://thirdweb.com/dashboard/settings/api-keys){target=\_blank}.

Press **Create API Key** then take the following steps:

1. Give your API key a name
2. Enter the allowed domains that the API key should accept requests from. It's recommended that you allow only necessary domains, but for development purposes, you can select **Allow all domains**
3. Press **Next** and confirm the prompt on the next page

![thirdweb create API key](/images/tutorials/eth-api/thirdweb/thirdweb-1.webp "Creating an API key on thirdweb")

Now, create a file a called `.env.local` at the root level directory of your project. Add your Client ID as follows:

```bash title=".env.local"
NEXT_PUBLIC_TW_CLIENT_ID="INSERT_CLIENT_ID"
```

There are no other fields that you need to specify in your `.env` file at this time. If you're uncertain about formatting, you can refer to the `.env.example` file included in the project.

## Run the project {: #run-the-project }

We're not finished with the project yet, but it should be at a stage where you can launch the template and see the web app load successfully in your browser. 

=== "npm"

    ```bash
    npm run dev
    ```

=== "yarn"

    ```bash
    yarn dev
    ```

=== "pnpm"

    ```bash
    pnpm dev
    ```

If you see a blank screen, this typically means that you've failed to properly configure your client ID. 

## Add Support for Moonbase Alpha {: #add-support-for-moonbase-alpha }

thirdweb offers a small number of chains from `@thirdweb/chains` and does not include Moonbeam networks in that list, so you'll need to specify the network details including chain ID and RPC URL. You can create a custom chain with [`defineChain`](https://portal.thirdweb.com/references/typescript/v5/defineChain){target=\_blank} as follows:

=== "Moonbeam"

    ```typescript title="chains.ts"
    import { defineChain } from 'thirdweb';
    const moonbeam = defineChain({
      id: {{ networks.moonbeam.chain_id }},
      rpc: '{{ networks.moonbeam.public_rpc_url }}',
    });
    ```

=== "Moonriver"

    ```typescript title="chains.ts"
    import { defineChain } from 'thirdweb';
    const moonriver = defineChain({
      id: {{ networks.moonriver.chain_id }},
      rpc: '{{ networks.moonriver.public_rpc_url }}',
    });
    ```

=== "Moonbase Alpha"

    ```typescript title="chains.ts"
    import { defineChain } from 'thirdweb';
    const moonbase = defineChain({
      id: {{ networks.moonbase.chain_id }},
      rpc: '{{ networks.moonbase.rpc_url }}',
    });
    ```

The NFT marketplace template includes a `chains.ts` file under `src/consts/chains.ts`. To add support for Moonbase Alpha to the DApp, add the following lines: 

```typescript title="chains.ts"
export const moonbase = defineChain({
  id: 1287,
  rpc: 'https://rpc.api.moonbase.moonbeam.network',
});
```

We don't need to add any import statements because `defineChain` is already imported by default as part of the template. Feel free to add additional chains if you'd like to add support for Moonbeam, Moonriver, or other networks. The full file can be viewed below:

??? code "View chains.ts"
    ```typescript
    import { defineChain } from 'thirdweb';

/**
 * All chains should be exported from this file
 */
export { avalancheFuji, sepolia, polygonAmoy } from 'thirdweb/chains';

/**
 * Define the Moonbase Alpha test network
 */
export const moonbase = defineChain({
  id: 1287,
  rpc: 'https://rpc.api.moonbase.moonbeam.network',
});
    ```

## Deploy ERC-721 NFT Contract {: #deploy-erc-721-nft-contract }

Of course, we'll need to have an NFT contract to showcase as part of the marketplace. You can use an existing NFT contract, but for demo purposes we'll walk through the steps of deploying a new ERC-721 contract with thirdweb. 

Head to [thirdweb Explore](https://thirdweb.com/explore){target=\_blank} and choose the `OpenEditionERC721` NFT standard. You can also access the [NFT contract directly](https://thirdweb.com/thirdweb.eth/OpenEditionERC721){target=\_blank}. Press **Deploy Now**, then take the following steps:

1. Add a name for your NFT
2. Optionally add a token symbol
3. Upload the image for your NFT. This will be uploaded to IPFS
4. Review the royalty information. By default, this is set to the address of your currently connected wallet and the royalty is set by default to 0%
5. Review the address to receive the proceeds of initial NFT sales. By default, this is set to the address of your currently connected wallet
6. Select your Network as **Moonbase Alpha**
7. Press **Deploy Now**

![Configure ERC-721](/images/tutorials/eth-api/thirdweb/thirdweb-2.webp "Configuring an ERC-721 contract on thirdweb")

You'll be asked for three wallet confirmations - the first two are transactions and the third is a signature. The first transaction deploys the NFT contract and the second sets the NFT metadata. The signature request is simply to add the NFT contract to your dashboard on thirdweb - this is highly recommended as it makes it easy to find your previously deployed NFTs from one easily-accessible place. 

### Set Claim Condition {: #set-claim-condition }

Before any NFTs can be minted, you'll need to configure the claim condition. If you try to mint any NFTs before setting the claim condition, the transaction will be reverted. To configure the claim condition for an open public mint, follow these steps:

1. Head to the **Claim Conditions** page
2. Select **Public phase**
3. Optionally, choose a price to charge per mint. You can also leave this as 0 for a free mint
4. Press **Save Phases**

![Set claim conditions](/images/tutorials/eth-api/thirdweb/thirdweb-3.webp "Setting claim conditions on thirdweb")

### Mint Some NFTs {: #mint-some-nfts } 

For aesthetic purposes, we'd like to have some NFTs show up in the marketplace that we created. Under the **Extensions**, **NFTs** section, press **Claim**. Then, you can mint some NFTs by taking the following steps:

1. Enter the address to receive the NFTs
2. Enter the desired quantity to mint
3. Press **Claim NFT** and confirm the transaction in your wallet

![Mint some NFTs](/images/tutorials/eth-api/thirdweb/thirdweb-4.webp "Minting some NFTs on thirdweb")

### Add NFT Contract to the DApp {: #add-nft-contract-to-the-dapp } 

After deploying and minting your NFTs, you'll need to specify your NFT contract in `src/consts/nft_contract.ts`. First, add `moonbase` to the list of imports as follows: 

```typescript title="nft_contracts.ts"
import { moonbase, avalancheFuji, polygonAmoy, sepolia } from './chains';
```

Then, add your NFT contract to the array of marketplace contracts as follows:

```typescript title="nft_contracts.ts"
  {
    address: '0x5647fb3dB4e47f25659F74b4e96902812f5bE9Fb',
    chain: moonbase,
    title: 'Moonbase NFT',
    thumbnailUrl:
      'https://258c828e8cc853bf5e0efd001055fb39.ipfscdn.io/ipfs/QmTDyLBf2LaG6mzPniPjpX3P4DTFvjAk3gtUgrAb8EVPUF/2024-05-22%2008.17.59.jpg',
    type: 'ERC721',
  },
```

To get the IPFS URL of the image of your NFT that you uploaded when creating the NFT contract, head to the **Events** tab of your NFT contract and locate the `SharedMetadataUpdated` event. Expand the dropdown and you'll see the image URI. You can concatenate this to an IPFS CDN as shown above. 

![Get IPFS URL](/images/tutorials/eth-api/thirdweb/thirdweb-5.webp "Getting the IPFS URL from thirdweb")

The finished file can be viewed below:

??? code "View nft-contracts.ts"
    ```typescript
    import type { Chain } from 'thirdweb';
import { moonbase, avalancheFuji, polygonAmoy } from './chains';

export type NftContract = {
  address: string;
  chain: Chain;
  type: 'ERC1155' | 'ERC721';

  title?: string;
  description?: string;
  thumbnailUrl?: string;
  slug?: string;
};

/**
 * Below is a list of all NFT contracts supported by your marketplace(s).
 * This is of course hard-coded for demo purposes
 *
 * In reality, the list should be dynamically fetched from your own data source
 */
export const NFT_CONTRACTS: NftContract[] = [
  {
    address: '0x6b869a0cF84147f05a447636c42b8E53De65714E',
    chain: avalancheFuji,
    title: 'Steakhouse: Liberatorz',
    thumbnailUrl:
      'https://258c828e8cc853bf5e0efd001055fb39.ipfscdn.io/ipfs/bafybeigonh3hde5suwcb3qvkh6ljtvxv7ubfmcqbwfvi3ihoi3igd27jwe/SteakhouseLogo.svg',
    type: 'ERC721',
  },
  {
    address: '0xC5A2c72c581eA4A17e17bEeF38a9597132830401',
    chain: avalancheFuji,
    title: 'Ugly Waifu',
    thumbnailUrl:
      'https://258c828e8cc853bf5e0efd001055fb39.ipfscdn.io/ipfs/bafybeidaadqapi7twzd7pjp24tu4ngsr3teubrhop7hg3jk3oj6lqysfgm/OS-LOGO.png',
    slug: 'ugly-waifu',
    type: 'ERC721',
  },

  {
    address: '0x0896Db00D8987Fba2152aa7c14c4255eBC7354cE',
    chain: avalancheFuji,
    title: 'Unnamed Collection',
    description: '',
    thumbnailUrl:
      'https://258c828e8cc853bf5e0efd001055fb39.ipfscdn.io/ipfs/Qmct2vS78Uwug3zVtqQognskPPRmd4wRQiaDAQWt1kRJws/0.png',
    slug: 'unnamed-collection',
    type: 'ERC721',
  },
  {
    address: '0x0ACaCa3d3F64bb6e6D3564BBc891c58Bd4A4c83c',
    chain: avalancheFuji,
    title: 'GoroBot',
    thumbnailUrl:
      'https://258c828e8cc853bf5e0efd001055fb39.ipfscdn.io/ipfs/bafybeiay3ffxy3os56bvnu5cmq7gids4v6n4hf5nvvcb3gy2dzavi3ltnu/profile.jpg',
    slug: 'gorobot',
    type: 'ERC721',
  },
  {
    address: '0x4b6CDEFF5885A57678261bb95250aC43aD490752',
    chain: polygonAmoy,
    title: 'Mata NFT',
    thumbnailUrl:
      'https://258c828e8cc853bf5e0efd001055fb39.ipfscdn.io/ipfs/bafybeidec7x6bptqmrxgptaedd7wfwxbsccqfogzwfsd4a7duxn4sdmnxy/0.png',
    type: 'ERC721',
  },
  {
    address: '0xd5e815241882676F772A624E3892b27Ff3a449c4',
    chain: avalancheFuji,
    title: 'Cats (ERC1155)',
    thumbnailUrl:
      'https://258c828e8cc853bf5e0efd001055fb39.ipfscdn.io/ipfs/bafybeif2nz6wbwuryijk2c4ayypocibexdeirlvmciqjyvlzz46mzoirtm/0.png',
    type: 'ERC1155',
  },
  {
    address: '0x5647fb3dB4e47f25659F74b4e96902812f5bE9Fb',
    chain: moonbase,
    title: 'Moonbase NFT',
    thumbnailUrl:
      'https://258c828e8cc853bf5e0efd001055fb39.ipfscdn.io/ipfs/QmTDyLBf2LaG6mzPniPjpX3P4DTFvjAk3gtUgrAb8EVPUF/2024-05-22%2008.17.59.jpg',
    type: 'ERC721',
  },
];
    ```

## Deploy Marketplace Contract {: #deploy-marketplace-contract }

While the template includes existing marketplace contracts for a couple of TestNets, let's deploy a similar one for Moonbase Alpha. Head to [thirdweb Explore](https://thirdweb.com/explore){target=\_blank} and choose the `MarketplaceV3` contract. You can also access [`MarketplaceV3` directly](https://thirdweb.com/thirdweb.eth/MarketplaceV3){target=\_blank}. Press **Deploy Now**, then take the following steps:

1. Add a name for the marketplace
2. Select **Moonbase Alpha** as the network
3. Press **Deploy Now**

You'll be asked to confirm a transaction and provide a signature. The former deploys the marketplace contract and the latter adds the contract to your dashboard on thirdweb (which is not required but highly recommend for keeping track of your contracts).

![Deploy marketplace contract](/images/tutorials/eth-api/thirdweb/thirdweb-6.webp "Deploying a marketplace contract on thirdweb")

### Add Marketplace Contract to the DApp {: #add-marketplace-contract-to-the-dapp }

After deploying your marketplace contract you'll need to specify it in `src/consts/marketplace_contract.ts`. To add support for the Moonbase marketplace first add `moonbase` to the list of imports as follows: 

```typescript title="marketplace_contract.ts"
import { moonbase, avalancheFuji, polygonAmoy, sepolia } from './chains';
```

Then, add your marketplace contract in the array of marketplace contracts as follows:

```typescript title="marketplace_contract.ts"
  {
    address: '0xA76C6E534aa651756Af8c222686fC1D3abF6952A',
    chain: moonbase,
  },
```

The finished file can be viewed below:

??? code "View marketplace-contracts.ts"
    ```typescript
    import type { Chain } from 'thirdweb';
import { moonbase, avalancheFuji, polygonAmoy, sepolia } from './chains';

type MarketplaceContract = {
  address: string;
  chain: Chain;
};

/**
 * You need a marketplace contract on each of the chains you want to support.
 * Only list one marketplace contract address for each chain
 */
export const MARKETPLACE_CONTRACTS: MarketplaceContract[] = [
  {
    address: '0x8C1D464B385A2B7EAa80dcAAD66DD8BC0256e717',
    chain: avalancheFuji,
  },
  {
    address: '0x571B773F1e4A7C080b51C36f37e06f371C515569',
    chain: polygonAmoy,
  },
  {
    address: '0xe0eFD6fb388405b67b3E9FaFc02649c70E749f03',
    chain: sepolia,
  },
  {
    address: '0xA76C6E534aa651756Af8c222686fC1D3abF6952A',
    chain: moonbase,
  },
];
    ```

## Wrapping Up {: #wrapping-up }

And that's it! Congratulations on making it through the tutorial. You can head to `http://localhost:3000` after running the DApp locally via one of the following: 

=== "npm"

    ```bash
    npm run dev
    ```

=== "yarn"

    ```bash
    yarn dev
    ```

=== "pnpm"

    ```bash
    pnpm dev
    ```

On the homepage you should see your newly added NFT contract. Click on the NFT collection and you'll see something that looks like the below:

![View finished product](/images/tutorials/eth-api/thirdweb/thirdweb-7.webp "Viewing the finished product of the NFT marketplace on thirdweb")

For more information on what you can do with thirdweb on Moonbeam be sure to check out the [thirdweb guide in the Builders section](/builders/ethereum/dev-env/thirdweb/) or the [thirdweb documentation site](https://portal.thirdweb.com/){target=\_blank}.

<div class="page-disclaimer">
    This tutorial is for educational purposes only. As such, any contracts or code created in this tutorial should not be used in production.
</div>

<div class="page-disclaimer">
  The information presented herein has been provided by third parties and is made available solely for general information purposes. Moonbeam does not endorse any project listed and described on the Moonbeam Doc Website (https://docs.moonbeam.network/). Moonbeam Foundation does not warrant the accuracy, completeness or usefulness of this information. Any reliance you place on such information is strictly at your own risk. Moonbeam Foundation disclaims all liability and responsibility arising from any reliance placed on this information by you or by anyone who may be informed of any of its contents. All statements and/or opinions expressed in these materials are solely the responsibility of the person or entity providing those materials and do not necessarily represent the opinion of Moonbeam Foundation. The information should not be construed as professional or financial advice of any kind. Advice from a suitably qualified professional should always be sought in relation to any particular matter or circumstance. The information herein may link to or integrate with other websites operated or content provided by third parties, and such other websites may link to this website. Moonbeam Foundation has no control over any such other websites or their content and will have no liability arising out of or related to such websites or their content. The existence of any such link does not constitute an endorsement of such websites, the content of the websites, or the operators of the websites. These links are being provided to you only as a convenience and you release and hold Moonbeam Foundation harmless from any and all liability arising from your use of this information or the information provided by any third-party website or service.
</div>
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/tutorials/eth-api/using-tenderly/
--- BEGIN CONTENT ---
---
title: Using Tenderly to Debug and Simulate Transactions
description: Follow a step-by-step guide on getting started with Tenderly, including using the debugger, forking and simulating transactions, and monitoring smart contracts.
categories: Tutorials
---

# Using Tenderly to Simulate and Debug Transactions

_by Kevin Neilson_

## Introduction {: #introduction }

Tenderly is an all-in-one development platform for EVM networks that enables Web3 developers to build, test, monitor, and operate their smart contracts. Tenderly has a [full suite of product offerings](/builders/ethereum/dev-env/tenderly/) to help you as a developer throughout the lifecycle of a smart contract, from the earliest stages of development to maintenance and alerting on a live production dApp.

Most services offered by Tenderly are free to use, but you'll need to subscribe to a paid plan for advanced features like real-time alerting and war room functionality. Tenderly supports Moonbeam and Moonriver but does not support Moonbase Alpha at this time. For more information about Tenderly's product offerings, be sure to familiarize yourself with the [Introduction to Tenderly](/builders/ethereum/dev-env/tenderly/).

In this tutorial, we're going to explore two of Tenderly's most powerful features, the debugger and the simulator.

## Checking Prerequisites {: #checking-prerequisites }

To get started, you will need the following:

 - Have a free [Tenderly Account](https://dashboard.tenderly.co/register?utm_source=homepage){target=\_blank}. You do not need a paid plan to complete this tutorial

## Create a Tenderly Project {: #create-a-tenderly-project }

Although not strictly required, it's a good idea to create a Tenderly project to keep things organized and access more of Tenderly's available features. Underneath the **Select Project** dropdown, you can press **Create Project** or head directly to the [Create Project](https://dashboard.tenderly.co/projects/create){target=\_blank} page of the dashboard.

Give your project a name, and then press **Create Project**. Although you can change your project name at a later point, the URL will remain the original one you created.

![Create a Tenderly account](/images/tutorials/eth-api/using-tenderly/tenderly-1.webp)

There is a limit of one project with a free account; however, you can have multiple smart contracts under the purview of a single project.

## Add Smart Contracts {: #add-smart-contracts }

Adding a smart contract to your Tenderly project is akin to bookmarking it. While not required, adding a contract will unlock additional Tenderly features over simply searching for the contract on the Tenderly platform.

To add a smart contract to your Tenderly project, click on the **Contracts** tab under the **Inspect** heading, then click **Add Contracts**. Then, take the following steps:

1. Enter the address of the contract. For this tutorial, we'll be using the FRAX stablecoin contract `0x322E86852e492a7Ee17f28a78c663da38FB33bfb`
2. Select the network the contract is deployed to. We'll select **Moonbeam** in this case
3. Give the contract a name to help you recognize it on the dashboard
4. Press **Add Contract**

![Add a smart contract](/images/tutorials/eth-api/using-tenderly/tenderly-2.webp)

## Simulate a Transaction {: #simulate-a-transaction }

Simulations allow you to see how a transaction will execute without actually sending it on the blockchain. You can simulate a transaction against any point in time or simply the latest block.

Head over to the **Simulator** tab, and let's craft a transaction to simulate against the Moonbeam network by taking the following steps:

1. Select the contract that you'd like to interact with. The name displayed here is the nickname that you gave the contract when [adding it to your Tenderly workspace](#add-smart-contracts)
2. Select the contract function you'd like to call. `Transfer` is selected for demonstration purposes
3. Next, we'll input the relevant function parameters. For destination address, you can input any address, such as Alith's address: `0xf24FF3a9CF04c71Dbc94D0b566f7A27B94566cac`
4. For amount, you can also specify any amount, such as `10000000000`
5. Select **Pending Block** to run the simulation against the latest Moonbeam block produced
6. Specify the from address as Baltathar: `0x3Cd0A705a2DC65e5b1E1205896BaA2be8A07c6e0` or another address of your choice
7. Press **Simulate Transaction**

![Simulate a transaction against Moonbeam](/images/tutorials/eth-api/using-tenderly/tenderly-3.webp)

Clearly, this simulated transaction is going to fail because we're trying to send 10,000 FRAX that we don't have. But, with the [Tenderly Simulator](https://docs.tenderly.co/simulator-ui){target=\_blank}, we can tinker with the blockchain state and run simulations that assume different conditions. For example, let's run the simulation assuming that Baltathar actually holds a balance of 10,000 FRAX. Press **Re-Simulate** in the upper right corner, then take the following steps:

1. Expand the **State Overrides** section
2. Press **Add State Override**
3. Select the relevant contract, in this case the FRAX one
4. Under the **Storage Variables** section, we're going to override the mapping that holds the balance of Baltathar by specifying the key as: `balanceOf[0x3Cd0A705a2DC65e5b1E1205896BaA2be8A07c6e0]` and the value as: `10000000000`. Pay careful attention that you are performing this step in the **Storage Variables** section and not the **Balance** section
5. Press **Add** to confirm adding the state override
6. Press **Simulate Transaction**

![Simulate a transaction against Moonbeam with state overrides](/images/tutorials/eth-api/using-tenderly/tenderly-4.webp)

!!! note
    Remember that the Alith and Baltathar accounts are part of the [list of public developer accounts](/builders/get-started/networks/moonbeam-dev/#pre-funded-development-accounts){target=\_blank} with known private keys. You will lose any funds sent to these addresses.

If you correctly added the state override, you should now see a transaction simulation success screen upon running the simulation. If you get an error, you can press **Re-Simulate** and verify that you have configured the state override correctly.

![Transaction simulation with state override success](/images/tutorials/eth-api/using-tenderly/tenderly-5.webp)

You can also access Tenderly's transaction simulator via the [Simulations API](https://docs.tenderly.co/reference/api#tag/Simulations){target=\_blank}.

## Debugging {: #debugging }

The [Debugger](https://docs.tenderly.co/debugger){target=\_blank} is one of the most powerful and acclaimed features of Tenderly. It's also quite fast and requires minimal setup. In fact, if the contract you're investigating is already verified on chain, firing up the debugger is as easy as searching for the transaction hash on Tenderly. Let's try it out.

In the upper search bar, you can paste a contract address or a transaction hash. Recall that Tenderly supports Moonbeam and Moonriver but does not currently support Moonbase Alpha. Here's an example transaction hash of a GLMR / FRAX swap on StellaSwap:

```text
0x80c87ab47e077ca491045047389e6bd88a748ca24971a288d09608834a3bda07
```

After finding the transaction hash, you're greeted at the top with all of the typical statistics about the transaction, such as status, gas price, gas used, etc. Following that, you'll see a breakdown of the tokens transferred. And at the bottom you'll see a long list of every function call. Given that a swap is a relatively complex interaction, and given that StellaSwap uses upgradable proxy contracts, you'll see quite a long list in this example.

![Debugger 1](/images/tutorials/eth-api/using-tenderly/tenderly-6.webp)

If you click on **Contracts** on the left-hand navigation bar, you'll see a list of every contract the transaction interacted with. You can click on a contract to see more details and view the entire source code if the contract is verified.

![Debugger 2](/images/tutorials/eth-api/using-tenderly/tenderly-7.webp)

Heading down the left-hand navigation bar, you'll see an **Events** tab followed by a **State Changes** tab, which shows a visual representation of each change to the chain state that occurred as a result of this transaction.

![Debugger 3](/images/tutorials/eth-api/using-tenderly/tenderly-8.webp)

If you scroll down to the **Debugger** tab, you'll be able to step through the contracts line by line and see key state information at the bottom, allowing you to pinpoint the source of any error.

![Debugger 4](/images/tutorials/eth-api/using-tenderly/tenderly-9.webp)

Finally, you'll see a **Gas Profiler**, which will give you a visual representation of where and how the gas was spent throughout the course of the transaction. You can click on any of the function calls (represented by the blue rectangles) to see how much gas was spent in each call.

![Debugger 4](/images/tutorials/eth-api/using-tenderly/tenderly-10.webp)

For a more detailed look, be sure to check out the [How to Use Tenderly Debugger](https://docs.tenderly.co/debugger){target=\_blank} guide. And that's it! You're well on your way to mastering Tenderly, which is sure to save you time and simplify your development experience building dApps on Moonbeam.

<div class="page-disclaimer">
    This tutorial is for educational purposes only. As such, any contracts or code created in this tutorial should not be used in production.
</div>

<div class="page-disclaimer">
  The information presented herein has been provided by third parties and is made available solely for general information purposes. Moonbeam does not endorse any project listed and described on the Moonbeam Doc Website (https://docs.moonbeam.network/). Moonbeam Foundation does not warrant the accuracy, completeness or usefulness of this information. Any reliance you place on such information is strictly at your own risk. Moonbeam Foundation disclaims all liability and responsibility arising from any reliance placed on this information by you or by anyone who may be informed of any of its contents. All statements and/or opinions expressed in these materials are solely the responsibility of the person or entity providing those materials and do not necessarily represent the opinion of Moonbeam Foundation. The information should not be construed as professional or financial advice of any kind. Advice from a suitably qualified professional should always be sought in relation to any particular matter or circumstance. The information herein may link to or integrate with other websites operated or content provided by third parties, and such other websites may link to this website. Moonbeam Foundation has no control over any such other websites or their content and will have no liability arising out of or related to such websites or their content. The existence of any such link does not constitute an endorsement of such websites, the content of the websites, or the operators of the websites. These links are being provided to you only as a convenience and you release and hold Moonbeam Foundation harmless from any and all liability arising from your use of this information or the information provided by any third-party website or service.
</div>
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/tutorials/integrations/0xgasless/
--- BEGIN CONTENT ---
---
title: Gasless Transactions with 0xGasless
description: Learn how to implement gasless transactions on Moonbeam using 0xGasless, enabling users to interact with smart contracts without holding native tokens.
categories: Tutorials
---

# Enabling Gasless Transactions with 0xGasless

## Why Gasless Transactions?

One of the primary challenges in blockchain development has been the requirement for users to hold native tokens (like ETH or GLMR) to pay transaction fees. This traditional EOA-based model creates unnecessary friction, particularly when onboarding users who expect Web2-like experiences.

Gasless transactions can help solve this through Account Abstraction ([ERC-4337](https://eips.ethereum.org/EIPS/eip-4337){target=\_blank}), implementing meta-transactions that separate user actions from fee payment. This architecture allows dApps or third-party paymasters to cover gas costs on behalf of users while smart contract wallets handle the transaction execution. [0xGasless](https://0xgasless.com/index.html){target=\_blank} leverages these principles in its SDK, enabling Moonbeam developers to implement sophisticated features like social logins, transaction batching, and custom wallet controls – all while abstracting away the complexity of gas management from end users.

In the following tutorial, we'll go through the end-to-end steps of setting up a paymaster on 0xGasless and dispatching a gasless transaction to modify the state of a smart contract on Moonbeam.

## Create and Fund a Paymaster

First, you'll need to [register for an account on 0xGasless](https://dashboard.0xgasless.com/auth/sign-in){target=\_blank}. Then, [create a Paymaster](https://dashboard.0xgasless.com/paymaster){target=\_blank} for the Moonbeam Network by pressing **Create Paymaster** and then taking the following steps:

1. Enter a name for your paymaster
2. Select **Moonbeam** as the chain
3. Press **Create**

![Create Paymaster](/images/tutorials/integrations/0xgasless/0xgasless-1.webp)

Your paymaster needs funds to cover gas fees for sponsored transactions. To deposit GLMR into your paymaster, take the following steps:

1. Enter the amount you would like to deposit
2. Press **Deposit** and confirm the transaction in your wallet

![Fund Paymaster](/images/tutorials/integrations/0xgasless/0xgasless-2.webp)

Your deposited funds remain flexible - use them to sponsor gasless transactions or withdraw them whenever needed.

## Dispatching a Gasless Transaction

In the following section, we'll create a script demonstrating how to dispatch a gasless transaction. 

### Prerequisites

Create a `.env` file in your project's root directory with the following:

```bash
PRIVATE_KEY=INSERT_PRIVATE_KEY
RPC_URL=https://rpc.api.moonbeam.network
```

Why are we specifying a private key in the `.env`? While this transaction will be gasless, you still need a private key to sign the transaction. The account associated with this private key:

- Does not need any GLMR tokens
- Will not pay for gas fees
- Is only used for transaction signing

!!! note 

	Never commit your .env file or share your private key. Add .env to your .gitignore file.

Also, make sure you have installed the 0xGasless SDK and supporting `ethers` and `dotenv` packages:

```bash
npm install ethers dotenv @0xgasless/smart-account
```

First, we'll import the required packages as follows:

```js
require('dotenv').config();
const ethers = require('ethers');
const {
  PaymasterMode,
  createSmartAccountClient,
} = require('@0xgasless/smart-account');
```

Next, we'll set the critical constants. We must define the `CHAIN_ID`, `BUNDLER_URL`, and `PAYMASTER_URL`. You can get your unique paymaster URL from the paymaster on your [0xGasless Dashboard](https://dashboard.0xgasless.com/paymaster){target=\_blank}.

The contract address we've defined here is the address of an [Incrementer contract](https://moonscan.io/address/0x3ae26f2c909eb4f1edf97bf60b36529744b09213) on Moonbeam, on which we'll call the increment function specified by the function selector. This simple contract will allow us to easily see if the gasless transaction has been dispatched successfully. 

```js
const CHAIN_ID = 1284; // Moonbeam mainnet
const BUNDLER_URL = `https://bundler.0xgasless.com/${CHAIN_ID}`;
const PAYMASTER_URL =
  'https://paymaster.0xgasless.com/v1/1284/rpc/INSERT_API_KEY';
const CONTRACT_ADDRESS = '0x3aE26f2c909EB4F1EdF97bf60B36529744b09213';
const FUNCTION_SELECTOR = '0xd09de08a';
```

!!! warning

    The Paymaster URL format has recently changed. Use:

    ```
    https://paymaster.0xgasless.com/v1/1284/rpc/INSERT_API_KEY
    ```

    Do not use the deprecated format:

    ```
    https://paymaster.0xgasless.com/api/v1/1284/rpc/INSERT_API_KEY
    ```

    The difference is that `/api` has been removed from the path. Make sure your code uses the current format.

### Sending the Transaction

To send a gasless transaction using the 0xGasless smart account, you can call `smartWallet.sendTransaction()` with two parameters:

   - The `transaction` object containing the contract interaction details
   - A configuration object specifying `paymasterServiceData` with `SPONSORED` mode. This indicates that the 0xGasless paymaster will use the gas tank to pay for the gas. 

The function returns a UserOperation response containing a hash. Wait for the transaction receipt using the `waitForUserOpReceipt()` helper function, which polls for completion with a configurable timeout (default 60 seconds).

```javascript
const userOpResponse = await smartWallet.sendTransaction(transaction, {
  paymasterServiceData: { mode: PaymasterMode.SPONSORED },
});

const receipt = await waitForUserOpReceipt(userOpResponse, 60000);
```

Putting it all together and adding plenty of logging and error handling for easy debugging, the full script is as follows:

??? code "Dispatch a gasless transaction"
    ```javascript
    require('dotenv').config();
const ethers = require('ethers');
const {
  PaymasterMode,
  createSmartAccountClient,
} = require('@0xgasless/smart-account');

const CHAIN_ID = 1284; // Moonbeam mainnet
const BUNDLER_URL = `https://bundler.0xgasless.com/${CHAIN_ID}`;
const PAYMASTER_URL =
  'https://paymaster.0xgasless.com/v1/1284/rpc/INSERT_API_KEY';
const CONTRACT_ADDRESS = '0x3aE26f2c909EB4F1EdF97bf60B36529744b09213';
const FUNCTION_SELECTOR = '0xd09de08a';

async function main() {
  console.log('Starting the script...');
  try {
    // Set up provider and wallet
    console.log('Setting up provider and wallet...');
    const provider = new ethers.providers.JsonRpcProvider(process.env.RPC_URL);
    const wallet = new ethers.Wallet(process.env.PRIVATE_KEY, provider);

    // Check connection and balance
    console.log('Checking network connection...');
    const network = await provider.getNetwork();
    console.log(
      `Connected to network: ${network.name} (Chain ID: ${network.chainId})`
    );
    const balance = await provider.getBalance(wallet.address);
    console.log(`Wallet balance: ${ethers.utils.formatEther(balance)} GLMR`);

    // Initialize smart account
    console.log('Initializing smart account...');
    const smartWallet = await createSmartAccountClient({
      signer: wallet,
      paymasterUrl: PAYMASTER_URL,
      bundlerUrl: BUNDLER_URL,
      chainId: CHAIN_ID,
    });
    const smartWalletAddress = await smartWallet.getAddress();
    console.log('Smart Account Address:', smartWalletAddress);

    // Create a transaction for contract interaction
    console.log('Creating contract transaction...');
    const transaction = {
      to: CONTRACT_ADDRESS,
      value: '0', // No native token transfer
      data: FUNCTION_SELECTOR, // The function selector for the method we want to call
    };

    // Send the transaction
    console.log('Sending transaction...');
    const userOpResponse = await smartWallet.sendTransaction(transaction, {
      paymasterServiceData: { mode: PaymasterMode.SPONSORED },
    });
    console.log('UserOp Hash:', userOpResponse.hash);

    console.log('Waiting for transaction receipt...');
    const userOpReceipt = await waitForUserOpReceipt(userOpResponse, 60000); // Wait for up to 60 seconds

    if (userOpReceipt.success) {
      console.log('Transaction successful!');
      console.log('Transaction hash:', userOpReceipt.receipt.transactionHash);
    } else {
      console.log('Transaction failed');
      console.log('Receipt:', userOpReceipt);
    }
  } catch (error) {
    console.error('An error occurred:');
    console.error(error);
  }
}

async function waitForUserOpReceipt(userOpResponse, timeoutMs = 60000) {
  return new Promise((resolve, reject) => {
    const startTime = Date.now();
    const checkReceipt = async () => {
      try {
        const receipt = await userOpResponse.wait();
        resolve(receipt);
      } catch (error) {
        if (Date.now() - startTime > timeoutMs) {
          reject(new Error(`Transaction wait timeout after ${timeoutMs}ms`));
        } else {
          setTimeout(checkReceipt, 5000); // Retry every 5 seconds
        }
      }
    };
    checkReceipt();
  });
}

main().catch((error) => {
  console.error('Unhandled error in main function:');
  console.error(error);
});
    ```

### Verifying Completion

Upon running the script, you'll see output that looks like the following: 

<div id="termynal" data-termynal>
    <span data-ty="input">0xgasless % node dispatch.js</span>
    <span data-ty>Starting the script...</span>
    <span data-ty>Setting up provider and wallet...</span>
    <span data-ty>Checking network connection...</span>
    <span data-ty>Connected to network: unknown (Chain ID: 1284)</span>
    <span data-ty>Wallet balance: 8.781249287153010128 GLMR</span>
    <span data-ty>Initializing smart account...</span>
    <span data-ty>Smart Account Address: 0xbBf77D3B43d81D426c4c3D200a76F4D3a914ccE3</span>
    <span data-ty>Creating contract transaction...</span>
    <span data-ty>Sending transaction...</span>
    <span data-ty>UserOp Hash: undefined</span>
    <span data-ty>Waiting for transaction receipt...</span>
    <span data-ty>Transaction successful!</span>
    <span data-ty>Transaction hash: 0x9cb49cc0acc21abc364c13dd52b3f65c206ec61c57a13c23b635f59e1919cf7c</span>
</div>

Since the gasless transaction we initiated interacts with an [Incrementer](https://moonscan.io/address/0x3ae26f2c909eb4f1edf97bf60b36529744b09213#readContract){target=\_blank} smart contract on Moonbeam, it's easy to check to see if the transaction was initiated successfully. You can return to [Read Contract section of the Incrementer contract on Moonscan](https://moonscan.io/address/0x3ae26f2c909eb4f1edf97bf60b36529744b09213#readContract) and check the number stored in the contract. Alternatively, you can head to the **Internal Transactions** tab and toggle advanced mode **ON** to see the contract call incrementing the contract. 

For more information about integrating support for gasless transactions into your dApp, be sure to check out the [0xGasless docs](https://gitbook.0xgasless.com/){target=\_blank}.


<div class="page-disclaimer">
    This tutorial is for educational purposes only. As such, any contracts or code created in this tutorial should not be used in production.
</div>

<div class="page-disclaimer">
  The information presented herein has been provided by third parties and is made available solely for general information purposes. Moonbeam does not endorse any project listed and described on the Moonbeam Doc Website (https://docs.moonbeam.network/). Moonbeam Foundation does not warrant the accuracy, completeness or usefulness of this information. Any reliance you place on such information is strictly at your own risk. Moonbeam Foundation disclaims all liability and responsibility arising from any reliance placed on this information by you or by anyone who may be informed of any of its contents. All statements and/or opinions expressed in these materials are solely the responsibility of the person or entity providing those materials and do not necessarily represent the opinion of Moonbeam Foundation. The information should not be construed as professional or financial advice of any kind. Advice from a suitably qualified professional should always be sought in relation to any particular matter or circumstance. The information herein may link to or integrate with other websites operated or content provided by third parties, and such other websites may link to this website. Moonbeam Foundation has no control over any such other websites or their content and will have no liability arising out of or related to such websites or their content. The existence of any such link does not constitute an endorsement of such websites, the content of the websites, or the operators of the websites. These links are being provided to you only as a convenience and you release and hold Moonbeam Foundation harmless from any and all liability arising from your use of this information or the information provided by any third-party website or service.
</div>
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/tutorials/integrations/local-subsquid/
--- BEGIN CONTENT ---
---
title: Index a Local Development Node
description: Improve your DApp development experience by following this guide to learn how to index a DApp deployed locally on a Moonbeam dev node with SQD (Subsquid)!
categories: Tutorials, Indexer Nodes and Queries
---

# Index a Local Moonbeam Development Node with SQD (formerly Subsquid)

_by Erin Shaben and Kevin Neilson_

## Introduction {: #introduction }

When developing a dApp, it's beneficial to develop smart contracts using a local development environment as opposed to a live network, such as a TestNet or MainNet. Local development removes some of the hassles involved with developing on a live network, like having to fund development accounts and waiting for blocks to be produced. On Moonbeam, developers can spin up their own local [Moonbeam development node](/builders/get-started/networks/moonbeam-dev/){target=\_blank} to quickly and easily build and test applications.

But what about dApps that rely on indexers to index blockchain data? How can developers of these applications streamline the development process? Thanks to [SQD](/builders/integrations/indexers/subsquid/){target=\_blank}, a data network for retrieving data from 100+ chains, it is now possible to index blocks in a local development environment, such as your Moonbeam development node!

This tutorial will walk you through the process of indexing data on a local Moonbeam development node using SQD. We'll create an ERC-20 contract and use SQD to index transfers of our ERC-20.

## Check Prerequisites {: #check-prerequisites }

To follow along with this tutorial, you'll need to have:

- [Docker installed](https://docs.docker.com/get-started/get-docker/){target=\_blank}
- [Docker Compose installed](https://docs.docker.com/compose/install){target=\_blank}
- An empty Hardhat project. For step-by-step instructions, please refer to the [Creating a Hardhat Project](/builders/ethereum/dev-env/hardhat/#creating-a-hardhat-project){target=\_blank} section of our Hardhat documentation page
- An [ERC-20 token deployed](#deploy-an-erc-20-contract) to your local development node, unless you plan on indexing Moonbase Alpha and using an existing ERC-20

We'll configure our Hardhat project and create our SQD project later on in the tutorial.

## Spin up a Local Development Node {: #spin-up-a-local-development-node }

To get started, we're going to spin up a local Moonbeam development node using Docker. For the purposes of this tutorial, we're going to configure our development node to produce (seal) blocks every four seconds. This will ease the debugging process. However, you can feel free to increase or decrease this time or configure your node to instantly seal blocks. When using instant seal, a block will be created when a transaction is received.

We'll use the following commands when starting up our node:

- `--dev` - specifies to use a development chain
- `--sealing 4000` - seals a block every four seconds (4000 milliseconds)
- `--rpc-external` - listen to all HTTP and WebSocket interfaces

To spin up a development node, which will pull the latest Docker image for Moonbeam, you can run the following command:

=== "Ubuntu"

    ```bash
    docker run --rm --name {{ networks.development.container_name }} --network host \
    moonbeamfoundation/moonbeam:{{ networks.development.build_tag }} \
    --dev --sealing 4000 --rpc-external
    ```

=== "MacOS"

    ```bash
    docker run --rm --name {{ networks.development.container_name }} -p 9944:9944 \
    moonbeamfoundation/moonbeam:{{ networks.development.build_tag }} \
    --dev --sealing 4000 --rpc-external
    ```

=== "Windows"

    ```bash
    docker run --rm --name {{ networks.development.container_name }} -p 9944:9944 ^
    moonbeamfoundation/moonbeam:{{ networks.development.build_tag }} ^
    --dev --sealing 4000 --rpc-external
    ```

This will start up our development node, which can be accessed on port 9944. Note that you do not have to use Docker; you can also [run a local node by compiling the Moonbeam binary](/builders/get-started/networks/moonbeam-dev/#getting-started-with-the-binary-file){target=\_blank}.

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>docker run --rm --name moonbeam_development -p 9944:9944 \</span>
    <span data-ty>moonbeamfoundation/moonbeam:v0.45.0 \</span>
    <span data-ty>--dev --rpc-external</span>
    <span data-ty>2025-07-10 09:04:26 Moonbeam Parachain Collator</span>
    <span data-ty>2025-07-10 09:04:26 ✌️  version 0.46.0-d7df89e7161</span>
    <span data-ty>2025-07-10 09:04:26 ❤️  by PureStake, 2019-2025</span>
    <span data-ty>2025-07-10 09:04:26 📋 Chain specification: Moonbase Development Testnet</span>
    <span data-ty>2025-07-10 09:04:26 🏷  Node name: truthful-volcano-8206</span>
    <span data-ty>2025-07-10 09:04:26 👤 Role: AUTHORITY</span>
    <span data-ty>2025-07-10 09:04:26 💾 Database: RocksDb at /tmp/substrate5PF2uR/chains/moonbase_dev/db/full</span>
    <span data-ty>2025-07-10 09:04:26 🔨 Initializing Genesis block/state (state: 0x554b…9ef4, header-hash: 0xbe59…cd6e)</span>
    <span data-ty>2025-07-10 09:04:26 Using default protocol ID "sup" because none is configured in the chain specs</span>
    <span data-ty>2025-07-10 09:04:26 🏷  Local node identity is: 12D3KooWJf8ba9DW6XH6Q7RZZK6qKHyYXAxE7eMSEgLqUDGaNP3n</span>
    <span data-ty>2025-07-10 09:04:26 Running libp2p network backend</span>
    <span data-ty>2025-07-10 09:04:26 💻 Operating system: linux</span>
    <span data-ty>2025-07-10 09:04:26 💻 CPU architecture: x86_64</span>
    <span data-ty>2025-07-10 09:04:26 💻 Target environment: gnu</span>
    <span data-ty>2025-07-10 09:04:26 💻 Memory: 12200MB</span>
    <span data-ty>2025-07-10 09:04:26 💻 Kernel: 6.10.14-linuxkit</span>
    <span data-ty>2025-07-10 09:04:26 💻 Linux distribution: Debian GNU/Linux 12 (bookworm)</span>
    <span data-ty>2025-07-10 09:04:26 💻 Virtual machine: no</span>
    <span data-ty>2025-07-10 09:04:26 📦 Highest known block at #0</span>
    <span data-ty>2025-07-10 09:04:26 〽️ Prometheus exporter started at 127.0.0.1:9615</span>
    <span data-ty>2025-07-10 09:04:26 Running JSON-RPC server: addr=0.0.0.0:9944, allowed origins=["*"]</span>
    <span data-ty>2025-07-10 09:04:26 🏁 CPU score: 708.84 MiBs</span>
    <span data-ty>2025-07-10 09:04:26 🏁 Memory score: 25.72 GiBs</span>
    <span data-ty>2025-07-10 09:04:26 🏁 Disk score (seq. writes): 2.24 GiBs</span>
    <span data-ty>2025-07-10 09:04:26 🏁 Disk score (rand. writes): 717.22 MiBs</span>
    <span data-ty>2025-07-10 09:04:26 Development Service Ready</span>
    <span data-ty>2025-07-10 09:04:26 💤 Idle (0 peers), best: #0 (0xbe59…cd6e), finalized #0 (0xbe59…cd6e), ⬇ 0 ⬆ 0</span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>

Our development node comes with 10 prefunded accounts.

??? note "Development account addresses and private keys"
    - Alith:
    - Public Address: `0xf24FF3a9CF04c71Dbc94D0b566f7A27B94566cac`
    - Private Key: `0x5fb92d6e98884f76de468fa3f6278f8807c48bebc13595d45af5bdc4da702133`

- Baltathar:
    - Public Address: `0x3Cd0A705a2DC65e5b1E1205896BaA2be8A07c6e0`
    - Private Key: `0x8075991ce870b93a8870eca0c0f91913d12f47948ca0fd25b49c6fa7cdbeee8b`

- Charleth:
    - Public Address: `0x798d4Ba9baf0064Ec19eB4F0a1a45785ae9D6DFc`
    - Private Key: `0x0b6e18cafb6ed99687ec547bd28139cafdd2bffe70e6b688025de6b445aa5c5b`

- Dorothy:
    - Public Address: `0x773539d4Ac0e786233D90A233654ccEE26a613D9`
    - Private Key: `0x39539ab1876910bbf3a223d84a29e28f1cb4e2e456503e7e91ed39b2e7223d68`

- Ethan:
    - Public Address: `0xFf64d3F6efE2317EE2807d223a0Bdc4c0c49dfDB`
    - Private Key: `0x7dce9bc8babb68fec1409be38c8e1a52650206a7ed90ff956ae8a6d15eeaaef4`

- Faith:
    - Public Address: `0xC0F0f4ab324C46e55D02D0033343B4Be8A55532d`
    - Private Key: `0xb9d2ea9a615f3165812e8d44de0d24da9bbd164b65c4f0573e1ce2c8dbd9c8df`

- Goliath:
    - Public Address: `0x7BF369283338E12C90514468aa3868A551AB2929`
    - Private Key: `0x96b8a38e12e1a31dee1eab2fffdf9d9990045f5b37e44d8cc27766ef294acf18`

- Heath: 
    - Public Address: `0x931f3600a299fd9B24cEfB3BfF79388D19804BeA`
    - Private Key: `0x0d6dcaaef49272a5411896be8ad16c01c35d6f8c18873387b71fbc734759b0ab`

- Ida: 
    - Public Address: `0xC41C5F1123ECCd5ce233578B2e7ebd5693869d73`
    - Private Key: `0x4c42532034540267bf568198ccec4cb822a025da542861fcb146a5fab6433ff8`

- Judith: 
    - Public Address: `0x2898FE7a42Be376C8BC7AF536A940F7Fd5aDd423`
    - Private Key: `0x94c49300a58d576011096bcb006aa06f5a91b34b4383891e8029c21dc39fbb8b`

For more information on running a Moonbeam development node, please refer to the [Getting Started with a Moonbeam Development Node](/builders/get-started/networks/moonbeam-dev/){target=\_blank} guide.

## Deploy an ERC-20 with Hardhat {: #deploy-an-erc-20-with-hardhat }

You should have already created an empty Hardhat project, but if you haven't done so, you can find instructions in the [Creating a Hardhat Project](/builders/ethereum/dev-env/hardhat/#creating-a-hardhat-project){target=\_blank} section of our Hardhat documentation page.

In this section, we'll configure our Hardhat project for a local Moonbeam development node, create an ERC-20 contract, and write scripts to deploy and interact with our contract.

Before we dive into creating our project, let's install a couple of dependencies that we'll need: the [Hardhat Ethers plugin](https://hardhat.org/hardhat-runner/plugins/nomicfoundation-hardhat-ethers){target=\_blank} and [OpenZeppelin contracts](https://docs.openzeppelin.com/contracts/4.x){target=\_blank}. The Hardhat Ethers plugin provides a convenient way to use the [Ethers](/builders/ethereum/libraries/ethersjs/){target=\_blank} library to interact with the network. We'll use OpenZeppelin's base ERC-20 implementation to create an ERC-20. To install both of these dependencies, you can run:

=== "npm"

    ```bash
    npm install @nomicfoundation/hardhat-ethers ethers@6 @openzeppelin/contracts
    ```

=== "yarn"

    ```bash
    yarn add @nomicfoundation/hardhat-ethers ethers@6 @openzeppelin/contracts
    ```

### Configure Hardhat for a Local Development Node {: #create-a-hardhat-project }

Before we update the configuration file, we'll need to get the private key of one of our development accounts, which will be used to deploy our contract and send transactions. For this example, we'll use Alith's private key:

```text
0x5fb92d6e98884f76de468fa3f6278f8807c48bebc13595d45af5bdc4da702133
```

!!! remember
    **You should never store your private keys in a JavaScript or Python file.**

    The private keys for the development accounts are public knowledge because the accounts exist within your own development environment. However, when you move on to indexing a live network such as Moonbase Alpha or Moonbeam (which is out of scope for this tutorial), you should manage your private keys with a designated secret manager or similar service.

Now we can edit `hardhat.config.js` to include the following network and account configurations for our Moonbeam development node:

???+ code "hardhat.config.js"

    ```js
    // Import the Ethers plugin required to interact with the contract
require('@nomicfoundation/hardhat-ethers');

/** @type import('hardhat/config').HardhatUserConfig */
module.exports = {
  // Specify the Solidity version
  solidity: '0.8.20',
  networks: {
    dev: {
      url: 'http://127.0.0.1:9944',
      chainId: 1281, // (hex: 0x501),
      accounts: [
        '0x5fb92d6e98884f76de468fa3f6278f8807c48bebc13595d45af5bdc4da702133',
      ], // Alith's private key
    },
  },
};
    ```

### Create an ERC-20 Contract {: #create-an-erc-20-contract }

For the purposes of this tutorial, we'll be creating a simple ERC-20 contract. We'll rely on OpenZeppelin's ERC-20 base implementation. We'll start by creating a file for the contract and naming it `MyTok.sol`:

```bash
mkdir -p contracts && touch contracts/MyTok.sol
```

Now we can edit the `MyTok.sol` file to include the following contract, which will mint an initial supply of MYTOKs and allow only the owner of the contract to mint additional tokens:

???+ code "MyTok.sol"

    ```solidity
    // SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract MyTok is ERC20, Ownable {
    constructor() ERC20("MyToken", "MTK") Ownable(msg.sender) {
        _mint(msg.sender, 50000 * 10 ** decimals());
    }

    function mint(address to, uint256 amount) public onlyOwner {
        _mint(to, amount);
    }
}
    ```

### Deploy an ERC-20 Contract {: #deploy-an-erc-20-contract }

Now that we have our contract set up, we can compile and deploy our contract.

To compile the contract, you can run:

```bash
npx hardhat compile
```

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>npx hardhat compile</span>
    <span data-ty>Compiled 6 Solidity files successfully (evm target: paris) </span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>

This command will compile our contract and generate an `artifacts` directory containing the ABI of the contract. To deploy our contract, we'll need to create a deployment script that deploys our ERC-20 contract and mints an initial supply of MYTOKs. We'll use Alith's account to deploy the contract, and we'll specify the initial supply to be 1000 MYTOK. The initial supply will be minted and sent to the contract owner, which is Alith.

Let's take the following steps to deploy our contract:

1. Create a directory and file for our script:

    ```bash
    mkdir -p scripts && touch scripts/deploy.js
    ```

2. In the `deploy.js` file, go ahead and add the following script:

    ???+ code "deploy.js"

        ```js
        // scripts/deploy.js
const hre = require('hardhat');
require('@nomicfoundation/hardhat-ethers');

async function main() {
  // Get ERC-20 contract
  const MyTok = await hre.ethers.getContractFactory('MyTok');

  // Deploy the contract
  const myTok = await MyTok.deploy();

  // Wait for the deployment
  await myTok.waitForDeployment();

  console.log(`Contract deployed to ${myTok.target}`);
}

main().catch((error) => {
  console.error(error);
  process.exitCode = 1;
});
        ```

3. Run the script using the `dev` network configurations we set up in the `hardhat.config.js` file:

    ```bash
    npx hardhat run scripts/deploy.js --network dev
    ```

The address of the deployed contract should be printed to the terminal. Save the address, as we'll need it to interact with the contract in the following section.

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>npx hardhat run scripts/deploy.js --network dev</span>
    <span data-ty>Contract deployed to 0xc01Ee7f10EA4aF4673cFff62710E1D7792aBa8f3</span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>

### Transfer ERC-20s {: #transfer-erc-20s }

Since we'll be indexing `Transfer` events for our ERC-20, we'll need to send a few transactions that transfer some tokens from Alith's account to our other test accounts. We'll do this by creating a simple script that transfers 10 MYTOKs to Baltathar, Charleth, Dorothy, and Ethan. We'll take the following steps:

1. Create a new file script to send transactions:

    ```bash
    touch scripts/transactions.js
    ```

2. In the `transactions.js` file, add the following script and insert the contract address of your deployed MyTok contract (output in the console in the prior step):

    ???+ code "transactions.js"

        ```js
        // We require the Hardhat Runtime Environment explicitly here. This is optional
// but useful for running the script in a standalone fashion through `node <script>`.
//
// You can also run a script with `npx hardhat run <script>`. If you do that, Hardhat
// will compile your contracts, add the Hardhat Runtime Environment's members to the
// global scope, and execute the script.
const hre = require('hardhat');

async function main() {
  // Get contract ABI
  const MyTok = await hre.ethers.getContractFactory('MyTok');

  // Plug ABI to address
  const myTok = await MyTok.attach(
    '0xc01Ee7f10EA4aF4673cFff62710E1D7792aBa8f3'
  );

  const value = 10000000000000000000n;

  let tx;
  // Transfer to Baltathar
  tx = await myTok.transfer(
    '0x3Cd0A705a2DC65e5b1E1205896BaA2be8A07c6e0',
    value
  );
  await tx.wait();
  console.log(`Transfer to Baltathar with TxHash ${tx.hash}`);

  // Transfer to Charleth
  tx = await myTok.transfer(
    '0x798d4Ba9baf0064Ec19eB4F0a1a45785ae9D6DFc',
    value
  );
  await tx.wait();
  console.log(`Transfer to Charleth with TxHash ${tx.hash}`);

  // Transfer to Dorothy
  tx = await myTok.transfer(
    '0x773539d4Ac0e786233D90A233654ccEE26a613D9',
    value
  );
  await tx.wait();
  console.log(`Transfer to Dorothy with TxHash ${tx.hash}`);

  // Transfer to Ethan
  tx = await myTok.transfer(
    '0xFf64d3F6efE2317EE2807d223a0Bdc4c0c49dfDB',
    value
  );
  await tx.wait();
  console.log(`Transfer to Ethan with TxHash ${tx.hash}`);
}

// We recommend this pattern to be able to use async/await everywhere
// and properly handle errors.
main().catch((error) => {
  console.error(error);
  process.exitCode = 1;
});
        ```

3. Run the script to send the transactions:

    ```bash
    npx hardhat run scripts/transactions.js --network dev
    ```

As each transaction is sent, you'll see a log printed to the terminal.

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>npx hardhat run scripts/transactions.js --network dev</span>
    <span data-ty>Transfer to Baltathar with TxHash 0x188eca1c42c6fa63588f998a453e2ce40d7d2166fdaa36b1838226dd06c8e3c2</span>
    <span data-ty>Transfer to Charleth with TxHash 0xc38dfa6addffbdb21d66e009a7c96f17c6dffd9f278fcefb62abb839a14f48be</span>
    <span data-ty>Transfer to Dorothy with TxHash Oxe413ee2dea27ac8d1ec281caff3f5235b098c28e38b7cdcae88455c571d2d3b0</span>
    <span data-ty>Transfer to Ethan with TxHash 0x21cb2a2b8e714a23c12eac41b75a369da06afe8d3bcfa56acf3d68649a4874a1</span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>

Now we can move on to creating our Squid to index the data on our local development node.

## Create a SQD Project {: #create-SQD-project }

Now we're going to create our Subquid project. First, we'll need to install the [SQD CLI](https://docs.sqd.ai/squid-cli/){target=\_blank}:

```bash
npm i -g @subsquid/cli@latest
```

To verify successful installation, you can run:

```bash
sqd --version
```

Now we'll be able to use the `sqd` command to interact with our Squid project. To create our project, we're going to use the `--template` (`-t`) flag, which will create a project from a template. We'll be using the EVM Squid template, which is a starter project for indexing EVM chains.

You can run the following command to create an EVM Squid named `local-squid`:

```bash
sqd init local-squid --template evm
```

This will create a Squid with all of the necessary dependencies. You can go ahead and install the dependencies:

```bash
cd local-squid && npm ci
```

Now that we have a starting point for our project, we'll need to configure our project to index ERC-20 `Transfer` events from our local development node.

### Set Up the Indexer for ERC-20 Transfers {: #set-up-the-indexer-for-erc-20-transfer events}

In order to index ERC-20 transfers, we'll need to take a series of actions:

1. Update the database schema and generate models for the data
2. Use the `ERC20` contract's ABI to generate TypeScript interface classes that will be used by our Squid to index `Transfer` events
3. Configure the processor to process `Transfer` events for the `ERC20` contract
4. Add logic to process the `Transfer` events and save the processed transfer data

As mentioned, we'll first need to define the database schema for the transfer data. To do so, we'll edit the `schema.graphql` file, which is located in the root directory, and create a `Transfer` entity and `Account` entity. You can copy and paste the below schema, ensuring that any existing schema is first removed.

???+ code "schema.graphql"

    ```graphql
    type Account @entity {
  "Account address"
  id: ID!
  transfersFrom: [Transfer!] @derivedFrom(field: "from")
  transfersTo: [Transfer!] @derivedFrom(field: "to")
}

type Transfer @entity {
  id: ID!
  blockNumber: Int!
  timestamp: DateTime!
  txHash: String!
  from: Account!
  to: Account!
  amount: BigInt!
}
    ```

Now we can generate the entity classes from the schema, which we'll use when we process the transfer data. This will create new classes for each entity in the `src/model/generated` directory.

```bash
sqd codegen
```

In the next step, we'll use the ERC-20 ABI to automatically generate TypeScript interface classes. Below is a generic ERC-20 standard ABI. Copy and paste it into a file named `erc20.json` in the `abi` folder at the root level of the project.

??? code "ERC-20 ABI"

    ```json
    [
  {
    "constant": true,
    "inputs": [],
    "name": "name",
    "outputs": [
      {
        "name": "",
        "type": "string"
      }
    ],
    "payable": false,
    "stateMutability": "view",
    "type": "function"
  },
  {
    "constant": false,
    "inputs": [
      {
        "name": "_spender",
        "type": "address"
      },
      {
        "name": "_value",
        "type": "uint256"
      }
    ],
    "name": "approve",
    "outputs": [
      {
        "name": "",
        "type": "bool"
      }
    ],
    "payable": false,
    "stateMutability": "nonpayable",
    "type": "function"
  },
  {
    "constant": true,
    "inputs": [],
    "name": "totalSupply",
    "outputs": [
      {
        "name": "",
        "type": "uint256"
      }
    ],
    "payable": false,
    "stateMutability": "view",
    "type": "function"
  },
  {
    "constant": false,
    "inputs": [
      {
        "name": "_from",
        "type": "address"
      },
      {
        "name": "_to",
        "type": "address"
      },
      {
        "name": "_value",
        "type": "uint256"
      }
    ],
    "name": "transferFrom",
    "outputs": [
      {
        "name": "",
        "type": "bool"
      }
    ],
    "payable": false,
    "stateMutability": "nonpayable",
    "type": "function"
  },
  {
    "constant": true,
    "inputs": [],
    "name": "decimals",
    "outputs": [
      {
        "name": "",
        "type": "uint8"
      }
    ],
    "payable": false,
    "stateMutability": "view",
    "type": "function"
  },
  {
    "constant": true,
    "inputs": [
      {
        "name": "_owner",
        "type": "address"
      }
    ],
    "name": "balanceOf",
    "outputs": [
      {
        "name": "balance",
        "type": "uint256"
      }
    ],
    "payable": false,
    "stateMutability": "view",
    "type": "function"
  },
  {
    "constant": true,
    "inputs": [],
    "name": "symbol",
    "outputs": [
      {
        "name": "",
        "type": "string"
      }
    ],
    "payable": false,
    "stateMutability": "view",
    "type": "function"
  },
  {
    "constant": false,
    "inputs": [
      {
        "name": "_to",
        "type": "address"
      },
      {
        "name": "_value",
        "type": "uint256"
      }
    ],
    "name": "transfer",
    "outputs": [
      {
        "name": "",
        "type": "bool"
      }
    ],
    "payable": false,
    "stateMutability": "nonpayable",
    "type": "function"
  },
  {
    "constant": true,
    "inputs": [
      {
        "name": "_owner",
        "type": "address"
      },
      {
        "name": "_spender",
        "type": "address"
      }
    ],
    "name": "allowance",
    "outputs": [
      {
        "name": "",
        "type": "uint256"
      }
    ],
    "payable": false,
    "stateMutability": "view",
    "type": "function"
  },
  {
    "payable": true,
    "stateMutability": "payable",
    "type": "fallback"
  },
  {
    "anonymous": false,
    "inputs": [
      {
        "indexed": true,
        "name": "owner",
        "type": "address"
      },
      {
        "indexed": true,
        "name": "spender",
        "type": "address"
      },
      {
        "indexed": false,
        "name": "value",
        "type": "uint256"
      }
    ],
    "name": "Approval",
    "type": "event"
  },
  {
    "anonymous": false,
    "inputs": [
      {
        "indexed": true,
        "name": "from",
        "type": "address"
      },
      {
        "indexed": true,
        "name": "to",
        "type": "address"
      },
      {
        "indexed": false,
        "name": "value",
        "type": "uint256"
      }
    ],
    "name": "Transfer",
    "type": "event"
  }
]
    ```

Next, we can use our contract's ABI to generate TypeScript interface classes. We can do this by running:

```bash
sqd typegen
```

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>sqd typegen</span>
    <span data-ty>TYPEGEN</span>
    <span data-ty>22:30:43 INFO sqd:evm-typegen saved src/abi/abi.support.ts</span>
    <span data-ty>22:30:43 INFO sqd:evm-typegen saved src/abi/multicall.ts</span>
    <span data-ty>22:30:43 INFO sqd:evm-typegen processing./abi/erc20.json</span>
    <span data-ty>22:30:43 INFO sqd:evm-typegen saved src/abi/erc20.abi.ts</span>
    <span data-ty>22:30:43 INFO sqd:evm-typegen saved src/abi/erc20.ts</span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>

This will generate the related TypeScript interface classes in the `src/abi/erc20.ts` file. For this tutorial, we'll be accessing the `events` specifically.

### Configure the Processor {: #configure-the-processor}

The `processor.ts` file tells SQD exactly what data you'd like to ingest. Transforming that data into the exact desired format will take place at a later step. In `processor.ts`, we'll need to indicate a data source, a contract address, the event(s) to index, and a block range.

Open up the `src` folder and head to the `processor.ts` file.

To get started, you can import the ERC-20 ABI, which will be used to define the ERC-20 data to be indexed:

```ts
import * as erc20 from './abi/erc20';
```

Next, we need to tell the SQD processor which contract we're interested in. Create a constant for the address in the following manner:

```ts
export const contractAddress = 'INSERT_CONTRACT_ADDRESS'.toLowerCase();
```

The `.toLowerCase()` is critical because the SQD processor is case-sensitive, and some block explorers format contract addresses with capitalization. Next, you'll see the line `export const processor = new EvmBatchProcessor()`, followed by `.setDataSource`. We'll need to make a few changes here. SQD has [available archives for many chains, including Moonbeam, Moonriver, and Moonbase Alpha](http://docs.sqd.ai/evm-indexing/supported-networks/){target=\_blank} that can speed up the data retrieval process. For indexing a local development node, there's no archive necessary so the exclusive data source will be the RPC URL of our local node. Go ahead and comment out or delete the archive line. Once done, your code should look similar to the below:

```ts
.setDataSource({
  chain: {
    url: assertNotNull('{{ networks.development.rpc_url }}'),
    rateLimit: 300,
  },
})
```

The Squid template comes with a variable for your RPC URL defined in your `.env` file. You can replace that with the RPC URL for your local development node. For demonstration purposes, the RPC URL for a local development node is hardcoded directly, as shown above. If you're setting the RPC URL in your `.env`, the respective line will look like this:

```text
RPC_ENDPOINT={{ networks.development.rpc_url }}
```

Now, let's define the event that we want to index by adding the following:

```ts
.addLog({
  address: [contractAddress],
  topic0: [erc20.events.Transfer.topic],
  transaction: true,
})
```

The `Transfer` event is defined in `erc20.ts`, which was auto-generated when `sqd typegen` was run. The import `import * as erc20 from './abi/erc20'` is already included as part of the Squid EVM template.

Block range is an important value to modify to narrow the scope of the blocks you're indexing. For example, if you launched your ERC-20 at block `1200000` on Moonbeam, there is no need to query the chain before that block for `Transfer` events. Since we're indexing a local node, this field can be excluded or set to 0. Setting an accurate block range will improve the performance of your indexer. You can set the earliest block to begin indexing in the following manner:

```ts
.setBlockRange({
  from: 0, // Note the lack of quotes here
});
```

The chosen start block here is 0 since we're indexing a local development node, but if you were indexing data on another Moonbeam network, you should change it to a starting block relevant to what you're indexing.

Change the `setFields` section to specify the following data for our processor to ingest:

```ts
.setFields({
  log: {
    topics: true,
    data: true,
  },
  transaction: {
    hash: true,
  },
})
```

Once you've completed the prior steps, your `processor.ts` file should look similar to this:

???+ code "processor.ts"

    ```ts
    import { assertNotNull } from '@subsquid/util-internal';
import {
  BlockHeader,
  EvmBatchProcessor,
  EvmBatchProcessorFields,
  Log as _Log,
  Transaction as _Transaction,
} from '@subsquid/evm-processor';
import * as erc20 from './abi/erc20';

// Here you'll need to import the contract
export const contractAddress =
  '0xc01Ee7f10EA4aF4673cFff62710E1D7792aBa8f3'.toLowerCase();

export const processor = new EvmBatchProcessor()
  .setDataSource({
    chain: {
      url: assertNotNull('http://127.0.0.1:9944'),
      rateLimit: 300,
    },
  })
  .setFinalityConfirmation(10)
  .setFields({
    log: {
      topics: true,
      data: true,
    },
    transaction: {
      hash: true,
    },
  })
  .addLog({
    address: [contractAddress],
    topic0: [erc20.events.Transfer.topic],
    transaction: true,
  })
  .setBlockRange({
    from: 0, // Note the lack of quotes here
  });

export type Fields = EvmBatchProcessorFields<typeof processor>;
export type Block = BlockHeader<Fields>;
export type Log = _Log<Fields>;
export type Transaction = _Transaction<Fields>;
    ```

### Transform and Save the Data {: #transform-and-save-the-data}

While `processor.ts` determines the data being consumed, `main.ts` determines the bulk of actions related to processing and transforming that data. In the simplest terms, we are processing the data that was ingested via the SQD processor and inserting the desired pieces into a TypeORM database. For more detailed information on how SQD works, be sure to check out the [SQD docs on Developing a Squid](https://docs.sqd.ai/sdk/how-to-start/squid-development/){target=\_blank}

Our `main.ts` file is going to scan through each processed block for the `Transfer` event and decode the transfer details, including the sender, receiver, and amount. The script also fetches account details for involved addresses and creates transfer objects with the extracted data. The script then inserts these records into a TypeORM database enabling them to be easily queried.

Let's break down the code that comprises `main.ts` in order:

1. In `processor.run`, the processor will iterate through all of the selected blocks and look for `Transfer` event logs. Whenever it finds a `Transfer` event, it's going to store it in an array of `Transfer` events where it awaits further processing
2. The `TransferEvent` interface is the type of structure that stores the data extracted from the event logs
3. `getTransfer` is a helper function that extracts and decodes ERC-20 `Transfer` event data from a log entry. It constructs and returns a `TransferEvent` object, which includes details such as the transaction ID, block number, sender and receiver addresses, and the amount transferred. `getTransfer` is called at the time of storing the relevant `Transfer` events into the array of transfers
4. `processTransfers` enriches the transfer data and then inserts these records into a TypeORM database using the `ctx.store` methods. The account model, while not strictly necessary, allows us to introduce another entity in the schema to demonstrate working with multiple entities in your Squid
5. `getAccount` is a helper function that manages the retrieval and creation of account objects. Given an account ID and a map of existing accounts, it returns the corresponding account object. If the account doesn't exist in the map, it creates a new one, adds it to the map, and then returns it

We'll demo a sample query in a later section. You can copy and paste the below code into your `main.ts` file:

???+ code "main.ts"

    ```ts
    import { In } from 'typeorm';
import { assertNotNull } from '@subsquid/evm-processor';
import { TypeormDatabase } from '@subsquid/typeorm-store';
import * as erc20 from './abi/erc20';
import { Account, Transfer } from './model';
import {
  Block,
  contractAddress,
  Log,
  Transaction,
  processor,
} from './processor';

// 1. Iterate through all selected blocks and look for transfer events,
// storing the relevant events in an array of transfer events
processor.run(new TypeormDatabase({ supportHotBlocks: true }), async (ctx) => {
  let transfers: TransferEvent[] = [];

  for (let block of ctx.blocks) {
    for (let log of block.logs) {
      if (
        log.address === contractAddress &&
        log.topics[0] === erc20.events.Transfer.topic
      ) {
        transfers.push(getTransfer(ctx, log));
      }
    }
  }

  await processTransfers(ctx, transfers);
});

// 2. Define an interface to hold the data from the transfer events
interface TransferEvent {
  id: string;
  block: Block;
  transaction: Transaction;
  from: string;
  to: string;
  amount: bigint;
}

// 3. Extract and decode ERC-20 transfer event data from a log entry
function getTransfer(ctx: any, log: Log): TransferEvent {
  let event = erc20.events.Transfer.decode(log);

  let from = event.from.toLowerCase();
  let to = event.to.toLowerCase();
  let amount = event.value;

  let transaction = assertNotNull(log.transaction, `Missing transaction`);

  return {
    id: log.id,
    block: log.block,
    transaction,
    from,
    to,
    amount,
  };
}

// 4. Enrich and insert data into TypeORM database
async function processTransfers(ctx: any, transfersData: TransferEvent[]) {
  let accountIds = new Set<string>();
  for (let t of transfersData) {
    accountIds.add(t.from);
    accountIds.add(t.to);
  }

  let accounts = await ctx.store
    .findBy(Account, { id: In([...accountIds]) })
    .then((q: any[]) => new Map(q.map((i: any) => [i.id, i])));

  let transfers: Transfer[] = [];

  for (let t of transfersData) {
    let { id, block, transaction, amount } = t;

    let from = getAccount(accounts, t.from);
    let to = getAccount(accounts, t.to);

    transfers.push(
      new Transfer({
        id,
        blockNumber: block.height,
        timestamp: new Date(block.timestamp),
        txHash: transaction.hash,
        from,
        to,
        amount,
      })
    );
  }

  await ctx.store.upsert(Array.from(accounts.values()));
  await ctx.store.insert(transfers);
}

// 5. Helper function to get account object
function getAccount(m: Map<string, Account>, id: string): Account {
  let acc = m.get(id);
  if (acc == null) {
    acc = new Account();
    acc.id = id;
    m.set(id, acc);
  }
  return acc;
}
    ```

Now we've taken all of the steps necessary and are ready to run our indexer!

### Run the Indexer {: #run-indexer }

To run our indexer, we're going to run a series of `sqd` commands, as follows:

1. Build our project

    ```bash
    sqd build
    ```

2. Launch the database:

    ```bash
    sqd up
    ```

3. Run the following two commands sequentially:

    ```bash
    sqd migration:generate
    sqd migration:apply
    ```

4. Launch the processor:

    ```bash
    sqd process
    ```

!!! note
    You can review the `commands.json` file to see what each `sqd` command does under the hood.

In your terminal, you should see your indexer starting to process blocks!

<div id="termynal" data-termynal>
    <span data-ty>query: CREATE TABLE "migrations" ("id" SERIAL NOT NULL, "timestamp" bigint NOT NULL, "name" character varying NOT NULL, CONSTRAINT "PK_8c82d7f526340ab734260ea46be" PRIMARY KEY ("id"))</span>
    <span data-ty>query: SELECT * FROM "migrations" "migrations" ORDER BY "id" DESC</span>
    <span data-ty>0 migrations are already loaded in the database.</span>
    <span data-ty>1 migrations were found in the source code.</span>
    <span data-ty>1 migrations are new migrations must be executed.</span>
    <span data-ty>query: START TRANSACTION</span>
    <span data-ty>query: CREATE TABLE "transfer" ("id" character varying NOT NULL, "block_number" integer NOT NULL, "timestamp" TIMESTAMP WITH TIME ZONE NOT NULL, "tx_hash" text NOT NULL, "amount" numeric NOT NULL, "from_id" character varying, "to_id" character varying, CONSTRAINT "PK_fd9ddbdd49a17afcbe014401295" PRIMARY KEY ("id"))</span>
    <span data-ty>query: CREATE INDEX "ID_76bdfed1a7eb27c6d8ecbb7349" ON "transfer" ("from_id")</span>
    <span data-ty>query: CREATE INDEX "IDX_0751309c6697eac9ef1149362" ON "transfer" ("to_id")</span>
    <span data-ty>query: CREATE TABLE "account" ("id" character varying NOT NULL, CONSTRAINT "PK_54115ee388cdb6d86bb4bf5bZea" PRIMARY KEY ("id"))</span>
    <span data-ty>query: ALTER TABLE "transfer" ADD CONSTRAINT "FK_76bdfed1a7eb27c6d8ecbb73496" FOREIGN KEY ("from_id") REFERENCES "account"("id") ON DELETE NO ACTION ON UPDATE NO ACTION</span>
    <span data-ty>query: ALTER TABLE "transfer" ADD CONSTRAINT "FK_0751309c66e97eac9ef11493623" FOREIGN KEY ("to_id") REFERENCES "account"("id") ON DELETE NO ACTION ON UPDATE NO ACTION</span>
    <span data-ty>query: INSERT INTO "migrations" ("timestamp", "name") VALUES ($1, $2) -- PARAMETERS: [1700202953250, "Data1700202953250"]</span>
    <span data-ty>Migration Data1700202953250 has been executed</span>
    <span data-ty>query: COMMIT </span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>

If your Squid isn't indexing blocks properly, make sure that your development node is running with the `--sealing` flag. For this example, you should have set the flag as `--sealing 4000`, so that a block is produced every four seconds. You can feel free to edit the sealing interval as needed. Before you try to spin up your Squid again, run the following commands to restart your Squid:

1. Shut down your Squid

    ```bash
    sqd down
    ```

2. Start your Squid back up:

    ```bash
    sqd up
    ```

3. Start indexing again:

    ```bash
    sqd process
    ```

Now your indexer should be indexing your development node without any problems!

## Query your Squid {: #query-your-squid }

To query your squid, open up a new terminal window within your project and run the following command:

```bash
sqd serve
```

And that's it! You can now run queries against your Squid on the GraphQL playground at `http://localhost:4350/graphql`. Try crafting your own GraphQL query, or use the below one:

???+ code "Sample query"

    ```ts
    query {
  accounts {
    id
    transfersFrom {
      id
      blockNumber
      timestamp
      txHash
      to {
        id
      }
      amount
    }
    transfersTo {
      id
      blockNumber
      timestamp
      txHash
      from {
        id
      }
      amount
    }
  }
}
    ```

![Running queries in GraphQL playground](/images/tutorials/integrations/local-subsquid/new/local-squid-1.webp)

All of the transfers will be returned, including the transfer of the initial supply to Alith's account and the transfers from Alith to Baltathar, Charleth, Dorothy, and Ethan.

And that's it! You've successfully used SQD to index data on a local Moonbeam development node! You can view the entire project on [GitHub](https://github.com/eshaben/local-squid-demo){target=\_blank}.

## Debug Your Squid {: #debug-your-squid }

It may seem tricky at first to debug errors when building your Squid, but fortunately, there are several techniques you can use to streamline this process. First and foremost, if you're facing errors with your Squid, you should enable debug mode in your `.env` file by uncommenting the debug mode line. This will trigger much more verbose logging and will help you locate the source of the error.

```text
# Uncommenting the below line enables debug mode
SQD_DEBUG=*
```

You can also add logging statements directly to your `main.ts` file to indicate specific parameters like block height and more. For example, see this version of `main.ts` which has been enhanced with detailed logging:

??? code "main.ts"

    ```ts
    import { In } from 'typeorm';
import { assertNotNull } from '@subsquid/evm-processor';
import { TypeormDatabase } from '@subsquid/typeorm-store';
import * as erc20 from './abi/erc20';
import { Account, Transfer } from './model';
import {
  Block,
  contractAddress,
  Log,
  Transaction,
  processor,
} from './processor';

processor.run(new TypeormDatabase({ supportHotBlocks: true }), async (ctx) => {
  ctx.log.info('Processor started');
  let transfers: TransferEvent[] = [];

  ctx.log.info(`Processing ${ctx.blocks.length} blocks`);
  for (let block of ctx.blocks) {
    ctx.log.debug(`Processing block number ${block.header.height}`);
    for (let log of block.logs) {
      ctx.log.debug(`Processing log with address ${log.address}`);
      if (
        log.address === contractAddress &&
        log.topics[0] === erc20.events.Transfer.topic
      ) {
        ctx.log.info(`Transfer event found in block ${block.header.height}`);
        transfers.push(getTransfer(ctx, log));
      }
    }
  }

  ctx.log.info(`Found ${transfers.length} transfers, processing...`);
  await processTransfers(ctx, transfers);
  ctx.log.info('Processor finished');
});

interface TransferEvent {
  id: string;
  block: Block;
  transaction: Transaction;
  from: string;
  to: string;
  amount: bigint;
}

function getTransfer(ctx: any, log: Log): TransferEvent {
  let event = erc20.events.Transfer.decode(log);

  let from = event.from.toLowerCase();
  let to = event.to.toLowerCase();
  let amount = event.value;

  let transaction = assertNotNull(log.transaction, `Missing transaction`);

  ctx.log.debug(
    `Decoded transfer event: from ${from} to ${to} amount ${amount.toString()}`
  );
  return {
    id: log.id,
    block: log.block,
    transaction,
    from,
    to,
    amount,
  };
}

async function processTransfers(ctx: any, transfersData: TransferEvent[]) {
  ctx.log.info('Starting to process transfer data');
  let accountIds = new Set<string>();
  for (let t of transfersData) {
    accountIds.add(t.from);
    accountIds.add(t.to);
  }

  ctx.log.debug(`Fetching accounts for ${accountIds.size} addresses`);
  let accounts = await ctx.store
    .findBy(Account, { id: In([...accountIds]) })
    .then((q: any[]) => new Map(q.map((i: any) => [i.id, i])));
  ctx.log.info(
    `Accounts fetched, processing ${transfersData.length} transfers`
  );

  let transfers: Transfer[] = [];

  for (let t of transfersData) {
    let { id, block, transaction, amount } = t;

    let from = getAccount(accounts, t.from);
    let to = getAccount(accounts, t.to);

    transfers.push(
      new Transfer({
        id,
        blockNumber: block.height,
        timestamp: new Date(block.timestamp),
        txHash: transaction.hash,
        from,
        to,
        amount,
      })
    );
  }

  ctx.log.debug(`Upserting ${accounts.size} accounts`);
  await ctx.store.upsert(Array.from(accounts.values()));
  ctx.log.debug(`Inserting ${transfers.length} transfers`);
  await ctx.store.insert(transfers);
  ctx.log.info('Transfer data processing completed');
}

function getAccount(m: Map<string, Account>, id: string): Account {
  let acc = m.get(id);
  if (acc == null) {
    acc = new Account();
    acc.id = id;
    m.set(id, acc);
  }
  return acc;
}
    ```

See the [SQD guide to logging](https://docs.sqd.ai/sdk/reference/logger/){target=\_blank} for more information on debug mode.

### Common Errors {: #common-errors }

Below are some common errors you may face when building a project and how you can solve them.

```text
FATAL sqd:processor RpcError: Expect block number from id: BlockId::Number(15316)
```

This error indicates that your indexer is trying to process blocks that don't exist on your local node. You can resolve this by setting a relevant `to` block limit in your processor as follows:

```ts
.setBlockRange({from: 0, to: 100})
```

Another common error can occur when you're experimenting with multiple instances of SQD on your machine.

```text
Error response from daemon: driver failed programming external connectivity on endpoint my-awesome-squid-db-1
(49df671a7b0531abbb5dc5d2a4a3f5dc7e7505af89bf0ad1e5480bd1cdc61052):
Bind for 0.0.0.0:23798 failed: port is already allocated
```

This error indicates that you have another instance of SQD running somewhere else. You can stop that gracefully with the command `sqd down` or by pressing the **Stop** button next to the container in Docker Desktop.

```text
Error: connect ECONNREFUSED 127.0.0.1:23798
     at createConnectionError (node:net:1634:14)
     at afterConnectMultiple (node:net:1664:40) {
     errno: -61,code: 'ECONNREFUSED',syscall: 'connect',
     address: '127.0.0.1',port: 23798}]}
```

To resolve this, run `sqd up` before you run `sqd migration:generate`.

Is your Squid error-free, yet you aren't seeing any transfers detected? Make sure your log events are consistent and identical to the ones your processor is looking for. Your contract address also needs to be lowercase, which you can be assured of by defining it as follows:

```text
export const contractAddress = '0x37822de108AFFdd5cDCFDaAa2E32756Da284DB85'.toLowerCase();
```

<div class="page-disclaimer">
    This tutorial is for educational purposes only. As such, any contracts or code created in this tutorial should not be used in production.
</div>

<div class="page-disclaimer">
  The information presented herein has been provided by third parties and is made available solely for general information purposes. Moonbeam does not endorse any project listed and described on the Moonbeam Doc Website (https://docs.moonbeam.network/). Moonbeam Foundation does not warrant the accuracy, completeness or usefulness of this information. Any reliance you place on such information is strictly at your own risk. Moonbeam Foundation disclaims all liability and responsibility arising from any reliance placed on this information by you or by anyone who may be informed of any of its contents. All statements and/or opinions expressed in these materials are solely the responsibility of the person or entity providing those materials and do not necessarily represent the opinion of Moonbeam Foundation. The information should not be construed as professional or financial advice of any kind. Advice from a suitably qualified professional should always be sought in relation to any particular matter or circumstance. The information herein may link to or integrate with other websites operated or content provided by third parties, and such other websites may link to this website. Moonbeam Foundation has no control over any such other websites or their content and will have no liability arising out of or related to such websites or their content. The existence of any such link does not constitute an endorsement of such websites, the content of the websites, or the operators of the websites. These links are being provided to you only as a convenience and you release and hold Moonbeam Foundation harmless from any and all liability arising from your use of this information or the information provided by any third-party website or service.
</div>
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/tutorials/integrations/nft-subsquid/
--- BEGIN CONTENT ---
---
title: Index NFT Transfers with SQD (Subsquid)
description: Learn how to use SQD (formerly Subsquid), a query node framework for Substrate-based chains, to index and process NFT transfer data for Moonbeam and Moonriver.
categories: Tutorials, Indexer Nodes and Queries
---

# Indexing NFT Transfers on Moonbeam with SQD (formerly Subsquid)

_by Massimo Luraschi_

## Introduction {: #introduction }

[SQD (formerly Subsquid)](https://www.sqd.ai/){target=\_blank} is a data network that allows rapid and cost-efficient retrieval of blockchain data from 100+ chains using SQD's decentralized data lake and open-source SDK.

The SDK offers a highly customizable Extract-Transform-Load-Query stack and indexing speeds of up to and beyond 50,000 blocks per second when indexing events and transactions.

SQD has native and full support for the Ethereum Virtual Machine (EVM) and Substrate data. This allows developers to extract on-chain data from any of the Moonbeam networks, process EVM logs and Substrate entities (events, extrinsic, and storage items) in one single project, and serve the resulting data with one single GraphQL endpoint. With SQD, filtering by EVM topic, contract address, and block range are all possible.

This guide will explain how to create a SQD project (also known as a _"Squid"_) from a template (indexing Moonsama transfers on Moonriver) and change it to index ERC-721 token transfers on the Moonbeam network. As such, you'll be looking at the `Transfer` EVM event topics. This guide can be adapted for Moonbase Alpha as well.

<div class="intro-disclaimer">
  The information presented herein is for informational purposes only and has been provided by third parties. Moonbeam does not endorse any project listed and described on the Moonbeam docs website (https://docs.moonbeam.network/).
</div>

## Checking Prerequisites {: #checking-prerequisites }

For a Squid project to be able to run, you need to have the following installed:

- Familiarity with Git
- [Node.js](https://nodejs.org/en/download/package-manager){target=\_blank} version 16 or later
- [Docker](https://docs.docker.com/get-started/get-docker/){target=\_blank}
- [Squid CLI](https://docs.sqd.ai/squid-cli/installation/){target=\_blank}

## Scaffold a Project From a Template {: #scaffolding-using-sqd-init }

We will start with the [`frontier-evm` squid template](https://github.com/subsquid-labs/squid-frontier-evm-template){target=\_blank}, available through [`sqd init`](https://docs.sqd.ai/squid-cli/init/){target=\_blank}. It is built to index EVM smart contracts deployed on Moonriver, but it can also index Substrate events. To retrieve the template and install the dependencies, run the following:

```bash
sqd init moonbeam-tutorial --template frontier-evm
cd moonbeam-tutorial
npm ci
```

## Define the Entity Schema {: #define-entity-schema }

Next, we ensure the Squid's data [schema](https://docs.sqd.ai/sdk/reference/schema-file/intro/){target=\_blank} defines the [entities](https://docs.sqd.ai/sdk/reference/schema-file/entities/){target=\_blank} that we want to track. We are interested in:

- Token transfers
- Ownership of tokens
- Contracts and their minted tokens

The EVM template already contains a schema file that defines `Token` and `Transfer` entities, but we need to modify it for our use case and add `Owner` and `Contract` entities:

```graphql title="schema.graphql"
type Token @entity {
  id: ID!
  owner: Owner
  uri: String
  transfers: [Transfer!]! @derivedFrom(field: "token")
  contract: Contract
}

type Owner @entity {
  id: ID!
  ownedTokens: [Token!]! @derivedFrom(field: "owner")
}

type Contract @entity {
  id: ID!
  name: String
  symbol: String
  totalSupply: BigInt
  mintedTokens: [Token!]! @derivedFrom(field: "contract")
}

type Transfer @entity {
  id: ID!
  token: Token!
  from: Owner
  to: Owner
  timestamp: BigInt
  block: BigInt!
}
```

It's worth noting a couple of things in this [schema definition](https://docs.sqd.ai/sdk/reference/schema-file/){target=\_blank}:

- **`@entity`** - signals that this type will be translated into an ORM model that is going to be persisted in the database
- **`@derivedFrom`** - signals that the field will not be persisted in the database. Instead, it will be [derived from](https://docs.sqd.ai/sdk/reference/schema-file/entity-relations/){target=\_blank} the entity relations
- **type references** (e.g., `owner: Owner`) - when used on entity types, they establish a relation between two entities

TypeScript entity classes have to be regenerated whenever the schema is changed, and to do that, we use the `squid-typeorm-codegen` tool. The pre-packaged `commands.json` already comes with a `codegen` shortcut, so we can invoke it with `sqd`:

```bash
sqd codegen
```

The generated entity classes can then be browsed in the `src/model/generated` directory. Each entity should have a `.model.ts` file.

## ABI Definition and Type Generation {: #abi-definition }

SQD maintains [tools](https://docs.sqd.ai/sdk/resources/tools/typegen/generation/?typegen=substrate){target=\_blank} for the automated generation of TypeScript classes to handle Substrate data sources (events, extrinsics, storage items). Possible runtime upgrades are automatically detected and accounted for.

Similar functionality is available for EVM indexing through the [`squid-evm-typegen`](https://docs.sqd.ai/sdk/resources/tools/typegen/generation/?typegen=evm){target=\_blank} tool. It generates TypeScript modules for handling EVM logs and transactions based on a [JSON ABI](https://docs.ethers.org/v6/basics/abi/){target=\_blank} of the contract.

We will need such a module for the [ERC-721](https://eips.ethereum.org/EIPS/eip-721){target=\_blank}-compliant part of the contracts' interfaces for our squid. Once again, the template repository already includes it, but it is still important to explain what needs to be done in case one wants to index a different type of contract.

The procedure uses a `sqd` script from the template that uses `squid-evm-typegen` to generate Typescript facades for JSON ABIs stored in the `abi` folder. Place any ABIs you require for interfacing your contracts there and run:

```bash
sqd typegen:evm
```

The results will be stored at `src/abi`. One module will be generated for each ABI file, including constants useful for filtering, functions for decoding EVM events, and functions defined in the ABI.

## Processor Object and the Batch Handler {: #define-event-handlers }

SQD SDK provides users with the [`SubstrateBatchProcessor` class](https://docs.sqd.ai/sdk/reference/processors/substrate-batch/context-interfaces/){target=\_blank}. The `SubstrateBatchProcessor` declaration and configurations are in the `src/processor.ts` file. Its instances connect to [SQD Network gateways](https://docs.sqd.ai/subsquid-network/reference/networks/){target=\_blank} at chain-specific URLs to get chain data and apply custom transformations. The indexing begins at the starting block and keeps up with new blocks after reaching the tip.

The `SubstrateBatchProcessor` [exposes methods](https://docs.sqd.ai/sdk/reference/processors/substrate-batch/general/){target=\_blank} to "subscribe" to specific data such as Substrate events, extrinsics, storage items, or, for EVM, logs, and transactions. The actual data processing is then started by calling the `.run()` function, as seen in the `src/main.ts` file. This will start generating requests to the gateway for [_batches_](https://docs.sqd.ai/sdk/resources/batch-processing/){target=\_blank} of data specified in the configuration and will trigger the callback function every time a batch is returned by the gateway.

This callback function expresses all the mapping logic. This is where chain data decoding should be implemented and where the code to save processed data on the database should be defined.

### Manage the EVM Contracts {: #managing-the-evm-contracts }

Before we begin defining the mapping logic of the Squid, we will write a `src/contracts.ts` utility module to manage the involved EVM contracts. It will export:

- Addresses of [Exiled Racers Pilots](https://moonbeam.moonscan.io/token/0x515e20e6275ceefe19221fc53e77e38cc32b80fb){target=\_blank} and [Exiled Racers Racecrafts](https://moonbeam.moonscan.io/token/0x104b904e19fbda76bb864731a2c9e01e6b41f855){target=\_blank}
- A `Map` from the contract addresses to hardcoded `Contract` entity instances

Now, let's take a look at the complete contents of the file:

```typescript title="src/contracts.ts"
import { Contract } from './model';

export const pilots =
  '0x515e20e6275CEeFe19221FC53e77E38cc32b80Fb'.toLowerCase();
export const racecrafts =
  '0x104b904e19fBDa76bb864731A2C9E01E6b41f855'.toLowerCase();

export const contractMapping: Map<string, Contract> = new Map();

// Create a Contract entity object for the Exiled Racers Pilot contract
contractMapping.set(
  pilots,
  new Contract({
    id: pilots,
    name: 'Exiled Racers Pilot',
    symbol: 'EXRP',
    totalSupply: 1729n,
    mintedTokens: [],
  })
);

// Create a Contract entity object for the Exiled Racers Racecraft contract
contractMapping.set(
  racecrafts,
  new Contract({
    id: racecrafts,
    name: 'Exiled Racers Racecraft',
    symbol: 'EXRR',
    totalSupply: 1617n,
    mintedTokens: [],
  })
);
```

## Configure the Processor {: #configure-processor }

In the `src/processor.ts` file, Squids instantiate the processor (a `SubstrateBatchProcessor` in our case) and configure it.

We adapt the template code to process EVM logs for the two Exiled Racers contracts and point the processor data source setting to the Moonbeam SQD Network gateway URL. Here is the result:

```typescript title="src/processor.ts"
import { assertNotNull } from '@subsquid/util-internal';
import {
  BlockHeader,
  DataHandlerContext,
  SubstrateBatchProcessor,
  SubstrateBatchProcessorFields,
  Event as _Event,
  Call as _Call,
  Extrinsic as _Extrinsic,
} from '@subsquid/substrate-processor';
import * as erc721 from './abi/erc721';
import { pilots, racecrafts } from './contracts';

export const processor = new SubstrateBatchProcessor()
  .setBlockRange({ from: 1250496 })
  .setGateway('https://v2.archive.subsquid.io/network/moonbeam-substrate')
  .setRpcEndpoint({
    url: assertNotNull(process.env.RPC_ENDPOINT), // TODO: Add the RPC URL to your .env file
    rateLimit: 10,
  })
  // Filter Transfer events from the Exiled Racers Pilot contract
  .addEvmLog({
    address: [pilots],
    range: { from: 1250496 }, // Block of the first transfer
    topic0: [erc721.events.Transfer.topic],
  })
  // Filter Transfer events from the Exiled Racers Racecraft contract
  .addEvmLog({
    address: [racecrafts],
    range: { from: 1398762 }, // Block of the first transfer
    topic0: [erc721.events.Transfer.topic],
  })
  // The timestamp is not provided unless we explicitly request it
  .setFields({
    block: {
      timestamp: true,
    },
  });

export type Fields = SubstrateBatchProcessorFields<typeof processor>;
export type Block = BlockHeader<Fields>;
export type Event = _Event<Fields>;
export type Call = _Call<Fields>;
export type Extrinsic = _Extrinsic<Fields>;
export type ProcessorContext<Store> = DataHandlerContext<Store, Fields>;
```

If you are adapting this guide for Moonbase Alpha, be sure to update the data source to the correct network:

```js
'https://v2.archive.subsquid.io/network/moonbase-substrate'
```

!!! note
    This code expects to find a working Moonbeam RPC URL in the `RPC_ENDPOINT` environment variable. You can get your own endpoint and API key from a supported [Endpoint Provider](/builders/get-started/endpoints/){target=\_blank}.

    Set it in the `.env` file and [SQD Cloud secrets](https://docs.sqd.ai/cloud/resources/env-variables/){target=\_blank} if and when you deploy your Squid there. We tested the code using a public endpoint at `wss://wss.api.moonbeam.network`; we recommend using private endpoints for production.

## Define the Batch Handler {: #define-batch-handler }

We'll need to rewrite the batch handler logic in the `src/main.ts` file.  We'll iterate over all of the events for each batch of blocks to find the EVM logs relative to the Exiled Racers contracts. We'll extract the from and to addresses and the token ID from the EVM logs. Then, we'll format this data as defined in the schema and save it to the database.

Here is the result:

```typescript title="src/main.ts"
import { Store, TypeormDatabase } from '@subsquid/typeorm-store';
import { In } from 'typeorm';
import { contractMapping, pilots, racecrafts } from './contracts';
import { Owner, Token, Transfer } from './model';
import * as erc721 from './abi/erc721';
import { processor, ProcessorContext, Event, Block } from './processor';
import { getEvmLog } from '@subsquid/frontier';

let contractsSaved = false;

processor.run(new TypeormDatabase(), async (ctx) => {
  const transfersData: TransferData[] = [];

  for (const block of ctx.blocks) {
    for (const event of block.events) {
      // If the event is an EVM log and the contract address emitting the log is
      // from the Exiled Racers Pilots or Racecrafts contracts, process the logs
      if (event.name === 'EVM.Log') {
        if (event.args.address) {
          if (
            event.args.address.toLowerCase() == pilots ||
            event.args.address.toLowerCase() == racecrafts
          ) {
            // For each event, get the transfer data
            const transfer = handleTransfer(block.header, event);
            transfersData.push(transfer);
          }
        }
      }
    }
  }

  // Save the contract addresses if they haven't already been saved. This will 
  // only need to happen once, so that is why the contractsSaved flag is used
  if (!contractsSaved) {
    await ctx.store.upsert([...contractMapping.values()]);
    contractsSaved = true;
  }
  await saveTransfers(ctx, transfersData);
});

type TransferData = {
  id: string;
  from: string;
  to: string;
  token: bigint;
  timestamp?: bigint;
  block: number;
  contractAddress: string;
};

function handleTransfer(block: Block, event: Event): TransferData {
  // Decode the event log into an EVM log
  const evmLog = getEvmLog(event);
  // Decode the EVM log to get the from and to addresses and the token ID
  const { from, to, tokenId } = erc721.events.Transfer.decode(evmLog);

  return {
    id: event.id,
    from,
    to,
    token: tokenId,
    timestamp: block.timestamp ? BigInt(block.timestamp) : undefined,
    block: block.height,
    contractAddress: event.args.address,
  };
}

async function saveTransfers(
  ctx: ProcessorContext<Store>,
  transfersData: TransferData[]
) {
  // Format the token ID in SYMBOL-ID format
  const getTokenId = (transferData: TransferData) =>
    `${
      contractMapping.get(transferData.contractAddress)?.symbol ?? ''
    }-${transferData.token.toString()}`;

  const tokensIds: Set<string> = new Set();
  const ownersIds: Set<string> = new Set();

  // Iterate over the transfers data to get the token IDs and owners
  for (const transferData of transfersData) {
    tokensIds.add(getTokenId(transferData));
    ownersIds.add(transferData.from);
    ownersIds.add(transferData.to);
  }

  // Use the token IDs and owners to check the database for existing entries 
  const tokens: Map<string, Token> = new Map(
    (await ctx.store.findBy(Token, { id: In([...tokensIds]) })).map((token) => [
      token.id,
      token,
    ])
  );

  const owners: Map<string, Owner> = new Map(
    (await ctx.store.findBy(Owner, { id: In([...ownersIds]) })).map((owner) => [
      owner.id,
      owner,
    ])
  );

  const transfers: Set<Transfer> = new Set();

  // Process and format all of the data to save to the database
  for (const transferData of transfersData) {
    // Create a contract instance, which will be used to query the
    // contract's tokenURI function below
    const contract = new erc721.Contract(
      ctx,
      { height: transferData.block },
      transferData.contractAddress
    );

    // Try to get the from address from the owners pulled from the database
    let from = owners.get(transferData.from);
    // If there isn't an existing entry for this owner, create one
    if (from == null) {
      from = new Owner({ id: transferData.from });
      owners.set(from.id, from);
    }

    // Try to get the to address from the owners pulled from the database
    let to = owners.get(transferData.to);
    // If there isn't an existing entry for this owner, create one
    if (to == null) {
      to = new Owner({ id: transferData.to });
      owners.set(to.id, to);
    }

    const tokenId = getTokenId(transferData);
    // Try to get the tokenId from the tokens pulled from the database
    let token = tokens.get(tokenId);
    // If there isn't an existing entry for this token, create one
    if (token == null) {
      token = new Token({
        id: tokenId,
        uri: await contract.tokenURI(transferData.token),
        contract: contractMapping.get(transferData.contractAddress),
      });
      tokens.set(token.id, token);
    }

    // Now that the owner entity has been created, we can establish
    // the connection between the Owner and the Token
    token.owner = to;

    // Since the Owner and Token entity objects have been created,
    // the last step is to create the Transfer entity object
    const { id, block, timestamp } = transferData;
    const transfer = new Transfer({
      id,
      block: BigInt(block),
      timestamp,
      from,
      to,
      token,
    });

    transfers.add(transfer);
  }

  // Save all of the data from this batch to the database
  await ctx.store.upsert([...owners.values()]);
  await ctx.store.upsert([...tokens.values()]);
  await ctx.store.insert([...transfers]);
}
```

!!! note
    The `contract.tokenURI` call accesses the **state** of the contract via a chain RPC endpoint. This can slow down indexing, but this data is only available in this way. You'll find more information on accessing state in the [dedicated section of the SQD docs](https://docs.sqd.ai/sdk/resources/tools/typegen/state-queries/#example-1){target=\_blank}.

## Launch and Set Up the Database {: #launch-database }

Squid projects automatically manage the database connection and schema via an [ORM abstraction](https://en.wikipedia.org/wiki/Object%E2%80%93relational\_mapping){target=\_blank}. In this approach, the schema is managed through migration files. Because we made changes to the schema, we need to remove the existing migration(s), create a new one, and then apply the new migration.

This involves the following steps:

1. Make sure you start with a clean Postgres database. The following commands drop-create a new Postgres instance in Docker:

    ```bash
    sqd down
    sqd up
    ```

2. Generate the new migration (this will wipe any old migrations):

    ```bash
    sqd migration:generate
    ```

    !!! note
        This command runs the following commands:

        - `clean` - deletes all the build artifacts
        - `build` - creates a fresh build of the project
        - `migration:clean` - cleans the migration folder
        - `migration:generate` - generates a database migration matching the TypeORM entities

When you launch the processor in the next section, your migrations will be applied automatically. However, if you need to apply them manually, you can do so using the `sqd migration:apply` command.

## Launch the Project {: #launch-project }

To launch the processor, run the following command (this will block the current terminal):

```bash
sqd process
```

!!! note
    This command runs the following commands:

    - `clean` - deletes all the build artifacts
    - `build` - creates a fresh build of the project
    - `migration:apply` - applies the database migrations

Finally, in a separate terminal window, launch the GraphQL server:

```bash
sqd serve
```

Visit `http://localhost:4350/graphql` to access the [GraphiQL](https://github.com/graphql/graphiql){target=\_blank} console. From this window, you can perform queries such as this one to fetch a batch of owners:

```graphql
query MyQuery {
  owners(limit: 10) {
    id
  }
}
```

Or this other one, looking up the tokens owned by a given owner:

```graphql
query MyQuery {
  tokens(where: {owner: {id_eq: "0x09534CF342ad376DdBA6C3e94490C3f161F42ed2"}}) {
    uri
    contract {
      id
      name
      symbol
      totalSupply
    }
  }
}
```

Have fun playing around with queries; after all, it's a _playground_!

## Publish the Project {: #publish-the-project }

SQD offers a SaaS solution to host projects created by its community. All templates ship with a deployment manifest file named `squid.yml`, which can be used with the Squid CLI command `sqd deploy`.

Please refer to the [SQD Cloud Quickstart](https://docs.sqd.ai/cloud/overview/){target=\_blank} page on SQD's documentation site for more information.

## Example Project Repository {: #example-project-repository }

You can view the template used here and many other example repositories [on SQD's examples organization on GitHub](https://github.com/orgs/subsquid-labs/repositories){target=\_blank}.

[SQD's documentation](https://docs.sqd.ai/){target=\_blank} contains informative material, and it's the best place to start if you are curious about some aspects that were not fully explained in this guide.

<div class="page-disclaimer">
    This tutorial is for educational purposes only. As such, any contracts or code created in this tutorial should not be used in production.
</div>

<div class="page-disclaimer">
  The information presented herein has been provided by third parties and is made available solely for general information purposes. Moonbeam does not endorse any project listed and described on the Moonbeam Doc Website (https://docs.moonbeam.network/). Moonbeam Foundation does not warrant the accuracy, completeness or usefulness of this information. Any reliance you place on such information is strictly at your own risk. Moonbeam Foundation disclaims all liability and responsibility arising from any reliance placed on this information by you or by anyone who may be informed of any of its contents. All statements and/or opinions expressed in these materials are solely the responsibility of the person or entity providing those materials and do not necessarily represent the opinion of Moonbeam Foundation. The information should not be construed as professional or financial advice of any kind. Advice from a suitably qualified professional should always be sought in relation to any particular matter or circumstance. The information herein may link to or integrate with other websites operated or content provided by third parties, and such other websites may link to this website. Moonbeam Foundation has no control over any such other websites or their content and will have no liability arising out of or related to such websites or their content. The existence of any such link does not constitute an endorsement of such websites, the content of the websites, or the operators of the websites. These links are being provided to you only as a convenience and you release and hold Moonbeam Foundation harmless from any and all liability arising from your use of this information or the information provided by any third-party website or service.
</div>
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/tutorials/integrations/supra/
--- BEGIN CONTENT ---
---
title: Supra Oracles
description: In this step-by-step tutorial, learn about Supra's pull model and how to use their price feeds to fetch price data in smart contracts on Moonbeam.
categories: Tutorials
---

# Fetching Price Data with Supra Oracles

## Introduction {: #introduction }

Oracles play a crucial role in blockchain ecosystems by facilitating the interaction between smart contracts and external data sources.

Supra Oracles is one Oracle service provider that enables you to retrieve price data from external services and feed it to smart contracts to validate the accuracy of such data and publish it on-chain. Supra achieves this flow using a pull model that fetches price data as needed.

In this guide, you'll learn about Supra's pull model and how to use their price feeds to fetch price data in smart contracts on Moonbeam.

<div class="intro-disclaimer">
  The information presented herein is for informational purposes only and has been provided by third parties. Moonbeam does not endorse any project listed and described on the Moonbeam docs website (https://docs.moonbeam.network/).
</div>

## An Overview of Supra's V1 Pull Model {: #pull-model }

Supra uses a pull model as a customized approach that publishes price data upon request. It combines Web2 and Web3 methods to achieve low latency when sending data from Supra to destination chains. The process involves the following steps:

1. Web2 methods are used to retrieve price data from Supra
2. Smart contracts are utilized for cryptographically verifying and writing the latest price data on-chain, where it lives on immutable ledgers, using [Supra's Pull contract](https://docs.supra.com/oracles/data-feeds/pull-oracle){target=\_blank}
3. Once the data has been written on-chain, the most recently published price feed data will be available in Supra's Storage contract

You can fetch price data from Supra for any [available data pairs](https://docs.supra.com/oracles/data-feeds/data-feeds-index){target=\_blank}.

The addresses for Supra's contracts on Moonbeam are as follows:

=== "Moonbeam"

    |  Contract   |                                                               Address                                                               |
    |:-----------:|:-----------------------------------------------------------------------------------------------------------------------------------:|
    | Pull Oracle | [{{ networks.moonbeam.supra.pull_oracle }}](https://moonscan.io/address/{{ networks.moonbeam.supra.pull_oracle }}){target=\_blank} |
    |   Storage   |     [{{ networks.moonbeam.supra.storage }}](https://moonscan.io/address/{{ networks.moonbeam.supra.storage }}){target=\_blank}     |

=== "Moonbase Alpha"

    |  Contract   |                                                                   Address                                                                    |
    |:-----------:|:--------------------------------------------------------------------------------------------------------------------------------------------:|
    | Pull Oracle | [{{ networks.moonbase.supra.pull_oracle }}](https://moonbase.moonscan.io/address/{{ networks.moonbase.supra.pull_oracle }}){target=\_blank} |
    |   Storage   |     [{{ networks.moonbase.supra.storage }}](https://moonbase.moonscan.io/address/{{ networks.moonbase.supra.storage }}){target=\_blank}     |

!!! note
    Moonriver is not supported at this time.

## Checking Prerequisites {: #checking-prerequisites }

To follow along with this guide, you will need:

- An account with funds.
  You can get DEV tokens for testing on Moonbase Alpha once every 24 hours from the [Moonbase Alpha Faucet](https://faucet.moonbeam.network){target=\_blank}

## Use Web2 Code to Retrieve Price Data {: #web2-retrieve-price-data }

To build out the Web2 component required to fetch price data from Supra, you can use their [Pull Service Client library](https://github.com/Entropy-Foundation/oracle-pull-example){target=\_blank}, designed to interact with a gRPC server to fetch price data. gRPC is a modern remote procedure call (RPC) framework created by Google. You can check out the [gRPC documentation](https://grpc.io/docs/what-is-grpc){target=\_blank} for more information if you need to familiarize yourself.

The library offers JavaScript or Rust-based clients for EVM, Sui, and Aptos-based chains. For Moonbeam, you can use the JavaScript or Rust-based EVM client. We'll use the [JavaScript client](https://github.com/Entropy-Foundation/oracle-pull-example/tree/master/rest/javascript/evm_client){target=\_blank}.

We'll copy the JavaScript client code and add it to our project, but you can also clone the [repository](https://github.com/Entropy-Foundation/oracle-pull-example){target=\_blank} with all the clients.

### Create a Project {: #create-a-project }

Follow these steps to create your project:

1. Create an empty project directory

    ```
    mkdir moonbeam-supra
    ```

2. Create a basic `package.json` file for your project

    ```
    cd moonbeam-supra && npm init-y
    ```

3. Install dependencies needed to work with Supra's gRPC server

    ```
    npm install @grpc/grpc-js @grpc/proto-loader
    ```

### Create the Pull Service Client {: #create-pull-service-client }

To create the pull service client, you'll need to create two files: one that defines the schema for the gRPC service, `client.proto`, and another that relies on the schema and is used to fetch the proof for a given data pair, `pullServiceClient.js`.

You can create both files using the following command:

```bash
touch client.proto pullServiceClient.js
```

Then, you can copy the following code snippets and add them to their respective files:

???+ code "Pull service client files"

    === "client.proto"

        ```proto
        syntax = "proto3";

package pull_service;

message PullResponse {
  oneof resp {
    PullResponseEvm evm = 1;
    PullResponseSui sui = 2;
    PullResponseAptos aptos = 3;
  }
}

service PullService {
  rpc GetProof(PullRequest) returns (PullResponse);
}

message PullRequest {
  repeated uint32 pair_indexes = 1;
  string chain_type = 2;
}

message PullResponseEvm {
  repeated uint32 pair_indexes = 1;
  bytes proof_bytes = 2;
}
        ```

    === "pullServiceClient.js"

        ```js
        const grpc = require('@grpc/grpc-js');
const protoLoader = require('@grpc/proto-loader');

class PullServiceClient {
  constructor(address) {
    var PROTO_PATH = __dirname + './client.proto';
    const packageDefinition = protoLoader.loadSync(PROTO_PATH, {
      keepCase: true,
      longs: String,
      enums: String,
      defaults: true,
      oneofs: true,
    });

    const pullProto =
      grpc.loadPackageDefinition(packageDefinition).pull_service;
    this.client = new pullProto.PullService(
      address,
      grpc.credentials.createSsl()
    );
  }

  getProof(request, callback) {
    this.client.getProof(request, callback);
  }
}

module.exports = PullServiceClient;
        ```

### Use the Pull Service Client to Fetch Price Data {: #use-the-pull-service-client }

In this section, you'll create an instance of the `PullServiceClient` to retrieve the proof for the ETH_USDT pair. You can modify this example for any of the [available data pairs](https://docs.supra.com/oracles/data-feeds/data-feeds-index){target=\_blank}.

To get started, create a file to add our logic:

```bash
touch main.js
```

In the `main.js` file, take the following steps to add the logic for retrieving proof data:

1. Import the `PullServiceClient` from the `pullServiceClient.js` file

    ```js title="main.js"
    const PullServiceClient = require('./pullServiceClient');
const oracleProofABI = require('./resources/oracleProof.json');
const signedCoherentClusterABI = require('./resources/signedCoherentCluster.json');
const { Web3 } = require('web3');
const oracleClientABI = require('./resources/oracleClient.json');
const feedClientABI = require('./resources/feedClient.json'); 

const web3 = new Web3('https://rpc.api.moonbeam.network');
const pairIndex = 1;

// Function that fetches proof data from the gRPC server using the specified parameters
const getProofs = () => {
  const address = 'mainnet-dora.supraoracles.com';
  const client = new PullServiceClient(address);

  const request = {
    pair_indexes: [pairIndex], // ETH_USDT
    chain_type: 'evm',
  };

  return new Promise((resolve, reject) => {
    client.getProof(request, (err, response) => {
      if (err) {
        console.error('Error:', err.details);
        return;
      }
      resolve(response);
    });
  });
};

// Function to convert the proof data to human-readable price data
const deserializeProofBytes = (proofHex) => {
  const proof_data = web3.eth.abi.decodeParameters(oracleProofABI, proofHex);
  // Fatching the raw bytes of the signed pair cluster data
  const clusters = proof_data[0].clustersRaw;
  // Fetching which pair IDs have been requested
  const pairMask = proof_data[0].pairMask;

  // Helps in iterating the vector of pair masking
  let pair = 0;
  // Lists of all the pair IDs, prices, decimals, and timestamps requested
  const pairId = [];
  const pairPrice = [];
  const pairDecimal = [];
  const pairTimestamp = [];

  for (let i = 0; i < clusters.length; ++i) {
    // Deserialize the raw bytes of the signed pair cluster data
    const scc = web3.eth.abi.decodeParameters(
      signedCoherentClusterABI,
      clusters[i]
    );

    for (let j = 0; j < scc[0].cc.pair.length; ++j) {
      pair += 1;
      // Verify whether the pair is requested or not
      if (!pairMask[pair - 1]) {
        continue;
      }
      // Pushing the pair IDs, prices, decimals, and timestamps requested in the output vector
      pairId.push(scc[0].cc.pair[j].toString(10));
      pairPrice.push(scc[0].cc.prices[j].toString(10));
      pairDecimal.push(scc[0].cc.decimals[j].toString(10));
      pairTimestamp.push(scc[0].cc.timestamp[j].toString(10));
    }
  }

  console.log('----- Deserialized Data ------');
  console.log('Pair index : ', pairId);
  console.log('Pair Price : ', pairPrice);
  console.log('Pair Decimal : ', pairDecimal);
  console.log('Pair Timestamp : ', pairTimestamp);
  console.log('------------------------------');
};

// Function to call the Oracle client to verify and publish the latest price data
const callContract = async (proofHex) => {
  const contractAddress = 'INSERT_CONTRACT_ADDRESS';
  const contract = new web3.eth.Contract(oracleClientABI, contractAddress);

  // Create the transaction object using the hex-formatted proof and the index of the
  // data pair you requested price data for
  const txData = contract.methods.GetPairPrice(proofHex, pairIndex).encodeABI();
  const gasEstimate = await contract.methods
    .GetPairPrice(proofHex, pairIndex)
    .estimateGas();
  const transactionObject = {
    from: 'INSERT_ADDRESS',
    to: contractAddress,
    data: txData,
    gas: gasEstimate,
    gasPrice: await web3.eth.getGasPrice(),
  };

  // Sign the transaction with the private key
  const signedTransaction = await web3.eth.accounts.signTransaction(
    transactionObject,
    'INSERT_PRIVATE_KEY'
  );

  // Send the signed transaction
  return await web3.eth.sendSignedTransaction(signedTransaction.rawTransaction);
};

// Function to get the most recently published on-chain price data
const getPriceData = async (index) => {
  const contractAddress = 'INSERT_CONTRACT_ADDRESS';
  const contract = new web3.eth.Contract(feedClientABI, contractAddress);

  // Get the price data and log it to the console
  const priceData = await contract.methods.getPrice(index).call();
  console.log('----- On-Chain Price Data ------');
  console.log('Round : ', priceData[0]);
  console.log('Decimals : ', priceData[1]);
  console.log('Timestamp : ', priceData[2]);
  console.log('Price : ', priceData[3]);
};

const main = async () => {
  const proofs = await getProofs();

  // Convert oracle proof bytes to hex
  const hex = web3.utils.bytesToHex(proofs.evm.proof_bytes);
  deserializeProofBytes(hex);

  // Verify and write the latest price data on-chain
  const receipt = await callContract(hex);
  console.log('Transaction receipt:', receipt);

  // Get the latest price data
  await getPriceData(pairIndex);
};

main();
    ```

2. Create a variable to store the index of the data pair for which you want to retrieve the price data. This example requests the ETH_USDT data pair, but you can use the [index of any available data pair](https://docs.supra.com/oracles/data-feeds/data-feeds-index){target=\_blank}

    ```js title="main.js"
    const PullServiceClient = require('./pullServiceClient');
const oracleProofABI = require('./resources/oracleProof.json');
const signedCoherentClusterABI = require('./resources/signedCoherentCluster.json');
const { Web3 } = require('web3');
const oracleClientABI = require('./resources/oracleClient.json');
const feedClientABI = require('./resources/feedClient.json'); 

const web3 = new Web3('https://rpc.api.moonbeam.network');
const pairIndex = 1;

// Function that fetches proof data from the gRPC server using the specified parameters
const getProofs = () => {
  const address = 'mainnet-dora.supraoracles.com';
  const client = new PullServiceClient(address);

  const request = {
    pair_indexes: [pairIndex], // ETH_USDT
    chain_type: 'evm',
  };

  return new Promise((resolve, reject) => {
    client.getProof(request, (err, response) => {
      if (err) {
        console.error('Error:', err.details);
        return;
      }
      resolve(response);
    });
  });
};

// Function to convert the proof data to human-readable price data
const deserializeProofBytes = (proofHex) => {
  const proof_data = web3.eth.abi.decodeParameters(oracleProofABI, proofHex);
  // Fatching the raw bytes of the signed pair cluster data
  const clusters = proof_data[0].clustersRaw;
  // Fetching which pair IDs have been requested
  const pairMask = proof_data[0].pairMask;

  // Helps in iterating the vector of pair masking
  let pair = 0;
  // Lists of all the pair IDs, prices, decimals, and timestamps requested
  const pairId = [];
  const pairPrice = [];
  const pairDecimal = [];
  const pairTimestamp = [];

  for (let i = 0; i < clusters.length; ++i) {
    // Deserialize the raw bytes of the signed pair cluster data
    const scc = web3.eth.abi.decodeParameters(
      signedCoherentClusterABI,
      clusters[i]
    );

    for (let j = 0; j < scc[0].cc.pair.length; ++j) {
      pair += 1;
      // Verify whether the pair is requested or not
      if (!pairMask[pair - 1]) {
        continue;
      }
      // Pushing the pair IDs, prices, decimals, and timestamps requested in the output vector
      pairId.push(scc[0].cc.pair[j].toString(10));
      pairPrice.push(scc[0].cc.prices[j].toString(10));
      pairDecimal.push(scc[0].cc.decimals[j].toString(10));
      pairTimestamp.push(scc[0].cc.timestamp[j].toString(10));
    }
  }

  console.log('----- Deserialized Data ------');
  console.log('Pair index : ', pairId);
  console.log('Pair Price : ', pairPrice);
  console.log('Pair Decimal : ', pairDecimal);
  console.log('Pair Timestamp : ', pairTimestamp);
  console.log('------------------------------');
};

// Function to call the Oracle client to verify and publish the latest price data
const callContract = async (proofHex) => {
  const contractAddress = 'INSERT_CONTRACT_ADDRESS';
  const contract = new web3.eth.Contract(oracleClientABI, contractAddress);

  // Create the transaction object using the hex-formatted proof and the index of the
  // data pair you requested price data for
  const txData = contract.methods.GetPairPrice(proofHex, pairIndex).encodeABI();
  const gasEstimate = await contract.methods
    .GetPairPrice(proofHex, pairIndex)
    .estimateGas();
  const transactionObject = {
    from: 'INSERT_ADDRESS',
    to: contractAddress,
    data: txData,
    gas: gasEstimate,
    gasPrice: await web3.eth.getGasPrice(),
  };

  // Sign the transaction with the private key
  const signedTransaction = await web3.eth.accounts.signTransaction(
    transactionObject,
    'INSERT_PRIVATE_KEY'
  );

  // Send the signed transaction
  return await web3.eth.sendSignedTransaction(signedTransaction.rawTransaction);
};

// Function to get the most recently published on-chain price data
const getPriceData = async (index) => {
  const contractAddress = 'INSERT_CONTRACT_ADDRESS';
  const contract = new web3.eth.Contract(feedClientABI, contractAddress);

  // Get the price data and log it to the console
  const priceData = await contract.methods.getPrice(index).call();
  console.log('----- On-Chain Price Data ------');
  console.log('Round : ', priceData[0]);
  console.log('Decimals : ', priceData[1]);
  console.log('Timestamp : ', priceData[2]);
  console.log('Price : ', priceData[3]);
};

const main = async () => {
  const proofs = await getProofs();

  // Convert oracle proof bytes to hex
  const hex = web3.utils.bytesToHex(proofs.evm.proof_bytes);
  deserializeProofBytes(hex);

  // Verify and write the latest price data on-chain
  const receipt = await callContract(hex);
  console.log('Transaction receipt:', receipt);

  // Get the latest price data
  await getPriceData(pairIndex);
};

main();

    const pairIndex = 1;
    ```

3. Create a `getProofs` function, where you'll add all the logic

    ```js title="main.js"
    const getProofs = () => {
      // Add logic
    };
    ```

4. In the `getProofs` function, you can define the address for the gRPC server and use it to create an instance of the `PullServiceClient`. Supra has one address for MainNets, `'mainnet-dora.supraoracles.com'` and one for TestNets, `'testnet-dora.supraoracles.com'`

    === "Moonbeam"

        ```js title="main.js"
        const getProofs = () => {
  const address = 'mainnet-dora.supraoracles.com';
  const client = new PullServiceClient(address);
        };
        ```

    === "Moonbase Alpha"

        ```js title="main.js"
        const getProofs = () => {
  const address = 'testnet-dora.supraoracles.com';
  const client = new PullServiceClient(address);
        };
        ```

5. To request data from the client, first, you need to define the data you want to request

    ```js title="main.js"
    const getProofs = () => {
      // ...
    const request = {
    pair_indexes: [pairIndex], // ETH_USDT
    chain_type: 'evm',
  };
    };
    ```

6. Now you can request the proof for the data pair(s) by calling the `getProof` method of the Pull Service Client

    ```js title="main.js"
    const getProofs = () => {
      // ...
    return new Promise((resolve, reject) => {
    client.getProof(request, (err, response) => {
      if (err) {
        console.error('Error:', err.details);
        return;
      }
      resolve(response);
    });
  });
    };
    ```

7. Create a `main` function that calls the `getProofs` function and saves the proofs to be consumed in later steps

    ```js title="main.js"
    const main = async () => {
  const proofs = await getProofs();
    };

main();
    ```

??? code "main.js"

    === "Moonbeam"

        ```js
        const PullServiceClient = require('./pullServiceClient');
const oracleProofABI = require('./resources/oracleProof.json');
const signedCoherentClusterABI = require('./resources/signedCoherentCluster.json');
const { Web3 } = require('web3');
const oracleClientABI = require('./resources/oracleClient.json');
const feedClientABI = require('./resources/feedClient.json'); 

const web3 = new Web3('https://rpc.api.moonbeam.network');
const pairIndex = 1;

// Function that fetches proof data from the gRPC server using the specified parameters
const getProofs = () => {
  const address = 'mainnet-dora.supraoracles.com';
  const client = new PullServiceClient(address);

  const request = {
    pair_indexes: [pairIndex], // ETH_USDT
    chain_type: 'evm',
  };

  return new Promise((resolve, reject) => {
    client.getProof(request, (err, response) => {
      if (err) {
        console.error('Error:', err.details);
        return;
      }
      resolve(response);
    });
  });
};

// Function to convert the proof data to human-readable price data
const deserializeProofBytes = (proofHex) => {
  const proof_data = web3.eth.abi.decodeParameters(oracleProofABI, proofHex);
  // Fatching the raw bytes of the signed pair cluster data
  const clusters = proof_data[0].clustersRaw;
  // Fetching which pair IDs have been requested
  const pairMask = proof_data[0].pairMask;

  // Helps in iterating the vector of pair masking
  let pair = 0;
  // Lists of all the pair IDs, prices, decimals, and timestamps requested
  const pairId = [];
  const pairPrice = [];
  const pairDecimal = [];
  const pairTimestamp = [];

  for (let i = 0; i < clusters.length; ++i) {
    // Deserialize the raw bytes of the signed pair cluster data
    const scc = web3.eth.abi.decodeParameters(
      signedCoherentClusterABI,
      clusters[i]
    );

    for (let j = 0; j < scc[0].cc.pair.length; ++j) {
      pair += 1;
      // Verify whether the pair is requested or not
      if (!pairMask[pair - 1]) {
        continue;
      }
      // Pushing the pair IDs, prices, decimals, and timestamps requested in the output vector
      pairId.push(scc[0].cc.pair[j].toString(10));
      pairPrice.push(scc[0].cc.prices[j].toString(10));
      pairDecimal.push(scc[0].cc.decimals[j].toString(10));
      pairTimestamp.push(scc[0].cc.timestamp[j].toString(10));
    }
  }

  console.log('----- Deserialized Data ------');
  console.log('Pair index : ', pairId);
  console.log('Pair Price : ', pairPrice);
  console.log('Pair Decimal : ', pairDecimal);
  console.log('Pair Timestamp : ', pairTimestamp);
  console.log('------------------------------');
};

// Function to call the Oracle client to verify and publish the latest price data
const callContract = async (proofHex) => {
  const contractAddress = 'INSERT_CONTRACT_ADDRESS';
  const contract = new web3.eth.Contract(oracleClientABI, contractAddress);

  // Create the transaction object using the hex-formatted proof and the index of the
  // data pair you requested price data for
  const txData = contract.methods.GetPairPrice(proofHex, pairIndex).encodeABI();
  const gasEstimate = await contract.methods
    .GetPairPrice(proofHex, pairIndex)
    .estimateGas();
  const transactionObject = {
    from: 'INSERT_ADDRESS',
    to: contractAddress,
    data: txData,
    gas: gasEstimate,
    gasPrice: await web3.eth.getGasPrice(),
  };

  // Sign the transaction with the private key
  const signedTransaction = await web3.eth.accounts.signTransaction(
    transactionObject,
    'INSERT_PRIVATE_KEY'
  );

  // Send the signed transaction
  return await web3.eth.sendSignedTransaction(signedTransaction.rawTransaction);
};

// Function to get the most recently published on-chain price data
const getPriceData = async (index) => {
  const contractAddress = 'INSERT_CONTRACT_ADDRESS';
  const contract = new web3.eth.Contract(feedClientABI, contractAddress);

  // Get the price data and log it to the console
  const priceData = await contract.methods.getPrice(index).call();
  console.log('----- On-Chain Price Data ------');
  console.log('Round : ', priceData[0]);
  console.log('Decimals : ', priceData[1]);
  console.log('Timestamp : ', priceData[2]);
  console.log('Price : ', priceData[3]);
};

const main = async () => {
  const proofs = await getProofs();

  // Convert oracle proof bytes to hex
  const hex = web3.utils.bytesToHex(proofs.evm.proof_bytes);
  deserializeProofBytes(hex);

  // Verify and write the latest price data on-chain
  const receipt = await callContract(hex);
  console.log('Transaction receipt:', receipt);

  // Get the latest price data
  await getPriceData(pairIndex);
};

main();

        const pairIndex = 1;

// Function that fetches proof data from the gRPC server using the specified parameters
const getProofs = () => {
  const address = 'mainnet-dora.supraoracles.com';
  const client = new PullServiceClient(address);

  const request = {
    pair_indexes: [pairIndex], // ETH_USDT
    chain_type: 'evm',
  };

  return new Promise((resolve, reject) => {
    client.getProof(request, (err, response) => {
      if (err) {
        console.error('Error:', err.details);
        return;
      }
      resolve(response);
    });
  });
};

        const main = async () => {
  const proofs = await getProofs();
        };

main();
        ```

    === "Moonbase Alpha"

        ```js
        const PullServiceClient = require('./pullServiceClient');
const oracleProofABI = require('./resources/oracleProof.json');
const signedCoherentClusterABI = require('./resources/signedCoherentCluster.json');
const { Web3 } = require('web3');
const oracleClientABI = require('./resources/oracleClient.json');
const feedClientABI = require('./resources/feedClient.json'); 

const web3 = new Web3('https://rpc.api.moonbase.moonbeam.network');
const pairIndex = 1;

// Function that fetches proof data from the gRPC server using the specified parameters
const getProofs = () => {
  const address = 'testnet-dora.supraoracles.com';
  const client = new PullServiceClient(address);

  const request = {
    pair_indexes: [pairIndex], // ETH_USDT
    chain_type: 'evm',
  };

  return new Promise((resolve, reject) => {
    client.getProof(request, (err, response) => {
      if (err) {
        console.error('Error:', err.details);
        return;
      }
      resolve(response);
    });
  });
};

// Function to convert the proof data to human-readable price data
const deserializeProofBytes = (proofHex) => {
  const proof_data = web3.eth.abi.decodeParameters(oracleProofABI, proofHex);
  // Fatching the raw bytes of the signed pair cluster data
  const clusters = proof_data[0].clustersRaw;
  // Fetching which pair IDs have been requested
  const pairMask = proof_data[0].pairMask;

  // Helps in iterating the vector of pair masking
  let pair = 0;
  // Lists of all the pair IDs, prices, decimals, and timestamps requested
  const pairId = [];
  const pairPrice = [];
  const pairDecimal = [];
  const pairTimestamp = [];

  for (let i = 0; i < clusters.length; ++i) {
    // Deserialize the raw bytes of the signed pair cluster data
    const scc = web3.eth.abi.decodeParameters(
      signedCoherentClusterABI,
      clusters[i]
    );

    for (let j = 0; j < scc[0].cc.pair.length; ++j) {
      pair += 1;
      // Verify whether the pair is requested or not
      if (!pairMask[pair - 1]) {
        continue;
      }
      // Pushing the pair IDs, prices, decimals, and timestamps requested in the output vector
      pairId.push(scc[0].cc.pair[j].toString(10));
      pairPrice.push(scc[0].cc.prices[j].toString(10));
      pairDecimal.push(scc[0].cc.decimals[j].toString(10));
      pairTimestamp.push(scc[0].cc.timestamp[j].toString(10));
    }
  }

  console.log('----- Deserialized Data ------');
  console.log('Pair index : ', pairId);
  console.log('Pair Price : ', pairPrice);
  console.log('Pair Decimal : ', pairDecimal);
  console.log('Pair Timestamp : ', pairTimestamp);
  console.log('------------------------------');
};

// Function to call the Oracle client to verify and publish the latest price data
const callContract = async (proofHex) => {
  const contractAddress = 'INSERT_CONTRACT_ADDRESS';
  const contract = new web3.eth.Contract(oracleClientABI, contractAddress);

  // Create the transaction object using the hex-formatted proof and the index of the
  // data pair you requested price data for
  const txData = contract.methods.GetPairPrice(proofHex, pairIndex).encodeABI();
  const gasEstimate = await contract.methods
    .GetPairPrice(proofHex, pairIndex)
    .estimateGas();
  const transactionObject = {
    from: 'INSERT_ADDRESS',
    to: contractAddress,
    data: txData,
    gas: gasEstimate,
    gasPrice: await web3.eth.getGasPrice(),
  };

  // Sign the transaction with the private key
  const signedTransaction = await web3.eth.accounts.signTransaction(
    transactionObject,
    'INSERT_PRIVATE_KEY'
  );

  // Send the signed transaction
  return await web3.eth.sendSignedTransaction(signedTransaction.rawTransaction);
};

// Function to get the most recently published on-chain price data
const getPriceData = async (index) => {
  const contractAddress = 'INSERT_CONTRACT_ADDRESS';
  const contract = new web3.eth.Contract(feedClientABI, contractAddress);

  // Get the price data and log it to the console
  const priceData = await contract.methods.getPrice(index).call();
  console.log('----- On-Chain Price Data ------');
  console.log('Round : ', priceData[0]);
  console.log('Decimals : ', priceData[1]);
  console.log('Timestamp : ', priceData[2]);
  console.log('Price : ', priceData[3]);
};

const main = async () => {
  const proofs = await getProofs();

  // Convert oracle proof bytes to hex
  const hex = web3.utils.bytesToHex(proofs.evm.proof_bytes);
  deserializeProofBytes(hex);

  // Verify and write the latest price data on-chain
  const receipt = await callContract(hex);
  console.log('Transaction receipt:', receipt);

  // Get the latest price data
  await getPriceData(pairIndex);
};

main();

        const pairIndex = 1;

// Function that fetches proof data from the gRPC server using the specified parameters
const getProofs = () => {
  const address = 'testnet-dora.supraoracles.com';
  const client = new PullServiceClient(address);

  const request = {
    pair_indexes: [pairIndex], // ETH_USDT
    chain_type: 'evm',
  };

  return new Promise((resolve, reject) => {
    client.getProof(request, (err, response) => {
      if (err) {
        console.error('Error:', err.details);
        return;
      }
      resolve(response);
    });
  });
};

        const main = async () => {
  const proofs = await getProofs();
        };

main();
        ```

So far, you have the logic required to retrieve proofs for data pairs. The proofs are bytes of data that are not human-readable, but you can follow the steps in the next section to deserialize the data into human-readable formats. This step is optional, so you can [skip ahead to verify the proofs and write the price data on-chain](#verify-and-publish-proofs).

### Deserialize the Proofs {: #deserialize-proofs }

If you want to deserialize the data to read the latest price data you've retrieved, you can use the interfaces for the proof data and the signed coherent cluster data.

Coherent cluster data is a set of values where all the values in that set agree. This is a component of Supra's DORA (Distributed Oracle Agreement) protocol, which, in its simplest form, is a protocol that aggregates a set of data into a single representative value. If you want to dive deeper, check out the [DORA litepaper](https://supra.com/news/dora-distributed-oracle-agreement){target=\_blank}.

You'll need to create a file for each interface, which you can store in a `resources` directory:

```bash
mkdir resources && touch resources/oracleProof.json resources/signedCoherentCluster.json
```

Then, you can copy the following code snippets and add them to their respective files:

???+ code "Interface files"

    === "oracleProof.json"

        ```json
        [
    {
        "type": "tuple",
        "name": "OracleProof",
        "components": [
            {
                "type": "tuple[]",
                "name": "votes",
                "components": [
                    {
                        "type": "tuple",
                        "name": "smrBlock",
                        "components": [
                            { "type": "uint64", "name": "round" },
                            { "type": "uint128", "name": "timestamp" },
                            { "type": "bytes32", "name": "author" },
                            { "type": "bytes32", "name": "qcHash" },
                            { "type": "bytes32[]", "name": "batchHashes" }
                        ]
                    },
                    { "type": "bytes8", "name": "roundLE" }
                ]
            },
            { "type": "uint256[2][]", "name": "sigs" },
            {
                "type": "tuple[]",
                "name": "smrBatches",
                "components": [
                    { "type": "bytes10", "name": "protocol" },
                    { "type": "bytes32[]", "name": "txnHashes" },
                    { "type": "uint256", "name": "batchIdx" }
                ]
            },
            {
                "type": "tuple[]",
                "name": "smrTxns",
                "components": [
                    { "type": "bytes32[]", "name": "clusterHashes" },
                    { "type": "bytes32", "name": "sender" },
                    { "type": "bytes10", "name": "protocol" },
                    { "type": "bytes1", "name": "tx_sub_type" },
                    { "type": "uint256", "name": "txnIdx" }
                ]
            },
            { "type": "bytes[]", "name": "clustersRaw" },
            { "type": "uint256[]", "name": "batchToVote" },
            { "type": "uint256[]", "name": "txnToBatch" },
            { "type": "uint256[]", "name": "clusterToTxn" },
            { "type": "uint256[]", "name": "clusterToHash" },
            { "type": "bool[]", "name": "pairMask" },
            { "type": "uint256", "name": "pairCnt" }
        ]
    }
]
        ```

    === "signedCoherentCluster.json"

        ```json
        [
    {
        "type": "tuple",
        "name": "scc",
        "components": [
            {
                "type": "tuple",
                "name": "cc",
                "components": [
                    { "type": "bytes32", "name": "dataHash" },
                    { "type": "uint256[]", "name": "pair" },
                    { "type": "uint256[]", "name": "prices" },
                    { "type": "uint256[]", "name": "timestamp" },
                    { "type": "uint256[]", "name": "decimals" }
                ]
            },
            { "type": "bytes", "name": "qc" },
            { "type": "uint256", "name": "round" },
            {
                "type": "tuple",
                "name": "origin",
                "components": [
                    { "type": "bytes32", "name": "_publicKeyIdentity" },
                    { "type": "uint256", "name": "_pubMemberIndex" },
                    { "type": "uint256", "name": "_committeeIndex" }
                ]
            }
        ]
    }
]
        ```

To work with these interfaces, you must install the [Ethereum library](/builders/ethereum/libraries/){target=\_blank} of your choice. For this example, we'll use [Web3.js](/builders/ethereum/libraries/web3js/){target=\_blank}.

```bash
npm i web3
```

Next, you can take the following steps to create a function that deserializes the proof data:

1. In the `main.js` file, import the interfaces and Web3
    
    ```js title="main.js"
    const oracleProofABI = require('./resources/oracleProof.json');
const signedCoherentClusterABI = require('./resources/signedCoherentCluster.json');
const { Web3 } = require('web3');
    ```

2. Create a Web3 instance, which will be used to interact with the interfaces. You can add this snippet directly after the imports

    === "Moonbeam"

        ```js title="main.js"
        const web3 = new Web3('https://rpc.api.moonbeam.network');
        ```

    === "Moonbase Alpha"
    
        ```js title="main.js"
        const web3 = new Web3('https://rpc.api.moonbase.moonbeam.network');
        ```

3. Create a `deserializeProofBytes` function to add all the logic for deserializing the proofs. The function should accept the proof formatted in hex as a parameter

    ```js title="main.js"
    const deserializeProofBytes = (proofHex) => {
      // Add logic here
    };
    ```

4. First you can decode the parameters of the proof data using the Oracle Proof interface and extract the raw bytes of the signed pair cluster data and which pair IDs have been requested

    ```js title="main.js"
    const deserializeProofBytes = (proofHex) => {
    const proof_data = web3.eth.abi.decodeParameters(oracleProofABI, proofHex);
  // Fatching the raw bytes of the signed pair cluster data
  const clusters = proof_data[0].clustersRaw;
  // Fetching which pair IDs have been requested
  const pairMask = proof_data[0].pairMask;
    };
    ```

5. Next, you can iterate over the signed pair cluster data and decode the parameters using the Signed Coherent Cluster interface, and then save the data for each pair to variables that you can log to the console

    ```js title="main.js"
    const deserializeProofBytes = (proofHex) => {
      // ...

    // Helps in iterating the vector of pair masking
  let pair = 0;
  // Lists of all the pair IDs, prices, decimals, and timestamps requested
  const pairId = [];
  const pairPrice = [];
  const pairDecimal = [];
  const pairTimestamp = [];

  for (let i = 0; i < clusters.length; ++i) {
    // Deserialize the raw bytes of the signed pair cluster data
    const scc = web3.eth.abi.decodeParameters(
      signedCoherentClusterABI,
      clusters[i]
    );

    for (let j = 0; j < scc[0].cc.pair.length; ++j) {
      pair += 1;
      // Verify whether the pair is requested or not
      if (!pairMask[pair - 1]) {
        continue;
      }
      // Pushing the pair IDs, prices, decimals, and timestamps requested in the output vector
      pairId.push(scc[0].cc.pair[j].toString(10));
      pairPrice.push(scc[0].cc.prices[j].toString(10));
      pairDecimal.push(scc[0].cc.decimals[j].toString(10));
      pairTimestamp.push(scc[0].cc.timestamp[j].toString(10));
    }
  }

  console.log('----- Deserialized Data ------');
  console.log('Pair index : ', pairId);
  console.log('Pair Price : ', pairPrice);
  console.log('Pair Decimal : ', pairDecimal);
  console.log('Pair Timestamp : ', pairTimestamp);
  console.log('------------------------------');
};
    ```

6. In the `main` function that you created in the previous section, you can convert the `proofs` to hex and call the `deserializeProofBytes` function

    ```js title="main.js"
    const main = async () => {
  const proofs = await getProofs();

  // Convert oracle proof bytes to hex
  const hex = web3.utils.bytesToHex(proofs.evm.proof_bytes);
  deserializeProofBytes(hex);
    };

main();
    ```

??? code "main.js"

    === "Moonbeam"

        ```js
        const PullServiceClient = require('./pullServiceClient');
const oracleProofABI = require('./resources/oracleProof.json');
const signedCoherentClusterABI = require('./resources/signedCoherentCluster.json');
const { Web3 } = require('web3');
const oracleClientABI = require('./resources/oracleClient.json');
const feedClientABI = require('./resources/feedClient.json'); 

const web3 = new Web3('https://rpc.api.moonbeam.network');
const pairIndex = 1;

// Function that fetches proof data from the gRPC server using the specified parameters
const getProofs = () => {
  const address = 'mainnet-dora.supraoracles.com';
  const client = new PullServiceClient(address);

  const request = {
    pair_indexes: [pairIndex], // ETH_USDT
    chain_type: 'evm',
  };

  return new Promise((resolve, reject) => {
    client.getProof(request, (err, response) => {
      if (err) {
        console.error('Error:', err.details);
        return;
      }
      resolve(response);
    });
  });
};

// Function to convert the proof data to human-readable price data
const deserializeProofBytes = (proofHex) => {
  const proof_data = web3.eth.abi.decodeParameters(oracleProofABI, proofHex);
  // Fatching the raw bytes of the signed pair cluster data
  const clusters = proof_data[0].clustersRaw;
  // Fetching which pair IDs have been requested
  const pairMask = proof_data[0].pairMask;

  // Helps in iterating the vector of pair masking
  let pair = 0;
  // Lists of all the pair IDs, prices, decimals, and timestamps requested
  const pairId = [];
  const pairPrice = [];
  const pairDecimal = [];
  const pairTimestamp = [];

  for (let i = 0; i < clusters.length; ++i) {
    // Deserialize the raw bytes of the signed pair cluster data
    const scc = web3.eth.abi.decodeParameters(
      signedCoherentClusterABI,
      clusters[i]
    );

    for (let j = 0; j < scc[0].cc.pair.length; ++j) {
      pair += 1;
      // Verify whether the pair is requested or not
      if (!pairMask[pair - 1]) {
        continue;
      }
      // Pushing the pair IDs, prices, decimals, and timestamps requested in the output vector
      pairId.push(scc[0].cc.pair[j].toString(10));
      pairPrice.push(scc[0].cc.prices[j].toString(10));
      pairDecimal.push(scc[0].cc.decimals[j].toString(10));
      pairTimestamp.push(scc[0].cc.timestamp[j].toString(10));
    }
  }

  console.log('----- Deserialized Data ------');
  console.log('Pair index : ', pairId);
  console.log('Pair Price : ', pairPrice);
  console.log('Pair Decimal : ', pairDecimal);
  console.log('Pair Timestamp : ', pairTimestamp);
  console.log('------------------------------');
};

// Function to call the Oracle client to verify and publish the latest price data
const callContract = async (proofHex) => {
  const contractAddress = 'INSERT_CONTRACT_ADDRESS';
  const contract = new web3.eth.Contract(oracleClientABI, contractAddress);

  // Create the transaction object using the hex-formatted proof and the index of the
  // data pair you requested price data for
  const txData = contract.methods.GetPairPrice(proofHex, pairIndex).encodeABI();
  const gasEstimate = await contract.methods
    .GetPairPrice(proofHex, pairIndex)
    .estimateGas();
  const transactionObject = {
    from: 'INSERT_ADDRESS',
    to: contractAddress,
    data: txData,
    gas: gasEstimate,
    gasPrice: await web3.eth.getGasPrice(),
  };

  // Sign the transaction with the private key
  const signedTransaction = await web3.eth.accounts.signTransaction(
    transactionObject,
    'INSERT_PRIVATE_KEY'
  );

  // Send the signed transaction
  return await web3.eth.sendSignedTransaction(signedTransaction.rawTransaction);
};

// Function to get the most recently published on-chain price data
const getPriceData = async (index) => {
  const contractAddress = 'INSERT_CONTRACT_ADDRESS';
  const contract = new web3.eth.Contract(feedClientABI, contractAddress);

  // Get the price data and log it to the console
  const priceData = await contract.methods.getPrice(index).call();
  console.log('----- On-Chain Price Data ------');
  console.log('Round : ', priceData[0]);
  console.log('Decimals : ', priceData[1]);
  console.log('Timestamp : ', priceData[2]);
  console.log('Price : ', priceData[3]);
};

const main = async () => {
  const proofs = await getProofs();

  // Convert oracle proof bytes to hex
  const hex = web3.utils.bytesToHex(proofs.evm.proof_bytes);
  deserializeProofBytes(hex);

  // Verify and write the latest price data on-chain
  const receipt = await callContract(hex);
  console.log('Transaction receipt:', receipt);

  // Get the latest price data
  await getPriceData(pairIndex);
};

main();

        const web3 = new Web3('https://rpc.api.moonbeam.network');
const pairIndex = 1;

// Function that fetches proof data from the gRPC server using the specified parameters
const getProofs = () => {
  const address = 'mainnet-dora.supraoracles.com';
  const client = new PullServiceClient(address);

  const request = {
    pair_indexes: [pairIndex], // ETH_USDT
    chain_type: 'evm',
  };

  return new Promise((resolve, reject) => {
    client.getProof(request, (err, response) => {
      if (err) {
        console.error('Error:', err.details);
        return;
      }
      resolve(response);
    });
  });
};

// Function to convert the proof data to human-readable price data
const deserializeProofBytes = (proofHex) => {
  const proof_data = web3.eth.abi.decodeParameters(oracleProofABI, proofHex);
  // Fatching the raw bytes of the signed pair cluster data
  const clusters = proof_data[0].clustersRaw;
  // Fetching which pair IDs have been requested
  const pairMask = proof_data[0].pairMask;

  // Helps in iterating the vector of pair masking
  let pair = 0;
  // Lists of all the pair IDs, prices, decimals, and timestamps requested
  const pairId = [];
  const pairPrice = [];
  const pairDecimal = [];
  const pairTimestamp = [];

  for (let i = 0; i < clusters.length; ++i) {
    // Deserialize the raw bytes of the signed pair cluster data
    const scc = web3.eth.abi.decodeParameters(
      signedCoherentClusterABI,
      clusters[i]
    );

    for (let j = 0; j < scc[0].cc.pair.length; ++j) {
      pair += 1;
      // Verify whether the pair is requested or not
      if (!pairMask[pair - 1]) {
        continue;
      }
      // Pushing the pair IDs, prices, decimals, and timestamps requested in the output vector
      pairId.push(scc[0].cc.pair[j].toString(10));
      pairPrice.push(scc[0].cc.prices[j].toString(10));
      pairDecimal.push(scc[0].cc.decimals[j].toString(10));
      pairTimestamp.push(scc[0].cc.timestamp[j].toString(10));
    }
  }

  console.log('----- Deserialized Data ------');
  console.log('Pair index : ', pairId);
  console.log('Pair Price : ', pairPrice);
  console.log('Pair Decimal : ', pairDecimal);
  console.log('Pair Timestamp : ', pairTimestamp);
  console.log('------------------------------');
};

        const main = async () => {
  const proofs = await getProofs();

  // Convert oracle proof bytes to hex
  const hex = web3.utils.bytesToHex(proofs.evm.proof_bytes);
  deserializeProofBytes(hex);
        };

main();
        ```

    === "Moonbase Alpha"

        ```js
        const PullServiceClient = require('./pullServiceClient');
const oracleProofABI = require('./resources/oracleProof.json');
const signedCoherentClusterABI = require('./resources/signedCoherentCluster.json');
const { Web3 } = require('web3');
const oracleClientABI = require('./resources/oracleClient.json');
const feedClientABI = require('./resources/feedClient.json'); 

const web3 = new Web3('https://rpc.api.moonbase.moonbeam.network');
const pairIndex = 1;

// Function that fetches proof data from the gRPC server using the specified parameters
const getProofs = () => {
  const address = 'testnet-dora.supraoracles.com';
  const client = new PullServiceClient(address);

  const request = {
    pair_indexes: [pairIndex], // ETH_USDT
    chain_type: 'evm',
  };

  return new Promise((resolve, reject) => {
    client.getProof(request, (err, response) => {
      if (err) {
        console.error('Error:', err.details);
        return;
      }
      resolve(response);
    });
  });
};

// Function to convert the proof data to human-readable price data
const deserializeProofBytes = (proofHex) => {
  const proof_data = web3.eth.abi.decodeParameters(oracleProofABI, proofHex);
  // Fatching the raw bytes of the signed pair cluster data
  const clusters = proof_data[0].clustersRaw;
  // Fetching which pair IDs have been requested
  const pairMask = proof_data[0].pairMask;

  // Helps in iterating the vector of pair masking
  let pair = 0;
  // Lists of all the pair IDs, prices, decimals, and timestamps requested
  const pairId = [];
  const pairPrice = [];
  const pairDecimal = [];
  const pairTimestamp = [];

  for (let i = 0; i < clusters.length; ++i) {
    // Deserialize the raw bytes of the signed pair cluster data
    const scc = web3.eth.abi.decodeParameters(
      signedCoherentClusterABI,
      clusters[i]
    );

    for (let j = 0; j < scc[0].cc.pair.length; ++j) {
      pair += 1;
      // Verify whether the pair is requested or not
      if (!pairMask[pair - 1]) {
        continue;
      }
      // Pushing the pair IDs, prices, decimals, and timestamps requested in the output vector
      pairId.push(scc[0].cc.pair[j].toString(10));
      pairPrice.push(scc[0].cc.prices[j].toString(10));
      pairDecimal.push(scc[0].cc.decimals[j].toString(10));
      pairTimestamp.push(scc[0].cc.timestamp[j].toString(10));
    }
  }

  console.log('----- Deserialized Data ------');
  console.log('Pair index : ', pairId);
  console.log('Pair Price : ', pairPrice);
  console.log('Pair Decimal : ', pairDecimal);
  console.log('Pair Timestamp : ', pairTimestamp);
  console.log('------------------------------');
};

// Function to call the Oracle client to verify and publish the latest price data
const callContract = async (proofHex) => {
  const contractAddress = 'INSERT_CONTRACT_ADDRESS';
  const contract = new web3.eth.Contract(oracleClientABI, contractAddress);

  // Create the transaction object using the hex-formatted proof and the index of the
  // data pair you requested price data for
  const txData = contract.methods.GetPairPrice(proofHex, pairIndex).encodeABI();
  const gasEstimate = await contract.methods
    .GetPairPrice(proofHex, pairIndex)
    .estimateGas();
  const transactionObject = {
    from: 'INSERT_ADDRESS',
    to: contractAddress,
    data: txData,
    gas: gasEstimate,
    gasPrice: await web3.eth.getGasPrice(),
  };

  // Sign the transaction with the private key
  const signedTransaction = await web3.eth.accounts.signTransaction(
    transactionObject,
    'INSERT_PRIVATE_KEY'
  );

  // Send the signed transaction
  return await web3.eth.sendSignedTransaction(signedTransaction.rawTransaction);
};

// Function to get the most recently published on-chain price data
const getPriceData = async (index) => {
  const contractAddress = 'INSERT_CONTRACT_ADDRESS';
  const contract = new web3.eth.Contract(feedClientABI, contractAddress);

  // Get the price data and log it to the console
  const priceData = await contract.methods.getPrice(index).call();
  console.log('----- On-Chain Price Data ------');
  console.log('Round : ', priceData[0]);
  console.log('Decimals : ', priceData[1]);
  console.log('Timestamp : ', priceData[2]);
  console.log('Price : ', priceData[3]);
};

const main = async () => {
  const proofs = await getProofs();

  // Convert oracle proof bytes to hex
  const hex = web3.utils.bytesToHex(proofs.evm.proof_bytes);
  deserializeProofBytes(hex);

  // Verify and write the latest price data on-chain
  const receipt = await callContract(hex);
  console.log('Transaction receipt:', receipt);

  // Get the latest price data
  await getPriceData(pairIndex);
};

main();

        const web3 = new Web3('https://rpc.api.moonbase.moonbeam.network');
const pairIndex = 1;

// Function that fetches proof data from the gRPC server using the specified parameters
const getProofs = () => {
  const address = 'testnet-dora.supraoracles.com';
  const client = new PullServiceClient(address);

  const request = {
    pair_indexes: [pairIndex], // ETH_USDT
    chain_type: 'evm',
  };

  return new Promise((resolve, reject) => {
    client.getProof(request, (err, response) => {
      if (err) {
        console.error('Error:', err.details);
        return;
      }
      resolve(response);
    });
  });
};

// Function to convert the proof data to human-readable price data
const deserializeProofBytes = (proofHex) => {
  const proof_data = web3.eth.abi.decodeParameters(oracleProofABI, proofHex);
  // Fatching the raw bytes of the signed pair cluster data
  const clusters = proof_data[0].clustersRaw;
  // Fetching which pair IDs have been requested
  const pairMask = proof_data[0].pairMask;

  // Helps in iterating the vector of pair masking
  let pair = 0;
  // Lists of all the pair IDs, prices, decimals, and timestamps requested
  const pairId = [];
  const pairPrice = [];
  const pairDecimal = [];
  const pairTimestamp = [];

  for (let i = 0; i < clusters.length; ++i) {
    // Deserialize the raw bytes of the signed pair cluster data
    const scc = web3.eth.abi.decodeParameters(
      signedCoherentClusterABI,
      clusters[i]
    );

    for (let j = 0; j < scc[0].cc.pair.length; ++j) {
      pair += 1;
      // Verify whether the pair is requested or not
      if (!pairMask[pair - 1]) {
        continue;
      }
      // Pushing the pair IDs, prices, decimals, and timestamps requested in the output vector
      pairId.push(scc[0].cc.pair[j].toString(10));
      pairPrice.push(scc[0].cc.prices[j].toString(10));
      pairDecimal.push(scc[0].cc.decimals[j].toString(10));
      pairTimestamp.push(scc[0].cc.timestamp[j].toString(10));
    }
  }

  console.log('----- Deserialized Data ------');
  console.log('Pair index : ', pairId);
  console.log('Pair Price : ', pairPrice);
  console.log('Pair Decimal : ', pairDecimal);
  console.log('Pair Timestamp : ', pairTimestamp);
  console.log('------------------------------');
};

        const main = async () => {
  const proofs = await getProofs();

  // Convert oracle proof bytes to hex
  const hex = web3.utils.bytesToHex(proofs.evm.proof_bytes);
  deserializeProofBytes(hex);
        };

main();
        ```

When you request the proof data, you can view that data in a human-readable format. You can try it out by running:

```bash
node main.js
```

The terminal output should look something like the following:

<div id="termynal" data-termynal>
  <span data-ty="input"><span class="file-path"></span>node main.js</span>
  <br>
  <span data-ty>----- Deserialized Data ------
    <br> Pair index :  [ '1' ]
    <br> Pair Price :  [ '3424260000000000000000' ]
    <br> Pair Decimal :  [ '18' ]
    <br> Pair Timestamp :  [ '1709317443269' ]
    <br> ------------------------------
  </span>
</div>

## Use Web3 to Verify and Publish the Proofs {: #verify-and-publish-proofs }

Now that we've retrieved the price data, we need to be able to consume it to verify and publish the data on-chain. To do this, we'll need a smart contract that uses Supra's Pull contract to verify the proof data.

### Create the Consumer Contract {: #create-the-consumer-contract }

You can take the following steps to create our smart contract:

1. Create a new file for the smart contract, which we'll name `OracleClient`

    ```bash
    touch OracleClient.sol
    ```

2. In the file, create an interface for Supra's Pull contract. The interface outlines the data structure for the price data and has a function that we'll call to verify proofs. Then, in our `OracleClient` contract, we'll instantiate the `ISupraOraclePull` interface with the address of Supra's Pull contract on Moonbeam or Moonbase Alpha

    ```solidity title="OracleClient.sol"
    // SPDX-License-Identifier: UNLICENSED
pragma solidity 0.8.20;

interface ISupraOraclePull {
    // Verified price data
    struct PriceData {
        // List of pairs
        uint256[] pairs;
        // List of prices
        // prices[i] is the price of pairs[i]
        uint256[] prices;
        // List of decimals
        // decimals[i] is the decimals of pairs[i]
        uint256[] decimals;
    }

    function verifyOracleProof(
        bytes calldata _bytesProof
    ) external returns (PriceData memory);
}

// Contract which can consume oracle pull data
contract OracleClient {
    // The oracle contract
    ISupraOraclePull internal oracle;

    // Event emitted when a pair price is received
    event PairPrice(uint256 pair, uint256 price, uint256 decimals);

    constructor(address oracle_) {
        oracle = ISupraOraclePull(oracle_);
    }

    function GetPairPrice(
        bytes calldata _bytesProof,
        uint256 pair
    ) external returns (uint256) {
        // Verify the proof
        ISupraOraclePull.PriceData memory prices = oracle.verifyOracleProof(
             _bytesProof
        );
        // Set the price and decimals for the requested data pair
        uint256 price = 0;
        uint256 decimals = 0;
        for (uint256 i = 0; i < prices.pairs.length; i++) {
            if (prices.pairs[i] == pair) {
                price = prices.prices[i];
                decimals = prices.decimals[i];
                break;
            }
        }
        require(price != 0, "Pair not found");
        return price;
    }
}
    ```

3. In the same file, create the `OracleClient` contract. As mentioned in the previous step, the constructor of this contract instantiates the `ISupraOraclePull` interface with the address of Supra's Pull contract. The contract also includes a function that calls the `verifyOracleProof` function of the Pull contract and saves the price data on-chain

    ```solidity title="OracleClient.sol"
    // ...

    // Contract which can consume oracle pull data
contract OracleClient {
    // The oracle contract
    ISupraOraclePull internal oracle;

    // Event emitted when a pair price is received
    event PairPrice(uint256 pair, uint256 price, uint256 decimals);

    constructor(address oracle_) {
        oracle = ISupraOraclePull(oracle_);
    }

    function GetPairPrice(
        bytes calldata _bytesProof,
        uint256 pair
    ) external returns (uint256) {
        // Verify the proof
        ISupraOraclePull.PriceData memory prices = oracle.verifyOracleProof(
             _bytesProof
        );
        // Set the price and decimals for the requested data pair
        uint256 price = 0;
        uint256 decimals = 0;
        for (uint256 i = 0; i < prices.pairs.length; i++) {
            if (prices.pairs[i] == pair) {
                price = prices.prices[i];
                decimals = prices.decimals[i];
                break;
            }
        }
        require(price != 0, "Pair not found");
        return price;
    }
}
    ```

??? code "OracleClient.sol"

    ```solidity
    // SPDX-License-Identifier: UNLICENSED
pragma solidity 0.8.20;

interface ISupraOraclePull {
    // Verified price data
    struct PriceData {
        // List of pairs
        uint256[] pairs;
        // List of prices
        // prices[i] is the price of pairs[i]
        uint256[] prices;
        // List of decimals
        // decimals[i] is the decimals of pairs[i]
        uint256[] decimals;
    }

    function verifyOracleProof(
        bytes calldata _bytesProof
    ) external returns (PriceData memory);
}

// Contract which can consume oracle pull data
contract OracleClient {
    // The oracle contract
    ISupraOraclePull internal oracle;

    // Event emitted when a pair price is received
    event PairPrice(uint256 pair, uint256 price, uint256 decimals);

    constructor(address oracle_) {
        oracle = ISupraOraclePull(oracle_);
    }

    function GetPairPrice(
        bytes calldata _bytesProof,
        uint256 pair
    ) external returns (uint256) {
        // Verify the proof
        ISupraOraclePull.PriceData memory prices = oracle.verifyOracleProof(
             _bytesProof
        );
        // Set the price and decimals for the requested data pair
        uint256 price = 0;
        uint256 decimals = 0;
        for (uint256 i = 0; i < prices.pairs.length; i++) {
            if (prices.pairs[i] == pair) {
                price = prices.prices[i];
                decimals = prices.decimals[i];
                break;
            }
        }
        require(price != 0, "Pair not found");
        return price;
    }
}
    ```

!!! note
    This contract only saves the price data for one pair. So, if you want to save the price data for multiple pairs, you must modify the contract.

### Deploy the Contract {: #deploy-the-consumer-contract }

With the contract created, you must next deploy the contract. Since we've already installed Web3.js, let's use it to deploy the contract. If you're unfamiliar with the process, you can reference the [Web3.js docs on deploying a smart contract](/builders/ethereum/libraries/web3js/#deploy-a-contract){target=\_blank}.

To deploy the contract, take the following steps:

1. Create a file that will contain the logic for compiling and deploying the smart contract

    ```bash
    touch deploy.js
    ```

2. Install the Solidity compiler. We're installing version 0.8.20, as that is the version required by the `OracleClient` contract

    ```bash
    npm i solc@0.8.20
    ```

3. Add the following imports

    ```js title="deploy.js"
    const fs = require('fs');
const solc = require('solc');
const { Web3 } = require('web3');
    ```

4. Create the Web3 instance

    === "Moonbeam"

        ```js
        const web3 = new Web3('https://rpc.api.moonbeam.network');
        ```

    === "Moonbase Alpha"

        ```js
        const web3 = new Web3('https://rpc.api.moonbase.moonbeam.network');
        ```

5. Create a function that compiles the `OracleClient` contract, saves the ABI in the `resources` directory for later use, and returns the ABI and bytecode for the deployment

    ```js title="deploy.js"
    const compile = () => {
  // Get path and load contract
  const source = fs.readFileSync('OracleClient.sol', 'utf8');

  // Create input object
  const input = {
    language: 'Solidity',
    sources: {
      'OracleClient.sol': {
        content: source,
      },
    },
    settings: {
      outputSelection: {
        '*': {
          '*': ['*'],
        },
      },
    },
  };
  // Compile the contract
  const tempFile = JSON.parse(solc.compile(JSON.stringify(input)));
  const contractFile = tempFile.contracts['OracleClient.sol']['OracleClient'];

  // Save ABI to a file
  fs.writeFileSync(
    './resources/oracleClient.json',
    JSON.stringify(contractFile.abi, null, 4),
    'utf8'
  );

  return { abi: contractFile.abi, bytecode: contractFile.evm.bytecode.object };
};
    ```

6. Create the function to deploy the compiled contract. You'll need to pass the address of Supra's Pull contract to the constructor. You'll also need to provide your address and your private key

    !!! remember
        Never store your private key in a JavaScript file; this is for demo purposes only.

    === "Moonbeam"

        ```js title="deploy.js"
        const deploy = async () => {
  // Compile the contract
  const { abi, bytecode } = compile();

  // Create contract instance
  const contract = new web3.eth.Contract(abi);

  // Create the deployment transaction and pass in the Pull Oracle contract address
  const deployTx = contract.deploy({
    data: bytecode,
    arguments: ['0x2FA6DbFe4291136Cf272E1A3294362b6651e8517'],
  });

  // Sign transaction with PK
  const createTransaction = await web3.eth.accounts.signTransaction(
    {
      data: deployTx.encodeABI(),
      gas: await deployTx.estimateGas(),
      gasPrice: await web3.eth.getGasPrice(),
      nonce: await web3.eth.getTransactionCount('INSERT_ADDRESS'),
    },
    'INSERT_PRIVATE_KEY'
  );

  // Send transaction and wait for receipt
  const createReceipt = await web3.eth.sendSignedTransaction(
    createTransaction.rawTransaction
  );

  console.log(`Contract deployed at address: ${createReceipt.contractAddress}`);
};

deploy();
        ```

    === "Moonbase Alpha"

        ```js title="deploy.js"
        const deploy = async () => {
  // Compile the contract
  const { abi, bytecode } = compile();

  // Create contract instance
  const contract = new web3.eth.Contract(abi);

  // Create the deployment transaction and pass in the Pull Oracle contract address
  const deployTx = contract.deploy({
    data: bytecode,
    arguments: ['0xaa2f56843Cec7840F0C106F0202313d8d8CB13d6'],
  });

  // Sign transaction with PK
  const createTransaction = await web3.eth.accounts.signTransaction(
    {
      data: deployTx.encodeABI(),
      gas: await deployTx.estimateGas(),
      gasPrice: await web3.eth.getGasPrice(),
      nonce: await web3.eth.getTransactionCount('INSERT_ADDRESS'),
    },
    'INSERT_PRIVATE_KEY'
  );

  // Send transaction and wait for receipt
  const createReceipt = await web3.eth.sendSignedTransaction(
    createTransaction.rawTransaction
  );

  console.log(`Contract deployed at address: ${createReceipt.contractAddress}`);
};

deploy();
        ```

??? code "deploy.js"

    === "Moonbeam"

        ```js
        const fs = require('fs');
const solc = require('solc');
const { Web3 } = require('web3');

const web3 = new Web3('https://rpc.api.moonbeam.network');

const compile = () => {
  // Get path and load contract
  const source = fs.readFileSync('OracleClient.sol', 'utf8');

  // Create input object
  const input = {
    language: 'Solidity',
    sources: {
      'OracleClient.sol': {
        content: source,
      },
    },
    settings: {
      outputSelection: {
        '*': {
          '*': ['*'],
        },
      },
    },
  };
  // Compile the contract
  const tempFile = JSON.parse(solc.compile(JSON.stringify(input)));
  const contractFile = tempFile.contracts['OracleClient.sol']['OracleClient'];

  // Save ABI to a file
  fs.writeFileSync(
    './resources/oracleClient.json',
    JSON.stringify(contractFile.abi, null, 4),
    'utf8'
  );

  return { abi: contractFile.abi, bytecode: contractFile.evm.bytecode.object };
};

const deploy = async () => {
  // Compile the contract
  const { abi, bytecode } = compile();

  // Create contract instance
  const contract = new web3.eth.Contract(abi);

  // Create the deployment transaction and pass in the Pull Oracle contract address
  const deployTx = contract.deploy({
    data: bytecode,
    arguments: ['0x2FA6DbFe4291136Cf272E1A3294362b6651e8517'],
  });

  // Sign transaction with PK
  const createTransaction = await web3.eth.accounts.signTransaction(
    {
      data: deployTx.encodeABI(),
      gas: await deployTx.estimateGas(),
      gasPrice: await web3.eth.getGasPrice(),
      nonce: await web3.eth.getTransactionCount('INSERT_ADDRESS'),
    },
    'INSERT_PRIVATE_KEY'
  );

  // Send transaction and wait for receipt
  const createReceipt = await web3.eth.sendSignedTransaction(
    createTransaction.rawTransaction
  );

  console.log(`Contract deployed at address: ${createReceipt.contractAddress}`);
};

deploy();
        ```

    === "Moonbase Alpha"

        ```js
        const fs = require('fs');
const solc = require('solc');
const { Web3 } = require('web3');

const web3 = new Web3('https://rpc.api.moonbase.moonbeam.network');

const compile = () => {
  // Get path and load contract
  const source = fs.readFileSync('OracleClient.sol', 'utf8');

  // Create input object
  const input = {
    language: 'Solidity',
    sources: {
      'OracleClient.sol': {
        content: source,
      },
    },
    settings: {
      outputSelection: {
        '*': {
          '*': ['*'],
        },
      },
    },
  };
  // Compile the contract
  const tempFile = JSON.parse(solc.compile(JSON.stringify(input)));
  const contractFile = tempFile.contracts['OracleClient.sol']['OracleClient'];

  // Save ABI to a file
  fs.writeFileSync(
    './resources/oracleClient.json',
    JSON.stringify(contractFile.abi, null, 4),
    'utf8'
  );

  return { abi: contractFile.abi, bytecode: contractFile.evm.bytecode.object };
};

const deploy = async () => {
  // Compile the contract
  const { abi, bytecode } = compile();

  // Create contract instance
  const contract = new web3.eth.Contract(abi);

  // Create the deployment transaction and pass in the Pull Oracle contract address
  const deployTx = contract.deploy({
    data: bytecode,
    arguments: ['0xaa2f56843Cec7840F0C106F0202313d8d8CB13d6'],
  });

  // Sign transaction with PK
  const createTransaction = await web3.eth.accounts.signTransaction(
    {
      data: deployTx.encodeABI(),
      gas: await deployTx.estimateGas(),
      gasPrice: await web3.eth.getGasPrice(),
      nonce: await web3.eth.getTransactionCount('INSERT_ADDRESS'),
    },
    'INSERT_PRIVATE_KEY'
  );

  // Send transaction and wait for receipt
  const createReceipt = await web3.eth.sendSignedTransaction(
    createTransaction.rawTransaction
  );

  console.log(`Contract deployed at address: ${createReceipt.contractAddress}`);
};

deploy();
        ```

To deploy the contract, run:

```bash
node deploy.js
```

The contract's address will be printed to the terminal; save it as you'll need it in the following steps.

<div id="termynal" data-termynal>
  <span data-ty="input"><span class="file-path"></span>node deploy.js</span>
  <br>
  <span data-ty>Contract deployed at address: 0xaf1207d950a2231937372cedc2e8ddfa22c40665</span>
</div>

### Call the Contract {: #call-the-consumer-contract }

To verify the proof data and publish the latest price on-chain, the last step you'll need to do is to create a function that calls the `GetPairPrice` function of the `OracleClient` contract.

Back in the `main.js` file, take the following steps:

1. Import the ABI for the `OracleClient` contract

    ```js title="main.js"
    const oracleClientABI = require('./resources/oracleClient.json');
    ```

2. Create a function that accepts the hex-formatted proof data and will be responsible for calling the `OracleClient` contract

    ```js title="main.js"
    const callContract = async (proofHex) => {
      // Add logic here
    };
    ```

3. In the `callContract` function, create an instance of the deployed `OracleClient` contract using the ABI and the contract address, which you should have saved from deploying the contract in the previous set of steps

    ```js title="main.js"
    const callContract = async (proofHex) => {
  const contractAddress = 'INSERT_CONTRACT_ADDRESS';
  const contract = new web3.eth.Contract(oracleClientABI, contractAddress);
    };
    ```

4. Create the transaction object that will call the `GetPairPrice` function of the `OracleClient` contract. You'll need to provide your address in the transaction object

    ```js title="main.js"
    const callContract = async (proofHex) => {
  const contractAddress = 'INSERT_CONTRACT_ADDRESS';
  const contract = new web3.eth.Contract(oracleClientABI, contractAddress);

  // Create the transaction object using the hex-formatted proof and the index of the
  // data pair you requested price data for
  const txData = contract.methods.GetPairPrice(proofHex, pairIndex).encodeABI();
  const gasEstimate = await contract.methods
    .GetPairPrice(proofHex, pairIndex)
    .estimateGas();
  const transactionObject = {
    from: 'INSERT_ADDRESS',
    to: contractAddress,
    data: txData,
    gas: gasEstimate,
    gasPrice: await web3.eth.getGasPrice(),
  };
    };
    ```
  
5. Add logic for signing and sending the transaction. You'll need to provide your private key

    !!! remember
        Never store your private key in a JavaScript file; this is for demo purposes only.

    ```js title="main.js"
    const callContract = async (proofHex) => {
  const contractAddress = 'INSERT_CONTRACT_ADDRESS';
  const contract = new web3.eth.Contract(oracleClientABI, contractAddress);

  // Create the transaction object using the hex-formatted proof and the index of the
  // data pair you requested price data for
  const txData = contract.methods.GetPairPrice(proofHex, pairIndex).encodeABI();
  const gasEstimate = await contract.methods
    .GetPairPrice(proofHex, pairIndex)
    .estimateGas();
  const transactionObject = {
    from: 'INSERT_ADDRESS',
    to: contractAddress,
    data: txData,
    gas: gasEstimate,
    gasPrice: await web3.eth.getGasPrice(),
  };

  // Sign the transaction with the private key
  const signedTransaction = await web3.eth.accounts.signTransaction(
    transactionObject,
    'INSERT_PRIVATE_KEY'
  );

  // Send the signed transaction
  return await web3.eth.sendSignedTransaction(signedTransaction.rawTransaction);
};
    ```

6. The last step is to call the `callContract` function from the `main` function

    ```js title="main.js"
    const main = async () => {
  const proofs = await getProofs();

  // Convert oracle proof bytes to hex
  const hex = web3.utils.bytesToHex(proofs.evm.proof_bytes);
  deserializeProofBytes(hex);

  // Verify and write the latest price data on-chain
  const receipt = await callContract(hex);
  console.log('Transaction receipt:', receipt);
    };

main();
    ```

??? code "main.js"

    === "Moonbeam"

        ```js
        const PullServiceClient = require('./pullServiceClient');
const oracleProofABI = require('./resources/oracleProof.json');
const signedCoherentClusterABI = require('./resources/signedCoherentCluster.json');
const { Web3 } = require('web3');
const oracleClientABI = require('./resources/oracleClient.json');
const feedClientABI = require('./resources/feedClient.json'); 

const web3 = new Web3('https://rpc.api.moonbeam.network');
const pairIndex = 1;

// Function that fetches proof data from the gRPC server using the specified parameters
const getProofs = () => {
  const address = 'mainnet-dora.supraoracles.com';
  const client = new PullServiceClient(address);

  const request = {
    pair_indexes: [pairIndex], // ETH_USDT
    chain_type: 'evm',
  };

  return new Promise((resolve, reject) => {
    client.getProof(request, (err, response) => {
      if (err) {
        console.error('Error:', err.details);
        return;
      }
      resolve(response);
    });
  });
};

// Function to convert the proof data to human-readable price data
const deserializeProofBytes = (proofHex) => {
  const proof_data = web3.eth.abi.decodeParameters(oracleProofABI, proofHex);
  // Fatching the raw bytes of the signed pair cluster data
  const clusters = proof_data[0].clustersRaw;
  // Fetching which pair IDs have been requested
  const pairMask = proof_data[0].pairMask;

  // Helps in iterating the vector of pair masking
  let pair = 0;
  // Lists of all the pair IDs, prices, decimals, and timestamps requested
  const pairId = [];
  const pairPrice = [];
  const pairDecimal = [];
  const pairTimestamp = [];

  for (let i = 0; i < clusters.length; ++i) {
    // Deserialize the raw bytes of the signed pair cluster data
    const scc = web3.eth.abi.decodeParameters(
      signedCoherentClusterABI,
      clusters[i]
    );

    for (let j = 0; j < scc[0].cc.pair.length; ++j) {
      pair += 1;
      // Verify whether the pair is requested or not
      if (!pairMask[pair - 1]) {
        continue;
      }
      // Pushing the pair IDs, prices, decimals, and timestamps requested in the output vector
      pairId.push(scc[0].cc.pair[j].toString(10));
      pairPrice.push(scc[0].cc.prices[j].toString(10));
      pairDecimal.push(scc[0].cc.decimals[j].toString(10));
      pairTimestamp.push(scc[0].cc.timestamp[j].toString(10));
    }
  }

  console.log('----- Deserialized Data ------');
  console.log('Pair index : ', pairId);
  console.log('Pair Price : ', pairPrice);
  console.log('Pair Decimal : ', pairDecimal);
  console.log('Pair Timestamp : ', pairTimestamp);
  console.log('------------------------------');
};

// Function to call the Oracle client to verify and publish the latest price data
const callContract = async (proofHex) => {
  const contractAddress = 'INSERT_CONTRACT_ADDRESS';
  const contract = new web3.eth.Contract(oracleClientABI, contractAddress);

  // Create the transaction object using the hex-formatted proof and the index of the
  // data pair you requested price data for
  const txData = contract.methods.GetPairPrice(proofHex, pairIndex).encodeABI();
  const gasEstimate = await contract.methods
    .GetPairPrice(proofHex, pairIndex)
    .estimateGas();
  const transactionObject = {
    from: 'INSERT_ADDRESS',
    to: contractAddress,
    data: txData,
    gas: gasEstimate,
    gasPrice: await web3.eth.getGasPrice(),
  };

  // Sign the transaction with the private key
  const signedTransaction = await web3.eth.accounts.signTransaction(
    transactionObject,
    'INSERT_PRIVATE_KEY'
  );

  // Send the signed transaction
  return await web3.eth.sendSignedTransaction(signedTransaction.rawTransaction);
};

// Function to get the most recently published on-chain price data
const getPriceData = async (index) => {
  const contractAddress = 'INSERT_CONTRACT_ADDRESS';
  const contract = new web3.eth.Contract(feedClientABI, contractAddress);

  // Get the price data and log it to the console
  const priceData = await contract.methods.getPrice(index).call();
  console.log('----- On-Chain Price Data ------');
  console.log('Round : ', priceData[0]);
  console.log('Decimals : ', priceData[1]);
  console.log('Timestamp : ', priceData[2]);
  console.log('Price : ', priceData[3]);
};

const main = async () => {
  const proofs = await getProofs();

  // Convert oracle proof bytes to hex
  const hex = web3.utils.bytesToHex(proofs.evm.proof_bytes);
  deserializeProofBytes(hex);

  // Verify and write the latest price data on-chain
  const receipt = await callContract(hex);
  console.log('Transaction receipt:', receipt);

  // Get the latest price data
  await getPriceData(pairIndex);
};

main();
        const web3 = new Web3('https://rpc.api.moonbeam.network');
const pairIndex = 1;

// Function that fetches proof data from the gRPC server using the specified parameters
const getProofs = () => {
  const address = 'mainnet-dora.supraoracles.com';
  const client = new PullServiceClient(address);

  const request = {
    pair_indexes: [pairIndex], // ETH_USDT
    chain_type: 'evm',
  };

  return new Promise((resolve, reject) => {
    client.getProof(request, (err, response) => {
      if (err) {
        console.error('Error:', err.details);
        return;
      }
      resolve(response);
    });
  });
};

// Function to convert the proof data to human-readable price data
const deserializeProofBytes = (proofHex) => {
  const proof_data = web3.eth.abi.decodeParameters(oracleProofABI, proofHex);
  // Fatching the raw bytes of the signed pair cluster data
  const clusters = proof_data[0].clustersRaw;
  // Fetching which pair IDs have been requested
  const pairMask = proof_data[0].pairMask;

  // Helps in iterating the vector of pair masking
  let pair = 0;
  // Lists of all the pair IDs, prices, decimals, and timestamps requested
  const pairId = [];
  const pairPrice = [];
  const pairDecimal = [];
  const pairTimestamp = [];

  for (let i = 0; i < clusters.length; ++i) {
    // Deserialize the raw bytes of the signed pair cluster data
    const scc = web3.eth.abi.decodeParameters(
      signedCoherentClusterABI,
      clusters[i]
    );

    for (let j = 0; j < scc[0].cc.pair.length; ++j) {
      pair += 1;
      // Verify whether the pair is requested or not
      if (!pairMask[pair - 1]) {
        continue;
      }
      // Pushing the pair IDs, prices, decimals, and timestamps requested in the output vector
      pairId.push(scc[0].cc.pair[j].toString(10));
      pairPrice.push(scc[0].cc.prices[j].toString(10));
      pairDecimal.push(scc[0].cc.decimals[j].toString(10));
      pairTimestamp.push(scc[0].cc.timestamp[j].toString(10));
    }
  }

  console.log('----- Deserialized Data ------');
  console.log('Pair index : ', pairId);
  console.log('Pair Price : ', pairPrice);
  console.log('Pair Decimal : ', pairDecimal);
  console.log('Pair Timestamp : ', pairTimestamp);
  console.log('------------------------------');
};

// Function to call the Oracle client to verify and publish the latest price data
const callContract = async (proofHex) => {
  const contractAddress = 'INSERT_CONTRACT_ADDRESS';
  const contract = new web3.eth.Contract(oracleClientABI, contractAddress);

  // Create the transaction object using the hex-formatted proof and the index of the
  // data pair you requested price data for
  const txData = contract.methods.GetPairPrice(proofHex, pairIndex).encodeABI();
  const gasEstimate = await contract.methods
    .GetPairPrice(proofHex, pairIndex)
    .estimateGas();
  const transactionObject = {
    from: 'INSERT_ADDRESS',
    to: contractAddress,
    data: txData,
    gas: gasEstimate,
    gasPrice: await web3.eth.getGasPrice(),
  };

  // Sign the transaction with the private key
  const signedTransaction = await web3.eth.accounts.signTransaction(
    transactionObject,
    'INSERT_PRIVATE_KEY'
  );

  // Send the signed transaction
  return await web3.eth.sendSignedTransaction(signedTransaction.rawTransaction);
};

        const main = async () => {
  const proofs = await getProofs();

  // Convert oracle proof bytes to hex
  const hex = web3.utils.bytesToHex(proofs.evm.proof_bytes);
  deserializeProofBytes(hex);

  // Verify and write the latest price data on-chain
  const receipt = await callContract(hex);
  console.log('Transaction receipt:', receipt);
        };

main();
        ```

    === "Moonbase Alpha"

        ```js
        const PullServiceClient = require('./pullServiceClient');
const oracleProofABI = require('./resources/oracleProof.json');
const signedCoherentClusterABI = require('./resources/signedCoherentCluster.json');
const { Web3 } = require('web3');
const oracleClientABI = require('./resources/oracleClient.json');
const feedClientABI = require('./resources/feedClient.json'); 

const web3 = new Web3('https://rpc.api.moonbase.moonbeam.network');
const pairIndex = 1;

// Function that fetches proof data from the gRPC server using the specified parameters
const getProofs = () => {
  const address = 'testnet-dora.supraoracles.com';
  const client = new PullServiceClient(address);

  const request = {
    pair_indexes: [pairIndex], // ETH_USDT
    chain_type: 'evm',
  };

  return new Promise((resolve, reject) => {
    client.getProof(request, (err, response) => {
      if (err) {
        console.error('Error:', err.details);
        return;
      }
      resolve(response);
    });
  });
};

// Function to convert the proof data to human-readable price data
const deserializeProofBytes = (proofHex) => {
  const proof_data = web3.eth.abi.decodeParameters(oracleProofABI, proofHex);
  // Fatching the raw bytes of the signed pair cluster data
  const clusters = proof_data[0].clustersRaw;
  // Fetching which pair IDs have been requested
  const pairMask = proof_data[0].pairMask;

  // Helps in iterating the vector of pair masking
  let pair = 0;
  // Lists of all the pair IDs, prices, decimals, and timestamps requested
  const pairId = [];
  const pairPrice = [];
  const pairDecimal = [];
  const pairTimestamp = [];

  for (let i = 0; i < clusters.length; ++i) {
    // Deserialize the raw bytes of the signed pair cluster data
    const scc = web3.eth.abi.decodeParameters(
      signedCoherentClusterABI,
      clusters[i]
    );

    for (let j = 0; j < scc[0].cc.pair.length; ++j) {
      pair += 1;
      // Verify whether the pair is requested or not
      if (!pairMask[pair - 1]) {
        continue;
      }
      // Pushing the pair IDs, prices, decimals, and timestamps requested in the output vector
      pairId.push(scc[0].cc.pair[j].toString(10));
      pairPrice.push(scc[0].cc.prices[j].toString(10));
      pairDecimal.push(scc[0].cc.decimals[j].toString(10));
      pairTimestamp.push(scc[0].cc.timestamp[j].toString(10));
    }
  }

  console.log('----- Deserialized Data ------');
  console.log('Pair index : ', pairId);
  console.log('Pair Price : ', pairPrice);
  console.log('Pair Decimal : ', pairDecimal);
  console.log('Pair Timestamp : ', pairTimestamp);
  console.log('------------------------------');
};

// Function to call the Oracle client to verify and publish the latest price data
const callContract = async (proofHex) => {
  const contractAddress = 'INSERT_CONTRACT_ADDRESS';
  const contract = new web3.eth.Contract(oracleClientABI, contractAddress);

  // Create the transaction object using the hex-formatted proof and the index of the
  // data pair you requested price data for
  const txData = contract.methods.GetPairPrice(proofHex, pairIndex).encodeABI();
  const gasEstimate = await contract.methods
    .GetPairPrice(proofHex, pairIndex)
    .estimateGas();
  const transactionObject = {
    from: 'INSERT_ADDRESS',
    to: contractAddress,
    data: txData,
    gas: gasEstimate,
    gasPrice: await web3.eth.getGasPrice(),
  };

  // Sign the transaction with the private key
  const signedTransaction = await web3.eth.accounts.signTransaction(
    transactionObject,
    'INSERT_PRIVATE_KEY'
  );

  // Send the signed transaction
  return await web3.eth.sendSignedTransaction(signedTransaction.rawTransaction);
};

// Function to get the most recently published on-chain price data
const getPriceData = async (index) => {
  const contractAddress = 'INSERT_CONTRACT_ADDRESS';
  const contract = new web3.eth.Contract(feedClientABI, contractAddress);

  // Get the price data and log it to the console
  const priceData = await contract.methods.getPrice(index).call();
  console.log('----- On-Chain Price Data ------');
  console.log('Round : ', priceData[0]);
  console.log('Decimals : ', priceData[1]);
  console.log('Timestamp : ', priceData[2]);
  console.log('Price : ', priceData[3]);
};

const main = async () => {
  const proofs = await getProofs();

  // Convert oracle proof bytes to hex
  const hex = web3.utils.bytesToHex(proofs.evm.proof_bytes);
  deserializeProofBytes(hex);

  // Verify and write the latest price data on-chain
  const receipt = await callContract(hex);
  console.log('Transaction receipt:', receipt);

  // Get the latest price data
  await getPriceData(pairIndex);
};

main();
        const web3 = new Web3('https://rpc.api.moonbase.moonbeam.network');
const pairIndex = 1;

// Function that fetches proof data from the gRPC server using the specified parameters
const getProofs = () => {
  const address = 'testnet-dora.supraoracles.com';
  const client = new PullServiceClient(address);

  const request = {
    pair_indexes: [pairIndex], // ETH_USDT
    chain_type: 'evm',
  };

  return new Promise((resolve, reject) => {
    client.getProof(request, (err, response) => {
      if (err) {
        console.error('Error:', err.details);
        return;
      }
      resolve(response);
    });
  });
};

// Function to convert the proof data to human-readable price data
const deserializeProofBytes = (proofHex) => {
  const proof_data = web3.eth.abi.decodeParameters(oracleProofABI, proofHex);
  // Fatching the raw bytes of the signed pair cluster data
  const clusters = proof_data[0].clustersRaw;
  // Fetching which pair IDs have been requested
  const pairMask = proof_data[0].pairMask;

  // Helps in iterating the vector of pair masking
  let pair = 0;
  // Lists of all the pair IDs, prices, decimals, and timestamps requested
  const pairId = [];
  const pairPrice = [];
  const pairDecimal = [];
  const pairTimestamp = [];

  for (let i = 0; i < clusters.length; ++i) {
    // Deserialize the raw bytes of the signed pair cluster data
    const scc = web3.eth.abi.decodeParameters(
      signedCoherentClusterABI,
      clusters[i]
    );

    for (let j = 0; j < scc[0].cc.pair.length; ++j) {
      pair += 1;
      // Verify whether the pair is requested or not
      if (!pairMask[pair - 1]) {
        continue;
      }
      // Pushing the pair IDs, prices, decimals, and timestamps requested in the output vector
      pairId.push(scc[0].cc.pair[j].toString(10));
      pairPrice.push(scc[0].cc.prices[j].toString(10));
      pairDecimal.push(scc[0].cc.decimals[j].toString(10));
      pairTimestamp.push(scc[0].cc.timestamp[j].toString(10));
    }
  }

  console.log('----- Deserialized Data ------');
  console.log('Pair index : ', pairId);
  console.log('Pair Price : ', pairPrice);
  console.log('Pair Decimal : ', pairDecimal);
  console.log('Pair Timestamp : ', pairTimestamp);
  console.log('------------------------------');
};

// Function to call the Oracle client to verify and publish the latest price data
const callContract = async (proofHex) => {
  const contractAddress = 'INSERT_CONTRACT_ADDRESS';
  const contract = new web3.eth.Contract(oracleClientABI, contractAddress);

  // Create the transaction object using the hex-formatted proof and the index of the
  // data pair you requested price data for
  const txData = contract.methods.GetPairPrice(proofHex, pairIndex).encodeABI();
  const gasEstimate = await contract.methods
    .GetPairPrice(proofHex, pairIndex)
    .estimateGas();
  const transactionObject = {
    from: 'INSERT_ADDRESS',
    to: contractAddress,
    data: txData,
    gas: gasEstimate,
    gasPrice: await web3.eth.getGasPrice(),
  };

  // Sign the transaction with the private key
  const signedTransaction = await web3.eth.accounts.signTransaction(
    transactionObject,
    'INSERT_PRIVATE_KEY'
  );

  // Send the signed transaction
  return await web3.eth.sendSignedTransaction(signedTransaction.rawTransaction);
};

        const main = async () => {
  const proofs = await getProofs();

  // Convert oracle proof bytes to hex
  const hex = web3.utils.bytesToHex(proofs.evm.proof_bytes);
  deserializeProofBytes(hex);

  // Verify and write the latest price data on-chain
  const receipt = await callContract(hex);
  console.log('Transaction receipt:', receipt);
        };

main();
        ```

And that's all the logic you'll need to request, verify, and write the latest price data for a data pair on-chain using Supra!

To verify and write the price data on-chain, go ahead and run:

```bash
node main.js
```

The deserialized output and the transaction receipt will be printed to the console.

<div id="termynal" data-termynal>
  <span data-ty="input"><span class="file-path"></span>node main.js</span>
  <br>
  <span data-ty>----- Deserialized Data ------
    <br> Pair index :  [ '1' ]
    <br> Pair Price :  [ '3424260000000000000000' ]
    <br> Pair Decimal :  [ '18' ]
    <br> Pair Timestamp :  [ '1709317443269' ]
    <br> ------------------------------
  </span>
  <span data-ty>Transaction receipt: {
    <br>  transactionHash: '0x7d6f14a049e41f8e873dedfed4aff53bc0d52ff06a17fb0901e35464511708b1',
    <br>transactionIndex: 1n,
    <br>blockHash: '0xb3551d522371b192f37e68634e6b0ce616adecf0d8b18e139980d2cf564f9313',
    <br>from: '0x097d9eea23de2d3081169e0225173d0c55768338',
    <br>to: '0xaf1207d950a2231937372cedc2e8ddfa22c40665',
    <br>blockNumber: 6178886n,
    <br>cumulativeGasUsed: 467872n,
    <br>gasUsed: 415356n,
    <br>logs: [],
    <br>logsBloom: '0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',
    <br>status: 1n,
    <br>effectiveGasPrice: 31250000n,
    <br>type: 0n
    <br>}
  </span>
</div>

## Retrieve On-Chain Price Data {: #retrieve-on-chain-price-data }

If you want to access the on-chain price data, you can create another contract that interacts with Supra's Storage contract.

### Create the Retrieval Contract {: #create-the-retrieval-contract }

To create the contract, you can take the following steps:

1. Create a new file for the smart contract, which we'll name `FeedClient`

    ```bash
    touch FeedClient.sol
    ```

2. In the file, create an interface for Supra's Storage contract. The interface has two functions: one for retrieving the price data for a single data pair and another that retrieves price data for multiple data pairs. Then, in our `FeedClient` contract, we'll instantiate the `ISupraSValueFeed` interface with the address of Supra's Storage contract on Moonbeam or Moonbase Alpha

    ```solidity title="FeedClient.sol"
    // SPDX-License-Identifier: UNLICENSED
pragma solidity 0.8.20;

interface ISupraSValueFeed {
    function getSvalue(uint64 _pairIndex) external view returns (bytes32, bool);
    function getSvalues(
        uint64[] memory _pairIndexes
    ) external view returns (bytes32[] memory, bool[] memory);
}
    ```

3. In the same file, create the `FeedClient` contract. As mentioned in the previous step, the constructor of this contract instantiates the `ISupraSValueFeed` interface with the address of Supra's Storage contract. The contract also includes functions that call the `getSValue` and `getSValues` functions of the Storage contract and return the response in a decoded format

    ```solidity title="FeedClient.sol"
    // ...

    contract FeedClient {
    // The storage contract
    ISupraSValueFeed internal sValueFeed;

    constructor(address storage_) {
        sValueFeed = ISupraSValueFeed(storage_);
    }

    function unpack(bytes32 data) internal pure returns (uint256[4] memory) {
        uint256[4] memory info;

        info[0] = bytesToUint256(abi.encodePacked(data >> 192)); // round
        info[1] = bytesToUint256(abi.encodePacked((data << 64) >> 248)); // decimal
        info[2] = bytesToUint256(abi.encodePacked((data << 72) >> 192)); // timestamp
        info[3] = bytesToUint256(abi.encodePacked((data << 136) >> 160)); // price

        return info;
    }

    function bytesToUint256(
        bytes memory _bs
    ) internal pure returns (uint256 value) {
        require(_bs.length == 32, "bytes length is not 32.");
        assembly {
            value := mload(add(_bs, 0x20))
        }
    }

    function getPrice(
        uint64 _priceIndex
    ) external view returns (uint256[4] memory) {
        (bytes32 val, ) = sValueFeed.getSvalue(_priceIndex);

        uint256[4] memory decoded = unpack(val);

        return decoded;
    }

    function getPriceForMultiplePair(
        uint64[] memory _pairIndexes
    ) external view returns (uint256[4][] memory) {
        (bytes32[] memory val, ) = sValueFeed.getSvalues(_pairIndexes);

        uint256[4][] memory decodedArray = new uint256[4][](val.length);

        for (uint256 i = 0; i < val.length; i++) {
            uint256[4] memory decoded = unpack(val[i]);
            decodedArray[i] = decoded;
        }

        return decodedArray;
    }
}
    ```

??? code "FeedClient.sol"

    ```solidity
    // SPDX-License-Identifier: UNLICENSED
pragma solidity 0.8.20;

interface ISupraSValueFeed {
    function getSvalue(uint64 _pairIndex) external view returns (bytes32, bool);
    function getSvalues(
        uint64[] memory _pairIndexes
    ) external view returns (bytes32[] memory, bool[] memory);
}

contract FeedClient {
    // The storage contract
    ISupraSValueFeed internal sValueFeed;

    constructor(address storage_) {
        sValueFeed = ISupraSValueFeed(storage_);
    }

    function unpack(bytes32 data) internal pure returns (uint256[4] memory) {
        uint256[4] memory info;

        info[0] = bytesToUint256(abi.encodePacked(data >> 192)); // round
        info[1] = bytesToUint256(abi.encodePacked((data << 64) >> 248)); // decimal
        info[2] = bytesToUint256(abi.encodePacked((data << 72) >> 192)); // timestamp
        info[3] = bytesToUint256(abi.encodePacked((data << 136) >> 160)); // price

        return info;
    }

    function bytesToUint256(
        bytes memory _bs
    ) internal pure returns (uint256 value) {
        require(_bs.length == 32, "bytes length is not 32.");
        assembly {
            value := mload(add(_bs, 0x20))
        }
    }

    function getPrice(
        uint64 _priceIndex
    ) external view returns (uint256[4] memory) {
        (bytes32 val, ) = sValueFeed.getSvalue(_priceIndex);

        uint256[4] memory decoded = unpack(val);

        return decoded;
    }

    function getPriceForMultiplePair(
        uint64[] memory _pairIndexes
    ) external view returns (uint256[4][] memory) {
        (bytes32[] memory val, ) = sValueFeed.getSvalues(_pairIndexes);

        uint256[4][] memory decodedArray = new uint256[4][](val.length);

        for (uint256 i = 0; i < val.length; i++) {
            uint256[4] memory decoded = unpack(val[i]);
            decodedArray[i] = decoded;
        }

        return decodedArray;
    }
}
    ```

### Deploy the Contract {: #deploy-the-retrieval-contract }

The steps for compiling and deploying the contract are similar to those in the previous section. You can either duplicate the `deploy.js` file and make the necessary edits or directly edit the existing `deploy.js` file with the following two changes:

- Update the contract name from `OracleClient` to `FeedClient`
- Update the contract address in the deployment transaction to be the Storage contract address instead of the Pull contract address

You should end up with the following code:

???+ code "deploy.js"

    === "Moonbeam"

        ```js
        const fs = require('fs');
const solc = require('solc');
const { Web3 } = require('web3');

const web3 = new Web3('https://rpc.api.moonbeam.network');

const compile = () => {
  // Get path and load contract
  const source = fs.readFileSync('FeedClient.sol', 'utf8');

  // Create input object
  const input = {
    language: 'Solidity',
    sources: {
      'FeedClient.sol': {
        content: source,
      },
    },
    settings: {
      outputSelection: {
        '*': {
          '*': ['*'],
        },
      },
    },
  };
  // Compile the contract
  const tempFile = JSON.parse(solc.compile(JSON.stringify(input)));
  const contractFile = tempFile.contracts['FeedClient.sol']['FeedClient'];

  // Save ABI to a file
  fs.writeFileSync(
    './resources/feedClient.json',
    JSON.stringify(contractFile.abi, null, 4),
    'utf8'
  );

  return { abi: contractFile.abi, bytecode: contractFile.evm.bytecode.object };
};

const deploy = async () => {
  // Compile the contract
  const { abi, bytecode } = compile();

  // Create contract instance
  const contract = new web3.eth.Contract(abi);

  // Create the deployment transaction and pass in the Storage contract address
  const deployTx = contract.deploy({
    data: bytecode,
    arguments: ['0xD02cc7a670047b6b012556A88e275c685d25e0c9'],
  });

  // Sign transaction with PK
  const createTransaction = await web3.eth.accounts.signTransaction(
    {
      data: deployTx.encodeABI(),
      gas: await deployTx.estimateGas(),
      gasPrice: await web3.eth.getGasPrice(),
      nonce: await web3.eth.getTransactionCount('INSERT_ADDRESS'),
    },
    'INSERT_PRIVATE_KEY'
  );

  // Send transaction and wait for receipt
  const createReceipt = await web3.eth.sendSignedTransaction(
    createTransaction.rawTransaction
  );

  console.log(`Contract deployed at address: ${createReceipt.contractAddress}`);
};

deploy();
        ```

    === "Moonbase Alpha"

        ```js
        const fs = require('fs');
const solc = require('solc');
const { Web3 } = require('web3');

const web3 = new Web3('https://rpc.api.moonbase.moonbeam.network');

const compile = () => {
  // Get path and load contract
  const source = fs.readFileSync('FeedClient.sol', 'utf8');

  // Create input object
  const input = {
    language: 'Solidity',
    sources: {
      'FeedClient.sol': {
        content: source,
      },
    },
    settings: {
      outputSelection: {
        '*': {
          '*': ['*'],
        },
      },
    },
  };
  // Compile the contract
  const tempFile = JSON.parse(solc.compile(JSON.stringify(input)));
  const contractFile = tempFile.contracts['FeedClient.sol']['FeedClient'];

  // Save ABI to a file
  fs.writeFileSync(
    './resources/feedClient.json',
    JSON.stringify(contractFile.abi, null, 4),
    'utf8'
  );

  return { abi: contractFile.abi, bytecode: contractFile.evm.bytecode.object };
};

const deploy = async () => {
  // Compile the contract
  const { abi, bytecode } = compile();

  // Create contract instance
  const contract = new web3.eth.Contract(abi);

  // Create the deployment transaction and pass in the Storage contract address
  const deployTx = contract.deploy({
    data: bytecode,
    arguments: ['0x4591d1B110ad451d8220d82252F829E8b2a91B17'],
  });

  // Sign transaction with PK
  const createTransaction = await web3.eth.accounts.signTransaction(
    {
      data: deployTx.encodeABI(),
      gas: await deployTx.estimateGas(),
      gasPrice: await web3.eth.getGasPrice(),
      nonce: await web3.eth.getTransactionCount('INSERT_ADDRESS'),
    },
    'INSERT_PRIVATE_KEY'
  );

  // Send transaction and wait for receipt
  const createReceipt = await web3.eth.sendSignedTransaction(
    createTransaction.rawTransaction
  );

  console.log(`Contract deployed at address: ${createReceipt.contractAddress}`);
};

deploy();
        ```

To deploy the contract, run:

```bash
node deploy.js
```

The contract address will be printed to your terminal; save it as you'll need it in the next section.

### Call the Contract {: #call-the-retrieval-contract }

For simplicity, you can add a function to the `main.js` file that retrieves the data from the `FeedClient` contract:

1. Import the ABI of the `FeedClient` contract

    ```js
    const feedClientABI = require('./resources/feedClient.json');
    ```

2. Create a function named `getPriceData` that accepts the index of a data pair as a parameter and will be responsible for calling the `FeedClient` contract

    ```js title="main.js"
    const getPriceData = async (index) => {
      // Add logic here
    };
    ```

3. In the `getPriceData` function, create an instance of the deployed `FeedClient` contract using the ABI and the contract address, which you should have saved from deploying the contract in the previous set of steps

    ```js title="main.js"
    const getPriceData = async (index) => {
  const contractAddress = 'INSERT_CONTRACT_ADDRESS';
  const contract = new web3.eth.Contract(feedClientABI, contractAddress);
    };
    ```

4. Call the `getPrice` function of the `FeedClient` contract and log the results to the console

    ```js title="main.js"
    const getPriceData = async (index) => {
  const contractAddress = 'INSERT_CONTRACT_ADDRESS';
  const contract = new web3.eth.Contract(feedClientABI, contractAddress);

  // Get the price data and log it to the console
  const priceData = await contract.methods.getPrice(index).call();
  console.log('----- On-Chain Price Data ------');
  console.log('Round : ', priceData[0]);
  console.log('Decimals : ', priceData[1]);
  console.log('Timestamp : ', priceData[2]);
  console.log('Price : ', priceData[3]);
};
    ```

5. In the `main` function, add the logic to call the `getPriceData` function

    ```js title="main.js"
    const main = async () => {
  const proofs = await getProofs();

  // Convert oracle proof bytes to hex
  const hex = web3.utils.bytesToHex(proofs.evm.proof_bytes);
  deserializeProofBytes(hex);

  // Verify and write the latest price data on-chain
  const receipt = await callContract(hex);
  console.log('Transaction receipt:', receipt);

  // Get the latest price data
  await getPriceData(pairIndex);
};

main();
    ```

??? code "main.js"

    === "Moonbeam"

        ```js
        const PullServiceClient = require('./pullServiceClient');
const oracleProofABI = require('./resources/oracleProof.json');
const signedCoherentClusterABI = require('./resources/signedCoherentCluster.json');
const { Web3 } = require('web3');
const oracleClientABI = require('./resources/oracleClient.json');
const feedClientABI = require('./resources/feedClient.json'); 

const web3 = new Web3('https://rpc.api.moonbeam.network');
const pairIndex = 1;

// Function that fetches proof data from the gRPC server using the specified parameters
const getProofs = () => {
  const address = 'mainnet-dora.supraoracles.com';
  const client = new PullServiceClient(address);

  const request = {
    pair_indexes: [pairIndex], // ETH_USDT
    chain_type: 'evm',
  };

  return new Promise((resolve, reject) => {
    client.getProof(request, (err, response) => {
      if (err) {
        console.error('Error:', err.details);
        return;
      }
      resolve(response);
    });
  });
};

// Function to convert the proof data to human-readable price data
const deserializeProofBytes = (proofHex) => {
  const proof_data = web3.eth.abi.decodeParameters(oracleProofABI, proofHex);
  // Fatching the raw bytes of the signed pair cluster data
  const clusters = proof_data[0].clustersRaw;
  // Fetching which pair IDs have been requested
  const pairMask = proof_data[0].pairMask;

  // Helps in iterating the vector of pair masking
  let pair = 0;
  // Lists of all the pair IDs, prices, decimals, and timestamps requested
  const pairId = [];
  const pairPrice = [];
  const pairDecimal = [];
  const pairTimestamp = [];

  for (let i = 0; i < clusters.length; ++i) {
    // Deserialize the raw bytes of the signed pair cluster data
    const scc = web3.eth.abi.decodeParameters(
      signedCoherentClusterABI,
      clusters[i]
    );

    for (let j = 0; j < scc[0].cc.pair.length; ++j) {
      pair += 1;
      // Verify whether the pair is requested or not
      if (!pairMask[pair - 1]) {
        continue;
      }
      // Pushing the pair IDs, prices, decimals, and timestamps requested in the output vector
      pairId.push(scc[0].cc.pair[j].toString(10));
      pairPrice.push(scc[0].cc.prices[j].toString(10));
      pairDecimal.push(scc[0].cc.decimals[j].toString(10));
      pairTimestamp.push(scc[0].cc.timestamp[j].toString(10));
    }
  }

  console.log('----- Deserialized Data ------');
  console.log('Pair index : ', pairId);
  console.log('Pair Price : ', pairPrice);
  console.log('Pair Decimal : ', pairDecimal);
  console.log('Pair Timestamp : ', pairTimestamp);
  console.log('------------------------------');
};

// Function to call the Oracle client to verify and publish the latest price data
const callContract = async (proofHex) => {
  const contractAddress = 'INSERT_CONTRACT_ADDRESS';
  const contract = new web3.eth.Contract(oracleClientABI, contractAddress);

  // Create the transaction object using the hex-formatted proof and the index of the
  // data pair you requested price data for
  const txData = contract.methods.GetPairPrice(proofHex, pairIndex).encodeABI();
  const gasEstimate = await contract.methods
    .GetPairPrice(proofHex, pairIndex)
    .estimateGas();
  const transactionObject = {
    from: 'INSERT_ADDRESS',
    to: contractAddress,
    data: txData,
    gas: gasEstimate,
    gasPrice: await web3.eth.getGasPrice(),
  };

  // Sign the transaction with the private key
  const signedTransaction = await web3.eth.accounts.signTransaction(
    transactionObject,
    'INSERT_PRIVATE_KEY'
  );

  // Send the signed transaction
  return await web3.eth.sendSignedTransaction(signedTransaction.rawTransaction);
};

// Function to get the most recently published on-chain price data
const getPriceData = async (index) => {
  const contractAddress = 'INSERT_CONTRACT_ADDRESS';
  const contract = new web3.eth.Contract(feedClientABI, contractAddress);

  // Get the price data and log it to the console
  const priceData = await contract.methods.getPrice(index).call();
  console.log('----- On-Chain Price Data ------');
  console.log('Round : ', priceData[0]);
  console.log('Decimals : ', priceData[1]);
  console.log('Timestamp : ', priceData[2]);
  console.log('Price : ', priceData[3]);
};

const main = async () => {
  const proofs = await getProofs();

  // Convert oracle proof bytes to hex
  const hex = web3.utils.bytesToHex(proofs.evm.proof_bytes);
  deserializeProofBytes(hex);

  // Verify and write the latest price data on-chain
  const receipt = await callContract(hex);
  console.log('Transaction receipt:', receipt);

  // Get the latest price data
  await getPriceData(pairIndex);
};

main();
        ```

    === "Moonbase Alpha"

        ```js
        const PullServiceClient = require('./pullServiceClient');
const oracleProofABI = require('./resources/oracleProof.json');
const signedCoherentClusterABI = require('./resources/signedCoherentCluster.json');
const { Web3 } = require('web3');
const oracleClientABI = require('./resources/oracleClient.json');
const feedClientABI = require('./resources/feedClient.json'); 

const web3 = new Web3('https://rpc.api.moonbase.moonbeam.network');
const pairIndex = 1;

// Function that fetches proof data from the gRPC server using the specified parameters
const getProofs = () => {
  const address = 'testnet-dora.supraoracles.com';
  const client = new PullServiceClient(address);

  const request = {
    pair_indexes: [pairIndex], // ETH_USDT
    chain_type: 'evm',
  };

  return new Promise((resolve, reject) => {
    client.getProof(request, (err, response) => {
      if (err) {
        console.error('Error:', err.details);
        return;
      }
      resolve(response);
    });
  });
};

// Function to convert the proof data to human-readable price data
const deserializeProofBytes = (proofHex) => {
  const proof_data = web3.eth.abi.decodeParameters(oracleProofABI, proofHex);
  // Fatching the raw bytes of the signed pair cluster data
  const clusters = proof_data[0].clustersRaw;
  // Fetching which pair IDs have been requested
  const pairMask = proof_data[0].pairMask;

  // Helps in iterating the vector of pair masking
  let pair = 0;
  // Lists of all the pair IDs, prices, decimals, and timestamps requested
  const pairId = [];
  const pairPrice = [];
  const pairDecimal = [];
  const pairTimestamp = [];

  for (let i = 0; i < clusters.length; ++i) {
    // Deserialize the raw bytes of the signed pair cluster data
    const scc = web3.eth.abi.decodeParameters(
      signedCoherentClusterABI,
      clusters[i]
    );

    for (let j = 0; j < scc[0].cc.pair.length; ++j) {
      pair += 1;
      // Verify whether the pair is requested or not
      if (!pairMask[pair - 1]) {
        continue;
      }
      // Pushing the pair IDs, prices, decimals, and timestamps requested in the output vector
      pairId.push(scc[0].cc.pair[j].toString(10));
      pairPrice.push(scc[0].cc.prices[j].toString(10));
      pairDecimal.push(scc[0].cc.decimals[j].toString(10));
      pairTimestamp.push(scc[0].cc.timestamp[j].toString(10));
    }
  }

  console.log('----- Deserialized Data ------');
  console.log('Pair index : ', pairId);
  console.log('Pair Price : ', pairPrice);
  console.log('Pair Decimal : ', pairDecimal);
  console.log('Pair Timestamp : ', pairTimestamp);
  console.log('------------------------------');
};

// Function to call the Oracle client to verify and publish the latest price data
const callContract = async (proofHex) => {
  const contractAddress = 'INSERT_CONTRACT_ADDRESS';
  const contract = new web3.eth.Contract(oracleClientABI, contractAddress);

  // Create the transaction object using the hex-formatted proof and the index of the
  // data pair you requested price data for
  const txData = contract.methods.GetPairPrice(proofHex, pairIndex).encodeABI();
  const gasEstimate = await contract.methods
    .GetPairPrice(proofHex, pairIndex)
    .estimateGas();
  const transactionObject = {
    from: 'INSERT_ADDRESS',
    to: contractAddress,
    data: txData,
    gas: gasEstimate,
    gasPrice: await web3.eth.getGasPrice(),
  };

  // Sign the transaction with the private key
  const signedTransaction = await web3.eth.accounts.signTransaction(
    transactionObject,
    'INSERT_PRIVATE_KEY'
  );

  // Send the signed transaction
  return await web3.eth.sendSignedTransaction(signedTransaction.rawTransaction);
};

// Function to get the most recently published on-chain price data
const getPriceData = async (index) => {
  const contractAddress = 'INSERT_CONTRACT_ADDRESS';
  const contract = new web3.eth.Contract(feedClientABI, contractAddress);

  // Get the price data and log it to the console
  const priceData = await contract.methods.getPrice(index).call();
  console.log('----- On-Chain Price Data ------');
  console.log('Round : ', priceData[0]);
  console.log('Decimals : ', priceData[1]);
  console.log('Timestamp : ', priceData[2]);
  console.log('Price : ', priceData[3]);
};

const main = async () => {
  const proofs = await getProofs();

  // Convert oracle proof bytes to hex
  const hex = web3.utils.bytesToHex(proofs.evm.proof_bytes);
  deserializeProofBytes(hex);

  // Verify and write the latest price data on-chain
  const receipt = await callContract(hex);
  console.log('Transaction receipt:', receipt);

  // Get the latest price data
  await getPriceData(pairIndex);
};

main();
        ```

Run the following command to print the price data to the terminal:

!!! note
    Feel free to comment out the calls to the `deserializeProofBytes` and `callContract` functions if you only want to retrieve the price data.

```bash
node main.js
```

The terminal output should now include the price data.

<div id="termynal" data-termynal>
  <span data-ty="input"><span class="file-path"></span>node main.js</span>
  <br>
  <span data-ty>----- On-Chain Price Data ------
    <br> Round :  1709333298000n
    <br> Decimals :  18n
    <br> Timestamp :  1709333298216n
    <br> Price :  3430850000000000000000n
  </span>
</div>

And that's it! You've successfully fetched the proof data from Supra, verified and published it on-chain, and retrieved it! For more information on Supra Oracles, please check out their [documentation](https://docs.supra.com/){target=\_blank}.

<div class="page-disclaimer">
    This tutorial is for educational purposes only. As such, any contracts or code created in this tutorial should not be used in production.
</div>

<div class="page-disclaimer">
  The information presented herein has been provided by third parties and is made available solely for general information purposes. Moonbeam does not endorse any project listed and described on the Moonbeam Doc Website (https://docs.moonbeam.network/). Moonbeam Foundation does not warrant the accuracy, completeness or usefulness of this information. Any reliance you place on such information is strictly at your own risk. Moonbeam Foundation disclaims all liability and responsibility arising from any reliance placed on this information by you or by anyone who may be informed of any of its contents. All statements and/or opinions expressed in these materials are solely the responsibility of the person or entity providing those materials and do not necessarily represent the opinion of Moonbeam Foundation. The information should not be construed as professional or financial advice of any kind. Advice from a suitably qualified professional should always be sought in relation to any particular matter or circumstance. The information herein may link to or integrate with other websites operated or content provided by third parties, and such other websites may link to this website. Moonbeam Foundation has no control over any such other websites or their content and will have no liability arising out of or related to such websites or their content. The existence of any such link does not constitute an endorsement of such websites, the content of the websites, or the operators of the websites. These links are being provided to you only as a convenience and you release and hold Moonbeam Foundation harmless from any and all liability arising from your use of this information or the information provided by any third-party website or service.
</div>
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/tutorials/interoperability/cross-chain-dao/
--- BEGIN CONTENT ---
---
title: Build a Cross-Chain DAO with OpenZeppelin's Governor
description: In this step-by-step tutorial, you'll learn about connected contracts and how to create a cross-chain DAO using OpenZeppelin's Governor contract on Moonbeam.
categories: Tutorials
---

# Building a Cross-Chain DAO with OpenZeppelin's Governor Contract

_by Jeremy Boetticher_

## Introduction {: #introduction }

Moonbeam works hard to support interoperability and cross-chain logic. Its [multi-chain](https://moonbeam.network/build/use-case){target=\_blank} initiative requires an updating of previously understood smart contract concepts so that they fit a cross-chain world. While some cross-chain primitives have been available for years, such as cross-chain tokens, others are only now starting to be worked on, such as cross-chain swaps, AMMs, and, of particular interest for this tutorial, DAOs.

In this tutorial, we will work through a thought process of writing smart contracts for a cross-chain DAO. The smart contracts in this example will be based off of OpenZeppelin's Governance smart contracts to demonstrate an evolution from single-chain to cross-chain and to highlight some incompatibilities that one might face when converting a DApp concept from single-chain to cross-chain. The cross-chain protocol used in this example will be [LayerZero](/builders/interoperability/protocols/layerzero/){target=\_blank}, but you are encouraged to adapt its concepts to any other protocol that you see fit, since cross-chain concepts often overlap between the protocols that Moonbeam hosts.  

The purpose of this tutorial is not to be the end-all, be-all definition of what a cross-chain DAO would be like, but instead to provide an example of thinking about the intricacies of writing a significantly complex cross-chain DApp. The focus of this tutorial will be on architecture, specifically cross-chain smart contract logic, instead of deploying and testing. **The following smart contracts are not tested or recommended for production use**. That being said, feel free to take inspiration from some of the design choices if you decide to write your cross-chain DAO. The full code base and demonstration of the DAO is available in a [GitHub repository](https://github.com/jboetticher/cross-chain-dao){target=\_blank}, with relevant instructions.  

<div class="intro-disclaimer">
  The information presented herein is for informational purposes only and has been provided by third parties. Moonbeam does not endorse any project listed and described on the Moonbeam docs website (https://docs.moonbeam.network/).
</div>

## Intuition And Planning {: #intuition-and-planning }

DAO stands for "Decentralized Autonomous Organization." In order for a smart contract to be a DAO, it must be:  

- **Decentralized** — control is separated and distributed among many actors
- **Autonomous** — execution must occur without reliance on a single person, government, or team
- **Organized** — there must be a way for actions to be proposed and then taken: code is law

One of the best single-chain DAOs is [Compound Finance's DAO](https://compound.finance/governance){target=\_blank}. It is **organized** because the smart contract allows users to propose actions to be taken on chain in the form of transaction parameters, which are later executed with the smart contract as the origin. It is **autonomous** because the execution of the proposals is permissionless and thus does not depend on any specific person or team. It is **decentralized** because proposals are voted on by holders of the Compound Finance token.

Let's take a look at the phases that a proposal in a DAO like Compound Finance's takes:  

![Typical DAO](/images/tutorials/interoperability/cross-chain-dao/cross-chain-dao-1.webp)

1. **Proposal** — a user proposes that the DAO execute one or more transactions
2. **Voting** — after a voting delay time period, a voting period opens, which allows users to vote with their voting weight. The voting weight is determined by a token balance snapshot typically taken sometime between the proposal start and the end of the voting delay period  
3. **Timelock** — an optional period that allows users to exit the ecosystem (sell their tokens) before the proposal can be executed
4. **Execution** — if the vote is successful, any user can trustlessly execute it

But what about a cross-chain DAO? In a cross-chain DAO, the actions that you would typically take should also be available cross-chain: proposals, votes, executions, cancellations, etc. This requires a more complex architecture since a lot of information has to be replicated across chains.  

There are many ways to architect a cross-chain DApp. You could make a more distributed system, where data and logic are distributed to multiple chains to maximize their use. On the other end of the spectrum, you could use a hub-and-spoke model, where the main logic and data are stored on a single chain and cross-chain messages will interact with it.  

![Cross-Chain DAO](/images/tutorials/interoperability/cross-chain-dao/cross-chain-dao-2.webp)

Let's break down some of the steps in more detail:  

1. **Proposal** — a user proposes that the DAO execute one or more transactions on the **hub** chain. A cross-chain message is sent to the satellite smart contracts on the **spoke** chains to let them know the parameters of the vote to take place  
2. **Voting** — after a voting delay time period, a voting period opens, which allows users to vote with their voting weight on every chain. The voting weight is determined by a cross-chain token's balance on each chain at a certain timestamp between the proposal start and end  
3. **Collection** — after the voting period, the cross-chain DAO on the **hub** chain sends a request to the **spoke** chains to send the voting results of each chain to the **hub** chain  
4. **Timelock** — an optional period that allows users to exit the ecosystem (sell their tokens) before the proposal can be executed  
5. **Execution** — if the vote is successful, any user can execute it trustlessly on the **hub** chain

!!! note
    Take note of the new collection phase. This is where the cross-chain aspect changes the logic the most. Essentially, the votes on each spoke chain must be collected and submitted to the hub chain after the voting period is over.

The process shown here makes it so that anyone can vote from across chains, so long as they hold the DAO token. For holding information that is read-only, we will be storing it on a single chain. Rare one-off actions such as proposals, cancellations, and so on are best done as a hub-and-spoke model. For information regarding voting logic, since users will be voting on multiple chains, voting weight and vote sums will be stored on each spoke chain and only sent to the hub chain after voting is over, since cross-chain actions are generally expensive.  

![Smart contracts overview](/images/tutorials/interoperability/cross-chain-dao/cross-chain-dao-3.webp)  

This is, of course, only one way to implement a cross-chain DAO, and you are encouraged to think of alternative and better ways. In the next section, we will look at an implementation.  

## Checking Prerequisites {: #checking-prerequisites }

Before we start writing the entire project, it's important to note that its finished form can be found in its own [cross-chain DAO GitHub repository](https://github.com/jboetticher/cross-chain-dao){target=\_blank}. It uses Hardhat, so prerequisite knowledge will be helpful for understanding how the repository works. This tutorial will not include information on how to use Hardhat and will instead focus solely on the smart contracts. If you would like to follow along, the prerequisites are as follows:  

- A fresh Hardhat project and [knowledge of how to use Hardhat](/builders/ethereum/dev-env/hardhat/){target=\_blank}
- [OpenZeppelin smart contracts installed](https://github.com/OpenZeppelin/openzeppelin-contracts){target=\_blank} as a dependency
- [LayerZero smart contracts installed](https://github.com/LayerZero-Labs/solidity-examples){target=\_blank} as a dependency

To install both dependencies, you can run:

```bash
npm install @openzeppelin/contracts @layerzerolabs/solidity-examples
```

## Writing the Cross-Chain DAO Token Contract {: #cross-chain-dao-token-contract }

Let's start at the basics and sort out how users will have their voting power calculated.

In Compound Finance's DAO, a user needs the COMP token to vote, which enables the decentralization aspect of a DAO. OpenZeppelin's `Governor` smart contract also has this feature, abstracting the tokens to votes feature into an [`IVotes` interface](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/utils/IVotes.sol){target=\_blank}.  

The `IVotes` interface requires a lot of different functions to represent the different weights in a voting scheme. Fortunately, OpenZeppelin provides an ERC-20 implementation of `IVotes`, called [ERC20Votes](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/extensions/ERC20Votes.sol){target=\_blank}.  

Recall [from earlier](#intuition-and-planning){target=\_blank} that we intend to have users vote on each chain and to only send voting data to the hub chain during the collection phase. This means that the voting weights must be stored on each chain. This is very easy, since all we have to do is ensure that the `ERC20Votes` contract is deployed on each chain, or, in other words, make the DAO token a cross-chain token.  

Previously, it was mentioned that LayerZero is being used as the cross-chain protocol for this tutorial. LayerZero was chosen because of their [OFT contract](https://github.com/LayerZero-Labs/solidity-examples/blob/main/contracts/token/oft/v1/OFT.sol){target=\_blank}, which makes it extremely easy to make an ERC-20 token cross-chain. This doesn't mean that you have to use LayerZero, though; every other cross-chain protocol has its own methods and the ability to create cross-chain assets.  

We will create a new file named `OFTVotes.sol`:  

```solidity
// SPDX-License-Identifier: MIT

pragma solidity ^0.8.0;

import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Votes.sol";
import "@openzeppelin/contracts/utils/introspection/IERC165.sol";
import "@layerzerolabs/solidity-examples/contracts/token/oft/IOFT.sol";
import "@layerzerolabs/solidity-examples/contracts/token/oft/OFTCore.sol";

abstract contract OFTVotes is OFTCore, ERC20Votes, IOFT {
    constructor(string memory _name, string memory _symbol, address _lzEndpoint) ERC20(_name, _symbol) OFTCore(_lzEndpoint) {}
}
```

As you can see, `OFTVotes` is an abstract smart contract that inherits from the `OFTCore`, `ERC20Votes`, and `IOFT` smart contracts. If properly implemented, this will give it both cross-chain ERC-20 properties as well as voting properties. Let's add the following function overrides to the `OFTVotes` smart contract:  

```solidity
function supportsInterface(bytes4 interfaceId) public view virtual override(OFTCore, IERC165) returns (bool) {
    return interfaceId == type(IOFT).interfaceId || interfaceId == type(IERC20).interfaceId || super.supportsInterface(interfaceId);
}

function token() public view virtual override returns (address) {
    return address(this);
}

function circulatingSupply() public view virtual override returns (uint) {
    return totalSupply();
}

function _debitFrom(address _from, uint16, bytes memory, uint _amount) internal virtual override returns(uint) {
    address spender = _msgSender();
    if (_from != spender) _spendAllowance(_from, spender, _amount);
    _burn(_from, _amount);
    return _amount;
}

function _creditTo(uint16, address _toAddress, uint _amount) internal virtual override returns(uint) {
    _mint(_toAddress, _amount);
    return _amount;
}
```

The first few functions are just ensuring compatibility with the smart contracts that they inherit from.

The `_debitFrom` function is a little spicier: it includes logic to burn tokens so that the token bridge works. Similarly, the `_creditTo` function includes logic to mint tokens. These two functions are required by the `OFTCore` smart contract. If you are wondering why minting and burning are involved when most bridges wrap, it's because OFT [teleports assets](/builders/interoperability/xcm/overview/#xcm-transport-protocols){target=\_blank} instead of wrapping them (similar to one of the XCM asset protocols).  

The `OFTVotes` contract is abstract, so let's create a final smart contract that we'll deploy. In the `contracts` folder, create a new smart contract called `CrossChainDAOToken.sol` and add the following:  

```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "./OFTVotes.sol";

contract CrossChainDAOToken is OFTVotes {
    constructor(uint256 _initialSupply, address _lzEndpoint)
        OFTVotes("Cross Chain DAO Token", "CCDT", _lzEndpoint)
        ERC20Permit("Cross Chain DAO Token")
    {
        _mint(msg.sender, _initialSupply);
    }

    // The functions below are overrides required by Solidity

    function _afterTokenTransfer(address from, address to, uint256 amount) internal override(ERC20Votes) {
        super._afterTokenTransfer(from, to, amount);
    }

    function _mint(address to, uint256 amount) internal override(ERC20Votes) {
        super._mint(to, amount);
    }

    function _burn(address account, uint256 amount) internal override(ERC20Votes) {
        super._burn(account, amount);
    }
}
```

This smart contract isn't very special since all it really does is add metadata in the constructor and mint preliminary tokens to the user. All of the overridden functions are only there because of Solidity rules, and they simply default to a parent contract's implementation. The only reason we didn't add the metadata to `OFTVotes` is because, in theory, that smart contract could be reused elsewhere.  

The `CrossChainDAOToken` smart contract is now ready for deployment on both spoke and hub chains. You can check its complete version in the [example repository](https://github.com/jboetticher/cross-chain-dao/blob/main/contracts/CrossChainDAOToken.sol){target=\_blank}.  


## Writing the Cross-Chain DAO Contract {: #cross-chain-dao-contract }

Now to the meat of this tutorial: the cross-chain DAO. To be clear, not *all* of the cross-chain logic will be stored in the cross-chain DAO smart contract. Instead, we will separate the hub logic into one contract and the [spoke chain logic into another](#dao-satellite-contract){target=\_blank}. This makes sense because of the hub-and-spoke model: some of the logic is stored on a single hub chain, while the spoke chains interface with it through a simpler satellite contract. We don't need logic meant to be on spoke chains to be on the hub chain.

We can start off by creating the base for the cross-chain DAO and then edit it so that it becomes cross-chain. To do so, we'll be taking the following steps:

1. Create the base contract using OpenZeppelin's contract wizard
2. Add support for cross-chain messaging (through LayerZero in this specific example)
3. Count votes from spoke chains
4. Add a new collection phase between voting and execution  
    - Requesting the collection of votes from spoke chains
    - Receiving the collection of votes from spoke chains
5. Add functionality to let spoke chains know when there is a new proposal to vote on
6. (Optional) Add ability to receive cross-chain messages to do non-voting action(s), like proposing or executing

### Starting with the OpenZeppelin Contract Wizard {: #starting-with-the-openzeppelin-contract-wizard }

A logical starting point for thinking about writing a cross-chain DAO is its predecessor: a single-chain DAO. There are many different implementations that exist, but since [OpenZeppelin](https://www.openzeppelin.com/solidity-contracts){target=\_blank} hosts an already popular smart contract repository, we will use their Governance smart contracts. A second reason why we're using OpenZeppelin's smart contracts is because they're based off of Compound Finance's DAO, which we've already investigated in the [previous section](#intuition-and-planning).  

A good way to play with the configurations of the `Governor` smart contract is to use the OpenZeppelin smart contract wizard. By going to the [OpenZeppelin contract page](https://www.openzeppelin.com/solidity-contracts){target=\_blank}, scrolling down, and clicking on the **Governor** tab, you can view the different ways that you can configure the `Governor` smart contract.

We're going to generate as simple of a base smart contract as possible for demonstration purposes:  

1. Name the `Governor` contract **CrossChainDAO**
2. Set the **Voting Delay** to 0 for simplicity, which also makes it so that the voting weight snapshot is taken as soon as the proposal is made
3. Set the **Voting Period** to something short, like 6 minutes
4. For calculating quorum (the minimum amount of vote weight required for a vote to pass), set **Quorum** to the number (**#**) 1
5. Disable **Timelock**, since the timelock period is optional anyways  

![OpenZeppelin Contract Wizard](/images/tutorials/interoperability/cross-chain-dao/cross-chain-dao-4.webp)

You should see a contract similar to this in the OpenZeppelin smart contract wizard:

```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.9;

import "@openzeppelin/contracts/governance/Governor.sol";
import "@openzeppelin/contracts/governance/extensions/GovernorSettings.sol";
import "@openzeppelin/contracts/governance/extensions/GovernorCountingSimple.sol";
import "@openzeppelin/contracts/governance/extensions/GovernorVotes.sol";

contract CrossChainDAO is Governor, GovernorSettings, GovernorCountingSimple, GovernorVotes {
    constructor(IVotes _token)
        Governor("CrossChainDAO")
        GovernorSettings(0 /* 0 block */, 30 /* 6 minutes */, 0)
        GovernorVotes(_token)
    {}

    function quorum(uint256 blockNumber) public pure override returns (uint256) {
        return 1e18;
    }

    // The following functions are overrides required by Solidity.

    function votingDelay() public view override(IGovernor, GovernorSettings) returns (uint256) {
        return super.votingDelay();
    }

    function votingPeriod() public view override(IGovernor, GovernorSettings) returns (uint256) {
        return super.votingPeriod();
    }

    function proposalThreshold() public view override(Governor, GovernorSettings) returns (uint256) {
        return super.proposalThreshold();
    }
}
```

Let's take this `CrossChainDAO` smart contract and add it to our working directory as `CrossChainDAO.sol`.  

### Adding Cross-Chain Support { #adding-cross-chain-support }

Let's tackle our next task: supporting cross-chain messaging. For this implementation, we will use the [`NonblockingLzApp` smart contract](https://github.com/LayerZero-Labs/solidity-examples/blob/main/contracts/lzApp/NonblockingLzApp.sol){target=\_blank} provided by LayerZero to make it easy to receive and send cross-chain messages. Most cross-chain protocols will have some smart contract to inherit from to receive a generic bytes payload, so you can use similar logic with a different parent smart contract.  

To get started, we'll take the following steps:

1. Import `NonblockingLzApp` and add it to the parent smart contracts of `CrossChainDAO`
2. Update the constructor as required by the `NonblockingLzApp` contract by passing in LayerZero's on-chain smart contract as an input
3. Create a function that overrides the `_nonblockingLzReceive` function of the `NonblockingLzApp` contract that will be responsible for receiving cross-chain data

```solidity
// ...other imports go here
import "@layerzerolabs/solidity-examples/contracts/lzApp/NonblockingLzApp.sol";

contract CrossChainDAO is Governor, GovernorSettings, GovernorCountingSimple, GovernorVotes, NonblockingLzApp {
    constructor(IVotes _token, address lzEndpoint)
        Governor("CrossChainDAO")
        GovernorSettings(0 /* 0 blocks */, 30 /* 6 minutes */, 0)
        GovernorVotes(_token)
        NonblockingLzApp(lzEndpoint)
    { }

    function _nonblockingLzReceive( uint16 _srcChainId, bytes memory, uint64, bytes memory _payload) internal override {
        // TODO: add cross-chain logic
    }
} 
```

We will come back to fully implement the `_nonblockingLzReceive` function when implementing the collection phase. Just understand that it is the interface by which LayerZero's cross-chain protocol interacts with when there are incoming messages.  

### Counting Votes with Cross-Chain Governor Counting Contract {: #counting-votes-with-cross-chain-governor-counting-contract }

We intend to receive cross-chain voting data via `_nonblockingLzReceive`, but that is pointless if it is not stored or counted. This logic and data will be housed in a parent contract of the `CrossChainDAO`. So let's implement this parent contract before beginning to write the `_nonblockinglzReceive` function.  

OpenZeppelin has divided many of the aspects of a DAO into multiple smart contracts, making it easier to replace sections of logic without having to change others. We don't have to go over all of the different smart contracts that came out of the OpenZeppelin smart contract wizard, but we do have to know what the [`GovernorCountingSimple` contract](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorCountingSimple.sol){target=\_blank} does.  

The `GovernorCountingSimple` contract defines how votes are counted and what votes are. It stores how many votes have been cast per proposal, what a vote can be (for, against, abstain), and it also controls whether or not quorum has been reached.  

Fortunately, when converting to a cross-chain version, a lot of the counting logic does not change. The only difference between our cross-chain variant and the single-chain variant is that the cross-chain variant must account for the collection phase and the votes that come with it. Let's add in some of that logic.

Before we write any custom code ourselves, copy and paste the [`GovernorCountingSimple` contract](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorCountingSimple.sol){target=\_blank} into a new file named `CrossChainGovernorCountingSimple.sol`. You can get the contract from its repository or within the `node_modules` folder.  

Let's start making changes:

1. Update the imported contract to use `@openzeppelin/contracts` instead of using a relative path
2. Rename the contract to `CrossChainGovernorCountingSimple`
3. Add a constructor that will take in a `uint16[]` to define the spoke chains that the `CrossChainDAO` smart contract will connect with
4. Add a struct and a corresponding map of them that will store the vote data received from other chains

```solidity
import "@openzeppelin/contracts/governance/Governor.sol"

abstract contract CrossChainGovernorCountingSimple is Governor {
    // ...
    // The lz-chain IDs that the DAO expects to receive data from during the 
    // collection phase
    uint16[] public spokeChains;

    constructor(uint16[] memory _spokeChains) {
        spokeChains = _spokeChains;
    }

    struct SpokeProposalVote {
        uint256 forVotes;
        uint256 againstVotes;
        uint256 abstainVotes;
        bool initialized;
    }

    // Maps a proposal ID to a map of a chain ID to summarized spoke voting data
    mapping(uint256 => mapping(uint16 => SpokeProposalVote)) public spokeVotes;
    // ...
}
```

!!! challenge
    In a production-ready cross-chain DAO, you would make the spoke chains modifiable by governance instead of keeping it static. Can you add an additional function that would make this possible? Which address should have access to this function?  

    *Hint: replace the array with a mapping.*

You might notice that the `SpokeProposalVote` is based off of the [`ProposalVote` struct](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/dfcc1d16c5efd0fd2a7abac56680810c861a9cd3/contracts/governance/extensions/GovernorCountingSimple.sol#L23){target=\_blank} in `GovernorCountingSimple`. The first difference is that the new struct includes a `bool` called `initialized` so that it's possible to check whether or not data was received from the spoke chain by retrieving the struct from the `spokeVotes` map. The second difference is that `SpokeProposalVote` does not include a map of users to votes because that information stays on the spoke chains and is not necessary for the calculations of whether or not a vote succeeded.

!!! challenge
    The new `SpokeProposalVote` struct is very similar to the `ProposalVote` struct. Can you think of a more optimal data structure for the smart contract that requires only one struct?

Now we have a place to store the cross-chain data, and we have a data structure to organize it with. We also want the cross-chain data to matter when calculating if a vote reached quorum and if a vote passed. By iterating through the stored cross-chain data from each of the spoke chains, the votes for each spoke chain are being added to the quorum and vote success calculations. To do so, you'll need to edit the `_quorumReached` and `_voteSucceeded` functions.

```solidity
function _quorumReached(uint256 proposalId) internal view virtual override returns (bool) {
    ProposalVote storage proposalVote = _proposalVotes[proposalId];
    uint256 abstainVotes = proposalVote.abstainVotes;
    uint256 forVotes = proposalVote.forVotes;

    for (uint16 i = 0; i < spokeChains.length; i++) {
        SpokeProposalVote storage v = spokeVotes[proposalId][spokeChains[i]];
        abstainVotes += v.abstainVotes;
        forVotes += v.forVotes;
    }

    return quorum(proposalSnapshot(proposalId)) <= forVotes + abstainVotes;
}

function _voteSucceeded(uint256 proposalId) internal view virtual override returns (bool) {
    ProposalVote storage proposalVote = _proposalVotes[proposalId];
    uint256 againstVotes = proposalVote.againstVotes;
    uint256 forVotes = proposalVote.forVotes;

    for (uint16 i = 0; i < spokeChains.length; i++) {
        SpokeProposalVote storage v = spokeVotes[proposalId][spokeChains[i]];
        againstVotes += v.againstVotes;
        forVotes += v.forVotes;
    }
    return forVotes > againstVotes;
}
```

That should be it for changes to how cross-chain votes are counted and stored. You can view the smart contract in its completed state in the [GitHub repository](https://github.com/jboetticher/cross-chain-dao/blob/main/contracts/CrossChainGovernorCountingSimple.sol){target=\_blank}.  

Now, in the child contract `CrossChainDAO`, you can import the `CrossChainGovernorCountingSimple` contract and replace `GovernorCountingSimple` with it:  

```solidity
// ...
import "@openzeppelin/contracts/governance/extensions/GovernorSettings.sol";
import "./CrossChainGovernorCountingSimple.sol";
import "@openzeppelin/contracts/governance/extensions/GovernorVotes.sol";

contract CrossChainDAO is Governor, GovernorSettings, CrossChainGovernorCountingSimple, GovernorVotes, NonblockingLzApp {

    constructor(IVotes _token, address lzEndpoint)
        Governor("CrossChainDAO")
        GovernorSettings(0 /* 0 blocks */, 30 /* 6 minutes */, 0)
        GovernorVotes(_token)
        NonblockingLzApp(lzEndpoint)
        CrossChainGovernorCountingSimple(_spokeChains)
    { }

    // ...
}
```

### Implementing a Collection Phase {: #implementing-a-collection-phase }

If you recall from the initial conception, a new collection phase should be added in between the voting period and the proposal's execution. During this phase:  

1. Execution must be postponed
2. The hub chain must request voting data from the spoke chains
3. The spoke chain must subsequently send the voting data

#### Defining the Collection Phase and Preventing Execution {: #defining-the-collection-phase-and-preventing-execution }

Let's tackle the first issue: ensuring that execution must be disabled during the collection phase. This will effectively define the collection phase from within the `CrossChainDAO` contract.

We'll need to:

1. Add two new mappings, `collectionStarted` and `collectionFinished`, which have been defined to track the collection status that we'll use in multiple functions throughout this section
2. Add a function that overrides the `_beforeExecute` function of the OpenZeppelin `Governor` contract that checks whether or not the each of the spoke chains have sent in voting data before a proposal is executed (which is found by checking `initialized`)
3. Add a function that marks a collection phase as `true` if all of the satellite chains have sent a cross-chain message back

```solidity
mapping(uint256 => bool) public collectionStarted;
mapping(uint256 => bool) public collectionFinished;

function _beforeExecute(
    uint256 proposalId,
    address[] memory targets,
    uint256[] memory values,
    bytes[] memory calldatas,
    bytes32 descriptionHash
) internal override {
    finishCollectionPhase(proposalId);

    require(
        collectionFinished[proposalId],
        "Collection phase for this proposal is unfinished!"
    );

    super._beforeExecute(proposalId, targets, values, calldatas, descriptionHash);
}

function finishCollectionPhase(uint256 proposalId) public {
    bool phaseFinished = true;
    for (uint16 i = 0; i < spokeChains.length && phaseFinished; i++) {
        phaseFinished =
            phaseFinished &&
            spokeVotes[proposalId][spokeChains[i]].initialized;
    }

    collectionFinished[proposalId] = phaseFinished;
}
```

If you wanted, you could also add the collection phase within the [IGovernor state machine](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/4f4b6ab40315e2fbfc06e65d78f06c5b26d4646c/contracts/governance/IGovernor.sol#L15){target=\_blank}. This would require more effort than it would be worth and is more feasible for a cross-chain DAO written from scratch, so we will not be doing it in this tutorial.  

#### Requesting Votes from Spoke Chains {: #requesting-votes-from-spoke-chains }

Moving on, let's figure out how to request voting data from spoke chains. We can start by making a new public trustless function to begin the collection phase, similar to the `execute` function:  

```solidity
// Requests the voting data from all of the spoke chains
function requestCollections(uint256 proposalId) public payable {
    require(
        block.number > proposalDeadline(proposalId),
        "Cannot request for vote collection until after the vote period is over!"
    );
    require(
        !collectionStarted[proposalId],
        "Collection phase for this proposal has already started!"
    );

    collectionStarted[proposalId] = true;

    // Sends an empty message to each of the aggregators. If they receive a 
    // message at all, it is their cue to send data back
    uint256 crossChainFee = msg.value / spokeChains.length;
    for (uint16 i = 0; i < spokeChains.length; i++) {
        // Using "1" as the function selector
        bytes memory payload = abi.encode(1, abi.encode(proposalId));
        _lzSend({
            _dstChainId: spokeChains[i],
            _payload: payload,
            _refundAddress: payable(address(this)),
            _zroPaymentAddress: address(0x0),
            _adapterParams: bytes(""),
            _nativeFee: crossChainFee
        });
    }
}
```

This function allows any user to start the collection process for a specific `proposalId` as long as:  

1. The voting phase for the proposal has finished
2. The collection phase has not yet started

Recall that each spoke chain will have a `DAOSatellite` smart contract associated with it that can also receive and send cross-chain messages. This function sends a cross-chain message to every registered spoke chain's `DAOSatellite` during the collection phase. The message contains a function selector, `1`, and a proposal ID. The function selector is used to request voting data for the given proposal instead of some other action (we will revisit [this concept very soon](#receiving-votes-from-spoke-chains)) from the destination `DAOSatellite` contract.

!!! note
    By using LayerZero, multiple messages must be sent in a single transaction so that every spoke chain can receive data. LayerZero, along with other cross-chain protocols, is **unicast** instead of **multicast**. As in, a cross-chain message can only arrive to a single destination. When designing a hub-and-spoke architecture, research if your [protocol supports multicast messaging](https://wormhole.com/docs/protocol/infrastructure/core-contracts/#multicast){target=\_blank}, as it may be more succinct.

This should be it for requesting data, since most of the logic afterwards will be hosted within the [DAO Satellite](#dao-satellite-contract). Just understand that when sending the proposal to the

#### Receiving Votes from Spoke Chains {: #receiving-votes-from-spoke-chains }

Recall that connected contracts that use LayerZero implement the `_nonblockingLzReceive` function to receive cross-chain messages. For incoming messages, we must be able to receive the voting data from other chains during the collection phase. Like good software developers, we want to maintain extensibility; we might also want to receive messages from other chains that do other actions, like execute or propose. But we only get one payload in one receiving function! How do we resolve this issue?  

!!! note
    For sake of simplicity, we won't implement cross-chain execution or proposals in this tutorial. The function selector concept is being introduced because it is an important topic in cross-chain DApps.  

Let's think about the EVM. How does a smart contract know that a transaction wants to call a specific function? Each function has a function selector, a hashed value that is mapped to a specific action. We can do the same thing, but with cross-chain messages and with integers instead of hashes.  

We'll update the `_nonblockingLzReceive` function as follows:

1. Define the function selector as a `uint16` variable stored at the start of the bytes payload. From here on out, we will ensure in our design that **every cross-chain message sent will have this `uint16` function selector at the start of its payload**.
2. Use assembly to load data at `payload's address + 32 bytes` into the `option` variable. Understanding why this is necessary requires a bit of understanding of how `abi.encode` works. The first 32 bytes of an ABI encoded payload are dedicated to information on the entire payload's size. After these first 32 bytes, the rest of the information is stored, which in this case is the function selector
3. Based on the input of the `option` variable, perform some type of cross-chain action. For this example, the number `0` maps to the option to receive the voting data from the other chains. You could add additional functionality to the next number, `1`, such as proposing or executing
4. If the `option` is `0`, we'll need to add functionality to receive the voting data. So, we'll call a function that will receive the voting data and pass in the `_srcChainId` and the newly unwrapped `payload` to this function. We'll create this function in the following steps

Add the following code to the `_nonblockingLzReceive` function:  

```solidity
// Gets a function selector option
uint16 option;
assembly {
    option := mload(add(payload, 32))
}

// Some options for cross-chain actions are: propose, vote, vote with reason,
// vote with reason and params, cancel, etc.
if (option == 0) {
    onReceiveSpokeVotingData(_srcChainId, payload);
} else if (option == 1) {
    // TODO: Feel free to put your own cross-chain actions (propose, execute, etc.)
} else {
    // TODO: You could revert here if you wanted to
}
```

When cross-chain messages are received (from any cross-chain protocol), they come with an arbitrary bytes payload. Typically, this bytes payload is created from an invocation of `abi.encode`, where multiple types of data are inserted. For the smart contract that receives this data, the data must be decoded with `abi.decode`, where information is decoded in a manner that is expected. For example, if the receiving smart contract's logic requires a `uint16` and an `address` to function properly, it will decode by including `abi.decode(payload, (uint16, address))`.  

When we have multiple functionalities packed into a message with a single payload, that payload might come in multiple formats, since different functions will require different bytes. Hence, we must examine the function selector before decoding the entire message.  

!!! note
    The `abi.encode` function is used the most because it has the most support for dynamic types, but you could feasibly use `abi.encodePacked` if your use case permits. Assembly-level logic would have to change if you chose to make this change.

We haven't written the `onReceiveSpokeVotingData` function yet. To do so, we'll take the following steps:

1. Create the `onReceiveSpokeVotingData` function that accepts a `_srcChainId` and `payload`
2. Store the external voting data for future use. We have already defined what type of information we want from spoke chains in [`CrossChainGovernorCountingSimple`](#counting-votes-with-cross-chain-governor-counting-contract){target=\_blank} via the `SpokeProposalVote` struct. We want three vote values: `forVotes`, `againstVotes`, and `abstainVotes`. Plus, we want to know for which proposal the data received is for, so we also want a proposal ID

```solidity
function onReceiveSpokeVotingData(uint16 _srcChainId, bytes memory payload) internal virtual {
    (
        , // uint16 option
        uint256 _proposalId,
        uint256 _for,
        uint256 _against,
        uint256 _abstain
    ) = abi.decode(payload, (uint16, uint256, uint256, uint256, uint256));
}
```

We can now store the data within the `spokeVotes` map defined in `CrossChainGovernorCountingSimple`, so long as that data hasn't already been stored:  

```solidity
    // As long as the received data isn't already initialized...
    if (spokeVotes[_proposalId][_srcChainId].initialized) {
        revert("Already initialized!");
    } else {
        // Add it to the map (while setting initialized true)
        spokeVotes[_proposalId][_srcChainId] = SpokeProposalVote(
            _for,
            _against,
            _abstain,
            true
        );
    }
```

At this point, the collection phase has been finished! The collection phase stops the execution before all votes are counted, and a message is sent requesting voting data from spoke chains.

### Making Proposals Cross-Chain { #making-proposals-cross-chain }

OpenZeppelin's `Governor` smart contract came with a `propose` function, but unfortunately it doesn't work for our purposes. When a user sends a proposal, the smart contract needs to send cross-chain messages to let the spoke chains know that there is a new proposal to vote on. But the destination chains also need gas to complete the messages' journey. Most cross-chain protocols currently require extra gas paid in the origin chain's native currency for the destination chain's transaction, and that can only be sent via a payable function. The `propose` function is not payable, hence why we must write our own cross-chain version.  

!!! note
    Technically, the cross-chain messages should be sent when the voting delay is over to sync with when the voting weight snapshot is taken. In this instance, the proposal and snapshot are made at the same time.

We'll rename the original `propose` function included in the `Governor` smart contract to be `crossChainPropose`. Then we'll modify it to send cross-chain messages with information on the proposal to every spoke chain, the IDs of which you may remember being stored in the [`CrossChainGovernorCountingSimple` contract](#counting-votes-with-cross-chain-governor-counting-contract){target=\_blank}:

```solidity
function crossChainPropose(address[] memory targets, uint256[] memory values, bytes[] memory calldatas, string memory description) 
    public payable virtual returns (uint256) {
    uint256 proposalId = super.propose(targets, values, calldatas, description);

    // Sends the proposal to all of the other chains
    if (spokeChains.length > 0) {
        uint256 crossChainFee = msg.value / spokeChains.length;

        // Iterate over every spoke chain
        for (uint16 i = 0; i < spokeChains.length; i++) {
            bytes memory payload = abi.encode(
                0, // Function selector "0" for destination contract
                abi.encode(proposalId, block.timestamp) // Encoding the proposal start
            );

            // Send a cross-chain message with LayerZero to the chain in the iterator
            _lzSend({
                _dstChainId: spokeChains[i],
                _payload: payload,
                _refundAddress: payable(address(this)),
                _zroPaymentAddress: address(0x0),
                _adapterParams: bytes(""),
                _nativeFee: crossChainFee
            });
        }
    }

    return proposalId;
}
```

Remember when we designed the `CrossChainDAO` smart contract's `_nonblockingLzReceive` function to expect a function selector? This is the same idea, except now we're expecting the satellite smart contract to also implement these features. So in this case, we've defined `0` as receiving a new proposal. We did the same thing when [requesting voting information](#requesting-votes-from-spoke-chains){target=\_blank} from spoke chains.  

At this point, the `CrossChainDAO.sol` smart contract is finished! If you want to view the completed smart contract, it is available in its [GitHub repository](https://github.com/jboetticher/cross-chain-dao/blob/main/contracts/CrossChainDAO.sol){target=\_blank}.

## Writing the DAO Satellite Contract {: #dao-satellite-contract }

So far, we've only talked about the cross-chain DAO and its accompanying token. The cross-chain DAO is never deployed on the spoke chains because it wouldn't be efficient to replicate *all* of the data across each spoke chain. But, we still need an interface to work with the `CrossChainDAO` smart contract on the spoke chains. Hence, we will create a satellite contract named `DAOSatellite`.

We'll take the following steps to create the new `DAOSatellite` contract:

1. Add dependencies and inherit the `NonblockingLzApp` contract
2. Add a constructor that defines what the hub chain is (every chain has its own ID in LayerZero and every other cross-chain protocol), the LayerZero endpoint, the cross-chain token that defines voting weight, and the average seconds per block on this weight (more on that later)
3. Add some structs, and storage variables to use later. They're mainly stripped-down versions of what are found in the `CrossChainDAO` and its parent contracts
4. Add a function to check if a given proposal ID is valid and open to voting

```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@layerzerolabs/solidity-examples/contracts/lzApp/NonblockingLzApp.sol";
import "@openzeppelin/contracts/utils/Timers.sol";
import "@openzeppelin/contracts/utils/Checkpoints.sol";
import "@openzeppelin/contracts/governance/utils/IVotes.sol";

contract DAOSatellite is NonblockingLzApp { 
    struct ProposalVote {
        uint256 againstVotes;
        uint256 forVotes;
        uint256 abstainVotes;
        mapping(address => bool) hasVoted;
    }

    enum VoteType {
        Against,
        For,
        Abstain
    }

    struct RemoteProposal {
        // Blocks provided by the hub chain as to when the local votes should start/finish.
        uint256 localVoteStart;
        bool voteFinished;
    }

    constructor(uint16 _hubChain, address _endpoint, IVotes _token, uint _targetSecondsPerBlock) 
        NonblockingLzApp(_endpoint) payable {
        hubChain = _hubChain;
        token = _token;
        targetSecondsPerBlock = _targetSecondsPerBlock;
    }

    uint16 public immutable hubChain;
    IVotes public immutable token;
    uint256 public immutable targetSecondsPerBlock;
    mapping(uint256 => RemoteProposal) public proposals;
    mapping(uint256 => ProposalVote) public proposalVotes;

    function isProposal(uint256 proposalId) view public returns(bool) {
        return proposals[proposalId].localVoteStart != 0;
    }
}
```

Since this smart contract inherits from `NonblockingLzApp`, it requires `_nonblockingLzReceive` to receive cross-chain messages. This smart contract communicates with the `CrossChainDAO` smart contract, and recall that there are currently two instances in which the `CrossChainDAO` sends a message:  

- When the `CrossChainDAO` wants to notify the spoke chains of a new proposal (function selector is `0`)  
- When the `CrossChainDAO` wants the spoke chains to send their voting data to the hub chain (function selector is `1`)  

Keeping that in mind, let's start with writing the receiving function `_nonblockingLzReceive` with a function selector just like the `CrossChainDAO`:  

```solidity
function _nonblockingLzReceive(uint16 _srcChainId, bytes memory, uint64, bytes memory _payload) internal override {
    require(_srcChainId == hubChain, "Only messages from the hub chain can be received!");

    uint16 option;
    assembly {
        option := mload(add(_payload, 32))
    }

    if (option == 0) {
        // Begin a proposal on the local chain, with local block times
     }
    else if (option == 1) {
        // Send vote results back to the hub chain
     }
}
```

Let's tackle the first action, `if (option == 0)`, beginning a proposal on the local chain:

1. Decode the payload, which includes a proposal ID and the timestamp of when the proposal was made as mentioned in the [CrossChainDAO section](#making-proposals-cross-chain)
2. Perform some funky calculations to generate a `cutOffBlockEstimation` by subtracting blocks from the current block based on the timestamp and a predetermined seconds-per-block estimate
3. Add a `RemoteProposal` struct to the proposals map, effectively registering the proposal and its voting-related data on the spoke chain

```solidity
(, uint256 proposalId, uint256 proposalStart) = abi.decode(_payload, (uint16, uint256, uint256));
require(!isProposal(proposalId), "Proposal ID must be unique.");

uint256 cutOffBlockEstimation = 0;
if(proposalStart < block.timestamp) {
    uint256 blockAdjustment = (block.timestamp - proposalStart) / targetSecondsPerBlock;
    if(blockAdjustment < block.number) {
        cutOffBlockEstimation = block.number - blockAdjustment;
    }
    else {
        cutOffBlockEstimation = block.number;
    }
}
else {
    cutOffBlockEstimation = block.number;
}

proposals[proposalId] = RemoteProposal(cutOffBlockEstimation, false);
```

The calculations in the above snippet are not enough to ensure a correct setup. While it may not matter as much when people can start voting, it does matter when the vote weight snapshot is made. If the vote weight snapshot is made too far apart between the spoke and hub chains, a user could send a token from one chain to another and effectively double their voting weight. Some [example mitigation strategies](#double-weight-attack-from-snapshot-mismatch) are listed below, but they are too complex to investigate in detail for this tutorial. In the meantime, the only strategy is to subtract blocks from the current block based on the timestamp and a predetermined seconds-per-block estimate.  

Now let's add logic to send vote results back to the hub chain:

1. Retrieve the proposal ID from the cross-chain message
2. Get the data for said proposal from the relevant map
3. Encode that data into a payload as defined by the `CrossChainDAO`
4. Send that data through LayerZero

```solidity
uint256 proposalId = abi.decode(_payload, (uint256));
ProposalVote storage votes = proposalVotes[proposalId];
bytes memory votingPayload = abi.encode(
    0, 
    abi.encode(proposalId, votes.forVotes, votes.againstVotes, votes.abstainVotes)
);
_lzSend({
    _dstChainId: hubChain,
    _payload: votingPayload,
    _refundAddress: payable(address(this)),
    _zroPaymentAddress: address(0x0),
    _adapterParams: bytes(""),
    // NOTE: DAOSatellite needs to be funded beforehand, in the constructor.
    //       There are better solutions, such as cross-chain swaps being built in from the hub chain, but
    //       this is the easiest solution for demonstration purposes.
    _nativeFee: 0.1 ether 
});
proposals[proposalId].voteFinished = true;
```

The only issue here is that the gas payment for the cross-chain message's transaction on the hub chain must be included, and there is no simple way to receive it. There are [options that could potentially avert this issue, as explained below](#chained-cross-chain-message-fees), but for simplicity's sake, the satellite contract will have to be sent native currency every once in a while.  

Finally, the last thing to add is a vote mechanism that allows users to vote. This mechanism is nearly exactly the same as the mechanism in the [`GovernorCountingSimple` smart contract](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorCountingSimple.sol){target=\_blank}, so much of the code can be copied over:  

```solidity
function castVote(uint256 proposalId, uint8 support) public virtual returns (uint256 balance)
{
    RemoteProposal storage proposal = proposals[proposalId];
    require(
        !proposal.voteFinished,
        "DAOSatellite: vote not currently active"
    );
    require(
        isProposal(proposalId), 
        "DAOSatellite: not a started vote"
    );

    uint256 weight = token.getPastVotes(msg.sender, proposal.localVoteStart);
    _countVote(proposalId, msg.sender, support, weight);

    return weight;
}

function _countVote(uint256 proposalId, address account, uint8 support, uint256 weight) internal virtual 
{
    ProposalVote storage proposalVote = proposalVotes[proposalId];

    require(!proposalVote.hasVoted[account], "DAOSatellite: vote already cast");
    proposalVote.hasVoted[account] = true;

    if (support == uint8(VoteType.Against)) {
        proposalVote.againstVotes += weight;
    } else if (support == uint8(VoteType.For)) {
        proposalVote.forVotes += weight;
    } else if (support == uint8(VoteType.Abstain)) {
        proposalVote.abstainVotes += weight;
    } else {
        revert("DAOSatellite: invalid value for enum VoteType");
    }
}
```

Note that the `castVote` function requires that:  

- The proposal isn't finished
- The proposal exists, as in, there is data that's stored within the `proposals` map.

In fact, the `_countVote` function is [directly copied](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/4fb6833e325658946c2185862b8e57e32f3683bc/contracts/governance/extensions/GovernorCountingSimple.sol#L78){target=\_blank} from the hub chain! Much of the logic of single-chain dApps can be reused in cross-chain dApps with minor tweaks.  

That's it for breaking down the satellite contract. It was more or less simple because most of the logic is just a reflection of what happens on the hub chain. You can view the completed smart contract in its [GitHub repository](https://github.com/jboetticher/cross-chain-dao/blob/main/contracts/DAOSatellite.sol){target=\_blank}.  

At this point, every single smart contract has been finished, and a deployment scheme like the one below can be made. If you are interested in seeing this in action, the [GitHub repository](https://github.com/jboetticher/cross-chain-dao){target=\_blank} that hosts the cross-chain DAO allows you to deploy on TestNets.  

![Smart contracts overview](/images/tutorials/interoperability/cross-chain-dao/cross-chain-dao-3.webp)  

As a reminder, **this tutorial's smart contracts are not tested or recommended for production use**.

## Caveats and Other Designs {: #caveats-and-other-designs }

Every single part of the smart contract system has been written, and if you got through it all, good job! It's a lot to soak in, and there are still parts that need to be developed for it to be production-ready.

The design of this cross-chain DAO was created off of OpenZeppelin's Governor base, but that doesn't mean that it's flawless. It's good to work off of preexisting smart contracts for a version 1 cross-chain DApp, but as you get closer to production-ready code, it's best to start from scratch and leave only the parts that are still relevant to the design. Working off of logic that's meant for single-chain can get in the way several times, which you will find a common occurrence when working with cross-chain smart contracts.  

For example, the `propose` function from the `Governor` smart contract couldn't be used and had to be replaced with a new cross-chain function. It would be best to completely remove the `propose` function, but that can't be done because of the way the `Governor` smart contract was designed. This is an obvious issue, and it goes to show that while it's good to prototype cross-chain DApps using preexisting smart contracts, it can be better to completely rewrite them while still reusing some logic.  

!!! challenge
    Can you rewrite the `CrossChainDAO` smart contract to only include the logic and functions necessary for cross-chain interactions? While you're at it, can you implement any of the alternate designs suggested below?

### Division of the Cross-Chain Selector Into Multiple Contracts {: #division-of-the-cross-chain-selector-into-multiple-contracts }

The cross-chain function selection method that was used in the `CrossChainDAO` and `DAOSatellite` smart contracts works fine enough. But instead of having a selector within a single smart contract, you could have cross-chain messages directed at multiple smart contracts that have special permissions within the `CrossChainDAO`. You may find this helpful in case you believe in single responsibility (SRP) for smart contracts.  

For example, the hub chain's `CrossChainDAO` could be composed of the main contract that receives cross-chain data as well as two other smart contracts: `CrossChainExecutor` and `CrossChainProposer`. So, when interacting with the `DAOSatellite` contract to send a message to `CrossChainDAO`, the spoke chain's smart contract could target `CrossChainExecutor` to execute or `CrossChainProposer` to propose. This would remove the need to double-wrap payloads and the need to include function-selecting logic in the cross-chain message receiving function. It could even help convert a single-chain DAO into one with cross-chain abilities.  

![Single Responsibility Principle](/images/tutorials/interoperability/cross-chain-dao/cross-chain-dao-5.webp)  

### Distributed Proposal and Execution {: #distributed-proposal-and-execution }

What if you wanted users to be able to execute a proposal on multiple chains instead of just the hub chain? There are a few ways to go about it:  

- Stick with a hub-and-spoke model
- Completely decentralize  

The hub-and-spoke model is already laid out in detail in this tutorial. In such a case where an execution could occur on multiple chains, you would have to have a smart contract on each chain that executes on behalf of the hub chain (which could be added to `DAOSatellite`). This smart contract would receive a message from the `execute` function provided by the `Governor` smart contract. This is simple enough, but it might be too many cross-chain messages to be efficient.  

If you decide to completely decentralize the DAO, it would be most likely to remove the `DAOSatellite` smart contract and deploy a modified `CrossChainDAO` smart contract on every chain. Each `CrossChainDAO` could control the proposals meant to be executed on its chain. It would require a redesign of how proposals are made and sent, however.  

You may also find an issue when generating the proposal ID. Take a look at how the IDs are being generated now:  

```solidity
function hashProposal(
    address[] memory targets,
    uint256[] memory values,
    bytes[] memory calldatas,
    bytes32 descriptionHash
) public pure virtual override returns (uint256) {
    return uint256(keccak256(abi.encode(targets, values, calldatas, descriptionHash)));
}
```

Conceivably, the same description and transaction details could be sent on both chain A and on chain B. This could cause errors because then there would be conflicting transactions. It may serve best to include another parameter to hash a proposal ID: the chain ID of the chain on which the proposal is meant to execute.

### Double-Weight Attack from Snapshot Mismatch {: #double-weight-attack-from-snapshot-mismatch }

One primary issue with the distribution of voting weight across chains via the `CrossChainDAOToken` is that blocks are not properly aligned across networks. This can cause a situation where the vote snapshots between multiple chains are not close together enough, resulting in a situation where voting weight is doubled when a cross-chain transfer of the DAO token front-runs a new proposal's voting weight snapshot.

One option is using an oracle that aligns blocks with timestamps to ensure that snapshots on spoke chains are as close to the hub chain's timestamp as possible.

A more simple solution would be to alter the `ERC20Votes` smart contract to depend on timestamps instead of blocks, but this could still be open to attacks in case the block producers on two chains collude.  

Alternatively, you could alter the `OFTVotes` smart contract to postpone the addition of voting weight until a few blocks after the weight is received.

### Chained Cross-Chain Message Fees {: chained-cross-chain-message-fees }

One of the flaws overlooked with the spoke chain's `DAOSatellite` smart contract is that whenever voting data is requested from the hub chain, the destination chain fees must be stored in the smart contract beforehand. Here are two plausible solutions to this:  

- Storing the request for data, and allowing anyone to trustlessly send the data back
- Sending the gas from the hub chain with the cross-chain message that requests the data

The first is the simplest solution, though it may increase the turn-around time from proposal to execution if you don't plan on running additional infrastructure. Similar to how the `execute` function can be run by anyone once a proposal has been finished, a new function would be written to allow anyone to send the vote data to the hub chain. Preferably, this would also require a [timeout for the collection phase](#collection-phase-time-out).  

![Chained Execution](/images/tutorials/interoperability/cross-chain-dao/cross-chain-dao-6.webp)  

The second is significantly more complex. It would require a setup that sends tokens with a payload instead of just a payload like the current contract does, and for a swap to occur on the destination chain to retrieve native currency for a cross-chain transaction.  

### Collection Phase Time Out {: collection-phase-time-out }

In case you want to be safe and you believe that a spoke chain might stall or even stop being supported, you would want to include a way to cap the amount of time that the collection phase takes and also add a way for your DAO's governance to add and remove spoke chains.  

For example, the hub chain would wait 30 blocks before disregarding voting data from spoke chains. And if the DAO's participants believe that chain A should be removed from future voting, they could start a proposal to do so, similar to OpenZeppelin's `GovernorSettings` contract.  

<div class="page-disclaimer">
    This tutorial is for educational purposes only. As such, any contracts or code created in this tutorial should not be used in production.
</div>

<div class="page-disclaimer">
  The information presented herein has been provided by third parties and is made available solely for general information purposes. Moonbeam does not endorse any project listed and described on the Moonbeam Doc Website (https://docs.moonbeam.network/). Moonbeam Foundation does not warrant the accuracy, completeness or usefulness of this information. Any reliance you place on such information is strictly at your own risk. Moonbeam Foundation disclaims all liability and responsibility arising from any reliance placed on this information by you or by anyone who may be informed of any of its contents. All statements and/or opinions expressed in these materials are solely the responsibility of the person or entity providing those materials and do not necessarily represent the opinion of Moonbeam Foundation. The information should not be construed as professional or financial advice of any kind. Advice from a suitably qualified professional should always be sought in relation to any particular matter or circumstance. The information herein may link to or integrate with other websites operated or content provided by third parties, and such other websites may link to this website. Moonbeam Foundation has no control over any such other websites or their content and will have no liability arising out of or related to such websites or their content. The existence of any such link does not constitute an endorsement of such websites, the content of the websites, or the operators of the websites. These links are being provided to you only as a convenience and you release and hold Moonbeam Foundation harmless from any and all liability arising from your use of this information or the information provided by any third-party website or service.
</div>
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/tutorials/interoperability/remote-batched-evm-calls/
--- BEGIN CONTENT ---
---
title: Remote Batch EVM Calls via XCM
description: In this guide, we'll use remote EVM execution via XCM coupled with the Batch Precompile to execute multiple contract calls in Moonbeam's EVM remotely via XCM.
template: main.html
categories: Tutorials, Ethereum Toolkit
---

# Remote Batch EVM Calls via XCM

_by Kevin Neilson_

## Introduction {: #introduction }

In this tutorial, we’ll be making a series of remote batch EVM calls from a relay chain (what Polkadot is to Moonbeam) using Polkadot's general message passing protocol called [XCM](/builders/interoperability/xcm/overview/){target=\_blank}. To do so, we'll be using a particular combination of XCM instructions that allow you to [call Moonbeam's EVM through an XCM message](/builders/interoperability/xcm/remote-execution/remote-evm-calls/){target=\_blank}. The unique twist to this tutorial is that rather than making a single remote EVM contract call, we'll be using Moonbeam's [Batch Precompile](/builders/ethereum/precompiles/ux/batch/){target=\_blank} to combine multiple EVM calls into a single transaction.

To get the most out of this tutorial, you may wish to first familiarize yourself with [Remote EVM Calls Through XCM](/builders/interoperability/xcm/remote-execution/remote-evm-calls/){target=\_blank} as well as Moonbeam's [Batch Precompile](/builders/ethereum/precompiles/ux/batch/){target=\_blank}.

**The content of this tutorial is for educational purposes only!**

For this example, you'll be working on top of Moonbase Alpha (Moonbeam TestNet), which has its own relay chain called [Moonbase relay](https://polkadot.js.org/apps/?rpc=wss://relay.api.moonbase.moonbeam.network#/accounts){target=\_blank} (akin to the Polkadot relay chain). The relay chain token is called UNIT, while Moonbase Alpha's is called DEV. Importantly, you **must understand that sending incorrect XCM messages can result in the loss of funds.** Consequently, it is essential to test XCM features on a TestNet before moving to a production environment.

The goal of this tutorial is to show you how the [Batch Precompile](/builders/ethereum/precompiles/ux/batch/){target=\_blank} can work in conjunction with [Polkadot's XCM](/builders/interoperability/xcm/overview/){target=\_blank} to allow you to trigger batch remote EVM calls on Moonbeam. To avoid adding complexity to this tutorial, the actual batch EVM calls we'll be making will be quite simple. We'll be initiating multiple mints of [planet ERC-20 test tokens on Moonbase Alpha](https://moonbase-minterc20.netlify.app){target=\_blank}. Although we've chosen simple contract calls for demonstration purposes, there are lots more real-life defi examples that you may wish to emulate, such as token approvals and swaps, claiming rewards from multiple pools, or swapping and depositing into LP pools.

Throughout this tutorial, we will refer to the account executing the batch EVM calls via XCM as Alice. Let's preview the flow of this tutorial:

1. Alice has an account on the relay chain, and she wants to mint Mars (MARS) and Neptune (NEPT) tokens (ERC-20s on Moonbase Alpha) using [Moonbase Minter](https://moonbase-minterc20.netlify.app){target=\_blank}. Alice needs to send an XCM message to Moonbase Alpha from her relay chain account
2. The XCM message will be received by Moonbase Alpha and its instructions executed. The instructions state Alice's intention to buy some block execution time in Moonbase Alpha and execute a call to Moonbase's Batch Precompile, composed of two distinct mint calls. The batch EVM call is dispatched through a special account Alice controls on Moonbase Alpha via XCM messages. This account is known as the [Computed Origin account](/builders/interoperability/xcm/remote-execution/computed-origins/){target=\_blank}. Even though this is a keyless account (private key is unknown), the public address can be [calculated in a deterministic way](/builders/interoperability/xcm/remote-execution/computed-origins/#calculate-computed-origin){target=\_blank}
3. The successful XCM execution will result in the mint commands being executed by the EVM, and Alice will receive her MARS and NEPT tokens in her special account
4. The execution of the remote EVM call through XCM will result in some EVM logs that are picked up by explorers. There is an EVM transaction and receipt that anyone can query to verify

The "happy path" of a remote batch EVM call dispatched via XCM is as follows:
![Remote batch EVM call via XCM diagram](/images/tutorials/interoperability/remote-batched-evm-calls/remote-batched-evm-calls-1.webp)

## Checking Prerequisites {: #checking-prerequisites }

Considering all the steps summarized in the [introduction](#introduction), the following prerequisites need to be accounted for:

- You need to have UNITs on the relay chain to pay for transaction fees when sending the XCM. If you have a Moonbase Alpha account funded with DEV tokens, you can swap some DEV for xcUNIT here on [Moonbeam Swap](https://moonbeam-swap.netlify.app/#/swap){target=\_blank}. Then withdraw the xcUNIT from Moonbase Alpha to [your account on the Moonbase relay chain](https://polkadot.js.org/apps/?rpc=wss://relay.api.moonbase.moonbeam.network#/accounts){target=\_blank} using [apps.moonbeam.network](https://apps.moonbeam.network/moonbase-alpha){target=\_blank}.
  You can get DEV tokens for testing on Moonbase Alpha once every 24 hours from the [Moonbase Alpha Faucet](https://faucet.moonbeam.network){target=\_blank}
- Your [Computed Origin account](/builders/interoperability/xcm/remote-execution/computed-origins/){target=\_blank} must hold DEV tokens to fund the call to the Batch Precompile, and also pay for the XCM execution (although this could be paid in UNIT tokens as xcUNIT). We will calculate the Computed Origin account address in the next section

## Calculating your Computed Origin Account {: #calculating-your-computed-origin-account }

Copy the account of your existing or newly created account on the [Moonbase relay chain](https://polkadot.js.org/apps/?rpc=wss://relay.api.moonbase.moonbeam.network#/accounts){target=\_blank}. You're going to need it to calculate the corresponding Computed Origin account, which is a special type of account that’s keyless (the private key is unknown). Transactions from a Computed Origin account can be initiated only via valid XCM instructions from the corresponding account on the relay chain. In other words, you are the only one who can initiate transactions on your Computed Origin account, and if you lose access to your Moonbase relay account, you’ll also lose access to your Computed Origin account.

To generate the Computed Origin account, first clone the [xcm-tools](https://github.com/Moonsong-Labs/xcm-tools){target=\_blank} repo. Run `yarn` to install the necessary packages, and then run:

```sh
yarn calculate-multilocation-derivative-account \
--ws-provider wss://wss.api.moonbase.moonbeam.network \
--address INSERT_MOONBASE_RELAY_ACCOUNT \
--para-id INSERT_ORIGIN_PARACHAIN_ID_IF_APPLIES \
--parents INSERT_PARENTS_VALUE_IF_APPLIES
```

Let's review the parameters passed along with this command:

- The `--ws-provider` or `-w` flag corresponds to the endpoint we’re using to fetch this information
- The `--address` or `-a` flag corresponds to your Moonbase relay chain address
- The `--para-id` or `-p` flag corresponds to the parachain ID of the origin chain (if applicable). If you are sending the XCM from the relay chain, you don't need to provide this parameter
- The `-parents` flag corresponds to the parents value of the origin chain in relation to the destination chain. If you're deriving a multi-location derivative account on a parachain destination from a relay chain origin, this value would be `1`. If left out, the parents value defaults to `0`

For our case, we will send the remote EVM call via XCM from Alice's account, which is `5Fe4nNwxJ9ai9hVkUubiy4e6BVs1tzJGDLXAdhUKuePq9CLp`. A parachain ID is omitted from the command since we are sending the XCM instruction from the relay chain. A parents value of `1` indicates that the relay chain is a parent of the destination parachain. The command and response should resemble the following image:

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>yarn calculate-multilocation-derivative-account \</span>
    <span data-ty>--ws-provider wss://wss.api.moonbase.moonbeam.network \</span>
    <span data-ty>--address 5Fe4nNwxJ9ai9hVkUubiy4e6BVs1tzJGDLXAdhUKuePq9CLp \</span>
    <span data-ty>--parents 1</span>
    <br>
    <span data-ty>yarn run v1.22.10</span>
    <span data-ty>warning ../../../package.json: No license field</span>
    <span data-ty>$ ts-node 'scripts/calculate-multilocation-derivative-account.ts' --ws-provider wss://wss.api.moonbase.moonbeam.network --address 5Fe4nNwxJ9ai9hVkUubiy4e6BVs1tzJGDLXAdhUKuePq9CLp --parents 1</span>
    <br>
    <span data-ty>Remote Origin calculated as ParentChain</span>
    <span data-ty>Parents 1</span>
    <span data-ty>AccountId32: 5Fe4nNwxJ9ai9hVkUubiy4e6BVs1tzJGDLXAdhUKuePq9CLp</span>
    <span data-ty>32 byte address is 0xf0615483cbe76f5b2aa80a8ce2b2e9a8206deb65b8a1323270e25802f600f95c</span>
    <span data-ty>20 byte address is 0xf0615483cbe76f5b2aa80a8ce2b2e9a8206deb65</span>
    <span data-ty>✨  Done in 1.02s.</span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>

The values are all summarized in the following table:

|                    Name                     |                                                                           Value                                                                           |
|:-------------------------------------------:|:---------------------------------------------------------------------------------------------------------------------------------------------------------:|
|        Origin Chain Encoded Address         |                                                    `5Fe4nNwxJ9ai9hVkUubiy4e6BVs1tzJGDLXAdhUKuePq9CLp`                                                     |
|        Origin Chain Decoded Address         |                                           `0x9e263df66ff98212347e9a6b51d56f7a982bc25bb1300cd20e5a68d726789043`                                            |
| Computed Origin Account (32 bytes) |                                           `0xf0615483cbe76f5b2aa80a8ce2b2e9a8206deb65b8a1323270e25802f600f95c`                                            |
| Computed Origin Account (20 bytes) |                                                       `0xf0615483cbe76f5b2aa80a8ce2b2e9a8206deb65`                                                        |

The script will return 32-byte and 20-byte addresses. We’re interested in the Ethereum-style account, the 20-byte one, which is `0xf0615483cbe76f5b2aa80a8ce2b2e9a8206deb65`. Feel free to look up your Computed Origin account on [Moonscan](https://moonbase.moonscan.io){target=\_blank}. Next, you can fund this account with DEV tokens.

You can get DEV tokens for testing on Moonbase Alpha once every 24 hours from the [Moonbase Alpha Faucet](https://faucet.moonbeam.network){target=\_blank}.

## Preparing the Mint EVM Calldata {: #preparing-the-mint-evm-calldata }

First, we'll generate the necessary calldata for minting the MARS and NEPT tokens. We'll then reference the Batch Precompile to batch the calls into a single one.

The function being targeted here is the `mint` function of [Moonbase Minter](https://moonbase-minterc20.netlify.app){target=\_blank}. It takes no parameters, and the function calldata is the same for each planet. However, each planet has a different contract address.

The easiest way to get the calldata is through the [Moonbase Minter](https://moonbase-minterc20.netlify.app){target=\_blank} page. Once you land on the website, take the following steps:

 1. Press **Connect MetaMask** and unlock your wallet
 2. Click on any of the **Mint** buttons since they all have the same calldata
 3. MetaMask should pop up, but **do not sign the transaction**. In MetaMask, click on the **hex** tab, and the encoded calldata should show up
 4. Click on the **Copy raw transaction data** button. This will copy the encoded calldata to the clipboard, which should match: `0x2004ffd9`

![Calldata for Minting action](/images/tutorials/interoperability/remote-batched-evm-calls/remote-batched-evm-calls-2.webp)

!!! note
    Other wallets also offer the same capabilities of checking the encoded calldata before signing the transaction.

## Preparing the Batch Calldata {: #preparing-the-batched-calldata }

Now that we have the calldata for the mint actions, we can work with the Batch Precompile to combine multiple calls into a single one. The Batch Precompile offers several different methods of batching your transactions according to your tolerance for subcall failures. For this example, we'll use the `batchAll` function, which reverts all subcalls if a single subcall fails. For more information about how each method of the Batch Precompile works, be sure to check out the full [Batch Precompile tutorial](/builders/ethereum/precompiles/ux/batch/){target=\_blank}.

For demonstration purposes, we'll be using [Remix](http://remix.ethereum.org){target=\_blank} to visualize and construct our calldata. If needed, the [Batch Precompile page](/builders/ethereum/precompiles/ux/batch/#remix-set-up){target=\_blank} offers a step-by-step guide for getting started with the Batch Precompile in Remix.

To quickly get started, go ahead and copy [`Batch.sol`](https://raw.githubusercontent.com/moonbeam-foundation/moonbeam/master/precompiles/batch/Batch.sol){target=\_blank} and compile it. From the **Deploy** tab of Remix, specify your environment in Remix as **Injected Web3** and make sure your wallet is on the Moonbase Alpha network. As it is a precompile, we won't be deploying anything but rather will access the Batch Precompile at its respective address:

=== "Moonbeam"

     ```text
     {{networks.moonbeam.precompiles.batch }}
     ```

=== "Moonriver"

     ```text
     {{networks.moonriver.precompiles.batch }}
     ```

=== "Moonbase Alpha"

     ```text
     {{networks.moonbase.precompiles.batch }}
     ```

After inputting the address and pressing **At Address**, take the following steps to prepare the batch calls:

1. Expand the **batchAll** or another desired method of the Batch Precompile
2. In the **To** field, place the addresses of the MARS and NEPT contracts enclosed in quotes and separated by a comma. The entire line should be wrapped in brackets as follows: 
`["0x1FC56B105c4F0A1a8038c2b429932B122f6B631f","0xed13B028697febd70f34cf9a9E280a8f1E98FD29"]`
3. Provide an empty array (`[]`) in the value field. We don't want to send any tokens to the contracts, as they are not payable contracts
4. In the `callData` field, provide the following: `["0x2004ffd9","0x2004ffd9"]`. Note that you need to provide the calldata for each call, even if the calldata is identical, like it is with both `mint` calls
5. Optionally, you could specify a gas limit, but there is no need here, so simply provide an empty array (`[]`)
6. To validate that you have correctly configured the calls, you can press **Transact**, but don't confirm the transaction in your wallet. If you get an error, double-check that you have correctly formatted each parameter
7. MetaMask should pop up, but **do not sign the transaction**. In MetaMask, click on the **hex** tab, and the encoded calldata should show up
8. Click on the **Copy raw transaction data** button. This will copy the encoded calldata of the batch call to the clipboard

![Generate batch calls using Batch Precompile](/images/tutorials/interoperability/remote-batched-evm-calls/remote-batched-evm-calls-3.webp)

We've now finished preparing our EVM calldata for the batch call. Next, we'll need to prepare the XCM instructions that will execute our remote batch call.

## Generating the Moonbeam Encoded Calldata {: #generating-the-moonbeam-encoded-call-data }

Now that we have the batch EVM calldata that contains the two mint commands, we need to generate the bytes that the `Transact` XCM instruction from the XCM message will execute. Note that these bytes represent the action that will be executed in the remote chain. In this example, we want the XCM message execution to enter the EVM and issue the two mint commands, from which we got the encoded calldata.

To get the SCALE (encoding type) encoded calldata for the transaction parameters, we can leverage the following [Polkadot.js API](/builders/substrate/libraries/polkadot-js-api/){target=\_blank} script (note that it requires `@polkadot/api`).

```js
import { ApiPromise, WsProvider } from '@polkadot/api'; // Version 10.13.1

// 1. Input Data
const providerWsURL = 'wss://wss.api.moonbase.moonbeam.network';
const batchPrecompile = '0x0000000000000000000000000000000000000808';
const contractCall =
  '0x96e292b8000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000e0000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000001e000000000000000000000000000000000000000000000000000000000000000020000000000000000000000001fc56b105c4f0a1a8038c2b429932b122f6b631f000000000000000000000000ed13b028697febd70f34cf9a9e280a8f1e98fd29000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000042004ffd90000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000042004ffd9000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000';

const generateCallData = async () => {
  // 2. Create Substrate API Provider
  const substrateProvider = new WsProvider(providerWsURL);
  const api = await ApiPromise.create({ provider: substrateProvider });

  // 3. Estimate Gas for EVM Call
  const gasLimit = 140000n;

  // 4. Call Parameters
  const callParams = {
    V2: {
      gasLimit: gasLimit + 10000n, // Estimated plus some extra gas
      action: { Call: batchPrecompile }, // Address of the Batch Precompile
      value: 0, // Not a payable contract
      input: contractCall, // Batch of the 2 mint calls
    },
  };

  // 5. Create the Extrinsic
  const tx = api.tx.ethereumXcm.transact(callParams);

  // 6. Get SCALE Encoded Calldata
  const encodedCall = tx.method.toHex();
  console.log(`Encoded Calldata: ${encodedCall}`);

  api.disconnect();
};

generateCallData();
```

!!! note
    You can also get the SCALE encoded calldata by manually building the extrinsic in [Polkadot.js Apps](https://polkadot.js.org/apps/?rpc=wss://wss.api.moonbase.moonbeam.network#/extrinsics){target=\_blank}.

Let's go through each of the main components of the snippet shown above:

 1. Provide the input data for the request. This includes: 
     - Moonbase Alpha endpoint URL to create the providers
     - Address of the Batch Precompile
     - Encoded calldata for the batch call that contains both mint commands
 2. Create the necessary providers. One is a [Polkadot.js API](/builders/substrate/libraries/polkadot-js-api/){target=\_blank} provider, through which we can call [Moonbeam pallets](/builders/substrate/interfaces/){target=\_blank} directly
 3. Here, we are hardcoding the gas limit for simplicity and to avoid gas estimation issues as a result of the Batch Precompile
 4. [Build the remote EVM call containing the batch call](/builders/interoperability/xcm/remote-execution/remote-evm-calls/#build-remote-evm-call-xcm){target=\_blank}
 5. Create the Ethereum XCM pallet call to the `transact` method, providing the call parameters specified above
 6. Get the SCALE calldata of the specific transaction parameter, which we need to provide to the `Transact` XCM instruction later on. Note that in this particular scenario, because we need only the calldata of the transaction parameters, we have to use `tx.method.toHex()`

Once you have the code set up, you can execute it with `node`, and you'll get the Moonbase Alpha remote EVM calldata:

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>node generate-encoded-calldata.js</span>
    <span data-ty>Encoded Calldata: 0x260001f0490200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008080000000000000000000000000000000000000000000000000000000000000000110896e292b8000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000e0000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000001e000000000000000000000000000000000000000000000000000000000000000020000000000000000000000001fc56b105c4f0a1a8038c2b429932b122f6b631f000000000000000000000000ed13b028697febd70f34cf9a9e280a8f1e98fd29000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000042004ffd90000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000042004ffd900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000</span>
<span data-ty="input"><span class="file-path"></span></span>
</div>

The encoded calldata for this example is:

```text
0x260001f0490200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008080000000000000000000000000000000000000000000000000000000000000000110896e292b8000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000e0000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000001e000000000000000000000000000000000000000000000000000000000000000020000000000000000000000001fc56b105c4f0a1a8038c2b429932b122f6b631f000000000000000000000000ed13b028697febd70f34cf9a9e280a8f1e98fd29000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000042004ffd90000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000042004ffd900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
```

And that is it! You have everything you need to start crafting the XCM message itself! It has been a long journey, but we are almost there.

## Building the XCM Message from the Relay Chain {: #building-the-xcm-message-relay-chain }

We are almost in the last part of this tutorial! In this section, we'll craft the XCM message using the [Polkadot.js API](/builders/substrate/libraries/polkadot-js-api/){target=\_blank}. We'll also break down the message instruction by instruction to understand what is happening each step of the way.

The XCM message we are about to build is composed of the following instructions:

 - [`WithdrawAsset`](/builders/interoperability/xcm/core-concepts/instructions/#withdraw-asset){target=\_blank} — takes funds from the account dispatching the XCM in the destination chain and puts them in holding where they can be used for later actions
 - [`BuyExecution`](/builders/interoperability/xcm/core-concepts/instructions/#buy-execution){target=\_blank} — buy a certain amount of block execution time
 - [`Transact`](/builders/interoperability/xcm/core-concepts/instructions/#transact){target=\_blank} — use part of the block execution time bought with the previous instruction to execute some arbitrary bytes
 - [`DepositAsset`](/builders/interoperability/xcm/core-concepts/instructions/#deposit-asset){target=\_blank} — takes assets from holding and deposits them to a given account

To build the XCM message, which will initiate the remote EVM call through XCM, and get its SCALE encoded calldata, you can use the following snippet:

```js
import { ApiPromise, WsProvider } from '@polkadot/api'; // Version 10.13.1

// 1. Input Data
const providerWsURL =
  'wss://relay.api.moonbase.moonbeam.network';
const amountToWithdraw = BigInt(1 * 10 ** 16); // 0.01 DEV
const devMultiLocation = {
  parents: 0,
  interior: { X1: { PalletInstance: 3 } },
};
const weightTransact = 43500000000n; // 25000 * Gas limit of EVM call
const multiLocAccount = '0xf0615483cbe76f5b2aa80a8ce2b2e9a8206deb65'; // REPLACE with your Computed Origin account
const transactBytes =
  '0x260001f0490200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008080000000000000000000000000000000000000000000000000000000000000000110896e292b8000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000e0000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000001e000000000000000000000000000000000000000000000000000000000000000020000000000000000000000001fc56b105c4f0a1a8038c2b429932b122f6b631f000000000000000000000000ed13b028697febd70f34cf9a9e280a8f1e98fd29000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000042004ffd90000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000042004ffd900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000';

// 2. XCM Destination (Moonbase Alpha Parachain ID 1000)
const dest = { V4: { parents: 0, interior: { X1: [{ Parachain: 1000 }] } } };

// 3. XCM Instruction 1
const instr1 = {
  WithdrawAsset: [
    {
      id: { Concrete: devMultiLocation },
      fun: { Fungible: amountToWithdraw },
    },
  ],
};

// 4. XCM Instruction 2
const instr2 = {
  BuyExecution: {
    fees: {
      id: { Concrete: devMultiLocation },
      fun: { Fungible: amountToWithdraw },
    },
    weightLimit: { Unlimited: null },
  },
};

// 5. XCM Instruction 3
const instr3 = {
  Transact: {
    originKind: 'SovereignAccount',
    requireWeightAtMost: { refTime: weightTransact, proofSize: 200000n },
    call: {
      encoded: transactBytes,
    },
  },
};

// 6. XCM Instruction 4
const instr4 = {
  DepositAsset: {
    assets: { Wild: 'All' },
    beneficiary: {
      parents: 0,
      interior: { X1: [{ AccountKey20: { key: multiLocAccount } }] },
    },
  },
};

// 7. Build XCM Message
const message = { V4: [instr1, instr2, instr3, instr4] };

const generateCallData = async () => {
  // 8. Create Substrate API Provider
  const substrateProvider = new WsProvider(providerWsURL);
  const api = await ApiPromise.create({ provider: substrateProvider });

  // 9. Create the Extrinsic
  const tx = api.tx.xcmPallet.send(dest, message);

  // 10. Get SCALE Encoded Calldata
  const encodedCall = tx.toHex();
  console.log(`Encoded Calldata: ${encodedCall}`);

  api.disconnect();
};

generateCallData();
```

!!! note
    You can also get the SCALE encoded calldata by manually building the extrinsic in [Polkadot.js Apps](https://polkadot.js.org/apps/?rpc=wss://relay.api.moonbase.moonbeam.network#/extrinsics){target=\_blank}.

Let's go through each of the main components of the snippet shown above:

 1. Provide the input data for the call. This includes:
     - [Moonbase relay chain](https://polkadot.js.org/apps/?rpc=wss://relay.api.moonbase.moonbeam.network#/accounts){target=\_blank} endpoint URL to create the provider
     - Amount of tokens (in Wei) to withdraw from the Computed Origin account. For this example, `0.01` tokens are more than enough. To understand how to get this value, please refer to the [XCM fee page](/builders/interoperability/xcm/core-concepts/weights-fees/#moonbeam-reserve-assets){target=\_blank}
     - The [multilocation of the DEV token](/builders/interoperability/xcm/xc-registration/assets/#register-moonbeam-native-assets){target=\_blank}, as seen by Moonbase Alpha
     - The weight for the `transact` XCM instruction. This can be obtained by multiplying `25000` by the gas limit obtained before. It is recommended to add approximately 10% more of the estimated value. You can read more about this value on the [Remote EVM Calls through XCM](/builders/interoperability/xcm/remote-execution/remote-evm-calls/#build-xcm-remote-evm){target=\_blank} page
     - The Computed Origin account, as it will be needed later for an XCM instruction
     - The bytes for the `transact` XCM instruction that we calculated in the previous section
 2. Define the destination multilocation for the XCM message. In this case, it is the Moonbase Alpha parachain
 3. First XCM instruction, `WithdrawAsset`. You need to provide the asset multilocation and the amount you want to withdraw. Both variables were already described before
 4. Second XCM instruction, `BuyExecution`. Here, we are paying for Moonbase Alpha block execution time in DEV tokens by providing its multilocation and the amount we took out with the previous instruction. Next, we are buying all the execution we can (`Unlimited` weight) with `0.01 DEV` tokens which should be around 20 billion weight units, plenty for our example
 5. Third XCM instruction, `Transact`. The instruction will use a portion of the weight bought (defined as `requireWeightAtMost`) and execute the arbitrary bytes that are provided (`transactBytes`)
 6. Fourth XCM instruction, `DepositAsset`. Whatever is left in holding after the actions executed before (in this case, it should be only DEV tokens) is deposited into the Computed Origin account, set as the `beneficiary`.
 7. Build the XCM message by concatenating the instructions inside a `V3` array
 8. Create the [Polkadot.js API](/builders/substrate/libraries/polkadot-js-api/){target=\_blank} provider
 9. Craft the `xcmPallet.send` extrinsic with the destination and XCM message. This method will append the [`DescendOrigin`](/builders/interoperability/xcm/core-concepts/instructions/#descend-origin){target=\_blank} XCM instruction to our XCM message, and it is the instruction that will provide the necessary information to calculate the Computed Origin account
 10. Get the SCALE encoded calldata. Note that in this particular scenario, because we need the full SCALE encoded calldata, we have to use `tx.toHex()`. This is because we will submit this transaction using the calldata

Once you have the code set up, you can execute it with `node`, and you'll get the relay chain XCM calldata:

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>node build-xcm-message.js</span>
    <span data-ty>Encoded Calldata: 0xb50a04630004000100a10f041000040000000f0000c16ff28623130000000f0000c16ff28623000601070053cd200a02350c007d09260001f0490200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008080000000000000000000000000000000000000000000000000000000000000000110896e292b8000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000e0000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000001e000000000000000000000000000000000000000000000000000000000000000020000000000000000000000001fc56b105c4f0a1a8038c2b429932b122f6b631f000000000000000000000000ed13b028697febd70f34cf9a9e280a8f1e98fd29000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000042004ffd90000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000042004ffd9000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000d010000010300f0615483cbe76f5b2aa80a8ce2b2e9a8206deb65</span>
<span data-ty="input"><span class="file-path"></span></span>
</div>

The encoded calldata for this example is:

```text
0xb50a04630004000100a10f041000040000000f0000c16ff28623130000000f0000c16ff28623000601070053cd200a02350c007d09260001f0490200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008080000000000000000000000000000000000000000000000000000000000000000110896e292b8000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000e0000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000001e000000000000000000000000000000000000000000000000000000000000000020000000000000000000000001fc56b105c4f0a1a8038c2b429932b122f6b631f000000000000000000000000ed13b028697febd70f34cf9a9e280a8f1e98fd29000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000042004ffd90000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000042004ffd9000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000d010000010300f0615483cbe76f5b2aa80a8ce2b2e9a8206deb65
```

!!! note
    The encoded calldata for you should be slightly different, as you should have replaced the Computed Origin account in the script with the one you created in the [Calculating Your Computed Origin Account](#calculating-your-computed-origin-account) section.

Now that we have the SCALE encoded calldata, the last step is to submit the transaction, which will send our XCM message to Moonbase Alpha, and do the remote batch EVM call!

## Sending the XCM Message from the Relay Chain {: #send-xcm-message-relay-chain }

Congratulations on making it here, you're almost done! Let's recap what we've done so far:

 - We've created a relay chain account that is funded with UNIT tokens (relay chain native tokens)
 - We determined its Computed Origin account on Moonbase Alpha and funded this new address with DEV tokens
 - We obtained the Batch Precompile calldata which combines two mint calls for MARS and NEPT ERC-20 tokens
 - We built the SCALE encoded calldata in Moonbase Alpha to access its EVM via XCM
 - We crafted our transaction to send an XCM message to Moonbase Alpha, in which we will ask it to execute the SCALE encoded calldata that was previously built. This, in turn, will execute the call to the Batch Precompile which includes the mint calls for both the MARS and NEPT ERC-20 tokens!

To send the XCM message that we built in the previous section, you can use the following code snippet:

```js
import { ApiPromise, WsProvider, Keyring } from '@polkadot/api'; // Version 10.13.1
import { cryptoWaitReady } from '@polkadot/util-crypto';

// 1. Input Data
const providerWsURL =
  'wss://relay.api.moonbase.moonbeam.network';
const MNEMONIC = 'INSERT_MNEMONIC'; // Not safe, only for testing
const txCall =
  '0xb50a04630004000100a10f041000040000000f0000c16ff28623130000000f0000c16ff28623000601070053cd200a02350c007d09260001f0490200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008080000000000000000000000000000000000000000000000000000000000000000110896e292b8000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000e0000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000001e000000000000000000000000000000000000000000000000000000000000000020000000000000000000000001fc56b105c4f0a1a8038c2b429932b122f6b631f000000000000000000000000ed13b028697febd70f34cf9a9e280a8f1e98fd29000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000042004ffd90000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000042004ffd9000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000d010000010300f0615483cbe76f5b2aa80a8ce2b2e9a8206deb65';

const sendXCM = async () => {
  // 2. Create Keyring Instance
  await cryptoWaitReady();
  const keyring = new Keyring({ type: 'sr25519' });
  const alice = keyring.addFromUri(MNEMONIC);

  // 3. Create Substrate API Provider
  const substrateProvider = new WsProvider(providerWsURL);
  const api = await ApiPromise.create({ provider: substrateProvider });

  // 4. Create the Extrinsic
  const tx = await api.tx(txCall).signAndSend(alice, (result) => {
    // 5. Check Transaction Status
    console.log(`Transaction sent`);
    if (result.status.isInBlock) {
      console.log(
        `Transaction included in blockHash ${result.status.asInBlock}`
      );
    }
  });

  api.disconnect();
};

sendXCM();
```

Once you have the code set up, you can execute it with `node`, and the XCM message will be sent to initiate your call to the Batch Precompile for the mints of MARS and NEPT ERC-20 tokens in Moonbase Alpha. Don't worry if you see an `Abnormal Closure` error. You can verify that your remote batch call was successful by looking up your Computed Origin account on [Moonbase Moonscan](https://moonbase.moonscan.io){target=\_blank}.

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>node send-xcm-message.js</span>
    <span data-ty>Transaction sent</span>
    <span data-ty>Transaction sent</span>
<span data-ty="input"><span class="file-path"></span></span>
</div>

And that is it! You've sent an XCM message, which performed a remote EVM call to the Batch Precompile via XCM and resulted in the minting of MARS and NEPT ERC-20 tokens. But let's go into more detail about what happened.

This action will emit different events. The first one is only relevant [in the relay chain](https://polkadot.js.org/apps/?rpc=wss://relay.api.moonbase.moonbeam.network#/explorer/query/10936471){target=\_blank}, and it is named `xcmPallet.Sent`, which is from the `xcmPallet.send` extrinsic. In [Moonbase Alpha](https://polkadot.js.org/apps/?rpc=wss://wss.api.moonbase.moonbeam.network#/explorer/query/4626493){target=\_blank}, the following events emitted by the `parachainSystem.setValidationData` extrinsic (where all the inbound XCM messages are processed) are of interest:

 - `parachainSystem.DownwardMessagesReceived` — states that there was an XCM message received
 - `evm.Log` — internal events emitted by the different contract calls. The structure is the same: contract address, topics, and relevant data
 - `ethereum.Executed` — contains information on the `from` address, the `to` address, and the transaction hash of an EVM call done
 - `polkadotXcm.AssetsTrapped` — flags that some assets were in holding and were not deposited to a given address. If the `Transact` XCM instruction does not exhaust the tokens allocated to it, it will execute a [`RefundSurplus`](/builders/interoperability/xcm/core-concepts/instructions/#refund-surplus){target=\_blank} after the XCM is processed. This instruction will take any leftover tokens from the execution bought and put them in holding. We could prevent this by adjusting the fee provided to the `Transact` instruction or by adding the instruction right after the `Transact`
 - `dmpQueue.ExecutedDownward` — states the result of executing a message received from the relay chain (a DMP message). In this case, the `outcome` is marked as `Complete`

Our XCM was successfully executed! If you visit [Moonbase Alpha Moonscan](https://moonbase.moonscan.io){target=\_blank} and search for [the transaction hash](https://moonbase.moonscan.io/tx/0xd5e855bc3ade42d040f3c29abe129bd8f488dee0014e731eba4617883aac3891){target=\_blank}, you'll find the call to the Batch Precompile that was executed via the XCM message. Note that you can only call the `mint` commands once per hour per planet. If you wish to experiment further and make additional mint calls, simply change the destination contract address to a different planet when configuring the batch call.

!!! challenge
    Use the Batch Precompile and remote EVM calls via XCM to combine an approval and a Uniswap V2 swap of MARS for any other token you want. As a thought experiment, consider carefully which method of the Batch Precompile is best suited to combine an approval and a swap transaction. Both the [Uniswap V2 Swap from Polkadot via XCM tutorial](/tutorials/interoperability/uniswapv2-swap-xcm/){target=\_blank} and the [Batch Precompile tutorial](/tutorials/eth-api/batch-approve-swap/){target=\_blank} are great resources to help you get started.

<div class="page-disclaimer">
    This tutorial is for educational purposes only. As such, any contracts or code created in this tutorial should not be used in production.
</div>
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/tutorials/interoperability/remote-staking-xcm/
--- BEGIN CONTENT ---
---
title: Remote Staking on Moonbeam from Polkadot via XCM
description: In this guide, we'll be leveraging remote execution to remotely stake GLMR on Moonbeam using a series of XCM instructions.
template: main.html
categories: Tutorials, XCM, Staking
---

# Remote Staking via XCM

_by Kevin Neilson_

## Introduction {: #introduction }

In this tutorial, we’ll stake DEV tokens remotely by sending XCM instructions from an account on the Moonbase relay chain (equivalent to the Polkadot relay chain). This tutorial assumes a basic familiarity with [XCM](/builders/interoperability/xcm/overview/){target=\_blank} and [Remote Execution via XCM](/builders/interoperability/xcm/remote-execution/substrate-calls/xcm-transactor-pallet/){target=\_blank}. You don’t have to be an expert on these topics but you may find it helpful to have some XCM knowledge as background.

There are actually two possible approaches for staking on Moonbeam remotely via XCM. We could send a [remote EVM call](/builders/interoperability/xcm/remote-execution/remote-evm-calls/){target=\_blank} that calls the [staking precompile](/builders/ethereum/precompiles/features/staking/){target=\_blank}, or we could use XCM to call the [parachain staking pallet](/builders/substrate/interfaces/features/staking/){target=\_blank} directly without interacting with the EVM. For this tutorial, we’ll be taking the latter approach and interacting with the parachain staking pallet directly.

**Note that there are still limitations in what you can remotely execute through XCM messages.** In addition, **developers must understand that sending incorrect XCM messages can result in the loss of funds.** Consequently, it is essential to test XCM features on a TestNet before moving to a production environment.

## Checking Prerequisites {: #checking-prerequisites }

For development purposes this tutorial is written for Moonbase Alpha and Moonbase relay using TestNet funds. For prerequisites:

- A Moonbase Alpha relay chain account funded with some UNIT, the native token of the Moonbase relay chain. If you have a Moonbase Alpha account funded with DEV tokens, you can swap some DEV for xcUNIT here on [Moonbeam Swap](https://moonbeam-swap.netlify.app/#/swap){target=\_blank}. Then withdraw the xcUNIT from Moonbase Alpha to [your account on the Moonbase relay chain](https://polkadot.js.org/apps/?rpc=wss://relay.api.moonbase.moonbeam.network#/accounts){target=\_blank} using [apps.moonbeam.network](https://apps.moonbeam.network/moonbase-alpha){target=\_blank}
- You'll need to [calculate the Computed Origin account](#calculating-your-computed-origin-account) of your Moonbase Alpha relay chain account and fund it with DEV tokens.
You can get DEV tokens for testing on Moonbase Alpha once every 24 hours from the [Moonbase Alpha Faucet](https://faucet.moonbeam.network){target=\_blank}

## Calculating your Computed Origin Account {: #calculating-your-computed-origin-account }

Copy the account of your existing or newly created account on the [Moonbase relay chain](https://polkadot.js.org/apps/?rpc=wss://relay.api.moonbase.moonbeam.network#/accounts){target=\_blank}. You're going to need it to calculate the corresponding Computed Origin account, which is a special type of account that’s keyless (the private key is unknown). Transactions from a Computed Origin account can be initiated only via valid XCM instructions from the corresponding account on the relay chain. In other words, you are the only one who can initiate transactions on your Computed Origin account, and if you lose access to your Moonbase relay account, you’ll also lose access to your Computed Origin account.

To generate the Computed Origin account, first clone the [xcm-tools](https://github.com/Moonsong-Labs/xcm-tools){target=\_blank} repo. Run `yarn` to install the necessary packages, and then run:

```sh
yarn calculate-multilocation-derivative-account \
--ws-provider wss://wss.api.moonbase.moonbeam.network \
--address INSERT_MOONBASE_RELAY_ACCOUNT \
--para-id INSERT_ORIGIN_PARACHAIN_ID_IF_APPLIES \
--parents INSERT_PARENTS_VALUE_IF_APPLIES
```

Let's review the parameters passed along with this command:

- The `--ws-provider` or `-w` flag corresponds to the endpoint we’re using to fetch this information
- The `--address` or `-a` flag corresponds to your Moonbase relay chain address
- The `--para-id` or `-p` flag corresponds to the parachain ID of the origin chain (if applicable). If you are sending the XCM from the relay chain, you don't need to provide this parameter
- The `-parents` flag corresponds to the parents value of the origin chain in relation to the destination chain. If you're deriving a multi-location derivative account on a parachain destination from a relay chain origin, this value would be `1`. If left out, the parents value defaults to `0`

Here, we have specified a parents value of `1` because the relay chain is the origin of the request (and the relay chain is considered a parent to the Moonbase alpha parachain). The relay chain does not have a parachain id so that field is omitted.

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>yarn calculate-multilocation-derivative-account \</span>
    <span data-ty>--ws-provider wss://wss.api.moonbase.moonbeam.network \</span>
    <span data-ty>--address 5DCvkTpkqo5AuvUFSrT76ABnm48iSBHpgsoDFNxFZAtesvWD \</span>
    <span data-ty>--parents 1</span>
    <br>
    <span data-ty>yarn run v1.22.10</span>
    <span data-ty>warning ../../../package.json: No license field</span>
    <span data-ty>$ ts-node 'scripts/calculate-multilocation-derivative-account.ts' --ws-provider wss://wss.api.moonbase.moonbeam.network --address 5DCvkTpkqo5AuvUFSrT76ABnm48iSBHpgsoDFNxFZAtesvWD --parents 1</span>
    <br>
    <span data-ty>Remote Origin calculated as ParentChain</span>
    <span data-ty>Parents 1</span>
    <span data-ty>AccountId32: 5DCvkTpkqo5AuvUFSrT76ABnm48iSBHpgsoDFNxFZAtesvWD</span>
    <span data-ty>32 byte address is 0x55738eb7227f27c9d55775f65ad261c5ac2894dcde73d913f77f69bf51e26279</span>
    <span data-ty>20 byte address is 0x55738eb7227f27c9d55775f65ad261c5ac2894dc</span>
    <span data-ty>✨  Done in 1.02s.</span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>

The script will return 32-byte and 20-byte addresses. We’re interested in the Ethereum-style account - the 20-byte one. Feel free to look up your Computed Origin account on [Moonscan](https://moonbase.moonscan.io){target=\_blank}. You’ll note that this account is empty. You’ll now need to fund this account with at least 1.1 DEV which you can get from [the faucet](https://faucet.moonbeam.network){target=\_blank}. And if you need more, you can always reach out to us on [Discord](https://discord.com/invite/amTRXQ9ZpW){target=\_blank} for additional DEV tokens.

## Preparing to Stake on Moonbase Alpha {: #preparing-to-stake-on-moonbase-alpha }

First and foremost, you’ll need the address of the collator you want to delegate to. To locate it, head to the [Moonbase Alpha Staking dApp](https://apps.moonbeam.network/moonbase-alpha/staking){target=\_blank} in a second window. Ensure you’re on the correct network, then press **Select a Collator**. Press the icon next to your desired collator to copy its address. You’ll also need to make a note of the number of delegations your collator has. The [Moonbeam Foundation 01 collator](https://moonbase.subscan.io/account/{{networks.moonbase.precompiles.staking}}){target=\_blank} shown below has `7` delegations at the time of writing.

![Moonbeam Network Apps Dashboard](/images/tutorials/interoperability/remote-staking-via-xcm/xcm-stake-1.webp)

## Remote Staking via XCM with the Polkadot.js API {: #remote-staking-via-xcm-with-the-polkadot-api }

This tutorial will cover the two-step process to perform remote staking operations. The first step we'll take is to generate the encoded call data for delegating a collator. Secondly, we'll send the encoded call data via XCM from the relay chain to Moonbase Alpha, which will result in the execution of the delegation.

### Generate the Encoded Call Data {: #generate-encoded-call-data }

We'll be using the `delegateWithAutoCompound` function of the [Parachain Staking Pallet](/builders/substrate/interfaces/features/staking/){target=\_blank}, which accepts six parameters: `candidate`, `amount`, `autoCompound`, `candidateDelegationCount`, `candidateAutoCompoundingDelegationCount`, and `delegationCount`.

In order to generate the encoded call data, we'll need to assemble the arguments for each of the `delegateWithAutoCompound` parameters and use them to build a transaction which will call the `delegateWithAutoCompound` function. We are not submitting a transaction, but simply preparing one to get the encoded call data. We'll take the following steps to build our script:

1. Create a [Polkadot.js API](/builders/substrate/libraries/polkadot-js-api/){target=\_blank} provider
2. Assemble the arguments for each of the parameters of the `delegateWithAutoCompound` function:

    - `candidate`- for this example we'll use the [Moonbeam Foundation 01 collator](https://moonbase.subscan.io/account/{{networks.moonbase.staking.candidates.address1}}){target=\_blank}: `{{networks.moonbase.staking.candidates.address1}}`. To retrieve the entire list of candidates, you can refer back to the [Preparing to Stake](#preparing-to-stake-on-moonbase-alpha) section
    - `amount` - we'll stake the minimum amount, which is 1 DEV or `1000000000000000000` Wei. You can find a [unit converter on Moonscan](https://moonscan.io/unitconverter){target=\_blank}
    - `autoCompound` - we'll set this to `100` to auto-compound all rewards
    - `candidateDelegationCount` - we'll retrieve using the `candidateInfo` function of the Parachain Staking Pallet to get the exact count. Alternatively, you can enter the upper bound of `300` because this estimation is only used to determine the weight of the call
    - `candidateAutoCompoundingDelegationCount` - we'll retrieve using the `autoCompoundingDelegations` function of the Parachain Staking Pallet to get the exact count. Alternatively, you can enter the upper bound of `300` because this estimation is only used to determine the weight of the call
    - `delegationCount` - we'll retrieve using the `delegatorState` function of the Parachain Staking Pallet to get the exact count. Alternatively, you can specify an upper bound here of `100`

3. Craft the `parachainStaking.delegateWithAutoCompound` extrinsic with each of the required arguments
4. Use the transaction to get the encoded call data for the delegation

```js
import { ApiPromise, WsProvider } from '@polkadot/api';
const provider = new WsProvider('wss://wss.api.moonbase.moonbeam.network');

const candidate = '0x12E7BCCA9b1B15f33585b5fc898B967149BDb9a5';
const amount = '1000000000000000000';
const autoCompound = 100;

const main = async () => {
  const api = await ApiPromise.create({ provider: provider });

  // Fetch your existing number of delegations
  let delegatorDelegationCount;
  const delegatorInfo = await api.query.parachainStaking.delegatorState(
    'INSERT_ACCOUNT' // Use the account you're delegating with
  );

  if (delegatorInfo.toHuman()) {
    delegatorDelegationCount = delegatorInfo.toHuman()['delegations'].length;
  } else {
    delegatorDelegationCount = 0;
  }

  // Fetch the collators existing delegations
  const collatorInfo = await api.query.parachainStaking.candidateInfo(
    candidate
  );
  const candidateDelegationCount = collatorInfo.toHuman()['delegationCount'];

  // Fetch the collators number of existing auto-compounding delegations
  const autoCompoundingDelegationsInfo =
    await api.query.parachainStaking.autoCompoundingDelegations(candidate);
  const candidateAutoCompoundingDelegationCount =
    autoCompoundingDelegationsInfo.length;

  // Craft extrinsic
  const tx = api.tx.parachainStaking.delegateWithAutoCompound(
    candidate,
    amount,
    autoCompound,
    candidateDelegationCount,
    candidateAutoCompoundingDelegationCount,
    delegatorDelegationCount
  );

  // Get SCALE encoded call data
  const encodedCall = tx.method.toHex();
  console.log(`Encoded Call Data: ${encodedCall}`);

  api.disconnect();
};
main();
```

!!! note
    If running this as a TypeScript project, be sure to set the `strict` flag under `compilerOptions` to `false` in your `tsconfig.json`.

If you'd prefer not to set up a local environment, you can run a code snippet in the [JavaScript console of Polkadot.js Apps](https://polkadot.js.org/apps/?rpc=wss://wss.api.moonbase.moonbeam.network#/js){target=\_blank}.

??? code "Code to run in the Polkadot.js Apps JavaScript console"

    ```javascript
    const candidate = '0x12E7BCCA9b1B15f33585b5fc898B967149BDb9a5';
const amount = '1000000000000000000';
const autoCompound = 100;

// Fetch your existing number of delegations
let delegatorDelegationCount;
// Use the account you're delegating with
const delegatorInfo = await api.query.parachainStaking.delegatorState(
  'INSERT_ACCOUNT'
);

if (delegatorInfo.toHuman()) {
  delegatorDelegationCount = delegatorInfo.toHuman()['delegations'].length;
} else {
  delegatorDelegationCount = 0;
}

// Fetch the collators existing delegations
const collatorInfo = await api.query.parachainStaking.candidateInfo(candidate);
const candidateDelegationCount = collatorInfo.toHuman()['delegationCount'];

// Fetch the collators number of existing auto-compounding delegations
const autoCompoundingDelegationsInfo =
  await api.query.parachainStaking.autoCompoundingDelegations(candidate);
const candidateAutoCompoundingDelegationCount =
  autoCompoundingDelegationsInfo.length;

// Craft extrinsic
const tx = api.tx.parachainStaking.delegateWithAutoCompound(
  candidate,
  amount,
  autoCompound,
  candidateDelegationCount,
  candidateAutoCompoundingDelegationCount,
  delegatorDelegationCount
);

// Get SCALE Encoded Call Data
const encodedCall = tx.method.toHex();
console.log(`Encoded Call Data: ${encodedCall}`);
    ```

### Assemble and Send XCM Instructions via the Polkadot.js API {: #sending-the-xcm-instructions-via-the-polkadot-api }

In this section, we'll be using the [Polkadot.js API](/builders/substrate/libraries/polkadot-js-api/){target=\_blank} to construct and send XCM instructions via the `send` extrinsic of the XCM Pallet on the Moonbase relay chain. The XCM message will transport our remote execution instructions to the Moonbase Alpha parachain to ultimately stake our desired amount of DEV tokens to a chosen collator.

The `send` function of the XCM Pallet accepts two parameters: `dest` and `message`. You can start assembling these parameters by taking the following steps:

1. Build the multilocation of the DEV token on Moonbase Alpha for the `dest`:

    ```javascript
    const dest = { V4: { parents: 0, interior: { X1: [{ Parachain: 1000 }] } } };
    ```

2. Build the `WithdrawAsset` instruction, which will require you to define:
    - The multilocation of the DEV token on Moonbase Alpha
    - The amount of DEV tokens to withdraw

    ```javascript
    const instr1 = {
  WithdrawAsset: [
    {
      id: {
        parents: 0,
        interior: { X1: [{ PalletInstance: 3 }] },
      },
      fun: { Fungible: 100000000000000000n },
    },
  ],
};
    ```

3. Build the `BuyExecution` instruction, which will require you to define:
    - The multilocation of the DEV token on Moonbase Alpha
    - The amount of DEV tokens to buy for execution
    - The weight limit

    ```javascript
    const instr2 = {
  BuyExecution: [
    {
      id: {
        parents: 0,
        interior: { X1: [{ PalletInstance: 3 }] },
      },
      fun: { Fungible: 100000000000000000n },
    },
    { Unlimited: null },
  ],
};
    ```

4. Build the `Transact` instruction, which will require you to define:
    - The origin type, which will be `SovereignAccount`
    - The required weight for the transaction. You'll need to define a value for `refTime`, which is the amount of computational time that can be used for execution, and the `proofSize`, which is the amount of storage in bytes that can be used. It is recommended that the weight given to this instruction needs to be around 10% more of `25000` times the gas limit for the call you want to execute via XCM
    - The encoded call data for delegating a collator, which we generated in the [previous section](#generate-encoded-call-data)

    ```javascript
    const instr3 = {
  Transact: {
    originKind: 'SovereignAccount',
    requireWeightAtMost: { refTime: 40000000000n, proofSize: 900000n },
    call: {
      encoded:
        '0x0c1212e7bcca9b1b15f33585b5fc898b967149bdb9a5000064a7b3b6e00d000000000000000064070000000700000000000000',
    },
  },
};
    ```

5. Combine the XCM instructions into a versioned XCM message:

    ```javascript
    const message = { V4: [instr1, instr2, instr3] };
    ```

Now that you have the values for each of the parameters, you can write the script to send the XCM message. You'll take the following steps:

 1. Provide the values for each of the parameters of the `send` function
 2. Create the [Polkadot.js API](/builders/substrate/libraries/polkadot-js-api/){target=\_blank} provider using the WSS endpoint of the Alphanet relay chain
 3. Create a Keyring instance using the mnemonic of your relay chain account, which will be used to send the transaction
 4. Craft the `xcmPallet.send` extrinsic with the `dest` and `message`
 5. Send the transaction using the `signAndSend` extrinsic and the Keyring instance you created in the third step

!!! remember
    This is for demo purposes only. Never store your private key in a JavaScript file.

```javascript
import { ApiPromise, WsProvider, Keyring } from '@polkadot/api';
import { cryptoWaitReady } from '@polkadot/util-crypto';

const privateKey = 'INSERT_PRIVATE_KEY_OR_MNEMONIC';

// 1. Define the dest and message arguments
const dest = { V4: { parents: 0, interior: { X1: [{ Parachain: 1000 }] } } };
const instr1 = {
  WithdrawAsset: [
    {
      id: {
        parents: 0,
        interior: { X1: [{ PalletInstance: 3 }] },
      },
      fun: { Fungible: 100000000000000000n },
    },
  ],
};
const instr2 = {
  BuyExecution: [
    {
      id: {
        parents: 0,
        interior: { X1: [{ PalletInstance: 3 }] },
      },
      fun: { Fungible: 100000000000000000n },
    },
    { Unlimited: null },
  ],
};
const instr3 = {
  Transact: {
    originKind: 'SovereignAccount',
    requireWeightAtMost: { refTime: 40000000000n, proofSize: 900000n },
    call: {
      encoded:
        '0x0c1212e7bcca9b1b15f33585b5fc898b967149bdb9a5000064a7b3b6e00d000000000000000064070000000700000000000000',
    },
  },
};
const message = { V4: [instr1, instr2, instr3] };

const performRemoteDelegation = async () => {
  // 2. Construct API provider
  const wsProvider = new WsProvider(
    'wss://relay.api.moonbase.moonbeam.network'
  );
  const api = await ApiPromise.create({ provider: wsProvider });

  // 3. Initialize wallet key pairs
  await cryptoWaitReady();
  const keyring = new Keyring({ type: 'sr25519' });
  // For demo purposes only. Never store your private key or mnemonic in a JavaScript file
  const otherPair = keyring.addFromUri(privateKey);
  console.log(`Derived Address from Private Key: ${otherPair.address}`);

  // 4. Define the transaction using the send method of the xcm pallet
  const tx = api.tx.xcmPallet.send(dest, message);

  // 5. Sign and send the transaction
  const txHash = await tx.signAndSend(otherPair);
  console.log(`Submitted with hash ${txHash}`);

  api.disconnect();
};

performRemoteDelegation();
```

!!! note
    Remember that your Computed Origin account must be funded with at least 1.1 DEV or more to ensure you have enough to cover the stake amount and transaction fees.

In the above snippet, besides submitting the remote staking via XCM transaction, we also print out the transaction hash to assist with any debugging.

And that’s it! To verify that your delegation was successful, you can visit [Subscan](https://moonbase.subscan.io){target=\_blank} to check your staking balance. Be advised that it may take a few minutes before your staking balance is visible on Subscan. Additionally, be aware that you will not be able to see this staking operation on Moonscan, because we initiated the delegation action directly via the [Parachain Staking Pallet](/builders/substrate/interfaces/features/staking/){target=\_blank} (on the Substrate side) rather than through the [Staking Precompile](/builders/ethereum/precompiles/features/staking/){target=\_blank} (on the EVM).

<div class="page-disclaimer">
    This tutorial is for educational purposes only. As such, any contracts or code created in this tutorial should not be used in production.
</div>
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/tutorials/interoperability/uniswapv2-swap-xcm/
--- BEGIN CONTENT ---
---
title: Uniswap V2 Swap on Moonbeam from Polkadot via XCM
description: In this guide, we'll use remote EVM execution via XCM to perform a Uniswap V2 swap to showcase how Moonbeam can be leveraged in a connected contracts approach.
template: main.html
categories: Tutorials, XCM
---

# Uniswap V2 Swap from Polkadot via XCM

_by Alberto Viera_

## Introduction {: #introduction }

In this tutorial, we’ll perform a Uniswap V2-styled swap from a relay chain (what Polkadot is to Moonbeam) using Polkadot's interoperability general message passing protocol called [XCM](/builders/interoperability/xcm/overview/){target=\_blank}. To do so, we'll be using a particular combination of XCM instructions that allow you to [call Moonbeam's EVM through an XCM message](/builders/interoperability/xcm/remote-execution/remote-evm-calls/){target=\_blank}. Consequently, any blockchain that is able to send an XCM message to Moonbeam can tap into its EVM and all the dApps built on top of it.

**The content of this tutorial is for educational purposes only!**

For this example, you'll be working on top of the Moonbase Alpha (Moonbeam TestNet), which has its own relay chain (similar to Polkadot). The relay chain token is called `UNIT`, while Moonbase Alpha's is called `DEV`. Doing this in TestNet is less fun than doing it in production, but **developers must understand that sending incorrect XCM messages can result in the loss of funds.** Consequently, it is essential to test XCM features on a TestNet before moving to a production environment.

Throughout this tutorial, we will refer to the account performing the Uniswap V2 swap via XCM as Alice. The tutorial has a lot of moving parts, so let's summarize them in a list and a flow diagram:

1. Alice has an account on the relay chain, and she wants to swap `DEV` tokens for `MARS` tokens (ERC-20 on Moonbase Alpha) on [Moonbeam-Swap](https://moonbeam-swap.netlify.app){target=\_blank}, a demo Uniswap V2 clone on Moonbase Alpha. Alice needs to send an XCM message to Moonbase Alpha from her relay chain account
2. The XCM message will be received by Moonbase Alpha and its instructions executed. The instructions state Alice's intention to buy some block execution time in Moonbase Alpha and execute a call to Moonbase's EVM, specifically, the Uniswap V2 (Moonbeam-Swap) router contract. The EVM call is dispatched through a special account Alice controls on Moonbase Alpha via XCM messages. This account is known as the [Computed Origin account](/builders/interoperability/xcm/remote-execution/computed-origins/){target=\_blank}. Even though this is a keyless account (private key is unknown), the public address can be [calculated in a deterministic way](/builders/interoperability/xcm/remote-execution/computed-origins/#calculate-computed-origin){target=\_blank}
3. The XCM execution will result in the swap being executed by the EVM, and Alice will receive her `MARS` tokens in her special account
4. The execution of the remote EVM call through XCM will result in some EVM logs that are picked up by explorers. There is an EVM transaction and receipt that anyone can query to verify

![Remote EVM Call Through XCM for Uniswap V2 Swap Diagram](/images/tutorials/interoperability/uniswapv2-swap-xcm/uniswapv2-swap-xcm-1.webp)

With the steps outlined, some prerequisites need to be taken into account, let's jump right into it!

## Checking Prerequisites {: #checking-prerequisites }

Considering all the steps summarized in the [introduction](#introduction), the following prerequisites need to be accounted for:

- You need to have UNITs on the relay chain to pay for transaction fees when sending the XCM. If you have a Moonbase Alpha account funded with DEV tokens, you can swap some DEV for xcUNIT here on [Moonbeam Swap](https://moonbeam-swap.netlify.app/#/swap){target=\_blank}. Then withdraw the xcUNIT from Moonbase Alpha to [your account on the Moonbase relay chain](https://polkadot.js.org/apps/?rpc=wss://relay.api.moonbase.moonbeam.network#/accounts){target=\_blank} using [apps.moonbeam.network](https://apps.moonbeam.network/moonbase-alpha){target=\_blank}
- Your [Computed Origin account](/builders/interoperability/xcm/remote-execution/computed-origins/){target=\_blank} must hold `DEV` tokens to fund the Uniswap V2 swap, and also pay for the XCM execution (although this could be paid in UNIT tokens as `xcUNIT`). We will calculate the Computed Origin account address in the next section

You can get DEV tokens for testing on Moonbase Alpha once every 24 hours from the [Moonbase Alpha Faucet](https://faucet.moonbeam.network){target=\_blank}

## Calculating your Computed Origin Account {: #calculating-your-computed-origin-account }

Copy the account of your existing or newly created account on the [Moonbase relay chain](https://polkadot.js.org/apps/?rpc=wss://relay.api.moonbase.moonbeam.network#/accounts){target=\_blank}. You're going to need it to calculate the corresponding Computed Origin account, which is a special type of account that’s keyless (the private key is unknown). Transactions from a Computed Origin account can be initiated only via valid XCM instructions from the corresponding account on the relay chain. In other words, you are the only one who can initiate transactions on your Computed Origin account, and if you lose access to your Moonbase relay account, you’ll also lose access to your Computed Origin account.

To generate the Computed Origin account, first clone the [xcm-tools](https://github.com/Moonsong-Labs/xcm-tools){target=\_blank} repo. Run `yarn` to install the necessary packages, and then run:

```sh
yarn calculate-multilocation-derivative-account \
--ws-provider wss://wss.api.moonbase.moonbeam.network \
--address INSERT_MOONBASE_RELAY_ACCOUNT \
--para-id INSERT_ORIGIN_PARACHAIN_ID_IF_APPLIES \
--parents INSERT_PARENTS_VALUE_IF_APPLIES
```

Let's review the parameters passed along with this command:

- The `--ws-provider` or `-w` flag corresponds to the endpoint we’re using to fetch this information
- The `--address` or `-a` flag corresponds to your Moonbase relay chain address
- The `--para-id` or `-p` flag corresponds to the parachain ID of the origin chain (if applicable). If you are sending the XCM from the relay chain, you don't need to provide this parameter
- The `-parents` flag corresponds to the parents value of the origin chain in relation to the destination chain. If you're deriving a multi-location derivative account on a parachain destination from a relay chain origin, this value would be `1`. If left out, the parents value defaults to `0`

For our case, we will send the remote EVM call via XCM from Alice's account, which is `5GKh9gMK5dn9SJp6qfMNcJiMMnY7LReYmgug2Fr5fKE64imn`, so the command and response would look like the following image.

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>yarn calculate-multilocation-derivative-account \</span>
    <span data-ty>--ws-provider wss://wss.api.moonbase.moonbeam.network \</span>
    <span data-ty>--address 5GKh9gMK5dn9SJp6qfMNcJiMMnY7LReYmgug2Fr5fKE64imn \</span>
    <span data-ty>--parents 1</span>
    <br>
    <span data-ty>yarn run v1.22.10</span>
    <span data-ty>warning ../../../package.json: No license field</span>
    <span data-ty>$ ts-node 'scripts/calculate-multilocation-derivative-account.ts' --ws-provider wss://wss.api.moonbase.moonbeam.network --address 5GKh9gMK5dn9SJp6qfMNcJiMMnY7LReYmgug2Fr5fKE64imn --parents 1</span>
    <br>
    <span data-ty>Remote Origin calculated as ParentChain</span>
    <span data-ty>Parents 1</span>
    <span data-ty>AccountId32: 5GKh9gMK5dn9SJp6qfMNcJiMMnY7LReYmgug2Fr5fKE64imn</span>
    <span data-ty>32 byte address is 0x61cd3e07fe7d7f6d4680e3e322986b7877f108ddb18ec02c2f17e82fe15f9016</span>
    <span data-ty>20 byte address is 0x61cd3e07fe7d7f6d4680e3e322986b7877f108dd</span>
    <span data-ty>✨  Done in 1.02s.</span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>

The values are all summarized in the following table:

|                    Name                     |                                                                           Value                                                                           |
|:-------------------------------------------:|:---------------------------------------------------------------------------------------------------------------------------------------------------------:|
|        Origin Chain Encoded Address         |                                                    `5GKh9gMK5dn9SJp6qfMNcJiMMnY7LReYmgug2Fr5fKE64imn`                                                     |
|        Origin Chain Decoded Address         |                                           `0xbc5f3c61709f218d983fc773a600958a07fb18047418df7eeb0501d0679e397a`                                            |
| Computed Origin Account (32 bytes) |                                           `0x61cd3e07fe7d7f6d4680e3e322986b7877f108ddb18ec02c2f17e82fe15f9016`                                            |
| Computed Origin Account (20 bytes) |                                                       `0x61cd3e07fe7d7f6d4680e3e322986b7877f108dd`                                                        |

The script will return 32-byte and 20-byte addresses. We’re interested in the Ethereum-style account - the 20-byte one, which is `0x61cd3e07fe7d7f6d4680e3e322986b7877f108dd`. Feel free to look up your Computed Origin account on [Moonscan](https://moonbase.moonscan.io){target=\_blank}. Next, you can fund this account with DEV tokens.

You can get DEV tokens for testing on Moonbase Alpha once every 24 hours from the [Moonbase Alpha Faucet](https://faucet.moonbeam.network){target=\_blank}.

## Getting the Uniswap V2 Swap Calldata {: #getting-uniswapv2-swap-calldata }

The following section will walk through the steps of getting the calldata for the Uniswap V2 swap, as we need to feed this calldata to the [remote EVM call](/builders/interoperability/xcm/remote-execution/remote-evm-calls/){target=\_blank} that we will build via XCM.

The function being targeted here is one from the Uniswap V2 router, more specifically [swapExactETHForTokens](https://github.com/Uniswap/v2-periphery/blob/master/contracts/UniswapV2Router02.sol#L252){target=\_blank}. This function will swap an exact amount of protocol native tokens (in this case `DEV`) for another ERC-20 token. It has the following inputs:

 - Minimum amount of tokens that you expect out of the swap (accounting for slippage)
 - Path that the take will trade (if there is no direct pool, the swap might be routed through multiple pair pools)
 - Address of the recipient of the tokens swapped
 - The deadline (in Unix time) from which the trade is no longer valid

The easiest way to get the calldata is through the [Moonbeam Uniswap V2 Demo](https://moonbeam-swap.netlify.app){target=\_blank} page. Once you go in the website, take the following steps:

 1. Set the swap **from** value and token and also set the swap **to** token. For this example, we want to swap 1 `DEV` token for `MARS`
 2. Click on the **Swap** button. Metamask should pop up, **do not sign the transaction**
 3. In Metamask, click on the **hex** tab, and the encoded calldata should show up
 4. Click on the **Copy raw transaction data** button. This will copy the encoded calldata to the clipboard

![Calldata for Uniswap V2 swap](/images/tutorials/interoperability/uniswapv2-swap-xcm/uniswapv2-swap-xcm-2.webp)

!!! note
    Other wallets also offer the same capabilities of checking the encoded calldata before signing the transaction.

Once you have the encoded calldata, feel free to reject the transaction in your wallet. The swap calldata that we obtained is encoded as follows (all but the function selector are expressed in 32 bytes or 64 hexadecimal characters blobs):

 1. The function selector, which is 4 bytes long (8 hexadecimal characters) that represents the function you are calling
 2. The minimum amount out of the swap that we want accounting for slippage, in this case, `10b3e6f66568aaee` is `1.2035` `MARS` tokens
 3. The location (pointer) of the data part of the path parameter (which is of type dynamic). `80` in hex is `128` decimal, meaning that information about the path is presented after 128 bytes from the beginning (without counting on the function selector). Consequently, the next bit of information about the path is presented in element 6
 4. The address receiving the tokens after the swap, in this case, is the `msg.sender` of the call
 5. The deadline limit for the swap
 6. The length of the address array representing the path
 7. First token involved in the swap, which is wrapped `DEV`
 8. Second token involved in the swap, `MARS`, so it is the last

```text
1. 0x7ff36ab5
2. 00000000000000000000000000000000000000000000000010b3e6f66568aaee -> Min Amount Out
3. 0000000000000000000000000000000000000000000000000000000000000080
4. 000000000000000000000000d720165d294224a7d16f22ffc6320eb31f3006e1 -> Receiving Address
5. 0000000000000000000000000000000000000000000000000000000063dbcda5 -> Deadline
6. 0000000000000000000000000000000000000000000000000000000000000002
7. 000000000000000000000000d909178cc99d318e4d46e7e66a972955859670e1
8. 0000000000000000000000001fc56b105c4f0a1a8038c2b429932b122f6b631f
```

In the calldata, we need to change three fields to ensure our swap will go through:

 - The minimum amount out, to account for slippage as the pool may have a different `DEV/MARS` balance when you try this out
 - The receiving address to our Computed Origin account
 - The deadline to provide a bit more flexibility for our swap, so you don't have to submit this immediately

**This is OK because we are just testing things :), do not use this code in production!** Our encoded calldata should look like this (the line breaks were left for visibility):

```text
0x7ff36ab5
0000000000000000000000000000000000000000000000000de0b6b3a7640000 -> New Min Amount
0000000000000000000000000000000000000000000000000000000000000080
00000000000000000000000061cd3e07fe7d7f6d4680e3e322986b7877f108dd -> New Address
00000000000000000000000000000000000000000000000000000000A036B1B9 -> New Deadline
0000000000000000000000000000000000000000000000000000000000000002
000000000000000000000000d909178cc99d318e4d46e7e66a972955859670e1
0000000000000000000000001fc56b105c4f0a1a8038c2b429932b122f6b631f
```

Which, as one line, is:

```text
0x7ff36ab50000000000000000000000000000000000000000000000000de0b6b3a7640000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000061cd3e07fe7d7f6d4680e3e322986b7877f108dd00000000000000000000000000000000000000000000000000000000A036B1B90000000000000000000000000000000000000000000000000000000000000002000000000000000000000000d909178cc99d318e4d46e7e66a972955859670e10000000000000000000000001fc56b105c4f0a1a8038c2b429932b122f6b631f
```

You can also get the calldata programmatically using the [Uniswap V2 SDK](https://docs.uniswap.org/sdk/v2/overview){target=\_blank}.

## Generating the Moonbeam Encoded Calldata {: #generating-the-moonbeam-encoded-call-data }

Now that we have the Uniswap V2 swap encoded calldata, we need to generate the bytes that the `Transact` XCM instruction from the XCM message will execute. Note that these bytes represent the action that will be executed in the remote chain. In this example, we want the XCM message execution to enter the EVM and perform the swap, from which we got the encoded calldata.

 To get the SCALE (encoding type) encoded calldata for the transaction parameters, we can leverage the following [Polkadot.js API](/builders/substrate/libraries/polkadot-js-api/){target=\_blank} script (note that it requires `@polkadot/api` and `ethers`).

```js
import { ApiPromise, WsProvider } from '@polkadot/api'; // Version 10.13.1
import { ethers } from 'ethers'; // Version 6.12.0
import BN from 'bn.js'; // Importing directly from bn.js

// 1. Input Data
const providerWsURL = 'wss://wss.api.moonbase.moonbeam.network';
const uniswapV2Router = '0x8a1932D6E26433F3037bd6c3A40C816222a6Ccd4';
const contractCall =
  '0x7ff36ab50000000000000000000000000000000000000000000000000de0b6b3a7640000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000061cd3e07fe7d7f6d4680e3e322986b7877f108dd00000000000000000000000000000000000000000000000000000000A036B1B90000000000000000000000000000000000000000000000000000000000000002000000000000000000000000d909178cc99d318e4d46e7e66a972955859670e10000000000000000000000001fc56b105c4f0a1a8038c2b429932b122f6b631f';

const generateCallData = async () => {
  // 2. Create Substrate API Provider
  const substrateProvider = new WsProvider(providerWsURL);
  const ethProvider = new ethers.WebSocketProvider(providerWsURL);
  const api = await ApiPromise.create({ provider: substrateProvider });

  // 3. Estimate Gas for EVM Call
  const gasLimit = await ethProvider.estimateGas({
    to: uniswapV2Router,
    data: contractCall,
    value: ethers.parseEther('0.01'),
  });
  console.log(`Gas required for call is ${gasLimit.toString()}`);

  // Convert ethers' BigNumber to Polkadot's BN and add some extra
  const totalGasLimit = new BN(gasLimit.toString()).add(new BN(10000));

  // 4. Call Parameters
  const callParams = {
    V2: {
      gasLimit: totalGasLimit, // Estimated plus some extra gas
      action: { Call: uniswapV2Router }, // Uniswap V2 router address
      value: new BN(ethers.parseEther('0.01').toString()), // 0.01 DEV
      input: contractCall, // Swap encoded calldata
    },
  };

  // 5. Create the Extrinsic
  const tx = api.tx.ethereumXcm.transact(callParams);

  // 6. Get SCALE Encoded Calldata
  const encodedCall = tx.method.toHex();
  console.log(`Encoded Calldata: ${encodedCall}`);

  api.disconnect();
};

generateCallData();
```

!!! note
    You can also get the SCALE encoded calldata by manually building the extrinsic in [Polkadot.js Apps](https://polkadot.js.org/apps/?rpc=wss://wss.api.moonbase.moonbeam.network#/extrinsics){target=\_blank}.

Let's go through each of the main components of the snippet shown above:

 1. Provide the input data for the call. This includes:
     - Moonbase Alpha endpoint URL to create the providers
     - [Uniswap V2 router address](https://moonbase.moonscan.io/address/0x8a1932d6e26433f3037bd6c3a40c816222a6ccd4#code){target=\_blank} which is the one the call interacts with
     - Encoded calldata for the Uniswap V2 swap that we calculated before
 2. Create the necessary providers. One is a [Polkadot.js API](/builders/substrate/libraries/polkadot-js-api/){target=\_blank} provider, through which we can call [Moonbeam pallets](/builders/substrate/interfaces/){target=\_blank} directly. The other one is an Ethereum API provider through Ethers.js
 3. This step is mainly a best practice. Here, we are estimating the gas of the EVM call that will be executed via XCM, as this is needed later on. You can also hardcode the gas limit value, but it is not recommended
 4. [Build the remote EVM call](/builders/interoperability/xcm/remote-execution/remote-evm-calls/#build-remote-evm-call-xcm){target=\_blank}. We bumped the gas by `10000` units to provide a bit of room in case conditions change. The inputs are identical to those used for the gas estimation
 5. Create the Ethereum XCM pallet call to the `transact` method, providing the call parameters we previously built
 6. Get the SCALE calldata of the specific transaction parameter, which we need to provide to the `Transact` XCM instruction later on. Note that in this particular scenario, because we need only the calldata of the transaction parameters, we have to use `tx.method.toHex()`

Once you have the code set up, you can execute it with `node`, and you'll get the Moonbase Alpha remote EVM calldata:

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>node generate-call-data-swap.js</span>
    <br>
    <span data-ty>Gas required for call is 596363</span>
    <span data-ty>Encoded Calldata: 0x2600019b40090000000000000000000000000000000000000000000000000000000000008a1932d6e26433f3037bd6c3a40c816222a6ccd40000c16ff286230000000000000000000000000000000000000000000000000091037ff36ab50000000000000000000000000000000000000000000000000de0b6b3a7640000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000061cd3e07fe7d7f6d4680e3e322986b7877f108dd00000000000000000000000000000000000000000000000000000000a036b1b90000000000000000000000000000000000000000000000000000000000000002000000000000000000000000d909178cc99d318e4d46e7e66a972955859670e10000000000000000000000001fc56b105c4f0a1a8038c2b429932b122f6b631f00</span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>

The encoded calldata for this example is:

```text
0x2600019b40090000000000000000000000000000000000000000000000000000000000008a1932d6e26433f3037bd6c3a40c816222a6ccd40000c16ff286230000000000000000000000000000000000000000000000000091037ff36ab50000000000000000000000000000000000000000000000000de0b6b3a7640000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000061cd3e07fe7d7f6d4680e3e322986b7877f108dd00000000000000000000000000000000000000000000000000000000a036b1b90000000000000000000000000000000000000000000000000000000000000002000000000000000000000000d909178cc99d318e4d46e7e66a972955859670e10000000000000000000000001fc56b105c4f0a1a8038c2b429932b122f6b631f00
```

And that is it! You have everything you need to start crafting the XCM message itself! It has been a long journey, but we are almost there.

## Building the XCM Message from the Relay Chain {: #building-the-xcm-message-relay-chain }

We are almost in the last part of this tutorial! In this section, we'll craft the XCM message using the [Polkadot.js API](/builders/substrate/libraries/polkadot-js-api/){target=\_blank}. We'll also dissect the message instruction per instruction to understand what is happening every step of the way.

The XCM message we are about to build is composed of the following instructions:

 - [`WithdrawAsset`](/builders/interoperability/xcm/core-concepts/instructions/#withdraw-asset){target=\_blank} — takes funds from the account dispatching the XCM in the destination chain and puts them in holding, a special take where funds can be used for later actions
 - [`BuyExecution`](/builders/interoperability/xcm/core-concepts/instructions/#buy-execution){target=\_blank} — buy a certain amount of block execution time
 - [`Transact`](/builders/interoperability/xcm/core-concepts/instructions/#transact){target=\_blank} — use part of the block execution time bought with the previous instruction to execute some arbitrary bytes
 - [`DepositAsset`](/builders/interoperability/xcm/core-concepts/instructions/#deposit-asset){target=\_blank} — takes assets from holding and deposits them to a given account

To build the XCM message, which will initiate the remote EVM call through XCM, and get its SCALE encoded calldata, you can use the following snippet:

```js
import { ApiPromise, WsProvider } from '@polkadot/api'; // Version 10.13.1

// 1. Input Data
const providerWsURL =
  'wss://relay.api.moonbase.moonbeam.network';
const amountToWithdraw = BigInt(1 * 10 ** 16); // 0.01 DEV
const devMultiLocation = {
  parents: 0,
  interior: { X1: [{ PalletInstance: 3 }] },
};
const weightTransact = 40000000000n; // 25000 * Gas limit of EVM call
const multiLocAccount = '0x61cd3e07fe7d7f6d4680e3e322986b7877f108dd';
const transactBytes =
  '0x2600019b40090000000000000000000000000000000000000000000000000000000000008a1932d6e26433f3037bd6c3a40c816222a6ccd40000c16ff286230000000000000000000000000000000000000000000000000091037ff36ab50000000000000000000000000000000000000000000000000de0b6b3a7640000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000061cd3e07fe7d7f6d4680e3e322986b7877f108dd00000000000000000000000000000000000000000000000000000000a036b1b90000000000000000000000000000000000000000000000000000000000000002000000000000000000000000d909178cc99d318e4d46e7e66a972955859670e10000000000000000000000001fc56b105c4f0a1a8038c2b429932b122f6b631f00';

// 2. XCM Destination (Moonbase Alpha Parachain ID 1000)
const dest = { V4: { parents: 0, interior: { X1: [{ Parachain: 1000 }] } } };

// 3. XCM Instruction 1
const instr1 = {
  WithdrawAsset: [
    {
      id: devMultiLocation,
      fun: { Fungible: amountToWithdraw },
    },
  ],
};

// 4. XCM Instruction 2
const instr2 = {
  BuyExecution: {
    fees: {
      id: devMultiLocation,
      fun: { Fungible: amountToWithdraw },
    },
    weightLimit: { Unlimited: null },
  },
};

// 5. XCM Instruction 3
const instr3 = {
  Transact: {
    originKind: 'SovereignAccount',
    requireWeightAtMost: { refTime: weightTransact, proofSize: 700000n },
    call: {
      encoded: transactBytes,
    },
  },
};

// 6. XCM Instruction 4
const instr4 = {
  DepositAsset: {
    assets: { Wild: 'All' },
    beneficiary: {
      parents: 0,
      interior: { X1: [{ AccountKey20: { key: multiLocAccount } }] },
    },
  },
};

// 7. Build XCM Message
const message = { V4: [instr1, instr2, instr3, instr4] };

const generateCallData = async () => {
  // 8. Create Substrate API Provider
  const substrateProvider = new WsProvider(providerWsURL);
  const api = await ApiPromise.create({ provider: substrateProvider });

  // 9. Create the Extrinsic
  const tx = api.tx.xcmPallet.send(dest, message);

  // 10. Get SCALE Encoded Calldata
  const encodedCall = tx.toHex();
  console.log(`Encoded Calldata: ${encodedCall}`);

  api.disconnect();
};

generateCallData();
```

!!! note
    You can also get the SCALE encoded calldata by manually building the extrinsic in [Polkadot.js Apps](https://polkadot.js.org/apps/?rpc=wss://relay.api.moonbase.moonbeam.network#/extrinsics){target=\_blank}.

Let's go through each of the main components of the snippet shown above:

 1. Provide the input data for the call. This includes:
     - Moonbase Alpha relay chain endpoint URL to create the provider
     - Amount of tokens (in Wei) to withdraw from the Computed Origin account. For this example, `0.01` tokens are more than enough. To understand how to get this value, please refer to the [XCM fee page](/builders/interoperability/xcm/core-concepts/weights-fees/#moonbeam-reserve-assets){target=\_blank}
     - The [multilocation of the `DEV` token](/builders/interoperability/xcm/xc-registration/assets/#register-moonbeam-native-assets){target=\_blank} as seen by Moonbase Alpha
     - The weight for the `transact` XCM instruction. This can be obtained by multiplying `25000` and the gas limit obtained before. It is recommended to add approximately 10% more of the estimated value. You can read more about this value in the [Remote EVM Calls through XCM](/builders/interoperability/xcm/remote-execution/remote-evm-calls/#build-xcm-remote-evm){target=\_blank} page
     - The Computed Origin account as it will be needed later for an XCM instruction
     - The bytes for the `transact` XCM instruction that we calculated in the previous section
 2. Define the destination multilocation for the XCM message. In this case, it is the Moonbase Alpha parachain
 3. First XCM instruction, `WithdrawAsset`. You need to provide the asset multilocation and the amount you want to withdraw. Both variables were already described before
 4. Second XCM instruction, `BuyExecution`. Here, we are paying for Moonbase Alpha block execution time in `DEV` tokens by providing its multilocation and the amount we took out with the previous instruction. Next, we are buying all the execution we can (`Unlimited` weight) with `0.001 DEV` tokens which should be around 20 billion weight units, plenty for our example
 5. Third XCM instruction, `Transact`. The instruction will use a portion of the weight bought (defined as `requireWeightAtMost`) and execute the arbitrary bytes that are provided (`transactBytes`)
 6. Fourth XCM instruction, `DepositAsset`. Whatever is left in holding after the actions executed before (in this case, it should be only `DEV` tokens) is deposited to the Computed Origin account, set as the `beneficiary`.
 7. Build the XCM message by concatenating the instructions inside a `V2` array
 8. Create the [Polkadot.js API](/builders/substrate/libraries/polkadot-js-api/){target=\_blank} provider
 9. Craft the `xcmPallet.send` extrinsic with the destination and XCM message. This method will append the [`DescendOrigin`](/builders/interoperability/xcm/core-concepts/instructions/#descend-origin){target=\_blank} XCM instruction to our XCM message, and it is the instruction that will provide the necessary information to calculate the Computed Origin account
 10. Get the SCALE encoded calldata. Note that in this particular scenario, because we need the full SCALE encoded calldata, we have to use `tx.toHex()`. This is because we will submit this transaction using the calldata

!!! challenge
    Try a more straightforward example and perform a balance transfer from the Computed Origin account to any other account you like. You'll have to build the SCALE encoded calldata for a `balance.Transfer` extrinsic or create the Ethereum call as a balance transfer transaction.

Once you have the code set up, you can execute it with `node`, and you'll get the relay chain XCM calldata:

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>node build-xcm-message-swap.js</span>
    <span data-ty>Encoded Calldata: 0x450604630004000100a10f0410000400010403000f0000c16ff286231300010403000f0000c16ff286230006010700902f500982b92a00fd042600019b40090000000000000000000000000000000000000000000000000000000000008a1932d6e26433f3037bd6c3a40c816222a6ccd40000c16ff286230000000000000000000000000000000000000000000000000091037ff36ab50000000000000000000000000000000000000000000000000de0b6b3a7640000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000061cd3e07fe7d7f6d4680e3e322986b7877f108dd00000000000000000000000000000000000000000000000000000000a036b1b90000000000000000000000000000000000000000000000000000000000000002000000000000000000000000d909178cc99d318e4d46e7e66a972955859670e10000000000000000000000001fc56b105c4f0a1a8038c2b429932b122f6b631f000d01000001030061cd3e07fe7d7f6d4680e3e322986b7877f108dd</span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>

The encoded calldata for this example is:

```text
0x450604630004000100a10f0410000400010403000f0000c16ff286231300010403000f0000c16ff286230006010700902f500982b92a00fd042600019b40090000000000000000000000000000000000000000000000000000000000008a1932d6e26433f3037bd6c3a40c816222a6ccd40000c16ff286230000000000000000000000000000000000000000000000000091037ff36ab50000000000000000000000000000000000000000000000000de0b6b3a7640000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000061cd3e07fe7d7f6d4680e3e322986b7877f108dd00000000000000000000000000000000000000000000000000000000a036b1b90000000000000000000000000000000000000000000000000000000000000002000000000000000000000000d909178cc99d318e4d46e7e66a972955859670e10000000000000000000000001fc56b105c4f0a1a8038c2b429932b122f6b631f000d01000001030061cd3e07fe7d7f6d4680e3e322986b7877f108dd
```

Now that we have the SCALE encoded calldata, the last step is to submit the transaction, which will send our XCM message to Moonbase Alpha, and do the remote EVM call!

## Sending the XCM Message from the Relay Chain {: #send-xcm-message-relay-chain }

This section is where everything comes together and where the magic happens! Let's recap what we've done so far:

 - We've created a relay chain account that is funded with `UNIT` tokens (relay chain native tokens)
 - We determined its Computed Origin account on Moonbase Alpha and funded this new address with `DEV` tokens (Moonbase Alpha native token)
 - We obtained the Uniswap V2 swap calldata, in which we'll be swapping `0.01 DEV` token for `MARS`, an ERC-20 that exists in Moonbase Alpha. We had to modify a couple of fields to adapt it to this particular example
 - We built the SCALE encoded calldata in Moonbase Alpha to access its EVM via XCM
 - We crafted our transaction to send an XCM message to Moonbase Alpha, in which we will ask it to execute the SCALE encoded calldata that was previously built. This, in turn, will execute an EVM call which will perform the Uniswap V2 swap for the precious `MARS` tokens!

To send the XCM message that we built in the previous section, you can use the following code snippet:

```js
import { ApiPromise, WsProvider, Keyring } from '@polkadot/api'; // Version 10.13.1
import { cryptoWaitReady } from '@polkadot/util-crypto';

// 1. Input Data
const providerWsURL =
  'wss://relay.api.moonbase.moonbeam.network';
const MNEMONIC = 'INSERT_MNEMONIC'; // Not safe, only for testing
const txCall =
  '0x450604630004000100a10f0410000400010403000f0000c16ff286231300010403000f0000c16ff286230006010700902f500982b92a00fd042600019b40090000000000000000000000000000000000000000000000000000000000008a1932d6e26433f3037bd6c3a40c816222a6ccd40000c16ff286230000000000000000000000000000000000000000000000000091037ff36ab50000000000000000000000000000000000000000000000000de0b6b3a7640000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000061cd3e07fe7d7f6d4680e3e322986b7877f108dd00000000000000000000000000000000000000000000000000000000a036b1b90000000000000000000000000000000000000000000000000000000000000002000000000000000000000000d909178cc99d318e4d46e7e66a972955859670e10000000000000000000000001fc56b105c4f0a1a8038c2b429932b122f6b631f000d01000001030061cd3e07fe7d7f6d4680e3e322986b7877f108dd';

const sendXCM = async () => {
  // 2. Create Substrate API Provider
  const substrateProvider = new WsProvider(providerWsURL);
  const api = await ApiPromise.create({ provider: substrateProvider });

  // 3. Create Keyring Instance
  await cryptoWaitReady();
  const keyring = new Keyring({ type: 'sr25519' });
  const alice = keyring.addFromUri(MNEMONIC);

  // 4. Create the Extrinsic
  const tx = await api.tx(txCall).signAndSend(alice, (result) => {
    // 5. Check Transaction Status
    if (result.status.isInBlock) {
      console.log(
        `Transaction included in blockHash ${result.status.asInBlock}`
      );
    }
  });

  api.disconnect();
};

sendXCM();
```

Once you have the code set up, you can execute it with `node`, and the XCM message will be sent to initiate your Uniswap V2 swap in Moonbase Alpha:

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>node send-xcm-message-swap.js</span>
    <span data-ty="input">Transaction included in blockHash 0x4260e32a208dde976c704bb8b08eccd6cdd2cdd9796d79a572c40ba38ce48af6</span>
    <span data-ty="input"><span class="file-path"></span></span>
</div>

And that is it! You've sent an XCM message, which performed a remote EVM call via XCM and resulted in a Uniswap V2-styled swap in Moonbase Alpha. But let's go into more detail about what happened.

This action will emit different events. The first one is the only relevant [in the relay chain](https://polkadot.js.org/apps/?rpc=wss://relay.api.moonbase.moonbeam.network#/explorer/query/0x85cad5f3cef5d578f6acc60c721ece14842be332fa333c9b9eafdfe078bc0290){target=\_blank}, and it is named `xcmPallet.Sent`, which is from the `xcmPallet.send` extrinsic. In [Moonbase Alpha](https://polkadot.js.org/apps/?rpc=wss://wss.api.moonbase.moonbeam.network#/explorer/query/0x1f60aeb1f2acbc2cf6e19b7ad969661f21f4847f7b40457c459e7d39f6bc0779){target=\_blank}, the following events emitted by the `parachainSystem.setValidationData` extrinsic (where all the inbound XCM messages are processed) are of interest:

 - `parachainSystem.DownwardMessagesReceived` — states that there was an XCM message received
 - `evm.Log` — internal events emitted by the different contract calls. The structure is the same: contract address, the topics, and relevant data
 - `ethereum.Executed` — contains information on the `from` address, the `to` address, and the transaction hash of an EVM call done
 - `polkadotXcm.AssetsTrapped` — flags that some assets were in holding and were not deposited to a given address. If the `Transact` XCM instruction does not exhaust the tokens allocated to it, it will execute a [`RefundSurplus`](/builders/interoperability/xcm/core-concepts/instructions/#refund-surplus){target=\_blank} after the XCM is processed. This instruction will take any leftover tokens from the execution bought and put them in holding. We could prevent this by adjusting the fee provided to the `Transact` instruction, or by adding the instruction right after the `Transact`
 - `dmpQueue.ExecutedDownward` — states the result of executing a message received from the relay chain (a DMP message). In this case, the `outcome` is marked as `Complete`

Our XCM was successfully executed! If you visit [Moonbase Alpha Moonscan](https://moonbase.moonscan.io){target=\_blank} and search for [the transaction hash](https://moonbase.moonscan.io/tx/0x3fd96c5c7a82cd0b54c654f64d41879814d94a3ad9b66820f2be2fe7fc2a18eb){target=\_blank}, you'll find the Uniswap V2 swap that was executed via the XCM message.

!!! challenge
    Do a Uniswap V2 swap of `MARS` for any other token you want. Note that in this case, you'll have to remotely execute an ERC-20 `approve` via XCM first to allow the Uniswap V2 Router to spend the tokens on your behalf. Once the approval is done, you can send the XCM message for the swap itself.

<div class="page-disclaimer">
    This tutorial is for educational purposes only. As such, any contracts or code created in this tutorial should not be used in production.
</div>
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/tutorials/interoperability/using-axelar-sdk/
--- BEGIN CONTENT ---
---
title: Mint a Cross-Chain NFT with Axelar
description: In this step-by-step tutorial, you'll learn how to use the Axelar SDK to send a message from Moonbeam to another connected chain to remotely mint an NFT.
categories: Tutorials, GMP Providers
---

# Minting a Cross-Chain NFT with the Axelar SDK
_by Jeremy Boetticher & Kevin Neilson_

## Introduction {: #introduction }

Axelar’s [general message passing (GMP)](https://docs.axelar.dev/dev/general-message-passing/overview){target=\_blank} allows smart contracts to communicate securely across chains. This enables developers to build cross-chain connected applications on Moonbeam that can tap into functionality from Polkadot, Ethereum, Avalanche, Cosmos, and beyond. In this tutorial, we'll introduce the JavaScript SDK package Axelar packed with tools to aid developers in this cross-chain vision.

The [AxelarJS SDK](https://github.com/axelarnetwork/axelarjs-sdk){target=\_blank}  allows developers to estimate fees, track and recover transactions, and quickly transfer tokens. To show off some of the SDK's tools, we will walk through a demo that deploys an NFT that can be minted across chains. Before following along with the tutorial, you may wish to first familiarize yourself with this [Overview of Axelar](/builders/interoperability/protocols/axelar/){target=\_blank}.

In this tutorial, we'll mint an NFT on a remote chain by using Axelar to send a specific message to trigger the mint. We'll be using the AxelarJS SDK in conjunction with a minting script that will define the parameters of the cross-chain mint, such as the destination chain, destination contract address, and more.
 
<div class="intro-disclaimer">
  The information presented herein is for informational purposes only and has been provided by third parties. Moonbeam does not endorse any project listed and described on the Moonbeam docs website (https://docs.moonbeam.network/).
</div>

## Axelar Refresher {: #axelar-refresher }

[Axelar](https://www.axelar.network){target=\_blank} is a blockchain that connects blockchains, delivering secure cross-chain communication. Every validator in Axelar’s network runs light nodes on chains that Axelar supports. In this demo, we'll interact with two Axelar contracts, one of which is the [Axelar Gateway contract](https://github.com/axelarnetwork/axelar-cgp-solidity/blob/main/contracts/AxelarGateway.sol){target=\_blank}. The dynamic validator set uses this contract to monitor activity on each chain. Their role is crucial for achieving consensus, ensuring that messages are accurately transmitted from one chain to another

![Axelar Diagram](/images/tutorials/interoperability/axelar-sdk/axelar-1.webp)

The other contract we will be working with is the [Axelar Gas Receiver microservice](https://docs.axelar.dev/learn#gas-receiver){target=\_blank}. Whenever you use the Axelar Gateway to send a cross-chain transaction, the Gas Receiver lets you pay for the subsequent transaction on the destination chain. Although not mandatory, this feature enables the end user to send just a single transaction. This transaction automatically updates the destination chain and allows all transaction fees to be paid using the source-chain token already held by the user.

## Building the Cross-Chain NFT Contract {: #building-the-cross-chain-nft-contract } 

We'll be deploying a [simple contract](https://github.com/jboetticher/axelar-sdk-demo/blob/main/contracts/CrossChainNFT.sol){target=\_blank} that can only mint an NFT if it receives a specific cross-chain message. Minting the NFT will require a token payment, which will be wrapped DEV (Moonbase Alpha’s native currency). A wrapped token for a native currency like DEV will mint one ERC-20 WDEV token for each DEV sent to it, and gives the option to redeem one WDEV token for one DEV. Using WDEV instead of native DEV is required because Axelar requires all tokens sent to be ERC-20s.

So to mint in the cross-chain message, it must receive at least 0.05 WDEV.

We’re putting the same contract on two chains, so it must send and receive messages. From a high level, our contract does two things:

1. Send an encoded address message with WDEV across chains via Axelar’s Gateway with the option to pay for its gas on the destination chain
2. Receive an encoded address message from Axelar, and execute only if it received at least 0.05 WDEV

You’ll be using a Hardhat project, but before we set it up, let’s first take a look at a few parts of the contract. I encourage you to follow along!

Contracts executed by the Axelar Gateway, like ours here, inherit from [`IAxelarExecutable`](https://github.com/axelarnetwork/axelar-gmp-sdk-solidity/blob/main/contracts/executable/AxelarExecutable.sol){target=\_blank}. This parent contract has two overridable functions, `_execute` and `_executeWithToken`, that allow developers to change the logic when a contract receives a contract call from the Axelar Gateway. Both functions have the same inputs, but `_executeWithToken` also includes `tokenSymbol` and `amount` to describe the token being sent cross-chain.

Now let’s finally take a look at our mint function. It takes three inputs: a destination address, a destination chain, and the amount of WDEV to send. Remember that this mint function is called on the origin chain (Moonbase Alpha), which mints an NFT on a different destination chain.

???+ code "mintXCNFT function"

    ```solidity
    function mintXCNFT(
    string memory destinationAddress,
    string memory destinationChain,
    uint256 amount
) external payable {
    // Create the payload
    bytes memory payload = abi.encode(msg.sender);
    
    // Takes WDEV from the user and puts them into this contract for the Gateway to take        
    wDev.transferFrom(msg.sender, address(this), amount);
    wDev.approve(address(gateway), amount);

    // Pay for gas
    // This is a gas service SPECIFICALLY for sending with token
    gasService.payNativeGasForContractCallWithToken{value: msg.value}(
        address(this),
        destinationChain,
        destinationAddress,
        payload,
        "WDEV",
        amount,
        msg.sender
    );

    // Call remote contract
    gateway.callContractWithToken(
        destinationChain,
        destinationAddress,
        payload,
        "WDEV",
        amount
    );
}
    ```

The logic itself has three steps. First, it takes WDEV from the caller. The caller must approve our NFT contract to transfer their WDEV beforehand. Then, our NFT contract approves the gateway to transfer the WDEV from the caller since the gateway contract will try to transfer the tokens from our NFT contract in the final step.

Next, to pay for gas on the destination chain, we make use of the [`IAxelarGasService` contract](https://github.com/axelarnetwork/axelar-cgp-solidity/blob/main/contracts/interfaces/IAxelarGasService.sol){target=\_blank}. This contract has many [different configurations to pay for gas](https://docs.axelar.dev/dev/gas-service/pricing){target=\_blank}, like paying for [`execute`](https://github.com/axelarnetwork/axelar-gmp-sdk-solidity/blob/main/contracts/executable/AxelarExecutable.sol#L17-L29){target=\_blank} versus [`executeWithToken`](https://github.com/axelarnetwork/axelar-gmp-sdk-solidity/blob/main/contracts/executable/AxelarExecutable.sol#L31-L53){target=\_blank} or using an ERC-20 token as payment versus using native currency. Be careful if you plan on writing your own contract later!

In this case, since the origin chain is Moonbase Alpha, the native currency is DEV. We can use native DEV to pay for gas on the destination chain based on the conversion rates between Moonbase Alpha’s native currency and the destination chain’s native currency. Since we’re sending a contract call that includes a token to pay for destination gas in DEV, we will be using the `payNativeGasForContractCallWithToken` function.

Finally, we call the gateway to send our cross-chain message with `callContractWithToken.` Notice that the payload (generic data that sent in a cross-chain call) that we’re sending is just the caller’s address. This data will need to be decoded by the destination contract.

Now let’s take a look at what happens on the destination chain. Since we expect tokens to be sent as payment for an NFT mint, we will override `_executeWithToken` from `IAxelarExecutable.`

???+ code "executeWithToken function"

    ```solidity
    // Mints the NFT for the user
function _executeWithToken(
    string memory, /*sourceChain*/
    string memory, /*sourceAddress*/
    bytes calldata payload,
    string memory tokenSymbol,
    uint256 amount
) internal override {
    require(
        keccak256(abi.encodePacked(tokenSymbol)) == keccak256("WDEV"),
        "Only WDEV is accepted"
    );
    require(amount >= 0.05 ether, "Not enough to mint!");

    address user = abi.decode(payload, (address));

    _mint(user, currentNFTID);
    currentNFTID++;
}
    ```

In our implementation of `_executeWithToken`, we first check to ensure that the `tokenSymbol` provided by Axelar is “WDEV”. Then we expect 0.05 WDEV tokens for payment and will revert if any other token or anything less than 0.05 WDEV gets sent. Afterwards, we decode the payload to get the address of the origin chain’s caller so that we can mint an NFT to that address. Finally, we finish the minting!

You can find the full code for the `CrossChainNFT.sol` below.

??? code "CrossChainNFT.sol"

    ```solidity
    // SPDX-License-Identifier: MIT

pragma solidity ^0.8.9;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@axelar-network/axelar-gmp-sdk-solidity/contracts/interfaces/IAxelarGasService.sol";
import { AxelarExecutable } from '@axelar-network/axelar-gmp-sdk-solidity/contracts/executable/AxelarExecutable.sol';

// Allows users to mint an NFT, but only cross chain
contract CrossChainNFT is ERC721, AxelarExecutable {
    constructor(
        address _gateway,
        IAxelarGasService _gasService,
        IERC20 _wDev
    ) ERC721("Cross Chain NFT", "XCNFT") AxelarExecutable(_gateway) {
        gasService = _gasService;
        wDev = _wDev;
    }

    uint256 currentNFTID;
    IAxelarGasService gasService;
    IERC20 wDev;

    // Mints the NFT for the user
    function _executeWithToken(
        string memory, /*sourceChain*/
        string memory, /*sourceAddress*/
        bytes calldata payload,
        string memory tokenSymbol,
        uint256 amount
    ) internal override {
        require(
            keccak256(abi.encodePacked(tokenSymbol)) == keccak256("WDEV"),
            "Only WDEV is accepted"
        );
        require(amount >= 0.05 ether, "Not enough to mint!");

        address user = abi.decode(payload, (address));

        _mint(user, currentNFTID);
        currentNFTID++;
    }

    function mintXCNFT(
        string memory destinationAddress,
        string memory destinationChain,
        uint256 amount
    ) external payable {
        // Create the payload
        bytes memory payload = abi.encode(msg.sender);
        
        // Takes WDEV from the user and puts them into this contract for the Gateway to take        
        wDev.transferFrom(msg.sender, address(this), amount);
        wDev.approve(address(gateway), amount);

        // Pay for gas 
        // This is a gas service SPECIFICALLY for sending with token
        gasService.payNativeGasForContractCallWithToken{value: msg.value}(
            address(this),
            destinationChain,
            destinationAddress,
            payload,
            "WDEV",
            amount,
            msg.sender
        );

        // Call remote contract
        gateway.callContractWithToken(
            destinationChain,
            destinationAddress,
            payload,
            "WDEV",
            amount
        );
    }
}
    ```

## Setting Up the Repository {: #setting-up-the-repository} 

Make sure to clone the [GitHub repository](https://github.com/jboetticher/axelar-sdk-demo/tree/main){target=\_blank} for this tutorial. We need to install some dependencies, including Hardhat, OpenZeppelin contracts, some Axelar contracts, and the Axelar SDK. To configure the dependencies properly, run the following command:

```bash
npm install
```

The repository contains two Solidity files. The first file is the `CrossChainNFT` as expected, and the second is an Axelar library `StringAddressUtils.sol` that doesn’t have an npm package yet but is still required for the Hardhat implementation.

There are also four Hardhat scripts within the repository’s scripts folder.

- `axelarStatus.js` - a Hardhat task that lets you view information about Axelar transactions
- `deploy.js` - deploys the `CrossChainNFT` to the network provided by Hardhat
- `gatewayGasReceiver.js` - returns hardcoded values for Axelar’s Gateway and gas service contracts
- `mint.js` - mints the `CrossChainNFT` (only run on Moonbase Alpha)

Before we get into the fun part, you will need to get an account with a [private key funded with DEV](https://faucet.moonbeam.network){target=\_blank} to deploy the contract and sign all future transactions. Place this within a `secrets.json` file within the repository’s main directory. You should format it as follows:

```json
{
    "privateKey": "INSERT_PRIVATE_KEY"
}
```

If everything goes well, you will be able to compile correctly:

```bash
npx hardhat compile
```

## Deploying the Cross-Chain Contract to Moonbase Alpha {: #deploying-the-cross-chain-contract-to-moonbase-alpha}

This demo focuses on using the scripts, so it’s best to take a look at them, starting with `deploy.js`, which is similar to the [Ethers.js tutorial deployment contracts](/builders/ethereum/libraries/ethersjs/#deploy-contract-script){target=\_blank}.

`gatewayGasReceiver.js` stores many of the contract addresses in this repo, which are necessary for the deployment. You likely will not have to change any of the hardcoded addresses. Try deploying your contract to the origin chain:

```bash
npx hardhat run scripts/deploy.js --network moonbase
```

You should see the address deployed and printed in the console. Be sure to copy it! You will need it to interact with the next script. You also need to deploy it to the destination chain. The choice of which destination network to use is up to you, but you will need its native currency to deploy. I’ve included some of the available networks and their faucets here:

|                                 Network                       |       Faucet        |                   Deployment Command                   |
|:------------------------------------------------------------------------:|:----------:|:------------------------------------------------------:|
| Sepolia |      [Faucet Link](https://sepolia-faucet.pk910.de){target=\_blank}        | <pre>```npx hardhat run scripts/deploy.js --network sepolia```</pre> |
|  Polygon Mumbai |   [Faucet Link](https://faucet.polygon.technology){target=\_blank}   |  <pre>```npx hardhat run scripts/deploy.js --network mumbai```</pre>  |
| Avalanche Fuji |  [Faucet Link](https://core.app/tools/testnet-faucet){target=\_blank} |   <pre>```npx hardhat run scripts/deploy.js --network fuji```</pre>   |
|   Fantom TestNet |    [Faucet Link](https://faucet.fantom.network){target=\_blank}     |  <pre>```npx hardhat run scripts/deploy.js --network fantom```</pre>  |

After running a deployment command, you'll see output like the below. Be sure to copy the destination chain's contract address because you'll need to provide that later. 

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>npx hardhat run scripts/deploy.js --network moonbase</span>
    <br>
    <span data-ty>Compiled 1 Solidity file successfully</span>
    <span data-ty>Nothing to compile</span>
    <span data-ty>Deployed CrossChainNFT on moonbase at: 0xB1972a5487A0Af15C47d321f25E25E8E3c3e8462</span>
</div>

## Building the Mint.js Script {: #building-the-mint-js-script}

The minting contract is quite exciting and will require Axelar’s SDK. At the top of the `mint.js` script, Ethers.js is initialized in a Hardhat script. The Axelar SDK is also initialized. There are multiple Axelar APIs available in the SDK, but in this case we will only be using the [Axelar Query API](https://docs.axelar.dev/dev/axelarjs-sdk/axelar-query-api#axelar-query-api){target=\_blank} since it includes all of the gas estimation functionality that we’ll need for paying gas fees across chains.

```js
const ethers = hre.ethers;
const axelarSDK = new AxelarQueryAPI({
  environment: Environment.TESTNET,
});
```

There are also some constants for you to change right after. This walkthrough is using Fantom as the destination chain, but you can use whichever chains you deployed to. Note that even though we’re using a TestNet environment, Axelar refers to [the chain names](https://docs.axelar.dev/dev/reference/testnet-contract-addresses){target=\_blank} by their MainNet equivalents, hence why the origin chain is `moonbeam` and not `moonbase.`

```js
const ORIGIN_CHAIN = 'moonbeam';
const DESTINATION_CHAIN = 'ethereum-sepolia';
// Address of CrossChainNFT printed in the console after running deploy script
const ORIGIN_CHAIN_ADDRESS = 'INSERT_CONTRACT_ADDRESS';
// Address of AxelarAcceptEverything.sol on Sepolia, you can change this 
// contract address to your own AxelarAcceptEverything.sol contract 
const DESTINATION_CHAIN_ADDRESS = '0x89f801C7DB23439FDdBad4f913D788F13d1d7494';
```

Next, we have to work with wrapped DEV to send across chains. First, we must wrap our DEV, and then we approve the contract on the origin chain to take some of our WDEV. This is necessary because the origin chain’s contract has to send your WDEV to pay for minting the NFT on the destination chain.

Note here that instead of hardcoding the WDEV contract address, we’re using the `IAxelarGateway` contract to find the address. We could have also done this in the smart contract, but I wanted to show off how you would do it with Ethers.js. As expected, we sign two transactions: first to wrap 0.13 WDEV, then to approve our `CrossChainNFT` contract to send that WDEV.

You may be wondering why we’re wrapping 0.13 WDEV when the price of the mint is only 0.05. At the time of writing, Axelar collects a small fee (0.08 WDEV in this case) when transferring tokens between networks, which can be calculated on their website. Gateways do this automatically, but this responsibility may be delegated to the `IAxelarGasService`contract in the future.

```js
const MOONBASE_WDEV_ADDRESS = await gateway.tokenAddresses('WDEV');

// Wrap + Approve WDEV to be used by the NFT contract
// wrap => transfer to contract => contract transfers to Gateway
const wDEVPayment = ethers.utils.parseUnits('0.13', 'ether');
const wDEV = await ethers.getContractAt('WETH9', MOONBASE_WDEV_ADDRESS);

const wrapTx = await wDEV.deposit({ value: wDEVPayment });
console.log('Wrap transaction hash: ', wrapTx.hash);

const approveTx = await wDEV.approve(ORIGIN_CHAIN_ADDRESS, wDEVPayment);
console.log('Approve transaction hash: ', approveTx.hash);

console.log('Awaiting transaction confirmations...');
await ethers.provider.waitForTransaction(approveTx.hash, 1);
```

Now we have to estimate the amount of DEV that we send to the `mintXCNFT` function to pay for gas on the destination chain. This is where the Axelar SDK kicks in.

We must estimate the amount of gas to spend on the destination chain because it is difficult to estimate a function that can only be called by a specific contract. In this case, we overestimate the amount of gas we will spend as `400,000`. In an actual production environment, you should benchmark the amount of gas that you spend. However, if you do end up overestimating by a lot, you will get refunded by Axelar’s gas services.

The estimateGasFee function provided by the Axelar SDK will find the conversion between the origin chain’s native currency and the destination chain’s native currency to find the right amount to send to the destination chain.

You, the astute reader, might wonder why we’re using `GLMR` instead of `DEV`. Similar to how Axelar uses the MainNet chain names instead of using the TestNet names, Axelar will interpret `GLMR` as `DEV` since we’re using the TestNet environment.

```js
const estimateGasUsed = 400000;
const gasFee = await axelarSDK.estimateGasFee(
  ORIGIN_CHAIN,
  DESTINATION_CHAIN,
  GasToken.GLMR,
  estimateGasUsed
);
const gasFeeToHuman = ethers.utils.formatEther(ethers.BigNumber.from(gasFee));
console.log(`Cross-Chain Gas Fee: ${gasFee} Wei / ${gasFeeToHuman} Ether`);
```

Calling this function from the SDK will return a string representing the amount of DEV WEI to pay, like `241760932800000`. That’s hard for us simple humans to understand, so we use Ethers.js to convert it into a more human-readable version to print to the console later.

```js
const gasFeeToHuman = ethers.utils.formatEther(ethers.BigNumber.from(gasFee));
```

Finally, we call the `mintXCNFT` contract function. The important takeaway here is that we’re sending the gas fee not as a gas limit but as value. Ethers.js can calculate how much gas to send on the origin chain. However, to pay for the destination chain, we have to calculate with the Axelar SDK and send it as value to the `IAxelarGasReceiver` contract.

```js
// Begin the minting
const mintRes = await nft.mintXCNFT(
  DESTINATION_CHAIN_ADDRESS,
  DESTINATION_CHAIN,
  wDEVPayment,
  { value: gasFee }
);
console.log('Minting transaction hash: ', mintRes.hash);
```

That’s the entire script! Before we run the script, check again to make sure that the four constants (`ORIGIN_CHAIN`, `DESTINATION_CHAIN`, `ORIGIN_CHAIN_ADDRESS`, `DESTINATION_CHAIN_ADDRESS`) at the top of the script are set correctly.

Here’s the command to mint your NFT!

```bash
npx hardhat run scripts/mint.js --network moonbase
```

The console should output something similar to this:

<div id="termynal" data-termynal>
    <span data-ty="input"><span class="file-path"></span>npx hardhat run scripts/mint.js --network moonbase</span>
    <br>
    <span data-ty>Nothing to compile</span>
    <span data-ty>Wrap transaction hash:  0x89bd6c42c9b7791ce51a0ef74e83fa46fc063eefcd838def3664cb12970156cd</span>
    <br>
    <span data-ty>Approve transaction hash:  0x1594d43444d1f8abdadcab78098452d8b25a9eed72c89597c1b9822b5a8e1605</span>
    <br>
    <span data-ty>Awaiting transaction confirmations...</span>
    <span data-ty>Cross-Chain Gas Fee: 1694247418108372848 Wei / 1.694247418108372848 Ether</span>
    <span data-ty>Minting transaction hash:  0x9daa8c762dc3c60c5ef009486fbd6c4e91baa55baec79db2be6e7d10cfc06c4c</span>
</div>

The most important data here is the minting transaction because that’s how you track your transaction's status. So don’t lose it! But if you do, you can look at all of the recent transactions on [Axelar’s TestNet scanner](https://testnet.axelarscan.io){target=\_blank}.

## Viewing Axelar Transaction Status {: #viewing-axelar-transaction-status}

Axelar has a [TestNet explorer](https://testnet.axelarscan.io/gmp/search){target=\_blank}, and a successful transaction for the interaction you just completed would look something like this:

![Viewing Transaction status on AxelarScan](/images/tutorials/interoperability/axelar-sdk/axelar-2.webp)

It's a good idea to try out the SDK to view the status of your transactions because it gives more information about your transaction and any possible errors. To do this, I wrote a Hardhat task for us to use. You can view the code in `axelarStatus.js`, but we’ll take a dive here too.

The main meat of the code is in these five lines. First, we initialize the SDK module that we will be using, the `AxelarGMPRecoveryAPI`. Unlike the `AxelarQueryAPI` that we used in the minting script, the `AxelarGMPRecoveryAPI` helps track and recover stalled transactions. Next, we have to query the transaction status, and the SDK takes care of it for us.

```js
const sdk = new AxelarGMPRecoveryAPI({
  environment: Environment.TESTNET,
});
const txStatus = await axelarSDK.queryTransactionStatus(txHash);
console.log(txStatus);
```

You can learn a bit more about the `AxelarGMPRecoveryAPI` in [Axelar’s documentation](https://docs.axelar.dev/dev/axelarjs-sdk/tx-status-query-recovery){target=\_blank}. It includes additional functionality in case a transaction goes wrong, especially if there isn’t enough gas sent along with the cross-chain transaction.

The `axelarStatus.js` file is configured as a Hardhat task rather than a script, which means that the command to run it will differ slightly from the command style required to execute a script. Be sure to note these differences and carefully craft the below command, replacing `INSERT_TRANSACTION_HASH` with the transaction of hash on the origin chain that you sent a cross-chain message in:

```bash
npx hardhat axelarStatus --tx INSERT_TRANSACTION_HASH
```

If you run the Hardhat script, you’ll end up with something like this in your console (I didn’t include all of it since it’s so large). You’re likely most interested in the status, where a list of possible ones is in [Axelar’s documentation](https://docs.axelar.dev/dev/axelarjs-sdk/tx-status-query-recovery#query-transaction-status-by-txhash){target=\_blank}. You’re looking for `destination_executed` to indicate that it was received and executed correctly, but if you’re too early you might find `source_gateway_called` or `destination_gateway_approved`.

<div id="termynal" data-termynal>
    <span data-ty>Status: 'source_gateway_called'</span>
    <span data-ty>Error: undefined</span>
    <span data-ty>Total Time Spent: { total: 39 }</span>
    <br>         
    <span data-ty>Gas Paid Info:</span>
    <span data-ty>Status: 'gas_paid'</span>
    <span data-ty>Block Hash: '0x4e9ec37b8ebfb2acb7180aff401493dfb3025439c42225c2908f984b54131baa'</span>
    <span data-ty>Chain: 'moonbeam'</span>
    <span data-ty>Address: '0xbE406F0189A0B4cf3A05C286473D23791Dd44Cc6'</span>
    <span data-ty>Transaction Hash: '0xeb3dc836b890bded6c9e9ce103cdbac69843c55fb19ade1771936d44b3bb9151'</span>
    <span data-ty>Event: 'NativeGasPaidForContractCallWithToken'</span>
    <span data-ty>Event Signature: 'NativeGasPaidForContractCallWithToken(address,string,string,bytes32,string,uint256,uint256,address)'</span>
    <span data-ty>Transaction Index: 0</span>
    <span data-ty>Event Index: 2</span>
    <span data-ty>Block Number: 7963797</span>
    <span data-ty>Block Timestamp: 1721782902</span>
    <br>
    <span data-ty>Call Transaction Details:</span>
    <span data-ty>Chain: 'moonbeam'</span>
    <span data-ty>Contract Address: '0x5769D84DD62a6fD969856c75c7D321b84d455929'</span>
    <span data-ty>Transaction Hash: '0xeb3dc836b890bded6c9e9ce103cdbac69843c55fb19ade1771936d44b3bb9151'</span>
    <span data-ty>Block Number: 7963797</span>
    <span data-ty>Log Index: 4</span>
    <span data-ty>Event: 'ContractCallWithToken'</span>
    <span data-ty>Sender: '0x1AE99204240C92DE9B01207Ed5dF777E4e738e05'</span>
    <span data-ty>Destination Chain: 'ethereum-sepolia'</span>
    <span data-ty>Destination Contract Address: '0x89f801C7DB23439FDdBad4f913D788F13d1d7494'</span>
    <span data-ty>Payload Hash: '0x4af6b315b6befdc046499484184d0fe2f273e733bfdb5927aeb5872b8a3761f7'</span>
    <span data-ty>Symbol: 'WDEV'</span>
    <span data-ty>Amount: '130000000000000000'</span>
    <br>
    <span data-ty>Transaction Receipt Details:</span>
    <span data-ty>Block Hash: '0x4e9ec37b8ebfb2acb7180aff401493dfb3025439c42225c2908f984b54131baa'</span>
    <span data-ty>Transaction Index: 0</span>
    <span data-ty>Gas Used: 813360</span>
    <span data-ty>Status: 1</span>
    <span data-ty>From: '0x3b939fead1557c741ff06492fd0127bd287a421e'</span>
    <span data-ty>To: '0x1ae99204240C92DE9B01207Ed5dF777E4e738e05'</span>
    <span data-ty>Effective Gas Price: 125000000</span>
</div>

You can learn more about debugging contracts in [Axelar’s documentation](https://docs.axelar.dev/dev/general-message-passing/debug/error-debugging){target=\_blank}, where they go into depth on specific error messages and how to use tools like Tenderly for logic errors.

## Conclusion {: #conclusion}

You’re well on your way to creating your own connected contracts with Axelar! Learn more about Axelar on their [docs site](https://docs.axelar.dev){target=\_blank}, and read about how Moonbeam is shaping up to be the leader in blockchain interoperability in our introduction to connected contracts. For more information on the AxelarJS SDK, be sure to check out the [Axelar Docs](https://docs.axelar.dev/dev/axelarjs-sdk/intro){target=\_blank}.

<div class="page-disclaimer">
    This tutorial is for educational purposes only. As such, any contracts or code created in this tutorial should not be used in production.
</div>

<div class="page-disclaimer">
  The information presented herein has been provided by third parties and is made available solely for general information purposes. Moonbeam does not endorse any project listed and described on the Moonbeam Doc Website (https://docs.moonbeam.network/). Moonbeam Foundation does not warrant the accuracy, completeness or usefulness of this information. Any reliance you place on such information is strictly at your own risk. Moonbeam Foundation disclaims all liability and responsibility arising from any reliance placed on this information by you or by anyone who may be informed of any of its contents. All statements and/or opinions expressed in these materials are solely the responsibility of the person or entity providing those materials and do not necessarily represent the opinion of Moonbeam Foundation. The information should not be construed as professional or financial advice of any kind. Advice from a suitably qualified professional should always be sought in relation to any particular matter or circumstance. The information herein may link to or integrate with other websites operated or content provided by third parties, and such other websites may link to this website. Moonbeam Foundation has no control over any such other websites or their content and will have no liability arising out of or related to such websites or their content. The existence of any such link does not constitute an endorsement of such websites, the content of the websites, or the operators of the websites. These links are being provided to you only as a convenience and you release and hold Moonbeam Foundation harmless from any and all liability arising from your use of this information or the information provided by any third-party website or service.
</div>
--- END CONTENT ---

## Basics Concepts [shared: true]

The following section contains foundational documentation shared across all Moonbeam products.
It describes the architecture and infrastructure that serve as the backbone for all integrations built with Moonbeam.
This includes the network development framework, Substrate and EVM development tools, developer tooling, and guidance for node operators.
This context is provided to help understand how the system works under the hood, but responses should stay focused on the specific product unless the user explicitly asks about the general architecture.

---

## List of shared concept pages:


## Full content for shared concepts:

Doc-Content: https://docs.moonbeam.network/learn/core-concepts/balances/
--- BEGIN CONTENT ---
---
title: Account Balances
description: A description of the main differences that Ethereum developers need to understand in terms of account balances on Moonbeam and how they differ from Ethereum.
categories: Basics
---

# Moonbeam Account Balances

## Introduction {: #introduction }

While Moonbeam strives to be compatible with Ethereum's Web3 API and EVM, there are some important Moonbeam differences that developers should know and understand in terms of account balances.

One of the design goals of Moonbeam is to create an environment that is as close as possible to Ethereum, and to offer a set of Web3 RPC endpoints that are compatible with Ethereum. However, Moonbeam is also a Substrate based chain, which means that it exposes Substrate RPCs, and that it has integral functionality that is powered by Substrate such as Staking, Governance, and other features which are not part of the Ethereum API.

Moonbeam [unified accounts](/learn/core-concepts/unified-accounts/){target=\_blank} are one way that Moonbeam achieves Ethereum compatibility, by changing the underlying account type in the protocol to be Ethereum-like (H160 or 20 byte addresses starting with `0x`). Unified accounts are used by both the Substrate and Ethereum APIs, and map to the same underlying data storage on the blockchain. Nevertheless, there are important differences that users coming from Ethereum should understand when using Moonbeam accounts via the Ethereum API.

This guide will outline some of these main differences and what to expect when using Moonbeam for the first time.

## Ethereum Account Balances {: #ethereum-account-balances }

An account on Ethereum is an entity with a token balance (Ether or ETH in this case). Account-holders can send Ether transactions on Ethereum and accounts can be controlled by either users (with the private key for signing) or smart contracts.

Therefore, Ethereum has two main types of accounts: user-owned and contract-owned. No matter the type, an Ethereum account has a single balance field that represents the number of Wei owned by this address, where Wei is a denomination of ETH (1 x 10^18 Wei per ETH).

![Ethereum balances diagram](/images/learn/core-concepts/balances/balances-1.webp)

## Moonbeam Account Balances {: #moonbeam-account-balances }

An account on Moonbeam is also an entity with a token balance (the token will depend on the network). Like on Ethereum, account holders can send token transactions on the Moonbeam Network they are connected to. In addition, accounts can be controlled by users (with the private key for signing) or smart contracts.

As with Ethereum, there are two main types of accounts: user-owned and contract owned. However, on Moonbeam, within both account types, there are also [proxy accounts](https://wiki.polkadot.com/learn/learn-proxies/){target=\_blank}, which can perform a limited number of actions on behalf of another account. In terms of balances, all of Moonbeam account types have five (5) different [balance types](https://wiki.polkadot.com/learn/learn-accounts/#balance-types#balance-types){target=\_blank}:

 - **Free** — refers to the balance that can be used (not locked/frozen) from the Substrate API. The concept of `free` balance depends on the action to be executed. For example, voting in democracy will not subtract the allocated balance to the vote from `free` balance, but token holders won't be able to transfer that balance
 - **Reducible** — refers to the balance that can be used (not locked/frozen) through the Ethereum API on Moonbeam. For example, this is the balance displayed by MetaMask. It is the real spendable balance, accounting for all democracy locks (displayed as transferable in Polkadot.js Apps)
 - **Reserved** — refers to the balance held due to on-chain requirements, and that can be freed by performing some on-chain action.  For example, bonds for creating a proxy account or setting an on-chain identity are shown as `reserved balance`. These funds are **not** transferable or accessible via the Ethereum API until they are freed
 - **Misc frozen** — represents a balance that the `free` balance may not drop below when withdrawing funds, except for transaction fee payment. For example, funds being used to vote on a governance proposal are shown as `misc frozen`. These funds are **not** transferable or accessible via the Ethereum API until they are freed
 - **Fee frozen** — represents a balance that the `free` balance may not drop below when specifically paying for transaction fees. These funds are **not** transferable or accessible via the Ethereum API until they are freed

![Moonbeam balances diagram](/images/learn/core-concepts/balances/balances-2.webp)

### Calculating Your Transferable Balance {: #calculating-your-transferable-balance }

An account's transferable or spendable balance can be calculated as the free balance minus the maximum of `0` or the difference between frozen and reserved tokens: 

```text
Transferable = free - max(0, frozen - reserved )
```

Here are two examples of calculating transferable balances:

An account has `1000` free tokens, `200` frozen tokens, and `50` reserved tokens. The transferable balance is calculated as:

```text
Transferable = 1000 - max(0, 200 - 50) = 1000 - 150 = 850
```

If the frozen tokens are less than the reserved tokens, with `1000` free tokens, `100` frozen tokens, and `150` reserved tokens, the transferable balance would be:

```text
Transferable = 1000 - max(0, 100 - 150) = 1000 - 0 = 1000
```

### Retrieve Your Balance {: #retrieve-your-balance }

You can check on your balances, including your free (or transferable) and reserved balances (if exists), using the [Polkadot.js API](/builders/substrate/libraries/polkadot-js-api/){target=\_blank}.

!!! note
    To test out the examples in this guide on Moonbeam or Moonriver, you will need to have your own endpoint and API key, which you can get from one of the supported [Endpoint Providers](/builders/get-started/endpoints/){target=\_blank}.

```js
import { ApiPromise, WsProvider } from '@polkadot/api';

const wsProvider = new WsProvider('wss://wss.api.moonbase.moonbeam.network');

const main = async () => {
  const polkadotApi = await ApiPromise.create({
    provider: wsProvider,
  });

  const balances = await polkadotApi.query.system.account('INSERT_ADDRESS');
  console.log(balances.toHuman());
};

main();
```

You can also retrieve your balance locks using the Polkadot.js API.

```js
import { ApiPromise, WsProvider } from '@polkadot/api';

const wsProvider = new WsProvider('wss://wss.api.moonbase.moonbeam.network');

const main = async () => {
  const polkadotApi = await ApiPromise.create({
    provider: wsProvider,
  });

  const locks = await polkadotApi.query.balances.locks('INSERT_ADDRESS');
  console.log(locks.toHuman());
};

main();
```

## Main Differences {: #main-differences }

The main difference between account balances on Ethereum and Moonbeam lies in the concept of locked and reserved balance on Moonbeam. These are tokens that are still owned by that account, but they are not spendable (yet).

From the Ethereum's API perspective, an account might show that it has a certain balance (called `reducible` balance). However, after an on-chain action, this value might increase (or decrease) without an actual balance transfer.

It is important to note that the account and behavior differences described here apply to account balances with the base asset (GLMR, MOVR) only and the balances of that asset that aren't interacting with smart contracts. As soon as a Moonbeam account balance is interacting with smart contracts, the behavior will be the same as Ethereum behavior. For example, if you wrap MOVR on Moonriver there is no way for the underlying balance to change via staking or governance actions, because that is part of the storage of the contract. In this case the reducible balance of that account has been committed to the wrapped MOVR smart contract and can't be modified by Substrate actions.
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/learn/core-concepts/consensus-finality/
--- BEGIN CONTENT ---
---
title: Consensus & Finality
description: The main differences that Ethereum developers should understand in terms of consensus and finality on Moonbeam and how it differs from Ethereum.
categories: Basics
---

# Moonbeam Consensus & Finality

## Introduction {: #introduction }

While Moonbeam strives to be compatible with Ethereum's Web3 API and EVM, there are some important Moonbeam differences that developers should know and understand in terms of consensus and finality.

In short, consensus is a way for different parties to agree on a shared state. As blocks are created, nodes in the network must decide which block will represent the next valid state. Finality defines when that valid state cannot be altered or reversed.

Ethereum began by using a consensus protocol based on [Proof-of-Work (PoW)](https://ethereum.org/en/developers/docs/consensus-mechanisms/pow){target=\_blank}, which provides probabilistic finality. However, in 2022, Ethereum switched to [Proof-of-Stake (PoS)](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos){target=\_blank}, which provides deterministic finality, and no longer uses PoW. In contrast, Moonbeam uses a hybrid consensus protocol based on Delegated Proof-of-Stake (DPoS), which also provides deterministic finality. DPoS is an evolution of Polkadot's [Nominated Proof of Stake (NPoS)](https://docs.polkadot.com/polkadot-protocol/architecture/polkadot-chain/pos-consensus/){target=\_blank} concept, that puts more power into the hands of token holders by allowing delegators to choose which collator candidate they want to support and in what magnitude.

This guide will outline some of these main differences around consensus and finality, and what to expect when using Moonbeam for the first time.

## Ethereum Consensus and Finality {: #ethereum-consensus-and-finality }

Ethereum currently uses a PoS consensus protocol, in which validators stake ETH in the network and are responsible for producing blocks and checking the validity of new blocks. The timing of block production is fixed and is divided into 12 second slots and 32 slot epochs. One validator per slot is randomly selected to produce a block and broadcast it to the network. There is a randomly selected committee of validators per slot that is responsible for determining the validity of the block. The greater the stake in the network, the greater the chance the validator will be chosen to produce or validate a block.

Finality is deterministic in Ethereum's PoS consensus protocol and is achieved through "checkpoint" blocks. Validators agree on the state of a block at particular checkpoint blocks, which are always the first block in an epoch, and if two-thirds of the validators agree, the block is finalized. Block finality can be reverted; however, there are strong economic incentives in place so validators do not attempt to collude to revert a block. You can find out more information in Vitalik's [On Settlement Finality](https://blog.ethereum.org/2016/05/09/on-settlement-finality){target=\_blank} blog, under the Finality in Casper section.

## Moonbeam Consensus and Finality {: #moonbeam-consensus-and-finality }

In Polkadot, there are collators and validators. [Collators](https://wiki.polkadot.com/learn/learn-collator/){target=\_blank} maintain parachains (in this case, Moonbeam) by collecting transactions from users and producing state transition proofs for the relay chain [validators](https://wiki.polkadot.com/learn/learn-validator/){target=\_blank}. The collator set (nodes that produce blocks) is selected based on the [stake they have in the network](/learn/features/consensus/){target=\_blank}.

For finality, Polkadot and Kusama rely on [GRANDPA](https://docs.polkadot.com/polkadot-protocol/architecture/polkadot-chain/pos-consensus/#finality-gadget-grandpa){target=\_blank}. GRANDPA provides deterministic finality for any given transaction (block). In other words, when a block or transaction is marked as final, it can't be reverted except via on-chain governance or forking. Moonbeam follows this deterministic finality.

## Main Differences Between PoS and DPoS {: #main-differences }

In terms of consensus, Moonbeam is based on Delegated Proof-of-Stake, while Ethereum relies on a standard Proof-of-Stake system, which is slightly different. Although both mechanisms rely on the use of stake to validate and create new blocks, there are some key differences.

With PoS on Ethereum, validators are selected to produce and validate blocks based on their own stake in the network. As long as a validator has placed a validator deposit, they can be selected to produce and validate blocks. However, as previously mentioned, the greater the stake in the network, the higher the chances a validator has to be selected to produce and validate blocks.

On the other hand, with DPoS on Moonbeam, collators become eligible to produce blocks based on their own stake plus their delegated stake in the network. Any token holder can choose to delegate their stake to a collator candidate. The top collator candidates by stake, including delegations, join the active set. The number of candidates in the active set is subject to [governance](/learn/features/governance/){target=\_blank}. Once in the active set, collators are randomly selected to produce blocks using the [Nimbus Consensus Framework](/learn/features/consensus/){target=\_blank}. It is important to note that once a collator is in the active set, their total stake does not impact their chances of being selected to produce blocks.

In terms of finality, blocks on Ethereum can take quite a bit longer to finalize than on Moonbeam due to the checkpoint finality system it uses. In Ethereum, validators determine finality at checkpoint blocks, which are always the first block in an epoch. Since an epoch has 32 slots and each slot is 12 seconds, it'll take at least 384 seconds, or 6.4 minutes for a block to be finalized.

Moonbeam does not use checkpoint blocks and instead relies on Polkadot's GRANDPA finality gadget, where the finality process is completed in parallel to block production. In addition, the finality process incorporates the blockchain's structure, which allows the relay chain validators to vote on the highest block that they think is valid. In this scenario, the vote would apply to all of the blocks leading up to the one that is finalized, which speeds up the finalization process. After a block has been included in the relay chain, a block can be finalized within one block on Moonbeam.

## Check Transaction Finality with Ethereum RPC Endpoints {: #check-tx-finality-with-ethereum-rpc-endpoints }

Although the finality gadgets differ, you can use the same, fairly simple strategy to check for transaction finality on both Ethereum and Moonbeam:

 1. You ask the network for the hash of the latest finalized block
 2. You retrieve the block number using the hash
 3. You compare it with the block number of your transaction. If your transaction was included in a previous block, it is finalized
 4. As a safety check, retrieve the block by number and verify that the given transaction hash is in the block

The snippets below follow this strategy to check transaction finality. It uses the `finalized` option for the [default block parameter](https://ethereum.org/en/developers/docs/apis/json-rpc/#default-block){target=\_blank} to get the latest finalized block.

To test out the examples in this guide on Moonbeam or Moonriver, you will need to have your own endpoint and API key, which you can get from one of the supported [Endpoint Providers](/builders/get-started/endpoints/){target=\_blank}.

!!! note
    The code snippets presented in the following sections are not meant for production environments. Please make sure you adapt it for each use-case.

=== "Ethers.js"

    ```js
    import { ethers } from 'ethers';

// Define the transaction hash to check finality
const txHash = 'INSERT_TX_HASH';

// Define the RPC of the provider for Moonbeam
// This can be adapted for Moonriver or Moonbase Alpha
const providerRPC = {
  moonbeam: {
    name: 'moonbeam',
    rpc: 'INSERT_RPC_API_ENDPOINT',
    chainId: 1284,
  }
};

// Define the Web3 provider
const web3Provider = new ethers.JsonRpcProvider(providerRPC.moonbeam.rpc, {
  chainId: providerRPC.moonbeam.chainId,
  name: providerRPC.moonbeam.name,
});

const main = async () => {
  // Get the last finalized block
  const finalizedBlockHeader = await web3Provider.getBlock('finalized');
  const finalizedBlockNumber = finalizedBlockHeader.number;

  // Get the transaction receipt of the given transaction hash
  const txReceipt = await web3Provider.getTransactionReceipt(txHash);

  // If block number of receipt is not null, compare it against finalized head
  if (txReceipt) {
    const txBlockNumber = txReceipt.blockNumber;

    // As a safety check, get given block to check if transaction is included
    const txBlock = await web3Provider.getBlock(txBlockNumber);

    console.log(`Current finalized block number is ${finalizedBlockNumber}`);
    console.log(
      `Your transaction in block ${txBlockNumber} is finalized? ${
        finalizedBlockNumber >= txBlockNumber
      }`
    );
    console.log(
      `Your transaction is indeed in block ${txBlockNumber}? ${txBlock.transactions.includes(
        txHash
      )}`
    );
  } else {
    console.log(
      'Your transaction has not been included in the canonical chain'
    );
  }
};

main();
    ```

=== "Web3.js"

    ```js
    import { Web3 } from 'web3';

// Define the transaction hash to check finality
const txHash = 'INSERT_TX_HASH';

// Define the Web3 provider for Moonbeam
// This can be adapted for Moonriver or Moonbase Alpha
const web3Provider = new Web3('INSERT_RPC_API_ENDPOINT');

const main = async () => {
  // Get the last finalized block
  const finalizedBlockHeader = await web3Provider.eth.getBlock('finalized');
  const finalizedBlockNumber = finalizedBlockHeader.number;

  // Get the transaction receipt of the given transaction hash
  const txReceipt = await web3Provider.eth.getTransactionReceipt(txHash);

  // If block number of receipt is not null, compare it against finalized head
  if (txReceipt) {
    const txBlockNumber = txReceipt.blockNumber;

    // As a safety check, get given block to check if transaction is included
    const txBlock = await web3Provider.eth.getBlock(txBlockNumber);

    console.log(`Current finalized block number is ${finalizedBlockNumber}`);
    console.log(
      `Your transaction in block ${txBlockNumber} is finalized? ${
        finalizedBlockNumber >= txBlockNumber
      }`
    );
    console.log(
      `Your transaction is indeed in block ${txBlockNumber}? ${txBlock.transactions.includes(
        txHash
      )}`
    );
  } else {
    console.log(
      'Your transaction has not been included in the canonical chain'
    );
  }
};

main();
    ```

=== "Web3.py"

    ```py
    from web3 import Web3

# Define the transaction hash to check finality
tx_hash = "INSERT_TX_HASH"

# Define the Web3 provider for Moonbeam
# This can be adapted for Moonriver or Moonbase Alpha
web3_provider = Web3(Web3.HTTPProvider("INSERT_RPC_API_ENDPOINT"))

if __name__ == "__main__":
    # Get the latest finalized block
    finalized_block_header = web3_provider.eth.get_block("finalized")
    finalized_block_number = finalized_block_header.number

    # Get the transaction receipt of the given transaction hash
    tx_receipt = web3_provider.eth.get_transaction_receipt(tx_hash)

    # If block number of receipt is not null, compare it against finalized head
    if tx_receipt is not None:
        tx_block_number = tx_receipt.blockNumber

        # As a safety check, get given block to check if transaction is included
        tx_block = web3_provider.eth.get_block(tx_block_number)
        is_in_block = False
        for tx in tx_block.transactions:
            if tx_hash == web3_provider.to_hex(tx):
                is_in_block = True

        print(f"Current finalized block number is { str(finalized_block_number) }")
        print(
            f"Your transaction in block { str(tx_block_number) } is finalized? { str(finalized_block_number >= tx_block_number) }"
        )
        print(
            f"Your transaction is indeed in block { str(tx_block_number) }? { is_in_block }"
        )
    else:
        print("Your transaction has not been included in the canonical chain")
    ```

## Check Transaction Finality with Moonbeam RPC Endpoints {: #check-tx-finality-with-moonbeam-rpc-endpoints }

Moonbeam has added support for two custom RPC endpoints, `moon_isBlockFinalized` and `moon_isTxFinalized`, that can be used to check whether an on-chain event is finalized. These methods are a bit more straightforward, as you don't need to compare block numbers to ensure your transaction is finalized.

For more information, you can go to the [Finality RPC Endpoints](/builders/ethereum/json-rpc/moonbeam-custom-api/#rpc-methods){target=\_blank} section of the Moonbeam Custom API page.

You can modify the scripts from the Ethereum RPC section above to use `moon_isBlockFinalized` and `moon_isTxFinalized`. To do this, you can make custom calls to the Substrate JSON-RPC using the `send` method of both [Web3.js](https://web3js.readthedocs.io){target=\_blank} and [Ethers.js](https://docs.ethers.org/v6){target=\_blank}. Custom RPC requests are also possible using [Web3.py](https://web3py.readthedocs.io){target=\_blank} with the `make_request` method. You'll need to pass in the method name and the parameters to the custom request, which you can find on the [Moonbeam Custom API](/builders/ethereum/json-rpc/moonbeam-custom-api/){target=\_blank} page.

???+ code "moon_isBlockFinalized"

    === "Ethers.js"

        ```js
        import { ethers } from 'ethers';

// Define the block hash to check finality
const blockHash = 'INSERT_BLOCK_HASH';

// Define the RPC of the provider for Moonbeam
// This can be adapted for Moonriver or Moonbase Alpha
const providerRPC = {
  moonbeam: {
    name: 'moonbeam',
    rpc: 'INSERT_RPC_API_ENDPOINT',
    chainId: 1284,
  },
};

// Define the Web3 provider
const web3Provider = new ethers.JsonRpcProvider(providerRPC.moonbeam.rpc, {
  chainId: providerRPC.moonbeam.chainId,
  name: providerRPC.moonbeam.name,
});

// Define the function for the custom web3 request
const customWeb3Request = async (web3Provider, method, params) => {
  try {
    return await web3Provider.send(method, params);
  } catch (error) {
    throw new Error(error.body);
  }
};

const main = async () => {
  // Check if the block has been finalized
  const isFinalized = await customWeb3Request(
    web3Provider,
    'moon_isBlockFinalized',
    [blockHash]
  );
  console.log(`Block is finalized? ${isFinalized}`);
};

main();
        ```

    === "Web3.js"

        ```js
        import { Web3 } from 'web3';

// Define the block hash to check finality
const blockHash = 'INSERT_BLOCK_HASH';

// Define the Web3 provider for Moonbeam
// This can be adapted for Moonriver or Moonbase Alpha
const web3Provider = new Web3('INSERT_RPC_API_ENDPOINT');

// Define the function for the custom Web3 request
const customWeb3Request = async (web3Provider, method, params) => {
  try {
    return await requestPromise(web3Provider, method, params);
  } catch (error) {
    throw new Error(error);
  }
};

// In Web3.js you need to return a promise
const requestPromise = async (web3Provider, method, params) => {
  return new Promise((resolve, reject) => {
    web3Provider.send(
      {
        jsonrpc: '2.0',
        id: 1,
        method,
        params,
      },
      (error, result) => {
        if (error) {
          reject(error.message);
        } else {
          if (result.error) {
            reject(result.error.message);
          }
          resolve(result);
        }
      }
    );
  });
};

const main = async () => {
  // Check if the block has been finalized
  const isFinalized = await customWeb3Request(
    web3Provider.currentProvider,
    'moon_isBlockFinalized',
    [blockHash]
  );

  console.log(JSON.stringify(isFinalized));
  console.log(`Block is finalized? ${isFinalized.result}`);
};

main();
        ```

    === "Web3.py"

        ```py
        from web3 import Web3

# Define the block hash to check finality
block_hash = 'INSERT_BLOCK_HASH'

# Set the RPC_address for Moonbeam
# This can also be adapted for Moonriver or Moonbase Alpha
RPC_address = 'INSERT_RPC_API_ENDPOINT'

# Define the Web3 provider
web3_provider = Web3(Web3.HTTPProvider(RPC_address))

# Asynchronous JSON-RPC API request
def custom_web3_request(method, params):
    response = web3_provider.provider.make_request(method, params)
    return response

if __name__ == "__main__":
    # Check if the block has been finalized
    is_finalized = custom_web3_request(
       'moon_isBlockFinalized', [block_hash])
    print(
        f'Block is finalized? { is_finalized["result"] }')
        ```

??? code "moon_isTxFinalized"

    === "Ethers.js"

        ```js
        import { ethers } from 'ethers';

// Define the transaction hash to check finality
const txHash = 'INSERT_TRANSACTION_HASH';

// Define the RPC of the provider for Moonbeam
// This can be adapted for Moonriver or Moonbase Alpha
const providerRPC = {
  moonbeam: {
    name: 'moonbeam',
    rpc: 'INSERT_RPC_API_ENDPOINT',
    chainId: 1284,
  },
};

// Define the Web3 provider
const web3Provider = new ethers.JsonRpcProvider(providerRPC.moonbeam.rpc, {
  chainId: providerRPC.moonbeam.chainId,
  name: providerRPC.moonbeam.name,
});

// Define the function for the custom web3 request
const customWeb3Request = async (web3Provider, method, params) => {
  try {
    return await web3Provider.send(method, params);
  } catch (error) {
    throw new Error(error.body);
  }
};

const main = async () => {
  // Check if the transaction has been finalized
  const isFinalized = await customWeb3Request(
    web3Provider,
    'moon_isTxFinalized',
    [txHash]
  );
  console.log(`Transaction is finalized? ${isFinalized}`);
};

main();
        ```

    === "Web3.js"

        ```js
        import Web3 from 'web3';

// Define the transaction hash to check finality
const txHash = 'INSERT_TRANSACTION_HASH';

// Define the Web3 provider for Moonbeam
// This can be adapted for Moonriver or Moonbase Alpha
const web3Provider = new Web3('INSERT_RPC_API_ENDPOINT');

// Define the function for the custom Web3 request
const customWeb3Request = async (web3Provider, method, params) => {
  try {
    return await requestPromise(web3Provider, method, params);
  } catch (error) {
    throw new Error(error);
  }
};

// In Web3.js you need to return a promise
const requestPromise = async (web3Provider, method, params) => {
  return new Promise((resolve, reject) => {
    web3Provider.send(
      {
        jsonrpc: '2.0',
        id: 1,
        method,
        params,
      },
      (error, result) => {
        if (error) {
          reject(error.message);
        } else {
          if (result.error) {
            reject(result.error.message);
          }
          resolve(result);
        }
      }
    );
  });
};

const main = async () => {
  // Check if the transaction has been finalized
  const isFinalized = await customWeb3Request(
    web3Provider.currentProvider,
    'moon_isTxFinalized',
    [txHash]
  );

  console.log(JSON.stringify(isFinalized));
  console.log(`Transaction is finalized? ${isFinalized}`);
};

main();
        ```

    === "Web3.py"

        ```py
        from web3 import Web3

# Define the transaction hash to check finality
tx_hash = 'INSERT_BLOCK_HASH'

# Set the RPC_address for Moonbeam
# This can also be adapted for Moonriver or Moonbase Alpha
RPC_address = 'INSERT_RPC_API_ENDPOINT'

# Define the Web3 provider
web3_provider = Web3(Web3.HTTPProvider(RPC_address))

# Asynchronous JSON-RPC API request
def custom_web3_request(method, params):
    response = web3_provider.provider.make_request(method, params)
    return response

if __name__ == "__main__":
    # Check if the transaction has been finalized
    is_finalized = custom_web3_request(
       'moon_isTxFinalized', [tx_hash])
    print(
        f'Transaction is finalized? { is_finalized["result"] }')
        ```

## Check Transaction Finality with Substrate RPC Endpoints {: #check-tx-finality-with-substrate-rpc-endpoints }

Using the following three RPC requests from the Substrate JSON-RPC, you can fetch the current finalized block and compare it with the block number of the transaction you want to check finality for:

- `chain_getFinalizedHead` - the first request gets the block hash of the last finalized block
- `chain_getHeader` - the second request gets the block header for a given block hash
- `eth_getTransactionReceipt` - this retrieves the transaction receipt given the transaction hash

The [Polkadot.js API package](/builders/substrate/libraries/polkadot-js-api/){target=\_blank} and [Python Substrate Interface package](/builders/substrate/libraries/py-substrate-interface/){target=\_blank} provide developers with a way to interact with Substrate chains using JavaScript and Python.

You can find more information about Polkadot.js and the Substrate JSON-RPC in the [official Polkadot.js documentation site](https://polkadot.js.org/docs/substrate/rpc){target=\_blank}, and more about Python Substrate Interface in the [official PySubstrate documentation site](https://jamdottech.github.io/py-polkadot-sdk/){target=\_blank}.

=== "Polkadot.js"

    ```js
    import { ApiPromise, WsProvider } from '@polkadot/api';
import { types } from 'moonbeam-types-bundle';

// Define the transaction hash to check finality
const txHash = 'INSERT_TX_HASH';

// Define the provider for Moonbeam
// This can be adapted for Moonriver or Moonbase Alpha
const wsProvider = new WsProvider('INSERT_WSS_API_ENDPOINT');

const main = async () => {
  // Create the provider using Moonbeam types
  const polkadotApi = await ApiPromise.create({
    provider: wsProvider,
    typesBundle: types,
  });
  await polkadotApi.isReady;

  // Get the latest finalized block of the Substrate chain
  const finalizedHeadHash = (
    await polkadotApi.rpc.chain.getFinalizedHead()
  ).toJSON();

  // Get finalized block header to retrieve number
  const finalizedBlockHeader = (
    await polkadotApi.rpc.chain.getHeader(finalizedHeadHash)
  ).toJSON();

  // Get the transaction receipt of the given tx hash
  const txReceipt = (
    await polkadotApi.rpc.eth.getTransactionReceipt(txHash)
  ).toJSON();

  // You can not verify if the tx is in the block because polkadotApi.rpc.eth.getBlockByNumber
  // does not return the list of tx hashes

  // If block number of receipt is not null, compare it against finalized head
  if (txReceipt) {
    console.log(
      `Current finalized block number is ${finalizedBlockHeader.number}`
    );
    console.log(
      `Your transaction in block ${txReceipt.blockNumber} is finalized? ${
        finalizedBlockHeader.number >= txReceipt.blockNumber
      }`
    );
  } else {
    console.log(
      'Your transaction has not been included in the canonical chain'
    );
  }

  polkadotApi.disconnect();
};

main();
    ```

=== "py-substrate-interface"

    ```py
    from substrateinterface import SubstrateInterface

# Define the Ethereum transaction hash to check finality
tx_hash = "INSERT_TX_HASH"

# Point API provider to Moonbeam
# This can be adapted for Moonriver or Moonbase Alpha
moonbeam_API_provider = SubstrateInterface(
    url="INSERT_WSS_API_ENDPOINT",
)

if __name__ == "__main__":
    # Get the latest finalized block header of the chain
    finalized_block_header = moonbeam_API_provider.get_block_header(finalized_only=True)
    # Get the finalized block number from the block header
    finalized_block_number = finalized_block_header["header"]["number"]
    # Get the transaction receipt of the given transaction hash through a
    # custom RPC request
    tx_receipt = moonbeam_API_provider.rpc_request(
        "eth_getTransactionReceipt", [tx_hash]
    )

    # Check if tx_receipt is null
    if tx_receipt is None:
        print("The transaction hash cannot be found in the canonical chain.")
    else:
        # Get the block number of the transaction
        tx_block_number = int(tx_receipt["result"]["blockNumber"], 16)
        # Get the transaction block through a custom RPC request
        tx_block = moonbeam_API_provider.rpc_request(
            "eth_getBlockByNumber", [tx_block_number, False]
        )

        print(f"Current finalized block number is { str(finalized_block_number) }")
        print(
            f"Your transaction in block { str(tx_block_number) } is finalized? { str(finalized_block_number >= tx_block_number) }"
        )
        print(
            f'Your transaction is indeed in block { str(tx_block_number) }? { str(tx_hash in tx_block["result"]["transactions"]) }'
        )
    ```

<div class="page-disclaimer">
  The information presented herein has been provided by third parties and is made available solely for general information purposes. Moonbeam does not endorse any project listed and described on the Moonbeam Doc Website (https://docs.moonbeam.network/). Moonbeam Foundation does not warrant the accuracy, completeness or usefulness of this information. Any reliance you place on such information is strictly at your own risk. Moonbeam Foundation disclaims all liability and responsibility arising from any reliance placed on this information by you or by anyone who may be informed of any of its contents. All statements and/or opinions expressed in these materials are solely the responsibility of the person or entity providing those materials and do not necessarily represent the opinion of Moonbeam Foundation. The information should not be construed as professional or financial advice of any kind. Advice from a suitably qualified professional should always be sought in relation to any particular matter or circumstance. The information herein may link to or integrate with other websites operated or content provided by third parties, and such other websites may link to this website. Moonbeam Foundation has no control over any such other websites or their content and will have no liability arising out of or related to such websites or their content. The existence of any such link does not constitute an endorsement of such websites, the content of the websites, or the operators of the websites. These links are being provided to you only as a convenience and you release and hold Moonbeam Foundation harmless from any and all liability arising from your use of this information or the information provided by any third-party website or service.
</div>
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/learn/core-concepts/security/
--- BEGIN CONTENT ---
---
title: Security Considerations
description: A description of the main differences that Ethereum developers need to understand in terms of security considerations when developing on Moonbeam.
categories: Basics
---

# Security Considerations

## Introduction {: #introduction }

When developing smart contracts on Moonbeam, there are some security considerations to be aware of that do not apply when developing on Ethereum. Moonbeam has several [precompiled contracts](/builders/ethereum/precompiles/){target=\_blank}, which are Solidity interfaces that enable developers to access Substrate-based functionality through the Ethereum API, but circumventing the EVM. Although the precompiled contracts are designed to improve the developer experience, there can be some unintended consequences that must be considered.

This guide will outline and provide examples of some security considerations to be cognizant of when developing on Moonbeam.

## Arbitrary Code Execution {: #arbitrary-code-execution }

Arbitrary code execution in Solidity is the ability to execute code and call functions of other contracts using an arbitrary number of arguments of any type.

A smart contract allows arbitrary execution of another contract when it allows a user to influence its own `call()` and pass in arbitrary call data and/or the `call()`s target. The [`call()` function](https://solidity-by-example.org/call){target=\_blank} is made available through the [address data type in Solidity](https://docs.soliditylang.org/en/latest/types.html#address){target=\_blank}. When the `call()` function is invoked, the target contract is called using the arbitrary call data.

Arbitrary code execution follows the pattern in the diagram below when **Contract A** allows a user to influence its call to **Contract B**.

![Arbitrary code execution](/images/learn/core-concepts/security/security-1.webp)

As previously mentioned, one major concern of arbitrarily executing code on Moonbeam is that Moonbeam has precompile contracts that can be called, which can be used to get around some protections that are typically available on Ethereum. To safely use arbitrary code execution on Moonbeam, you should consider the following, which **only applies to contracts that allow arbitrary code execution**:

- Moonbeam [precompiled contracts](/builders/ethereum/precompiles/){target=\_blank} such as the Native ERC-20 precompile, XC-20 precompiles, and XCM-related precompiles allow users to manage and transfer assets without requiring access to the EVM. Instead, these actions are done using native Substrate code. So, if your contract holds native tokens or XC-20s and allows arbitrary code execution, these precompiles can be used to drain the balance of the contract, bypassing any security checks that are normally enforced by the EVM
- Setting the value attribute of the transaction object to a fixed amount when using the `call()` function (for example, `call{value: 0}(...)`) can be bypassed by calling the native asset precompile and specifying an amount to transfer in the encoded call data
- Allowing users that consume your contract to pass in arbitrary call data that will execute any function on the target contract, especially if the contract being targeted is a precompile, is **not** safe. To be safe, you can hard code the function selector for a safe function that you want to allow to be executed
- Blacklisting target contracts (including precompiles) in the function that executes arbitrary call data is **not** considered safe, as other precompiles might be added in the future. Providing whitelisted target contracts in the function that executes the arbitrary call data is considered safe, assuming that the contracts being called are not precompiles, or that in the case they are, the contract making the call does not hold the native token or any XC-20

In the following sections, you'll learn about each of these security considerations through examples.

### Precompiles Can Override a Set Value {: #setting-a-value }

On Ethereum, a smart contract that allows for arbitrary code execution could force the value of a call to be a specific amount (for example, `{value: 0}`), guaranteeing that only that amount of native currency would be sent with the transaction. Whereas on Moonbeam, the [native ERC-20 precompile contract](/builders/ethereum/precompiles/ux/erc20/){target=\_blank} enables you to interact with the native currency on Moonbeam as an ERC-20 through the Substrate API. As a result, you can transfer the Moonbeam native asset from a smart contract by setting the `value` of a call, as well as through the native ERC-20 precompile. If you set the `value` of an arbitrary call, it can be overridden by targeting the [native ERC-20 precompile contract](/builders/ethereum/precompiles/ux/erc20/){target=\_blank} and passing in call data to transfer the native asset. Since ERC-20s and XC-20s are not native assets, setting the value attribute doesn't provide any protection for these types of assets on Ethereum or Moonbeam.

For example, if you have a contract that allows arbitrary code execution and you pass it encoded call data that transfers the balance of a contract to another address, you could essentially drain the given contract of its balance.

To get the encoded call data, you can use any of the [ABI encoding functions outlined in the Solidity docs](https://docs.soliditylang.org/en/latest/units-and-global-variables.html#abi-encoding-and-decoding-functions){target=\_blank}, including `abi.encodeWithSelector` as seen in the following function:

```solidity
function getBytes(address _erc20Contract, address _arbitraryCallContract, address _to) public view returns (bytes memory) {
    // Load ERC-20 interface of contract
    IERC20 erc20 = IERC20(_erc20Contract);
    // Get amount to transfer
    uint256 amount = erc20.balanceOf(_arbitraryCallContract);
    // Build the encoded call data
    return abi.encodeWithSelector(IERC20.transfer.selector, _to, amount);
}
```

Once you have the encoded call data, you could make an arbitrary call to the [native ERC-20 precompile contract](/builders/ethereum/precompiles/ux/erc20/){target=\_blank}, set the value of the call to `0`, and pass in the call data in bytes:

```solidity
function makeArbitraryCall(address _target, bytes calldata _bytes) public {
    // Value: 0 does not protect against native ERC-20 precompile calls or XCM precompiles
    (bool success,) = _target.call{value: 0}(_bytes);
    require(success);
}
```

The value of `0` will be overridden by the amount to be transferred as specified in the encoded call data, which in this example is the balance of the contract.

### Whitelisting Safe Function Selectors {: #whitelisting-function-selectors }

By whitelisting a specific function selector, you can control what functions can be executed and ensure only functions that are considered safe and do not call precompiles are allowed to be called.

To get the function selector to whitelist, you can [keccack256 hash](https://emn178.github.io/online-tools/keccak_256.html){target=\_blank} the signature of the function.

Once you have the whitelisted function selector, you can use inline assembly to get the function selector from the encoded call data and compare the two selectors using the [require function](https://docs.soliditylang.org/en/v0.8.17/control-structures.html#panic-via-assert-and-error-via-require){target=\_blank}. If the function selector from the encoded call data matches the whitelisted function selector, you can make the call. Otherwise, an exception will be thrown.

```solidity
function makeArbitraryCall(address _target, bytes calldata _bytes) public {
    // Get the function selector from the encoded call data
    bytes4 selector;
    assembly {
        selector := calldataload(_bytes.offset)
    }

    // Ensure the call data calls an approved and safe function
    require(selector == INSERT_WHITELISTED_FUNCTION_SELECTOR);

    // Arbitrary call
    (bool success,) = _target.call(_bytes);
    require(success);
}
```

### Whitelisting Safe Contracts {: #whitelisting-safe-contracts}

By whitelisting a specific target contract address in the function that can execute arbitrary call data, you can ensure that the call is considered safe, as the EVM will enforce that only whitelisted contracts can be called. This assumes that the contracts being called are not precompiles. If they are precompiles, you'll want to make sure that the contract making the call does not hold the native token or any XC-20.

Blacklisting contracts from arbitrary code execution is not considered safe, as other precompiles might be added in the future.

To whitelist a given contract, you can use the [require function](https://docs.soliditylang.org/en/v0.8.17/control-structures.html#panic-via-assert-and-error-via-require){target=\_blank}, which will compare the target contract address to the whitelisted contract address. If the addresses match, the call can be executed. Otherwise, an exception will be thrown.

```solidity
function makeArbitraryCall(address _target, bytes calldata _bytes) public {
    // Ensure the contract address is safe
    require(_target == INSERT_CONTRACT_ADDRESS);

    // Arbitrary call
    (bool success,) = _target.call(_bytes);
    require(success);
}
```

## Precompiles Can Bypass Sender vs Origin Checks {: #bypass-sender-origin-checks }

The transaction origin, or `tx.origin`, is the address of the externally owned account (EOA) the transaction originated from. Whereas the `msg.sender` is the address that has initiated the current call. The `msg.sender` can be an EOA or a contract. The two can be different values if one contract calls another contract, as opposed to directly calling a contract from an EOA. In this case, the `msg.sender` will be the calling contract and the `tx.origin` will be the EOA that initially called the calling contract.

For example, if Alice calls a function in contract A that then calls a function in contract B, when looking at the call to contract B, the `tx.origin` is Alice and the `msg.sender` is contract A.

!!! note
    As a [best practice](https://consensysdiligence.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/tx-origin/){target=\_blank}, `tx.origin` should not be used for authorization. Instead, you should use `msg.sender`.

You can use the [require function](https://docs.soliditylang.org/en/v0.8.17/control-structures.html#panic-via-assert-and-error-via-require){target=\_blank} to compare the `tx.origin` and `msg.sender`. If they are the same address, you're ensuring that only EOAs can call the function. If the `msg.sender` is a contract address, an exception will be thrown.

```solidity
function transferFunds(address payable _target) payable public {
    require(tx.origin == msg.sender);
    _target.call{value: msg.value};
}
```

On Ethereum, you can use this check to ensure that a given contract function can only be called once by an EOA. This is because on Ethereum, EOAs can only interact with a contract once per transaction. However, **this is not the case** on Moonbeam, as EOAs can interact with a contract multiple times at once by using precompiled contracts, such as the [batch](/builders/ethereum/precompiles/ux/batch/){target=\_blank} and [call permit](/builders/ethereum/precompiles/ux/call-permit/){target=\_blank} precompiles.

With the batch precompile, users can perform multiple calls to a contract atomically. The caller of the batch function will be the `msg.sender` and `tx.origin`, enabling multiple contract interactions at once.

With the call permit precompile, if a user wants to interact with a contract multiple times in one transaction, they can do so by signing a permit for each contract interaction and dispatching all of the permits in a single function call. This will only bypass the `tx.origin == msg.sender` check if the dispatcher is the same account as the permit signer. Otherwise, the `msg.sender` will be the permit signer and the `tx.origin` will be the dispatcher, causing an exception to be thrown.
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/learn/core-concepts/transfers-api/
--- BEGIN CONTENT ---
---
title: Transfer & Monitor Balances on Moonbeam
description: A description of the main differences that developers need to understand in terms of the different balance transfers available on Moonbeam compared to Ethereum.
categories: Basics
---

# Balance Transfers on Moonbeam

## Introduction {: #introduction }

While Moonbeam strives to be compatible with Ethereum's Web3 API and EVM, there are some important Moonbeam differences that developers should know and understand in terms of balance transfers of the base network token (for example, GLMR and MOVR).

Token holders have two ways of initiating a balance transfer on Moonbeam. On the one hand, users can use the Ethereum API via apps like MetaMask, MathWallet, or any other tools that use the Ethereum JSON-RPC. On the other hand, users can use the Substrate API via the Polkadot.js Apps website or directly using the Substrate RPC.

Developers need to be aware that token holders can leverage both APIs to transfer the base-layer network token. Note that these comments do not apply to transfers of other assets, like ERC-20 based assets in the Moonriver or Moonbeam EVMs. Transfers of these assets are only done via the Ethereum APIs since these are smart contract interactions.

This guide will outline some of the main differences between both APIs for base-layer network token balance transfers and what to expect when using Moonbeam for the first time.

## Ethereum Transfers {: #ethereum-transfers }

A simple balance transfer using the Ethereum API relies on the `eth_sendRawTransaction` JSON-RPC. This can be done directly from one account to another or via a smart contract.

There are different strategies to listen for transfers or balance changes on Ethereum, which are not covered in this documentation. But they are all focused on different strategies using the Ethereum JSON-RPC.

## Moonbeam Transfers {: #moonbeam-transfers }

As stated before, Moonbeam enables token holders to execute base-layer network token transfers via both the Ethereum and Substrate API. There are multiple scenarios to trigger token transfers on Moonbeam. Consequently, to monitor all transfers, **you should use the Polkadot.js SDK** (Substrate API).

Before going over the different scenarios, there are two different elements associated with a block:

 - **Extrinsic** — refers to state changes that originated outside of the system itself. The most common form of extrinsic is a transaction. They are ordered by execution
 - **Events** — refers to logs generated from the extrinsic. There can be multiple events per extrinsic. They are ordered by execution

The different transfer scenarios are:

 - **Substrate transfer** — it will create an extrinsic, either `balances.transferAllowDeath` or `balances.transferKeepAlive`. It will trigger **one** `balances.Transfer` event
 - **Substrate feature** — some native Substrate features can create extrinsic that would send tokens to an address. For example, [Treasury](/learn/features/treasury/){target=\_blank} can create an extrinsic such as `treasury.proposeSend`, which will trigger **one or multiple** `balances.Transfer` events
 - **Ethereum transfer** — it will create an `ethereum.transact` extrinsic with an empty input. It will trigger **one** `balances.Transfer` event
 - **Ethereum transfers via smart contracts** — it will create an `ethereum.transact` extrinsic with some data as input. It will trigger **one or multiple** `balances.Transfer` events

All the scenarios described above will effectively transfer base-layer network tokens. The easiest way to monitor them all is to rely on the `balances.Transfer` event.

## Monitor Native Token Balance Transfers {: #monitor-transfers }

The following code samples will demonstrate how to listen to both types of native token transfers, sent via the Substrate or Ethereum API, using either the [Polkadot.js API library](https://polkadot.js.org/docs/api/start/){target=\_blank} or [Substrate API Sidecar](https://github.com/paritytech/substrate-api-sidecar){target=\_blank}. The following code snippets are for demo purposes only and should not be used without modification and further testing in a production environment.

### Using Polkadot.js API {: #using-polkadotjs-api }

The [Polkadot.js API package](https://polkadot.js.org/docs/api/start/){target=\_blank} provides developers a way to interact with Substrate chains using JavaScript.

The following code snippet uses [`subscribeFinalizedHeads`](https://polkadot.js.org/docs/substrate/rpc/#subscribefinalizedheads-header){target=\_blank} to subscribe to new finalized block headers, loops through extrinsics fetched from the block, and retrieves the events of each extrinsic. Then, it checks if any event corresponds to a `balances.Transfer` event. If so, it will extract the `from`, `to`, `amount`, and the `tx hash` of the transfer and display it on the console. Note that the `amount` is shown in the smallest unit (Wei).  You can find all the available information about Polkadot.js and the Substrate JSON-RPC on their [official documentation site](https://polkadot.js.org/docs/substrate/rpc){target=\_blank}.

```ts
import { typesBundlePre900 } from 'moonbeam-types-bundle';
import { ApiPromise, WsProvider } from '@polkadot/api';

// This script will listen to all GLMR transfers (Substrate & Ethereum) and extract the tx hash
// It can be adapted for Moonriver or Moonbase Alpha

const main = async () => {
  // Define the provider for Moonbeam
  const wsProvider = new WsProvider('wss://wss.api.moonbeam.network');
  // Create the provider using Moonbeam types
  const polkadotApi = await ApiPromise.create({
    provider: wsProvider,
    typesBundle: typesBundlePre900 as any,
  });

  // Subscribe to finalized blocks
  await polkadotApi.rpc.chain.subscribeFinalizedHeads(
    async (lastFinalizedHeader) => {
      const [{ block }, records] = await Promise.all([
        polkadotApi.rpc.chain.getBlock(lastFinalizedHeader.hash),
        polkadotApi.query.system.events.at(lastFinalizedHeader.hash),
      ]);

      block.extrinsics.forEach((extrinsic, index) => {
        const {
          method: { args, method, section },
        } = extrinsic;

        const isEthereum = section == 'ethereum' && method == 'transact';

        // Gets the transaction object
        const tx = args[0] as any;

        // Convert to the correct Ethereum Transaction format
        const ethereumTx =
          isEthereum &&
          ((tx.isLegacy && tx.asLegacy) ||
            (tx.isEip1559 && tx.asEip1559) ||
            (tx.isEip2930 && tx.asEip2930));

        // Check if the transaction is a transfer
        const isEthereumTransfer =
          ethereumTx &&
          ethereumTx.input.length === 0 &&
          ethereumTx.action.isCall;

        // Retrieve all events for this extrinsic
        const events = records.filter(
          ({ phase }) =>
            phase.isApplyExtrinsic && phase.asApplyExtrinsic.eq(index)
        );

        // This hash will only exist if the transaction was executed through Ethereum.
        let ethereumHash = '';

        if (isEthereum) {
          // Search for Ethereum execution
          events.forEach(({ event }) => {
            if (event.section == 'ethereum' && event.method == 'Executed') {
              ethereumHash = event.data[2].toString();
            }
          });
        }

        // Search if it is a transfer
        events.forEach(({ event }) => {
          if (event.section == 'balances' && event.method == 'Transfer') {
            const from = event.data[0].toString();
            const to = event.data[1].toString();
            const balance = (event.data[2] as any).toBigInt();

            const substrateHash = extrinsic.hash.toString();

            console.log(
              `Transfer from ${from} to ${to} of ${balance} (block #${lastFinalizedHeader.number})`
            );
            console.log(`  - Triggered by extrinsic: ${substrateHash}`);
            if (isEthereum) {
              console.log(
                `  - Ethereum (isTransfer: ${isEthereumTransfer}) hash: ${ethereumHash}`
              );
            }
          }
        });
      });
    }
  );
};

main();
```

In addition, you can find more sample code snippets related to more specific cases around balance transfers on this [GitHub page](https://gist.github.com/crystalin/b2ce44a208af60d62b5ecd1bad513bce){target=\_blank}.

### Using Substrate API Sidecar {: #using-substrate-api-sidecar }

Developers can also retrieve Moonbeam blocks and monitor transactions sent via both the Substrate and Ethereum APIs using [Substrate API Sidecar](https://github.com/paritytech/substrate-api-sidecar){target=\_blank}, a REST API service for interacting with blockchains built with the Substrate framework.

The following code snippet uses the Axios HTTP client to query the [Sidecar endpoint `/blocks/head`](https://paritytech.github.io/substrate-api-sidecar/dist){target=\_blank} for the latest finalized block and then decodes the block for the `from`, `to`, `value`, `tx hash`, and `transaction status` of native token transfers at both the EVM and Substrate API level.

```js
import axios from 'axios';

// This script will decode all native token transfers (Substrate & Ethereum) in a given Sidecar block, and extract the tx hash. It can be adapted for any Moonbeam network.

// Endpoint to retrieve the latest block
const endpoint = 'http://127.0.0.1:8080/blocks/head';

async function main() {
  try {
    // Retrieve the block from the Sidecar endpoint
    const response = await axios.get(endpoint);
    // Retrieve the block height of the current block
    console.log('Block Height: ' + response.data.number);

    // Iterate through all extrinsics in the block
    response.data.extrinsics.forEach((extrinsic) => {
      // Retrieve Ethereum Transfers
      if (
        extrinsic.method.pallet === 'ethereum' &&
        extrinsic.method.method === 'transact'
      ) {
        // Get the value for any of the three EIP transaction standards supported
        const value =
          (extrinsic.args.transaction.legacy &&
            extrinsic.args.transaction.legacy.value) ||
          (extrinsic.args.transaction.eip1559 &&
            extrinsic.args.transaction.eip1559.value) ||
          (extrinsic.args.transaction.eip2930 &&
            extrinsic.args.transaction.eip2930.value);

        // Iterate through the events to get transaction details
        extrinsic.events.forEach((event) => {
          if (
            event.method.pallet === 'ethereum' &&
            event.method.method === 'Executed'
          ) {
            console.log('From: ' + event.data[0]);
            console.log('To: ' + event.data[1]);
            console.log('Tx Hash: ' + event.data[2]);
            console.log('Value: ' + value);
            // Check the execution status
            if (event.data[3].succeed) {
              console.log('Status: Success');
            } else {
              console.log('Status: Failed');
            }
          }
        });
      }

      // Retrieve Substrate Transfers
      if (
        extrinsic.method.pallet === 'balances' &&
        (extrinsic.method.method === 'transferKeepAlive' ||
          extrinsic.method.method === 'transferAllowDeath')
      ) {
        // Iterate through the events to get transaction details
        extrinsic.events.forEach((event) => {
          if (
            event.method.pallet === 'balances' &&
            event.method.method === 'Transfer'
          ) {
            console.log('From: ' + event.data[0]);
            console.log('To: ' + event.data[1]);
            console.log('Tx Hash: ' + extrinsic.hash);
            console.log('Value: ' + event.data[2]);
            // Check the execution status
            if (extrinsic.success) {
              console.log('Status: Success');
            } else {
              console.log('Status: Failed');
            }
          }
        });
      }
    });
  } catch (err) {
    console.log(err);
  }
}

main();
```

You can reference the [Substrate API Sidecar page](/builders/substrate/libraries/sidecar/) for information on installing and running your own Sidecar service instance, as well as more details on how to decode Sidecar blocks for Moonbeam transactions.
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/learn/core-concepts/tx-fees/
--- BEGIN CONTENT ---
---
title: Calculating Transaction Fees
description: Learn about the transaction fee model used in Moonbeam and the differences compared to Ethereum that developers should be aware of.
categories: Basics
---

# Calculating Transaction Fees on Moonbeam

## Introduction {: #introduction }

Similar to [the Ethereum and Substrate APIs for sending transfers](/learn/core-concepts/transfers-api/){target=\_blank} on Moonbeam, the Substrate and EVM layers on Moonbeam also have distinct transaction fee models that developers should be aware of when they need to calculate and keep track of transaction fees for their transactions.

For starters, Ethereum transactions consume gas units based on their computational complexity and data storage requirements. On the other hand, Substrate transactions use the concept of "weight" to determine fees. In this guide, you'll learn how to calculate the transaction fees for both Substrate and Ethereum transactions. In terms of Ethereum transactions, you'll also learn about the key differences between how transaction fees are calculated on Moonbeam and Ethereum.

### Key Differences with Ethereum {: #key-differences-with-ethereum}

There are some key differences between the transaction fee model on Moonbeam and the one on Ethereum that developers should be mindful of when developing on Moonbeam:

  - The [dynamic fee mechanism](https://forum.moonbeam.network/t/proposal-status-idea-dynamic-fee-mechanism-for-moonbeam-and-moonriver/241){target=\_blank} resembles that of [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559){target=\_blank} but the implementation is different

  - The amount of gas used in Moonbeam's transaction fee model is mapped from the transaction's Substrate extrinsic `refTime` component of the transaction weight via a fixed factor of `{{ networks.moonbase.tx_weight_to_gas_ratio }}` and `proofSize` component of the transaction weight via a fixed factor of `{{ xcm.generic_weights.proof_size.weight_per_gas }}`. The transaction weight vector is then multiplied with the unit gas price to calculate the transaction fee. This fee model means it can potentially be significantly cheaper to send transactions such as basic balance transfers via the Ethereum API than the Substrate API.

  - The EVM is designed to solely have capacity for gas and Moonbeam requires additional metrics outside of gas. In particular, Moonbeam needs the ability to record proof size, which is the amount of storage required on Moonbeam for a relay chain validator to verify a state transition. When the capacity limit for proof size has been reached for the current block, which is 25% of the block limit, an "Out of Gas" error will be thrown. This can happen even if there is remaining *legacy* gas in the gasometer. This additional metric also impacts refunds. Refunds are based on the more consumed resource after the execution. In other words, if more proof size has been consumed proportionally than legacy gas, the refund will be calculated using proof size

  - Moonbeam has implemented a new mechanism defined in [MBIP-5](https://github.com/moonbeam-foundation/moonbeam/blob/master/MBIPS/MBIP-5.md){target=\_blank} that limits block storage and increases gas usage for transactions that result in an increase in storage

## Overview of MBIP-5 {: #overview-of-mbip-5 }

MBIP-5 introduced changes to Moonbeam's fee mechanism that account for storage growth on the network, which deviates from the way Ethereum handles fees. By raising the gas needed to execute transactions that increase chain state and by establishing a block storage limit, it controls storage growth.

This impacts contract deployments that add to the chain state, transactions that create new storage entries, and precompiled contract calls that result in the creation of new accounts.

The block storage limit prevents transactions in a single block from collectively increasing the storage state by more than the limit. The limit for each network is as follows:

=== "Moonbeam"

    ```text
    {{ networks.moonbeam.mbip_5.block_storage_limit }}KB
    ```

=== "Moonriver"

    ```text
    {{ networks.moonriver.mbip_5.block_storage_limit }}KB
    ```

=== "Moonbase Alpha"

    ```text
    {{ networks.moonbase.mbip_5.block_storage_limit }}KB
    ```

To determine the amount of gas for storage in bytes, there is a ratio that is defined as:

```text
Ratio = Block Gas Limit / (Block Storage Limit * 1024 Bytes)
```

The block gas limit for each network is as follows:

=== "Moonbeam"

    ```text
    {{ networks.moonbeam.gas_block }}
    ```

=== "Moonriver"

    ```text
    {{ networks.moonriver.gas_block }}
    ```

=== "Moonbase Alpha"

    ```text
    {{ networks.moonbase.gas_block }}
    ```

Knowing the block gas and storage limits, the ratio of gas to storage is computed as follows:

=== "Moonbeam"

    ```text
    Ratio = {{ networks.moonbeam.gas_block_numbers_only }} / ({{ networks.moonbeam.mbip_5.block_storage_limit }} * 1024)
    Ratio = {{ networks.moonbeam.mbip_5.gas_storage_ratio }} 
    ```

=== "Moonriver"

    ```text
    Ratio = {{ networks.moonriver.gas_block_numbers_only }} / ({{ networks.moonriver.mbip_5.block_storage_limit }} * 1024)
    Ratio = {{ networks.moonriver.mbip_5.gas_storage_ratio }} 
    ```

=== "Moonbase Alpha"

    ```text
    Ratio = {{ networks.moonbase.gas_block_numbers_only }} / ({{ networks.moonbase.mbip_5.block_storage_limit }} * 1024)
    Ratio = {{ networks.moonbase.mbip_5.gas_storage_ratio }} 
    ```

Then, you can take the storage growth in bytes for a given transaction and multiply it by the gas-to-storage growth ratio to determine how many units of gas to add to the transaction. For example, if you execute a transaction that increases the storage by {{ networks.moonbase.mbip_5.example_storage }} bytes, the following calculation is used to determine the units of gas to add:

=== "Moonbeam"

    ```text
    Additional Gas = {{ networks.moonbeam.mbip_5.example_storage }} * {{ networks.moonbeam.mbip_5.gas_storage_ratio }}
    Additional Gas = {{ networks.moonbeam.mbip_5.example_addtl_gas }}
    ```

=== "Moonriver"

    ```text
    Additional Gas = {{ networks.moonriver.mbip_5.example_storage }} * {{ networks.moonriver.mbip_5.gas_storage_ratio }}
    Additional Gas = {{ networks.moonriver.mbip_5.example_addtl_gas }}
    ```

=== "Moonbase Alpha"

    ```text
    Additional Gas = {{ networks.moonbase.mbip_5.example_storage }} * {{ networks.moonbase.mbip_5.gas_storage_ratio }}
    Additional Gas = {{ networks.moonbase.mbip_5.example_addtl_gas }}
    ```

To see how this MBIP differentiates Moonbeam from Ethereum firsthand, you can estimate the gas for two different contract interactions on both networks: one that modifies an item in the chain state and one that doesn't. For example, you can use a greeting contract that allows you to store a name and then use the name to say "Hello".

```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract SayHello {
    mapping(address => string) public addressToName;

    constructor(string memory _name) {
        addressToName[msg.sender] = _name;
    }

    // Store a name associated to the address of the sender
    function setName(string memory _name) public {
        addressToName[msg.sender] = _name;
    } 

    // Use the name in storage associated to the sender
    function sayHello() external view returns (string memory) {
        return string(abi.encodePacked("Hello ", addressToName[msg.sender]));
    }
}
```

You can deploy this contract on both Moonriver and Ethereum, or on Moonbeam's TestNet, Moonbase Alpha, and Ethereum's TestNet, Sepolia. The above contract has already been deployed to Moonbase Alpha and Sepolia. You can feel free to access these contracts at the following addresses:

=== "Moonbase Alpha"

    ```text
    0xDFF8E772A9B212dc4FbA19fa650B440C5c7fd7fd
    ```

=== "Sepolia"

    ```text
    0x8D0C059d191011E90b963156569A8299d7fE777d
    ```

Next, you can use the `eth_estimateGas` method to check the gas estimate for calling the `setName` and `sayHello` functions on each network. To do so, you'll need the bytecode for each transaction, which includes the function selector, and for the `setName` function, the name to be set. This example bytecode sets the name to "Chloe":

=== "Set Name"

    ```text
    0xc47f00270000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000543686c6f65000000000000000000000000000000000000000000000000000000
    ```

=== "Say Hello"

    ```text
    0xef5fb05b
    ```

Now, you can use the following curl commands on Moonbase Alpha to return the gas estimate:

=== "Set Name"

    ```sh
    curl {{ networks.moonbase.rpc_url }} -H "Content-Type:application/json;charset=utf-8" -d \
    '{
        "jsonrpc": "2.0",
        "id": 1,
        "method": "eth_estimateGas",
        "params":[{
            "to": "0xDFF8E772A9B212dc4FbA19fa650B440C5c7fd7fd",
            "data": "0xc47f00270000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000543686c6f65000000000000000000000000000000000000000000000000000000"
        }]
    }'
    ```

=== "Say Hello"

    ```sh
    curl {{ networks.moonbase.rpc_url }} -H "Content-Type:application/json;charset=utf-8" -d \
    '{
        "jsonrpc": "2.0",
        "id": 1,
        "method": "eth_estimateGas",
        "params":[{
            "to": "0xDFF8E772A9B212dc4FbA19fa650B440C5c7fd7fd",
            "data": "0xef5fb05b"
        }]
    }'
    ```

Then on Sepolia, you can use the same bytecode for the `data` and modify the RPC URL and contract address to target the contract deployed to Sepolia:

=== "Set Name"

    ```sh
    curl https://sepolia.publicgoods.network -H "Content-Type:application/json;charset=utf-8" -d \
    '{
        "jsonrpc": "2.0",
        "id": 1,
        "method": "eth_estimateGas",
        "params":[{
            "to": "0x8D0C059d191011E90b963156569A8299d7fE777d",
            "data": "0xc47f00270000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000543686c6f65000000000000000000000000000000000000000000000000000000"
        }]
    }'
    ```

=== "Say Hello"

    ```sh
    curl https://sepolia.publicgoods.network -H "Content-Type:application/json;charset=utf-8" -d \
    '{
        "jsonrpc": "2.0",
        "id": 1,
        "method": "eth_estimateGas",
        "params":[{
            "to": "0x8D0C059d191011E90b963156569A8299d7fE777d",
            "data": "0xef5fb05b"
        }]
    }'
    ```

At the time of writing, the gas estimates for both networks are as follows:

=== "Moonbase Alpha"

    |   Method   | Gas Estimate |
    |:----------:|:------------:|
    |  `setName` |     45977    |
    | `sayHello` |     25938    |

=== "Sepolia"

    |   Method   | Gas Estimate |
    |:----------:|:------------:|
    |  `setName` |     21520    |
    | `sayHello` |     21064    |

You'll see that on Sepolia, the gas estimates for both calls are very similar, whereas on Moonbase Alpha, there is a noticeable difference between the calls and that the `setName` call, which modifies the storage, uses more gas than the `sayHello` call.

## Ethereum API Transaction Fees {: #ethereum-api-transaction-fees }

To calculate the fee incurred on a Moonbeam transaction sent via the Ethereum API, the following formula can be used:

=== "EIP-1559"

    ```text
    GasPrice = BaseFee + MaxPriorityFeePerGas < MaxFeePerGas ? 
                BaseFee + MaxPriorityFeePerGas : 
                MaxFeePerGas;
    Transaction Fee = (GasPrice * TransactionWeight) / {{ networks.moonbase.tx_weight_to_gas_ratio }}
    ```

=== "Legacy"

    ```text
    Transaction Fee = (GasPrice * TransactionWeight) / {{ networks.moonbase.tx_weight_to_gas_ratio }}
    ```

=== "EIP-2930"

    ```text
    Transaction Fee = (GasPrice * TransactionWeight) / {{ networks.moonbase.tx_weight_to_gas_ratio }}
    ```

!!! note
    EIP-1559 transaction fees on Moonbeam are calculated using the previous block's base fee.

The following sections describe in more detail each of the components needed to calculate the transaction fee.

### Base Fee {: #base-fee}

The `BaseFee` is the minimum amount charged to send a transaction and is a value set by the network itself. It was introduced in [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559){target=\_blank}. Moonbeam has its own [dynamic fee mechanism](https://forum.moonbeam.network/t/proposal-status-idea-dynamic-fee-mechanism-for-moonbeam-and-moonriver/241){target=\_blank} for calculating the base fee, which is adjusted based on block congestion. As of runtime 2300, the dynamic fee mechanism has been rolled out to all of the Moonbeam-based networks.

The minimum gas price for each network is as follows:

=== "Moonbeam"

    |     Variable      |                   Value                    |
    |:-----------------:|:------------------------------------------:|
    | Minimum Gas Price | {{ networks.moonbeam.min_gas_price }} Gwei |

=== "Moonriver"

    |     Variable      |                   Value                    |
    |:-----------------:|:------------------------------------------:|
    | Minimum Gas Price | {{ networks.moonriver.min_gas_price }} Gwei |

=== "Moonbase Alpha"

    |     Variable      |                   Value                    |
    |:-----------------:|:------------------------------------------:|
    | Minimum Gas Price | {{ networks.moonbase.min_gas_price }} Gwei |

To calculate the dynamic base fee, the following calculation is used:

=== "Moonbeam"

    ```text
    BaseFee = NextFeeMultiplier * 31250000000 / 10^18
    ```

=== "Moonriver"

    ```text
    BaseFee = NextFeeMultiplier * 312500000 / 10^18
    ```

=== "Moonbase Alpha"

    ```text
    BaseFee = NextFeeMultiplier * 31250000 / 10^18
    ```

The value of `NextFeeMultiplier` can be retrieved from the Substrate Sidecar API, via the following endpoint:

```text
GET /pallets/transaction-payment/storage/nextFeeMultiplier?at={blockId}
```

The pallets endpoints for Sidecar returns data relevant to a pallet, such as data in a pallet's storage. You can read more about the pallets endpoint in the [official Sidecar documentation](https://paritytech.github.io/substrate-api-sidecar/dist/#operations-tag-pallets){target=\_blank}. The data at hand that's required from storage is the `nextFeeMultiplier`, which can be found in the `transaction-payment` pallet. The stored `nextFeeMultiplier` value can be read directly from the Sidecar storage schema. Read as a JSON object, the relevant nesting structure is as follows:

```text
RESPONSE JSON Storage Object:
    |--at
        |--hash
        |--height
    |--pallet
    |--palletIndex
    |--storageItem
    |--keys
    |--value
```

The relevant data will be stored in the `value` key of the JSON object. This value is a fixed point data type, hence the real value is found by dividing the `value` by `10^18`. This is why [the calculation of `BaseFee`](#ethereum-api-transaction-fees) includes such an operation.

### GasPrice, MaxFeePerGas, and MaxPriorityFeePerGas {: #gasprice-maxfeepergas-maxpriorityfeepergas }

The `GasPrice` is used to specify the gas price of legacy transactions prior to [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559){target=\_blank}. The `MaxFeePerGas` and `MaxPriorityFeePerGas` were both introduced in EIP-1559 alongside the `BaseFee`. The `MaxFeePerGas` defines the maximum fee permitted to be paid per unit of gas and is the sum of the `BaseFee` and the `MaxPriorityFeePerGas`. The `MaxPriorityFeePerGas` is the maximum priority fee configured by the sender of a transaction that is used to incentivize the prioritization of a transaction in a block.

Although Moonbeam is Ethereum-compatible, it is also a Substrate-based chain at its core, and priorities work differently in Substrate than in Ethereum. In Substrate, transactions are not prioritized by gas price. To address this, Moonbeam uses a modified prioritization system that reprioritizes Substrate transactions using an Ethereum-first solution. A Substrate transaction still goes through the validity process, where it is assigned transaction tags, longevity, and a priority. The original priority is then overwritten with a new priority based on the transaction's fee per gas, which is derived from the transaction's tip and weight. If the transaction is an Ethereum transaction, the priority is set according to the priority fee.

It's important to note that priority is not the sole component responsible for determining the order of transactions in a block. Other components, such as the longevity of a transaction, also play a role in the sorting process.

The values of `GasPrice`, `MaxFeePerGas` and `MaxPriorityFeePerGas` for the applicable transaction types can be read from the block JSON object according to the structure described in [the Sidecar API page](/builders/substrate/libraries/sidecar/#evm-fields-mapping-in-block-json-object){target=\_blank}.

The data for an Ethereum transaction in a particular block can be extracted from the following block endpoint:

```text
GET /blocks/{blockId}
```

The paths to the relevant values have also been truncated and reproduced below:

=== "EIP1559"
    |      EVM Field       |                               Block JSON Field                               |
    |:--------------------:|:----------------------------------------------------------------------------:|
    |     MaxFeePerGas     |     `extrinsics[extrinsic_number].args.transaction.eip1559.maxFeePerGas`     |
    | MaxPriorityFeePerGas | `extrinsics[extrinsic_number].args.transaction.eip1559.maxPriorityFeePerGas` |

=== "Legacy"
    | EVM Field |                        Block JSON Field                         |
    |:---------:|:---------------------------------------------------------------:|
    | GasPrice  | `extrinsics[extrinsic_number].args.transaction.legacy.gasPrice` |

=== "EIP2930"
    | EVM Field |                         Block JSON Field                         |
    |:---------:|:----------------------------------------------------------------:|
    | GasPrice  | `extrinsics[extrinsic_number].args.transaction.eip2930.gasPrice` |

### Transaction Weight {: #transaction-weight}

`TransactionWeight` is a Substrate mechanism used to measure the execution time a given transaction takes to be executed within a block. A transaction's weight is a vector of two components: `refTime` and `proofSize`. `refTime` refers to the amount of computational time that can be used for execution. `proofSize` refers to the size of the PoV (Proof of Validity) of the Moonbeam block that gets submitted to the Polkadot Relay Chain for validation. Since both `refTime` and `proofSize` are integral components of determining a weight, it is impossible to obtain an accurate weight value with just one of these values.

For all transactions types, `TransactionWeight` can be retrieved under the event of the relevant extrinsic where the `method` field is set to:

```text
pallet: "system", method: "ExtrinsicSuccess" 
```

And then `TransactionWeight` is mapped to the following two fields of the block JSON object. `proofSize` is mapped as follows:

```text
extrinsics[extrinsic_number].events[event_number].data[0].weight.proof_size 
```

And `refTime` is mapped as follows:

```text
extrinsics[extrinsic_number].events[event_number].data[0].weight.ref_time 
```

### Fee History Endpoint {: #eth-feehistory-endpoint }

Moonbeam networks implement the [`eth_feeHistory`](https://www.alchemy.com/docs/node/ethereum/ethereum-api-endpoints/eth-fee-history){target_blank} JSON-RPC endpoint as a part of the support for EIP-1559.

`eth_feeHistory` returns a collection of historical gas information from which you can reference and calculate what to set for the `MaxFeePerGas` and `MaxPriorityFeePerGas` fields when submitting EIP-1559 transactions.

The following curl example will return the gas information of the last 10 blocks starting from the latest block on the respective Moonbeam network using `eth_feeHistory`:

=== "Moonbeam"

    ```sh
    curl --location \
         --request POST '{{ networks.moonbeam.rpc_url }}' \
         --header 'Content-Type: application/json' \
         --data-raw '{
            "jsonrpc": "2.0",
            "id": 1,
            "method": "eth_feeHistory",
            "params": ["0xa", "latest"]
         }'
    ```
=== "Moonriver"

    ```sh
    curl --location \
         --request POST '{{ networks.moonriver.rpc_url }}' \
         --header 'Content-Type: application/json' \
         --data-raw '{
            "jsonrpc": "2.0",
            "id": 1,
            "method": "eth_feeHistory",
            "params": ["0xa", "latest"]
         }'
    ```
=== "Moonbase Alpha"

    ```sh
    curl --location \
         --request POST '{{ networks.moonbase.rpc_url }}' \
         --header 'Content-Type: application/json' \
         --data-raw '{
            "jsonrpc": "2.0",
            "id": 1,
            "method": "eth_feeHistory",
            "params": ["0xa", "latest"]
         }'
    ```
=== "Moonbeam Dev Node"

    ```sh
    curl --location \
         --request POST '{{ networks.development.rpc_url }}' \
         --header 'Content-Type: application/json' \
         --data-raw '{
            "jsonrpc": "2.0",
            "id": 1,
            "method": "eth_feeHistory",
            "params": ["0xa", "latest"]
         }'
    ```

### Sample Code for Calculating Transaction Fees {: #sample-code }

The following code snippet uses the [Axios HTTP client](https://axios-http.com){target=\_blank} to query the [Sidecar endpoint `/blocks/head`](https://paritytech.github.io/substrate-api-sidecar/dist/#operations-tag-blocks){target=\_blank} for the latest finalized block. It then calculates the transaction fees of all transactions in the block according to the transaction type (for Ethereum API: legacy, EIP-1559 or EIP-2930 standards, and for Substrate API), as well as calculating the total transaction fees in the block.

!!! note
    EIP-1559 transaction fees on Moonbeam are calculated using the previous block's base fee.

The following code sample is for demo purposes only and should not be used without modification and further testing in a production environment.

You can use the following snippet for any Moonbeam-based network, but you'll need to modify the `baseFee` accordingly. You can refer back to the [Base Fee](#base-fee) section to get the calculation for each network.

```js
import axios from 'axios';

// This script calculates the transaction fees of all transactions in a block
// according to the transaction type (for Ethereum API: legacy, EIP-1559 or
// EIP-2930 standards, and Substrate API) using the dynamic fee mechanism.
// It also calculates the total fees in the block

// Endpoint to retrieve the latest block
const endpointBlock = 'http://127.0.0.1:8080/blocks/head';
// Endpoint to retrieve the latest nextFeeMultiplier
const endpointPallet =
  'http://127.0.0.1:8080/pallets/transaction-payment/storage/nextFeeMultiplier?at=';
// Endpoint to retrieve the node client's information
const endpointNodeVersion = 'http://127.0.0.1:8080/node/version';

// Define the minimum base fee for each network
const baseFee = {
  moonbeam: 31250000000n,
  moonriver: 312500000n,
  moonbase: 31250000n,
};

async function main() {
  try {
    // Create a variable to sum the transaction fees in the whole block
    let totalFees = 0n;

    // Find which Moonbeam network the Sidecar is pointing to
    const responseClient = await axios.get(endpointNodeVersion);
    const network = responseClient.data.clientImplName;

    // Retrieve the block from the Sidecar endpoint
    const responseBlock = await axios.get(endpointBlock);
    // Retrieve the block height of the current block
    console.log('Block Height: ' + responseBlock.data.number);

    // Use the previous block's base fee to match the on-chain data
    // Find the block's nextFeeMultiplier
    const prevBlock = Number(responseBlock.data.number) - 1;
    const responsePallet = await axios.get(endpointPallet + prevBlock);

    // Iterate through all extrinsics in the block
    responseBlock.data.extrinsics.forEach((extrinsic) => {
      // Create an object to store transaction information
      let transactionData = new Object();
      // Set the network field
      transactionData['network'] = network;

      // Filter for Ethereum Transfers
      if (
        extrinsic.method.pallet === 'ethereum' &&
        extrinsic.method.method === 'transact'
      ) {
        // Iterate through the events to get non type specific parameters
        extrinsic.events.forEach((event) => {
          if (
            event.method.pallet === 'ethereum' &&
            event.method.method === 'Executed'
          ) {
            // Get Transaction Hash
            transactionData['hash'] = event.data[2];
          }
          if (
            event.method.pallet === 'system' &&
            event.method.method === 'ExtrinsicSuccess'
          ) {
            // Add correction weight if needed to Transaction Weight!
            transactionData['weight'] = BigInt(event.data[0].weight.refTime);
          }
        });

        // Get the transaction type and type specific parameters and compute the
        // transaction fee
        if (extrinsic.args.transaction.legacy) {
          transactionData['txType'] = 'legacy';
          transactionData['gasPrice'] = BigInt(
            extrinsic.args.transaction.legacy.gasPrice
          );
          transactionData['txFee'] =
            (transactionData['gasPrice'] * transactionData['weight']) / 25000n;
        } else if (extrinsic.args.transaction.eip1559) {
          transactionData['txType'] = 'eip1599';
          transactionData['maxFeePerGas'] = BigInt(
            extrinsic.args.transaction.eip1559.maxFeePerGas
          );
          transactionData['maxPriorityFeePerGas'] = BigInt(
            extrinsic.args.transaction.eip1559.maxPriorityFeePerGas
          );
          // Update based on the network you're getting tx fees for
          transactionData['baseFee'] =
            (BigInt(responsePallet.data.value) * baseFee.moonbeam) /
            BigInt('1000000000000000000');

          // Gas price dependes on the MaxFeePerGas and MaxPriorityFeePerGas set
          transactionData['gasPrice'] =
            transactionData['baseFee'] +
              transactionData['maxPriorityFeePerGas'] <
            transactionData['maxFeePerGas']
              ? transactionData['baseFee'] +
                transactionData['maxPriorityFeePerGas']
              : transactionData['maxFeePerGas'];

          transactionData['txFee'] =
            (transactionData['gasPrice'] * transactionData['weight']) / 25000n;
        } else if (extrinsic.args.transaction.eip2930) {
          transactionData['txType'] = 'eip2930';
          transactionData['gasPrice'] = BigInt(
            extrinsic.args.transaction.eip2930.gasPrice
          );
          transactionData['txFee'] =
            (transactionData['gasPrice'] * transactionData['weight']) / 25000n;
        }

        // Increment totalFees
        totalFees += transactionData['txFee'];

        // Display the tx information to console
        console.log(transactionData);
      }
      // Filter for Substrate transactions, check if the extrinsic has a
      // 'TransactionFeePaid' event
      else {
        extrinsic.events.forEach((event) => {
          if (
            event.method.pallet === 'transactionPayment' &&
            event.method.method === 'TransactionFeePaid'
          ) {
            transactionData['txType'] = 'substrate';
            transactionData['txFee'] = event.data[1];
            transactionData['tip'] = event.data[1];
          }
          if (
            event.method.pallet === 'system' &&
            event.method.method === 'ExtrinsicSuccess'
          ) {
            transactionData['weight'] = event.data[0].weight.refTime;
          }
        });
      }
    });

    // Output the total amount of fees in the block
    console.log('Total fees in block: ' + totalFees);
  } catch (err) {
    console.log(err);
  }
}

main();
```

## Substrate API Transaction Fees {: #substrate-api-transaction-fees }

This section of the guide assumes you are interacting with Moonbeam blocks via [the Substrate API Sidecar](/builders/substrate/libraries/sidecar/){target=\_blank} service. There are other ways of interacting with Moonbeam blocks, such as using [the Polkadot.js API library](/builders/substrate/libraries/polkadot-js-api/){target=\_blank}. The logic is identical once the blocks are retrieved.

You can reference the [Substrate API Sidecar page](/builders/substrate/libraries/sidecar/){target=\_blank} for information on installing and running your own Sidecar service instance, as well as more details on how to decode Sidecar blocks for Moonbeam transactions.

**Note that the information in this section assumes you are running version {{ networks.moonbase.substrate_api_sidecar.stable_version }} of the Substrate Sidecar REST API.**

All the information around fee data for transactions sent via the Substrate API can be extracted from the following block endpoint:

```text
GET /blocks/{blockId}
```

The block endpoints will return data relevant to one or more blocks. You can read more about the block endpoints on the [official Sidecar documentation](https://paritytech.github.io/substrate-api-sidecar/dist/#operations-tag-blocks){target=\_blank}. Read as a JSON object, the relevant nesting structure is as follows:  

```text
RESPONSE JSON Block Object:
    ...
    |--number
    |--extrinsics
        |--{extrinsic_number}
            |--method
            |--signature
            |--nonce
            |--args
            |--tip           
            |--hash
            |--info
            |--era
            |--events
                |--{event_number}
                    |--method
                        |--pallet: "transactionPayment"
                        |--method: "TransactionFeePaid"
                    |--data
                        |--0
                        |--1
                        |--2
    ...

```

The object mappings are summarized as follows:

|   Tx Information   |                      Block JSON Field                       |
|:------------------:|:-----------------------------------------------------------:|
| Fee paying account | `extrinsics[extrinsic_number].events[event_number].data[0]` |
|  Total fees paid   | `extrinsics[extrinsic_number].events[event_number].data[1]` |
|        Tip         | `extrinsics[extrinsic_number].events[event_number].data[2]` |

The transaction fee related information can be retrieved under the event of the relevant extrinsic where the `method` field is set to:

```text
pallet: "transactionPayment", method: "TransactionFeePaid" 
```

And then the total transaction fee paid for this extrinsic is mapped to the following field of the block JSON object:

```text
extrinsics[extrinsic_number].events[event_number].data[1]
```

<div class="page-disclaimer">
  The information presented herein has been provided by third parties and is made available solely for general information purposes. Moonbeam does not endorse any project listed and described on the Moonbeam Doc Website (https://docs.moonbeam.network/). Moonbeam Foundation does not warrant the accuracy, completeness or usefulness of this information. Any reliance you place on such information is strictly at your own risk. Moonbeam Foundation disclaims all liability and responsibility arising from any reliance placed on this information by you or by anyone who may be informed of any of its contents. All statements and/or opinions expressed in these materials are solely the responsibility of the person or entity providing those materials and do not necessarily represent the opinion of Moonbeam Foundation. The information should not be construed as professional or financial advice of any kind. Advice from a suitably qualified professional should always be sought in relation to any particular matter or circumstance. The information herein may link to or integrate with other websites operated or content provided by third parties, and such other websites may link to this website. Moonbeam Foundation has no control over any such other websites or their content and will have no liability arising out of or related to such websites or their content. The existence of any such link does not constitute an endorsement of such websites, the content of the websites, or the operators of the websites. These links are being provided to you only as a convenience and you release and hold Moonbeam Foundation harmless from any and all liability arising from your use of this information or the information provided by any third-party website or service.
</div>
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/learn/core-concepts/unified-accounts/
--- BEGIN CONTENT ---
---
title: Unified Accounts
description:  Moonbeam replaced the default Substrate account system with native support for the Ethereum-based H160 accounts and ECDSA keys. Find out more information!
categories: Basics
---

# Unified Accounts

## Introduction {: #introduction }

As Moonbeam is designed to be an Ethereum-compatible parachain on Polkadot, the underlying account system replaces the default Substrate-style accounts and keys with Ethereum-style accounts and keys. As a result, you can interact with your Moonbeam account using [MetaMask](/tokens/connect/metamask/){target=\_blank} and Ethereum tools you may already be familiar with, such as [Remix](/builders/ethereum/dev-env/remix/){target=\_blank} and [Hardhat](/builders/ethereum/dev-env/hardhat/){target=\_blank}.

You can also interact with your Moonbeam account using Polkadot.js Apps as it natively supports H160 addresses and ECDSA keys. For more information on this integration, you can check out the [Interacting with Moonbeam Using Polkadot.js Apps](/tokens/connect/polkadotjs/){target=\_blank} guide.

## Substrate EVM Compatible Blockchain {: #substrate-evm-compatible-blockchain }

Any parachain in the Polkadot ecosystem can offer a full EVM implementation, which provides the possibility of executing Solidity-based smart contracts with minimal to no changes. Substrate makes this integration possible - just plug the [EVM pallet](https://docs.rs/pallet-evm/2.0.1/pallet_evm){target=\_blank} into your runtime for EVM support, and the [Ethereum Pallet with Frontier](https://github.com/polkadot-evm/frontier){target=\_blank} to have Ethereum RPC compatibility. The availability of these open-source modules that Moonbeam has developed with Parity has led multiple parachains to offer Ethereum compatibility on their chains.

But there is an important catch. With the configuration described above, a user, for example, Alice, can have an Ethereum-style address (H160 format), which is 40+2 hex-characters long, in a Substrate based chain. This address matches a private key, which can be used to sign transactions in the Ethereum side of the chain. Furthermore, the address is mapped into a storage slot inside the Substrate Balance pallet to a Substrate-style address (H256 format).

However, Alice only knows the private key of the H160 address, and not of the mapped version. Therefore, she is unable to send transactions with her H256 address and is limited only to do read-only operations through Substrate’s API. As a consequence, Alice needs another H256 address matching a different private key to be able to operate in the Substrate side of the chain, which include, among others, staking, balances, and governance.

The following diagram illustrates this configuration.

![Old account system diagram](/images/learn/core-concepts/unified-accounts/unified-accounts-1.webp)

This can creates friction and a poor user experience for Alice. First, she has to move tokens to her H160 mapped H256 address to be able to make transactions and deploy contracts through the EVM. Second, she also needs to hold a balance in her other H256 address (which she has a different private key for) to use Substrate-based features. So in short, Alice needs a minimum of two private keys to have the best of both worlds.

## Moonbeam Unified Accounts {: #moonbeam-unified-accounts }

Moonbeam’s focus is to create a fully Ethereum-compatible environment on Polkadot with the best user experience possible. This extends beyond the base Ethereum feature set, with additional features such as on-chain governance, staking, and cross-chain integrations.

With unified accounts, a user, for example, Bob, will only need a single H160 address, with its corresponding private key, to do everything we mentioned above, including both EVM and Substrate functions.

The diagram for this new configuration looks as follows.

![New account system diagram](/images/learn/core-concepts/unified-accounts/unified-accounts-2.webp)

That is it, Bob only holds one private key that matches one address. He does not need to move balances between 2 different accounts and is able to access all the features with a single account and private key. We have standardized this single account to conform to the Ethereum-style H160 address and ECDSA key standards.
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/learn/features/consensus/
--- BEGIN CONTENT ---
---
title: Moonbeam's Nimbus Consensus Framework
description: Learn about all the parts of Moonbeam's Nimbus consensus framework and how it works as part of Polkadot's shared security model.
categories: Basics
---

# Nimbus Parachain Consensus Framework

## Introduction {: #introduction }

Polkadot relies on a [hybrid consensus model](https://docs.polkadot.com/polkadot-protocol/architecture/polkadot-chain/pos-consensus/). In such a scheme, the block finality gadget and the block production mechanism are separate. Consequently, parachains only have to worry about producing blocks and rely on the relay chain to validate the state transitions.

At a parachain level, block producers are called [collators](https://wiki.polkadot.com/learn/learn-collator/). They maintain parachains (such as Moonbeam) by collecting transactions from users and offering blocks to the relay chain [validators](https://wiki.polkadot.com/learn/learn-validator/).

However, parachains might find the following problems they need to solve in a trustless and decentralized matter (if applicable):

 - Amongst all of the nodes in the network, which ones are allowed to author blocks?
 - If multiple nodes are allowed, will they be eligible at the same time? Only one? Maybe a few?

Enter Nimbus. Nimbus is a framework for building slot-based consensus algorithms on [Cumulus](https://github.com/paritytech/polkadot-sdk/tree/master/cumulus)-based parachains. It strives to provide standard implementations for the logistical parts of such consensus engines and helpful traits for implementing the elements (filters) that researchers and developers want to customize. These filters can be customizable to define what a block authorship slot is and can be composed, so block authorship is restricted to a subset of collators in multiple steps.

For example, Moonbeam uses a two-layer approach. The first layer comprises the parachain staking filter, which helps select an active collator pool among all collator candidates using a staked-based ranking. The second layer adds another filter which narrows down the number of collators to a subset for each slot.

Notice that Nimbus can only answer which collator(s) are eligible to produce a parachain block in the next available slot. It is the [Cumulus](https://docs.polkadot.com/develop/parachains/#cumulus) consensus mechanism that marks this parachain block as best, and ultimately the [BABE](https://docs.polkadot.com/polkadot-protocol/architecture/polkadot-chain/pos-consensus/#babe) and [GRANDPA](https://docs.polkadot.com/polkadot-protocol/architecture/polkadot-chain/pos-consensus/#grandpa-finality-gadget) hybrid consensus model (of the relay chain) that will include this parachain block in the relay chain and finalize it. Once any relay chain forks are resolved at a relay chain level, that parachain block is deterministically finalized.

The following two sections go over the filtering strategy currently used on Moonbeam.

## Parachain Staking Filtering {: #parachain-staking-filtering }

Collators can join the candidate pool by simply bonding some tokens via an extrinsic. Once in the pool, token holders can add to the candidate's stake via delegation (also referred to as staking), that is, at a parachain level.

Parachain staking is the first of the two Nimbus filters applied to the candidate pool. It selects the top {{ networks.moonbase.staking.max_candidates }} candidates in terms of tokens staked in the network, which includes the candidate's bond and delegations from token holders. This filtered pool is called selected candidates, and selected candidates are renewed every round (which lasts {{ networks.moonbase.staking.round_blocks }} blocks). For a given round, the following diagram describes the parachain staking filtering:

![Nimbus Parachain Staking Filter](/images/learn/features/consensus/consensus-1.webp)

From this pool, another filter is applied to retrieve a subset of eligible candidates for the next block authoring slot.

If you want to learn more about staking, visit our [staking documentation](/learn/features/staking/).

## Fixed Size Subset Filtering {: #fixed-size-subset-filtering }

Once the parachain staking filter is applied and the selected candidates are retrieved, a second filter is applied on a block by block basis and helps narrow down the selected candidates to a smaller number of eligible collators for the next block authoring slot.

In broad terms, this second filter picks a pseudo-random subset of the previously selected candidates. The eligibility ratio, a tunable parameter, defines the size of this subset.

A high eligibility ratio results in fewer chances for the network to skip a block production slot, as more collators will be eligible to propose a block for a specific slot. However, only a certain number of validators are assigned to a parachain, meaning that most of these blocks will not be backed by a validator. For those that are, a higher number of backed blocks means that it might take longer for the relay chain to solve any possible forks and return a finalized block. Moreover, this might create an unfair advantage for certain collators that might be able to get their proposed block faster to relay chain validators, securing a higher portion of block rewards (if any).

A lower eligibility ratio might provide faster block finalization times and a fairer block production distribution amongst collators. However, if the eligible collators are not able to propose a block (for whatever reason), the network will skip a block, affecting its stability.

Once the size of the subset is defined, collators are randomly selected using a source of entropy. Currently, an internal coin-flipping algorithm is implemented, but this will later be migrated to use [Verifiable random function](https://docs.polkadot.com/polkadot-protocol/parachain-basics/randomness/){target=\_blank}. Consequently, a new subset of eligible collators is selected for every relay chain block. For a given round and a given block `XYZ`, the following diagram describes the fixed-size subset filtering:

![Nimbus Parachain Staking Filter](/images/learn/features/consensus/consensus-2.webp)

## Why Nimbus? {: #why-nimbus }

You might ask yourself: but why Nimbus? Initially, it was not envisioned when Moonbeam was being developed. As Moonbeam progressed, the necessity for a more customizable but straightforward parachain consensus mechanism became clear, as the available methods presented some drawbacks or technical limitations.

<!-- In the [relay chain provided consensus](https://github.com/paritytech/cumulus/blob/master/client/consensus/relay-chain/src/lib.rs), each node sees itself as a collator and can propose a parachain candidate block. It is then up to the relay chain to solve any possible forks and finalize a block. 

[AuRa](https://crates.io/crates/sc-consensus-aura) (short for authority-round) consensus mechanism is based on a known list of authorities that take turns to produce blocks in every slot. Each authority can propose only one block per slot and builds on top of the longest chain.-->

With Nimbus, writing a parachain consensus engine is as easy as writing a pallet! This simplicity and flexibility is the main value it adds.

Some technical benefits of Nimbus are considered in the following sections.

### Weight and Extra Execution {: #weight-and-extra-execution }

Nimbus puts the author-checking execution in a [Substrate pallet](https://docs.polkadot.com/develop/parachains/customize-parachain/overview/). At first glance, you might think this adds a higher execution load to a single block compared to doing this check off-chain. But consider this from a validator’s perspective

The validators will also have to check the author. By putting the author-checking execution logic in a pallet, the execution time can be benchmarked and quantified with weights. If this execution time is not accounted for, there is the risk of a block exceeding the relay chain Wasm execution limit (currently 0.5 seconds).

In practice, this check will be fast and will most likely not push execution time over the limit. But from a theoretical perspective, accounting for its weight is better for implementation purposes.

### Reusability {: #reusability }

Another benefit of moving the author-checking execution to a pallet, rather than a custom executor, is that one single executor can be reused for any consensus that can be expressed in the Nimbus framework. That is slot-based, signature-sealed algorithms.

For example, the [relay-chain provided consensus](https://github.com/paritytech/polkadot-sdk/blob/master/cumulus/client/consensus/relay-chain/src/lib.rs), [AuRa](https://crates.io/crates/sc-consensus-aura) and [BABE](https://crates.io/crates/sc-consensus-babe) each have their own custom executor. With Nimbus, these consensus mechanisms can reuse the same executor. The power of reusability is evidenced by the Nimbus implementation of AuRa in less than 100 lines of code.

### Hot-Swapping Consensus {: #hot-swapping-consensus }

Teams building parachains may want to change, tune, or adjust their consensus algorithm from time to time. Without nimbus, swapping consensus would require a client upgrade and hard fork.

With the Nimbus framework, writing a consensus engine is as easy as writing a
[Substrate pallet](https://docs.polkadot.com/develop/parachains/customize-parachain/make-custom-pallet/). Consequently, swapping consensus is as easy as upgrading a pallet.

Nonetheless, hot swapping is still bounded by consensus engines (filters) that fit within Nimbus, but it might be helpful for teams that are yet confident on what consensus they want to implement in the long run.
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/learn/features/eth-compatibility/
--- BEGIN CONTENT ---
---
title: Ethereum Compatibility
description: Transitioning from Ethereum to Moonbeam? Here's a brief overview of the key components and key differences of Moonbeam's Ethereum compatibility.
categories: Basics
---

# Ethereum Compatibility

Moonbeam bridges the Ethereum and Polkadot ecosystems, offering developers the familiarity of Ethereum's tooling and infrastructure while leveraging Polkadot's scalability and interoperability.

This documentation overviews Moonbeam's Ethereum compatibility features and highlights its key components. It also covers some critical differences between Moonbeam and Ethereum so Ethereum developers know what to expect.

## Key Components {: #key-components }

### EVM Compatibility {: #evm }

Moonbeam incorporates a fully compatible EVM to execute smart contracts in Solidity or other EVM-compatible languages. This enables developers to deploy existing Ethereum smart contracts on Moonbeam with minimal modifications.

Learn more:

- [Moonbeam's Ethereum-compatibility architecture](/learn/platform/technology/#ethereum-compatibility-architecture){target=\_blank}

### Ethereum-style Accounts {: #ethereum-style-accounts }

Moonbeam employs H160 Ethereum-style accounts and ECDSA keys, ensuring compatibility with existing Ethereum wallets and facilitating a smooth end-user experience. This is possible due to Moonbeam's unified accounts system, which modifies the underlying Substrate account system to use Ethereum accounts by default.

Learn more:

- [Moonbeam's unified accounts system](/learn/core-concepts/unified-accounts/){target=\_blank}

### JSON-RPC Support {: #json-rpc-support }

Moonbeam offers full JSON-RPC compatibility with Ethereum, allowing developers to interact with Moonbeam nodes using familiar Ethereum tools and libraries. This compatibility extends to methods for account management, transaction submission, smart contract deployment, and event monitoring.

In addition to standard Ethereum RPC methods, Moonbeam supports non-standard Debug and Trace modules, providing developers with enhanced debugging and tracing capabilities for smart contract execution. The Debug module allows developers to inspect internal state transitions and execution traces, enabling efficient debugging of complex smart contracts. The Trace module provides detailed transaction traces, including opcode-level execution information and gas consumption, facilitating performance analysis and optimization.

Learn more:

- [Supported Ethereum RPC methods](/builders/ethereum/json-rpc/eth-rpc/){target=\_blank}
- [Subscribe to events with Ethereum JSON-RPC methods](/builders/ethereum/json-rpc/pubsub/){target=\_blank}
- [Debug and trace transactions with non-standard RPC methods](/builders/ethereum/json-rpc/debug-trace/){target=\_blank}

### Ethereum Developer Tools and Libraries {: #ethereum-dev-tools }

With the underlying support for Ethereum JSON-RPC methods, Moonbeam leverages Ethereum's rich ecosystem of developer libraries and environments. With seamless integration of popular Ethereum libraries and development environments, developers can leverage their existing knowledge and tooling to build and deploy decentralized applications (DApps) on Moonbeam.

Learn more:

- [Ethereum libraries](/builders/ethereum/libraries/){target=\_blank}
- [Ethereum development environments](/builders/ethereum/libraries/){target=\_blank}

### Precompiled Contracts {: #precompiled-contracts }

Moonbeam provides precompiled contracts that allow Ethereum smart contracts to seamlessly access Substrate functionality. These precompiled contracts expose Substrate features such as on-chain governance, staking, and identity management to Ethereum-based DApps on Moonbeam. This integration ensures that Ethereum developers can harness the full potential of Moonbeam's features, expanding the possibilities for dApp development on Moonbeam.

In addition, developers can leverage Ethereum MainNet precompiles seamlessly within their smart contracts on Moonbeam. These precompiled contracts, widely used on the Ethereum network, offer optimized and efficient execution of common cryptographic operations and complex computations. By supporting Ethereum MainNet precompiles, Moonbeam ensures compatibility with Ethereum-based dApps while enabling developers to utilize familiar tools and libraries to build on its platform.

Learn more:

- [Overview of the precompiled contracts on Moonbeam](/builders/ethereum/precompiles/overview/){target=\_blank}

### Ethereum Token Standards {: #ethereum-token-standards }

Moonbeam supports Ethereum token standards, allowing developers to deploy and interact with tokens that adhere to popular standards such as ERC-20, ERC-721, and ERC-1155. By supporting these standards, Moonbeam enables developers to deploy existing Ethereum tokens without modification.

Due to Moonbeam's native interoperability, ERC-20s can be sent cross-chain to other chains within the Polkadot ecosystem via Cross-Consensus Messaging (XCM).

Learn more:

- [Create common OpenZeppelin contracts such as ERC-20, ERC-721, and ERC-1155 tokens](/builders/ethereum/dev-env/openzeppelin/contracts/){target=\_blank}
- [XCM-enabled ERC-20s](/builders/interoperability/xcm/xc20/overview/#local-xc20s){target=\_blank} (also referred to as local XC-20s)

## Key Differences {: #key-differences }

### Consensus Mechanisms {: #consensus-mechanisms }

Moonbeam uses a Delegated Proof-of-Stake (DPoS) consensus mechanism, where token holders in the network can delegate candidates to become block producers, known as _collators_. On the other hand, Ethereum uses a Proof-of-Stake (PoS) system in which validators are selected based on their stake in the network to produce and validate blocks.

Learn more:

- [Differences between PoS and DPoS](/learn/core-concepts/consensus-finality/#main-differences){target=_blank}

### Finality {: #finality }

Moonbeam and Ethereum have different finality processes. On Ethereum, there is a checkpoint system where validators determine finality at checkpoint blocks, which takes at least 6.4 minutes for a block to be finalized. Moonbeam relies on Polkadot's [GRANDPA](https://docs.polkadot.com/polkadot-protocol/architecture/polkadot-chain/pos-consensus/#finality-gadget-grandpa){target=\_blank} finality gadget, which expedites finality by completing the process parallel to block production and allowing relay chain validators to vote on the highest block, finalizing all blocks leading up to that block.

Learn more:

- [Consensus and finality on Moonbeam](/learn/core-concepts/consensus-finality/){target=_blank}

### Proxy Accounts {: #proxy-accounts }

On both Moonbeam and Ethereum, accounts can be controlled by two main types of accounts: Externally Owned Accounts (EOA) or smart contracts. However, on Moonbeam, within both account types, there are also proxy accounts, which can perform a limited number of actions on behalf of another account.

Learn more:

- [An overview of proxy accounts](https://wiki.polkadot.com/learn/learn-proxies/){target=\_blank}
- [How to set up a proxy account](/tokens/manage/proxy-accounts/){target=\_blank}

### Account Balances {: #account-balances }

Balances on Ethereum are fairly straightforward; if an account holds tokens, that account has a token balance. On Moonbeam, different balance types exist to support various Substrate functionality. There are five types: free, reducible, reserved, miscellaneous frozen, and fee frozen. When using Ethereum tools, accounts show the reducible balance and don't include locked or frozen balances.

Learn more:

- [Moonbeam account balances](/learn/core-concepts/balances/){target=_blank}

### Balance Transfers {: #balance-transfers }

Since Moonbeam is a Substrate-based chain, balance transfers of the native asset (GLMR, MOVR, and DEV) can occur through the Ethereum and Substrate APIs. Like Ethereum, transfers sent through the Ethereum API rely on the `eth_sendRawTransaction`. Transfers sent through the Substrate API are done using the Balances Pallet, a built-in module in the Substrate framework that provides functionality for managing accounts and balances.

Learn more:

- [Balance transfers on Moonbeam](/learn/core-concepts/transfers-api/){target=_blank}

### Transaction Fees {: #transaction-fees }

Moonbeam and Ethereum calculate transaction fees differently due to variations in their underlying architectures and consensus mechanisms. The fundamental difference in how transaction fees are calculated is that Ethereum uses a gas-based fee system, and Moonbeam uses a weight-based system that maps to the gas used. Moonbeam also implements additional metrics in the underlying gas calculations, including proof size and storage costs.

Learn more:

- [Calculating transaction fees on Moonbeam](/learn/core-concepts/tx-fees/){target=\_blank}
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/learn/features/governance/
--- BEGIN CONTENT ---
---
title: Governance
description: As a Polkadot parachain, Moonbeam uses an on-chain governance system, allowing for a stake-weighted vote on public referenda.
categories: Governance, Basics
---

# Governance on Moonbeam

## Introduction {: #introduction }

The goal of Moonbeam’s governance mechanism is to advance the protocol according to the desires of the community. In that shared mission, the governance process seeks to include all token holders. Any and all changes to the protocol must go through a referendum so that all token holders, weighted by stake, can have input on the decision.

Governance forums like the [Moonbeam Community Forum](https://forum.moonbeam.network){target=\_blank} and [Polkassembly](https://moonbeam.polkassembly.io/opengov){target=\_blank} enable open discussion and allow proposals to be refined based on community input. Autonomous enactments and [forkless upgrades](https://docs.polkadot.com/develop/parachains/maintenance/runtime-upgrades/#forkless-upgrades){target=\_blank} unite the community towards a shared mission to advance the protocol.

With the rollout of OpenGov (originally referred to as Gov2), the second phase of governance in Polkadot, several modifications have been introduced to the governance process. You can read the [OpenGov: What is Polkadot Gov2](https://moonbeam.network/news/opengov-what-is-polkadot-gov2){target=\_blank} blog post, which provides an overview of all of the changes made in OpenGov.

As of runtime 2400, all Moonbeam networks use OpenGov as their governance system.

## Principles {: #principles }

Guiding "soft" principles for engagement with Moonbeam's governance process include:

 - Being inclusive to token holders that want to engage with Moonbeam and that are affected by governance decisions
 - Favoring token holder engagement, even with views contrary to our own, versus a lack of engagement
 - A commitment to openness and transparency in the decision-making process
 - Working to keep the greater good of the network above personal gain
 - Acting at all times as a moral agent that considers the consequences of action (or inaction) from a moral standpoint
 - Being patient and generous in our interactions with other token holders, but not tolerating abusive or destructive language, actions, and behavior, and abiding by [Moonbeam’s Code of Conduct](https://github.com/moonbeam-foundation/code-of-conduct){target=\_blank}

These points were heavily inspired by Vlad Zamfir’s writings on governance. Refer to his articles, especially the [How to Participate in Blockchain Governance in Good Faith (and with Good Manners)](https://medium.com/@Vlad_Zamfir/how-to-participate-in-blockchain-governance-in-good-faith-and-with-good-manners-bd4e16846434){target=\_blank} Medium article.

## On-Chain Governance Mechanics {: #on-chain-governance-mechanics }

The "hard" governance process for Moonbeam will be driven by an on-chain process that allows the majority of tokens on the network to determine the outcomes of key decisions around the network. These decision points come in the form of stake-weighted voting on proposed referenda.

Some of the main components of this governance model include:

 - **Referenda** — a stake-based voting scheme where each referendum is tied to a specific proposal for a change to the Moonbeam system including values for key parameters, code upgrades, or changes to the governance system itself
 - **Voting** — referenda will be voted on by token holders on a stake-weighted basis. Referenda which pass are subject to delayed enactment so that people who disagree with the direction of the decision have time to exit the network
 - **Council & Technical Committee Governance V1** — a group of community members who have special voting rights within the system. With the deprecation and removal of Governance v1, both of these committees were dissolved as of the [runtime 2800 release](https://forum.moonbeam.network/t/runtime-rt2801-schedule/1616/4){target=\_blank}
 - **OpenGov Technical Committee** — a group of community members who can add certain proposals to the Whitelisted Track

For more details on how these Substrate frame pallets implement on-chain governance, you can checkout the [Walkthrough of Polkadot’s Governance](https://polkadot.com/blog/a-walkthrough-of-polkadots-governance){target=\_blank} blog post and the [Polkadot Governance Wiki](https://wiki.polkadot.com/learn/learn-polkadot-opengov/){target=\_blank}.

## Governance v2: OpenGov {: #opengov }

This section will cover everything you need to know about OpenGov on Moonbeam.

### General Definitions {: #general-definitions-gov2 }

- **Proposal** — an action or item, defined by the preimage hash, being proposed by a token holder and open for consideration and discussion by token holders
 - **Referendum** — a proposal that is up for token-holder voting. Each referendum is tied to a specific proposal for a change to the Moonbeam system including values for key parameters, code upgrades, or changes to the governance system itself

- **Preimage hash** — hash of the proposal to be enacted. The first step to make a proposal is to submit a preimage. The hash is just its identifier. The proposer of the preimage can be different than the user that proposes that preimage as a formal proposal
 - **Preimage deposit** — amount of tokens that the proposer needs to bond when submitting a preimage. It is calculated as the sum of a base deposit per network plus a fee per byte of the preimage being proposed

 - **Origin** - an authorization-based dispatch source for an operation, which is used to determine the Track that a referendum is posted under
 - **Track** - an Origin-specific pipeline that outlines the life cycle of proposals. Currently, there are five Tracks:

    |    Origin Track     |                                   Description                                    |                         Referendum Examples                          |
    |:-------------------:|:--------------------------------------------------------------------------------:|:--------------------------------------------------------------------:|
    |        Root         |                                Highest privilege                                 |           Runtime upgrades, Technical Committee management           |
    |     Whitelisted     | Proposals to be whitelisted by the Technical Committee before being dispatched |                       Fast-tracked operations                        |
    |    General Admin    |                          For general on-chain decisions                          | Changes to XCM fees, Orbiter program, Staking parameters, Registrars |
    | Emergency Canceller |          For cancellation of a referendum. Decision Deposit is refunded          |                    Wrongly constructed referendum                    |
    |  Emergency Killer   |       For killing of bad/malicious referendum. Decision Deposit is slashed       |                         Malicious referendum                         |
    | Fast General Admin  |                      For faster general on-chain decisions                       |                       HRMP channel management                        |

Tracks have different criteria parameters that are proportional to their level of Origin class. For example, more dangerous and privileged referenda will have more safeguards, higher thresholds, and longer consideration periods for approval. Please refer to the [Governance Parameters](#governance-parameters-v2) section for more information.

- **Voting** — a mechanism for token holders to support (Aye), oppose (Nay), or remain neutral (Abstain) on a proposal. For Aye and Nay, the voting weight is determined by both the number of tokens locked and the lock duration (Conviction). Abstain votes do not receive additional weighting
    - **Conviction** — the time that token holders voluntarily lock their tokens when voting; the longer they are locked, the more weight their vote has
    - **Lock balance** — the number of tokens that a user commits to a vote (note, this is not the same as a user's total account balance)
    Moonbeam uses the concept of voluntary locking, which allows token holders to increase their voting power by locking tokens for a longer period of time. Specifying no Lock Period means a user's vote is valued at 10% of their lock balance. Specifying a greater Conviction increases voting power. For each increase in Conviction (vote multiplier), the Lock Periods double

- **Approval** — minimum "Aye" votes as a percentage of overall Conviction-weighted votes needed for approval
 - **Support** — the minimum portion of Aye and Abstain votes (ignoring conviction) needed as a percentage of the total active supply for a proposal to pass. Nay votes do not count toward Support

- **Lead-in Period** — the initial proposal voting and discussion period. At this stage, proposals are in an undecided state until they pass some criteria for the given Track. The criteria include:
    - **Prepare Period** — the minimum time the referendum needs to wait before it can progress to the next phase after submission
    - **Capacity** — limit for the number of referenda on a given Track that can be decided at once
    - **Decision Deposit** — the minimum deposit amount required for a referendum to progress to the decision phase after the end of the Lead-in Period. Since each Track has a defined Capacity, this deposit is larger than the submission deposit, and its goal is to mitigate spam
    
 - **Decide Period** - token holders continue to vote on the referendum. If a referendum does not pass by the end of the period, it will be rejected, and the Decision Deposit will be refunded
 - **Confirm Period** - a period of time within the Decide Period where the referendum needs to have maintained enough Approval and Support to be approved and move to the Enactment Period
 - **Enactment Period** - a specified time, which is defined at the time the proposal was created, that an approved referendum waits before it can be dispatched. There is a minimum amount of time for each Track

- **Vote Delegation** — a voter can give their voting power, including Conviction voting, to another token holder (delegate), who may be more knowledgeable and able to make specific decisions
 - **Multirole Delegation** — the ability to delegate voting power on a Track-by-Track basis, where a token holder can specify different delegates for each Track

### Governance Parameters {: #governance-parameters-v2 }

=== "Moonbeam"  
    |          Variable           |                           Value                            |
    |:---------------------------:|:----------------------------------------------------------:|
    |    Preimage base deposit    |     {{ networks.moonbeam.preimage.base_deposit }} GLMR     |
    |  Preimage deposit per byte  |     {{ networks.moonbeam.preimage.byte_deposit }} GLMR     |
    | Proposal Submission Deposit | {{ networks.moonbeam.governance.submission_deposit }} GLMR |

=== "Moonriver"
    |          Variable           |                            Value                            |
    |:---------------------------:|:-----------------------------------------------------------:|
    |    Preimage base deposit    |     {{ networks.moonriver.preimage.base_deposit }} MOVR     |
    |  Preimage deposit per byte  |     {{ networks.moonriver.preimage.byte_deposit }} MOVR     |
    | Proposal Submission Deposit | {{ networks.moonriver.governance.submission_deposit }} MOVR |

=== "Moonbase Alpha"
    |          Variable           |                           Value                           |
    |:---------------------------:|:---------------------------------------------------------:|
    |    Preimage base deposit    |     {{ networks.moonbase.preimage.base_deposit }} DEV     |
    |  Preimage deposit per byte  |     {{ networks.moonbase.preimage.byte_deposit }} DEV     |
    | Proposal Submission Deposit | {{ networks.moonbase.governance.submission_deposit }} DEV |

#### General Parameters by Track {: #general-parameters-by-track }

=== "Moonbeam"
    |         Track          | Track ID |                                      Capacity                                       |                                Decision<br>Deposit                                 |
    |:----------------------:|:--------:|:-----------------------------------------------------------------------------------:|:----------------------------------------------------------------------------------:|
    |          Root          |    0     |        {{ networks.moonbeam.governance.tracks.root.max_deciding }} proposals        |        {{ networks.moonbeam.governance.tracks.root.decision_deposit }} GLMR        |
    |      Whitelisted       |    1     |    {{ networks.moonbeam.governance.tracks.whitelisted.max_deciding }} proposals     |    {{ networks.moonbeam.governance.tracks.whitelisted.decision_deposit }} GLMR     |
    |     General Admin      |    2     |   {{ networks.moonbeam.governance.tracks.general_admin.max_deciding }} proposals    |   {{ networks.moonbeam.governance.tracks.general_admin.decision_deposit }} GLMR    |
    | Emergency<br>Canceller |    3     |     {{ networks.moonbeam.governance.tracks.canceller.max_deciding }} proposals      |     {{ networks.moonbeam.governance.tracks.canceller.decision_deposit }} GLMR      |
    |  Emergency<br>Killer   |    4     |       {{ networks.moonbeam.governance.tracks.killer.max_deciding }} proposals       |       {{ networks.moonbeam.governance.tracks.killer.decision_deposit }} GLMR       |
    |   Fast General Admin   |    5     | {{ networks.moonbeam.governance.tracks.fast_general_admin.max_deciding }} proposals | {{ networks.moonbeam.governance.tracks.fast_general_admin.decision_deposit }} GLMR |

=== "Moonriver"
    |         Track          | Track ID |                                       Capacity                                       |                                 Decision<br>Deposit                                 |
    |:----------------------:|:--------:|:------------------------------------------------------------------------------------:|:-----------------------------------------------------------------------------------:|
    |          Root          |    0     |        {{ networks.moonriver.governance.tracks.root.max_deciding }} proposals        |        {{ networks.moonriver.governance.tracks.root.decision_deposit }} MOVR        |
    |      Whitelisted       |    1     |    {{ networks.moonriver.governance.tracks.whitelisted.max_deciding }} proposals     |    {{ networks.moonriver.governance.tracks.whitelisted.decision_deposit }} MOVR     |
    |     General Admin      |    2     |   {{ networks.moonriver.governance.tracks.general_admin.max_deciding }} proposals    |   {{ networks.moonriver.governance.tracks.general_admin.decision_deposit }} MOVR    |
    | Emergency<br>Canceller |    3     |     {{ networks.moonriver.governance.tracks.canceller.max_deciding }} proposals      |     {{ networks.moonriver.governance.tracks.canceller.decision_deposit }} MOVR      |
    |  Emergency<br>Killer   |    4     |       {{ networks.moonriver.governance.tracks.killer.max_deciding }} proposals       |       {{ networks.moonriver.governance.tracks.killer.decision_deposit }} MOVR       |
    |   Fast General Admin   |    5     | {{ networks.moonriver.governance.tracks.fast_general_admin.max_deciding }} proposals | {{ networks.moonriver.governance.tracks.fast_general_admin.decision_deposit }} MOVR |

=== "Moonbase Alpha"
    |         Track          | Track ID |                                      Capacity                                       |                                Decision<br>Deposit                                |
    |:----------------------:|:--------:|:-----------------------------------------------------------------------------------:|:---------------------------------------------------------------------------------:|
    |          Root          |    0     |        {{ networks.moonbase.governance.tracks.root.max_deciding }} proposals        |        {{ networks.moonbase.governance.tracks.root.decision_deposit }} DEV        |
    |      Whitelisted       |    1     |    {{ networks.moonbase.governance.tracks.whitelisted.max_deciding }} proposals     |    {{ networks.moonbase.governance.tracks.whitelisted.decision_deposit }} DEV     |
    |     General Admin      |    2     |   {{ networks.moonbase.governance.tracks.general_admin.max_deciding }} proposals    |   {{ networks.moonbase.governance.tracks.general_admin.decision_deposit }} DEV    |
    | Emergency<br>Canceller |    3     |     {{ networks.moonbase.governance.tracks.canceller.max_deciding }} proposals      |     {{ networks.moonbase.governance.tracks.canceller.decision_deposit }} DEV      |
    |  Emergency<br>Killer   |    4     |       {{ networks.moonbase.governance.tracks.killer.max_deciding }} proposals       |       {{ networks.moonbase.governance.tracks.killer.decision_deposit }} DEV       |
    |   Fast General Admin   |    5     | {{ networks.moonbase.governance.tracks.fast_general_admin.max_deciding }} proposals | {{ networks.moonbase.governance.tracks.fast_general_admin.decision_deposit }} DEV |

#### Period Parameters by Track {: #period-parameters-by-track }

=== "Moonbeam"
    |         Track          |                                                                                Prepare<br>Period                                                                                 |                                                                                  Decide<br>Period                                                                                  |                                                                                Confirm<br>Period                                                                                 |                                                                                 Minimum<br>Enactment Period                                                                                  |
    |:----------------------:|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|
    |          Root          |               {{ networks.moonbeam.governance.tracks.root.prepare_period.blocks }} blocks <br>({{ networks.moonbeam.governance.tracks.root.prepare_period.time }})               |               {{ networks.moonbeam.governance.tracks.root.decision_period.blocks }} blocks<br> ({{ networks.moonbeam.governance.tracks.root.decision_period.time }})               |               {{ networks.moonbeam.governance.tracks.root.confirm_period.blocks }} blocks<br> ({{ networks.moonbeam.governance.tracks.root.confirm_period.time }})               |               {{ networks.moonbeam.governance.tracks.root.min_enactment_period.blocks }} blocks<br> ({{ networks.moonbeam.governance.tracks.root.min_enactment_period.time }})               |
    |      Whitelisted       |        {{ networks.moonbeam.governance.tracks.whitelisted.prepare_period.blocks }} blocks<br> ({{ networks.moonbeam.governance.tracks.whitelisted.prepare_period.time }})        |        {{ networks.moonbeam.governance.tracks.whitelisted.decision_period.blocks }} blocks<br> ({{ networks.moonbeam.governance.tracks.whitelisted.decision_period.time }})        |        {{ networks.moonbeam.governance.tracks.whitelisted.confirm_period.blocks }} blocks<br> ({{ networks.moonbeam.governance.tracks.whitelisted.confirm_period.time }})        |        {{ networks.moonbeam.governance.tracks.whitelisted.min_enactment_period.blocks }} blocks<br> ({{ networks.moonbeam.governance.tracks.whitelisted.min_enactment_period.time }})        |
    |     General Admin      |      {{ networks.moonbeam.governance.tracks.general_admin.prepare_period.blocks }} blocks<br> ({{ networks.moonbeam.governance.tracks.general_admin.prepare_period.time }})      |      {{ networks.moonbeam.governance.tracks.general_admin.decision_period.blocks }} blocks<br> ({{ networks.moonbeam.governance.tracks.general_admin.decision_period.time }})      |      {{ networks.moonbeam.governance.tracks.general_admin.confirm_period.blocks }} blocks<br> ({{ networks.moonbeam.governance.tracks.general_admin.confirm_period.time }})      |      {{ networks.moonbeam.governance.tracks.general_admin.min_enactment_period.blocks }} blocks<br> ({{ networks.moonbeam.governance.tracks.general_admin.min_enactment_period.time }})      |
    | Emergency<br>Canceller |          {{ networks.moonbeam.governance.tracks.canceller.prepare_period.blocks }} blocks<br> ({{ networks.moonbeam.governance.tracks.canceller.prepare_period.time }})          |          {{ networks.moonbeam.governance.tracks.canceller.decision_period.blocks }} blocks<br> ({{ networks.moonbeam.governance.tracks.canceller.decision_period.time }})          |          {{ networks.moonbeam.governance.tracks.canceller.confirm_period.blocks }} blocks<br> ({{ networks.moonbeam.governance.tracks.canceller.confirm_period.time }})          |          {{ networks.moonbeam.governance.tracks.canceller.min_enactment_period.blocks }} blocks<br> ({{ networks.moonbeam.governance.tracks.canceller.min_enactment_period.time }})          |
    |  Emergency<br>Killer   |             {{ networks.moonbeam.governance.tracks.killer.prepare_period.blocks }} blocks<br> ({{ networks.moonbeam.governance.tracks.killer.prepare_period.time }})             |             {{ networks.moonbeam.governance.tracks.killer.decision_period.blocks }} blocks<br> ({{ networks.moonbeam.governance.tracks.killer.decision_period.time }})             |             {{ networks.moonbeam.governance.tracks.killer.confirm_period.blocks }} blocks<br> ({{ networks.moonbeam.governance.tracks.killer.confirm_period.time }})             |             {{ networks.moonbeam.governance.tracks.killer.min_enactment_period.blocks }} blocks<br> ({{ networks.moonbeam.governance.tracks.killer.min_enactment_period.time }})             |
    |   Fast General Admin   | {{ networks.moonbeam.governance.tracks.fast_general_admin.prepare_period.blocks }} blocks<br> ({{ networks.moonbeam.governance.tracks.fast_general_admin.prepare_period.time }}) | {{ networks.moonbeam.governance.tracks.fast_general_admin.decision_period.blocks }} blocks<br> ({{ networks.moonbeam.governance.tracks.fast_general_admin.decision_period.time }}) | {{ networks.moonbeam.governance.tracks.fast_general_admin.confirm_period.blocks }} blocks<br> ({{ networks.moonbeam.governance.tracks.fast_general_admin.confirm_period.time }}) | {{ networks.moonbeam.governance.tracks.fast_general_admin.min_enactment_period.blocks }} blocks<br> ({{ networks.moonbeam.governance.tracks.fast_general_admin.min_enactment_period.time }}) |

=== "Moonriver"
    |         Track          |                                                                                 Prepare<br>Period                                                                                  |                                                                                   Decide<br>Period                                                                                   |                                                                                 Confirm<br>Period                                                                                  |                                                                                  Minimum<br>Enactment Period                                                                                   |
    |:----------------------:|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|
    |          Root          |               {{ networks.moonriver.governance.tracks.root.prepare_period.blocks }} blocks <br>({{ networks.moonriver.governance.tracks.root.prepare_period.time }})               |               {{ networks.moonriver.governance.tracks.root.decision_period.blocks }} blocks<br> ({{ networks.moonriver.governance.tracks.root.decision_period.time }})               |               {{ networks.moonriver.governance.tracks.root.confirm_period.blocks }} blocks<br> ({{ networks.moonriver.governance.tracks.root.confirm_period.time }})               |               {{ networks.moonriver.governance.tracks.root.min_enactment_period.blocks }} blocks<br> ({{ networks.moonriver.governance.tracks.root.min_enactment_period.time }})               |
    |      Whitelisted       |        {{ networks.moonriver.governance.tracks.whitelisted.prepare_period.blocks }} blocks<br> ({{ networks.moonriver.governance.tracks.whitelisted.prepare_period.time }})        |        {{ networks.moonriver.governance.tracks.whitelisted.decision_period.blocks }} blocks<br> ({{ networks.moonriver.governance.tracks.whitelisted.decision_period.time }})        |        {{ networks.moonriver.governance.tracks.whitelisted.confirm_period.blocks }} blocks<br> ({{ networks.moonriver.governance.tracks.whitelisted.confirm_period.time }})        |        {{ networks.moonriver.governance.tracks.whitelisted.min_enactment_period.blocks }} blocks<br> ({{ networks.moonriver.governance.tracks.whitelisted.min_enactment_period.time }})        |
    |     General Admin      |      {{ networks.moonriver.governance.tracks.general_admin.prepare_period.blocks }} blocks<br> ({{ networks.moonriver.governance.tracks.general_admin.prepare_period.time }})      |      {{ networks.moonriver.governance.tracks.general_admin.decision_period.blocks }} blocks<br> ({{ networks.moonriver.governance.tracks.general_admin.decision_period.time }})      |      {{ networks.moonriver.governance.tracks.general_admin.confirm_period.blocks }} blocks<br> ({{ networks.moonriver.governance.tracks.general_admin.confirm_period.time }})      |      {{ networks.moonriver.governance.tracks.general_admin.min_enactment_period.blocks }} blocks<br> ({{ networks.moonriver.governance.tracks.general_admin.min_enactment_period.time }})      |
    | Emergency<br>Canceller |          {{ networks.moonriver.governance.tracks.canceller.prepare_period.blocks }} blocks<br> ({{ networks.moonriver.governance.tracks.canceller.prepare_period.time }})          |          {{ networks.moonriver.governance.tracks.canceller.decision_period.blocks }} blocks<br> ({{ networks.moonriver.governance.tracks.canceller.decision_period.time }})          |          {{ networks.moonriver.governance.tracks.canceller.confirm_period.blocks }} blocks<br> ({{ networks.moonriver.governance.tracks.canceller.confirm_period.time }})          |          {{ networks.moonriver.governance.tracks.canceller.min_enactment_period.blocks }} blocks<br> ({{ networks.moonriver.governance.tracks.canceller.min_enactment_period.time }})          |
    |  Emergency<br>Killer   |             {{ networks.moonriver.governance.tracks.killer.prepare_period.blocks }} blocks<br> ({{ networks.moonriver.governance.tracks.killer.prepare_period.time }})             |             {{ networks.moonriver.governance.tracks.killer.decision_period.blocks }} blocks<br> ({{ networks.moonriver.governance.tracks.killer.decision_period.time }})             |             {{ networks.moonriver.governance.tracks.killer.confirm_period.blocks }} blocks<br> ({{ networks.moonriver.governance.tracks.killer.confirm_period.time }})             |             {{ networks.moonriver.governance.tracks.killer.min_enactment_period.blocks }} blocks<br> ({{ networks.moonriver.governance.tracks.killer.min_enactment_period.time }})             |
    |   Fast General Admin   | {{ networks.moonriver.governance.tracks.fast_general_admin.prepare_period.blocks }} blocks<br> ({{ networks.moonriver.governance.tracks.fast_general_admin.prepare_period.time }}) | {{ networks.moonriver.governance.tracks.fast_general_admin.decision_period.blocks }} blocks<br> ({{ networks.moonriver.governance.tracks.fast_general_admin.decision_period.time }}) | {{ networks.moonriver.governance.tracks.fast_general_admin.confirm_period.blocks }} blocks<br> ({{ networks.moonriver.governance.tracks.fast_general_admin.confirm_period.time }}) | {{ networks.moonriver.governance.tracks.fast_general_admin.min_enactment_period.blocks }} blocks<br> ({{ networks.moonriver.governance.tracks.fast_general_admin.min_enactment_period.time }}) |

=== "Moonbase Alpha"
    |         Track          |                                                                                Prepare<br>Period                                                                                 |                                                                                  Decide<br>Period                                                                                  |                                                                                Confirm<br>Period                                                                                 |                                                                                 Minimum<br>Enactment Period                                                                                  |
    |:----------------------:|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|
    |          Root          |               {{ networks.moonbase.governance.tracks.root.prepare_period.blocks }} blocks <br>({{ networks.moonbase.governance.tracks.root.prepare_period.time }})               |               {{ networks.moonbase.governance.tracks.root.decision_period.blocks }} blocks<br> ({{ networks.moonbase.governance.tracks.root.decision_period.time }})               |               {{ networks.moonbase.governance.tracks.root.confirm_period.blocks }} blocks<br> ({{ networks.moonbase.governance.tracks.root.confirm_period.time }})               |               {{ networks.moonbase.governance.tracks.root.min_enactment_period.blocks }} blocks<br> ({{ networks.moonbase.governance.tracks.root.min_enactment_period.time }})               |
    |      Whitelisted       |        {{ networks.moonbase.governance.tracks.whitelisted.prepare_period.blocks }} blocks<br> ({{ networks.moonbase.governance.tracks.whitelisted.prepare_period.time }})        |        {{ networks.moonbase.governance.tracks.whitelisted.decision_period.blocks }} blocks<br> ({{ networks.moonbase.governance.tracks.whitelisted.decision_period.time }})        |        {{ networks.moonbase.governance.tracks.whitelisted.confirm_period.blocks }} blocks<br> ({{ networks.moonbase.governance.tracks.whitelisted.confirm_period.time }})        |        {{ networks.moonbase.governance.tracks.whitelisted.min_enactment_period.blocks }} blocks<br> ({{ networks.moonbase.governance.tracks.whitelisted.min_enactment_period.time }})        |
    |     General Admin      |      {{ networks.moonbase.governance.tracks.general_admin.prepare_period.blocks }} blocks<br> ({{ networks.moonbase.governance.tracks.general_admin.prepare_period.time }})      |      {{ networks.moonbase.governance.tracks.general_admin.decision_period.blocks }} blocks<br> ({{ networks.moonbase.governance.tracks.general_admin.decision_period.time }})      |      {{ networks.moonbase.governance.tracks.general_admin.confirm_period.blocks }} blocks<br> ({{ networks.moonbase.governance.tracks.general_admin.confirm_period.time }})      |      {{ networks.moonbase.governance.tracks.general_admin.min_enactment_period.blocks }} blocks<br> ({{ networks.moonbase.governance.tracks.general_admin.min_enactment_period.time }})      |
    | Emergency<br>Canceller |          {{ networks.moonbase.governance.tracks.canceller.prepare_period.blocks }} blocks<br> ({{ networks.moonbase.governance.tracks.canceller.prepare_period.time }})          |          {{ networks.moonbase.governance.tracks.canceller.decision_period.blocks }} blocks<br> ({{ networks.moonbase.governance.tracks.canceller.decision_period.time }})          |          {{ networks.moonbase.governance.tracks.canceller.confirm_period.blocks }} blocks<br> ({{ networks.moonbase.governance.tracks.canceller.confirm_period.time }})          |          {{ networks.moonbase.governance.tracks.canceller.min_enactment_period.blocks }} blocks<br> ({{ networks.moonbase.governance.tracks.canceller.min_enactment_period.time }})          |
    |  Emergency<br>Killer   |             {{ networks.moonbase.governance.tracks.killer.prepare_period.blocks }} blocks<br> ({{ networks.moonbase.governance.tracks.killer.prepare_period.time }})             |             {{ networks.moonbase.governance.tracks.killer.decision_period.blocks }} blocks<br> ({{ networks.moonbase.governance.tracks.killer.decision_period.time }})             |             {{ networks.moonbase.governance.tracks.killer.confirm_period.blocks }} blocks<br> ({{ networks.moonbase.governance.tracks.killer.confirm_period.time }})             |             {{ networks.moonbase.governance.tracks.killer.min_enactment_period.blocks }} blocks<br> ({{ networks.moonbase.governance.tracks.killer.min_enactment_period.time }})             |
    |   Fast General Admin   | {{ networks.moonbase.governance.tracks.fast_general_admin.prepare_period.blocks }} blocks<br> ({{ networks.moonbase.governance.tracks.fast_general_admin.prepare_period.time }}) | {{ networks.moonbase.governance.tracks.fast_general_admin.decision_period.blocks }} blocks<br> ({{ networks.moonbase.governance.tracks.fast_general_admin.decision_period.time }}) | {{ networks.moonbase.governance.tracks.fast_general_admin.confirm_period.blocks }} blocks<br> ({{ networks.moonbase.governance.tracks.fast_general_admin.confirm_period.time }}) | {{ networks.moonbase.governance.tracks.fast_general_admin.min_enactment_period.blocks }} blocks<br> ({{ networks.moonbase.governance.tracks.fast_general_admin.min_enactment_period.time }}) |

!!! note
    As of runtime 3000, [asynchronous backing](https://wiki.polkadot.com/learn/learn-async-backing/#asynchronous-backing){target=\_blank} has been enabled on all Moonbeam networks. As a result, the target block time was reduced from 12 seconds to 6 seconds, which may break some timing-based assumptions.

#### Support and Approval Parameters by Track {: #support-and-approval-parameters-by-track }

=== "Moonbeam"
    |         Track          | Approval Curve |                                                                                                                                                                                                                                                 Approval Parameters                                                                                                                                                                                                                                                  | Support Curve |                                                                                                                                                                                                                                               Support Parameters                                                                                                                                                                                                                                               |
    |:----------------------:|:--------------:|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|:-------------:|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|
    |          Root          |   Reciprocal   |                                           {{ networks.moonbeam.governance.tracks.root.min_approval.time0 }}: {{ networks.moonbeam.governance.tracks.root.min_approval.percent0 }}%<br>{{ networks.moonbeam.governance.tracks.root.min_approval.time1 }}: {{ networks.moonbeam.governance.tracks.root.min_approval.percent1 }}%<br>{{ networks.moonbeam.governance.tracks.root.min_approval.time2 }}: {{ networks.moonbeam.governance.tracks.root.min_approval.percent2 }}%                                           |    Linear     |                                                                                                                {{ networks.moonbeam.governance.tracks.root.min_support.time0 }}: {{ networks.moonbeam.governance.tracks.root.min_support.percent0 }}%<br>{{ networks.moonbeam.governance.tracks.root.min_support.time1 }}: {{ networks.moonbeam.governance.tracks.root.min_support.percent1 }}%                                                                                                                |
    |      Whitelisted       |   Reciprocal   |                      {{ networks.moonbeam.governance.tracks.whitelisted.min_approval.time0 }}: {{ networks.moonbeam.governance.tracks.whitelisted.min_approval.percent0 }}%<br>{{ networks.moonbeam.governance.tracks.whitelisted.min_approval.time1 }}: {{ networks.moonbeam.governance.tracks.whitelisted.min_approval.percent1 }}%<br>{{ networks.moonbeam.governance.tracks.whitelisted.min_approval.time2 }}: {{ networks.moonbeam.governance.tracks.whitelisted.min_approval.percent2 }}%                      |  Reciprocal   |                      {{ networks.moonbeam.governance.tracks.whitelisted.min_support.time0 }}: {{ networks.moonbeam.governance.tracks.whitelisted.min_support.percent0 }}%<br>{{ networks.moonbeam.governance.tracks.whitelisted.min_support.time1 }}: {{ networks.moonbeam.governance.tracks.whitelisted.min_support.percent1 }}%<br>{{ networks.moonbeam.governance.tracks.whitelisted.min_support.time2 }}: {{ networks.moonbeam.governance.tracks.whitelisted.min_support.percent2 }}%                      |
    |     General Admin      |   Reciprocal   |                {{ networks.moonbeam.governance.tracks.general_admin.min_approval.time0 }}: {{ networks.moonbeam.governance.tracks.general_admin.min_approval.percent0 }}%<br>{{ networks.moonbeam.governance.tracks.general_admin.min_approval.time1 }}: {{ networks.moonbeam.governance.tracks.general_admin.min_approval.percent1 }}%<br>{{ networks.moonbeam.governance.tracks.general_admin.min_approval.time2 }}: {{ networks.moonbeam.governance.tracks.general_admin.min_approval.percent2 }}%                |  Reciprocal   |                {{ networks.moonbeam.governance.tracks.general_admin.min_support.time0 }}: {{ networks.moonbeam.governance.tracks.general_admin.min_support.percent0 }}%<br>{{ networks.moonbeam.governance.tracks.general_admin.min_support.time1 }}: {{ networks.moonbeam.governance.tracks.general_admin.min_support.percent1 }}%<br>{{ networks.moonbeam.governance.tracks.general_admin.min_support.time2 }}: {{ networks.moonbeam.governance.tracks.general_admin.min_support.percent2 }}%                |
    | Emergency<br>Canceller |   Reciprocal   |                            {{ networks.moonbeam.governance.tracks.canceller.min_approval.time0 }}: {{ networks.moonbeam.governance.tracks.canceller.min_approval.percent0 }}%<br>{{ networks.moonbeam.governance.tracks.canceller.min_approval.time1 }}: {{ networks.moonbeam.governance.tracks.canceller.min_approval.percent1 }}%<br>{{ networks.moonbeam.governance.tracks.canceller.min_approval.time2 }}: {{ networks.moonbeam.governance.tracks.canceller.min_approval.percent2 }}%                            |  Reciprocal   |                            {{ networks.moonbeam.governance.tracks.canceller.min_support.time0 }}: {{ networks.moonbeam.governance.tracks.canceller.min_support.percent0 }}%<br>{{ networks.moonbeam.governance.tracks.canceller.min_support.time1 }}: {{ networks.moonbeam.governance.tracks.canceller.min_support.percent1 }}%<br>{{ networks.moonbeam.governance.tracks.canceller.min_support.time2 }}: {{ networks.moonbeam.governance.tracks.canceller.min_support.percent2 }}%                            |
    |  Emergency<br>Killer   |   Reciprocal   |                                     {{ networks.moonbeam.governance.tracks.killer.min_approval.time0 }}: {{ networks.moonbeam.governance.tracks.killer.min_approval.percent0 }}%<br>{{ networks.moonbeam.governance.tracks.killer.min_approval.time1 }}: {{ networks.moonbeam.governance.tracks.killer.min_approval.percent1 }}%<br>{{ networks.moonbeam.governance.tracks.killer.min_approval.time2 }}: {{ networks.moonbeam.governance.tracks.killer.min_approval.percent2 }}%                                     |  Reciprocal   |                                     {{ networks.moonbeam.governance.tracks.killer.min_support.time0 }}: {{ networks.moonbeam.governance.tracks.killer.min_support.percent0 }}%<br>{{ networks.moonbeam.governance.tracks.killer.min_support.time1 }}: {{ networks.moonbeam.governance.tracks.killer.min_support.percent1 }}%<br>{{ networks.moonbeam.governance.tracks.killer.min_support.time2 }}: {{ networks.moonbeam.governance.tracks.killer.min_support.percent2 }}%                                     |
    |   Fast General Admin   |   Reciprocal   | {{ networks.moonbeam.governance.tracks.fast_general_admin.min_approval.time0 }}: {{ networks.moonbeam.governance.tracks.fast_general_admin.min_approval.percent0 }}%<br>{{ networks.moonbeam.governance.tracks.fast_general_admin.min_approval.time1 }}: {{ networks.moonbeam.governance.tracks.fast_general_admin.min_approval.percent1 }}%<br>{{ networks.moonbeam.governance.tracks.fast_general_admin.min_approval.time2 }}: {{ networks.moonbeam.governance.tracks.fast_general_admin.min_approval.percent2 }}% |  Reciprocal   | {{ networks.moonbeam.governance.tracks.fast_general_admin.min_support.time0 }}: {{ networks.moonbeam.governance.tracks.fast_general_admin.min_support.percent0 }}%<br>{{ networks.moonbeam.governance.tracks.fast_general_admin.min_support.time1 }}: {{ networks.moonbeam.governance.tracks.fast_general_admin.min_support.percent1 }}%<br>{{ networks.moonbeam.governance.tracks.fast_general_admin.min_support.time2 }}: {{ networks.moonbeam.governance.tracks.fast_general_admin.min_support.percent2 }}% |

=== "Moonriver"
    |         Track          | Approval Curve |                                                                                                                                                                                                                                                    Approval Parameters                                                                                                                                                                                                                                                     | Support Curve |                                                                                                                                                                                                                                                  Support Parameters                                                                                                                                                                                                                                                  |
    |:----------------------:|:--------------:|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|:-------------:|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|
    |          Root          |   Reciprocal   |                                           {{ networks.moonriver.governance.tracks.root.min_approval.time0 }}: {{ networks.moonriver.governance.tracks.root.min_approval.percent0 }}%<br>{{ networks.moonriver.governance.tracks.root.min_approval.time1 }}: {{ networks.moonriver.governance.tracks.root.min_approval.percent1 }}%<br>{{ networks.moonriver.governance.tracks.root.min_approval.time2 }}: {{ networks.moonriver.governance.tracks.root.min_approval.percent2 }}%                                           |    Linear     |                                                                                                                 {{ networks.moonriver.governance.tracks.root.min_support.time0 }}: {{ networks.moonriver.governance.tracks.root.min_support.percent0 }}%<br>{{ networks.moonriver.governance.tracks.root.min_support.time1 }}: {{ networks.moonriver.governance.tracks.root.min_support.percent1 }}%                                                                                                                 |
    |      Whitelisted       |   Reciprocal   |                      {{ networks.moonriver.governance.tracks.whitelisted.min_approval.time0 }}: {{ networks.moonriver.governance.tracks.whitelisted.min_approval.percent0 }}%<br>{{ networks.moonriver.governance.tracks.whitelisted.min_approval.time1 }}: {{ networks.moonriver.governance.tracks.whitelisted.min_approval.percent1 }}%<br>{{ networks.moonriver.governance.tracks.whitelisted.min_approval.time2 }}: {{ networks.moonriver.governance.tracks.whitelisted.min_approval.percent2 }}%                      |  Reciprocal   |                      {{ networks.moonriver.governance.tracks.whitelisted.min_support.time0 }}: {{ networks.moonriver.governance.tracks.whitelisted.min_support.percent0 }}%<br>{{ networks.moonriver.governance.tracks.whitelisted.min_support.time1 }}: {{ networks.moonriver.governance.tracks.whitelisted.min_support.percent1 }}%<br>{{ networks.moonriver.governance.tracks.whitelisted.min_support.time2 }}: {{ networks.moonriver.governance.tracks.whitelisted.min_support.percent2 }}%                      |
    |     General Admin      |   Reciprocal   |                {{ networks.moonriver.governance.tracks.general_admin.min_approval.time0 }}: {{ networks.moonriver.governance.tracks.general_admin.min_approval.percent0 }}%<br>{{ networks.moonriver.governance.tracks.general_admin.min_approval.time1 }}: {{ networks.moonriver.governance.tracks.general_admin.min_approval.percent1 }}%<br>{{ networks.moonriver.governance.tracks.general_admin.min_approval.time2 }}: {{ networks.moonriver.governance.tracks.general_admin.min_approval.percent2 }}%                |  Reciprocal   |                {{ networks.moonriver.governance.tracks.general_admin.min_support.time0 }}: {{ networks.moonriver.governance.tracks.general_admin.min_support.percent0 }}%<br>{{ networks.moonriver.governance.tracks.general_admin.min_support.time1 }}: {{ networks.moonriver.governance.tracks.general_admin.min_support.percent1 }}%<br>{{ networks.moonriver.governance.tracks.general_admin.min_support.time2 }}: {{ networks.moonriver.governance.tracks.general_admin.min_support.percent2 }}%                |
    | Emergency<br>Canceller |   Reciprocal   |                            {{ networks.moonriver.governance.tracks.canceller.min_approval.time0 }}: {{ networks.moonriver.governance.tracks.canceller.min_approval.percent0 }}%<br>{{ networks.moonriver.governance.tracks.canceller.min_approval.time1 }}: {{ networks.moonriver.governance.tracks.canceller.min_approval.percent1 }}%<br>{{ networks.moonriver.governance.tracks.canceller.min_approval.time2 }}: {{ networks.moonriver.governance.tracks.canceller.min_approval.percent2 }}%                            |  Reciprocal   |                            {{ networks.moonriver.governance.tracks.canceller.min_support.time0 }}: {{ networks.moonriver.governance.tracks.canceller.min_support.percent0 }}%<br>{{ networks.moonriver.governance.tracks.canceller.min_support.time1 }}: {{ networks.moonriver.governance.tracks.canceller.min_support.percent1 }}%<br>{{ networks.moonriver.governance.tracks.canceller.min_support.time2 }}: {{ networks.moonriver.governance.tracks.canceller.min_support.percent2 }}%                            |
    |  Emergency<br>Killer   |   Reciprocal   |                                     {{ networks.moonriver.governance.tracks.killer.min_approval.time0 }}: {{ networks.moonriver.governance.tracks.killer.min_approval.percent0 }}%<br>{{ networks.moonriver.governance.tracks.killer.min_approval.time1 }}: {{ networks.moonriver.governance.tracks.killer.min_approval.percent1 }}%<br>{{ networks.moonriver.governance.tracks.killer.min_approval.time2 }}: {{ networks.moonriver.governance.tracks.killer.min_approval.percent2 }}%                                     |  Reciprocal   |                                     {{ networks.moonriver.governance.tracks.killer.min_support.time0 }}: {{ networks.moonriver.governance.tracks.killer.min_support.percent0 }}%<br>{{ networks.moonriver.governance.tracks.killer.min_support.time1 }}: {{ networks.moonriver.governance.tracks.killer.min_support.percent1 }}%<br>{{ networks.moonriver.governance.tracks.killer.min_support.time2 }}: {{ networks.moonriver.governance.tracks.killer.min_support.percent2 }}%                                     |
    |   Fast General Admin   |   Reciprocal   | {{ networks.moonriver.governance.tracks.fast_general_admin.min_approval.time0 }}: {{ networks.moonriver.governance.tracks.fast_general_admin.min_approval.percent0 }}%<br>{{ networks.moonriver.governance.tracks.fast_general_admin.min_approval.time1 }}: {{ networks.moonriver.governance.tracks.fast_general_admin.min_approval.percent1 }}%<br>{{ networks.moonriver.governance.tracks.fast_general_admin.min_approval.time2 }}: {{ networks.moonriver.governance.tracks.fast_general_admin.min_approval.percent2 }}% |  Reciprocal   | {{ networks.moonriver.governance.tracks.fast_general_admin.min_support.time0 }}: {{ networks.moonriver.governance.tracks.fast_general_admin.min_support.percent0 }}%<br>{{ networks.moonriver.governance.tracks.fast_general_admin.min_support.time1 }}: {{ networks.moonriver.governance.tracks.fast_general_admin.min_support.percent1 }}%<br>{{ networks.moonriver.governance.tracks.fast_general_admin.min_support.time2 }}: {{ networks.moonriver.governance.tracks.fast_general_admin.min_support.percent2 }}% |

=== "Moonbase Alpha"
    |         Track          | Approval Curve |                                                                                                                                                                                                                                                 Approval Parameters                                                                                                                                                                                                                                                  | Support Curve |                                                                                                                                                                                                                                               Support Parameters                                                                                                                                                                                                                                               |
    |:----------------------:|:--------------:|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|:-------------:|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|
    |          Root          |   Reciprocal   |                                           {{ networks.moonbase.governance.tracks.root.min_approval.time0 }}: {{ networks.moonbase.governance.tracks.root.min_approval.percent0 }}%<br>{{ networks.moonbase.governance.tracks.root.min_approval.time1 }}: {{ networks.moonbase.governance.tracks.root.min_approval.percent1 }}%<br>{{ networks.moonbase.governance.tracks.root.min_approval.time2 }}: {{ networks.moonbase.governance.tracks.root.min_approval.percent2 }}%                                           |    Linear     |                                                                                                                {{ networks.moonbase.governance.tracks.root.min_support.time0 }}: {{ networks.moonbase.governance.tracks.root.min_support.percent0 }}%<br>{{ networks.moonbase.governance.tracks.root.min_support.time1 }}: {{ networks.moonbase.governance.tracks.root.min_support.percent1 }}%                                                                                                                |
    |      Whitelisted       |   Reciprocal   |                      {{ networks.moonbase.governance.tracks.whitelisted.min_approval.time0 }}: {{ networks.moonbase.governance.tracks.whitelisted.min_approval.percent0 }}%<br>{{ networks.moonbase.governance.tracks.whitelisted.min_approval.time1 }}: {{ networks.moonbase.governance.tracks.whitelisted.min_approval.percent1 }}%<br>{{ networks.moonbase.governance.tracks.whitelisted.min_approval.time2 }}: {{ networks.moonbase.governance.tracks.whitelisted.min_approval.percent2 }}%                      |  Reciprocal   |                      {{ networks.moonbase.governance.tracks.whitelisted.min_support.time0 }}: {{ networks.moonbase.governance.tracks.whitelisted.min_support.percent0 }}%<br>{{ networks.moonbase.governance.tracks.whitelisted.min_support.time1 }}: {{ networks.moonbase.governance.tracks.whitelisted.min_support.percent1 }}%<br>{{ networks.moonbase.governance.tracks.whitelisted.min_support.time2 }}: {{ networks.moonbase.governance.tracks.whitelisted.min_support.percent2 }}%                      |
    |     General Admin      |   Reciprocal   |                {{ networks.moonbase.governance.tracks.general_admin.min_approval.time0 }}: {{ networks.moonbase.governance.tracks.general_admin.min_approval.percent0 }}%<br>{{ networks.moonbase.governance.tracks.general_admin.min_approval.time1 }}: {{ networks.moonbase.governance.tracks.general_admin.min_approval.percent1 }}%<br>{{ networks.moonbase.governance.tracks.general_admin.min_approval.time2 }}: {{ networks.moonbase.governance.tracks.general_admin.min_approval.percent2 }}%                |  Reciprocal   |                {{ networks.moonbase.governance.tracks.general_admin.min_support.time0 }}: {{ networks.moonbase.governance.tracks.general_admin.min_support.percent0 }}%<br>{{ networks.moonbase.governance.tracks.general_admin.min_support.time1 }}: {{ networks.moonbase.governance.tracks.general_admin.min_support.percent1 }}%<br>{{ networks.moonbase.governance.tracks.general_admin.min_support.time2 }}: {{ networks.moonbase.governance.tracks.general_admin.min_support.percent2 }}%                |
    | Emergency<br>Canceller |   Reciprocal   |                            {{ networks.moonbase.governance.tracks.canceller.min_approval.time0 }}: {{ networks.moonbase.governance.tracks.canceller.min_approval.percent0 }}%<br>{{ networks.moonbase.governance.tracks.canceller.min_approval.time1 }}: {{ networks.moonbase.governance.tracks.canceller.min_approval.percent1 }}%<br>{{ networks.moonbase.governance.tracks.canceller.min_approval.time2 }}: {{ networks.moonbase.governance.tracks.canceller.min_approval.percent2 }}%                            |  Reciprocal   |                            {{ networks.moonbase.governance.tracks.canceller.min_support.time0 }}: {{ networks.moonbase.governance.tracks.canceller.min_support.percent0 }}%<br>{{ networks.moonbase.governance.tracks.canceller.min_support.time1 }}: {{ networks.moonbase.governance.tracks.canceller.min_support.percent1 }}%<br>{{ networks.moonbase.governance.tracks.canceller.min_support.time2 }}: {{ networks.moonbase.governance.tracks.canceller.min_support.percent2 }}%                            |
    |  Emergency<br>Killer   |   Reciprocal   |                                     {{ networks.moonbase.governance.tracks.killer.min_approval.time0 }}: {{ networks.moonbase.governance.tracks.killer.min_approval.percent0 }}%<br>{{ networks.moonbase.governance.tracks.killer.min_approval.time1 }}: {{ networks.moonbase.governance.tracks.killer.min_approval.percent1 }}%<br>{{ networks.moonbase.governance.tracks.killer.min_approval.time2 }}: {{ networks.moonbase.governance.tracks.killer.min_approval.percent2 }}%                                     |  Reciprocal   |                                     {{ networks.moonbase.governance.tracks.killer.min_support.time0 }}: {{ networks.moonbase.governance.tracks.killer.min_support.percent0 }}%<br>{{ networks.moonbase.governance.tracks.killer.min_support.time1 }}: {{ networks.moonbase.governance.tracks.killer.min_support.percent1 }}%<br>{{ networks.moonbase.governance.tracks.killer.min_support.time2 }}: {{ networks.moonbase.governance.tracks.killer.min_support.percent2 }}%                                     |
    |   Fast General Admin   |   Reciprocal   | {{ networks.moonbase.governance.tracks.fast_general_admin.min_approval.time0 }}: {{ networks.moonbase.governance.tracks.fast_general_admin.min_approval.percent0 }}%<br>{{ networks.moonbase.governance.tracks.fast_general_admin.min_approval.time1 }}: {{ networks.moonbase.governance.tracks.fast_general_admin.min_approval.percent1 }}%<br>{{ networks.moonbase.governance.tracks.fast_general_admin.min_approval.time2 }}: {{ networks.moonbase.governance.tracks.fast_general_admin.min_approval.percent2 }}% |  Reciprocal   | {{ networks.moonbase.governance.tracks.fast_general_admin.min_support.time0 }}: {{ networks.moonbase.governance.tracks.fast_general_admin.min_support.percent0 }}%<br>{{ networks.moonbase.governance.tracks.fast_general_admin.min_support.time1 }}: {{ networks.moonbase.governance.tracks.fast_general_admin.min_support.percent1 }}%<br>{{ networks.moonbase.governance.tracks.fast_general_admin.min_support.time2 }}: {{ networks.moonbase.governance.tracks.fast_general_admin.min_support.percent2 }}% |

#### Conviction Multiplier {: #conviction-multiplier-v2 }

The Conviction multiplier is related to the number of Enactment Periods the tokens will be locked for after the referenda is enacted (if approved). Consequently, the longer you are willing to lock your tokens, the stronger your vote will be weighted. You also have the option of not locking tokens at all, but vote weight is drastically reduced (tokens are still locked during the duration of the referendum).

If you were to vote 1000 tokens with a 6x Conviction, your weighted vote would be 6000 units. That is, 1000 locked tokens multiplied by the Conviction, which in this scenario would be 6. On the other hand, if you decided you didn't want to have your tokens locked after enactment, you could vote your 1000 tokens with a 0.1x Conviction. In this case, your weighted vote would only be 100 units.

The Conviction multiplier values for each network are:

=== "Moonbeam"
    | Lock Periods After Enactment | Conviction Multiplier |                       Approx. Lock Time                        |
    |:----------------------------:|:---------------------:|:--------------------------------------------------------------:|
    |              0               |          0.1          |                              None                              |
    |              1               |           1           | {{networks.moonbeam.conviction.lock_period.conviction_1}} day  |
    |              2               |           2           | {{networks.moonbeam.conviction.lock_period.conviction_2}} days |
    |              4               |           3           | {{networks.moonbeam.conviction.lock_period.conviction_3}} days |
    |              8               |           4           | {{networks.moonbeam.conviction.lock_period.conviction_4}} days |
    |              16              |           5           | {{networks.moonbeam.conviction.lock_period.conviction_5}} days |
    |              32              |           6           | {{networks.moonbeam.conviction.lock_period.conviction_6}} days |

=== "Moonriver"
    | Lock Periods After Enactment | Conviction Multiplier |                        Approx. Lock Time                        |
    |:----------------------------:|:---------------------:|:---------------------------------------------------------------:|
    |              0               |          0.1          |                              None                               |
    |              1               |           1           | {{networks.moonriver.conviction.lock_period.conviction_1}} day  |
    |              2               |           2           | {{networks.moonriver.conviction.lock_period.conviction_2}} days |
    |              4               |           3           | {{networks.moonriver.conviction.lock_period.conviction_3}} days |
    |              8               |           4           | {{networks.moonriver.conviction.lock_period.conviction_4}} days |
    |              16              |           5           | {{networks.moonriver.conviction.lock_period.conviction_5}} days |
    |              32              |           6           | {{networks.moonriver.conviction.lock_period.conviction_6}} days |

=== "Moonbase Alpha"
    | Lock Periods After Enactment | Conviction Multiplier |                       Approx. Lock Time                        |
    |:----------------------------:|:---------------------:|:--------------------------------------------------------------:|
    |              0               |          0.1          |                              None                              |
    |              1               |           1           | {{networks.moonbase.conviction.lock_period.conviction_1}} day  |
    |              2               |           2           | {{networks.moonbase.conviction.lock_period.conviction_2}} days |
    |              4               |           3           | {{networks.moonbase.conviction.lock_period.conviction_3}} days |
    |              8               |           4           | {{networks.moonbase.conviction.lock_period.conviction_4}} days |
    |              16              |           5           | {{networks.moonbase.conviction.lock_period.conviction_5}} days |
    |              32              |           6           | {{networks.moonbase.conviction.lock_period.conviction_6}} days |

!!! note
    The lock time approximations are based upon regular {{ networks.moonriver.block_time }}-second block times. Block production may vary and thus the displayed lock times should not be deemed exact.

### Roadmap of a Proposal {: #roadmap-of-a-proposal-v2 }

Before a proposal is submitted, the author of the proposal can submit their proposal idea to the designated Democracy Proposals section of the [Moonbeam Governance discussion forum](https://forum.moonbeam.network/c/governance/2){target=\_blank} for feedback from the community for at least five days. From there, the author can make adjustments to the proposal based on the feedback they've collected.

Once the author is ready, they can submit their proposal on-chain. To do so, first, they need to submit the preimage of the proposal. The submitter needs to bond a fee to store the preimage on-chain. The bond is returned once the submitter unnotes the preimage. Next, they can submit the actual proposal and pay the Submission Deposit, which is enough to cover the on-chain storage cost of the proposal. Then the Lead-in Period begins and the community can begin voting "Aye" or "Nay" on the proposal by locking tokens. In order for the referendum to advance and move out of the Lead-in Period to the Decide period, the following criteria must be met:

- The referendum must wait the duration of the Prepare Period, which allows for adequate time to discuss the proposal before it progresses to the next phase
- There is enough Capacity in the chosen Track
- A Decision Deposit has been made that meets the minimum requirements for the Track

If a referendum meets the above criteria, it moves to the Decide Period and takes up one of the spots in its designated Track. In the Decide Period, voting continues and the referendum has a set amount of days to reach the Approval and Support requirements needed for it to progress to the Confirm Period.

Once in the Confirm Period, a referendum must continuously meet the Approval and Support requirements for the duration of the period. If a referendum fails to meet the requirements at any point, it is returned to the Decide Period. If the referendum meets the Approval and Support requirements again, it can progress to the Confirm Period again and the Decide Period will be delayed until the end of the Confirm Period. If the Decide Period ends and not enough Approval and Support was received, the referendum will be rejected and the Decision Deposit will be returned. The proposal can be proposed again at any time.

If a referendum continuously receives enough Approval and Support during the Confirm Period, it will be approved and move to the Enactment Period. It will wait the duration of the Enactment Period before it gets dispatched.

The happy path for a proposal is shown in the following diagram:

![A happy path diagram of the proposal roadmap in OpenGov.](/images/learn/features/governance/proposal-roadmap.webp)

### Proposal Example Walkthrough

A proposal (with its preimage) is submitted for the General Admin Track on Moonriver would have the following characteristics:

 - The Approval curve starts at {{ networks.moonriver.governance.tracks.general_admin.min_approval.percent0 }}% on {{ networks.moonriver.governance.tracks.general_admin.min_approval.time0 }}, goes to {{ networks.moonriver.governance.tracks.general_admin.min_approval.percent1 }}% on {{ networks.moonriver.governance.tracks.general_admin.min_approval.time1 }}
 - The Support curve starts at {{ networks.moonriver.governance.tracks.general_admin.min_support.percent0 }}% on {{ networks.moonriver.governance.tracks.general_admin.min_support.time0 }}, goes to {{ networks.moonriver.governance.tracks.general_admin.min_support.percent1 }}% on {{ networks.moonriver.governance.tracks.general_admin.min_support.time1 }}
 - A referendum starts the Decide Period with 0% "Aye" votes (nobody voted in the Lead-in Period)
 - Token holders begin to vote and the Approval increases to a value above {{ networks.moonriver.governance.tracks.general_admin.min_approval.percent1 }}% by {{ networks.moonriver.governance.tracks.general_admin.min_approval.time1 }}
 - If the Approval and Support thresholds are met for the duration of the Confirm Period ({{ networks.moonriver.governance.tracks.general_admin.confirm_period.blocks }} blocks, approximately {{ networks.moonriver.governance.tracks.general_admin.confirm_period.time }}), the referendum is approved
 - If the Approval and Support thresholds are not met during the Decision Period, the proposal is rejected. Note that the thresholds need to be met for the duration of the Confirm Period. Consequently, if they are met but the Decision Period expires before the completion of the Confirm Period, the proposal is rejected

The Approval and Support percentages can be calculated using the following:

=== "Approval"

    ```text
    Approval = 100 * ( Total Conviction-weighted "Aye" votes / Total Conviction-weighted votes ) 
    ```

=== "Support"

    ```text
    Support = 100 * ( Total Aye + Abstain votes, ignoring conviction / Total supply )
    ```

### Proposal Cancellations {: #proposal-cancellations }

In the event that a proposal already in the voting stage is found to have an issue, it may be necessary to prevent its approval. These instances may involve malicious activity or technical issues that make the changes impossible to implement due to recent upgrades to the network.

Cancellations must be voted on by the network to be executed. Cancellation proposals are faster than a typical proposal because they must be decided before the enactment of the proposal they seek to cancel, but they follow the same process as other referenda.

There is a cancellation Origin for use against referenda that contain an unforeseen problem, called the Emergency Canceller. The Emergency Canceller Origin and the Root Origin are allowed to cancel referenda. Regardless of the Origin, if a proposal is cancelled, it gets rejected and the Decision Deposit gets refunded.

In addition, there is a Kill Origin, which is for bad referenda intending to harm the network, called Emergency Killer. The Emergency Killer Origin and the Root Origin have the ability to kill referenda. In this case, a proposal is cancelled and the Decision Deposit is slashed, meaning the deposit amount is burned regardless of the Origin.

### Rights of the OpenGov Technical Committee {: #rights-of-the-opengov-technical-committee }

On Polkadot, the Technical Committee from Governance v1 was replaced with the Fellowship, which is a "mostly self-governing expert body with a primary goal of representing humans who embody and contain the technical knowledge base of the Kusama and/or Polkadot networks and protocol," according to [Polkadot's wiki](https://wiki.polkadot.com/general/web3-and-polkadot/#fellowship){target=\_blank}.

For Moonbeam's implementation of OpenGov, instead of the Fellowship, there is a community OpenGov Technical Committee that has very similar power to that of the Fellowship. Their power in governance resides in their ability to whitelist a proposal. OpenGov Technical Committee members may only vote to whitelist a proposal if whitelisting that proposal would protect against a security vulnerability to the network. The passing threshold of the OpenGov Technical Committee members on whether to whitelist a proposal is determined by governance. As such, the OpenGov Technical Committee has very limited power over the network. Its purpose is to provide technical review of urgent security issues that are proposed by token holders.

While still subject to governance, the idea behind the Whitelist track is that it will have different parameters to make it faster for proposals to pass. The Whitelist Track parameters, including approval, support, and voting, are determined by the Moonriver or Moonbeam token holders through governance and cannot be changed by the OpenGov Technical Committee.

The OpenGov Technical Committee is made up of members of the community who have technical knowledge and expertise in Moonbeam-based networks.

### Related Guides on OpenGov {: #try-it-out }

For related guides on submitting and voting on referenda on Moonbeam with OpenGov, please check the following guides:

 - [How to Submit a Proposal](/tokens/governance/proposals/){target=\_blank}
 - [How to Vote on a Proposal](/tokens/governance/voting/){target=\_blank}
 - [Interact with the Preimages Precompiled Contract (Solidity Interface)](/builders/ethereum/precompiles/features/governance/preimage/){target=\_blank}
 - [Interact with the Referenda Precompiled Contract (Solidity Interface)](/builders/ethereum/precompiles/features/governance/referenda/){target=\_blank}
 - [Interact with the Conviction Voting Precompiled Contract (Solidity Interface)](/builders/ethereum/precompiles/features/governance/conviction-voting/){target=\_blank}
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/learn/features/randomness/
--- BEGIN CONTENT ---
---
title: Randomness
description: Learn about the sources of VRF randomness on Moonbeam, the request and fulfillment process, and some security considerations when using on-chain randomness.
categories: Basics
---

# Randomness on Moonbeam

## Introduction {: #introduction }

Randomness is necessary for a variety of blockchain applications to create unbiased, unpredictable, and unique outcomes. However, obtaining a reliable source of randomness is a challenge. Computers are deterministic, meaning given the same input, the same output will always be produced. Therefore, random values generated by computers are referred to as pseudo-random as they appear to be statistically random, but given the same input, the output can easily be repeated.

Moonbeam utilizes verifiable random functions (VRF) to generate randomness that can be verified on-chain. A VRF is a cryptographic function that takes some input and produces random values, along with a proof of authenticity that they were generated by the submitter. The proof can be verified by anyone to ensure that the random values were generated correctly.

There are two available sources of randomness that provide random inputs based on block producers' VRF keys and past randomness results: [local VRF](#local-vrf) and [BABE epoch randomness](#babe-epoch-randomness). Local VRF is determined directly within Moonbeam using the collator of the block's VRF key and the last block's VRF output. On the other hand, [BABE](https://docs.polkadot.com/polkadot-protocol/architecture/polkadot-chain/pos-consensus/#block-production-babe){target=\_blank} epoch randomness is based on all the VRF produced by the relay chain validators during a complete [epoch](https://wiki.polkadot.com/general/glossary/#epoch){target=\_blank}.

You can interact with and request on-chain randomness using the Randomness Precompile contract, a Solidity interface that enables smart contract developers to access the randomness functionality through the Ethereum API. For more information, please check out the [Interacting with the Randomness Precompile](/builders/ethereum/precompiles/features/randomness/){target=\_blank} guide. You can also take a look at the [Randomness Pallet](/builders/substrate/interfaces/features/randomness/){target=\_blank}, which can be used to obtain current randomness requests and results.

## General Definitions {: #general-definitions }

- **Epoch** - a time duration in the BABE protocol that is broken into smaller time slots. Slots are discrete units of time six seconds in length. On Polkadot, one epoch lasts approximately 2,400 slots or 4 hours. On Kusama, one epoch lasts approximately 600 slots or 1 hour.
- **Deposit** - an amount of funds required to request random words. There is one deposit per request. Once the request has been fulfilled, the deposit will be returned to the account that requested the randomness
- **Block expiration delay** - the number of blocks that must pass before a local VRF request expires and can be purged
- **Epoch expiration delay** - the number of epochs that must pass before a BABE request expires and can be purged
- **Minimum block delay** - the minimum number of blocks before a request can be fulfilled for local VRF requests
- **Maximum block delay** - the maximum number of blocks before a request can be fulfilled for local VRF requests
- **Maximum random words** - the maximum number of random words being requested
- **Epoch fulfillment delay** - the delay in epochs before a request can be fulfilled for a BABE request

## Quick Reference {: #quick-reference }

=== "Moonbeam"
    |        Variable         |                                             Value                                             |
    |:-----------------------:|:---------------------------------------------------------------------------------------------:|
    |         Deposit         |                {{ networks.moonbeam.randomness.req_deposit_amount.glmr }} GLMR                 |
    | Block expiration delay  |                  {{ networks.moonbeam.randomness.block_expiration }} blocks                   |
    | Epoch expiration delay  |                  {{ networks.moonbeam.randomness.epoch_expiration }} epochs                   |
    |   Minimum block delay   |                {{ networks.moonbeam.randomness.min_vrf_blocks_delay }} blocks                 |
    |   Maximum block delay   |                {{ networks.moonbeam.randomness.max_vrf_blocks_delay }} blocks                 |
    |  Maximum random words   |                   {{ networks.moonbeam.randomness.max_random_words }} words                   |
    | Epoch fulfillment delay | {{ networks.moonbeam.randomness.epoch_fulfillment_delay }} epochs (following the current one) |

=== "Moonriver"
    |        Variable         |                                             Value                                              |
    |:-----------------------:|:----------------------------------------------------------------------------------------------:|
    |         Deposit         |                {{ networks.moonriver.randomness.req_deposit_amount.movr }} MOVR                 |
    | Block expiration delay  |                  {{ networks.moonriver.randomness.block_expiration }} blocks                   |
    | Epoch expiration delay  |                  {{ networks.moonriver.randomness.epoch_expiration }} epochs                   |
    |   Minimum block delay   |                {{ networks.moonriver.randomness.min_vrf_blocks_delay }} blocks                 |
    |   Maximum block delay   |                {{ networks.moonriver.randomness.max_vrf_blocks_delay }} blocks                 |
    |  Maximum random words   |                   {{ networks.moonriver.randomness.max_random_words }} words                   |
    | Epoch fulfillment delay | {{ networks.moonriver.randomness.epoch_fulfillment_delay }} epochs (following the current one) |

=== "Moonbase Alpha"
    |        Variable         |                                             Value                                             |
    |:-----------------------:|:---------------------------------------------------------------------------------------------:|
    |         Deposit         |                 {{ networks.moonbase.randomness.req_deposit_amount.dev }} DEV                 |
    | Block expiration delay  |                  {{ networks.moonbase.randomness.block_expiration }} blocks                   |
    | Epoch expiration delay  |                  {{ networks.moonbase.randomness.epoch_expiration }} epochs                   |
    |   Minimum block delay   |                {{ networks.moonbase.randomness.min_vrf_blocks_delay }} blocks                 |
    |   Maximum block delay   |                {{ networks.moonbase.randomness.max_vrf_blocks_delay }} blocks                 |
    |  Maximum random words   |                   {{ networks.moonbase.randomness.max_random_words }} words                   |
    | Epoch fulfillment delay | {{ networks.moonbase.randomness.epoch_fulfillment_delay }} epochs (following the current one) |

## Local VRF {: #local-vrf }

Local VRF randomness is generated on a block-by-block basis at the beginning of the block using the previous block's VRF output along with the public key of the current block author's VRF key. The generated randomness result is stored and used to fulfill all randomness requests for the current block.

You can request local VRF randomness using the [`requestLocalVRFRandomWords` method](/builders/ethereum/precompiles/features/randomness/#:~:text=requestLocalVRFRandomWords){target=\_blank} of the [Randomness Precompile](/builders/ethereum/precompiles/features/randomness/){target=\_blank}.

If your contract could have concurrent requests open, you can use the `requestId` returned from the `requestLocalVRFRandomWords` method to track which response is associated with which randomness request.

## BABE Epoch Randomness {: #babe-epoch-randomness }

BABE epoch randomness is based on a hash of the VRF values from the blocks produced in the relay chain epoch before last. On Polkadot, an [epoch lasts for roughly 4 hours](https://wiki.polkadot.com/learn/learn-cryptography/#vrf){target=\_blank}, and on Kusama, an [epoch lasts for roughly 1 hour](https://guide.kusama.network/docs/maintain-polkadot-parameters#periods-of-common-actions-and-attributes){target=\_blank}. The hashing is completed on the relay chain, and as such, it is not possible for a collator on Moonbeam to influence the randomness value unless they are also a validator on the relay chain and were responsible for producing the last output included in an epoch.

The randomness remains constant during an epoch. If a collator skips block production, the next eligible collator can fulfill the request using the same random value.

You can request BABE epoch randomness using the [`requestRelayBabeEpochRandomWords` method](/builders/ethereum/precompiles/features/randomness/#:~:text=requestRelayBabeEpochRandomWords){target=\_blank} of the [Randomness Precompile](/builders/ethereum/precompiles/features/randomness/){target=\_blank}. In order to generate unique randomness, a different salt must be provided to the `requestRelayBabeEpochRandomWords` function.

At the beginning of each relay chain epoch change, the randomness from one epoch ago is read from the relay chain state proof and used to fulfill all randomness requests that are due in the current block.

## Request & Fulfill Process {: #request-and-fulfill-process }

In general, the request and fulfill process for randomness is as follows:

1. Pay the deposit required to request random words
2. Request the randomness either using the local VRF or BABE epoch source of randomness. When requesting randomness you'll need to specify a few things:

    - a refund address where any excess fees will be sent to
    - the amount of fees which will be set aside to pay for fulfillment. If the specified amount is not enough you can always increase the request fees later, or if it's more than enough you'll be refunded the excess fees to the specified address after fulfillment
    - a unique salt that will be used to generate different random words
    - the number of random words you would like to request
    - for local VRF, the delay period in blocks, which is used to increase unpredictability. It must be between the [minimum and maximum number of blocks](#quick-reference) as listed above. For BABE epoch randomness, you do not need to specify a delay but can fulfill the request after the [epoch delay](#quick-reference) has passed

3. Wait for the delay period to pass
4. Fulfill the randomness request, which triggers the random words to be computed using the current block's randomness result and the given salt. This can manually be done by anyone using the fee that was initially set aside for the request
5. For fulfilled requests, the random words are returned and the cost of execution will be refunded from the request fee to the address that initiated the fulfillment. Then any excess fees and the request deposit are transferred to the specified refund address

If a request expires it can be purged by anyone. When this happens, the request fee is paid out to the address that initiated the purge and the deposit is returned to the original requester.

The happy path for a randomness request is shown in the following diagram:

![Randomness request happy path diagram](/images/learn/features/randomness/randomness-1.webp)

## Security Considerations {: #security-considerations }

A method with the ability to call your `fulfillRandomness` method directly could spoof a VRF response with any random value, so it's critical that it can only be directly called by the `RandomnessConsumer.sol` contract's `rawFulfillRandomness` method.

For your users to trust that your contract's random behavior is free from malicious interference, it's best if you can write it so that all behaviors implied by a VRF response are executed *during* your `fulfillRandomness` method. If your contract must store the response (or anything derived from it) and use it later, you must ensure that any user-significant behavior which depends on that stored value cannot be manipulated by a subsequent VRF request.

Similarly, the collators have some influence over the order in which VRF responses appear on the blockchain, so if your contract could have multiple VRF requests in flight simultaneously, you must ensure that the order in which the VRF responses arrive cannot be used to manipulate your contract's user-significant behavior.

Since the output of the random words generated for `requestLocalVRFRandomWords` is dependent on the collator producing the block at fulfillment, the collator could skip its block, forcing the fulfillment to be executed by a different collator and therefore generating a different VRF. However, such an attack would incur the cost of losing the block reward to the collator. It is also possible for a collator to be able to predict some of the possible outcome of the VRF if the delay between the request and the fulfillment is too short. It is for this reason that you can choose to provide a higher delay.

Since the output of the random words generated for `requestRelayBabeEpochRandomWords` is dependent on the relay chain validator producing the blocks during an epoch, it is possible for the last validator of an epoch to choose between two possible VRF outputs by skipping the production of a block. However, such an attack would incur the cost of losing the block reward to the validator. It is not possible for a parachain collator to predict or influence the output of the relay chain VRF, not to censor the fulfillment, as long as there is one honest collator.
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/learn/features/staking/
--- BEGIN CONTENT ---
---
title: Staking
description: Moonbeam provides staking features where token holders delegate collator candidates with their tokens and earn rewards.
categories: Basics, Staking
---

# Staking on Moonbeam

## Introduction {: #introduction }

Moonbeam uses a block production mechanism based on [Polkadot's Proof-of-Stake model](https://docs.polkadot.com/polkadot-protocol/architecture/polkadot-chain/pos-consensus/){target=\_blank}, where there are collators and validators. [Collators](https://wiki.polkadot.com/learn/learn-collator/){target=\_blank} maintain parachains (in this case, Moonbeam) by collecting transactions from users and producing state transition proofs for the relay chain [validators](https://wiki.polkadot.com/learn/learn-validator/){target=\_blank}.

The candidates in the active set of collators (nodes that produce blocks) are selected based on their stake in the network. And here is where staking comes in.

Collator candidates (and token holders if they delegate) have a stake in the network. The top N candidates by staked amount are chosen to produce blocks with a valid set of transactions, where N is a configurable parameter. Part of each block reward goes to the collators that produced the block, who then share it with the delegators considering their percental contributions towards the collator's stake. In such a way, network members are incentivized to stake tokens to improve the overall security. Since staking is done at a protocol level through the staking interface, if you choose to delegate, the collators you delegate to do not have access to your tokens.

To easily manage staking related actions, you can visit the [Moonbeam Network DApp](https://apps.moonbeam.network){target=\_blank} and use the network tabs at the top of the page to easily switch between Moonbeam networks. To learn how to use the DApp, you can check out the [How to Stake MOVR Tokens](https://moonbeam.network/news/how-to-stake-movr-tokens-on-moonriver-and-earn-staking-rewards){target=\_blank} guide or [video tutorial](https://www.youtube.com/watch?v=8GwetYmzEJM){target=\_blank}, both of which can be adapted for the Moonbeam and the Moonbase Alpha TestNet.

## General Definitions {: #general-definitions }

Some important parameters to understand in relation to the staking system on Moonbeam include:

 - **Round** — a specific number of blocks around which staking actions are enforced. For example, new delegations are enacted when the next round starts. When bonding less or revoking delegations, funds are returned after a specified number of rounds
 - **Candidates** - node operators that are eligible to become block producers if they can acquire enough stake to be in the active set
 - **Collators** — active set of candidates that are selected to be block producers. They collect transactions from users and produce state transition proofs for the relay chain to validate
 - **Delegators** — token holders who stake tokens, vouching for specific collator candidates. Any user that holds a minimum amount of tokens as [free balance](https://wiki.polkadot.com/learn/learn-accounts/#balance-types#balance-types) can become a delegator
 - **Minimum delegation per candidate** — minimum amount of tokens to delegate candidates once a user is in the set of delegators
 - **Maximum delegators per candidate** — maximum number of delegators, by staked amount, that a candidate can have which are eligible to receive staking rewards
 - **Maximum delegations** — maximum number of candidates a delegator can delegate
 - **Exit delay** - an exit delay is the amount of rounds before a candidate or delegator can execute a scheduled request to decrease or revoke a bond, or leave the set of candidates or delegators
 - **Reward payout delay** - a certain amount of rounds must pass before staking rewards are distributed automatically to the free balance
 - **Reward pool** - a portion of the annual inflation that is set aside for collators and delegators
 - **Collator commission** - default fixed percent a collator takes off the top of the due staking rewards. Not related to the reward pool
 - **Delegator rewards** — the aggregate delegator rewards distributed over all eligible delegators, taking into account the relative size of stakes ([read more](/learn/features/staking/#reward-distribution))
 - **Auto-compounding** - a setting that automatically applies a percentage of a delegator's rewards to their total amount delegated
 - **Slashing** — a mechanism to discourage collator misbehavior, where typically the collator and their delegators get slashed by losing a percentage of their stake. Currently, there is no slashing but this can be changed through governance. Collators who produce blocks that are not finalized by the relay chain won't receive rewards

## Quick Reference {: #quick-reference }

=== "Moonbeam"
    |             Variable             |                                                                         Value                                                                         |
    |:--------------------------------:|:-----------------------------------------------------------------------------------------------------------------------------------------------------:|
    |          Round duration          |                        {{ networks.moonbeam.staking.round_blocks }} blocks ({{ networks.moonbeam.staking.round_hours }} hours)                        |
    | Minimum delegation per candidate |                                                  {{ networks.moonbeam.staking.min_del_stake }} GLMR                                                   |
    | Maximum delegators per candidate |                                                    {{ networks.moonbeam.staking.max_del_per_can }}                                                    |
    |       Maximum delegations        |                                                    {{ networks.moonbeam.staking.max_del_per_del }}                                                    |
    |       Reward payout delay        |    {{ networks.moonbeam.delegator_timings.rewards_payouts.rounds }} rounds ({{ networks.moonbeam.delegator_timings.rewards_payouts.hours }} hours)    |
    |    Add or increase delegation    |                                           takes effect in the next round (funds are withdrawn immediately)                                            |
    |    Decrease delegation delay     |      {{ networks.moonbeam.delegator_timings.del_bond_less.rounds }} rounds ({{ networks.moonbeam.delegator_timings.del_bond_less.hours }} hours)      |
    |     Revoke delegations delay     | {{ networks.moonbeam.delegator_timings.revoke_delegations.rounds }} rounds ({{ networks.moonbeam.delegator_timings.revoke_delegations.hours }} hours) |
    |      Leave delegators delay      |   {{ networks.moonbeam.delegator_timings.leave_delegators.rounds }} rounds ({{ networks.moonbeam.delegator_timings.leave_delegators.hours }} hours)   |

=== "Moonriver"
    |             Variable             |                                                                          Value                                                                          |
    |:--------------------------------:|:-------------------------------------------------------------------------------------------------------------------------------------------------------:|
    |          Round duration          |                        {{ networks.moonriver.staking.round_blocks }} blocks ({{ networks.moonriver.staking.round_hours }} hours)                        |
    | Minimum delegation per candidate |                                                   {{ networks.moonriver.staking.min_del_stake }} MOVR                                                   |
    | Maximum delegators per candidate |                                                    {{ networks.moonriver.staking.max_del_per_can }}                                                     |
    |       Maximum delegations        |                                                    {{ networks.moonriver.staking.max_del_per_del }}                                                     |
    |       Reward payout delay        |    {{ networks.moonriver.delegator_timings.rewards_payouts.rounds }} rounds ({{ networks.moonriver.delegator_timings.rewards_payouts.hours }} hours)    |
    |    Add or increase delegation    |                                            takes effect in the next round (funds are withdrawn immediately)                                             |
    |    Decrease delegation delay     |      {{ networks.moonriver.delegator_timings.del_bond_less.rounds }} rounds ({{ networks.moonriver.delegator_timings.del_bond_less.hours }} hours)      |
    |     Revoke delegations delay     | {{ networks.moonriver.delegator_timings.revoke_delegations.rounds }} rounds ({{ networks.moonriver.delegator_timings.revoke_delegations.hours }} hours) |
    |      Leave delegators delay      |   {{ networks.moonriver.delegator_timings.leave_delegators.rounds }} rounds ({{ networks.moonriver.delegator_timings.leave_delegators.hours }} hours)   |

=== "Moonbase Alpha"
    |             Variable             |                                                                         Value                                                                         |
    |:--------------------------------:|:-----------------------------------------------------------------------------------------------------------------------------------------------------:|
    |          Round duration          |                        {{ networks.moonbase.staking.round_blocks }} blocks ({{ networks.moonbase.staking.round_hours }} hours)                        |
    | Minimum delegation per candidate |                                                   {{ networks.moonbase.staking.min_del_stake }} DEV                                                   |
    | Maximum delegators per candidate |                                                    {{ networks.moonbase.staking.max_del_per_can }}                                                    |
    |       Maximum delegations        |                                                    {{ networks.moonbase.staking.max_del_per_del }}                                                    |
    |       Reward payout delay        |    {{ networks.moonbase.delegator_timings.rewards_payouts.rounds }} rounds ({{ networks.moonbase.delegator_timings.rewards_payouts.hours }} hours)    |
    |    Add or increase delegation    |                                           takes effect in the next round (funds are withdrawn immediately)                                            |
    |    Decrease delegation delay     |      {{ networks.moonbase.delegator_timings.del_bond_less.rounds }} rounds ({{ networks.moonbase.delegator_timings.del_bond_less.hours }} hours)      |
    |     Revoke delegations delay     | {{ networks.moonbase.delegator_timings.revoke_delegations.rounds }} rounds ({{ networks.moonbase.delegator_timings.revoke_delegations.hours }} hours) |
    |      Leave delegators delay      |   {{ networks.moonbase.delegator_timings.leave_delegators.rounds }} rounds ({{ networks.moonbase.delegator_timings.leave_delegators.hours }} hours)   |

!!! note
    As of runtime 3000, [asynchronous backing](https://wiki.polkadot.com/learn/learn-async-backing/#asynchronous-backing){target=\_blank} has been enabled on all Moonbeam networks. As a result, the target block time was reduced from 12 seconds to 6 seconds, which may break some timing-based assumptions.

To learn how to get the current value of any of the parameters around staking, check out the [Retrieving Staking Parameters](/tokens/staking/stake/#retrieving-staking-parameters){target=\_blank} section of the [How to Stake your Tokens](/tokens/staking/stake/){target=\_blank} guide.

If you're looking for candidate or collator-specific requirements and information, you can take a look at the [Collators](/node-operators/networks/collators/requirements/#bonding-requirements){target=\_blank} guide.

## Resources for Selecting a Collator {: #resources-for-selecting-a-collator}

There are a few resources you can check out to help you select a collator to delegate:

=== "Moonbeam"
    |           Variable           |                                      Value                                      |
    |:----------------------------:|:-------------------------------------------------------------------------------:|
    |     Stake GLMR Dashboard     |              [Stake GLMR](https://stakeglmr.com){target=\_blank}               |
    |    Collators Leaderboard     |       [Moonscan](https://moonbeam.moonscan.io/collators){target=\_blank}       |
    |      Collator Dashboard      | [DappLooker](https://dapplooker.com/dashboard/moonbeam-collator-dashboard-91){target=\_blank} |

=== "Moonriver"
    |           Variable           |                                      Value                                       |
    |:----------------------------:|:--------------------------------------------------------------------------------:|
    |     Stake MOVR Dashboard     |               [Stake MOVR](https://stakemovr.com){target=\_blank}               |
    |    Collators Leaderboard     |       [Moonscan](https://moonriver.moonscan.io/collators){target=\_blank}       |
    |      Collator Dashboard      | [DappLooker](https://dapplooker.com/dashboard/moonriver-collator-dashboard-28){target=\_blank} |

=== "Moonbase Alpha"
    |      Variable      |                                      Value                                       |
    |:------------------:|:--------------------------------------------------------------------------------:|
    | List of candidates | [Moonbase Alpha Subscan](https://moonbase.subscan.io/validator){target=\_blank} |

!!! note
    The DappLooker Collator dashboard for Moonriver is experimental beta software and may not accurately reflect collator performance. Be sure to do your own research before delegating to a collator.

### General Tips {: #general-tips }

- To optimize your staking rewards, you should generally choose a collator with a lower total amount bonded. In that case, your delegation amount will represent a larger portion of the collator’s total stake and you will earn proportionally higher rewards. However, there is a higher risk of the collator being kicked out of the active set and not earning rewards at all
- The minimum bond for each collator tends to increase over time, so if your delegation is close to the minimum, there is a higher chance you might fall below the minimum and not receive rewards
- Spreading delegations between multiple collators is more efficient in terms of rewards, but only recommended if you have enough to stay above the minimum bond of each collator
- You can consider collator performance by reviewing the number of blocks each collator has produced recently
- You can set up auto-compounding which will automatically restake a specified percentage of your delegation rewards

## Reward Distribution {: #reward-distribution }

Rewards for collators and their delegators are calculated at the start of every round for their work prior to the [reward payout delay](#quick-reference). For example, on Moonriver the rewards are calculated for the collators work from {{ networks.moonriver.delegator_timings.rewards_payouts.rounds }} rounds ago.

The calculated rewards are then paid out on a block-by-block basis starting at the second block of the round. For every block, one collator will be chosen to receive their entire reward payout from the prior round, along with their delegators, until all rewards have been paid out for that round. For example, if there are {{ networks.moonriver.staking.max_candidates }} collators who produced blocks in the prior round, all of the collators and their delegators will be paid by block {{ networks.moonriver.staking.paid_out_block }} of the new round.

You can choose to auto-compound your delegation rewards so you no longer have to manually delegate rewards. If you choose to set up auto-compounding, you can specify the percentage of rewards to be auto-compounded. These rewards will then be automatically added to your delegation.

### Annual Inflation {: #annual-inflation}

The distribution of the annual inflation goes as follows:

=== "Moonbeam"
    |                 Variable                  |                                         Value                                         |
    |:-----------------------------------------:|:-------------------------------------------------------------------------------------:|
    |             Annual inflation              |               {{ networks.moonbeam.inflation.total_annual_inflation }}%               |
    | Rewards pool for collators and delegators | {{ networks.moonbeam.inflation.delegator_reward_inflation }}% of the annual inflation |
    |            Collator commission            | {{ networks.moonbeam.inflation.collator_reward_inflation }}% of the annual inflation  |
    |          Parachain bond reserve           |  {{ networks.moonbeam.inflation.parachain_bond_inflation }}% of the annual inflation  |

=== "Moonriver"
    |                 Variable                  |                                         Value                                          |
    |:-----------------------------------------:|:--------------------------------------------------------------------------------------:|
    |             Annual inflation              |               {{ networks.moonriver.inflation.total_annual_inflation }}%               |
    | Rewards pool for collators and delegators | {{ networks.moonriver.inflation.delegator_reward_inflation }}% of the annual inflation |
    |            Collator commission            | {{ networks.moonriver.inflation.collator_reward_inflation }}% of the annual inflation  |
    |          Parachain bond reserve           |  {{ networks.moonriver.inflation.parachain_bond_inflation }}% of the annual inflation  |

=== "Moonbase Alpha"
    |                 Variable                  |                                         Value                                         |
    |:-----------------------------------------:|:-------------------------------------------------------------------------------------:|
    |             Annual inflation              |               {{ networks.moonbase.inflation.total_annual_inflation }}%               |
    | Rewards pool for collators and delegators | {{ networks.moonbase.inflation.delegator_reward_inflation }}% of the annual inflation |
    |            Collator commission            | {{ networks.moonbase.inflation.collator_reward_inflation }}% of the annual inflation  |
    |          Parachain bond reserve           |  {{ networks.moonbase.inflation.parachain_bond_inflation }}% of the annual inflation  |

From the rewards pool, collators get the rewards corresponding to their stake in the network. The rest are distributed among delegators by stake.

### Calculating Rewards {: #calculating-rewards }

Mathematically speaking, for collators, the reward distribution per block proposed and finalized would look like this:

![Staking Collator Reward](/images/learn/features/staking/staking-overview-1.webp)

Where `amount_due` is the corresponding inflation being distributed in a specific block, the `stake` corresponds to the number of tokens bonded by the collator in respect to the total stake of that collator (accounting delegations).

For each delegator, the reward distribution (per block proposed and finalized by the delegated collator) would look like this:

![Staking Delegator Reward](/images/learn/features/staking/staking-overview-2.webp)

Where `amount_due` is the corresponding inflation being distributed in a specific block, the `stake` corresponds to the amount of tokens bonded by each delegator in respect to the total stake of that collator.

## Risks {: #risks }

*Holders of MOVR/GLMR tokens should perform careful due diligence on collators before delegating. Being listed as a collator is not an endorsement or recommendation from the Moonbeam Network, the Moonriver Network, or Moonbeam Foundation. Neither the Moonbeam Network, Moonriver Network, nor Moonbeam Foundation has vetted the list collators and assumes no responsibility with regard to the selection, performance, security, accuracy, or use of any third-party offerings.  You alone are responsible for doing your own diligence to understand the applicable fees and all risks present, including actively monitoring the activity of your collators.*

*You agree and understand that neither the Moonbeam Network, the Moonriver Network, nor Moonbeam Foundation guarantees that you will receive staking rewards and any applicable percentage provided (i) is an estimate only and not guaranteed, (ii) may change at any time and (iii) may be more or less than the actual staking rewards you receive. The Moonbeam Foundation makes no representations as to the monetary value of any rewards at any time.*

*Staking MOVR/GLMR tokens is not free of risk.*
*Staked MOVR/GLMR tokens are locked up, and retrieving them requires a {{ networks.moonriver.delegator_timings.del_bond_less.days }} day/{{ networks.moonbeam.delegator_timings.del_bond_less.days }} day waiting period .*
*Additionally, if a collator fails to perform required functions or acts in bad faith, a portion of their total stake can be slashed (i.e. destroyed). This includes the stake of their delegators. If a collators behaves suspiciously or is too often offline, delegators can choose to unbond from them or switch to another collator. Delegators can also mitigate risk by electing to distribute their stake across multiple collators.*
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/learn/features/treasury/
--- BEGIN CONTENT ---
---
title: Treasury
description: Moonbeam has an on-chain Treasury controlled by Treasury Council members, enabling stakeholders to submit proposals to further the network.
categories: Basics
---

# Treasury on Moonbeam

## Introduction {: #introduction }

The Moonbeam Treasury is an on-chain collection of funds launched at the network's genesis. Initially pre-funded with 0.5% of the token supply, the Treasury continues to accumulate GLMR as {{ networks.moonbeam.inflation.parachain_bond_treasury }}% of the parachain bond reserve inflation goes to the Treasury. For more information about Moonbeam inflation figures, see [GLMR Tokenomics](https://moonbeam.foundation/glimmer-token-tokenomics/){target=\_blank}.

The Moonbeam Treasury funds initiatives that support and grow the network. Stakeholders can propose spending requests for Treasury Council review, focusing on efforts like integrations, collaborations, community events, and outreach. Treasury spend proposers must submit their proposals to the [Moonbeam Forum](https://forum.moonbeam.network/c/governance/treasury-proposals/8){target=\_blank}. For submission details, see [How to Propose a Treasury Spend](/tokens/governance/treasury-spend/){target=\_blank}.

The [Treasury Council](https://forum.moonbeam.network/g/TreasuryCouncil){target=\_blank} oversees the spending of the Moonbeam Treasury and votes on funding proposals. It comprises two members from the Moonbeam Foundation and three external community members. The three external members are elected to terms of {{ networks.moonbeam.treasury.months_elected }} months. The same Treasury Council oversees Treasury requests for both Moonbeam and Moonriver. The Council meets monthly to review proposals submitted on the [Moonbeam Forum](https://forum.moonbeam.network/c/governance/treasury-proposals/8){target=\_blank}. Once a proposal is agreed upon, the Council members must complete the on-chain approval process.

## General Definitions {: #general-definitions }

Some important terminology to understand regarding treasuries:

- **Treasury Council** — a group of Moonbeam Foundation representatives and external community members. The Council reviews funding proposals, ensures alignment with the community, and ultimately authorizes Treasury spending
- **Proposal** — a plan or suggestion submitted by stakeholders to further the network to be approved by the Treasury Council

## Treasury Addresses {: #treasury-addresses }

The Treasury address for each respective network can be found below:

=== "Moonbeam"

    [0x6d6F646c70632f74727372790000000000000000](https://moonbase.subscan.io/account/0x6d6F646c70632f74727372790000000000000000){target=_blank}

=== "Moonriver"

    [0x6d6f646C70792f74727372790000000000000000](https://moonriver.subscan.io/account/0x6d6f646C70792f74727372790000000000000000){target=_blank}

=== "Moonbase Alpha"

    [0x6d6F646c70632f74727372790000000000000000](https://moonbase.subscan.io/account/0x6d6F646c70632f74727372790000000000000000){target=_blank}


## Roadmap of a Treasury Proposal {: #roadmap-of-a-treasury-proposal }

The happy path of a Treasury spend request is as follows:

1. **Proposal submission** - the user submits a proposal to the [Moonbeam Forum](https://forum.moonbeam.network/c/governance/treasury-proposals/8){target=\_blank}

2. **Forum discussion** - the proposal is discussed by the community on the Forum. The ultimate Aye/Nay decision is determined by the Treasury council

3. **Treasury approval and action** - if the Treasury Council agrees, it authorizes the Treasury spending and moves the process forward

## Treasury Council Voting Process {: #treasury-council-voting-process }

A member of the Treasury Council will submit a `treasury.spend` call. This call requires specifying the amount, the asset type, and the beneficiary account to receive the funds. The Treasury supports spending various token types beyond GLMR, including native USDT/USDC. Once this extrinsic is submitted, a new Treasury Council collective proposal will be created and made available for council members to vote on. Once approved through the Treasury Council's internal voting process, the funds will be released automatically to the beneficiary account through the `treasury.payout` extrinsic.
 
!!! note
    There is no on-chain action for the proposer or beneficiary of the Treasury spend request.
    All Treasury spend actions will be completed by members of the Treasury Council.

Note that this process has changed significantly from prior Treasury processes, where tokenholders could submit Treasury proposals with bonds attached. Now, no on-chain action is necessary to submit a Treasury proposal. Rather, all that is needed is to raise a Treasury Council request on the [Moonbeam Forum](https://forum.moonbeam.network/c/governance/treasury-proposals/8){target=\_blank} and the Treasury Council will take care of the on-chain components. 

For more information, see [How to Propose a Treasury Spend](/tokens/governance/treasury-spend/#next-steps){target=\_blank}
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/learn/features/xchain-plans/
--- BEGIN CONTENT ---
---
title: Cross-Chain Communication
description: This guide covers the ways you can build cross-chain dApps with Moonbeam, including via XCM, cross consensus messaging, and GMP, general message passing.
categories: Basics, XCM
---

# Cross-Chain Communication Methods

Moonbeam makes it easy for developers to build smart contracts that connect across chains, both within the Polkadot ecosystem and outside the Polkadot ecosystem. This page will provide an overview of the underlying protocols that enable cross-chain communication and how you can leverage them to build connected contracts. For step-by-step guides of how to put these principles into practice, be sure to check out the [interoperability tutorials](/tutorials/interoperability/){target=\_blank}.

Two key terms that will come up frequently in this guide are XCM and GMP. [XCM](/builders/interoperability/xcm/){target=\_blank} refers to cross-consensus messaging, and it's Polkadot's native interoperability language that facilitates communication between Polkadot blockchains. You can read more about the [standardized XCM message format](https://docs.polkadot.com/develop/interoperability/intro-to-xcm/){target=\_blank} and [How to Get Started Building with XCM](/builders/interoperability/xcm/){target=\_blank}.

[GMP](https://moonbeam.network/news/seamless-blockchain-interoperability-the-power-of-general-message-passing-gmp){target=\_blank}, or general message passing, refers to the sending and receiving of messages within decentralized blockchain networks. While XCM is a type of general message passing, GMP colloquially refers to cross-chain communication between Moonbeam and blockchains outside of Polkadot. Similarly, in this guide, XCM refers to cross-chain messaging within Polkadot, and GMP refers to cross-chain messaging between Moonbeam and other ecosystems outside of Polkadot.

## Quick Reference {: #quick-reference }  

=== "Comparison of XCM vs GMP"
|     Specification     |                                                                       XCM                                                                        |                                                                                                                                                       GMP                                                                                                                                                        |
|:---------------------:|:------------------------------------------------------------------------------------------------------------------------------------------------:|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|
|       **Scope**       |                                                      Polkadot and its connected parachains                                                       |                                                                                                                                    Any blockchain supported by a GMP provider                                                                                                                                    |
|     **Provider**      |                                                                     Polkadot                                                                     | [Axelar](/builders/interoperability/protocols/axelar/){target=\_blank}, [Wormhole](/builders/interoperability/protocols/wormhole/){target=\_blank}, [LayerZero](/builders/interoperability/protocols/layerzero/){target=\_blank}, [Hyperlane](/builders/interoperability/protocols/hyperlane/){target=\_blank}, etc. |
|  **Implementation**   |                               [XCM Virtual Machine](https://wiki.polkadot.com/learn/learn-xcvm/){target=\_blank}                               |                                                                                                                                                 Smart contracts                                                                                                                                                  |
|     **Security**      |                                                            Polkadot's shared security                                                            |                                                                                                                                 Proprietary consensus determined by GMP provider                                                                                                                                 |
|       **Fees**        | [Purchased with `BuyExecution` XCM instruction with supported asset](/builders/interoperability/xcm/core-concepts/weights-fees/){target=\_blank} |                                                                                                                    User sends value with transaction to pay for gas on the destination chain                                                                                                                     |
| **Adding New Chains** |                                            Requires creation of XCM channels by both connected chains                                            |                                                                                                                                       Requires GMP provider to add support                                                                                                                                       |

## XCM Transport Methods {: #xcm-transport-methods }  

XCMP is the protocol that carries messages conforming to the XCM standard. The difference between the two is easy to remember with the added letter "P" for protocol. While XCM is the language that defines the format of the message to send, XCMP can be thought of as the pipes that enable the delivery of said messages.

XCMP is comprised of channels that enable communication between connected blockchains. When a parachain launches on Polkadot, two XCM channels are established automatically to allow for communication between the Polkadot relay chain and the parachain itself. XCM channels are omnidirectional, so two channels must be established for bidirectional communication. 

Polkadot parachains can optionally choose to establish additional XCM channels with other parachains. Establishing XCM channels with other chains is a double opt-in process, so the receiving chain must also agree to have the channel established. Establishing XCM channels with another parachain allows for the exchange of XCM messages, enabling the flow of cross-chain assets and remote contract calls, to name a few examples. 

There are several different subcategories of XCM transport methods, including:

### VMP {: #vmp } 

VMP, or [Vertical Message Passing](https://wiki.polkadot.com/learn/learn-xcm-transport/#vmp-vertical-message-passing){target=\_blank}, refers to message passing between the relay chain and a parachain. Given that XCM channels are one-way, there are two types of message passing that comprise VMP, namely:  

- **UMP** - Upward Message Passing refers to message passing from a parachain to the relay chain
- **DMP** - Downward Message Passing refers to message passing from the relay chain to a parachain

### HRMP {: #HRMP } 

[Horizontal Relay-routed Message Passing](https://wiki.polkadot.com/learn/learn-xcm-transport/#hrmp-xcmp-lite){target=\_blank} (HRMP) is a temporary protocol that is currently being used while XCMP (Cross-Chain Message Passing) is still under development. HRMP serves as a placeholder and provides the same functionality and interface as XCMP. However, HRMP is more resource-intensive because it stores all messages within the Relay Chain's storage. 

When opening XCM channels with other parachains today, those channels are using HRMP in place of the aforementioned XCMP. Once the implementation of XCMP is complete, the plan is to phase out HRMP and replace it with XCMP gradually. For more information about each one, be sure to check out [Polkadot's Guide to XCM Transport](https://wiki.polkadot.com/learn/learn-xcm-transport/){target=\_blank}.

## General Message Passing {: #general-message-passing } 

As you know, GMP colloquially refers to cross-chain communication between Moonbeam and other blockchains outside of Polkadot. General message passing is enabled by cross-chain protocols that specialize in cross-chain communication. Each GMP provider takes a slightly different approach, but conceptually, they are quite similar. There are different contracts and functions for each provider, but each GMP provider has the same end goal: to provide secure and reliable cross-chain communication.  

### Happy Path of a Cross-Chain Message {: #happy-path-of-a-cross-chain-message } 

At a high level, the happy path of a message sent via GMP is as follows. A user or developer will call a contract specific to the GMP protocol, sometimes referred to as a mailbox contract or a gateway contract. This call typically includes parameters like the destination chain, the destination contract address, and includes sufficient value to pay for the transaction on the destination chain. A GMP provider listens for specific events on the origin blockchain pertaining to their gateway or mailbox contracts that indicate that a user wants to send a cross-chain message using their protocol. The GMP provider will validate certain parameters, including whether or not sufficient value was provided to pay for gas on the destination chain. In fact, the GMP provider may have a decentralized network of many nodes checking the authenticity of the message and verifying parameters. The GMP provider will not validate the integrity of the contract call to be delivered on the destination chain. E.g., the GMP provider will happily deliver a valid, paid-for message that contains a smart contract call that reverts on arrival. Finally, if everything checks out according to the consensus mechanism of the GMP provider, the message will be delivered to the destination chain, triggering the respective contract call at the destination.

![Happy Path of a cross chain GMP message](/images/learn/features/xchain-plans/xchain-plans-1.webp) 

### GMP Providers Integrated with Moonbeam {: #gmp-providers-integrated-with-moonbeam } 
A large number of GMP providers have integrated with Moonbeam, which is beneficial for several reasons. For one, it enables you to work with whichever GMP provider you prefer. Second, it means that Moonbeam is connected to a rapidly growing number of chains. Whenever a GMP provider integrated with Moonbeam adds support for another chain, Moonbeam is automatically now connected with that chain. GMP providers are constantly adding support for new chains, and it's exciting to see those new integrations benefit the Moonbeam community. Additionally, having a variety of GMP providers allows for redundancy and backup. GMP providers have occasional maintenance windows or downtime; thus, it may make sense to add support for multiple GMP providers to ensure consistent uptime. 

A significant number of GMP providers have integrated with Moonbeam, offering multiple benefits. Firstly, this integration allows users the flexibility to choose their preferred GMP provider. Secondly, Moonbeam's connectivity is enhanced as it automatically links with any new chains that its GMP providers support. Given that GMP providers frequently expand their support to new chains, the continuous roll out of new chains is a promising ongoing benefit for the Moonbeam community. Additionally, the diversity of GMP providers ensures better reliability and backup options. Since GMP providers can occasionally experience downtime or scheduled maintenance, the ability to integrate with multiple GMP providers is an important benefit.

The following GMP providers have integrated with Moonbeam: 

- [Axelar](/builders/interoperability/protocols/axelar/){target=\_blank}
- [Hyperlane](/builders/interoperability/protocols/hyperlane/){target=\_blank}
- [LayerZero](/builders/interoperability/protocols/layerzero/){target=\_blank} 
- [Wormhole](/builders/interoperability/protocols/wormhole/){target=\_blank}

## Implementing Both XCM and GMP {: #implementing-both-xcm-and-gmp } 

Building with XCM or GMP does not preclude building with the other. As they suit different use cases, a team may seek to utilize XCM to handle interoperability needs within Polkadot, and GMP to deliver cross-chain messages to and from blockchains outside of Polkadot. As an example, several DEXes on Moonbeam support the trading of tokens migrated to Moonbeam via XCM, such as xcDOT, and assets bridged from ecosystems outside of Polkadot, such as USDC via Wormhole. 

### Moonbeam Routed Liquidity {: #moonbeam-routed-liquidity }

[Moonbeam Routed Liquidity](/builders/interoperability/mrl/) (MRL) enables seamless liquidity between external blockchains connected to Moonbeam via Wormhole to Polkadot parachains connected to Moonbeam via XCM. This combination of GMP and XCM means that any ERC-20 token on a chain that Wormhole has integrated with can be routed through Moonbeam to a destination parachain (and back). A diagram of the happy path of a token transfer to a parachain via MRL is shown below, and you can find more information at the [MRL docs](/builders/interoperability/mrl/). 

![Happy Path of an MRL token transfer](/images/learn/features/xchain-plans/xchain-plans-2.webp) 


<div class="page-disclaimer">
  The information presented herein has been provided by third parties and is made available solely for general information purposes. Moonbeam does not endorse any project listed and described on the Moonbeam Doc Website (https://docs.moonbeam.network/). Moonbeam Foundation does not warrant the accuracy, completeness or usefulness of this information. Any reliance you place on such information is strictly at your own risk. Moonbeam Foundation disclaims all liability and responsibility arising from any reliance placed on this information by you or by anyone who may be informed of any of its contents. All statements and/or opinions expressed in these materials are solely the responsibility of the person or entity providing those materials and do not necessarily represent the opinion of Moonbeam Foundation. The information should not be construed as professional or financial advice of any kind. Advice from a suitably qualified professional should always be sought in relation to any particular matter or circumstance. The information herein may link to or integrate with other websites operated or content provided by third parties, and such other websites may link to this website. Moonbeam Foundation has no control over any such other websites or their content and will have no liability arising out of or related to such websites or their content. The existence of any such link does not constitute an endorsement of such websites, the content of the websites, or the operators of the websites. These links are being provided to you only as a convenience and you release and hold Moonbeam Foundation harmless from any and all liability arising from your use of this information or the information provided by any third-party website or service.
</div>
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/learn/platform/code/
--- BEGIN CONTENT ---
---
title: Moonbeam Source Code
description: Moonbeam is an open source project in the Polkadot ecosystem, with publicly available and auditable source code.
categories: Basics
---

# Moonbeam Source Code

Moonbeam is an open source project.  The main Moonbeam repo can be found here:

[:fontawesome-brands-github: https://github.com/moonbeam-foundation/moonbeam](https://github.com/moonbeam-foundation/moonbeam){target=\_blank}

Moonbeam is implemented using the Substrate framework. The source code for Substrate can be found here:

[:fontawesome-brands-github: https://github.com/paritytech/substrate](https://github.com/paritytech/polkadot-sdk/tree/master/substrate){target=\_blank}

We also work on Ethereum compatibility features along with engineers from Parity as part of the Frontier project. Source code for Frontier can be found here:

[:fontawesome-brands-github: https://github.com/polkadot-evm/frontier](https://github.com/polkadot-evm/frontier){target=\_blank}

If you are interested in contributing code to Moonbeam, please raise an issue or PR on the [Moonbeam GitHub repository](https://github.com/moonbeam-foundation/moonbeam){target=\_blank}
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/learn/platform/links/
--- BEGIN CONTENT ---
---
title: Important Moonbeam Related Links
description: If you're new to Moonbeam or the Polkadot network, here are some important links to review, including compatible Ethereum tools.
categories: Basics
---

# Links

 - **[Polkadot Docs](https://docs.polkadot.com/){target=\_blank}** - starting point for learning about the [Polkadot SDK](https://docs.polkadot.com/develop/parachains/intro-polkadot-sdk/){target=\_blank}, a Rust-based framework for developing blockchains. Moonbeam is developed using Substrate and uses many of the modules that come with it
 - **[Polkadot.com](https://polkadot.com){target=\_blank}** - learn about Polkadot, including the vision behind the network and how the system works, i.e., staking, governance, etc.
 - **[Polkadot-JS Apps](https://polkadot.js.org/apps){target=\_blank}** - a web-based interface for interacting with Substrate based nodes, including Moonbeam
 - **[Solidity Docs](https://solidity.readthedocs.io){target=\_blank}** - Solidity is the main smart contract programming language supported by Ethereum and Moonbeam.  The Solidity docs site is very comprehensive
 - **[Remix](https://remix.ethereum.org){target=\_blank}** - web-based IDE for Solidity smart contract development that is compatible with Moonbeam
 - **[Hardhat](https://hardhat.org){target=\_blank}** - development tools for Solidity, including debugging, testing, and automated deployment that is compatible with Moonbeam
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/learn/platform/networks/moonbase/
--- BEGIN CONTENT ---
---
title: Moonbase Alpha TestNet Overview
description: An overview of the current configuration of the Moonbeam TestNet, Moonbase Alpha, and information on how to start building on it using Solidity.
categories: Basics
---

# The Moonbase Alpha TestNet

## Goal {: #goal }

The first Moonbeam TestNet, named Moonbase Alpha, aims to provide developers with a place to start experimenting and building on Moonbeam in a shared environment. Since Moonbeam is deployed as a parachain on Kusama and Polkadot, the goal of the TestNet is to reflect the production configurations. For this reason, it was decided that it needed to be a parachain-based configuration rather than a Substrate development setup.

In order to collect as much feedback as possible and provide fast issue resolution, please join the [Moonbeam Discord](https://discord.com/invite/PfpUATX){target=\_blank}.

## Initial Configuration {: #initial-configuration }

Moonbase Alpha has the following configuration:

 - Runs as a parachain connected to a relay chain
 - Has an active set of {{ networks.moonbase.staking.max_candidates }} collator nodes run by the community
 - The relay chain hosts validators to finalize relay chain blocks. One of them is selected to finalize each block collated by Moonbeam's collators. This setup provides room to expand to a two-parachain configuration in the future
 - Has infrastructure providers that provide [API endpoints](/builders/get-started/endpoints/){target=\_blank} to connect to the network. Projects can also [run their own node](/node-operators/networks/run-a-node/){target=\_blank} to have access to their own private endpoints

![TestNet Diagram](/images/learn/platform/networks/moonbase-diagram.webp)

Some important variables/configurations to note include:

=== "General"
    |       Variable        |                   Value                    |
    |:---------------------:|:------------------------------------------:|
    |   Minimum gas price   | {{ networks.moonbase.min_gas_price }} Gwei |
    |   Target block time   | {{ networks.moonbase.block_time }} seconds |
    |    Block gas limit    |     {{ networks.moonbase.gas_block }}      |
    | Transaction gas limit |       {{ networks.moonbase.gas_tx }}       |

=== "Staking"
    |             Variable              |                                                                    Value                                                                    |
    |:---------------------------------:|:-------------------------------------------------------------------------------------------------------------------------------------------:|
    |     Minimum delegation stake      |                                              {{ networks.moonbase.staking.min_del_stake }} DEV                                              |
    | Maximum delegators per candidates |                                               {{ networks.moonbase.staking.max_del_per_can }}                                               |
    |  Maximum delegations per account  |                                               {{ networks.moonbase.staking.max_del_per_del }}                                               |
    |               Round               |                   {{ networks.moonbase.staking.round_blocks }} blocks ({{ networks.moonbase.staking.round_hours }} hour)                    |
    |           Bond duration           |                                 Delegations take effect in the next round; funds are withdrawn immediately                                 |
    |          Unbond duration          | {{ networks.moonbase.delegator_timings.del_bond_less.rounds }} rounds ({{ networks.moonbase.delegator_timings.del_bond_less.hours }} hours) |

!!! note
    As of runtime 3000, [asynchronous backing](https://wiki.polkadot.com/learn/learn-async-backing/#asynchronous-backing){target=\_blank} has been enabled on all Moonbeam networks. As a result, the target block time was reduced from 12 seconds to 6 seconds, which may break some timing-based assumptions.
    
    Additionally, as of runtime 2900, the block and transaction gas limits increased by 4x on Moonbase Alpha.

## Network Endpoints {: #network-endpoints }

Moonbase Alpha has two types of endpoints available for users to connect to: one for HTTPS and one for WSS.

If you're looking for your own endpoints suitable for production use, you can check out the [Endpoint Providers](/builders/get-started/endpoints/#endpoint-providers){target=\_blank} section of our documentation. Otherwise, to get started quickly you can use one of the following public HTTPS or WSS endpoints.

=== "HTTPS"
    |      Provider       |                              RPC URL                               |   Limits    |
    |:-------------------:|:------------------------------------------------------------------:|:-----------:|
    |       Dwellir       |         <pre>```https://moonbase-rpc.dwellir.com```</pre>          | 20 req/sec  |
    |     OnFinality      |  <pre>```https://moonbeam-alpha.api.onfinality.io/public```</pre>  | 40 req/sec  |
    | Moonbeam Foundation |     <pre>```https://rpc.api.moonbase.moonbeam.network```</pre>     | 25 req/sec  |
    |     UnitedBloc      |          <pre>```https://moonbase.unitedbloc.com```</pre>          | 32 req/sec  |
    |     RadiumBlock     | <pre>```https://moonbase.public.curie.radiumblock.co/http```</pre> | 200 req/sec |

=== "WSS"
    |      Provider       |                              RPC URL                              |   Limits    |
    |:-------------------:|:-----------------------------------------------------------------:|:-----------:|
    |       Dwellir       |          <pre>```wss://moonbase-rpc.dwellir.com```</pre>          | 20 req/sec  |
    |     OnFinality      | <pre>```wss://moonbeam-alpha.api.onfinality.io/public-ws```</pre> | 40 req/sec  |
    | Moonbeam Foundation |     <pre>```wss://wss.api.moonbase.moonbeam.network```</pre>      | 25 req/sec  |
    |     UnitedBloc      |          <pre>```wss://moonbase.unitedbloc.com```</pre>           | 32 req/sec  |
    |     RadiumBlock     |  <pre>```wss://moonbase.public.curie.radiumblock.co/ws```</pre>   | 200 req/sec |


#### Relay Chain {: #relay-chain }

To connect to the Moonbase Alpha relay chain, you can use the following WS Endpoint:

| Provider |                          RPC URL                           |
|:--------:|:----------------------------------------------------------:|
| OpsLayer | <pre>```wss://relay.api.moonbase.moonbeam.network```</pre> |

## Quick Start {: #quick-start }

For the [Web3.js library](/builders/ethereum/libraries/web3js/){target=\_blank}, you can create a local Web3 instance and set the provider to connect to Moonbase Alpha (both HTTP and WS are supported):

```js
const { Web3 } = require('web3'); // Load Web3 library
.
.
.
// Create local Web3 instance - set Moonbase Alpha as provider
const web3 = new Web3('https://rpc.api.moonbase.moonbeam.network'); 
```

For the [Ethers.js library](/builders/ethereum/libraries/ethersjs/){target=\_blank}, define the provider by using `ethers.JsonRpcProvider(providerURL, {object})` and setting the provider URL to Moonbase Alpha:

```js
const ethers = require('ethers'); // Load Ethers library

const providerURL = 'https://rpc.api.moonbase.moonbeam.network';
// Define provider
const provider = new ethers.JsonRpcProvider(providerURL, {
    chainId: 1287,
    name: 'moonbase-alphanet'
});
```

Any Ethereum wallet should be able to generate a valid address for Moonbeam (for example, [MetaMask](https://metamask.io){target=\_blank}).

## Chain ID {: #chain-id }

Moonbase Alpha TestNet chain ID is: `1287`, which is `0x507` in hex.

## Alphanet Relay Chain {: #relay-chain }

The Alphanet relay chain is connected to Moonbase Alpha and is [Westend](https://polkadot.com/blog/westend-introducing-a-new-testnet-for-polkadot-and-kusama){target=\_blank}-based but unique to the Moonbeam ecosystem. It resembles how you would interact with Kusama or Polkadot. The native tokens of the Alphanet relay chain are UNIT tokens, which are for testing purposes only and have no real value.

## Telemetry {: #telemetry }

You can see current Moonbase Alpha telemetry information by visiting [Polkadot's Telemetry dashboard](https://telemetry.polkadot.io/#list/0x91bc6e169807aaa54802737e1c504b2577d4fafedd5a02c10293b1cd60e39527){target=\_blank}.

## Tokens {: #tokens }

Tokens on Moonbase Alpha, named DEV, will be issued on demand. **DEV tokens hold no value and can be freely acquired**.

You can enter your address to automatically request DEV tokens from the [Moonbase Alpha Faucet](https://faucet.moonbeam.network){target=\_blank} website. The faucet dispenses {{ networks.moonbase.website_faucet_amount }} every 24 hours.

For token requests of more than the limited amount allowed by the faucet, contact a moderator directly via the [Moonbeam Discord server](https://discord.com/invite/PfpUATX){target=\_blank}. We are happy to provide the tokens needed to test your applications.

## Proof of Stake {: #proof-of-stake }

The Moonbase Alpha TestNet is a fully decentralized Delegated Proof of Stake network where users of the network can delegate collator candidates to produce blocks and "earn rewards" for testing purposes. Please note, that the Moonbase Alpha DEV tokens have no real value. The number of candidates in the active set will be subject to governance. The active set will consist of the top candidates by stake, including delegations.

## Limitations {: #limitations }

This is the first TestNet for Moonbeam, so there are some limitations.

Some [precompiles](https://www.evm.codes/precompiled){target=\_blank} are yet to be included. You can check out the list of supported precompiles on the [Canonical Contract page](/builders/ethereum/precompiles/){target=\_blank}. However, all built-in functions are available.

Since the release of Moonbase Alpha v6, the maximum gas limit per block has been set to {{ networks.moonbase.gas_block }}, with a maximum gas limit per transaction of {{ networks.moonbase.gas_tx }}.
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/learn/platform/networks/moonbeam/
--- BEGIN CONTENT ---
---
title: Moonbeam Network Overview
description: An overview of the current configuration of the Moonbeam deployment on Polkadot, Moonbeam, and information on how to start building on it using Solidity.
categories: Basics
---

# Moonbeam

## Goal {: #goal }

Moonbeam was onboarded as a parachain to Polkadot on December 17th 2021. Moonbeam is the most Ethereum compatible smart-contract parachain in the Polkadot ecosystem. It allows developers to port their projects with minimal to no code changes, enabling them to tap into the Polkadot ecosystem and all its assets.

In order to collect as much feedback as possible and provide fast issue resolution, you can check out the dedicated [Moonbeam Network section on Discord](https://discord.com/invite/PfpUATX){target=\_blank}.

## Initial Configurations {: #initial-configurations }

Currently, Moonbeam has the following configurations:

- Runs as a parachain connected to the Polkadot relay chain
- Has an active set of {{ networks.moonbeam.staking.max_candidates }} collators
- Has infrastructure providers that provide [API endpoints](/builders/get-started/endpoints/){target=\_blank} to connect to the network. Projects can also [run their own node](/node-operators/networks/run-a-node/){target=\_blank} to have access to their own private endpoints

![Moonbeam Diagram](/images/learn/platform/networks/moonbeam-diagram.webp)

Some important variables/configurations to note include (still subject to change):

=== "General"
    |       Variable        |                                  Value                                  |
    |:---------------------:|:-----------------------------------------------------------------------:|
    |   Minimum gas price   |               {{ networks.moonbeam.min_gas_price }} Gwei*               |
    |   Target block time   |               {{ networks.moonbeam.block_time }} seconds                |
    |    Block gas limit    | {{ networks.moonbeam.gas_block }}  |
    | Transaction gas limit |  {{ networks.moonbeam.gas_tx }}    |

=== "Staking"
    |             Variable              |                                                  Value                                                  |
    |:---------------------------------:|:-------------------------------------------------------------------------------------------------------:|
    |     Minimum delegation stake      |                           {{ networks.moonbeam.staking.min_del_stake }} GLMR                            |
    | Maximum delegators per candidates |                             {{ networks.moonbeam.staking.max_del_per_can }}                             |
    |  Maximum delegations per account  |                             {{ networks.moonbeam.staking.max_del_per_del }}                             |
    |               Round               | {{ networks.moonbeam.staking.round_blocks }} blocks ({{ networks.moonbeam.staking.round_hours }} hours) |
    |           Bond duration           |               delegation takes effect in the next round (funds are withdrawn immediately)               |
    |          Unbond duration          |                  {{ networks.moonbeam.delegator_timings.del_bond_less.rounds }} rounds                  |

_*Read more about [token denominations](#token-denominations)_

## Network Endpoints {: #network-endpoints }

Moonbeam has two types of endpoints available for users to connect to: one for HTTPS and one for WSS.

If you're looking for your own endpoints suitable for production use, you can check out the [Endpoint Providers](/builders/get-started/endpoints/#endpoint-providers){target=\_blank} section of our documentation. Otherwise, to get started quickly you can use one of the following public HTTPS or WSS endpoints:

=== "HTTPS"
    |  Provider   |                              RPC URL                               |   Limits    |
    |:-----------:|:------------------------------------------------------------------:|:-----------:|
    |   Dwellir   |         <pre>```https://moonbeam-rpc.dwellir.com```</pre>          | 20 req/sec  |
    | OnFinality  |     <pre>```https://moonbeam.api.onfinality.io/public```</pre>     | 40 req/sec  |
    | UnitedBloc  |          <pre>```https://moonbeam.unitedbloc.com```</pre>          | 32 req/sec  |
    | RadiumBlock | <pre>```https://moonbeam.public.curie.radiumblock.co/http```</pre> | 200 req/sec |
    |    1RPC     |               <pre>```https://1rpc.io/glmr```</pre>                | 10k req/day |
    |    Grove    |         <pre>```https://moonbeam.rpc.grove.city/v1/01fdb492```</pre>         | 5k req/day  |



=== "WSS"
    |  Provider   |                            RPC URL                             |   Limits    |
    |:-----------:|:--------------------------------------------------------------:|:-----------:|
    |   Dwellir   |        <pre>```wss://moonbeam-rpc.dwellir.com```</pre>         | 20 req/sec  |
    | OnFinality  |  <pre>```wss://moonbeam.api.onfinality.io/public-ws```</pre>   | 40 req/sec  |
    | UnitedBloc  |         <pre>```wss://moonbeam.unitedbloc.com```</pre>         | 32 req/sec  |
    | RadiumBlock | <pre>```wss://moonbeam.public.curie.radiumblock.co/ws```</pre> | 200 req/sec |
    |    1RPC     |              <pre>```wss://1rpc.io/glmr```</pre>               | 10k req/day |

## Quick Start {: #quick-start }

Before getting started, make sure you've retrieved your own endpoint and API key from one of the custom [Endpoint Providers](/builders/get-started/endpoints/){target=\_blank}. Then for the [Web3.js library](/builders/ethereum/libraries/web3js/){target=\_blank}, you can create a local Web3 instance and set the provider to connect to Moonbeam (both HTTP and WS are supported):

```js
const { Web3 } = require('web3'); // Load Web3 library
.
.
.
// Create local Web3 instance - set Moonbeam as provider
const web3 = new Web3('INSERT_RPC_API_ENDPOINT'); // Insert your RPC URL here
```

For the [Ethers.js library](/builders/ethereum/libraries/ethersjs/){target=\_blank}, define the provider by using `ethers.JsonRpcProvider(providerURL, {object})` and setting the provider URL to Moonbeam:

```js
const ethers = require('ethers'); // Load Ethers library

const providerURL = 'INSERT_RPC_API_ENDPOINT'; // Insert your RPC URL here

// Define provider
const provider = new ethers.JsonRpcProvider(providerURL, {
    chainId: 1284,
    name: 'moonbeam'
});
```

Any Ethereum wallet should be able to generate a valid address for Moonbeam (for example, [MetaMask](https://metamask.io){target=\_blank}).

## Chain ID {: #chain-id }

Moonbeam chain ID is: `1284`, or `0x504` in hex.

## Telemetry {: #telemetry }

You can see current Moonbeam telemetry information by visiting [Polkadot's Telemetry dashboard](https://telemetry.polkadot.io/#list/0xfe58ea77779b7abda7da4ec526d14db9b1e9cd40a217c34892af80a9b332b76d){target=\_blank}.

## Tokens {: #tokens }

The tokens on Moonbeam are called Glimmer (GLMR). Check out the Moonbeam Foundation site for more information on the [Glimmer](https://moonbeam.foundation/glimmer-token-tokenomics){target=\_blank} token.

### Token Denominations {: #token-denominations }

The smallest unit of Glimmer (GMLR), similarly to Ethereum, is a Wei. It takes 10^18 Wei to make one Glimmer. The denominations are as follows:

|   Unit    |    Glimmer (GLMR)    |              Wei              |
|:---------:|:--------------------:|:-----------------------------:|
|    Wei    | 0.000000000000000001 |               1               |
|  Kilowei  |  0.000000000000001   |             1,000             |
|  Megawei  |    0.000000000001    |           1,000,000           |
|  Gigawei  |     0.000000001      |         1,000,000,000         |
| Microglmr |       0.000001       |       1,000,000,000,000       |
| Milliglmr |        0.001         |     1,000,000,000,000,000     |
|   GLMR    |          1           |   1,000,000,000,000,000,000   |
| Kiloglmr  |        1,000         | 1,000,000,000,000,000,000,000 |

## Proof of Stake {: #proof-of-stake }

The Moonriver network is a fully decentralized Delegated Proof of Stake network where users of the network can delegate collator candidates to produce blocks and earn rewards. It uses the [Nimbus framework](/learn/features/consensus/){target=\_blank} framework for parachain consensus. The number of candidates in the active set will be subject to governance. The active set will consist of the top candidates by stake, including delegations.

## Limitations {: #limitations }

Some [precompiles](https://www.evm.codes/precompiled){target=\_blank} are yet to be included. You can check a list of supported precompiles on the [Solidity Precompiles page](/builders/ethereum/precompiles/overview/){target=\_blank}. However, all built-in functions are available.
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/learn/platform/networks/moonriver/
--- BEGIN CONTENT ---
---
title: Moonriver Overview
description: An overview of the current configuration of the Moonbeam deployment on Kusama, Moonriver, and information on how to start building on it using Solidity.
categories: Basics
---

# Moonriver

## Goal {: #goal }

In June 2021, Moonriver was first launched as a parachain on the Kusama network. Moonriver is a sister network of Moonbeam, and provides an environment to test new code under real economic conditions. Developers now have access to start building on an incentivized canary network connected to Kusama.

In order to collect as much feedback as possible and provide fast issue resolution, you can check out the dedicated [Moonriver section on Discord](https://discord.com/invite/5TaUvbRvgM){target=\_blank}.

## Initial Configurations {: #initial-configurations }

Currently, Moonriver has the following configurations:

- Runs as a parachain connected to the Kusama relay chain
- Has an active set of {{ networks.moonriver.staking.max_candidates }} collators
- Has infrastructure providers that provide [API endpoints](/builders/get-started/endpoints/){target=\_blank} to connect to the network. Projects can also [run their own node](/node-operators/networks/run-a-node/){target=\_blank} to have access to their own private endpoints

![Moonriver Diagram](/images/learn/platform/networks/moonriver-diagram.webp)

Some important variables/configurations to note include:

=== "General"
    |       Variable        |                    Value                     |
    |:---------------------:|:--------------------------------------------:|
    |   Minimum gas price   | {{ networks.moonriver.min_gas_price }} Gwei* |
    |   Target block time   | {{ networks.moonriver.block_time }} seconds  |
    |    Block gas limit    |      {{ networks.moonriver.gas_block }}      |
    | Transaction gas limit |       {{ networks.moonriver.gas_tx }}        |

=== "Staking"
    |             Variable              |                                                   Value                                                   |
    |:---------------------------------:|:---------------------------------------------------------------------------------------------------------:|
    |     Minimum delegation stake      |                            {{ networks.moonriver.staking.min_del_stake }} MOVR                            |
    | Maximum delegators per candidates |                             {{ networks.moonriver.staking.max_del_per_can }}                              |
    |  Maximum delegations per account  |                             {{ networks.moonriver.staking.max_del_per_del }}                              |
    |               Round               | {{ networks.moonriver.staking.round_blocks }} blocks ({{ networks.moonriver.staking.round_hours }} hours) |
    |           Bond duration           |                delegation takes effect in the next round (funds are withdrawn immediately)                |
    |          Unbond duration          |                  {{ networks.moonriver.delegator_timings.del_bond_less.rounds }} rounds                   |

_*Read more about [token denominations](#token-denominations)_

!!! note
    As of runtime 3000, [asynchronous backing](https://wiki.polkadot.com/learn/learn-async-backing/#asynchronous-backing){target=\_blank} has been enabled on all Moonbeam networks. As a result, the target block time was reduced from 12 seconds to 6 seconds, which may break some timing-based assumptions.

    Additionally, the block and transaction gas limits increased by 4x on Moonriver.

## Network Endpoints {: #network-endpoints }

Moonriver has two types of endpoints available for users to connect to: one for HTTPS and one for WSS.

If you're looking for your own endpoints suitable for production use, you can check out the [Endpoint Providers](/builders/get-started/endpoints/#endpoint-providers){target=\_blank} section of our documentation. Otherwise, to get started quickly you can use one of the following public HTTPS or WSS endpoints:

=== "HTTPS"
      |  Provider   |                               RPC URL                               |   Limits    |
      |:-----------:|:-------------------------------------------------------------------:|:-----------:|
      |   Dwellir   |         <pre>```https://moonriver-rpc.dwellir.com```</pre>          | 20 req/sec  |
      | OnFinality  |     <pre>```https://moonriver.api.onfinality.io/public```</pre>     | 40 req/sec  |
      | UnitedBloc  |          <pre>```https://moonriver.unitedbloc.com```</pre>          | 32 req/sec  |
      | RadiumBlock | <pre>```https://moonriver.public.curie.radiumblock.co/http```</pre> | 200 req/sec |
      |    Grove    |        <pre>```https://moonriver.rpc.grove.city/v1/01fdb492```</pre>        | 5k req/day  |

=== "WSS"
    |  Provider   |                             RPC URL                             |   Limits    |
    |:-----------:|:---------------------------------------------------------------:|:-----------:|
    |   Dwellir   |        <pre>```wss://moonriver-rpc.dwellir.com```</pre>         | 20 req/sec  |
    | OnFinality  |  <pre>```wss://moonriver.api.onfinality.io/public-ws```</pre>   | 40 req/sec  |
    | UnitedBloc  |         <pre>```wss://moonriver.unitedbloc.com```</pre>         | 32 req/sec  |
    | RadiumBlock | <pre>```wss://moonriver.public.curie.radiumblock.co/ws```</pre> | 200 req/sec |

## Quick Start {: #quick-start }

Before getting started, make sure you've retrieved your own endpoint and API key from one of the custom [Endpoint Providers](/builders/get-started/endpoints/){target=\_blank}. Then for the [Web3.js library](/builders/ethereum/libraries/web3js/){target=\_blank}, you can create a local Web3 instance and set the provider to connect to Moonriver (both HTTP and WS are supported):

```js
const { Web3 } = require('web3'); // Load Web3 library
.
.
.
// Create local Web3 instance - set Moonriver as provider
const web3 = new Web3('INSERT_RPC_API_ENDPOINT'); // Insert your RPC URL here
```

For the [Ethers.js library](/builders/ethereum/libraries/ethersjs/){target=\_blank}, define the provider by using `ethers.JsonRpcProvider(providerURL, {object})` and setting the provider URL to Moonriver:

```js
const ethers = require('ethers'); // Load Ethers library

const providerURL = 'INSERT_RPC_API_ENDPOINT'; // Insert your RPC URL here

// Define provider
const provider = new ethers.JsonRpcProvider(providerURL, {
    chainId: 1285,
    name: 'moonriver'
});
```

Any Ethereum wallet should be able to generate a valid address for Moonbeam (for example, [MetaMask](https://metamask.io){target=\_blank}).

## Chain ID {: #chain-id }

Moonriver chain ID is: `1285`, or `0x505` in hex.

## Telemetry {: #telemetry }

You can see current Moonriver telemetry information by visiting [Polkadot's Telemetry dashboard](https://telemetry.polkadot.io/#list/0x401a1f9dca3da46f5c4091016c8a2f26dcea05865116b286f60f668207d1474b){target=\_blank}.

## Tokens {: #tokens }

The tokens on Moonriver will also be called Moonriver (MOVR). Check out the Moonbeam Foundation site for more information on the [Moonriver token](https://moonbeam.foundation/moonriver-token-tokenomics){target=\_blank}.

### Token Denominations {: #token-denominations }

The smallest unit of Moonriver, similarly to Ethereum, is a Wei. It takes 10^18 Wei to make one Moonriver. The denominations are as follows:

|      Unit      |   Moonriver (MOVR)   |              Wei              |
|:--------------:|:--------------------:|:-----------------------------:|
|      Wei       | 0.000000000000000001 |               1               |
|    Kilowei     |  0.000000000000001   |             1,000             |
|    Megawei     |    0.000000000001    |           1,000,000           |
|    Gigawei     |     0.000000001      |         1,000,000,000         |
| Micromoonriver |       0.000001       |       1,000,000,000,000       |
| Millimoonriver |        0.001         |     1,000,000,000,000,000     |
|   Moonriver    |          1           |   1,000,000,000,000,000,000   |
| Kilomoonriver  |        1,000         | 1,000,000,000,000,000,000,000 |

## Proof of Stake {: #proof-of-stake }

The Moonriver network is a fully decentralized Delegated Proof of Stake network where users of the network can delegate collator candidates to produce blocks and earn rewards. It uses the [Nimbus framework](/learn/features/consensus/){target=\_blank} framework for parachain consensus. The number of candidates in the active set will be subject to governance. The active set will consist of the top candidates by stake, including delegations.

## Limitations {: #limitations }

Some [precompiles](https://www.evm.codes/precompiled){target=\_blank} are yet to be included. You can check a list of supported precompiles on the [Canonical Contract page](/builders/ethereum/precompiles/){target=\_blank}. However, all built-in functions are available.
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/learn/platform/networks/overview/
--- BEGIN CONTENT ---
---
title: Overview of Networks
description: An overview of all of the MainNet and TestNet deployments of Moonbeam, an Ethereum-compatible smart contract parachain on Polkadot and Kusama.
categories: Basics
---

# Networks

There are multiple long-lived Moonbeam-based networks. Most significantly, there is the Moonbeam deployment on Polkadot and Kusama.

An overview of our parachain deployments is as follows:

 - Moonbeam: deployment on Polkadot (_December 2021_)
 - Moonriver: deployment on Kusama (_June 2021_)
 - Moonbase Alpha: Parachain TestNet for Moonbeam and Moonriver (_September 2020_)

This strategy allows us to de-risk software upgrades to Moonbeam on the Polkadot MainNet while still maintaining a reasonable update velocity.

## Moonbeam {: #moonbeam }

The Moonbeam production MainNet is a parachain on Polkadot and has been since December 17th, 2021. Moonbeam features the highest levels of security and availability. Code running on the MainNet has generally been vetted through one or more of the other networks listed above.

Moonbeam will offer parachain-related functionalities such as [XCMP](https://wiki.polkadot.com/learn/learn-xcm-transport/#xcmp-cross-chain-message-passing){target=\_blank} and [SPREE](https://wiki.polkadot.com/learn/learn-spree/){target=\_blank} as these features become available.

[Learn more about Moonbeam](/learn/platform/networks/moonbeam/).

## Moonriver {: #moonriver }

In advance of deploying to the Polkadot MainNet, [Moonbeam launched Moonriver](https://moonbeam.network/news/moonriver-won-a-parachain-slot-and-is-now-producing-blocks-on-the-kusama-network){target=\_blank} as a parachain on the Kusama network. The parachain functionality is live on Kusama.

Moonriver will offer parachain-related functionalities such as [XCMP](https://wiki.polkadot.com/learn/learn-xcm-transport/#xcmp-cross-chain-message-passing){target=\_blank} and [SPREE](https://wiki.polkadot.com/learn/learn-spree/){target=\_blank} as these features become available.

[Learn more about Moonriver](/learn/platform/networks/moonriver/).

## Moonbase Alpha {: #moonbase-alpha }

This TestNet is a network hosted by OpsLayer. It features a parachain/relay chain scheme. The goal is to allow developers to test the Ethereum compatibility features of Moonbeam in a shared parachain environment without needing to run their own nodes or network.

[Learn more about Moonbase Alpha](/learn/platform/networks/moonbase/).
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/learn/platform/technology/
--- BEGIN CONTENT ---
---
title: Technology & Architecture
description: Moonbeam is built using Rust and Polkadot's Substrate framework, enabling rich tools for implementation while allowing for specialization and optimization.
categories: Basics
---

# Technology & Architecture

## The Moonbeam Development Stack {: #the-moonbeam-development-stack }

Moonbeam is a smart contract blockchain platform built in the Rust programming language using the Substrate framework. Substrate, developed by [Parity Technologies](https://www.parity.io/){target=_blank} (the original founding contributors of Polkadot), is an open-source, modular SDK for creating blockchains. Substrate allows developers to customize their blockchains while still benefiting from features such as forkless upgrades, shared security (when connected as a parachain to Polkadot or Kusama), and an extensive library of pre-built runtime modules known as pallets.

### Rust Programming Language {: #rust-programming-language }

Rust is a good language for implementing a blockchain. It is highly performant like C and C++ but has built-in memory safety features enforced at compile time, preventing many common bugs and security issues arising from C and C++ implementations.

### Substrate Framework {: #substrate-framework }

Substrate provides a rich set of tools for creating blockchains, including a runtime execution environment that enables a generic state transition function and a pluggable set of modules (pallets) that implement various blockchain subsystems. By using Substrate, Moonbeam can leverage several key features offered to parachains launched on the Polkadot relay chain, including:

- **Shared security** — Polkadot's validators secure all parachains  
- **Cross-Consensus Messaging (XCM)** — native interoperability with other parachains  
- **Flexible upgrades** — Substrate’s forkless upgrade mechanism

Pallets are at the heart of Substrate-based chains, providing specific functionality in modular form. Examples include:

- **Balances pallet** — manages account balances and transfers  
- **Assets pallet** — handles the creation and management of on-chain fungible assets  
- **Consensus pallets** — provide mechanisms like AURA or BABE for block production  
- **Governance pallets** — facilitate on-chain governance  
- **Frontier pallets** — the Ethereum compatibility layer pioneered by the Moonbeam team  
- **Parachain Staking pallet** — enables Delegated Proof of Stake (DPoS)  

In addition to these pallets provided by Polkadot's Substrate, developers can [create their own pallets](https://docs.polkadot.com/develop/parachains/customize-parachain/make-custom-pallet/){target=_blank} to add custom functionality. Moonbeam leverages multiple existing Substrate frame pallets as well as several custom pallets for features such as cross-chain token integration, the [Orbiter Program](/node-operators/networks/collators/orbiter/){target=_blank}, and more. You can find the Moonbeam runtime (built using Substrate) and related pallets in the [Moonbeam GitHub repository](https://github.com/moonbeam-foundation/moonbeam){target=_blank}.

Moonbeam also uses the Cumulus library to facilitate integration with the Polkadot relay chain.

### Frontier: Substrate's Ethereum Compatibility Layer {: #frontier }

[Frontier](https://polkadot-evm.github.io/frontier){target=\_blank} serves as Substrate's Ethereum compatibility layer, facilitating the seamless operation of standard Ethereum DApps on Substrate-based chains without requiring modifications. This compatibility is achieved by integrating specialized Substrate pallets into the Substrate runtime. These pallets include:

- **EVM pallet** — responsible for executing EVM operations  
- **Ethereum pallet** — manages block data storage and offers RPC compatibility  
- **Base Fee pallet and Dynamic Fee pallet** — provide EIP-1559 functionality (not used in Moonbeam)

Moonbeam uses the EVM and Ethereum pallets to achieve full Ethereum compatibility. Instead of the Base Fee or Dynamic Fee pallets, Moonbeam has its own [dynamic fee mechanism](https://forum.moonbeam.network/t/proposal-dynamic-fee-mechanism-for-moonbeam-and-moonriver/241){target=\_blank} for base fee calculations. Basing the EVM implementation on the Substrate EVM Pallet provides a Rust-based EVM engine and support from the Parity engineering team.

## Blockchain Runtime {: #blockchain-runtime }

The core Moonbeam runtime specifies the state transition function and behavior of the Moonbeam blockchain. The runtime is built using [FRAME](/learn/platform/glossary/#substrate-frame-pallets){target=\_blank}, compiled to a [WebAssembly (Wasm)](/learn/platform/glossary/#webassemblywasm){target=\_blank} binary as well as a native binary. These compiled versions are executed in the Polkadot relay chain and Moonbeam node environments.

!!! note
    Substrate FRAME pallets are a collection of Rust-based modules that provide the functionality required when building a blockchain. WebAssembly is an open standard that defines a portable binary code format. Different programming languages, compilers, and browsers support it. Find more definitions [in our glossary](/learn/platform/glossary/){target=\_blank}.

Some of the key Substrate FRAME pallets used in the Moonbeam runtime include:

 - **Balances** — support for accounts, balances, and transfers  
 - **EVM** — a full Rust-based EVM implementation based on SputnikVM (part of Frontier)  
 - **Ethereum** — provides emulation of Ethereum block processing for the EVM (part of Frontier)  
 - **Executive** — orchestration layer that dispatches calls to other runtime modules  
 - **Identity** — support for setting on-chain identities for account addresses  
 - **System** — provides low-level types, storage, and blockchain functions  
 - **Treasury** — on-chain treasury that can be used to fund public goods such as a parachain slot  

In addition to these Substrate FRAME Pallets, Moonbeam implements custom pallets to achieve additional functionality, such as:

- **Parachain Staking** — enables a Delegated Proof of Stake (DPoS) system  
- **Moonbeam Orbiters** — supports the [Orbiter Program](/node-operators/networks/collators/orbiter/){target=\_blank}, which diversifies the collator pool  
- **XCM Transactor** — simplifies remote cross-chain calls via [Cross-Consensus Messaging (XCM)](/builders/interoperability/xcm/overview/){target=\_blank}  
- **Asset Manager** — registers XCM assets  

### Forkless Upgrades {: #forkless-upgrades }

One of the best things about developing on Polkadot with Substrate is the ability to introduce [forkless upgrades](https://docs.polkadot.com/develop/parachains/maintenance/runtime-upgrades/){target=_blank} to blockchain runtimes. In traditional blockchain architectures, substantial changes to the blockchain's rules often require a hard fork, which can be disruptive and contentious.  

Substrate takes a different approach by separating the blockchain's state (data) from its logic (rules). Logic lives in the runtime, which is itself stored on-chain. Whenever a new runtime is uploaded (via FRAME's `set_code` call) and approved through on-chain governance, all nodes automatically switch to the new runtime at a specified block. This process is seamless and does not split the network.  

Moonbeam regularly uses forkless upgrades to add features or fixes without requiring node operators to upgrade their software manually. You can keep track of and discuss upcoming Moonbeam upgrades on the [Moonbeam forum](https://forum.moonbeam.network){target=_blank}.

## Ethereum Compatibility Architecture {: #ethereum-compatibility-architecture }

Smart contracts on Moonbeam can be implemented using Solidity, Vyper, and any other language that compiles smart contracts to EVM-compatible bytecode. Moonbeam aims to provide a low-friction and secure environment for the development, testing, and execution of smart contracts while remaining compatible with the existing Ethereum developer toolchain.

The execution behavior and semantics of Moonbeam-based smart contracts strive to be as close as possible to Ethereum Layer 1. Moonbeam is a single shard, so cross-contract calls have the same synchronous execution semantics as on Ethereum Layer 1.

![Diagram showing the interactions made possible through Moonbeam's Ethereum compatibility](/images/learn/platform/technology-diagram.webp)

A high-level interaction flow is shown above. A Web3 RPC call from a DApp or existing Ethereum developer tool, such as Hardhat, is received by a Moonbeam node. The node has both Web3 RPCs and Substrate RPCs available, meaning you can use Ethereum or Substrate tools when interacting with a Moonbeam node. Associated Substrate runtime functions handle these RPC calls. The Substrate runtime checks signatures and handles any extrinsics. Smart contract calls are ultimately passed to the EVM to execute the state transitions.

### Ethereum Pallet {: #ethereum-pallet}

The [Ethereum pallet](https://polkadot-evm.github.io/frontier/overview){target=\_blank} is responsible for handling blocks and transaction receipts and statuses. It enables sending and receiving Ethereum-formatted data to and from Moonbeam by storing an Ethereum-style block and its associated transaction hashes in the Substrate runtime.

When a user submits a raw Ethereum transaction, it converts into a Substrate transaction through the Ethereum pallet's `transact` extrinsic—using the Ethereum pallet as the sole executor of the EVM pallet forces all of the data to be stored and transacted in an Ethereum-compatible way, which is how explorers like [Moonscan](/builders/get-started/explorers/#moonscan){target=\_blank} (built by Etherscan) can index block data.

### EVM Pallet {: #evm-pallet }

The [EVM pallet](https://polkadot-evm.github.io/frontier/overview){target=\_blank} implements a sandboxed virtual stack machine and uses the [SputnikVM](https://github.com/rust-ethereum/evm){target=\_blank} as the underlying EVM engine. It executes Ethereum smart contract bytecode in a manner similar to Ethereum mainnet, including gas metering and state changes.

Moonbeam uses unified accounts, meaning an H160 (Ethereum-style) address is also a valid Substrate address, so you only need a single account to interact with the Substrate runtime and the EVM. Once a balance exists in the EVM, smart contracts can be created and interacted with through standard Ethereum RPC calls.  

The EVM pallet should produce nearly identical execution results to Ethereum, such as gas cost and balance changes. However, there are some differences. Although the EVM pallet aims for near-identical behavior to Ethereum, some differences exist, for example, Moonbeam's [dynamic fee mechanism](https://forum.moonbeam.network/t/proposal-dynamic-fee-mechanism-for-moonbeam-and-moonriver/241){target=\_blank}. For more information, refer to the [Frontier EVM Pallet documentation](https://polkadot-evm.github.io/frontier/){target=\_blank}.

Moonbeam includes additional EVM precompiles for functionalities like cryptographic operations (ECRecover, SHA256, BLAKE2, BN128) and dispatching Substrate calls directly from within the EVM. Moonbeam uses the following EVM precompiles:

- **[pallet-evm-precompile-simple](https://polkadot-evm.github.io/frontier/rustdocs/pallet_evm_precompile_simple){target=\_blank}** - includes five basic precompiles: ECRecover, ECRecoverPublicKey, Identity, RIPEMD160, SHA256
- **[pallet-evm-precompile-blake2](https://polkadot-evm.github.io/frontier/rustdocs/pallet_evm_precompile_blake2/struct.Blake2F.html){target=\_blank}** - includes the BLAKE2 precompile
- **[pallet-evm-precompile-bn128](https://polkadot-evm.github.io/frontier/rustdocs/pallet_evm_precompile_bn128/index.html){target=\_blank}** - includes three BN128 precompiles: BN128Add, BN128Mul, and BN128Pairing
- **[pallet-evm-precompile-modexp](https://polkadot-evm.github.io/frontier/rustdocs/pallet_evm_precompile_modexp/struct.Modexp.html){target=\_blank}** - includes the modular exponentiation precompile
- **[pallet-evm-precompile-sha3fips](https://polkadot-evm.github.io/frontier/rustdocs/pallet_evm_precompile_sha3fips/struct.Sha3FIPS256.html){target=\_blank}** -includes the standard SHA3 precompile
- **[pallet-evm-precompile-dispatch](https://polkadot-evm.github.io/frontier/rustdocs/pallet_evm_precompile_dispatch/struct.Dispatch.html){target=\_blank}** - includes the dispatch precompile

You can find an overview of most of these precompiles on the [Ethereum MainNet Precompiled Contracts](/builders/ethereum/precompiles/utility/eth-mainnet/){target=\_blank} page.

## Native Interoperability {: #native-interoperability }

While Substrate allows developers to create blockchains, one of its most significant advantages is that it supports integration for native interoperability through relay chains like Polkadot and Kusama.  

A relay chain is a central chain that connects several blockchains, known as parachains. Each parachain is a distinct blockchain with its runtime and state, but all are connected to and secured by the relay chain. Once connected, parachains can communicate via [Cross-Consensus Messaging (XCM)](/builders/interoperability/xcm/overview/){target=_blank} to exchange information and conduct transactions in the same language, enabling a wide range of interoperable applications.  

Moonbeam and Moonriver have established XCM connections with a large number of parachains. You can see a visualization of all XCM integrations in this [XCM Channel Viewer](https://dotsama-channels.vercel.app/#/){target=_blank}.
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/learn/platform/tokens/
--- BEGIN CONTENT ---
---
title: Utility Tokens
description: Each of the Moonbeam networks require a utility token to function. Glimmer (GLMR) for Moonbeam on Polkadot and Moonriver (MOVR) for Moonriver on Kusama.
categories: Basics
---

# Introduction

As a decentralized smart contract platform, Moonbeam requires a utility token to function.  

This token is central to the design of Moonbeam and cannot be removed without sacrificing essential functionality. The Moonbeam token uses include:

 - Supporting the gas metering of smart contract execution
 - Incentivizing collators and powering the mechanics around the creation of a decentralized node infrastructure on which the platform can run
 - Facilitating the on-chain governance mechanism, including proposing referenda, electing council members, voting, etc.
 - Paying for network transaction fees

## Glimmer Token {: #glimmer-token }

In the Moonbeam deployment on Polkadot MainNet, this token is called Glimmer, as in, “that smart contract call will cost 0.3 Glimmer.”  The token symbol is GLMR.

You can find more information about Glimmer on the [Moonbeam Foundation](https://moonbeam.foundation/glimmer-token-tokenomics) website.

## Moonriver Token {: #moonriver-token }

In the Moonbeam deployment on Kusama (called Moonriver), this token is called Moonriver, as in, “that smart contract call will cost 0.003 Moonriver.”  The token symbol will be MOVR.

You can find more information about Moonriver on the [Moonbeam Foundation](https://moonbeam.foundation/moonriver-token-tokenomics) website.

## DEV Token {: #dev-token }

In the Moonbeam TestNet (called Moonbase Alpha), the token is called DEV. This token can be acquired freely, as its only purpose is to drive development and testing on Moonbase Alpha.

You can get DEV tokens for testing on Moonbase Alpha once every 24 hours from the [Moonbase Alpha Faucet](https://faucet.moonbeam.network){target=\_blank}.
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/learn/platform/vision/
--- BEGIN CONTENT ---
---
title: The Moonbeam Vision | Multi-chain
description: Moonbeam is designed to enable a multi-chain future, where users and assets can move freely across many specialized and heterogeneous chains.
categories: Basics
---

# Our Vision for Moonbeam

We believe in a multi-chain future with many chains, and many users and assets on those chains. In this context, we have created Moonbeam: a smart contract platform that provides an Ethereum-compatible environment for building decentralized applications. Moonbeam was designed to serve these new kinds of assets and users that exist across two or more chains.

Existing smart contract platforms are designed to service the users and assets on a single, specific chain.  By providing cross-chain smart contract functionality, Moonbeam allows developers to shift existing workloads and logic to Moonbeam and extend the reach of their applications to new users and assets on other chains.

Moonbeam's cross-chain integration is accomplished by becoming a [parachain](/learn/platform/glossary/#parachains) on the Polkadot network.  The [Polkadot network](/learn/platform/glossary/#polkadot) provides integration and connectivity between parachains that are connected to the network and to other non-Polkadot-based chains, such as Ethereum and Bitcoin, via bridges.

## Who Benefits From Moonbeam {: #who-benefits-from-moonbeam }

There are three main audiences who can most benefit from Moonbeam's cross-chain functionality:

### Existing Ethereum-Based Projects {: #existing-ethereum-based-projects }

Projects that are struggling with cost and scalability challenges on Ethereum can use Moonbeam to:

 - Move portions of their existing workloads and state off of Ethereum Layer 1 with minimal required changes.  
 - Implement a hybrid approach, where applications live on both Ethereum and Moonbeam simultaneously.  
 - Extend their reach to the Polkadot network and other chains that are connected to Polkadot.  

### Polkadot Ecosystem Projects {: #polkadot-ecosystem-projects }

Ecosystem projects that need smart contract functionality can use Moonbeam to:  

 - Augment their existing parachains and parathreads.  
 - Add new functionality that is needed but not included on the main [Polkadot relay chain](/learn/platform/glossary/#relay-chain). For example, they could create a place where teams can crowdfund their projects, implement lockdrops, and process other, more complex financial transactions than are provided by base [Substrate](/learn/platform/glossary/#substrate) functionality.  
 - Leverage the mature and extensive Ethereum development toolchain.  

### Developers of New DApps {: #developers-of-new-dapps }

Individuals and teams that want to try building on Polkadot can use Moonbeam to:

 - Leverage the specialized functionality from Polkadot parachains while reaching users and assets on other chains.  
 - Compose functionality from Polkadot parachains by using Moonbeam as a lightweight integration layer that aggregates network services before presenting them to end users. Implementing a composed service using pre-built integrations on a smart contract platform will be a lot faster and easier (in many cases) than building a full Substrate runtime and performing the integrations yourself in the runtime.  

## Key Features and Functionality {: #key-features-and-functionality }

Moonbeam achieves these goals with the following key features:  

 - **Decentralized and Permissionless** , providing a base requirement for censorship resistance and support for many existing and future DApp use cases.  
 - **Contains a Full EVM Implementation** , enabling Solidity-based smart contracts to be migrated with minimal change and with expected execution results.  
 - **Implements the Web3 RPC API** so that existing DApp front-ends can be migrated with minimal change required, and so existing Ethereum-based tools, such as Hardhat, Remix, and MetaMask, can be used without modification against Moonbeam.  
 - **Compatible with the Substrate Ecosystem Toolset** , including block explorers, front-end development libraries, and wallets, allowing developers and users to use the right tool for what they are trying to accomplish.  
 - **Native Cross-Chain Integration** via the Polkadot network and via token bridges, which allows for token movement, state visibility, and message passing with Ethereum and other chains.  
 - **On-Chain Governance** to allow stakeholders to quickly and forklessly evolve the base protocol according to developer and community needs.  

This unique combination of elements fills a strategic market gap, while allowing Moonbeam to address future developer needs as the Polkadot network grows over time.  Building your own chain with Substrate is powerful, but also comes with a number of additional responsibilities, such as learning and implementing the chain’s runtime in Rust, creating a token economy, and incentivizing a community of node operators.

For many developers and projects, an Ethereum-compatible smart contract approach will be much simpler and faster to implement.  And by building these smart contracts on Moonbeam, developers can still integrate with other chains and get value from Polkadot-based network effects.
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/learn/platform/why-polkadot/
--- BEGIN CONTENT ---
---
title: Why Polkadot
description: Moonbeam is built on the Substrate framework and connected to the Polkadot network, adding speed and security to the platform.
categories: Basics
---

# Why We're Building on Polkadot

After extensive research, we decided to build Moonbeam using the [Substrate development framework](/learn/platform/glossary/#substrate) and to deploy Moonbeam as a [parachain](/learn/platform/glossary/#parachains) on the [Polkadot network](/learn/platform/glossary/#polkadot).

## Substrate Blockchain Framework {: #substrate-blockchain-framework }

Substrate is a good technical fit for Moonbeam. By building on top of this framework, we can leverage the extensive functionality that Substrate includes out-of-the-box, rather than building it ourselves. This includes peer-to-peer networking, consensus mechanisms, governance functionality, an EVM implementation, and more.

Overall, using Substrate will dramatically reduce the time and implementation effort needed to implement Moonbeam. Substrate allows a great degree of customization, which is necessary in order to achieve our Ethereum compatibility goals. And, by using Rust, we benefit from both safety guarantees and performance gains.

## Polkadot Network and Ecosystem {: #polkadot-network-and-ecosystem }

The Polkadot network is also a good fit for Moonbeam. As a parachain on Polkadot, Moonbeam will be able to directly integrate with — and move tokens between — any other parachains and parathreads on the network.

We can also leverage any of the bridges that are independently built to connect non-Polkadot chains to Polkadot, including bridges to Ethereum. Polkadot’s interoperability model uniquely supports Moonbeam’s cross-chain integration goals and is a key enabling technology to support the Moonbeam vision.

But perhaps just as important as the technical criteria above, we are impressed with the people in the Polkadot ecosystem. This includes individuals at Parity, the Web3 Foundation, and other projects in the ecosystem. We have built many valuable relationships and find the people to be both extremely talented and the kind of people we want to be around.
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/builders/ethereum/dev-env/openzeppelin/overview/
--- BEGIN CONTENT ---
---
title: An Overview of OpenZeppelin on Moonbeam
description: Learn how to use OpenZeppelin products for creating and managing Solidity smart contracts on Moonbeam, thanks to its Ethereum compatibility features.
categories: Basics, Ethereum Toolkit
---

# OpenZeppelin

## Introduction {: #introduction } 

[OpenZeppelin](https://www.openzeppelin.com){target=\_blank} is well known in the Ethereum developer community as their set of audited smart contracts and libraries are a standard in the industry. For example, most of the tutorials that show developers how to deploy an ERC-20 token use OpenZeppelin contracts.

You can find more information about OpenZeppelin on their [documentation site](https://docs.openzeppelin.com){target=\_blank}.

As part of its Ethereum compatibility features, OpenZeppelin products can be seamlessly used on Moonbeam. This page will provide information on different OpenZeppelin solutions that you can test.

## OpenZeppelin on Moonbeam {: #openzeppelin-on-moonbeam } 

Currently, the following OpenZeppelin products/solutions work on the different networks available on Moonbeam:

|      **Product**      | **Moonbeam** | **Moonriver** | **Moonbase Alpha** | **Moonbase Dev Node** |
|:---------------------:|:------------:|:-------------:|:------------------:|:---------------------:|
| Contracts & libraries |      ✓       |       ✓       |         ✓          |           ✓           |
|   Contracts Wizard    |      ✓       |       ✓       |         ✓          |           ✓           |

You will find a corresponding tutorial for each product in the following links:

 - [**Contracts Wizard**](/builders/ethereum/dev-env/openzeppelin/contracts/#openzeppelin-contract-wizard) — where you'll find a guide on how to use OpenZeppelin web-based wizard to create different token contracts with different functionalities
 - [**Contracts & libraries**](/builders/ethereum/dev-env/openzeppelin/contracts/#deploying-openzeppelin-contracts-on-moonbeam) — where you'll find tutorials to deploy the most common token contracts using OpenZeppelin's templates: ERC-20, ERC-721 and ERC-1155
 
<div class="page-disclaimer">
  The information presented herein has been provided by third parties and is made available solely for general information purposes. Moonbeam does not endorse any project listed and described on the Moonbeam Doc Website (https://docs.moonbeam.network/). Moonbeam Foundation does not warrant the accuracy, completeness or usefulness of this information. Any reliance you place on such information is strictly at your own risk. Moonbeam Foundation disclaims all liability and responsibility arising from any reliance placed on this information by you or by anyone who may be informed of any of its contents. All statements and/or opinions expressed in these materials are solely the responsibility of the person or entity providing those materials and do not necessarily represent the opinion of Moonbeam Foundation. The information should not be construed as professional or financial advice of any kind. Advice from a suitably qualified professional should always be sought in relation to any particular matter or circumstance. The information herein may link to or integrate with other websites operated or content provided by third parties, and such other websites may link to this website. Moonbeam Foundation has no control over any such other websites or their content and will have no liability arising out of or related to such websites or their content. The existence of any such link does not constitute an endorsement of such websites, the content of the websites, or the operators of the websites. These links are being provided to you only as a convenience and you release and hold Moonbeam Foundation harmless from any and all liability arising from your use of this information or the information provided by any third-party website or service.
</div>
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/builders/ethereum/precompiles/overview/
--- BEGIN CONTENT ---
---
title: Solidity Precompiles
description: An overview of the available Solidity precompiles on Moonbeam. Precompiles enable you to interact with Substrate features using the Ethereum API.
categories: Reference, Basics
---

# Overview of the Precompiled Contracts on Moonbeam

## Overview {: #introduction }

On Moonbeam, a precompiled contract is native Substrate code that has an Ethereum-style address and can be called using the Ethereum API, like any other smart contract. The precompiles allow you to call the Substrate runtime directly which is not normally accessible from the Ethereum side of Moonbeam.

The Substrate code responsible for implementing precompiles can be found in the [EVM pallet](/learn/platform/technology/#evm-pallet){target=\_blank}. The EVM pallet includes the [standard precompiles found on Ethereum and some additional precompiles that are not specific to Ethereum](https://github.com/polkadot-evm/frontier/tree/master/frame/evm/precompile){target=\_blank}. It also provides the ability to create and execute custom precompiles through the generic [`Precompiles` trait](https://polkadot-evm.github.io/frontier/rustdocs/pallet_evm/trait.Precompile.html){target=\_blank}. There are several custom Moonbeam-specific precompiles that have been created, all of which can be found in the [Moonbeam codebase](https://github.com/moonbeam-foundation/moonbeam/tree/master/precompiles){target=\_blank}. It is important to highlight that the precompiles from this list with the `CallableByContract` check are not callable inside the contract constructor.

The Ethereum precompiled contracts contain complex functionality that is computationally intensive, such as hashing and encryption. The custom precompiled contracts on Moonbeam provide access to Substrate-based functionality such as staking, governance, XCM-related functions, and more.

The Moonbeam-specific precompiles can be interacted with through familiar and easy-to-use Solidity interfaces using the Ethereum API, which are ultimately used to interact with the underlying Substrate interface. This flow is depicted in the following diagram:

![Precompiled Contracts Diagram](/images/builders/ethereum/precompiles/overview/overview-1.webp)

!!! note
    There can be some unintended consequences when using the precompiled contracts on Moonbeam. Please refer to the [Security Considerations](/learn/core-concepts/security/){target=\_blank} page for more information.

## Precompiled Contract Addresses {: #precompiled-contract-addresses }

The precompiled contracts are categorized by address and based on the origin network. If you were to convert the precompiled addresses to decimal format, and break them into categories by numeric value, the categories are as follows:

- **0-1023** - [Ethereum MainNet precompiles](#ethereum-mainnet-precompiles)
- **1024-2047** - precompiles that are [not in Ethereum and not Moonbeam specific](#non-moonbeam-specific-nor-ethereum-precomiles)
- **2048-4095** - [Moonbeam specific precompiles](#moonbeam-specific-precompiles)

### Ethereum MainNet Precompiles {: #ethereum-mainnet-precompiles }

=== "Moonbeam"
    |                                                          Contract                                                           |                  Address                   |
    |:---------------------------------------------------------------------------------------------------------------------------:|:------------------------------------------:|
    |      [ECRECOVER](/builders/ethereum/precompiles/utility/eth-mainnet/#verify-signatures-with-ecrecover){target=\_blank}      | 0x0000000000000000000000000000000000000001 |
    |              [SHA256](/builders/ethereum/precompiles/utility/eth-mainnet/#hashing-with-sha256){target=\_blank}              | 0x0000000000000000000000000000000000000002 |
    |          [RIPEMD160](/builders/ethereum/precompiles/utility/eth-mainnet/#hashing-with-ripemd-160){target=\_blank}           | 0x0000000000000000000000000000000000000003 |
    |            [Identity](/builders/ethereum/precompiles/utility/eth-mainnet/#the-identity-function){target=\_blank}            | 0x0000000000000000000000000000000000000004 |
    |    [Modular Exponentiation](/builders/ethereum/precompiles/utility/eth-mainnet/#modular-exponentiation){target=\_blank}     | 0x0000000000000000000000000000000000000005 |
    |                  [BN128Add](/builders/ethereum/precompiles/utility/eth-mainnet/#bn128add){target=\_blank}                   | 0x0000000000000000000000000000000000000006 |
    |                  [BN128Mul](/builders/ethereum/precompiles/utility/eth-mainnet/#bn128mul){target=\_blank}                   | 0x0000000000000000000000000000000000000007 |
    |              [BN128Pairing](/builders/ethereum/precompiles/utility/eth-mainnet/#bn128pairing){target=\_blank}               | 0x0000000000000000000000000000000000000008 |
    | [Blake2](https://polkadot-evm.github.io/frontier/rustdocs/pallet_evm_precompile_blake2/struct.Blake2F.html){target=\_blank} | 0x0000000000000000000000000000000000000009 |
    |                 [P256Verify](https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7212.md){target=\_blank}                 | 0x0000000000000000000000000000000000000100 |

=== "Moonriver"
    |                                                          Contract                                                           |                  Address                   |
    |:---------------------------------------------------------------------------------------------------------------------------:|:------------------------------------------:|
    |      [ECRECOVER](/builders/ethereum/precompiles/utility/eth-mainnet/#verify-signatures-with-ecrecover){target=\_blank}      | 0x0000000000000000000000000000000000000001 |
    |              [SHA256](/builders/ethereum/precompiles/utility/eth-mainnet/#hashing-with-sha256){target=\_blank}              | 0x0000000000000000000000000000000000000002 |
    |          [RIPEMD160](/builders/ethereum/precompiles/utility/eth-mainnet/#hashing-with-ripemd-160){target=\_blank}           | 0x0000000000000000000000000000000000000003 |
    |            [Identity](/builders/ethereum/precompiles/utility/eth-mainnet/#the-identity-function){target=\_blank}            | 0x0000000000000000000000000000000000000004 |
    |    [Modular Exponentiation](/builders/ethereum/precompiles/utility/eth-mainnet/#modular-exponentiation){target=\_blank}     | 0x0000000000000000000000000000000000000005 |
    |                  [BN128Add](/builders/ethereum/precompiles/utility/eth-mainnet/#bn128add){target=\_blank}                   | 0x0000000000000000000000000000000000000006 |
    |                  [BN128Mul](/builders/ethereum/precompiles/utility/eth-mainnet/#bn128mul){target=\_blank}                   | 0x0000000000000000000000000000000000000007 |
    |              [BN128Pairing](/builders/ethereum/precompiles/utility/eth-mainnet/#bn128pairing){target=\_blank}               | 0x0000000000000000000000000000000000000008 |
    | [Blake2](https://polkadot-evm.github.io/frontier/rustdocs/pallet_evm_precompile_blake2/struct.Blake2F.html){target=\_blank} | 0x0000000000000000000000000000000000000009 |
    |                 [P256Verify](https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7212.md){target=\_blank}                 | 0x0000000000000000000000000000000000000100 |

=== "Moonbase Alpha"
    |                                                          Contract                                                           |                  Address                   |
    |:---------------------------------------------------------------------------------------------------------------------------:|:------------------------------------------:|
    |      [ECRECOVER](/builders/ethereum/precompiles/utility/eth-mainnet/#verify-signatures-with-ecrecover){target=\_blank}      | 0x0000000000000000000000000000000000000001 |
    |              [SHA256](/builders/ethereum/precompiles/utility/eth-mainnet/#hashing-with-sha256){target=\_blank}              | 0x0000000000000000000000000000000000000002 |
    |          [RIPEMD160](/builders/ethereum/precompiles/utility/eth-mainnet/#hashing-with-ripemd-160){target=\_blank}           | 0x0000000000000000000000000000000000000003 |
    |            [Identity](/builders/ethereum/precompiles/utility/eth-mainnet/#the-identity-function){target=\_blank}            | 0x0000000000000000000000000000000000000004 |
    |    [Modular Exponentiation](/builders/ethereum/precompiles/utility/eth-mainnet/#modular-exponentiation){target=\_blank}     | 0x0000000000000000000000000000000000000005 |
    |                  [BN128Add](/builders/ethereum/precompiles/utility/eth-mainnet/#bn128add){target=\_blank}                   | 0x0000000000000000000000000000000000000006 |
    |                  [BN128Mul](/builders/ethereum/precompiles/utility/eth-mainnet/#bn128mul){target=\_blank}                   | 0x0000000000000000000000000000000000000007 |
    |              [BN128Pairing](/builders/ethereum/precompiles/utility/eth-mainnet/#bn128pairing){target=\_blank}               | 0x0000000000000000000000000000000000000008 |
    | [Blake2](https://polkadot-evm.github.io/frontier/rustdocs/pallet_evm_precompile_blake2/struct.Blake2F.html){target=\_blank} | 0x0000000000000000000000000000000000000009 |
    |                 [P256Verify](https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7212.md){target=\_blank}                 | 0x0000000000000000000000000000000000000100 |

### Non-Moonbeam Specific nor Ethereum Precompiles {: #non-moonbeam-specific-nor-ethereum-precompiles }

=== "Moonbeam"
    |                                                                      Contract                                                                      |                  Address                   |
    |:--------------------------------------------------------------------------------------------------------------------------------------------------:|:------------------------------------------:|
    |                    [SHA3FIPS256](/builders/ethereum/precompiles/utility/eth-mainnet/#hashing-with-sha3fips256){target=\_blank}                     | 0x0000000000000000000000000000000000000400 |
    |                                                                 Dispatch [Removed]                                                                 | 0x0000000000000000000000000000000000000401 |
    | [ECRecoverPublicKey](https://polkadot-evm.github.io/frontier/rustdocs/pallet_evm_precompile_simple/struct.ECRecoverPublicKey.html){target=\_blank} | 0x0000000000000000000000000000000000000402 |

=== "Moonriver"
    |                                                                      Contract                                                                      |                  Address                   |
    |:--------------------------------------------------------------------------------------------------------------------------------------------------:|:------------------------------------------:|
    |                    [SHA3FIPS256](/builders/ethereum/precompiles/utility/eth-mainnet/#hashing-with-sha3fips256){target=\_blank}                     | 0x0000000000000000000000000000000000000400 |
    |                                                                 Dispatch [Removed]                                                                 | 0x0000000000000000000000000000000000000401 |
    | [ECRecoverPublicKey](https://polkadot-evm.github.io/frontier/rustdocs/pallet_evm_precompile_simple/struct.ECRecoverPublicKey.html){target=\_blank} | 0x0000000000000000000000000000000000000402 |

=== "Moonbase Alpha"
    |                                                                           Contract                                                                            |                  Address                   |
    |:-------------------------------------------------------------------------------------------------------------------------------------------------------------:|:------------------------------------------:|
    |                          [SHA3FIPS256](/builders/ethereum/precompiles/utility/eth-mainnet/#hashing-with-sha3fips256){target=\_blank}                          | 0x0000000000000000000000000000000000000400 |
    |                                                                      Dispatch [Removed]                                                                       | 0x0000000000000000000000000000000000000401 |
    |      [ECRecoverPublicKey](https://polkadot-evm.github.io/frontier/rustdocs/pallet_evm_precompile_simple/struct.ECRecoverPublicKey.html){target=\_blank}       | 0x0000000000000000000000000000000000000402 |

### Moonbeam Specific Precompiles {: #moonbeam-specific-precompiles }

=== "Moonbeam"
    |                                                                                        Contract                                                                                        |                               Address                               |
    |:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|:-------------------------------------------------------------------:|
    |                  [Parachain Staking](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/parachain-staking/StakingInterface.sol){target=\_blank}                  |              {{networks.moonbeam.precompiles.staking}}              |
    |                 [Crowdloan Rewards](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/crowdloan-rewards/CrowdloanInterface.sol){target=\_blank}                 |             {{networks.moonbeam.precompiles.crowdloan}}             |
    |                         [ERC-20 Interface](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/balances-erc20/ERC20.sol){target=\_blank}                          |               {{networks.moonbeam.precompiles.erc20}}               |
    |                                                                      Democracy [Removed]                                                                      |             {{networks.moonbeam.precompiles.democracy}}             |
    |                                [X-Tokens](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xtokens/Xtokens.sol){target=\_blank}                                |              {{networks.moonbeam.precompiles.xtokens}}              |
    |                        [Relay Encoder](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/relay-encoder/RelayEncoder.sol){target=\_blank}                        |           {{networks.moonbeam.precompiles.relay_encoder}}           |
    |                [XCM Transactor V1](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-transactor/src/v1/XcmTransactorV1.sol){target=\_blank}                 |         {{networks.moonbeam.precompiles.xcm_transactor_v1}}         |
    |                  [Author Mapping](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/author-mapping/AuthorMappingInterface.sol){target=\_blank}                  |          {{networks.moonbeam.precompiles.author_mapping}}           |
    |                                   [Batch](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/batch/Batch.sol){target=\_blank}                                    |               {{networks.moonbeam.precompiles.batch}}               |
    |                            [Randomness](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/randomness/Randomness.sol){target=\_blank}                            |            {{networks.moonbeam.precompiles.randomness}}             |
    |                           [Call Permit](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/call-permit/CallPermit.sol){target=\_blank}                           |            {{networks.moonbeam.precompiles.call_permit}}            |
    |                                   [Proxy](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/proxy/Proxy.sol){target=\_blank}                                    |               {{networks.moonbeam.precompiles.proxy}}               |
    |                            [XCM Utilities](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-utils/XcmUtils.sol){target=\_blank}                            |             {{networks.moonbeam.precompiles.xcm_utils}}             |
    |                [XCM Transactor V2](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-transactor/src/v2/XcmTransactorV2.sol){target=\_blank}                 |         {{networks.moonbeam.precompiles.xcm_transactor_v2}}         |
    |                   [Council Collective [Removed]](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}                   |        {{networks.moonbeam.precompiles.collective_council}}         |
    |             [Technical Committee Collective [Removed]](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}             |     {{networks.moonbeam.precompiles.collective_tech_committee}}     |
    |                   [Treasury Council Collective](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}                    |        {{networks.moonbeam.precompiles.collective_treasury}}        |
    |                             [Referenda](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/referenda/Referenda.sol){target=\_blank}                              |             {{networks.moonbeam.precompiles.referenda}}             |
    |                  [Conviction Voting](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/conviction-voting/ConvictionVoting.sol){target=\_blank}                  |         {{networks.moonbeam.precompiles.conviction_voting}}         |
    |                               [Preimage](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/preimage/Preimage.sol){target=\_blank}                               |             {{networks.moonbeam.precompiles.preimage}}              |
    |                      [OpenGov Tech Committee](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}                      | {{networks.moonbeam.precompiles.collective_opengov_tech_committee}} |
    |               [Precompile Registry](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/precompile-registry/PrecompileRegistry.sol){target=\_blank}               |             {{networks.moonbeam.precompiles.registry}}              |
    |                                      [GMP](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/gmp/Gmp.sol){target=\_blank}                                       |                {{networks.moonbeam.precompiles.gmp}}                |
    |                [XCM Transactor V3](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-transactor/src/v3/XcmTransactorV3.sol){target=\_blank}                 |         {{networks.moonbeam.precompiles.xcm_transactor_v3}}         |
    |                               [XCM interface](https://github.com/Moonsong-Labs/moonkit/blob/main/precompiles/pallet-xcm/XcmInterface.sol){target=\_blank}                               |             {{networks.moonbeam.precompiles.xcm_interface}}              |
    |                               [Identity](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/identity/Identity.sol){target=\_blank}                               |             {{networks.moonbeam.precompiles.identity}}              |
    

=== "Moonriver"
    |                                                                           Contract                                                                            |                               Address                                |
    |:-------------------------------------------------------------------------------------------------------------------------------------------------------------:|:--------------------------------------------------------------------:|
    |      [Parachain Staking](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/parachain-staking/StakingInterface.sol){target=\_blank}      |              {{networks.moonriver.precompiles.staking}}              |
    |     [Crowdloan Rewards](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/crowdloan-rewards/CrowdloanInterface.sol){target=\_blank}     |             {{networks.moonriver.precompiles.crowdloan}}             |
    |             [ERC-20 Interface](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/balances-erc20/ERC20.sol){target=\_blank}              |               {{networks.moonriver.precompiles.erc20}}               |
    |                                                                     Democracy [Disabled]                                                                      |             {{networks.moonriver.precompiles.democracy}}             |
    |                    [X-Tokens](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xtokens/Xtokens.sol){target=\_blank}                    |              {{networks.moonriver.precompiles.xtokens}}              |
    |            [Relay Encoder](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/relay-encoder/RelayEncoder.sol){target=\_blank}            |           {{networks.moonriver.precompiles.relay_encoder}}           |
    |    [XCM Transactor V1](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-transactor/src/v1/XcmTransactorV1.sol){target=\_blank}     |         {{networks.moonriver.precompiles.xcm_transactor_v1}}         |
    |      [Author Mapping](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/author-mapping/AuthorMappingInterface.sol){target=\_blank}      |          {{networks.moonriver.precompiles.author_mapping}}           |
    |                       [Batch](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/batch/Batch.sol){target=\_blank}                        |               {{networks.moonriver.precompiles.batch}}               |
    |                [Randomness](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/randomness/Randomness.sol){target=\_blank}                |            {{networks.moonriver.precompiles.randomness}}             |
    |               [Call Permit](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/call-permit/CallPermit.sol){target=\_blank}               |            {{networks.moonriver.precompiles.call_permit}}            |
    |                       [Proxy](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/proxy/Proxy.sol){target=\_blank}                        |               {{networks.moonriver.precompiles.proxy}}               |
    |                [XCM Utilities](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-utils/XcmUtils.sol){target=\_blank}                |             {{networks.moonriver.precompiles.xcm_utils}}             |
    |    [XCM Transactor V2](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-transactor/src/v2/XcmTransactorV2.sol){target=\_blank}     |         {{networks.moonriver.precompiles.xcm_transactor_v2}}         |
    |       [Council Collective [Removed]](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}       |        {{networks.moonriver.precompiles.collective_council}}         |
    | [Technical Committee Collective [Removed]](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank} |     {{networks.moonriver.precompiles.collective_tech_committee}}     |
    |       [Treasury Council Collective](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}        |        {{networks.moonriver.precompiles.collective_treasury}}        |
    |                 [Referenda](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/referenda/Referenda.sol){target=\_blank}                  |             {{networks.moonriver.precompiles.referenda}}             |
    |      [Conviction Voting](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/conviction-voting/ConvictionVoting.sol){target=\_blank}      |         {{networks.moonriver.precompiles.conviction_voting}}         |
    |                   [Preimage](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/preimage/Preimage.sol){target=\_blank}                   |             {{networks.moonriver.precompiles.preimage}}              |
    |          [OpenGov Tech Committee](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}          | {{networks.moonriver.precompiles.collective_opengov_tech_committee}} |
    |   [Precompile Registry](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/precompile-registry/PrecompileRegistry.sol){target=\_blank}   |             {{networks.moonriver.precompiles.registry}}              |
    |                          [GMP](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/gmp/Gmp.sol){target=\_blank}                           |                {{networks.moonriver.precompiles.gmp}}                |
    |    [XCM Transactor V3](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-transactor/src/v3/XcmTransactorV3.sol){target=\_blank}     |         {{networks.moonriver.precompiles.xcm_transactor_v3}}         |
    |                               [XCM interface](https://github.com/Moonsong-Labs/moonkit/blob/main/precompiles/pallet-xcm/XcmInterface.sol){target=\_blank}                               |             {{networks.moonriver.precompiles.xcm_interface}}              |
    |                   [Identity](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/identity/Identity.sol){target=\_blank}                   |             {{networks.moonriver.precompiles.identity}}              |

=== "Moonbase Alpha"
    |                                                                            Contract                                                                            |                               Address                               |
    |:--------------------------------------------------------------------------------------------------------------------------------------------------------------:|:-------------------------------------------------------------------:|
    |      [Parachain Staking](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/parachain-staking/StakingInterface.sol){target=\_blank}      |              {{networks.moonbase.precompiles.staking}}              |
    |     [Crowdloan Rewards](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/crowdloan-rewards/CrowdloanInterface.sol){target=\_blank}     |             {{networks.moonbase.precompiles.crowdloan}}             |
    |             [ERC-20 Interface](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/balances-erc20/ERC20.sol){target=\_blank}              |               {{networks.moonbase.precompiles.erc20}}               |
    |                                                                      Democracy [Removed]                                                                       |             {{networks.moonbase.precompiles.democracy}}             |
    |                    [X-Tokens](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xtokens/Xtokens.sol){target=\_blank}                    |              {{networks.moonbase.precompiles.xtokens}}              |
    |            [Relay Encoder](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/relay-encoder/RelayEncoder.sol){target=\_blank}            |           {{networks.moonbase.precompiles.relay_encoder}}           |
    |    [XCM Transactor V1](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-transactor/src/v1/XcmTransactorV1.sol){target=\_blank}     |         {{networks.moonbase.precompiles.xcm_transactor_v1}}         |
    |      [Author Mapping](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/author-mapping/AuthorMappingInterface.sol){target=\_blank}      |          {{networks.moonbase.precompiles.author_mapping}}           |
    |                       [Batch](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/batch/Batch.sol){target=\_blank}                        |               {{networks.moonbase.precompiles.batch}}               |
    |                [Randomness](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/randomness/Randomness.sol){target=\_blank}                |            {{networks.moonbase.precompiles.randomness}}             |
    |               [Call Permit](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/call-permit/CallPermit.sol){target=\_blank}               |            {{networks.moonbase.precompiles.call_permit}}            |
    |                       [Proxy](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/proxy/Proxy.sol){target=\_blank}                        |               {{networks.moonbase.precompiles.proxy}}               |
    |                [XCM Utilities](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-utils/XcmUtils.sol){target=\_blank}                |             {{networks.moonbase.precompiles.xcm_utils}}             |
    |    [XCM Transactor V2](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-transactor/src/v2/XcmTransactorV2.sol){target=\_blank}     |         {{networks.moonbase.precompiles.xcm_transactor_v2}}         |
    |       [Council Collective [Removed]](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}       |        {{networks.moonbase.precompiles.collective_council}}         |
    | [Technical Committee Collective [Removed]](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank} |     {{networks.moonbase.precompiles.collective_tech_committee}}     |
    |       [Treasury Council Collective](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}        |        {{networks.moonbase.precompiles.collective_treasury}}        |
    |                 [Referenda](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/referenda/Referenda.sol){target=\_blank}                  |             {{networks.moonbase.precompiles.referenda}}             |
    |      [Conviction Voting](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/conviction-voting/ConvictionVoting.sol){target=\_blank}      |         {{networks.moonbase.precompiles.conviction_voting}}         |
    |                   [Preimage](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/preimage/Preimage.sol){target=\_blank}                   |             {{networks.moonbase.precompiles.preimage}}              |
    |          [OpenGov Tech Committee](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}          | {{networks.moonbase.precompiles.collective_opengov_tech_committee}} |
    |   [Precompile Registry](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/precompile-registry/PrecompileRegistry.sol){target=\_blank}   |             {{networks.moonbase.precompiles.registry}}              |
    |                          [GMP](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/gmp/Gmp.sol){target=\_blank}                           |                {{networks.moonbase.precompiles.gmp}}                |
    |    [XCM Transactor V3](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-transactor/src/v3/XcmTransactorV3.sol){target=\_blank}     |         {{networks.moonbase.precompiles.xcm_transactor_v3}}         |
    |                               [XCM Interface](https://github.com/Moonsong-Labs/moonkit/blob/main/precompiles/pallet-xcm/XcmInterface.sol){target=\_blank}                               |             {{networks.moonbeam.precompiles.xcm_interface}}              |
    |                   [Identity](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/identity/Identity.sol){target=\_blank}                   |             {{networks.moonbase.precompiles.identity}}              |
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/builders/get-started/create-account/
--- BEGIN CONTENT ---
---
title: Create an Account
description: To begin developing on Moonbeam, you must create an account. This guide will provide you with the information needed to create one to use on Moonbeam.
categories: Basics
---

# Create an Account

## Introduction {: #introduction }

To get started developing on Moonbeam, developers must create an account. The most prevalent approach involves leveraging a wallet application, which facilitates generating and managing cryptographic keys essential for interacting with Moonbeam.

Moonbeam uses H160 Ethereum-style accounts and ECDSA keys, represented in 20-byte addresses. If you already have an Ethereum account and its private key or mnemonic, you can use your account on Moonbeam.

This guide will walk you through the step-by-step process of creating an account on Moonbeam. Whether you're new to blockchain technology or an experienced Ethereum user, this guide will provide all the information you need to get started.

!!! note
    This guide does not pertain to a local Moonbeam development node. If you are using a development node, you don't need to worry about creating an account, as the node comes with ten pre-funded accounts for testing purposes. Please refer to the [Getting Started with a Local Moonbeam Development Node](/builders/get-started/networks/moonbeam-dev/){target=\_blank} guide for more information.

## Choose a Wallet {: #choose-a-wallet }

A wallet is a software or hardware tool that allows you to securely store, manage, and interact with your digital assets, such as tokens or coins. Wallets store your private keys, which are essential for authorizing transactions on the network.

You can review a list of wallets on the [Moonbeam DApp Directory](https://apps.moonbeam.network/moonbeam/app-dir?cat=wallets){target=\_blank}.

![View list of wallets on the Moonbeam DApp](/images/builders/get-started/create-account/create-account-1.webp)

The list of wallets on the dApp is not exhaustive and may only cover some of the available options. You should be able to use any Ethereum-compatible wallet to generate an address and its associated private key.

You can also check out any of the wallets in the [Connect to Moonbeam](/tokens/connect/){target=\_blank} section of the docs.

## Use Your Wallet to Create an Account {: #use-your-wallet-to-create-an-account }

After you've selected a wallet and downloaded it, you'll most likely be prompted to create a new account or import an existing one the first time you open it. You'll want to create a new account.

Depending on the wallet, when creating an account, you may be prompted to backup and restore a seed phrase, also referred to as a mnemonic or recovery phrase. This phrase is a sequence of generated words that serve as a backup mechanism for private keys. They typically consist of 12 to 24 words randomly selected from a predefined list. Seed phrases are used to derive private keys deterministically, meaning that the same sequence of words will always generate the same set of private keys. They are crucial for recovering access to a cryptocurrency wallet in case of loss or device failure. **Make sure you save the phrase in a safe place; if you lose access to this phrase, you'll lose access to any funds you hold in your account.**

After saving your seed phrase, you can start developing on Moonbeam. Many wallets offer the option to export the private key linked to your account. By doing so, you can utilize your private key instead of the seed phrase during development. However, taking adequate precautions to securely store your private key or seed phrase while developing is essential.

And that's it! Before sending your first transaction on a Moonbeam-based network, ensure you have the necessary [network configurations for your chosen network](/builders/get-started/networks/){target=\_blank} and an [RPC endpoint](/builders/get-started/endpoints/){target=\_blank} for the network. Once you have these items, you'll be able to follow along with tutorials like the [How to use Ethers.js](/builders/ethereum/libraries/ethersjs/){target=\_blank} or the [How to use Web3.js](/builders/ethereum/libraries/web3js/){target=\_blank} to send a transaction.
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/builders/get-started/explorers/
--- BEGIN CONTENT ---
---
title: Block Explorers
description: An overview of the currently available block explorers that may be used to navigate the Substrate and Ethereum layers of Moonbeam.
categories: Basics
---

# Block Explorers

## Introduction {: #introduction }

Block explorers can be thought of as search engines for the blockchain. They allow users to search for information such as balances, contracts, and transactions. More advanced block explorers even offer indexing capabilities, which enable them to provide a complete set of information, such as ERC-20 tokens in the network. They might even offer API services to access it via external services.

Moonbeam provides two different kinds of explorers: ones to query the Ethereum API and others  dedicated to the Substrate API. All EVM-based transactions are accessible via the Ethereum API, while the Substrate API can be relied upon for Substrate-native functions such as governance and staking. The Substrate API also includes information about the EVM-based transactions, but only limited information is shown.

## Quick Links {: #quick-links }

=== "Moonbeam"
    | Block Explorer |   Type    |                                                                  URL                                                                  |
    |:--------------:|:---------:|:-------------------------------------------------------------------------------------------------------------------------------------:|
    |    Moonscan    |    EVM    |                            [https://moonbeam.moonscan.io/](https://moonbeam.moonscan.io){target=\_blank}                             |
    |   Expedition   |    EVM    |  [https://moonbeam-explorer.netlify.app/?network=Moonbeam](https://moonbeam-explorer.netlify.app/?network=Moonbeam){target=\_blank}  |
    |    Subscan     | Substrate |                             [https://moonbeam.subscan.io/](https://moonbeam.subscan.io){target=\_blank}                              |
    |  Polkadot.js   | Substrate | [https://polkadot.js.org/apps/#/explorer](https://polkadot.js.org/apps/?rpc=wss://wss.api.moonbeam.network#/explorer){target=\_blank} |

=== "Moonriver"
    | Block Explorer |   Type    |                                                                       URL                                                                       |
    |:--------------:|:---------:|:-----------------------------------------------------------------------------------------------------------------------------------------------:|
    |    Moonscan    |    EVM    |                                [https://moonriver.moonscan.io/](https://moonriver.moonscan.io){target=\_blank}                                 |
    |   Expedition   |    EVM    |      [https://moonbeam-explorer.netlify.app/?network=Moonriver](https://moonbeam-explorer.netlify.app/?network=Moonriver){target=\_blank}      |
    |    Subscan     | Substrate |                                 [https://moonriver.subscan.io/](https://moonriver.subscan.io){target=\_blank}                                  |
    |  Polkadot.js   | Substrate | [https://polkadot.js.org/apps/#/explorer](https://polkadot.js.org/apps/?rpc=wss://wss.api.moonrvier.moonbeam.network#/explorer){target=\_blank} |

=== "Moonbase Alpha"
    | Block Explorer |   Type    |                                                                      URL                                                                       |
    |:--------------:|:---------:|:----------------------------------------------------------------------------------------------------------------------------------------------:|
    |    Moonscan    |    EVM    |                                 [https://moonbase.moonscan.io/](https://moonbase.moonscan.io){target=\_blank}                                 |
    |   Expedition   |    EVM    | [https://moonbeam-explorer.netlify.app/?network=MoonbaseAlpha](https://moonbeam-explorer.netlify.app/?network=MoonbaseAlpha){target=\_blank}  |
    |    Subscan     | Substrate |                                  [https://moonbase.subscan.io/](https://moonbase.subscan.io){target=\_blank}                                  |
    |  Polkadot.js   | Substrate | [https://polkadot.js.org/apps/#/explorer](https://polkadot.js.org/apps/?rpc=wss://wss.api.moonbase.moonbeam.network#/explorer){target=\_blank} |

=== "Moonbeam Dev Node"
    | Block Explorer |   Type    |                                                                        URL                                                                        |
    |:--------------:|:---------:|:-------------------------------------------------------------------------------------------------------------------------------------------------:|
    |   Expedition   |    EVM    | [https://moonbeam-explorer.netlify.app/?network=MoonbeamDevNode](https://moonbeam-explorer.netlify.app/?network=MoonbeamDevNode){target=\_blank} |
    |  Polkadot.js   | Substrate |     [https://polkadot.js.org/apps/#/explorer](https://polkadot.js.org/apps/?rpc=wss://ws%3A%2F%2F127.0.0.1%3A9944#/explorer){target=\_blank}      |

## Ethereum API {: #ethereum-api }

### Moonscan {: #Moonscan }

[Moonscan](https://moonscan.io){target=\_blank} is the primary Ethereum API block explorer for Moonbeam-based networks. Built by the Etherscan team, Moonscan provides a powerful, intuitive, and feature-rich experience. In addition to its comprehensive transaction and block data, Moonscan provides a number of [statistics and charts](https://moonbeam.moonscan.io/charts){target=\_blank}, such as average gas price, daily transactions, and block size charts.

Other Moonscan features include:

 - [Collator leaderboard](https://moonbeam.moonscan.io/collators){target=\_blank} ranking collators by performance
 - [Contract source code verification](/builders/ethereum/verify-contracts/block-explorers/){target=\_blank}, accessible both via a web interface and an API
 - Ability to read and write state data of verified smart contracts
 - [Token approvals](https://moonscan.io/tokenapprovalchecker){target=\_blank} where you can view and revoke any of your prior token approvals
 - [Adding token information](/builders/get-started/token-profile/){target=\_blank} and creating a profile for ERC-20s, ERC-721s, and ERC-1155s deployed to Moonbeam-based networks. The profile can include links to your project, social media, price data, and other information pertaining to your token

![Moonbeam Moonscan](/images/builders/get-started/explorers/explorers-1.webp)

### Expedition {: #expedition }

A Moonbeam-themed version of the [Expedition](https://github.com/xops/expedition){target=\_blank} explorer can be found in [this link](https://moonbeam-explorer.netlify.app){target=\_blank}. It is a basic JSON-RPC based explorer.

By default, the explorer is connected to Moonbeam. However, you can switch to Moonriver or Moonbase Alpha, or connect it to a local dev node by following the next steps:

 1. Click on the network text, where you'll be able to select between all different networks, including a **Moonbeam Development Node** running on `{{ networks.development.rpc_url }}`
 2. In the case you want to connect to a specific RPC URL, select **Add Custom Chain** and enter the URL. For example, `http://localhost:9937`

![Expedition Explorer](/images/builders/get-started/explorers/explorers-2.webp)

## Substrate API {: #substrate-api }

### Subscan {: #subscan }

[Subscan](https://moonbeam.subscan.io){target=\_blank} is the primary Substrate API block explorer for Moonbeam-based networks. Subscan is capable of parsing standard or custom modules. For example, this is useful to display information regarding the Staking, Governance, and EVM pallets (or modules). The code is all open-source and can be found in the [Subscan Essentials GitHub repo](https://github.com/subscan-explorer/subscan-essentials){target=\_blank}.

![Subscan Moonbeam](/images/builders/get-started/explorers/explorers-3.webp)

### Polkadot.js {: #polkadotjs }

While not a full-featured block explorer, Polkadot.js Apps is a convenient option especially for users running local development nodes to view events and query transaction hashes. Polkadot.js Apps uses the WebSocket endpoint to interact with the Network. You can easily connect to [Moonbeam](https://polkadot.js.org/apps/?rpc=wss://wss.api.moonbeam.network#/explorer){target=\_blank}, [Moonriver](https://polkadot.js.org/apps/?rpc=wss://wss.api.moonriver.moonbase.moonbeam.network#/explorer){target=\_blank}, or [Moonbase Alpha](https://polkadot.js.org/apps/?rpc=wss://wss.api.moonbase.moonbeam.network#/explorer){target=\_blank}.

![Polkadot.js Moonbeam](/images/builders/get-started/explorers/explorers-4.webp)

To connect it to a Moonbeam development node, you can follow the steps in the [Connecting Polkadot.js Apps to a Local Moonbeam Node](/builders/get-started/networks/moonbeam-dev/#connecting-polkadot-js-apps-to-a-local-moonbeam-node){target=\_blank} section of the [Getting Started with a Moonbeam Development Node](/builders/get-started/networks/moonbeam-dev/){target=\_blank} guide. The default port for this is `9944`.

![Polkadot.js Local Node](/images/builders/get-started/explorers/explorers-5.webp)
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/builders/get-started/networks/moonbase/
--- BEGIN CONTENT ---
---
title: Moonbase Alpha Get Started Guide
description: The Moonbeam TestNet, named Moonbase Alpha, is the easiest way to get started with a Polkadot environment. Follow this tutorial to connect to the TestNet.
categories: Basics
---

# Get Started with Moonbase Alpha

## Network Endpoints {: #network-endpoints }

Moonbase Alpha has two types of endpoints available for users to connect to: one for HTTPS and one for WSS.

If you're looking for your own endpoints suitable for production use, you can check out the [Endpoint Providers](/builders/get-started/endpoints/#endpoint-providers){target=\_blank} section of our documentation. Otherwise, to get started quickly you can use one of the following public HTTPS or WSS endpoints.

=== "HTTPS"
    |      Provider       |                              RPC URL                               |   Limits    |
    |:-------------------:|:------------------------------------------------------------------:|:-----------:|
    |       Dwellir       |         <pre>```https://moonbase-rpc.dwellir.com```</pre>          | 20 req/sec  |
    |     OnFinality      |  <pre>```https://moonbeam-alpha.api.onfinality.io/public```</pre>  | 40 req/sec  |
    | Moonbeam Foundation |     <pre>```https://rpc.api.moonbase.moonbeam.network```</pre>     | 25 req/sec  |
    |     UnitedBloc      |          <pre>```https://moonbase.unitedbloc.com```</pre>          | 32 req/sec  |
    |     RadiumBlock     | <pre>```https://moonbase.public.curie.radiumblock.co/http```</pre> | 200 req/sec |

=== "WSS"
    |      Provider       |                              RPC URL                              |   Limits    |
    |:-------------------:|:-----------------------------------------------------------------:|:-----------:|
    |       Dwellir       |          <pre>```wss://moonbase-rpc.dwellir.com```</pre>          | 20 req/sec  |
    |     OnFinality      | <pre>```wss://moonbeam-alpha.api.onfinality.io/public-ws```</pre> | 40 req/sec  |
    | Moonbeam Foundation |     <pre>```wss://wss.api.moonbase.moonbeam.network```</pre>      | 25 req/sec  |
    |     UnitedBloc      |          <pre>```wss://moonbase.unitedbloc.com```</pre>           | 32 req/sec  |
    |     RadiumBlock     |  <pre>```wss://moonbase.public.curie.radiumblock.co/ws```</pre>   | 200 req/sec |


#### Relay Chain {: #relay-chain }

To connect to the Moonbase Alpha relay chain, you can use the following WS Endpoint:

| Provider |                          RPC URL                           |
|:--------:|:----------------------------------------------------------:|
| OpsLayer | <pre>```wss://relay.api.moonbase.moonbeam.network```</pre> |

## Quick Start {: #quick-start }

For the [Web3.js library](/builders/ethereum/libraries/web3js/){target=\_blank}, you can create a local Web3 instance and set the provider to connect to Moonbase Alpha (both HTTP and WS are supported):

```js
const { Web3 } = require('web3'); // Load Web3 library
.
.
.
// Create local Web3 instance - set Moonbase Alpha as provider
const web3 = new Web3('https://rpc.api.moonbase.moonbeam.network'); 
```

For the [Ethers.js library](/builders/ethereum/libraries/ethersjs/){target=\_blank}, define the provider by using `ethers.JsonRpcProvider(providerURL, {object})` and setting the provider URL to Moonbase Alpha:

```js
const ethers = require('ethers'); // Load Ethers library

const providerURL = 'https://rpc.api.moonbase.moonbeam.network';
// Define provider
const provider = new ethers.JsonRpcProvider(providerURL, {
    chainId: 1287,
    name: 'moonbase-alphanet'
});
```

Any Ethereum wallet should be able to generate a valid address for Moonbeam (for example, [MetaMask](https://metamask.io){target=\_blank}).

## Chain ID {: #chain-id }

Moonbase Alpha TestNet chain ID is: `1287`, which is `0x507` in hex.

## Block Explorers

For Moonbase Alpha, you can use any of the following block explorers:

 - **Ethereum API (Etherscan Equivalent)** — [Moonscan](https://moonbase.moonscan.io){target=\_blank}
 - **Ethereum API JSON-RPC based** — [Moonbeam Basic Explorer](https://moonbeam-explorer.netlify.app/?network=MoonbaseAlpha){target=\_blank}
 - **Substrate API** — [Subscan](https://moonbase.subscan.io){target=\_blank} or [Polkadot.js Apps](https://polkadot.js.org/apps/?rpc=wss://wss.api.moonbase.moonbeam.network#/explorer){target=\_blank}

For more information on each of the available block explorers, please head to the [Block Explorers](/builders/get-started/explorers/){target=\_blank} section of the documentation.

## Connect MetaMask

If you already have MetaMask installed, you can easily connect MetaMask to the Moonbase Alpha TestNet:

<div class="button-wrapper">
    <a href="#" class="md-button connectMetaMask" value="moonbase">Connect MetaMask</a>
</div>

!!! note
    MetaMask will popup asking for permission to add Moonbase Alpha as a custom network. Once you approve permissions, MetaMask will switch your current network to Moonbase Alpha.

If you do not have MetaMask installed, or would like to follow a tutorial to get started, please check out the [Interacting with Moonbeam using MetaMask](/tokens/connect/metamask/){target=\_blank} guide.

## Configuration {: #configuration }

Please note the following gas configuration parameters. These values are subject to change in future runtime upgrades.

|       Variable        |                   Value                    |
|:---------------------:|:------------------------------------------:|
|   Minimum gas price   | {{ networks.moonbase.min_gas_price }} Gwei |
|   Target block time   | {{ networks.moonbase.block_time }} seconds |
|    Block gas limit    |     {{ networks.moonbase.gas_block }}      |
| Transaction gas limit |       {{ networks.moonbase.gas_tx }}       |

## Get Tokens {: #get-tokens }

To start building on Moonbase Alpha, you can get DEV tokens from the Moonbase Alpha Faucet. For specific amounts, you can always reach out directly to us via our community channels.

To request DEV tokens from the faucet, you can enter your address on the [Moonbase Alpha Faucet](https://faucet.moonbeam.network){target=\_blank} website. The faucet dispenses {{ networks.moonbase.website_faucet_amount }} every 24 hours.

![Moonbase Alpha Faucet Website.](/images/builders/get-started/networks/moonbase/moonbase-1.webp)

!!! note
    Moonbase Alpha DEV tokens have no value. Please don't spam the faucet with unnecessary requests.

## Demo DApps {: #Demo-DApps }

There are a variety of DApps deployed to Moonbase Alpha enabling you to experiment with various apps and integrations. You can also acquire a variety of test tokens through the [Moonbase ERC20 Minter](https://moonbase-minterc20.netlify.app){target=\_blank} or [Moonbeam Uniswap](https://moonbeam-swap.netlify.app/#/swap){target=\_blank} DApps. For example, [Moonbeam Uniswap](https://moonbeam-swap.netlify.app/#/swap){target=\_blank} can help you acquire cross-chain assets such as xcUNIT or xcKarura for testing XCM related functions. In the below table, you'll find each sample DApp, its associated URL, and GitHub repository.

### Quick Links {: #quick-links }

|                                            DApp                                            |    Description     |                                                                            Repository                                                                            |
|:------------------------------------------------------------------------------------------:|:------------------:|:----------------------------------------------------------------------------------------------------------------------------------------------------------------:|
|     [Moonbase ERC-20 Minter](https://moonbase-minterc20.netlify.app){target=\_blank}      |   ERC-20 Faucet    |                 [https://github.com/papermoonio/moonbase-mintableERC20](https://github.com/papermoonio/moonbase-mintableERC20){target=\_blank}                  |
|        [Moonbeam Uniswap](https://moonbeam-swap.netlify.app/#/swap){target=\_blank}        |  Uniswap V2 Fork   |                       [https://github.com/papermoonio/moonbeam-uniswap](https://github.com/papermoonio/moonbeam-uniswap){target=\_blank}                        |

|        [MoonLotto Lottery](https://moonbase-moonlotto.netlify.app){target=\_blank}        |   TheGraph Demo    | [Interface](https://github.com/papermoonio/moonlotto-interface){target=\_blank}, [Subgraph](https://github.com/papermoonio/moonlotto-subgraph){target=\_blank} |
| [Moonbeam WalletConnect](https://moonbeam-walletconnect-demo.netlify.app){target=\_blank} | WalletConnect Demo |            [https://github.com/papermoonio/moonbeam-walletconnect-demo](https://github.com/papermoonio/moonbeam-walletconnect-demo){target=\_blank}             |
|              [MoonGas](https://moonbeam-gasinfo.netlify.app){target=\_blank}              | Gas Price Tracker  |                    [https://github.com/albertov19/moonbeam-gas-station](https://github.com/albertov19/moonbeam-gas-station){target=\_blank}                     |

!!! note
    These DApps are intended for demonstration purposes only and may be incomplete or unsuitable for production deployments.

### Moonbase ERC20 Minter {: #moonbase-erc20-minter }

The [Moonbase ERC-20 Minter](https://moonbase-minterc20.netlify.app){target=\_blank} enables you to mint a variety of ERC-20 test tokens corresponding to the 8 planets of the solar system, and Pluto. To mint tokens, first press **Connect MetaMask** in the upper right hand corner. Then scroll to the **Mint Tokens** section and the choose desired ERC-20 contract. Press **Submit Tx** and confirm the transaction in MetaMask. Each mint will grant you 100 tokens, and you can mint tokens for each contract once per hour.

![ERC20 Minter](/images/builders/get-started/networks/moonbase/moonbase-2.webp)

### Moonbeam Uniswap {: #moonbeam-uniswap }

[Moonbeam Uniswap](https://moonbeam-swap.netlify.app/#/swap){target=\_blank} is a fork of [Uniswap-V2](https://blog.uniswap.org/uniswap-v2){target=\_blank} deployed to Moonbase Alpha. Notably, Moonbeam Uniswap allows developers to easily make a swap to acquire [cross-chain assets](/builders/interoperability/xcm/xc20/){target=\_blank} such as xcKarura or xcUNIT for XCM testing purposes. To perform your first swap, take the following steps:

1. Press **Select a token**
2. Connect your MetaMask wallet and ensure you're on the Moonbase Alpha network
3. Press **Choose a List** on the prompt
4. Select **Moon Menu**
5. Search for or select your desired asset from the list then continue with the swap

![Moonbeam Swap](/images/builders/get-started/networks/moonbase/moonbase-3.webp)

!!! note
    If you see only a partial list of assets under **Moon Menu**, your browser may have cached an older version of **Moon Menu**. Clearing the cache and re-adding **Moon Menu** will resolve this.



### MoonLotto Lottery {: #moonlotto-lottery }

[MoonLotto](https://moonbase-moonlotto.netlify.app){target=\_blank} is a simple lottery game on Moonbase Alpha derived from [The Graph's Example Subgraph](https://github.com/graphprotocol/example-subgraph){target=\_blank}.  Purchasing a ticket costs 1 DEV and a winner is chosen each half hour if there are at least 10 participants. [MoonLotto.sol](https://github.com/papermoonio/moonlotto-subgraph/blob/main/contracts/MoonLotto.sol){target=\_blank} holds the contract logic for the lottery. To participate, take the following steps:

1. Connect your MetaMask wallet and ensure you're on the Moonbase Alpha network
2. Enter the address of the recipient of lotto ticket or check **I want to buy a ticket for my address**
3. Press **Submit on MetaMask** and confirm the transaction in MetaMask

![MoonLotto Lottery](/images/builders/get-started/networks/moonbase/moonbase-5.webp)

### Moonbeam WalletConnect {: #moonbeam-walletconnect }

[Moonbeam WalletConnect](https://moonbeam-walletconnect-demo.netlify.app){target=\_blank} shows how easy it is to integrate [WalletConnect](https://walletconnect.com){target=\_blank} into your DApps and unlock support for a great variety of crypto wallets. Be sure to check out the [demo app repository](https://github.com/papermoonio/moonbeam-walletconnect-demo){target=\_blank} to see exactly how the WalletConnect integration works. To get started, you can take the following steps:

1. Press **Connect Wallet**
2. Scan the QR code using a [wallet compatible with WalletConnect](https://walletguide.walletconnect.network/){target=\_blank}

![Moonbeam WalletConnect](/images/builders/get-started/networks/moonbase/moonbase-6.webp)

### MoonGas {: #moongas }

[MoonGas](https://moonbeam-gasinfo.netlify.app){target=\_blank} is a convenient dashboard for viewing the minimum, maximum, and average gas price of transactions in the prior block across all Moonbeam networks. Note, these statistics can fluctuate widely by block and occasionally include outlier values. You can check out the [repository for MoonGas](https://github.com/albertov19/moonbeam-gas-station){target=\_blank}.

You'll notice that the minimum gas price for Moonbeam is {{ networks.moonbeam.min_gas_price }} Gwei, while the minimum for Moonriver is {{ networks.moonriver.min_gas_price }} Gwei and Moonbase Alpha is {{ networks.moonbase.min_gas_price }} Gwei. This difference stems from the [100 to 1 re-denomination of GLMR](https://moonbeam.network/news/moonbeam-foundation-announces-liquidity-programs-a-new-token-event-and-glmr-redenomination){target=\_blank} and thus the {{ networks.moonbeam.min_gas_price }} Gwei minimum on Moonbeam corresponds to a {{ networks.moonriver.min_gas_price }} Gwei minimum on Moonriver and a {{ networks.moonbase.min_gas_price }} Gwei on Moonbase.

![MoonGas](/images/builders/get-started/networks/moonbase/moonbase-7.webp)
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/builders/get-started/networks/moonbeam-dev/
--- BEGIN CONTENT ---
---
title: Run a Moonbeam Development Node
description: Follow this tutorial to learn how to spin up your first Moonbeam development node, how to configure it for development purposes, and connect to it.
categories: Basics
---

# Getting Started with a Local Moonbeam Development Node

<style>.embed-container { position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%; } .embed-container iframe, .embed-container object, .embed-container embed { position: absolute; top: 0; left: 0; width: 100%; height: 100%; }</style><div class='embed-container'><iframe src='https://www.youtube.com/embed/-bRooBW2g0o' frameborder='0' allowfullscreen></iframe></div>
<style>.caption { font-family: Open Sans, sans-serif; font-size: 0.9em; color: rgba(170, 170, 170, 1); font-style: italic; letter-spacing: 0px; position: relative;}</style>

## Introduction {: #introduction }

A Moonbeam development node is your own personal development environment for building and testing applications on Moonbeam. For Ethereum developers, it is comparable to the Hardhat Network. It enables you to get started quickly and easily without the overhead of a relay chain. You can spin up your node with the `--sealing` option to author blocks instantly, manually, or at a custom interval after transactions are received. By default, a block will be created when a transaction is received, which is similar to the default behavior of Hardhat Network's instamine feature.

If you follow this guide to the end, you will have a Moonbeam development node running in your local environment with 10 prefunded [accounts](#pre-funded-development-accounts).

!!! note
    This tutorial was created using the {{ networks.development.build_tag }} tag of [Moonbase Alpha](https://github.com/moonbeam-foundation/moonbeam/releases/tag/{{ networks.development.build_tag }}){target=\_blank}. The Moonbeam platform and the [Frontier](https://github.com/polkadot-evm/frontier){target=\_blank} components it relies on for Substrate-based Ethereum compatibility are still under very active development.
    The examples in this guide assume you have a MacOS or Ubuntu 22.04-based environment and will need to be adapted accordingly for Windows.

## Spin Up a Moonbeam Development Node {: #spin-up-a-node }

There are two ways to get started running a Moonbeam node. You can use [Docker to run a pre-built binary](#getting-started-with-docker) or you can [compile the binary locally](#getting-started-with-the-binary-file) and set up a development node yourself. Using Docker is a quick and convenient way to get started, as you won't have to install Substrate and all the dependencies, and you can skip the node-building process as well. It does require you to [install Docker](https://docs.docker.com/get-started/get-docker/){target=\_blank}. On the other hand, if you decide you want to go through the process of building your development node, it could take roughly 30 minutes or longer to complete, depending on your hardware.

### Spin Up a Node with Docker {: #getting-started-with-docker }

Using Docker enables you to spin up a node in a matter of seconds. Once you have Docker installed, you can take the following steps to spin up your node:

1. Execute the following command to download the latest Moonbeam image:

    ```bash
    docker pull moonbeamfoundation/moonbeam:{{ networks.development.build_tag }}
    ```

    The tail end of the console log should look like this:

    <div id="termynal" data-termynal>
  <span data-ty="input"><span class="file-path"></span>docker pull moonbeamfoundation/moonbeam:v0.43.0</span>
  <br>
  <span data-ty>v0.43.0: Pulling from moonbeamfoundation/moonbeam
    <br> b0a0cf830b12: Pull complete
    <br> fbff687640dd: Pull complete
    <br> 58ea427410e2: Pull complete
    <br> 811ba55e6e61: Pull complete
    <br> 4316d5f1b914: Pull complete
    <br> 128693ce218e: Pull complete
    <br> a3ac90b88463: Pull complete
    <br> Digest: sha256:86421aca2381265cd2e5283cb98705e24be0bc92a73937363f79d9d6e0d62088
    <br> Status: Downloaded newer image for moonbeamfoundation/moonbeam:v0.43.0
    <br> docker.io/moonbeamfoundation/moonbeam:v0.43.0
  </span>
</div>

2. Spin up a Moonbeam development node by running the following Docker command, which will launch the node in instant seal mode for local testing so that blocks are authored instantly as transactions are received:

    === "Ubuntu"

        ```bash
        docker run --rm --name {{ networks.development.container_name }} --network host \
        moonbeamfoundation/moonbeam:{{ networks.development.build_tag }} \
        --dev --rpc-external
        ```

    === "MacOS"

        ```bash
        docker run --rm --name {{ networks.development.container_name }} -p 9944:9944 \
        moonbeamfoundation/moonbeam:{{ networks.development.build_tag }} \
        --dev --rpc-external
        ```

    === "Windows"

        ```bash
        docker run --rm --name {{ networks.development.container_name }} -p 9944:9944 ^
        moonbeamfoundation/moonbeam:{{ networks.development.build_tag }} ^
        --dev --rpc-external
        ```

!!! note
    On MacOS with silicon chips, Docker images may perform poorly. To improve performance, try [spinning up a Node with a Binary File](#getting-started-with-the-binary-file).

If successful, you should see an output showing an idle state waiting for blocks to be authored:

<div id="termynal" data-termynal>
  <span data-ty="input"><span class="file-path"></span>docker run --rm --name moonbeam_development --network host \
    <br> moonbeamfoundation/moonbeam:v0.45.0 \
    <br> --dev --rpc-external
  </span>
  <br>
  <span data-ty>CLI parameter `--execution` has no effect anymore and will be removed in the future!
    <br> 2025-07-10 09:04:26 Moonbeam Parachain Collator
    <br> 2025-07-10 09:04:26 ✌️  version 0.46.0-d7df89e7161
    <br> 2025-07-10 09:04:26 ❤️  by PureStake, 2019-2025
    <br> 2025-07-10 09:04:26 📋 Chain specification: Moonbase Development Testnet
    <br> 2025-07-10 09:04:26 🏷  Node name: black-and-white-sticks-9174
    <br> 2025-07-10 09:04:26 👤 Role: AUTHORITY
    <br> 2025-07-10 09:04:26 💾 Database: RocksDb at /tmp/substrateO3YeRz/chains/moonbase_dev/db/full
    <br> 2025-07-10 09:04:26 🔨 Initializing Genesis block/state (state: 0xf7c4…5c0f, header-hash: 0x42bd…3b5b)
    <br> 2025-07-10 09:04:26 Using default protocol ID "sup" because none is configured in the chain specs
    <br> 2025-07-10 09:04:26 🏷  Local node identity is: 12D3KooWLcpczme2JeBEfLqmjqkzYVKTGKhhGmwSzHjRXGBVhDX7
    <br> 2025-07-10 09:04:26 💻 Operating system: linux
    <br> 2025-07-10 09:04:26 💻 CPU architecture: x86_64
    <br> 2025-07-10 09:04:26 💻 Target environment: gnu
    <br> 2025-07-10 09:04:26 💻 CPU: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
    <br> 2025-07-10 09:04:26 💻 CPU cores: 12
    <br> 2025-07-10 09:04:26 💻 Memory: 7946MB
    <br> 2025-07-10 09:04:26 💻 Kernel: 6.4.16-linuxkit
    <br> 2025-07-10 09:04:26 💻 Linux distribution: Debian GNU/Linux 12 (bookworm)
    <br> 2025-07-10 09:04:26 💻 Virtual machine: yes
    <br> 2025-07-10 09:04:26 📦 Highest known block at #0
    <br> 2025-07-10 09:04:26 Running JSON-RPC server: addr=0.0.0.0:9944, allowed origins=["*"]
    <br> 2025-07-10 09:04:26 🏁 CPU score: 1.14 GiBs
    <br> 2025-07-10 09:04:26 〽️ Prometheus exporter started at 127.0.0.1:9615
    <br> 2025-07-10 09:04:26 🏁 Memory score: 10.41 GiBs
    <br> 2025-07-10 09:04:26 🏁 Disk score (seq. writes): 987.96 MiBs
    <br> 2025-07-10 09:04:26 🏁 Disk score (rand. writes): 363.65 MiBs
    <br> 2025-07-10 09:04:26 Development Service Ready
    <br> 2025-07-10 09:04:26 💤 Idle (0 peers), best: #0 (0xa083…f354), finalized #0 (0xa083…f354), ⬇ 0 ⬆ 0
    <br> 2025-07-10 09:04:26 💤 Idle (0 peers), best: #0 (0xa083…f354), finalized #0 (0xa083…f354), ⬇ 0 ⬆ 0
  </span>
</div>

For more information on some of the flags and options used in the example, check out [Flags](#node-flags) and [Options](#node-options). If you want to see a complete list of all of the flags, options, and subcommands, open the help menu by running:

```bash
docker run --rm --name {{ networks.development.container_name }} \
moonbeamfoundation/moonbeam \
--help
```

To continue with the tutorial, the next section is not necessary, as you've already spun up a node with Docker. You can skip ahead to the [Configure your Moonbeam Development Node](#configure-moonbeam-dev-node) section.

### Spin Up a Node with a Binary File {: #getting-started-with-the-binary-file }

As an alternative to using Docker, you can spin up a node using the Moonbeam binary. This method is more time-consuming. Depending on your hardware, the process could take around 30 minutes to complete.

!!! note
    If you know what you are doing, you can directly download the precompiled binaries attached to each release on the [Moonbeam release page](https://github.com/moonbeam-foundation/moonbeam/releases){target=\_blank}. These will not work in all systems. For example, the binaries only work with x86-64 Linux with specific versions of dependencies. The safest way to ensure compatibility is to compile the binary on the system where it will be run.

To build the binary file, you can take the following steps:

1. Clone a specific tag of the Moonbeam repo, which you can find on the [Moonbeam GitHub repository](https://github.com/moonbeam-foundation/moonbeam){target=\_blank}:

    ```bash
    git clone -b {{ networks.development.build_tag }} https://github.com/moonbeam-foundation/moonbeam
    cd moonbeam
    ```

    !!! note
        Spaces in the installation file path will cause a compilation error.

2. If you already have Rust installed, you can skip the next two steps. Otherwise, install Rust and its prerequisites [via Rust's recommended method](https://www.rust-lang.org/tools/install){target=\_blank} by executing:

    ```bash
    curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
    ```

3. Update your PATH environment variable by running:

    ```bash
    source $HOME/.cargo/env
    ```

4. Build the development node by running:

    !!! note
        If you are using Ubuntu 20.04 or 22.04, then you will need to make sure these additional dependencies have been installed before building the binary:

        ```bash
        apt install clang protobuf-compiler libprotobuf-dev pkg-config libssl-dev -y 
        ```

        For MacOS users, these dependencies can be installed via Homebrew:

        ```bash
        brew install llvm
        brew install protobuf
        ```

    ```bash
    cargo build --release
    ```

    Here is what the tail end of the build output should look like:

    <div id="termynal" data-termynal>
  <span data-ty>Compiling try-runtime-cli v0.9.0 (https://github.com/paritytech/substrate?branch=rococo-v1#401c24e8)
    <br> Compiling frame-benchmarking-cli v3.0.0 (https://github.com/paritytech/substrate?branch=rococo-v1#401c24e8)
    <br> Compiling cumulus-client-cli v0.1.0 (https://github.com/paritytech/cumulus?branch=rococo-v1#9d89ed65)
    <br> Compiling moonbeam-rpc-txpool v0.6.0 (/home/purestake/moonbeam/client/rpc/txpool)
    <br> Compiling moonbeam-rpc-debug v0.1.0 (/home/purestake/moonbeam/client/rpc/debug)
    <br> Compiling moonbeam-rpc-trace v0.6.0 (/home/purestake/moonbeam/client/rpc/trace)
    <br> Compiling cumulus-client-network v0.1.0 (https://github.com/paritytech/cumulus?branch=rococo-v1#9d89ed65)
    <br> Compiling cumulus-client-consensus-relay-chain v0.1.0 (https://github.com/paritytech/cumulus?branch=rococo-v1#9d89ed65)
    <br> Compiling polkadot-test-service v0.8.29 (https://github.com/paritytech/polkadot?branch=rococo-v1#b64741e6)
    <br> Compiling cumulus-client-collator v0.1.0 (https://github.com/paritytech/cumulus?branch=rococo-v1#9d89ed65)
    <br> Compiling cumulus-client-service v0.1.0 (https://github.com/paritytech/cumulus?branch=rococo-v1#9d89ed65)
    <br> Finished release [optimized] target(s) in 31m 17s
  </span>
</div>

!!! note
    The initial build will take a while. Depending on your hardware, you should expect approximately 30 minutes for the build process to finish.

Then, you will want to run the node in development mode using the following command:

```bash
./target/release/moonbeam --dev
```

!!! note
    For people not familiar with Substrate, the `--dev` flag is a way to run a Substrate-based node in a single-node developer configuration for testing purposes. When you run your node with the `--dev` flag, your node is started in a fresh state, and its state does not persist.

You should see an output that looks like the following, showing an idle state waiting for blocks to be produced:

<div id="termynal" data-termynal>
  <span data-ty="input"><span class="file-path"></span>./target/release/moonbeam --dev</span>
  <br>
  <span data-ty> 2025-07-10 09:04:26 Moonbeam Parachain Collator
    <br> 2025-07-10 09:04:26 ✌️  version 0.46.0-d7df89e7161
    <br> 2025-07-10 09:04:26 ❤️  by PureStake, 2019-2025
    <br> 2025-07-10 09:04:26 📋 Chain specification: Moonbase Development Testnet
    <br> 2025-07-10 09:04:26 🏷  Node name: black-and-white-sticks-9174
    <br> 2025-07-10 09:04:26 👤 Role: AUTHORITY
    <br> 2025-07-10 09:04:26 💾 Database: RocksDb at /tmp/substrateO3YeRz/chains/moonbase_dev/db/full
    <br> 2025-07-10 09:04:26 🔨 Initializing Genesis block/state (state: 0x7c34…99c5, header-hash: 0xa083…f354)
    <br> 2025-07-10 09:04:26 Using default protocol ID "sup" because none is configured in the chain specs
    <br> 2025-07-10 09:04:26 🏷  Local node identity is: 12D3KooWLcpczme2JeBEfLqmjqkzYVKTGKhhGmwSzHjRXGBVhDX7
    <br> 2025-07-10 09:04:26 💻 Operating system: linux
    <br> 2025-07-10 09:04:26 💻 CPU architecture: x86_64
    <br> 2025-07-10 09:04:26 💻 Target environment: gnu
    <br> 2025-07-10 09:04:26 💻 CPU: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
    <br> 2025-07-10 09:04:26 💻 CPU cores: 12
    <br> 2025-07-10 09:04:26 💻 Memory: 7946MB
    <br> 2025-07-10 09:04:26 💻 Kernel: 6.4.16-linuxkit
    <br> 2025-07-10 09:04:26 💻 Linux distribution: Debian GNU/Linux 12 (bookworm)
    <br> 2025-07-10 09:04:26 💻 Virtual machine: yes
    <br> 2025-07-10 09:04:26 📦 Highest known block at #0
    <br> 2025-07-10 09:04:26 Running JSON-RPC server: addr=0.0.0.0:9944, allowed origins=["*"]
    <br> 2025-07-10 09:04:26 🏁 CPU score: 1.14 GiBs
    <br> 2025-07-10 09:04:26 〽️ Prometheus exporter started at 127.0.0.1:9615
    <br> 2025-07-10 09:04:26 🏁 Memory score: 10.41 GiBs
    <br> 2025-07-10 09:04:26 🏁 Disk score (seq. writes): 987.96 MiBs
    <br> 2025-07-10 09:04:26 🏁 Disk score (rand. writes): 363.65 MiBs
    <br> 2025-07-10 09:04:26 Development Service Ready
    <br> 2025-07-10 09:04:26 💤 Idle (0 peers), best: #0 (0xa083…f354), finalized #0 (0xa083…f354), ⬇ 0 ⬆ 0
    <br> 2025-07-10 09:04:26 💤 Idle (0 peers), best: #0 (0xa083…f354), finalized #0 (0xa083…f354), ⬇ 0 ⬆ 0
  </span>
</div>

For more information on some of the flags and options used in the example, check out the [Flags](#node-flags) and [Options](#node-options). If you want to see a complete list of all of the flags, options, and subcommands, open the help menu by running:

```bash
./target/release/moonbeam --help
```

## Configure Your Moonbeam Development Node {: #configure-moonbeam-dev-node }

Now that you know how to get a standard Moonbeam development node up and running, you may be wondering how you can configure it. The following sections will cover some common configurations you can use when you spin up your node.

### Common Flags to Configure Your Node {: #node-flags }

Flags do not take an argument. To use a flag, add it to the end of a command. For example:

```bash
./target/release/moonbeam --dev
```

- **`--dev`** - specifies the development chain
- **`--tmp`** - runs a temporary node in which all of the configuration will be deleted at the end of the process
- **`--rpc-external`** - listen to all RPC and WebSocket interfaces

### Common Options to Configure Your Node {: #node-options }

Options accept an argument to the right of the option. For example:

```bash
./target/release/moonbeam --dev --sealing 6000
```

- **`-l <log pattern>` or `--log <log pattern>`** - sets a custom logging filter. The syntax for the log pattern is `<target>=<level>`. For example, to print all of the JSON-RPC logs, the command would look like this: `-l json=trace`
- **`--sealing <interval>`** - when blocks should be sealed in the dev service. Accepted arguments for interval: `instant`, `manual`, or a number representing the timer interval in milliseconds (for example, `6000` will have the node produce blocks every 6 seconds). The default is `instant``. Please refer to the [Configure Block Production](#configure-block-production) section below for more information
- **`--rpc-port <port>`** - sets the unified port for HTTP and WS connections. Accepts a port as the argument. Default is {{ networks.parachain.rpc }}
- **`--ws-port <port>`** - *deprecated as of [client v0.33.0](https://github.com/moonbeam-foundation/moonbeam/releases/tag/v0.33.0){target=\_blank}, use `--rpc-port` for HTTP and WS connections instead* - sets the WebSockets RPC server TCP port. As of [client v0.30.0](https://github.com/moonbeam-foundation/moonbeam/releases/tag/v0.30.0){target=\_blank}, it sets the unified port for both HTTP and WS connections. Accepts a port as the argument
- **`--rpc-max-connections <connections>`** - specifies the combined HTTP and WS connection limit. The default is 100 connections
- **`--ws-max-connections <connections>`** - *deprecated as of [client v0.33.0](https://github.com/moonbeam-foundation/moonbeam/releases/tag/v0.33.0){target=\_blank}, use `--rpc-max-connections` to limit the HTTP and WS connections instead* - this flag adjusts the combined HTTP and WS connection limit. The default is 100 connections
- **`--rpc-cors <origins>`** - specifies the browser origins allowed to access the HTTP and WS RPC servers. The origins can be a comma-separated list of the origins to allow access, or you can also specify `null`. When running a development node, the default is to allow all origins

For a complete list of flags and options, spin up your Moonbeam development node with `--help` added to the end of the command.

### Configure Block Production {: #configure-block-production }

By default, your Moonbeam development node is spun up in instant seal mode, which instantly authors blocks as transactions are received. However, you can specify when blocks should be authored or sealed by using the `--sealing` option.

The `--sealing` flag accepts any of the following arguments:

- `instant` - as we already covered, this is the default option in which blocks are authored as soon as a transaction is received
- `manual` - allows you to produce blocks manually. If a transaction is received, a block will not be produced until you manually create one
- an interval in milliseconds - authors a block on a specific time interval. For example, if you set it to `6000`, you will have the node produce blocks every 6 seconds

The flag should be appended to the start-up command in the following format:

```text
--sealing <interval>
```

If you choose `manual`, you'll need to manually create the blocks yourself, which can be done with the `engine_createBlock` JSON-RPC method:

```text
engine_createBlock(createEmpty: *bool*, finalize: *bool*, parentHash?: *BlockHash*)
```

For example, you can use the following snippet to manually create a block using [Ethers.js](/builders/ethereum/libraries/ethersjs/){target=\_blank}, an Ethereum library that makes it easy to interact with JSON-RPC methods:

```js
import { ethers } from 'ethers';

const produceBlock = async () => {
  // Connect to the Ethereum node (if applicable, replace the URL with your node's address)
  const provider = new ethers.JsonRpcProvider(
    '{{ networks.development.rpc_url }}'
  );

  // Set the custom JSON-RPC method and parameters
  const method = 'engine_createBlock';
  const params = [true, true, null];

  try {
    // Send the custom JSON-RPC call
    const result = await provider.send(method, params);
  } catch (error) {
    // Handle any errors that may occur
    console.error('Error:', error.message);
  }
};

produceBlock();
```

!!! note
    If you're unfamiliar with Ethers, please refer to the [Ethers.js](/builders/ethereum/libraries/ethersjs/){target=\_blank} documentation page to learn more.

## Prefunded Development Accounts {: #pre-funded-development-accounts }

Moonbeam has a [unified accounts](/learn/core-concepts/unified-accounts/){target=\_blank} system, which enables users to have an Ethereum-styled H160 account that can interact with the Substrate API and the Ethereum API. As a result, you can interact with your account through [Polkadot.js Apps](/tokens/connect/polkadotjs/#connect-polkadotjs-apps){target=\_blank} or [MetaMask](/tokens/connect/metamask/){target=\_blank} (or any other [EVM wallet](/tokens/connect/){target=\_blank}). In addition, you can also use other [development tools](/builders/ethereum/dev-env/){target=\_blank}, such as [Remix](/builders/ethereum/dev-env/remix/){target=\_blank} and [Hardhat](/builders/ethereum/dev-env/hardhat/){target=\_blank}.

Your Moonbeam development node comes with ten prefunded Ethereum-styled accounts for development. The addresses are derived from Substrate's canonical development mnemonic:

```text
bottom drive obey lake curtain smoke basket hold race lonely fit walk
```

??? note "Development account addresses and private keys"
    - Alith:
    - Public Address: `0xf24FF3a9CF04c71Dbc94D0b566f7A27B94566cac`
    - Private Key: `0x5fb92d6e98884f76de468fa3f6278f8807c48bebc13595d45af5bdc4da702133`

- Baltathar:
    - Public Address: `0x3Cd0A705a2DC65e5b1E1205896BaA2be8A07c6e0`
    - Private Key: `0x8075991ce870b93a8870eca0c0f91913d12f47948ca0fd25b49c6fa7cdbeee8b`

- Charleth:
    - Public Address: `0x798d4Ba9baf0064Ec19eB4F0a1a45785ae9D6DFc`
    - Private Key: `0x0b6e18cafb6ed99687ec547bd28139cafdd2bffe70e6b688025de6b445aa5c5b`

- Dorothy:
    - Public Address: `0x773539d4Ac0e786233D90A233654ccEE26a613D9`
    - Private Key: `0x39539ab1876910bbf3a223d84a29e28f1cb4e2e456503e7e91ed39b2e7223d68`

- Ethan:
    - Public Address: `0xFf64d3F6efE2317EE2807d223a0Bdc4c0c49dfDB`
    - Private Key: `0x7dce9bc8babb68fec1409be38c8e1a52650206a7ed90ff956ae8a6d15eeaaef4`

- Faith:
    - Public Address: `0xC0F0f4ab324C46e55D02D0033343B4Be8A55532d`
    - Private Key: `0xb9d2ea9a615f3165812e8d44de0d24da9bbd164b65c4f0573e1ce2c8dbd9c8df`

- Goliath:
    - Public Address: `0x7BF369283338E12C90514468aa3868A551AB2929`
    - Private Key: `0x96b8a38e12e1a31dee1eab2fffdf9d9990045f5b37e44d8cc27766ef294acf18`

- Heath: 
    - Public Address: `0x931f3600a299fd9B24cEfB3BfF79388D19804BeA`
    - Private Key: `0x0d6dcaaef49272a5411896be8ad16c01c35d6f8c18873387b71fbc734759b0ab`

- Ida: 
    - Public Address: `0xC41C5F1123ECCd5ce233578B2e7ebd5693869d73`
    - Private Key: `0x4c42532034540267bf568198ccec4cb822a025da542861fcb146a5fab6433ff8`

- Judith: 
    - Public Address: `0x2898FE7a42Be376C8BC7AF536A940F7Fd5aDd423`
    - Private Key: `0x94c49300a58d576011096bcb006aa06f5a91b34b4383891e8029c21dc39fbb8b`

Also included with the development node is an additional prefunded account used for testing purposes:

- Gerald:
    - Public Address: `0x6Be02d1d3665660d22FF9624b7BE0551ee1Ac91b`
    - Private Key: `0x99b3c12287537e38c90a9219d4cb074a89a16e9cdb20bf85728ebd97c343e342`

You can connect any of these accounts to [MetaMask](/tokens/connect/metamask/){target=\_blank}, [Talisman](/tokens/connect/talisman/){target=\_blank}, [Polkadot.js Apps](/tokens/connect/polkadotjs/){target=\_blank}, etc., using their private keys.

## Development Node Endpoints {: #access-your-development-node }

You can access your Moonbeam development node using the following RPC and WSS endpoints:

=== "HTTP"

    ```text
    {{ networks.development.rpc_url }}
    ```

=== "WSS"

    ```text
    {{ networks.development.wss_url }}
    ```

## Block Explorers {: #block-explorers }

For a Moonbeam development node, you can use any of the following block explorers:

 - **Substrate API** — [Polkadot.js Apps](https://polkadot.js.org/apps/?rpc=ws://127.0.0.1:9944#/explorer){target=\_blank} on WS port `{{ networks.parachain.ws }}`
 - **Ethereum API JSON-RPC-based** — [Moonbeam Basic Explorer](https://moonbeam-explorer.netlify.app/?network=MoonbeamDevNode){target=\_blank} on HTTP port `{{ networks.parachain.ws }}`

## Debug, Trace, and TxPool APIs {: #debug-trace-txpool-apis }

You can also gain access to some non-standard RPC methods by running a tracing node, which allows developers to inspect and debug transactions during runtime. Tracing nodes use a different Docker image than a standard Moonbeam development node.

To learn how to run a Moonbeam development tracing node, check out the [Run a Tracing Node](/node-operators/networks/tracing-node/){target=\_blank} guide, and be sure to switch to the **Moonbeam Development Node** tab throughout the instructions. Then, to access the non-standard RPC methods with your tracing node, check out the [Debug & Trace](/builders/ethereum/json-rpc/debug-trace/){target=\_blank} guide.

## Purge a Development Node {: #purging-your-node }

If you want to remove data associated with your node, you can purge it. The instructions for purging a node are different depending on how you initially spun up your node.

### Purge a Node Spun Up with Docker {: #purge-docker-node }

If you spun up your node using Docker along with the `-v` flag to specify a mounted directory for your container, you will need to purge that directory. To do so, you can run the following command:

```bash
sudo rm -rf {{ networks.moonbase.node_directory }}/*
```

If you followed the instructions in this guide and did not use the `-v` flag, you can stop and remove the Docker container. The associated data will be removed along with it. To do so, you can run the following command:

```bash
sudo docker stop `CONTAINER_ID` && docker rm `CONTAINER_ID`
```

### Purge a Node Spun up with a Binary File {: #purge-binary-node }

When running a node via the binary file, data is stored in a local directory, typically located in `~/.local/shared/moonbeam/chains/development/db`. If you want to start a fresh instance of the node, you can either delete the content of the folder or run the following command inside the `moonbeam` folder:

```bash
./target/release/moonbeam purge-chain --dev -y
```

This will remove the data folder. Note that all chain data is now lost. To learn more about all of the available `purge-chain` commands, you can check out the [Purging Binary Data](/node-operators/networks/run-a-node/systemd/#purging-compiled-binary){target=\_blank} section of our documentation.
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/builders/get-started/networks/moonbeam/
--- BEGIN CONTENT ---
---
title: Get Started with Moonbeam
description: Learn how to connect to Moonbeam via RPC and WSS endpoints, how to connect MetaMask to Moonbeam, and about the available Moonbeam block explorers.
categories: Basics
---

# Get Started with Moonbeam

## Network Endpoints {: #network-endpoints }

Moonbeam has two types of endpoints available for users to connect to: one for HTTPS and one for WSS.

If you're looking for your own endpoints suitable for production use, you can check out the [Endpoint Providers](/builders/get-started/endpoints/#endpoint-providers){target=\_blank} section of our documentation. Otherwise, to get started quickly you can use one of the following public HTTPS or WSS endpoints:

=== "HTTPS"
    |  Provider   |                              RPC URL                               |   Limits    |
    |:-----------:|:------------------------------------------------------------------:|:-----------:|
    |   Dwellir   |         <pre>```https://moonbeam-rpc.dwellir.com```</pre>          | 20 req/sec  |
    | OnFinality  |     <pre>```https://moonbeam.api.onfinality.io/public```</pre>     | 40 req/sec  |
    | UnitedBloc  |          <pre>```https://moonbeam.unitedbloc.com```</pre>          | 32 req/sec  |
    | RadiumBlock | <pre>```https://moonbeam.public.curie.radiumblock.co/http```</pre> | 200 req/sec |
    |    1RPC     |               <pre>```https://1rpc.io/glmr```</pre>                | 10k req/day |
    |    Grove    |         <pre>```https://moonbeam.rpc.grove.city/v1/01fdb492```</pre>         | 5k req/day  |



=== "WSS"
    |  Provider   |                            RPC URL                             |   Limits    |
    |:-----------:|:--------------------------------------------------------------:|:-----------:|
    |   Dwellir   |        <pre>```wss://moonbeam-rpc.dwellir.com```</pre>         | 20 req/sec  |
    | OnFinality  |  <pre>```wss://moonbeam.api.onfinality.io/public-ws```</pre>   | 40 req/sec  |
    | UnitedBloc  |         <pre>```wss://moonbeam.unitedbloc.com```</pre>         | 32 req/sec  |
    | RadiumBlock | <pre>```wss://moonbeam.public.curie.radiumblock.co/ws```</pre> | 200 req/sec |
    |    1RPC     |              <pre>```wss://1rpc.io/glmr```</pre>               | 10k req/day |

## Quick Start {: #quick-start }

Before getting started, make sure you've retrieved your own endpoint and API key from one of the custom [Endpoint Providers](/builders/get-started/endpoints/){target=\_blank}. Then for the [Web3.js library](/builders/ethereum/libraries/web3js/){target=\_blank}, you can create a local Web3 instance and set the provider to connect to Moonbeam (both HTTP and WS are supported):

```js
const { Web3 } = require('web3'); // Load Web3 library
.
.
.
// Create local Web3 instance - set Moonbeam as provider
const web3 = new Web3('INSERT_RPC_API_ENDPOINT'); // Insert your RPC URL here
```

For the [Ethers.js library](/builders/ethereum/libraries/ethersjs/){target=\_blank}, define the provider by using `ethers.JsonRpcProvider(providerURL, {object})` and setting the provider URL to Moonbeam:

```js
const ethers = require('ethers'); // Load Ethers library

const providerURL = 'INSERT_RPC_API_ENDPOINT'; // Insert your RPC URL here

// Define provider
const provider = new ethers.JsonRpcProvider(providerURL, {
    chainId: 1284,
    name: 'moonbeam'
});
```

Any Ethereum wallet should be able to generate a valid address for Moonbeam (for example, [MetaMask](https://metamask.io){target=\_blank}).

## Chain ID {: #chain-id }

Moonbeam chain ID is: `1284`, or `0x504` in hex.

## Block Explorers {: #block-explorers }

For Moonbeam, you can use any of the following block explorers:

 - **Ethereum API (Etherscan Equivalent)** — [Moonscan](https://moonbeam.moonscan.io){target=\_blank}
 - **Ethereum API JSON-RPC based** — [Moonbeam Basic Explorer](https://moonbeam-explorer.netlify.app/?network=Moonbeam){target=\_blank}
 - **Substrate API** — [Subscan](https://moonbeam.subscan.io){target=\_blank} or [Polkadot.js Apps](https://polkadot.js.org/apps/?rpc=wss://wss.api.moonbeam.network#/explorer){target=\_blank}

For more information on each of the available block explorers, please head to the [Block Explorers](/builders/get-started/explorers/){target=\_blank} section of the documentation.

## Connect MetaMask {: #connect-metamask }

If you already have MetaMask installed, you can easily connect MetaMask to Moonbeam:

<div class="button-wrapper">
    <a href="#" class="md-button connectMetaMask" value="moonbeam">Connect MetaMask</a>
</div>

!!! note
    MetaMask will popup asking for permission to add Moonbeam as a custom network. Once you approve permissions, MetaMask will switch your current network to Moonbeam.

If you do not have MetaMask installed, or would like to follow a tutorial to get started, please check out the [Interacting with Moonbeam using MetaMask](/tokens/connect/metamask/){target=\_blank} guide.

## Configuration {: #configuration }

Please note the following gas configuration parameters. These values are subject to change in future runtime upgrades.


|       Variable        |                   Value                    |
|:---------------------:|:------------------------------------------:|
|   Minimum gas price   | {{ networks.moonbeam.min_gas_price }} Gwei |
|   Target block time   | {{ networks.moonbeam.block_time }} seconds |
|    Block gas limit    |     {{ networks.moonbeam.gas_block }}      |
| Transaction gas limit |       {{ networks.moonbeam.gas_tx }}       |
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/builders/get-started/networks/moonriver/
--- BEGIN CONTENT ---
---
title: Moonriver Get Started Guide
description: Learn how to connect to Moonriver via RPC and WSS endpoints, how to connect MetaMask to Moonriver, and about the available Moonriver block explorers.
categories: Basics
---

# Get Started with Moonriver

## Network Endpoints {: #network-endpoints }

Moonriver has two types of endpoints available for users to connect to: one for HTTPS and one for WSS.

If you're looking for your own endpoints suitable for production use, you can check out the [Endpoint Providers](/builders/get-started/endpoints/#endpoint-providers){target=\_blank} section of our documentation. Otherwise, to get started quickly you can use one of the following public HTTPS or WSS endpoints:

=== "HTTPS"
      |  Provider   |                               RPC URL                               |   Limits    |
      |:-----------:|:-------------------------------------------------------------------:|:-----------:|
      |   Dwellir   |         <pre>```https://moonriver-rpc.dwellir.com```</pre>          | 20 req/sec  |
      | OnFinality  |     <pre>```https://moonriver.api.onfinality.io/public```</pre>     | 40 req/sec  |
      | UnitedBloc  |          <pre>```https://moonriver.unitedbloc.com```</pre>          | 32 req/sec  |
      | RadiumBlock | <pre>```https://moonriver.public.curie.radiumblock.co/http```</pre> | 200 req/sec |
      |    Grove    |        <pre>```https://moonriver.rpc.grove.city/v1/01fdb492```</pre>        | 5k req/day  |

=== "WSS"
    |  Provider   |                             RPC URL                             |   Limits    |
    |:-----------:|:---------------------------------------------------------------:|:-----------:|
    |   Dwellir   |        <pre>```wss://moonriver-rpc.dwellir.com```</pre>         | 20 req/sec  |
    | OnFinality  |  <pre>```wss://moonriver.api.onfinality.io/public-ws```</pre>   | 40 req/sec  |
    | UnitedBloc  |         <pre>```wss://moonriver.unitedbloc.com```</pre>         | 32 req/sec  |
    | RadiumBlock | <pre>```wss://moonriver.public.curie.radiumblock.co/ws```</pre> | 200 req/sec |

## Quick Start {: #quick-start }

Before getting started, make sure you've retrieved your own endpoint and API key from one of the custom [Endpoint Providers](/builders/get-started/endpoints/){target=\_blank}. Then for the [Web3.js library](/builders/ethereum/libraries/web3js/){target=\_blank}, you can create a local Web3 instance and set the provider to connect to Moonriver (both HTTP and WS are supported):

```js
const { Web3 } = require('web3'); // Load Web3 library
.
.
.
// Create local Web3 instance - set Moonriver as provider
const web3 = new Web3('INSERT_RPC_API_ENDPOINT'); // Insert your RPC URL here
```

For the [Ethers.js library](/builders/ethereum/libraries/ethersjs/){target=\_blank}, define the provider by using `ethers.JsonRpcProvider(providerURL, {object})` and setting the provider URL to Moonriver:

```js
const ethers = require('ethers'); // Load Ethers library

const providerURL = 'INSERT_RPC_API_ENDPOINT'; // Insert your RPC URL here

// Define provider
const provider = new ethers.JsonRpcProvider(providerURL, {
    chainId: 1285,
    name: 'moonriver'
});
```

Any Ethereum wallet should be able to generate a valid address for Moonbeam (for example, [MetaMask](https://metamask.io){target=\_blank}).

## Chain ID {: #chain-id }

Moonriver chain ID is: `1285`, or `0x505` in hex.

## Block Explorers {: #block-explorers }

For Moonriver, you can use any of the following block explorers:

 - **Ethereum API (Etherscan Equivalent)** — [Moonscan](https://moonriver.moonscan.io){target=\_blank}
 - **Ethereum API JSON-RPC based** — [Moonbeam Basic Explorer](https://moonbeam-explorer.netlify.app/?network=Moonriver){target=\_blank}
 - **Substrate API** — [Subscan](https://moonriver.subscan.io){target=\_blank} or [Polkadot.js Apps](https://polkadot.js.org/apps/?rpc=wss://wss.api.moonriver.moonbeam.network#/explorer){target=\_blank}
 
For more information on each of the available block explorers, please head to the [Block Explorers](/builders/get-started/explorers/) section of the documentation.

## Connect MetaMask {: #connect-metamask }

If you already have MetaMask installed, you can easily connect MetaMask to Moonriver:

<div class="button-wrapper">
    <a href="#" class="md-button connectMetaMask" value="moonriver">Connect MetaMask</a>
</div>

!!! note
    MetaMask will popup asking for permission to add Moonriver as a custom network. Once you approve permissions, MetaMask will switch your current network to Moonriver.

If you do not have MetaMask installed, or would like to follow a tutorial to get started, please check out the [Interacting with Moonbeam using MetaMask](/tokens/connect/metamask/) guide.

## Configuration {: #configuration }

Please note the following gas configuration parameters. These values are subject to change in future runtime upgrades.

|       Variable        |                    Value                    |
|:---------------------:|:-------------------------------------------:|
|   Minimum gas price   | {{ networks.moonriver.min_gas_price }} Gwei |
|   Target block time   | {{ networks.moonriver.block_time }} seconds |
|    Block gas limit    |     {{ networks.moonriver.gas_block }}      |
| Transaction gas limit |       {{ networks.moonriver.gas_tx }}       |
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/builders/get-started/quick-start/
--- BEGIN CONTENT ---
---
title: Quickly Get Started
description: Everything you need to know to get started developing, deploying, and interacting with smart contracts on Moonbeam.
categories: Basics
---

# Quick Start Guide for Developing on Moonbeam

## Quick Overview {: #overview }

Moonbeam is a fully Ethereum-compatible smart contract platform on Polkadot. As such, you can interact with Moonbeam via the [Ethereum API](/builders/ethereum/){target=\_blank} and [Substrate API](/builders/substrate/){target=\_blank}.

Although Moonbeam is a Substrate-based platform, Moonbeam uses a [unified accounts](/learn/core-concepts/unified-accounts/){target=\_blank} system, which replaces Substrate-style accounts and keys with Ethereum-style accounts and keys. As a result, you can interact with your Moonbeam account with [MetaMask](/tokens/connect/metamask/){target=\_blank}, [Ledger](/tokens/connect/ledger/){target=\_blank}, and other Ethereum-compatible wallets by simply adding Moonbeam's network configurations. Similarly, you can develop on Moonbeam using Ethereum [libraries](/builders/ethereum/libraries/){target=\_blank} and [development environments](/builders/ethereum/dev-env/){target=\_blank}.

## Moonbeam Networks {: #moonbeam-networks }

To get started developing on Moonbeam, it's important to be aware of the various networks within the Moonbeam ecosystem.

|                                          Network                                          | Network Type  |                                   Relay Chain                                    | Native Asset Symbol | Native Asset Decimals |
|:-----------------------------------------------------------------------------------------:|:-------------:|:--------------------------------------------------------------------------------:|:-------------------:|:---------------------:|
|           [Moonbeam](/builders/get-started/networks/moonbeam/){target=\_blank}            |    MainNet    |                 [Polkadot](https://polkadot.com){target=\_blank}                 |        GLMR         |          18           |
|          [Moonriver](/builders/get-started/networks/moonriver/){target=\_blank}           |    MainNet    |                 [Kusama](https://kusama.network){target=\_blank}                 |        MOVR         |          18           |
|        [Moonbase Alpha](/builders/get-started/networks/moonbase/){target=\_blank}         |    TestNet    | [Alphanet relay](/learn/platform/networks/moonbase/#relay-chain){target=\_blank} |         DEV         |          18           |
| [Moonbeam Development Node](/builders/get-started/networks/moonbeam-dev/){target=\_blank} | Local TestNet |                                       None                                       |         DEV         |          18           |

!!! note
    A Moonbeam development node doesn't have a relay chain as its purpose is to be your own personal development environment where you can get started developing quickly without the overhead of a relay chain.

### Network Configurations {: #network-configurations }

When working with developer tools, depending on the tool, you might need to configure Moonbeam to interact with the network. To do so, you can use the following information:

=== "Moonbeam"

    |    Variable     |                                                 Value                                                  |
    |:---------------:|:------------------------------------------------------------------------------------------------------:|
    |    Chain ID     |                           <pre>```{{ networks.moonbeam.chain_id }}```</pre>                            |
    | Public RPC URLs | <pre>```https://moonbeam.public.blastapi.io```</pre>  <pre>```https://moonbeam.unitedbloc.com```</pre> |
    | Public WSS URLs |                           <pre>```wss://moonbeam.public.blastapi.io```</pre>                           |

=== "Moonriver"

    |    Variable     |                                                  Value                                                   |
    |:---------------:|:--------------------------------------------------------------------------------------------------------:|
    |    Chain ID     |                            <pre>```{{ networks.moonriver.chain_id }}```</pre>                            |
    | Public RPC URLs | <pre>```https://moonriver.public.blastapi.io```</pre>  <pre>```https://moonriver.unitedbloc.com```</pre> |
    | Public WSS URLs |                           <pre>```wss://moonriver.public.blastapi.io```</pre>                            |

=== "Moonbase Alpha"

    |    Variable     |                                                    Value                                                    |
    |:---------------:|:-----------------------------------------------------------------------------------------------------------:|
    |    Chain ID     |                              <pre>```{{ networks.moonbase.chain_id }}```</pre>                              |
    | Public RPC URLs | <pre>```https://moonbase-alpha.public.blastapi.io```</pre> <pre>```{{ networks.moonbase.rpc_url }}```</pre> |
    | Public WSS URLs |  <pre>```wss://moonbase-alpha.public.blastapi.io```</pre> <pre>```{{ networks.moonbase.wss_url }}```</pre>  |

=== "Moonbeam Dev Node"

    |   Variable    |                        Value                         |
    |:-------------:|:----------------------------------------------------:|
    |   Chain ID    | <pre>```{{ networks.development.chain_id }}```</pre> |
    | Local RPC URL | <pre>```{{ networks.development.rpc_url }}```</pre>  |
    | Local WSS URL | <pre>```{{ networks.development.wss_url }}```</pre>  |

!!! note
    You can create your own endpoint suitable for development or production from one of the [supported RPC providers](/builders/get-started/endpoints/#endpoint-providers){target=\_blank}.

### Block Explorers {: #explorers }

Moonbeam provides two different kinds of explorers: ones to query the Ethereum API, and others dedicated to the Substrate API. All EVM-based transactions are accessible via the Ethereum API whereas the Substrate API can be relied upon for Substrate-native functions such as governance, staking, and some information about EVM-based transactions. For more information on each explorer, please check out the [Block Explorers](/builders/get-started/explorers/){target=\_blank} page.

=== "Moonbeam"
    | Block Explorer |   Type    |                                                                  URL                                                                  |
    |:--------------:|:---------:|:-------------------------------------------------------------------------------------------------------------------------------------:|
    |    Moonscan    |    EVM    |                            [https://moonbeam.moonscan.io/](https://moonbeam.moonscan.io){target=\_blank}                             |
    |   Expedition   |    EVM    |  [https://moonbeam-explorer.netlify.app/?network=Moonbeam](https://moonbeam-explorer.netlify.app/?network=Moonbeam){target=\_blank}  |
    |    Subscan     | Substrate |                             [https://moonbeam.subscan.io/](https://moonbeam.subscan.io){target=\_blank}                              |
    |  Polkadot.js   | Substrate | [https://polkadot.js.org/apps/#/explorer](https://polkadot.js.org/apps/?rpc=wss://wss.api.moonbeam.network#/explorer){target=\_blank} |

=== "Moonriver"
    | Block Explorer |   Type    |                                                                       URL                                                                       |
    |:--------------:|:---------:|:-----------------------------------------------------------------------------------------------------------------------------------------------:|
    |    Moonscan    |    EVM    |                                [https://moonriver.moonscan.io/](https://moonriver.moonscan.io){target=\_blank}                                 |
    |   Expedition   |    EVM    |      [https://moonbeam-explorer.netlify.app/?network=Moonriver](https://moonbeam-explorer.netlify.app/?network=Moonriver){target=\_blank}      |
    |    Subscan     | Substrate |                                 [https://moonriver.subscan.io/](https://moonriver.subscan.io){target=\_blank}                                  |
    |  Polkadot.js   | Substrate | [https://polkadot.js.org/apps/#/explorer](https://polkadot.js.org/apps/?rpc=wss://wss.api.moonrvier.moonbeam.network#/explorer){target=\_blank} |

=== "Moonbase Alpha"
    | Block Explorer |   Type    |                                                                      URL                                                                       |
    |:--------------:|:---------:|:----------------------------------------------------------------------------------------------------------------------------------------------:|
    |    Moonscan    |    EVM    |                                 [https://moonbase.moonscan.io/](https://moonbase.moonscan.io){target=\_blank}                                 |
    |   Expedition   |    EVM    | [https://moonbeam-explorer.netlify.app/?network=MoonbaseAlpha](https://moonbeam-explorer.netlify.app/?network=MoonbaseAlpha){target=\_blank}  |
    |    Subscan     | Substrate |                                  [https://moonbase.subscan.io/](https://moonbase.subscan.io){target=\_blank}                                  |
    |  Polkadot.js   | Substrate | [https://polkadot.js.org/apps/#/explorer](https://polkadot.js.org/apps/?rpc=wss://wss.api.moonbase.moonbeam.network#/explorer){target=\_blank} |

=== "Moonbeam Dev Node"
    | Block Explorer |   Type    |                                                                        URL                                                                        |
    |:--------------:|:---------:|:-------------------------------------------------------------------------------------------------------------------------------------------------:|
    |   Expedition   |    EVM    | [https://moonbeam-explorer.netlify.app/?network=MoonbeamDevNode](https://moonbeam-explorer.netlify.app/?network=MoonbeamDevNode){target=\_blank} |
    |  Polkadot.js   | Substrate |     [https://polkadot.js.org/apps/#/explorer](https://polkadot.js.org/apps/?rpc=wss://ws%3A%2F%2F127.0.0.1%3A9944#/explorer){target=\_blank}      |

## Funding TestNet Accounts {: #testnet-tokens }

To get started developing on one of the TestNets, you'll need to fund your account with DEV tokens to send transactions. Please note that DEV tokens have no real value and are for testing purposes only.

|                                          TestNet                                          |                                                                           Where To Get Tokens From                                                                           |
|:-----------------------------------------------------------------------------------------:|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|
|        [Moonbase Alpha](/builders/get-started/networks/moonbase/){target=\_blank}         | The [Moonbase Alpha Faucet](https://faucet.moonbeam.network){target=\_blank} website. <br> The faucet dispenses {{ networks.moonbase.website_faucet_amount }} every 24 hours |
| [Moonbeam Development Node](/builders/get-started/networks/moonbeam-dev/){target=\_blank} | Any of the [ten pre-funded accounts](/builders/get-started/networks/moonbeam-dev/#pre-funded-development-accounts){target=\_blank} that come with your <br> development node |

## Development Tools {: #development-tools }

As Moonbeam is a Substrate-based chain that is fully Ethereum-compatible, you can use Substrate-based tools and Ethereum-based tools.

### JavaScript Tools {: #javascript }

=== "Ethereum"

    |                                   Tool                                   |      Type       |
    |:------------------------------------------------------------------------:|:---------------:|
    |   [Ethers.js](/builders/ethereum/libraries/ethersjs/){target=\_blank}    |     Library     |
    |     [Web3.js](/builders/ethereum/libraries/web3js/){target=\_blank}      |     Library     |
    |      [Hardhat](/builders/ethereum/dev-env/hardhat/){target=\_blank}      | Dev Environment |
    | [OpenZeppelin](/builders/ethereum/dev-env/openzeppelin/){target=\_blank} | Dev Environment |
    |        [Remix](/builders/ethereum/dev-env/remix/){target=\_blank}        | Dev Environment |
    | [Scaffold-Eth](/builders/ethereum/dev-env/scaffold-eth/){target=\_blank} | Dev Environment |
    |     [thirdweb](/builders/ethereum/dev-env/thirdweb/){target=\_blank}     | Dev Environment |
    | [Waffle & Mars](/builders/ethereum/dev-env/waffle-mars/){target=\_blank} | Dev Environment |

=== "Substrate"

    |                                       Tool                                        |  Type   |
    |:---------------------------------------------------------------------------------:|:-------:|
    | [Polkadot.js API](/builders/substrate/libraries/polkadot-js-api/){target=\_blank} | Library |

### Python Tools {: #python }

=== "Ethereum"

    |                              Tool                               |      Type       |
    |:---------------------------------------------------------------:|:---------------:|
    | [Web3.py](/builders/ethereum/libraries/web3py/){target=\_blank} |     Library     |
    |     [Ape](/builders/ethereum/dev-env/ape/){target=\_blank}      | Dev Environment |

=== "Substrate"

    |                                              Tool                                               |  Type   |
    |:-----------------------------------------------------------------------------------------------:|:-------:|
    | [Py Substrate Interface](/builders/substrate/libraries/py-substrate-interface/){target=\_blank} | Library |
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/builders/interoperability/xcm/core-concepts/instructions/
--- BEGIN CONTENT ---
---
title: XCM Instructions
description: When XCM instructions are combined, they form an XCM message that performs a cross-chain action. Take a look at some of the most common instructions.
categories: XCM, Basics
---

# XCM Instructions

## Introduction {: #introduction }

XCM messages contain a series of [actions and instructions](https://github.com/paritytech/xcm-format#5-the-xcvm-instruction-set){target=\_blank} that are executed by the Cross-Consensus Virtual Machine (XCVM). An action (for example, transferring a token from one blockchain to another) consists of instructions that the XCVM partly executes in the origin and destination chains.

For example, an XCM message that transfers DOT from Polkadot to Moonbeam will include the following XCM instructions (in that order), some of which are executed on Polkadot and some of which are executed on Moonbeam:

 1. [TransferReserveAsset](#transfer-reserve-asset) — executed in Polkadot
 2. [ReserveAssetDeposited](#reserve-asset-deposited) — executed in Moonbeam
 3. [ClearOrigin](#clear-origin) — executed in Moonbeam
 4. [BuyExecution](#buy-execution) — executed in Moonbeam
 5. [DepositAsset](#deposit-asset) — executed in Moonbeam

Building the instructions for an XCM message from scratch is not an easy task. Consequently, there are wrapper functions and pallets that developers can leverage to use XCM features. The [Polkadot XCM](/builders/interoperability/xcm/xc20/send-xc20s/xcm-pallet/){target=\_blank} and [XCM Transactor](/builders/interoperability/xcm/remote-execution/substrate-calls/xcm-transactor-pallet/){target=\_blank} Pallets provide functions with a predefined set of XCM instructions to either send [XC-20s](/builders/interoperability/xcm/xc20/overview/){target=\_blank} or remotely execute on other chains via XCM.

If you're interested in experimenting with different combinations of instructions, you can [use the Polkadot XCM Pallet to execute and send custom XCM messages](/builders/interoperability/xcm/send-execute-xcm/){target=\_blank}.

This guide provides an overview of some of the most commonly used XCM instructions, including those in the above example.

## Buy Execution {: #buy-execution }

The [`BuyExecution`](https://github.com/paritytech/xcm-format#buyexecution){target=\_blank} instruction typically gets executed in the target chain. It takes assets from the holding register, a temporary position in the Cross-Consensus Virtual Machine (XCVM), to pay for execution fees. The target chain determines the fees to pay.

## Clear Origin {: #clear-origin }

The [`ClearOrigin`](https://github.com/paritytech/xcm-format#clearorigin){target=\_blank} instruction gets executed in the target chain. It clears the origin of the XCM author, thereby ensuring that later XCM instructions cannot command the authority of the author.

## Deposit Asset {: #deposit-asset }

The [`DepositAsset`](https://github.com/paritytech/xcm-format#depositasset){target=\_blank} instruction gets executed in the target chain. It removes the assets from the holding register, a temporary position in the Cross-Consensus Virtual Machine (XCVM), and sends them to a destination account on the target chain.

## Descend Origin {: #descend-origin }

The [`DescendOrigin`](https://github.com/paritytech/xcm-format#descendorigin){target=\_blank} instruction gets executed in the target chain. It mutates the origin on the target chain to match the origin on the source chain, ensuring execution on the target chain occurs on behalf of the same entity initiating the XCM message on the source chain.

## Initiate Reserve Withdraw {: #initiate-reserve-withdraw }

The [`InitiateReserveWithdraw`](https://github.com/paritytech/xcm-format#initiatereservewithdraw){target=\_blank} instruction gets executed in the source chain. It removes the assets from the holding register, a temporary position in the Cross-Consensus Virtual Machine (XCVM), (essentially burning them), and sends an XCM message to the reserve chain starting with the `WithdrawAsset` instruction.

## Refund Surplus {: #refund-surplus }

The [`RefundSurplus`](https://github.com/paritytech/xcm-format#refundsurplus){target=\_blank} instruction typically gets executed in the target chain after the XCM is processed. This instruction will take any leftover assets from the `BuyExecution` instruction and put the assets into the holding register, a temporary position in the Cross-Consensus Virtual Machine (XCVM).

## Reserve Asset Deposited {: #reserve-asset-deposited }

The [`ReserveAssetDeposited`](https://github.com/paritytech/xcm-format#reserveassetdeposited-){target=\_blank} instruction gets executed in the target chain. It takes a representation of the assets received in the Sovereign account and places them into the holding register, a temporary position in the Cross-Consensus Virtual Machine (XCVM).

## Set Appendix {: #set-appendix }

The [`SetAppendix`](https://github.com/paritytech/xcm-format#setappendix){target=\_blank} instruction gets executed in the target chain. It sets the appendix register, which holds code that should be run after the current execution is finished.

## Transfer Reserve Asset {: #transfer-reserve-asset }

The [`TransferReserveAsset`](https://github.com/paritytech/xcm-format#transferreserveasset){target=\_blank} instruction gets executed in the reserve chain. It moves assets from the origin account and deposits them into a destination account on the target chain. It then sends an XCM message to the target chain with the `ReserveAssetDeposited` instruction, followed by the XCM instructions that are to be executed.

## Transact {: #transact }

The [`Transact`](https://github.com/paritytech/xcm-format#transact){target=\_blank} instruction gets executed in the target chain. It dispatches encoded call data from a given origin, allowing for the execution of specific operations or functions on the target chain.

## Withdraw Asset {: #withdraw-asset }

The [`WithdrawAsset`](https://github.com/paritytech/xcm-format#withdrawasset){target=\_blank} instruction can be executed in either the source or target chain. It removes assets and places them into the holding register, a temporary position in the Cross-Consensus Virtual Machine (XCVM).
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/builders/interoperability/xcm/overview/
--- BEGIN CONTENT ---
---
title: Cross-Consensus Messaging (XCM)
description: An overview of how cross-consensus messaging (XCM) works and how developers can leverage Polkadot/Kusama XCM to gain access to new assets.
categories: Basics, XCM
---

# Cross-Consensus Messaging (XCM)

## Introduction {: #introduction }

[Polkadot's architecture](https://wiki.polkadot.com/learn/learn-architecture/){target=\_blank} allows parachains to natively interoperate with each other, enabling cross-blockchain transfers of any type of data or asset.

To do so, a [Cross-Consensus Message (XCM)](https://wiki.polkadot.com/learn/learn-xcm/){target=\_blank} format defines a language around how the message transfer between two interoperating blockchains should be performed. XCM is not specific to Polkadot, as it aims to be a generic and extensible language between different consensus systems.

This page is a brief introduction and overview of XCM and other related elements. More information can be found in [Polkadot's Wiki](https://wiki.polkadot.com/learn/learn-xcm/){target=\_blank}.

If you want to jump to more XCM-related content, feel free to check out the following pages:

- [**Core XCM Concepts**](/builders/interoperability/xcm/core-concepts/){target=\_blank} - learn topics related to [XCM Instructions](/builders/interoperability/xcm/core-concepts/instructions/){target=\_blank}, [Multilocations](/builders/interoperability/xcm/core-concepts/multilocations/){target=\_blank}, and [XCM Fees](/builders/interoperability/xcm/core-concepts/weights-fees/){target=\_blank}
- [**XC Registration**](/builders/interoperability/xcm/xc-registration/){target=\_blank} - go through the process of [Opening an XCM Channel with Moonbeam](/builders/interoperability/xcm/xc-registration/xc-integration/){target=\_blank} and how to [Register Polkadot Native Assets as XC-20s](/builders/interoperability/xcm/xc-registration/assets/){target=\_blank}
- [**XC-20s**](/builders/interoperability/xcm/xc20/){target=\_blank} - read an [Overview](/builders/interoperability/xcm/xc20/overview/){target=\_blank} of this Moonbeam-only asset class and learn how to [Interact with XC-20s](/builders/interoperability/xcm/xc20/interact/){target=\_blank} and how to [Send them via XCM](/builders/interoperability/xcm/xc20/send-xc20s/){target=\_blank}
- [**Remote Execution via XCM**](/builders/interoperability/xcm/remote-execution/){target=\_blank} - grasp all concepts related to remote execution via XCM, starting with a [High-Level Overview](/builders/interoperability/xcm/remote-execution/overview/){target=\_blank}, then [Computed Origins](/builders/interoperability/xcm/remote-execution/computed-origins/){target=\_blank} and wrapping up with [Remote Calls via XCM](/builders/interoperability/xcm/remote-execution/substrate-calls/){target=\_blank} and [Remote EVM Calls via XCM](/builders/interoperability/xcm/remote-execution/remote-evm-calls/){target=\_blank}
- [**XCM SDK**](https://moonbeam-foundation.github.io/xcm-sdk/latest/){target=\_blank} - learn how to [Use Moonbeam's XCM SDK](https://moonbeam-foundation.github.io/xcm-sdk/latest/example-usage/xcm/){target=\_blank}
- **XCM Debugging and Tools** - learn how to test some XCM scenarios by  [Sending and Executing Generic XCM Messages](/builders/interoperability/xcm/send-execute-xcm/){target=\_blank}, or how to use the [XCM Utilities Precompile](/builders/interoperability/xcm/xcm-utils/){target=\_blank} to access XCM_related utility functions directly within the EVM

## General XCM Definitions {: #general-xcm-definitions }

- **XCM** — stands for Cross-Consensus Message. It is a general way for consensus systems to communicate with each other
 - **VMP** — stands for Vertical Message Passing, one of the transport methods for XCMs. It allows parachains to exchange messages with the relay chain. *UMP* (Upward Message Passing) enables parachains to send messages to their relay chain, while *DMP* (Downward Message Passing) enables the relay chain to pass messages down to one of their parachains
 - **XCMP** — stands for Cross-Consensus Message Passing, one of the transport methods for XCMs. It allows parachains to exchange messages with other parachains on the same relay chain
 - **HRMP** — stands for Horizontal Relay-routed Message Passing, a stop-gap protocol while a full XCMP implementation is launched. It has the same interface as XCMP, but messages are stored on the relay chain
- **Sovereign account** —  an account each chain in the ecosystem has, one for the relay chain and the other for other parachains. It is calculated as the `blake2` hash of a specific word and parachain ID concatenated (`blake2(para+ParachainID)` for the Sovereign account in the relay chain, and `blake2(sibl+ParachainID)` for the Sovereign account in other parachains), truncating the hash to the correct length. The account is owned by root and can only be used through SUDO (if available) or [governance (referenda)](/learn/features/governance/){target=\_blank}. The Sovereign account typically signs XCM messages in other chains in the ecosystem
 - **Multilocation** —  a way to specify a point in the entire relay chain/parachain ecosystem relative to a given origin. For example, it can be used to specify a specific parachain, asset, account, or even a pallet inside a parachain. In general terms, a multilocation is defined with a `parents` and an `interior`:
 
    - `parents` - refers to how many "hops" into a parent blockchain you need to take from a given origin
    - `interior` - refers to how many fields you need to define the target point. 
    
    For example, to target a parachain with ID `1000` from another parachain, the multilocation would be `{ "parents": 1, "interior": { "X1": [{ "Parachain": 1000 }]}}`

## Cross-Chain Transport Protocols via XCM {: #xcm-transport-protocols }

XCM implements two cross-consensus or transport protocols for acting on XCM messages between its constituent parachains, Moonbeam being one of them:

- **Vertical Message Passing (VMP)** — once a project is onboarded as a parachain, it automatically has a bi-directional communication channel with the relay chain. Therefore, there is no need for chain registration. VMP is divided into two kinds of message-passing transport protocols:

    * **Upward Message Passing (UMP)** — allows parachains to send messages to their relay chain, for example, from Moonbeam to Polkadot
    * **Downward Message Passing (DMP)** — allows the relay chain to pass messages down to one of their parachains, for example, from Polkadot to Moonbeam

- **Cross-Chain Message Passing (XCMP)** — allows two parachains to exchange messages as long as they are connected to the same relay chain. Cross-chain transactions are resolved using a simple queuing mechanism based on a Merkle tree to ensure fidelity. Collators exchange messages between parachains, while the relay chain validators will verify that the message transmission happened

!!! note
    Currently, while XCMP is being developed, a stop-gap protocol is implemented called Horizontal Relay-routed Message Passing (HRMP), in which the messages are stored in and read from the relay chain. This will be deprecated in the future for the full XCMP implementation.

![Vertical Message Passing and Cross-chain Message Passing Overview](/images/builders/interoperability/xcm/overview/overview-1.webp)

## Establishing Cross-Chain Communication {: #channel-registration }

Before two chains can start communicating, a messaging channel must be opened. Channels are unidirectional, meaning that a channel from chain A to chain B will only pass messages from A to B. Therefore, two channels must be opened to send messages back and forth.

A channel for XCMs between the relay chain and parachain is automatically opened when a connection is established. However, when parachain A wants to open a communication channel with parachain B, parachain A must send an open channel extrinsic to its network. This extrinsic is an XCM as well!

Even though parachain A has expressed its intentions of opening an XCM channel with parachain B, the latter has not signaled to the relay chain its intentions to receive messages from parachain A. Therefore, to have an established channel, parachain B must send an extrinsic (an XCM) to the relay chain. The accepting channel extrinsic is similar to the previous one. However, the encoded call data only includes the new method (accept channel) and the parachain ID of the sender (parachain A in this example). Once both parachains have agreed, the channel is opened within the following epoch.

To learn more about the channel registration process, please refer to the [How to Establish an XC Integration with Moonbeam](/builders/interoperability/xcm/xc-registration/xc-integration/){target=\_blank} guide.

![XCM Channel Registration Overview](/images/builders/interoperability/xcm/overview/overview-2.webp)

Once the channel is established, cross-chain messages can be sent between parachains. For asset transfers, assets need to be registered before being transferred through XCMs, either by being baked into the runtime as a constant or through a pallet. Moonbeam relies on a Substrate pallet to handle asset registration without the need for runtime upgrades, making the process a lot simpler.

To learn how to register an asset on Moonbeam and the information necessary to add Moonbeam assets to another chain, please refer to the [How to Register Cross-Chain Assets](/builders/interoperability/xcm/xc-registration/assets/){target=\_blank} guide.

## XCM on Moonbeam {: #moonbeam-and-xcm }

As Moonbeam is a parachain within the Polkadot ecosystems, one of the most direct implementations of XCM is to enable asset transfer from Polkadot and other parachains from/to Moonbeam. This allows users to bring their tokens to Moonbeam and all its dApps.

To this end, Moonbeam has introduced [XC-20s](/builders/interoperability/xcm/xc20/overview/){target=\_blank}, which expand on Moonbeam's unique Ethereum compatibility features. XC-20s allow Polkadot native assets to be represented via a standard [ERC-20 interface](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/assets-erc20/ERC20.sol){target=\_blank} through a precompiled contract. When these assets are registered on Moonbeam, they can be set as XCM execution fee assets. Consequently, when a user transfers such an asset to Moonbeam, a small part of the amount will be used to cover the XCM execution fees.

In addition, ERC-20s that are deployed to Moonbeam can be sent to other chains in the Polkadot ecosystem via XCM. Consequently, from a developer's perspective, XC-20s are ERC-20 tokens with the added benefit of being an XCM cross-chain asset, and dApps can easily support them through a familiar ERC-20 interface.

![Moonbeam XC-20 XCM Integration With Polkadot](/images/builders/interoperability/xcm/overview/overview-3.webp)

To send XC-20s across the Polkadot ecosystem from Moonbeam, developers need to use the [Polkadot XCM Pallet](/builders/interoperability/xcm/xc20/send-xc20s/xcm-pallet/){target=\_blank} for transfers via the Substrate API and the [X-Tokens Precompile](/builders/interoperability/xcm/xc20/send-xc20s/xtokens-precompile/){target=\_blank} or the [XCM Precompile](/builders/interoperability/xcm/xc20/send-xc20s/eth-api/){target=\_blank} for transfers via the Ethereum API.

Another unique feature of Moonbeam is the ability to initiate XCM actions from EVM smart contracts or to call its EVM through XCM messages via remote execution. This unlocks a new set of possibilities, where contracts on Moonbeam can access parachain-specific functionalities via XCM, or other parachain ecosystems can use EVM smart contracts on Moonbeam to expand their functions.

The following sections provide a high-level overview of the main use cases mentioned before.

### XCM Transfers between Moonbeam & Polkadot {: #transfers-moonbeam-polkadot }

As Moonbeam is a parachain within the Polkadot ecosystem, a straightforward implementation of XCM + VMP is DOT transfers from/to Polkadot/Moonbeam. To this end, DOT was registered as [_xcDOT_](https://moonscan.io/token/0xffffffff1fcacbd218edc0eba20fc2308c778080){target=\_blank} on Moonbeam.

Alice (Polkadot) wants to transfer a certain amount of DOT from Polkadot to her account on Moonbeam, named Alith. Therefore, she initiates an XCM that expresses her intentions. For such transfers, Moonbeam owns a Sovereign account on Polkadot.

Consequently, the XCM message execution on Polkadot will transfer the amount of DOT to Moonbeam's Sovereign account on Polkadot. Once the assets are deposited, the second part of the message is sent to Moonbeam.

Moonbeam will locally execute the action the XCM message is programmed to do. In this case, it is to mint and transfer the same amount of _xcDOT_ to the account defined by Alice, which in this case is Alith. The fee to execute the XCM in the target parachain is paid in the asset being transferred (_xcDOT_ for this example).

![Transfers from the Relay Chain to Moonbeam](/images/builders/interoperability/xcm/overview/overview-4.webp)

Note the following:

- The Alice and Alith accounts can be different. For example, Polkadot's accounts are SR25519 (or ED25519), while Moonbeam's are ECDSA (Ethereum-styled) accounts. They can also have different owners
- There is a certain degree of trust where one chain relies on the other to execute its part of the XCM message. This is programmed at a runtime level so that it can be easily verified
- For this example, _xcDOT_ is a wrapped representation of the original DOT being held in Moonbeam's Sovereign account on Polkadot. _xcDOT_ can be transferred within Moonbeam at any time, and they can be redeemed for DOT on a 1:1 basis as well (minus some fees)

Alith deposited her _xcDOT_ in a liquidity pool. Next, Charleth acquires some _xcDOT_ by swapping against that liquidity pool, and he wants to transfer some _xcDOT_ to Charley's Polkadot account. Therefore, he initiates an XCM that expresses his intentions.

Consequently, the XCM message execution on Moonbeam will burn the number of _xcDOT_. Once the assets are burned, the second part of the message is sent to Polkadot.

Polkadot will execute the action the XCM message is programmed to do locally. In this case, it is to transfer the same amount of _xcDOT_ burned from the Moonbeam Sovereign account to the account defined by Charleth, which in this case is Charley.

![Transfers Back from Moonbeam to the Relay Chain](/images/builders/interoperability/xcm/overview/overview-5.webp)

### XCM Transfers between Moonbeam & Other Parachains {: #transfers-moonbeam-other-parachains }

Since Moonbeam is a parachain within the Polkadot ecosystem, a straightforward implementation of XCM and XCMP asset transfers from and to Moonbeam and other parachains. This section gives a high-level overview of the main differences compared to XCMs from Polkadot/Moonbeam.

The first requirement is that a bidirectional channel between the parachains must exist, and the asset being transferred must be registered in the target parachain. Only when both conditions are met can XCMs be sent between parachains.

Then, when Alith (Moonbeam) transfers a certain amount of GLMR from Moonbeam to another account (Alice) in a target parachain, tokens are sent to a Sovereign Account owned by that target parachain on Moonbeam.

As the XCM message is executed in the target parachain, it is expected that this will mint and transfer the same amount of _xcGLMR_ (cross-chain GLMR) to the account defined by Alith, which in this case is Alice. The fee to execute the XCM in the target parachain is paid in the transferred asset (_xcGLMR_ for this example).

![Transfers from Moonbeam to another Parachain](/images/builders/interoperability/xcm/overview/overview-6.webp)

As explained in the previous section, the process is similar for _xcGLMR_ to move back to Moonbeam. First, the XCM message execution burns the number of _xcGLMR_ returned to Moonbeam. Once burned, the remnant part of the message is sent to Moonbeam via the relay chain. Moonbeam will locally execute the XCM message's and transfer GLMR (the same amount of burned _xcGLMR_) from the target parachain Sovereign account to the specified address.

### Remote Execution between Other Chains & Moonbeam {: #execution-chains-moonbeam }

As mentioned before, XCM also enables remote execution from/to Moonbeam to other chains in the Polkadot ecosystem.

Similarly to the other use cases, it is necessary for XCM-specific channels to be established before remote execution can happen between the chains. Channels are general-purpose, so they can be used for both asset transfers and remote execution.

Another important component is the asset for which the remote execution fees are paid. On Moonbeam, when an XC-20 is registered, it can be set as an XCM execution fee asset. Consequently, when transferring that XC-20 to Moonbeam, the XCM execution fee is deducted from the amount being transferred. For remote execution, users can include a small amount of tokens in the XCM message to cover XCM execution fees.

Alice (Polkadot) wants to perform a certain remote action through a smart contract on Moonbeam. Therefore, she initiates an XCM that expresses her intentions; she must have previously funded the XCM execution account she owns on Moonbeam with either GLMR or _xcDOT_.

Moonbeam will locally execute the action the XCM message is programmed to do. In this case, it is to withdraw the asset decided by Alice for the XCM execution fee and buy some execution time on Moonbeam to execute the smart contract call on Moonbeam's EVM.

You can read more about the flow in detail on the [Remote Execution](/builders/interoperability/xcm/remote-execution/overview/){target=\_blank} page.
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/builders/interoperability/xcm/remote-execution/overview/
--- BEGIN CONTENT ---
---
title: Remote Execution Overview
description: Learn the basics of remote execution via XCM messages, which allow users to execute actions on other blockchains using accounts they control remotely via XCM.
categories: XCM Remote Execution, Basics
---

# Remote Execution via XCM

## Introduction {: #introduction }

The [Cross-Consensus Message (XCM)](https://wiki.polkadot.com/learn/learn-xcm/){target=\_blank} format defines how messages can be sent between interoperable blockchains. This format opens the door to sending an XCM message that executes an arbitrary set of bytes in a Moonbeam-based network, the relay chain, or other parachains in the Polkadot/Kusama ecosystems.

Remote execution via XCM opens a new set of possibilities for cross-chain interactions, from chains executing actions on other chains to users performing remote actions without switching chains.

This page covers the fundamentals of XCM remote execution. If you want to learn how to perform remote execution via XCM, please refer to the [Remote Execution via the Substrate API](/builders/interoperability/xcm/remote-execution/substrate-calls/xcm-transactor-pallet/){target=\_blank} or the [Remote Execution via the Ethereum API](/builders/interoperability/xcm/xc20/send-xc20s/xtokens-precompile/){target=\_blank} guides.

## Execution Origin {: #execution-origin }

Generally speaking, all transactions have an origin, which is where a call comes from. Ethereum transactions have only one origin type, the `msg.sender`, which is the account that initiated the transaction.

Substrate-based transactions are more complex, as they can have different origins with different privilege levels. This is similar to having an EVM smart contract call with a specific `require` statement in which the call must come from an allowed address. In contrast, these privilege levels are programmed in the Substrate-based runtime itself.

Origins are super important across different components of the Substrate runtime and, hence, the Moonbeam runtime. For example, they define the authority level they inherit in the [on-chain governance implementation](/learn/features/governance/){target=\_blank}.

During the execution of an XCM message, the origin defines the context in which the XCM is being executed. By default, the XCM is executed by the source chain's Sovereign account in the destination chain. This Polkadot-specific property of having remote origins that are calculated when executing XCM is known as [Computed Origins](/builders/interoperability/xcm/remote-execution/computed-origins/){target=\_blank} (formerly known as Multilocation Derivative Accounts).

Depending on the destination chain's configuration, including the `DescendOrigin` XCM instruction can mutate the origin from which the XCM message is executed. This property is significant for remote XCM execution, as the action being executed considers the context of the newly mutated origin and not the source chain's Sovereign account.

## XCM Instructions for Remote Execution {: #xcm-instructions-remote-execution }

The core XCM instructions required to perform remote execution on Moonbeam (as an example) via XCM are the following:

 - [`DescendOrigin`](/builders/interoperability/xcm/core-concepts/instructions/#descend-origin){target=\_blank} - (optional) gets executed in Moonbeam. Mutates the origin to create a new Computed Origin that represents a keyless account controlled via XCM by the sender in the source chain
 - [`WithdrawAsset`](/builders/interoperability/xcm/core-concepts/instructions/#withdraw-asset){target=\_blank} - gets executed in Moonbeam. Takes funds from the Computed Origin
 - [`BuyExecution`](/builders/interoperability/xcm/core-concepts/instructions/#buy-execution){target=\_blank} - gets executed in Moonbeam. Uses the funds taken by the previous XCM instruction to pay for the XCM execution, including the remote call
 - [`Transact`](/builders/interoperability/xcm/core-concepts/instructions/#transact){target=\_blank} - gets executed in Moonbeam. Executes the arbitrary bytes provided in the XCM instruction

The XCM instructions detailed above can be complemented by other XCM instructions to handle certain scenarios, like failure on execution, more accurately. One example is the inclusion of [`SetAppendix`](/builders/interoperability/xcm/core-concepts/instructions/#set-appendix){target=\_blank}, [`RefundSurplus`](/builders/interoperability/xcm/core-concepts/instructions/#refund-surplus){target=\_blank}, and [`Deposit`](/builders/interoperability/xcm/core-concepts/instructions/#deposit-asset){target=\_blank}.

## General Remote Execution via XCM Flow {: #general-remote-execution-via-xcm-flow }

A user initiates a transaction in the source chain through a pallet that builds the XCM with at least the [required XCM instructions for remote execution](#xcm-instructions-remote-execution). The transaction is executed in the source chain, which sends an XCM message with the given instructions to the destination chain.

The XCM message arrives at the destination chain, which executes it. It is executed with the source chain's Sovereign account as a Computed Origin by default. One example that uses this type of origin is when chains open or accept an HRMP channel on the relay chain.

If the XCM message included a [`DescendOrigin`](/builders/interoperability/xcm/core-concepts/instructions/#descend-origin){target=\_blank} instruction, the destination chain may mutate the origin to calculate a new Computed Origin (as is the case with Moonbeam-based networks).

Next, [`WithdrawAsset`](/builders/interoperability/xcm/core-concepts/instructions/#withdraw-asset){target=\_blank} takes funds from the Computed Origin (either a Sovereign account or mutated), which are then used to pay for the XCM execution through the [`BuyExecution`](/builders/interoperability/xcm/core-concepts/instructions/#buy-execution){target=\_blank} XCM instruction. Note that on both instructions, you need to specify which asset you want to use. In addition, you must include the bytes to be executed in the amount of execution to buy.

Lastly, [`Transact`](/builders/interoperability/xcm/core-concepts/instructions/#transact){target=\_blank} executes an arbitrary set of bytes that correspond to a pallet and function in the destination chain. You have to specify the type of origin to use (typically `SovereignAccount`) and the weight required to execute the bytes (similar to gas in the Ethereum realm).

![Diagram of the XCM instructions executed on the destination chain for remote execution.](/images/builders/interoperability/xcm/remote-execution/overview/overview-1.webp)
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/builders/interoperability/xcm/xc20/overview/
--- BEGIN CONTENT ---
---
title: XC-20s and Cross-Chain Assets
description: Learn about the types of cross-chain assets on Moonbeam, in particular, local and external XC-20s, and view a list of the external XC-20s on Moonbeam.
categories: Basics, XC-20
---

# Overview of XC-20s

## Introduction {: #introduction }

The [Cross-Consensus Message (XCM)](https://wiki.polkadot.com/learn/learn-xcm/){target=\_blank} format provides a universal way for blockchains to exchange messages and transfer assets. To extend this interoperability to the EVM, Moonbeam introduced XC-20s, ERC-20 tokens on Moonbeam that are fully compatible with XCM transfers.

Any ERC-20 deployed on Moonbeam can be configured as an XC-20, making it accessible to any chain connected via XCM. This allows EVM-focused developers to work with familiar ERC-20 workflows while benefiting from Polkadot’s native cross-chain functionality, all without needing Substrate-specific expertise.

From a technical standpoint, local XC-20s are ERC-20 tokens originating on Moonbeam (including bridged tokens deemed native once issued on Moonbeam), whereas external XC-20s are wrapped representations of tokens whose canonical ledger exists on another parachain or the relay chain. In all cases, XC-20s function just like standard ERC-20s—supporting common EVM-based use cases (such as DeFi, DEXs, and lending platforms)—but with the added advantage of seamless cross-chain operability.

![Moonbeam XC-20 XCM Integration With Polkadot](/images/builders/interoperability/xcm/overview/overview-3.webp)

This page aims to cover the basics on XC-20s; if you want to learn how to interact with or transfer XC-20s, please refer to the [Send XC-20s guide](/builders/interoperability/xcm/xc20/send-xc20s/overview/){target=\_blank}.

## Types of XC-20s {: #types-of-xc-20s }

There are two types of XC-20s: local and external.

### What are Local XC-20s? {: #local-xc20s }

Local XC-20s are all ERC-20s that exist on the EVM, and that can be transferred cross-chain through XCM. For local XC-20s to be transferred to another parachain, the asset must be registered on that chain. When transferring local XC-20s, the underlying tokens reside in the destination chain's Sovereign account on Moonbeam. A [sovereign account](/builders/interoperability/xcm/core-concepts/sovereign-accounts/){target=\_blank} is a keyless account governed by a blockchain runtime—rather than an individual—that can hold assets and interact with other chains. Local XC-20s must follow [the ERC-20 interface outlined in this guide](/builders/interoperability/xcm/xc20/interact/#the-erc20-interface){target=\_blank}. They must implement the standard ERC-20 function signatures, including the correct function selector of the `transfer` function as described in [EIP-20](https://eips.ethereum.org/EIPS/eip-20){target=\_blank}. However, additional functionality can still be added as long as it doesn’t break the base methods. 

Creating a local XC-20 is equivalent to deploying a standard ERC-20 and enabling cross-chain features on any Moonbeam network.

### What are External XC-20s? {: #external-xc20s }

External XC-20s are cross-chain tokens originating from another parachain or the relay chain, and they are represented on Moonbeam as ERC-20 tokens. The original tokens remain locked in a Moonbeam sovereign account on their home chain, while the wrapped ERC-20 representation can be freely utilized on Moonbeam. When you transfer external XC-20s, the canonical assets remain in the sovereign account on their source chain, while the ERC-20 representation is what circulates on Moonbeam.

External XC-20s all have _xc_ prepended to their names to distinguish them as cross-chain assets. For example, DOT, native to the Polkadot relay chain, is known as xcDOT when represented as an XC-20 on Moonbeam.

### Local XC-20s vs External XC-20s {: #local-xc-20s-vs-external-xc-20s }

Local XC-20s are EVM-native ERC-20 tokens whose “home” (or reserve chain) is Moonbeam from a Polkadot perspective. This includes tokens originally bridged in from outside Polkadot (for example, Wormhole-wrapped ETH), because once they’re issued on Moonbeam as ERC-20s, Polkadot views them as local to Moonbeam. When local XC-20s are transferred to another parachain, the tokens move into that chain’s sovereign account on Moonbeam.

External XC-20s, on the other hand, are ERC-20 representations of tokens whose canonical ledger remains on another parachain or the relay chain. Moonbeam holds the “wrapped” version, while the underlying tokens stay locked in Moonbeam’s sovereign account on the originating chain.

From a cross-chain transfer perspective, local and external XC-20s can be sent through Polkadot’s XCM infrastructure using the Ethereum or Substrate API. Because the underlying asset is an ERC-20 with EVM bytecode following the [EIP-20 token standard](https://eips.ethereum.org/EIPS/eip-20){target=\_blank}, both transfers initiated via the Substrate and Ehereum APIs generate EVM logs visible to EVM-based explorers such as [Moonscan](https://moonscan.io){target=\_blank}. In contrast, you can't send a regular ERC-20 transfer using the Substrate API. Aside from cross-chain transfers through XCM, all other XC-20 interactions (such as querying balances or adjusting allowances) must occur in the EVM.

Cross-chain transfers of XC-20s are executed via the Polkadot XCM Pallet, which utilizes regular mint, burn, and transfer mechanisms of ERC-20s for the XCM asset flow. If you’d like to learn how to send XC-20s using that pallet, refer to the [Using the Polkadot XCM Pallet](/builders/interoperability/xcm/xc20/send-xc20s/xcm-pallet/){target=\_blank} guide.

## Asset Reserves {: #asset-reserves }

When transferring tokens across chains in the Polkadot or Kusama ecosystems, each token has a “reserve” chain that holds its canonical ledger—the source of truth for minting, burning, and supply management. For XC-20s, understanding which chain is the reserve determines whether the asset is managed locally on Moonbeam or remotely on another chain.

Regardless of where the reserve is located, XC-20s on Moonbeam are still ERC-20 tokens that developers and users can interact with in the EVM. However, from an XCM perspective, the reserve chain determines how the tokens are locked, unlocked, minted, or burned behind the scenes when performing cross-chain operations.

### Local Reserve Assets {: #local-reserve-assets }

A local reserve asset on Moonbeam is a token whose canonical ledger—from an XCM perspective—resides natively on Moonbeam. In other words, Moonbeam is the asset’s home chain, where minting and burning take place. 

For example, Wormhole-wrapped ETH (wETH) is considered a local reserve asset on Moonbeam, even though Ethereum is the ultimate source of ETH. Once ETH is wrapped by Wormhole and enters the Polkadot ecosystem via Moonbeam, wETH can be transferred to other parachains through [Moonbeam Routed Liquidity (MRL)](/builders/interoperability/mrl/){target=\_blank}.

The important caveat is that, on a purely Ethereum-level view, ETH remains governed by and minted on Ethereum. However, from an XCM standpoint, wETH on Moonbeam is treated as a local reserve asset, meaning the canonical supply of wETH (as far as Polkadot ecosystems are concerned) exists on Moonbeam.

### Remote Reserve Assets {: #remote-reserve-assets }

A remote reserve asset is a token whose canonical ledger—the source of truth for minting and burning—resides on a chain different from where it’s currently in use. In the case of xcDOT on Moonbeam, the underlying DOT tokens representing the xcDOT remain locked in Moonbeam’s sovereign account on the Polkadot relay chain, while xcDOT functions as a wrapped representation in Moonbeam’s EVM environment.

Users can hold and transact with xcDOT on Moonbeam (for DeFi, governance, and more), knowing that the underlying DOT is safely locked on the relay chain. At any point, the wrapped xcDOT can be redeemed for the original DOT, effectively burning the xcDOT and unlocking the corresponding DOT tokens on Polkadot.

## Current List of External XC-20s {: #current-xc20-assets }

The current list of available external XC-20 assets per network is as follows:

=== "Moonbeam"
    |        Origin         |  Symbol   |                                                            XC-20 Address                                                             |
    |:---------------------:|:---------:|:------------------------------------------------------------------------------------------------------------------------------------:|
    |       Polkadot        |   xcDOT   |  [0xFfFFfFff1FcaCBd218EDc0EbA20Fc2308C778080](https://moonscan.io/token/0xFfFFfFff1FcaCBd218EDc0EbA20Fc2308C778080){target=\_blank}  |
    |         Acala         |  xcaUSD   |  [0xfFfFFFFF52C56A9257bB97f4B2b6F7B2D624ecda](https://moonscan.io/token/0xfFfFFFFF52C56A9257bB97f4B2b6F7B2D624ecda){target=\_blank}  |
    |         Acala         |   xcACA   |  [0xffffFFffa922Fef94566104a6e5A35a4fCDDAA9f](https://moonscan.io/token/0xffffFFffa922Fef94566104a6e5A35a4fCDDAA9f){target=\_blank}  |
    |         Acala         |  xcLDOT   |  [0xFFfFfFffA9cfFfa9834235Fe53f4733F1b8B28d4](https://moonscan.io/token/0xFFfFfFffA9cfFfa9834235Fe53f4733F1b8B28d4){target=\_blank}  |
    |        Apillon        |  xcNCTR   |  [0xFfFFfFfF8A9736B44EbF188972725bED67BF694E](https://moonscan.io/token/0xFfFFfFfF8A9736B44EbF188972725bED67BF694E){target=\_blank}  |
    |         Astar         |  xcASTR   |  [0xFfFFFfffA893AD19e540E172C10d78D4d479B5Cf](https://moonscan.io/token/0xFfFFFfffA893AD19e540E172C10d78D4d479B5Cf){target=\_blank}  |
    |        Bifrost        |   xcBNC   |  [0xFFffffFf7cC06abdF7201b350A1265c62C8601d2](https://moonscan.io/token/0xFFffffFf7cC06abdF7201b350A1265c62C8601d2){target=\_blank}  |
    |        Bifrost        |  xcBNCS   |  [0xfFfffffF6aF229AE7f0F4e0188157e189a487D59](https://moonscan.io/token/0xfFfffffF6aF229AE7f0F4e0188157e189a487D59){target=\_blank}  |
    |        Bifrost        |   xcFIL   |  [0xfFFfFFFF6C57e17D210DF507c82807149fFd70B2](https://moonscan.io/token/0xfFFfFFFF6C57e17D210DF507c82807149fFd70B2){target=\_blank}  |
    |        Bifrost        |  xcvASTR  |  [0xFffFffff55C732C47639231a4C4373245763d26E](https://moonscan.io/token/0xFffFffff55C732C47639231a4C4373245763d26E){target=\_blank}  |
    |        Bifrost        |  xcvBNC   |  [0xffFffFff31d724194b6A76e1d639C8787E16796b](https://moonscan.io/token/0xffFffFff31d724194b6A76e1d639C8787E16796b){target=\_blank}  |
    |        Bifrost        |  xcvDOT   |  [0xFFFfffFf15e1b7E3dF971DD813Bc394deB899aBf](https://moonscan.io/token/0xFFFfffFf15e1b7E3dF971DD813Bc394deB899aBf){target=\_blank}  |
    |        Bifrost        |  xcvFIL   |  [0xFffffFffCd0aD0EA6576B7b285295c85E94cf4c1](https://moonscan.io/token/0xFffffFffCd0aD0EA6576B7b285295c85E94cf4c1){target=\_blank}  |
    |        Bifrost        |  xcvGLMR  |  [0xFfFfFFff99dABE1a8De0EA22bAa6FD48fdE96F6c](https://moonscan.io/token/0xFfFfFFff99dABE1a8De0EA22bAa6FD48fdE96F6c){target=\_blank}  |
    |        Bifrost        | xcvMANTA  |  [0xFFfFFfFfdA2a05FB50e7ae99275F4341AEd43379](https://moonscan.io/token/0xFFfFFfFfdA2a05FB50e7ae99275F4341AEd43379){target=\_blank}  |
    |      Centrifuge       |   xcCFG   |  [0xFFfFfFff44bD9D2FFEE20B25D1Cf9E78Edb6Eae3](https://moonscan.io/token/0xFFfFfFff44bD9D2FFEE20B25D1Cf9E78Edb6Eae3){target=\_blank}  |
    |      Composable       | xcIBCMOVR |  [0xFfFfffFF3AFcd2cAd6174387df17180a0362E592](https://moonscan.io/token/0xFfFfffFF3AFcd2cAd6174387df17180a0362E592){target=\_blank}  |
    |      Composable       | xcIBCPICA |  [0xfFFFFfFFABe9934e61db3b11be4251E6e869cf59](https://moonscan.io/token/0xfFFFFfFFABe9934e61db3b11be4251E6e869cf59){target=\_blank}  |
    |      Composable       | xcIBCIST  |  [0xfFfFffff6A3977d5B65D1044FD744B14D9Cef932](https://moonscan.io/token/0xfFfFffff6A3977d5B65D1044FD744B14D9Cef932){target=\_blank}  |
    |      Composable       | xcIBCBLD  |  [0xFffFffff9664be0234ea4dc64558F695C4f2A9EE](https://moonscan.io/token/0xFffFffff9664be0234ea4dc64558F695C4f2A9EE){target=\_blank}  |
    |      Composable       | xcIBCTIA  |  [0xFFFfFfff644a12F6F01b754987D175F5A780A75B](https://moonscan.io/token/0xFFFfFfff644a12F6F01b754987D175F5A780A75B){target=\_blank}  |
    |      Composable       | xcIBCATOM |  [0xffFFFffF6807D5082ff2f6F86BdE409245e2D953](https://moonscan.io/token/0xffFFFffF6807D5082ff2f6F86BdE409245e2D953){target=\_blank}  |
    |       Darwinia        |  xcRING   |  [0xFfffFfff5e90e365eDcA87fB4c8306Df1E91464f](https://moonscan.io/token/0xFfffFfff5e90e365eDcA87fB4c8306Df1E91464f){target=\_blank}  |
    |          DED          |   xcDED   |  [0xfFffFFFf5da2d7214D268375cf8fb1715705FdC6](https://moonscan.io/token/0xfFffFFFf5da2d7214D268375cf8fb1715705FdC6){target=\_blank}  |
    |      Equilibrium      |   xcEQ    |  [0xFffFFfFf8f6267e040D8a0638C576dfBa4F0F6D6](https://moonscan.io/token/0xFffFFfFf8f6267e040D8a0638C576dfBa4F0F6D6){target=\_blank}  |
    |      Equilibrium      |   xcEQD   |  [0xFFffFfFF8cdA1707bAF23834d211B08726B1E499](https://moonscan.io/token/0xFFffFfFF8cdA1707bAF23834d211B08726B1E499){target=\_blank}  |
    |        HydraDX        |   xcHDX   |  [0xFFFfFfff345Dc44DDAE98Df024Eb494321E73FcC](https://moonscan.io/token/0xFFFfFfff345Dc44DDAE98Df024Eb494321E73FcC){target=\_blank}  |
    |       Interlay        |  xcIBTC   |  [0xFFFFFfFf5AC1f9A51A93F5C527385edF7Fe98A52](https://moonscan.io/token/0xFFFFFfFf5AC1f9A51A93F5C527385edF7Fe98A52){target=\_blank}  |
    |       Interlay        |  xcINTR   |  [0xFffFFFFF4C1cbCd97597339702436d4F18a375Ab](https://moonscan.io/token/0xFffFFFFF4C1cbCd97597339702436d4F18a375Ab){target=\_blank}  |
    |         Manta         |  xcMANTA  |  [0xfFFffFFf7D3875460d4509eb8d0362c611B4E841](https://moonscan.io/token/0xfFFffFFf7D3875460d4509eb8d0362c611B4E841){target=\_blank}  |
    |         Nodle         |  xcNODL   |  [0xfffffffFe896ba7Cb118b9Fa571c6dC0a99dEfF1](https://moonscan.io/token/0xfffffffFe896ba7Cb118b9Fa571c6dC0a99dEfF1){target=\_blank}  |
    | OriginTrail Parachain |  xcNEURO  |  [0xFfffffFfB3229c8E7657eABEA704d5e75246e544](https://moonscan.io/token/0xFfffffFfB3229c8E7657eABEA704d5e75246e544){target=\_blank}  |
    |       Parallel        |  xcPARA   |  [0xFfFffFFF18898CB5Fe1E88E668152B4f4052A947](https://moonscan.io/token/0xFfFffFFF18898CB5Fe1E88E668152B4f4052A947){target=\_blank}  |
    |         Peaq          |  xcPEAQ   |  [0xFffFFFFFEC4908b74688a01374f789B48E9a3eab](https://moonscan.io/token/0xFffFFFFFEC4908b74688a01374f789B48E9a3eab){target=\_blank}  |
    |       Pendulum        |   xcPEN   |  [0xffFFfFFf2257622F345E1ACDe0D4f46D7d1D77D0](https://moonscan.io/token/0xffFFfFFf2257622F345E1ACDe0D4f46D7d1D77D0){target=\_blank}  |
    |         Phala         |   xcPHA   |  [0xFFFfFfFf63d24eCc8eB8a7b5D0803e900F7b6cED](https://moonscan.io/token/0xFFFfFfFf63d24eCc8eB8a7b5D0803e900F7b6cED){target=\_blank}  |
    |       Polkadex        |  xcPDEX   |  [0xfFffFFFF43e0d9b84010b1b67bA501bc81e33C7A](https://moonscan.io/token/0xfFffFFFF43e0d9b84010b1b67bA501bc81e33C7A){target=\_blank}  |
    |  Polkadot Asset Hub   |  xcPINK   |  [0xfFfFFfFf30478fAFBE935e466da114E14fB3563d](https://moonscan.io/token/0xfFfFFfFf30478fAFBE935e466da114E14fB3563d){target=\_blank}  |
    |  Polkadot Asset Hub   |  xcSTINK  |  [0xFffFffFf54c556bD1d0F64ec6c78f1B477525E56](https://moonscan.io/token/0xFffFffFf54c556bD1d0F64ec6c78f1B477525E56){target=\_blank}  |
    |  Polkadot Asset Hub   |  xcUSDC   |  [0xFFfffffF7D2B0B761Af01Ca8e25242976ac0aD7D](https://moonscan.io/token/0xFFfffffF7D2B0B761Af01Ca8e25242976ac0aD7D){target=\_blank}  |
    |  Polkadot Asset Hub   |  xcUSDT   |  [0xFFFFFFfFea09FB06d082fd1275CD48b191cbCD1d](https://moonscan.io/token/0xFFFFFFfFea09FB06d082fd1275CD48b191cbCD1d){target=\_blank}  |
    |  Polkadot Asset Hub   |  xcWIFD   |  [0xfffffffF2e1D1ac9eA1686255bEfe995B31abc96](https://moonscan.io/token/0xfffffffF2e1D1ac9eA1686255bEfe995B31abc96){target=\_blank}  |
    |      Snowbridge       |  WBTC.e   | [0xfFffFFFf1B4Bb1ac5749F73D866FfC91a3432c47](https://moonscan.io/address/0xffffffff1B4BB1AC5749F73D866FFC91A3432C47){target=\_blank} |
    |      Snowbridge       | wstETH.e  |  [0xFfFFFfFF5D5DEB44BF7278DEE5381BEB24CB6573](https://moonscan.io/token/0xFfFFFfFF5D5DEB44BF7278DEE5381BEB24CB6573){target=\_blank}  |
    |      Snowbridge       |  WETH.e   |  [0xfFffFFFF86829AFE1521AD2296719DF3ACE8DED7](https://moonscan.io/token/0xfFffFFFF86829AFE1521AD2296719DF3ACE8DED7){target=\_blank}  |
    |       Subsocial       |   xcSUB   |  [0xfFfFffFf43B4560Bc0C451a3386E082bff50aC90](https://moonscan.io/token/0xfFfFffFf43B4560Bc0C451a3386E082bff50aC90){target=\_blank}  |
    |        Unique         |   xcUNQ   |  [0xFffffFFFD58f77E6693CFB99EbE273d73C678DC2](https://moonscan.io/token/0xFffffFFFD58f77E6693CFB99EbE273d73C678DC2){target=\_blank}  |
    |       Zeitgeist       |   xcZTG   |  [0xFFFFfffF71815ab6142E0E20c7259126C6B40612](https://moonscan.io/token/0xFFFFfffF71815ab6142E0E20c7259126C6B40612){target=\_blank}  |

     _*You can check each [Asset ID](https://polkadot.js.org/apps/?rpc=wss://wss.api.moonbeam.network#/assets){target=\_blank} on Polkadot.js Apps_

=== "Moonriver"
    |      Origin      | Symbol  |                                                                XC-20 Address                                                                 |
    |:----------------:|:-------:|:--------------------------------------------------------------------------------------------------------------------------------------------:|
    |      Kusama      |  xcKSM  | [0xFfFFfFff1FcaCBd218EDc0EbA20Fc2308C778080](https://moonriver.moonscan.io/token/0xffffffff1fcacbd218edc0eba20fc2308c778080){target=\_blank} |
    |     Bifrost      |  xcBNC  | [0xFFfFFfFFF075423be54811EcB478e911F22dDe7D](https://moonriver.moonscan.io/token/0xFFfFFfFFF075423be54811EcB478e911F22dDe7D){target=\_blank} |
    |     Bifrost      | xcvBNC  | [0xFFffffff3646A00f78caDf8883c5A2791BfCDdc4](https://moonriver.moonscan.io/token/0xFFffffff3646A00f78caDf8883c5A2791BfCDdc4){target=\_blank} |
    |     Bifrost      | xcvKSM  | [0xFFffffFFC6DEec7Fc8B11A2C8ddE9a59F8c62EFe](https://moonriver.moonscan.io/token/0xFFffffFFC6DEec7Fc8B11A2C8ddE9a59F8c62EFe){target=\_blank} |
    |     Bifrost      | xcvMOVR | [0xfFfffFfF98e37bF6a393504b5aDC5B53B4D0ba11](https://moonriver.moonscan.io/token/0xfFfffFfF98e37bF6a393504b5aDC5B53B4D0ba11){target=\_blank} |
    |     Calamari     |  xcKMA  | [0xffffffffA083189F870640B141AE1E882C2B5BAD](https://moonriver.moonscan.io/token/0xffffffffA083189F870640B141AE1E882C2B5BAD){target=\_blank} |
    |       Crab       | xcCRAB  | [0xFFFffFfF8283448b3cB519Ca4732F2ddDC6A6165](https://moonriver.moonscan.io/token/0xFFFffFfF8283448b3cB519Ca4732F2ddDC6A6165){target=\_blank} |
    |   Crust-Shadow   |  xcCSM  | [0xffFfFFFf519811215E05eFA24830Eebe9c43aCD7](https://moonriver.moonscan.io/token/0xffFfFFFf519811215E05eFA24830Eebe9c43aCD7){target=\_blank} |
    |      Heiko       |  xcHKO  | [0xffffffFF394054BCDa1902B6A6436840435655a3](https://moonriver.moonscan.io/token/0xffffffFF394054BCDa1902B6A6436840435655a3){target=\_blank} |
    |    Integritee    | xcTEER  | [0xFfFfffFf4F0CD46769550E5938F6beE2F5d4ef1e](https://moonriver.moonscan.io/token/0xFfFfffFf4F0CD46769550E5938F6beE2F5d4ef1e){target=\_blank} |
    |      Karura      |  xcKAR  | [0xFfFFFFfF08220AD2E6e157f26eD8bD22A336A0A5](https://moonriver.moonscan.io/token/0xFfFFFFfF08220AD2E6e157f26eD8bD22A336A0A5){target=\_blank} |
    |      Karura      | xcaSEED | [0xFfFffFFfa1B026a00FbAA67c86D5d1d5BF8D8228](https://moonriver.moonscan.io/token/0xFfFffFFfa1B026a00FbAA67c86D5d1d5BF8D8228){target=\_blank} |
    |      Khala       |  xcPHA  | [0xffFfFFff8E6b63d9e447B6d4C45BDA8AF9dc9603](https://moonriver.moonscan.io/token/0xffFfFFff8E6b63d9e447B6d4C45BDA8AF9dc9603){target=\_blank} |
    |     Kintsugi     | xcKINT  | [0xfffFFFFF83F4f317d3cbF6EC6250AeC3697b3fF2](https://moonriver.moonscan.io/token/0xfffFFFFF83F4f317d3cbF6EC6250AeC3697b3fF2){target=\_blank} |
    |     Kintsugi     | xckBTC  | [0xFFFfFfFfF6E528AD57184579beeE00c5d5e646F0](https://moonriver.moonscan.io/token/0xFFFfFfFfF6E528AD57184579beeE00c5d5e646F0){target=\_blank} |
    | Kusama Asset Hub | xcRMRK  | [0xffffffFF893264794d9d57E1E0E21E0042aF5A0A](https://moonriver.moonscan.io/token/0xffffffFF893264794d9d57E1E0E21E0042aF5A0A){target=\_blank} |
    | Kusama Asset Hub | xcUSDT  | [0xFFFFFFfFea09FB06d082fd1275CD48b191cbCD1d](https://moonriver.moonscan.io/token/0xFFFFFFfFea09FB06d082fd1275CD48b191cbCD1d){target=\_blank} |
    |      Litmus      |  xcLIT  | [0xfffFFfFF31103d490325BB0a8E40eF62e2F614C0](https://moonriver.moonscan.io/token/0xfffFFfFF31103d490325BB0a8E40eF62e2F614C0){target=\_blank} |
    |     Mangata      |  xcMGX  | [0xffFfFffF58d867EEa1Ce5126A4769542116324e9](https://moonriver.moonscan.io/token/0xffFfFffF58d867EEa1Ce5126A4769542116324e9){target=\_blank} |
    |     Picasso      | xcPICA  | [0xFffFfFFf7dD9B9C60ac83e49D7E3E1f7A1370aD2](https://moonriver.moonscan.io/token/0xFffFfFFf7dD9B9C60ac83e49D7E3E1f7A1370aD2){target=\_blank} |
    |    Robonomics    |  xcXRT  | [0xFffFFffF51470Dca3dbe535bD2880a9CcDBc6Bd9](https://moonriver.moonscan.io/token/0xFffFFffF51470Dca3dbe535bD2880a9CcDBc6Bd9){target=\_blank} |
    |      Shiden      |  xcSDN  | [0xFFFfffFF0Ca324C842330521525E7De111F38972](https://moonriver.moonscan.io/token/0xFFFfffFF0Ca324C842330521525E7De111F38972){target=\_blank} |
    |    Tinkernet     | xcTNKR  | [0xfFFfFffF683474B842852111cc31d470bD8f5081](https://moonriver.moonscan.io/token/0xffffffff683474b842852111cc31d470bd8f5081){target=\_blank} |
    |      Turing      |  xcTUR  | [0xfFffffFf6448d0746f2a66342B67ef9CAf89478E](https://moonriver.moonscan.io/token/0xfFffffFf6448d0746f2a66342B67ef9CAf89478E){target=\_blank} |

    _*You can check each [Asset ID](https://polkadot.js.org/apps/?rpc=wss://wss.api.moonriver.moonbeam.network#/assets){target=\_blank} on Polkadot.js Apps_

=== "Moonbase Alpha"
    |        Origin        | Symbol |                                                                XC-20 Address                                                                |
    |:--------------------:|:------:|:-------------------------------------------------------------------------------------------------------------------------------------------:|
    | Relay Chain Alphanet | xcUNIT | [0xFfFFfFff1FcaCBd218EDc0EbA20Fc2308C778080](https://moonbase.moonscan.io/token/0xFfFFfFff1FcaCBd218EDc0EbA20Fc2308C778080){target=\_blank} |

     _*You can check each [Asset ID](https://polkadot.js.org/apps/?rpc=wss://wss.api.moonbase.moonbeam.network#/assets){target=\_blank} on Polkadot.js Apps_

### Retrieve List of External XC-20s and Their Metadata {: #list-xchain-assets }

To fetch a list of the currently available external XC-20s along with their associated metadata, you can query the chain state using the [Polkadot.js API](/builders/substrate/libraries/polkadot-js-api/){target=\_blank}. You'll take the following steps:

1. Create an API provider for the network you'd like to get the list of assets for. You can use the following WSS endpoints for each network:

    === "Moonbeam"

        ```text
        wss://wss.api.moonbeam.network
        ```

    === "Moonriver"

        ```text
        wss://wss.api.moonriver.moonbeam.network
        ```

    === "Moonbase Alpha"

        ```text
        {{ networks.moonbase.wss_url }}
        ```

2. Query the `assets` pallet for all assets
3. Iterate over the list of assets to get all of the asset IDs along with their associated metadata

```js
import { ApiPromise, WsProvider } from '@polkadot/api';

const getXc20s = async () => {
  try {
    const substrateProvider = new WsProvider('INSERT_WSS_ENDPOINT');
    const api = await ApiPromise.create({ provider: substrateProvider });

    const assets = await api.query.assets.asset.entries();

    await Promise.all(
      assets.map(async ([{ args: [id] }]) => {
        try {
          const metadata = await api.query.assets.metadata(id);
          const humanMetadata = metadata.toHuman();
          
          console.log(`\nAsset ID: ${id}`);
          console.log('Metadata:');
          console.log('  Name:', humanMetadata.name);
          console.log('  Symbol:', humanMetadata.symbol);
          console.log('  Decimals:', humanMetadata.decimals);
          console.log('  Deposit:', humanMetadata.deposit);
          console.log('  IsFrozen:', humanMetadata.isFrozen);
          console.log('-----');
        } catch (error) {
          console.error(`Error fetching metadata for asset ${id}:`, error);
        }
      })
    );

    await api.disconnect();
  } catch (error) {
    console.error('Error in getXc20s:', error);
  }
};

getXc20s().catch(console.error);
```

The result will display the asset ID along with some additional information for all of the registered external XC-20s.

## Retrieve Local XC-20 Metadata {: #retrieve-local-xc20-metadata }

Since local XC-20s are ERC-20s on Moonbeam that can be transferred via XCM to another parachain, you can interact with local XC-20s like you would an ERC-20. As long as you have the address and the ABI of the ERC-20, you can retrieve its metadata by interacting with its ERC-20 interface to retrieve the name, symbol, and decimals for the asset.

The following is an example that retrieves the asset metadata for the [Jupiter token](https://moonbase.moonscan.io/token/0x9aac6fb41773af877a2be73c99897f3ddfacf576){target=\_blank} on Moonbase Alpha:

=== "Ethers.js"

    ```js
    import { ethers } from 'ethers';

const providerRPC = {
  moonbase: {
    name: 'moonbase',
    rpc: 'https://rpc.api.moonbase.moonbeam.network', // Insert your RPC URL here
    chainId: 1287, // 0x507 in hex,
  },
};

const provider = new ethers.JsonRpcProvider(providerRPC.moonbase.rpc, {
  chainId: providerRPC.moonbase.chainId,
  name: providerRPC.moonbase.name,
});

// Replace with the address of the ERC-20 token
const tokenAddress = '0x9Aac6FB41773af877a2Be73c99897F3DdFACf576';
const tokenABI = [
  'function name() view returns (string)',
  'function symbol() view returns (string)',
  'function decimals() view returns (uint8)',
];

const tokenContract = new ethers.Contract(tokenAddress, tokenABI, provider);
async function getTokenMetadata() {
  try {
    const [name, symbol, decimals] = await Promise.all([
      tokenContract.name(),
      tokenContract.symbol(),
      tokenContract.decimals(),
    ]);
    console.log(`Name: ${name}`);
    console.log(`Symbol: ${symbol}`);
    console.log(`Decimals: ${decimals}`);
  } catch (error) {
    console.error('Error fetching token metadata:', error);
  }
}
getTokenMetadata();
    ```

=== "Web3.js"

    ```js
    import { Web3 } from 'web3';

// Insert your RPC URL here
const web3 = new Web3('https://rpc.api.moonbase.moonbeam.network');

// Replace with the address of the ERC-20 token
const tokenAddress = '0x9Aac6FB41773af877a2Be73c99897F3DdFACf576';
const tokenABI = [
  // ERC-20 ABI
  {
    constant: true,
    inputs: [],
    name: 'name',
    outputs: [{ name: '', type: 'string' }],
    payable: false,
    stateMutability: 'view',
    type: 'function',
  },
  {
    constant: true,
    inputs: [],
    name: 'symbol',
    outputs: [{ name: '', type: 'string' }],
    payable: false,
    stateMutability: 'view',
    type: 'function',
  },
  {
    constant: true,
    inputs: [],
    name: 'decimals',
    outputs: [{ name: '', type: 'uint8' }],
    payable: false,
    stateMutability: 'view',
    type: 'function',
  },
];
const tokenContract = new web3.eth.Contract(tokenABI, tokenAddress);
async function getTokenMetadata() {
  try {
    const [name, symbol, decimals] = await Promise.all([
      tokenContract.methods.name().call(),
      tokenContract.methods.symbol().call(),
      tokenContract.methods.decimals().call(),
    ]);
    console.log(`Name: ${name}`);
    console.log(`Symbol: ${symbol}`);
    console.log(`Decimals: ${decimals}`);
  } catch (error) {
    console.error('Error fetching token metadata:', error);
  }
}
getTokenMetadata();
    ```

=== "Web3.py"

    ```py
    from web3 import Web3

web3 = Web3(Web3.HTTPProvider("https://rpc.api.moonbase.moonbeam.network"))

# Replace with the address of the ERC-20 token
token_address = "0x9Aac6FB41773af877a2Be73c99897F3DdFACf576"
token_abi = [  # ERC-20 ABI
    {
        "constant": True,
        "inputs": [],
        "name": "name",
        "outputs": [{"name": "", "type": "string"}],
        "payable": False,
        "stateMutability": "view",
        "type": "function",
    },
    {
        "constant": True,
        "inputs": [],
        "name": "symbol",
        "outputs": [{"name": "", "type": "string"}],
        "payable": False,
        "stateMutability": "view",
        "type": "function",
    },
    {
        "constant": True,
        "inputs": [],
        "name": "decimals",
        "outputs": [{"name": "", "type": "uint8"}],
        "payable": False,
        "stateMutability": "view",
        "type": "function",
    },
]
token_contract = web3.eth.contract(address=token_address, abi=token_abi)


def get_token_metadata():
    try:
        name = token_contract.functions.name().call()
        symbol = token_contract.functions.symbol().call()
        decimals = token_contract.functions.decimals().call()
        print(f"Name: {name}")
        print(f"Symbol: {symbol}")
        print(f"Decimals: {decimals}")
    except Exception as e:
        print(f"Error fetching token metadata: {e}")


get_token_metadata()
    ```
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/builders/interoperability/xcm/xc20/send-xc20s/overview/
--- BEGIN CONTENT ---
---
title: XC-20 Transfers Overview
description: Explore the types of asset transfers and some of the fundamentals of remote asset transfers via XCM, including the XCM instructions for asset transfers.
categories: Basics, XC-20
---

# Overview of XC-20 Transfers

## Introduction {: #introduction }

Assets can move between parachains using XCM. Two main approaches exist:

- **Asset teleporting** – destroys tokens on the reserve chain and mints the same amount on the destination chain. Each chain holds the native asset as a reserve, similar to a burn-mint bridging mechanism. Because each chain can create tokens, a degree of trust is required
- **Remote transfers** – moves tokens from the reserve chain to a Sovereign account (an account on the reserve chain trustlessly controlled by the destination chain). The destination chain then mints a wrapped (also called “virtual” or “cross-chain”) representation. This wrapped version is always interchangeable 1:1 with the original asset, functioning like a lock-mint and burn-unlock bridge. The chain where the asset originates is known as the reserve chain

![Asset Teleporting and Remote Transfers](/images/builders/interoperability/xcm/xc20/send-xc20s/overview/overview-1.webp)

Moonbeam currently uses remote transfers for XC-20 transfers.

This page covers the fundamentals of XCM-based remote transfers. To learn how to perform XC-20 transfers, refer to the the [XC-20 transfers via the Substrate API](/builders/interoperability/xcm/xc20/send-xc20s/xcm-pallet/){target=\_blank} guide.

## XCM Instructions for Asset Transfers {: #xcm-instructions-for-asset-transfers }

The XCM Pallet and Precompile abstract much of the complexity involved in cross-chain asset transfers, automatically constructing the necessary XCM messages. Nevertheless, having a basic understanding of the underlying instructions can be useful. 

For reference, you can find the Polkadot XCM Pallet extrinsics for sending XC-20s in the [Using the Polkadot XCM Pallet To Send XC-20s guide](/builders/interoperability/xcm/xc20/send-xc20s/xcm-pallet/){target=_blank}.

The instructions in each XCM transfer vary depending on the asset and the transfer route. For example, returning a native token like xcDOT to its reserve chain (from Moonbeam to Polkadot) differs from sending DOT from Polkadot to Moonbeam. Below are examples of the instructions commonly involved in these token transfers.

### Instructions to Transfer a Reserve Asset from the Reserve Chain {: #transfer-native-from-origin }

When DOT is transferred from Polkadot to Moonbeam, the following XCM instructions are executed in sequence:

1. [`TransferReserveAsset`](/builders/interoperability/xcm/core-concepts/instructions/#transfer-reserve-asset){target=_blank} - executes on Polkadot, moving the DOT from the sender and depositing it into Moonbeam’s Sovereign account on Polkadot

2. [`ReserveAssetDeposited`](/builders/interoperability/xcm/core-concepts/instructions/#reserve-asset-deposited){target=_blank} - executes on Moonbeam, minting the corresponding ERC-20 representation of DOT (xcDOT) on Moonbeam

3. [`ClearOrigin`](/builders/interoperability/xcm/core-concepts/instructions/#clear-origin){target=_blank} - executes on Moonbeam, clearing any origin data—previously set to Polkadot’s Sovereign account

4. [`BuyExecution`](/builders/interoperability/xcm/core-concepts/instructions/#buy-execution){target=_blank} - executes on Moonbeam, determining the execution fees. Here, a portion of the newly minted xcDOT is used to pay the cost of XCM

5. [`DepositAsset`](/builders/interoperability/xcm/core-concepts/instructions/#deposit-asset){target=_blank} - executes on Moonbeam, delivering the xcDOT to the intended recipient’s account on Moonbeam

This process invokes `TransferReserveAsset` with `assets`, `dest`, and `xcm`parameters. Within the `xcm` parameter, you typically specify the `BuyExecution` and `DepositAsset` instructions. As shown in the [`TransferReserveAsset` instruction](https://github.com/paritytech/polkadot-sdk/blob/{{ polkadot_sdk }}/polkadot/xcm/xcm-executor/src/lib.rs#L630){target=\_blank}, the flow also includes `ReserveAssetDeposited` and `ClearOrigin` to complete the transfer.

For more information on constructing an XCM message for asset transfers, such as DOT to Moonbeam, refer to the [Polkadot XCM Pallet guide](/builders/interoperability/xcm/xc20/send-xc20s/xcm-pallet/){target=\_blank}.

### Instructions to Transfer a Reserve Asset back to the Reserve Chain {: #transfer-native-to-origin }

In scenarios where you want to move an asset back to its reserve chain, such as sending xcDOT from Moonbeam to Polkadot, Moonbeam uses the following set of XCM instructions:

1. [`WithdrawAsset`](/builders/interoperability/xcm/core-concepts/instructions/#withdraw-asset){target=_blank} – executes on Moonbeam, taking the specified token (xcDOT) from the sender

2. [`InitiateReserveWithdraw`](/builders/interoperability/xcm/core-concepts/instructions/#initiate-reserve-withdraw){target=_blank} – executes on Moonbeam, which, burns the token on Moonbeam (removing the wrapped representation), and sends an XCM message to Polkadot, indicating the tokens should be released there 

3. [`WithdrawAsset`](/builders/interoperability/xcm/core-concepts/instructions/#withdraw-asset){target=_blank} – executes on Polkadot, removing the tokens from Moonbeam’s Sovereign account on Polkadot

4. [`ClearOrigin`](/builders/interoperability/xcm/core-concepts/instructions/#clear-origin){target=_blank} – gets executed on Polkadot. Clears any origin data (e.g., the Sovereign account on Moonbeam)

5. [`BuyExecution`](/builders/interoperability/xcm/core-concepts/instructions/#buy-execution){target=_blank} – Polkadot determines the execution fees and uses part of the DOT being transferred to pay for them

6. [`DepositAsset`](/builders/interoperability/xcm/core-concepts/instructions/#deposit-asset){target=_blank} – finally, the native DOT tokens are deposited into the specified Polkadot account

Steps 3 through 6 are automatically triggered by the `InitiateReserveWithdraw` instruction (step 2) and execute on Polkadot. Once `InitiateReserveWithdraw` is invoked on Moonbeam, the assembled XCM message instructs Polkadot to run those final instructions, completing the cross-chain transfer. In other words, while Moonbeam constructs the XCM instructions behind the scenes, they ultimately execute on Polkadot to complete the asset’s return to its reserve chain.

For more information on constructing an XCM message to transfer reserve assets to a target chain, such as xcDOT to Polkadot, you refer to the guide to the [Polkadot XCM Pallet](/builders/interoperability/xcm/xc20/send-xc20s/xcm-pallet/){target=_blank}.

!!! note
	The specific instructions may vary over time, but this overall flow remains consistent: the tokens are withdrawn from the user on Moonbeam, burned from the local representation, and unlocked on the reserve chain. At the end of the process, they become fully accessible again on their reserve chain.
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/node-operators/networks/collators/overview/
--- BEGIN CONTENT ---
---
title: Run a Collator Node
description: Instructions on how to dive in and become a collator in the Moonbeam Network once you are running a node.
categories: Basics, Node Operators and Collators
---

# Run a Collator on Moonbeam

## Introduction {: #introduction }

Collators are members of the network that maintain the parachains they take part in. They run a full node (for both their particular parachain and the relay chain), and they produce the state transition proof for relay chain validators.

There are some [requirements](/node-operators/networks/collators/requirements/){target=\_blank} that need to be considered prior to becoming a collator candidate including machine, bonding, account, and community requirements.

Candidates will need a minimum amount of tokens bonded (self-bonded) to be considered eligible. Only a certain number of the top collator candidates by total stake, including self-bonded and delegated stake, will be in the active set of collators. Otherwise, the collator will remain in the candidate pool.

Once a candidate is selected to be in the active set of collators, they are eligible to produce blocks.

Moonbeam uses the [Nimbus Parachain Consensus Framework](/learn/features/consensus/){target=\_blank}. This provides a two-step filter to allocate candidates to the active set of collators, then assign collators to a block production slot:

 - The parachain staking filter selects the top candidates in terms of tokens staked in each network. For the exact number of top candidates per each network and the minimum bond amount, you can check out the [Minimum Collator Bond](/node-operators/networks/collators/requirements/#minimum-collator-bond){target=\_blank} section of our documentation. This filtered pool is called selected candidates (also known as the active set), which are rotated every round
 - The fixed size subset filter picks a pseudo-random subset of the previously selected candidates for each block production slot

Users can spin up full nodes on Moonbeam, Moonriver, and Moonbase Alpha and activate the `collate` feature to participate in the ecosystem as collator candidates. To do this, you can checkout the [Run a Node](/node-operators/networks/run-a-node/){target=\_blank} section of the documentation and spin up a node using either [Docker](/node-operators/networks/run-a-node/docker/){target=\_blank} or [Systemd](/node-operators/networks/run-a-node/systemd/){target=\_blank}.

## Join the Discord {: #join-discord }

As a collator, it is important to keep track of updates and changes to configuration. It is also important to be able to easily contact us and vice versa in case there is any issue with your node, as that will not only negatively affect collator and delegator rewards, it will also negatively affect the network.

For this purpose, we use [Discord](https://discord.com/invite/moonbeam){target=\_blank}. The most relevant Discord channels for collators are the following:

 - **tech-upgrades-announcements** — here we will publish any updates or changes in configuration changes collators will be required to follow. We will also announce any technical issues to monitor, such as network stalls
 - **collators** — this is the general collator discussion channel. We are proud of having an active and friendly collator community so if you have any questions, this is the place to ask. We will also ping collators here for any issues that require their attention.
 - **meet-the-collators** — in this channel you can introduce yourself to potential delegators

After you join our Discord, feel free to DM *gilmouta* or *artkaseman* and introduce yourself. This will let us know who to contact if we see an issue with your node, and will also let us assign the relevant Discord collator role, enabling you to post in *meet-the-collators*.
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/node-operators/networks/run-a-node/overview/
--- BEGIN CONTENT ---
---
title: Run a Node
description: Learn about all of the necessary details to run a full parachain node for the Moonbeam Network to have your RPC endpoint or produce blocks.
categories: Basics, Node Operators and Collators
---

# Run a Node on Moonbeam

## Introduction {: #introduction }

Running a full node on a Moonbeam-based network allows you to connect to the network, sync with a bootnode, obtain local access to RPC endpoints, author blocks on the parachain, and more.

There are multiple deployments of Moonbeam, including the Moonbase Alpha TestNet, Moonriver on Kusama, and Moonbeam on Polkadot. Here's how these environments are named and their corresponding [chain specification file](https://docs.polkadot.com/develop/parachains/deployment/generate-chain-specs/) names:

|    Network     |      Hosted By      |             Chain Name              |
|:--------------:|:-------------------:|:-----------------------------------:|
| Moonbase Alpha | Moonbeam Foundation | {{ networks.moonbase.chain_spec }}  |
|   Moonriver    |       Kusama        | {{ networks.moonriver.chain_spec }} |
|    Moonbeam    |      Polkadot       | {{ networks.moonbeam.chain_spec }}  |

!!! note
    Moonbase Alpha is still considered an Alphanet, and as such _will not_ have 100% uptime. The parachain might be purged as needed. During the development of your application, make sure you implement a method to redeploy your contracts and accounts to a fresh parachain quickly. If a chain purge is required, it will be announced via our [Discord channel](https://discord.com/invite/PfpUATX) at least 24 hours in advance.

## Requirements {: #requirements }

Running a parachain node is similar to a typical Substrate node, but there are some differences. A Substrate parachain node is a bigger build because it contains code to run the parachain itself, as well as code to sync the relay chain and facilitate communication between the two. As such, this build is quite large and may take over 30 min and require 32GB of memory.

The minimum specs recommended to run a node are shown in the following table. For our Kusama and Polkadot MainNet deployments, disk requirements will be higher as the network grows.

=== "Moonbeam"
    |  Component   |                                                        Requirement                                                         |
    |:------------:|:--------------------------------------------------------------------------------------------------------------------------:|
    |   **CPU**    |                             {{ networks.moonbeam.node.cores }} Cores (Fastest per core speed)                              |
    |   **RAM**    |                                            {{ networks.moonbeam.node.ram }} GB                                             |
    |   **SSD**    |                                      {{ networks.moonbeam.node.hd }} TB (recommended)                                      |
    | **Firewall** | P2P port must be open to incoming traffic:<br>&nbsp; &nbsp; - Source: Any<br>&nbsp; &nbsp; - Destination: 30333, 30334 TCP |

=== "Moonriver"
    |  Component   |                                                        Requirement                                                         |
    |:------------:|:--------------------------------------------------------------------------------------------------------------------------:|
    |   **CPU**    |                             {{ networks.moonriver.node.cores }} Cores (Fastest per core speed)                             |
    |   **RAM**    |                                            {{ networks.moonriver.node.ram }} GB                                            |
    |   **SSD**    |                                     {{ networks.moonriver.node.hd }} TB (recommended)                                      |
    | **Firewall** | P2P port must be open to incoming traffic:<br>&nbsp; &nbsp; - Source: Any<br>&nbsp; &nbsp; - Destination: 30333, 30334 TCP |

=== "Moonbase Alpha"
    |  Component   |                                                        Requirement                                                         |
    |:------------:|:--------------------------------------------------------------------------------------------------------------------------:|
    |   **CPU**    |                             {{ networks.moonbase.node.cores }} Cores (Fastest per core speed)                              |
    |   **RAM**    |                                            {{ networks.moonbase.node.ram }} GB                                             |
    |   **SSD**    |                                      {{ networks.moonbase.node.hd }} TB (recommended)                                      |
    | **Firewall** | P2P port must be open to incoming traffic:<br>&nbsp; &nbsp; - Source: Any<br>&nbsp; &nbsp; - Destination: 30333, 30334 TCP |

!!! note
    If you don't see an `Imported` message (without the `[Relaychain]` tag) when running a node, you might need to double-check your port configuration.

## Running Ports {: #running-ports }

As stated before, the relay/parachain nodes will listen on multiple ports. The default Substrate ports are used in the parachain, while the relay chain will listen on the next higher port.

The only ports that need to be open for incoming traffic are those designated for P2P. **Collators must not have RPC or WS ports opened**.

!!! note
    As of client v0.33.0, the `--ws-port` and `--ws-max-connections` flags have been deprecated and removed in favor of the `--rpc-port` and `--rpc-max-connections` flags for both RPC and WSS connections. The default port is `9944`, and the default maximum number of connections is set to 100.

### Default Ports for a Parachain Full-Node {: #default-ports-for-a-parachain-full-node }

|  Description   |                Port                 |
|:--------------:|:-----------------------------------:|
|    **P2P**     | {{ networks.parachain.p2p }} (TCP)  |
|  **RPC & WS**  |     {{ networks.parachain.ws }}     |
| **Prometheus** | {{ networks.parachain.prometheus }} |

### Default Ports of Embedded Relay Chain {: #default-ports-of-embedded-relay-chain }

|  Description   |                 Port                  |
|:--------------:|:-------------------------------------:|
|    **P2P**     | {{ networks.relay_chain.p2p }} (TCP)  |
|  **RPC & WS**  |     {{ networks.relay_chain.ws }}     |
| **Prometheus** | {{ networks.relay_chain.prometheus }} |

## Installation {: #installation }

There are a couple different guides to help you get started running a Moonbeam-based node:

- [Using Docker](/node-operators/networks/run-a-node/docker/) - this method provides a quick and easy way to get started with a Docker container
- [Using Systemd](/node-operators/networks/run-a-node/systemd/) - this method is recommended for those with experience compiling a Substrate node

## Debug, Trace and TxPool APIs {: #debug-trace-txpool-apis }

You can also gain access to some non-standard RPC methods by running a tracing node, which allow developers to inspect and debug transactions during runtime. Tracing nodes use a different Docker image than a standard Moonbase Alpha, Moonriver, or Moonbeam node. Check out the [Run a Tracing Node](/node-operators/networks/tracing-node/) guide and be sure to switch to the right network tab throughout the instructions. Then to interact with your tracing node, check out the [Debug & Trace](/builders/ethereum/json-rpc/debug-trace/) guide.

## Lazy Loading {: #lazy-loading }

Lazy loading lets a Moonbeam node operate while downloading network state in the background, eliminating the need to wait for full synchronization before use. You can activate lazy loading with the following flag:

- **`--lazy-loading-remote-rpc`** - allows lazy loading by relying on a specified RPC for network state until the node is fully synchronized e.g. `--lazy-loading-remote-rpc 'INSERT-RPC-URL'`

Upon spooling up a node with this feature, you'll see output like the following:

<div id="termynal" data-termynal>
  <span data-ty>[Lazy loading 🌗]
    <br>You are now running the Moonbeam client in lazy loading mode, where data is retrieved
    <br>from a live RPC node on demand.
    <br>Using remote state from: https://moonbeam.unitedbloc.com
    <br>Forking from block: 8482853
    <br>To ensure the client works properly, please note the following:
    <br>    1. *Avoid Throttling*: Ensure that the backing RPC node is not limiting the number of
    <br>    requests, as this can prevent the lazy loading client from functioning correctly;
    <br>    2. *Be Patient*: As the client may take approximately 20 times longer than normal to
    <br>    retrieve and process the necessary data for the requested operation.
    <br>The service will start in 10 seconds...</span>
</div>

!!! note
    Lazy loading a Moonbeam requires a large number of RPC requests. To avoid being rate-limited by a public endpoint, it's highly recommended to use a [dedicated endpoint](/builders/get-started/endpoints#endpoint-providers).  

You can further customize your use of the lazy loading functionality with the following optional parameters:

- **`--lazy-loading-block`** - specifies a block hash from which to start loading data. If not provided, the latest block will be used
- **`--lazy-loading-delay-between-requests`** - the delay (in milliseconds) between RPC requests when using lazy loading. This parameter controls the amount of time to wait between consecutive RPC requests. This can help manage request rate and avoid overwhelming the server. Default value is `100` milliseconds
- **`--lazy-loading-max-retries-per-request`** - the maximum number of retries for an RPC request when using lazy loading. Default value is `10` retries
- **`--lazy-loading-runtime-override`** - path to a WASM file to override the runtime when forking. If not provided, it will fetch the runtime from the block being forked
- **`--lazy-loading-state-overrides`** - path to a JSON file containing state overrides to be applied when forking 

The state overrides file should define the respective pallet, storage item, and value that you seek to override as follows:

```json
[
 {
     "pallet": "System",
     "storage": "SelectedCandidates",
     "value": "0x04f24ff3a9cf04c71dbc94d0b566f7a27b94566cac"
 }
]
```

## Logs and Troubleshooting {: #logs-and-troubleshooting }

You will see logs from both the relay chain and the parachain. The relay chain will be prefixed by `[Relaychain]`, while the parachain has no prefix.

### P2P Ports Not Open {: #p2p-ports-not-open }

If you don't see an `Imported` message (without the `[Relaychain]` tag), you need to check the P2P port configuration. P2P port must be open to incoming traffic.

### In Sync {: #in-sync }

Both chains must be in sync at all times, and you should see either `Imported` or `Idle` messages and have connected peers.

### Genesis Mismatching {: #genesis-mismatching }

The Moonbase Alpha TestNet may need to be purged and upgraded once in a while. Consequently, you may see the following message:

```text
DATE [Relaychain] Bootnode with peer id `ID` is on a different
chain (our genesis: GENESIS_ID theirs: OTHER_GENESIS_ID)
```

This typically means that you are running an older version and will need to upgrade.

We announce the upgrades (and corresponding chain purge) via our [Discord channel](https://discord.com/invite/PfpUATX) at least 24 hours in advance.

Instructions for purging chain data will vary slightly depending on how you spun up your node:

  - For Docker, you can check out the [Purge Your Node](/node-operators/networks/run-a-node/docker/#purge-your-node) section of the [Using Docker](/node-operators/networks/run-a-node/docker/) page
  - For Systemd, you can take a look at the [Purge Your Node](/node-operators/networks/run-a-node/systemd/#purge-your-node) section of the [Using Systemd](/node-operators/networks/run-a-node/systemd/) page
--- END CONTENT ---

## Reference Concepts [shared: true]

The following section contains reference material for Moonbeam.
It includes network endpoints, JSON-RPC methods, and contract or token addresses.
While it may not be required for all use cases, it offers a deeper technical layer for advanced development work.

---

## List of shared concept pages:


## Full content for shared concepts:

Doc-Content: https://docs.moonbeam.network/learn/dapp-directory/
--- BEGIN CONTENT ---
---
title: List your Dapp on the Moonbeam DApp Directory
description: Follow this tutorial to learn how to list your Moonbeam or Moonriver project or update a current listing on the Moonbeam Foundation DApp Directory.
dropdown_description: Explore the DApp Directory and listing process
categories: Reference
---

# How to List your Project on the Moonbeam DApp Directory

## Introduction to the Moonbeam DApp Directory {: #introduction-to-state-of-the-dapps }

The Moonbeam ecosystem comprises two distinct production networks: Moonbeam and Moonriver. Each network has its own dedicated [DApp Directory](https://apps.moonbeam.network/moonbeam/app-dir){target=\_blank}, maintained by the Moonbeam Foundation. These directories categorize projects spanning from DeFi to NFTs to gaming, providing users with comprehensive access to diverse applications.

You'll supply core project details like name, description, and relevant links when adding your project. Depending on your project type, you may include additional data such as on-chain stats and token information.

Despite the distinction between the Moonbeam and Moonriver DApp directories, the submission process remains the same. To list your project on the DApp Directory, you must submit a pull request to the [Moonbeam Foundation's App Directory Data repository on GitHub](https://github.com/moonbeam-foundation/app-directory-data){target=\_blank}. This guide outlines the necessary data and formatting specifics for your submission.

![The Moonbeam DApp Directory home page](/images/learn/dapps-list/directory-1.webp)

## Overview of the Project Data {: #overview-project-data }

There are four main sources of data that are used for a project's listing in the Moonbeam DApp Directory:

- **Core Project Data** - core project data such as descriptions, logos, and screenshots. This data also includes IDs used to query data from external platforms
- **Active Users and Transaction Volume** - on-chain data based on smart contract activity for all of the contracts associated with the project. Data is discovered via the use of contract labeling in Moonscan, which is then indexed by Web3Go and consumed by the DApp Directory
- **TVL Data** - TVL data for the protocol, sourced from the project's listing on DefiLlama
- **Project Token Information** - token information, which is sourced from the project's listing on CoinGecko

## Prerequisites for Using External Data Sources {: #configuring-external-data-sources }

Before pulling data from the mentioned sources, certain prerequisites must be fulfilled. However, it's worth noting that these steps may not apply to all project types. For instance, in the case of wallets, where there are no smart contracts, the DApp Directory is currently unable to display user and transaction activity data.

### Configure the Data Source for Active Users and Transaction Volume {: #configure-active-users }

For projects that have smart contracts deployed on Moonbeam or Moonriver, it is important that those contracts can be linked to the DApp Directory project data.

The end-to-end flow for linking smart contract activity to the DApp Directory is as follows:

1. The smart contract owner fills in the [form to label contracts on Moonscan](https://moonscan.io/contactus?id=5){target=\_blank}
2. The contracts become labeled in Moonscan
3. Periodically, the entire list of labeled contracts is exported and transmitted to Web3Go to be ingested
4. Every hour, Web3Go loads smart contract activity within Moonbeam and Moonriver and runs a job to index this data by the labels

To get your project's smart contracts properly labeled on [Moonscan](https://moonscan.io){target=\_blank}, please refer to Web3Go's documentation on the [Labeling Structure](https://dinlol.gitbook.io/moonscan-smart-contract-label-for-projects/labeling-structure){target=\_blank} and [How to Submit Contract Information](https://dinlol.gitbook.io/moonscan-smart-contract-label-for-projects/how-to-submit-contract-information){target=\_blank} on Moonscan.

Once you've labeled your smart contracts and are ready to submit your project to the DApp Directory, configuring the Directory to utilize your smart contract data becomes straightforward. You'll only need the **Project** component of your labeled contracts.

Consider the following example project with two smart contracts: a Comptroller and a Router recently updated to a new version.

|  Project   | Contract Name | Contract Version |      Resulting Label       |
|:----------:|:-------------:|:----------------:|:--------------------------:|
| My Project |  Comptroller  |        V1        | My Project: Comptroller V1 |
| My Project |    Router     |        V2        |   My Project: Router V2    |

To submit your project to the Moonbeam DApp Directory, ensure you have your **Project** name ready, identified here as `My Project`.

If you're ready to add your project to the DApp Directory, skip to the [How to Submit Your Project Listing](#how-to-submit-your-project-listing) section.

### Configure the Data Source for TVL {: #configure-tvl }

If the project represents a DeFi protocol with TVL (whereby value is locked in the protocol's smart contract), it is possible to display TVL in the Moonbeam DApp Directory.

TVL data is pulled from [DefiLlama](https://defillama.com){target=\_blank}, so you must list your project there. To get your project listed, please refer to DefiLlama's documentation on [How to list a DeFi project](https://docs.llama.fi/list-your-project/submit-a-project){target=\_blank}.

After listing your project, you can easily configure the DApp Directory to pull data from DefiLlama. To do so, you'll need the DefiLlama identifier, which you can find in the URL for your protocol's page. For example, the URL for Moonwell's page is `https://defillama.com/protocol/moonwell`, so the identifier is `moonwell`.

If you have the identifier and are ready to submit your project to the Moonbeam DApp Directory, skip to the [How to Submit Your Project Listing](#how-to-submit-your-project-listing) section.

### Configure the Data Source for Project Token Information {: #project-token-information }

If a project has a token, it is possible to display the name of the token, current price, and contract in the DApp Directory.

However, the data is pulled from [CoinGecko](https://www.coingecko.com){target=\_blank}, so the project's token must be listed there. If your token is not listed there, you can complete [CoinGecko's Request Form](https://support.coingecko.com/hc/en-us/requests/new){target=\_blank} to initiate the listing process.

Assuming your project's token is listed there, you must obtain the CoinGecko **API ID** value. You can find the **API ID** value in the **Information** section of the token's page on CoinGecko. For example, the **API ID** on [Moonwell's token page](https://www.coingecko.com/en/coins/moonwell){target=\_blank} is `moonwell-artemis`.

If you have the CoinGecko ID and are ready to submit your project to the Moonbeam DApp Directory, you can continue to the next section.

## How to Submit Your Project Listing {: #how-to-submit-your-project-listing }

As mentioned, you must submit a pull request to the Moonbeam Foundation's GitHub repository that holds the DApp Directory's data. Before getting started, it's worth noting that to expedite the review process, the GitHub user who submits the pull request is recommended to be a major contributor to the project's GitHub so that the Moonbeam Foundation can quickly verify that they represent the project. You can check out the [Review Process](#review-process) section for more information.

To begin, you have two options for adding your project information to the [`app-directory-data` repository on GitHub](https://github.com/moonbeam-foundation/app-directory-data){targe\_blank}. You can utilize [GitHub's browser-based editor](https://github.dev/moonbeam-foundation/app-directory-data){target=\_blank}, which offers a user-friendly interface.

![The app-directory-data repository loaded on GitHub's browser-based editor](/images/learn/dapps-list/directory-2.webp)

Or you can clone the repository locally and make modifications using your preferred code editor, in which you can use the following command to clone the repository:

```bash
git clone https://github.com/moonbeam-foundation/app-directory-data.git
```

Once you've cloned the project, you can create a new branch to which you will add all of your changes. To do this on the browser-based editor, take the following steps:

1. Click on the current branch name in the bottom left corner
2. A menu will appear at the top of the page. Enter the name of your branch
3. Click **Create new branch...**

![Create a new branch on GitHub's browser-based editor](/images/learn/dapps-list/directory-3.webp)

The page will reload, and your branch name will now be displayed in the bottom left corner.

### Projects with Deployments on Moonbeam and Moonriver {: #projects-with-deployments }

If a project is deployed to both Moonbeam and Moonriver, there are two different options available:

- Create a separate project structure for each deployment
- Use a single project structure and modify the project data file for both projects

Separate project structures should be used if:

- The two deployments have distinct representations in DefiLlama (i.e., two distinct identifiers)
- The project has two different tokens, one native to Moonbeam and one native to Moonriver

Otherwise, either option may be used.

### Set Up the Folder Structure for Your Project {: #set-up-the-file-structure }

All configurations for each project listed in the DApp Directory are stored in the `projects` folder.

To get started, you must have a name that uniquely and properly identifies your project. Using your project name, you can take the following steps:

1. Create a new directory for your project using your unique project name
2. In your project directory, you'll need to create:
    1. A project data file is a JSON file that defines all your project data and contains references to the images stored in the `logos` and `screenshots` folders. The list of fields you can use to define your data, with descriptions, is outlined in the next section. The file must be named using your unique project name
    2. A `logos` folder where your project logo images are stored
    3. (Optional) A `screenshots` folder where screenshots for the project are stored

??? code "Example folder structure"

    ```text
    my-project
├── my-project.json
├── logos
│   ├── my-project-logo-small.jpeg
│   └── my-project-logo-full.jpeg
└── screenshots
    ├── my-project-screenshot1-small.jpeg
    ├── my-project-screenshot1-full.jpeg
    ├── my-project-screenshot2-small.jpeg
    └── my-project-screenshot2-full.jpeg
    ```

![The file structure displayed on GitHub's browser-based editor](/images/learn/dapps-list/directory-4.webp)

With the foundational file structure in place, you're ready to populate the necessary information for your project submission.

### Add Information to the Project Data File {: #add-information }

Your project's data file is where you'll add all the information for your project. The file permits the following top-level properties:

| <div style="width:10vw">Property</div> |                         Type                          |                                                                                                                                                                      Description                                                                                                                                                                       |
|:--------------------------------------:|:-----------------------------------------------------:|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|
|                  `id`                  |                        String                         |                                                                                               Unique identifier for the dApp in the Moonbeam DApp Directory. It should be a unique, human-readable string representing this project. E.g., `my-project`                                                                                                |
|                 `slug`                 |                        String                         |                                                  Identifier used in certain third-party sources. In particular, if the project is listed in DefiLlama, this value should be set to the DefiLlama identifier. See the [Configure the Data Source for TVL](#configure-tvl) section for more information                                                  |
|                 `name`                 |                        String                         |                                                                                                                                      The project name as it will appear in the DApp Directory. E.g., `My Project`                                                                                                                                      |
|               `category`               |                        String                         |                                         The category the project should be associated with. A project can only have one category, and it corresponds to the category list in the left-hand nav of the DApp Directory. See the [Category and Tags](#category-and-tags) section for the accepted list of values                                          |
|             `coinGeckoId`              |                        String                         |                                              If the project has a token listed on CoinGecko, this property should have the **API ID** value corresponding to the given token. See the [Configure the Data Source for Project Token Information](#project-token-information) section for more information                                               |
|                `chains`                |                   Array of Strings                    |                                                                                                               List of Moonbeam ecosystem chains on which the project is deployed. Valid values are currently `moonbeam` and `moonriver`                                                                                                                |
|              `web3goIDs`               |                   Array of Strings                    | List of Web3Go identifiers for a given dApp. The identifiers should correspond to the **Project** component of the smart contract labels set up in Moonscan. Generally, there should only be one value in the array. See the [Configure the Data Source for Active Users and Transaction Volume](#configure-active-users) section for more information |
|                 `logo`                 |            Map of Strings to JSON objects             |                                                                                                     Map of logo image files associated with this project and stored in the `logos` directory. See the [Logos](#logos) section for more information                                                                                                     |
|           `shortDescription`           |                        String                         |                                                                                                      A short description of the project used in the display card when browsing dapps in the directory. This should be kept to under 80 characters                                                                                                      |
|             `description`              |                        String                         |                                                                               A longer description used in the project detail page. Markdown or similar formatting cannot be used. Line breaks can be used using `\r\n`. The text should be limited to a few paragraphs                                                                                |
|                 `tags`                 |                   Array of Strings                    |                                                                       A list of applicable [tags](#category-and-tags) for this project. Tag values will show up in the project details. See the [Category and Tags](#category-and-tags) section for the accepted list of values                                                                        |
|              `contracts`               |            Array of contract JSON objects             |                                                     List of contracts for the project. Currently, this is used only for token contracts. The list of smart contracts which make up the protocol is externally sourced from Moonscan. See the [Contracts](#contracts) section for more information                                                      |
|                 `urls`                 |       Map of Strings (names) to Strings (URLs)        |                                                                                                        Mapping of URLs for websites and socials associated with the project. See the [URLs](#urls) section for the accepted list of properties                                                                                                         |
|             `screenshots`              | Array of Maps of Strings (size) to image JSON objects |                                                                                        List of screenshot image files associated with this project and stored in the `screenshots` directory. See the [Screenshots](#screenshots) section for more information                                                                                         |
|         `projectCreationDate`          |                          int                          |                                                                                                                                   The date the project was created. Used for sorting purposes in the DApp Directory                                                                                                                                    |

??? code "Example project data file"

    ```json
    {
    "id": "moonwell",
    "slug": "moonwell",
    "name": "Moonwell",
    "category": "lending",
    "coinGeckoId": "moonwell-artemis",
    "chains": [
        "moonbeam"
    ],
    "web3goIDs": [
        "Moonwell Artemis"
    ],
    "logo": {
        "small": {
            "fileName": "moonwell-logo-small.jpeg",
            "width": 40,
            "height": 40,
            "mimeType": "image/jpeg"
        },
        "large": {
            "fileName": "moonwell-logo-large.jpeg",
            "width": 400,
            "height": 400,
            "mimeType": "image/jpeg"
        },
        "full": {
            "fileName": "moonwell-logo-full.jpeg",
            "width": 3000,
            "height": 3000,
            "mimeType": "image/jpeg"
        }
    },
    "shortDescription": "Lending, borrowing, and DeFi protocol built on Moonbeam and Moonriver",
    "description": "Moonwell is an open lending, borrowing, and decentralized finance protocol built on Moonbeam and Moonriver. Moonwell’s composable design can accommodate a full range of DeFi applications in the greater Polkadot and Kusama (DotSama) ecosystem.\r\n\r\nOur first deployment will be on Kusama’s Moonriver, the sister network of Polkadot’s Moonbeam. Moonriver is where new products are expected to be incubated and developed prior to being deployed on Moonbeam.",
    "tags": [
        "Lending",
        "DeFi"
    ],
    "contracts": [
        {
            "contract": "0x511ab53f793683763e5a8829738301368a2411e3",
            "chain": "moonbeam",
            "name": "WELL Token"
        }
    ],
    "urls": {
        "website": "https://moonwell.fi/",
        "try": "https://moonwell.fi/",
        "twitter": "https://twitter.com/MoonwellDeFi",
        "medium": "https://moonwell.medium.com/",
        "telegram": "https://t.me/moonwellfichat",
        "github": "https://github.com/moonwell-open-source",
        "discord": "https://discord.gg/moonwellfi"
    },
    "screenshots": [
        {
            "small": {
                "fileName": "moonwell-screenshot-small1.png",
                "width": 429,
                "height": 200,
                "mimeType": "image/png"
            },
            "full": {
                "fileName": "moonwell-screenshot-full1.png",
                "width": 514,
                "height": 300,
                "mimeType": "image/png"
            }
        },
        {
            "small": {
                "fileName": "moonwell-screenshot-small2.png",
                "width": 429,
                "height": 200,
                "mimeType": "image/png"
            },
            "full": {
                "fileName": "moonwell-screenshot-full2.png",
                "width": 1716,
                "height": 800,
                "mimeType": "image/png"
            }
        },
        {
            "small": {
                "fileName": "moonwell-screenshot-small3.png",
                "width": 429,
                "height": 200,
                "mimeType": "image/png"
            },
            "full": {
                "fileName": "moonwell-screenshot-full3.png",
                "width": 1054,
                "height": 637,
                "mimeType": "image/png"
            }
        },
        {
            "small": {
                "fileName": "moonwell-screenshot-small4.png",
                "width": 429,
                "height": 200,
                "mimeType": "image/png"
            },
            "full": {
                "fileName": "moonwell-screenshot-full4.png",
                "width": 1365,
                "height": 436,
                "mimeType": "image/png"
            }
        }
    ],
    "projectCreationDate": 1644828523000
}
    ```

#### Category and Tags {: #category-and-tags }

A category is the primary classification for a project. A project can be categorized under only one category, but it can have multiple tags. Ensure you carefully select the most applicable category for your project to ensure it is easily found. Any secondary classifications can be included as a tag. 

The currently supported values for `category` are:

```text
- Bridges
- DAO
- DEX
- DeFi
- Gaming
- Lending
- NFTs
- Other
- Social
- Wallets
```

The currently supported values for `tag` are:

```text
- Bridges
- DAO
- DEX
- DeFi
- DePIN
- Developer Tools
- Explorers
- Files
- GLMR Grants
- Gaming
- Infrastructure
- IoT
- Lending
- MOVR Grants
- Messaging
- NFT
- NFT Marketplaces
- On-ramp
- Other
- Social
- Tool
- VPN
- Wallets
- ZeroTrust
```

#### URLs {: #urls }

The `urls` property name/value pairs are used so a project can provide links to their website, socials, etc.

The following table lists the supported `urls` properties:

| Property Name |                                                    Description                                                     |                     Example                     |
|:-------------:|:------------------------------------------------------------------------------------------------------------------:|:-----------------------------------------------:|
|   `website`   |                                          The main website for the project                                          |            https://moonbeam.network/            |
|     `try`     | URL a user should visit if they want to try out the dApp. Typically, this page will have a link to launch the dApp |            https://moonbeam.network/            |
|   `twitter`   |                                           The project's Twitter profile                                            |       https://twitter.com/MoonbeamNetwork       |
|   `medium`    |                                             The project's Medium site                                              |       https://medium.com/moonbeam-network       |
|  `telegram`   |                                               The project's Telegram                                               |         https://t.me/Moonbeam_Official          |
|   `github`    |                                          The project's GitHub repository                                           | https://github.com/moonbeam-foundation/moonbeam |
|   `discord`   |                                               The project's Discord                                                |       https://discord.com/invite/PfpUATX        |

The format of the property name/value pairs should follow the JSON standard, for example:

```json
"urls": {
    "website": "https://moonbeam.network/",
    "try": "https://docs.moonbeam.network/",
    "twitter": "https://twitter.com/MoonbeamNetwork"
}
```

#### Logos {: #logos }

The `logos` property of the main project data file is a map of image sizes (i.e., `small`, `large`, `full`) to corresponding image JSON objects. The image JSON object contains the display properties for the given image.

The following table lists the properties of the image JSON object:

|  Property  |  Type  |                                                                       Description                                                                        |
|:----------:|:------:|:--------------------------------------------------------------------------------------------------------------------------------------------------------:|
| `fileName` | String |                                         The name of the image file (unqualified) stored in the `logos` directory                                         |
|  `width`   |  int   |                                                          The width of the logo image in pixels                                                           |
|  `height`  |  int   |                                                          The height of the logo image in pixels                                                          |
| `mimeType` | String | The standard [MIME type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/MIME_types){target=\_blank} of the file. E.g., `"image/jpeg"` |

Currently, only the `small` size is utilized, and the dimensions for small logos should be 40x40 pixels.

Here is an example showing the structure of the `logo` property that supplies `small` and `full` logos:

```json
"logo": {
    "small": {
        "fileName": "my-project-logo-small.jpeg",
        "width": 40,
        "height": 40,
        "mimeType": "image/jpeg"
    },
    "full": {
        "fileName": "my-project-logo-full.jpeg",
        "width": 3000,
        "height": 3000,
        "mimeType": "image/jpeg"
    }
}
```

#### Screenshots {: #screenshots }

The `screenshots` property of the main project data file is an array of maps. Each map in the array is for a specific screenshot.

However, different-sized images for each screenshot should be supplied so that different sizes can be used in different contexts (e.g., thumbnails vs full-sized images). Thus, for each screenshot, there is a map of image sizes (i.e., `small`, `large`, `full`) to corresponding image JSON objects. The image JSON object contains the display properties for the given image.

The following table lists the properties of the image JSON object:

|  Property  |  Type  |                                                                       Description                                                                        |
|:----------:|:------:|:--------------------------------------------------------------------------------------------------------------------------------------------------------:|
| `fileName` | String |                                      The name of the image file (unqualified) stored in the `screenshots` directory                                      |
|  `width`   |  int   |                                                          The width of the logo image in pixels                                                           |
|  `height`  |  int   |                                                          The height of the logo image in pixels                                                          |
| `mimeType` | String | The standard [MIME type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/MIME_types){target=\_blank} of the file. E.g., `"image/jpeg"` |

Here is an example showing the structure of the `screenshot` property for two screenshots (`screenshot1` and `screenshot2`):

```json
"screenshots": [
    {
        "small": {
            "fileName": "my-project-screenshot1-small.png",
            "width": 429,
            "height": 200,
            "mimeType": "image/png"
        },
        "full": {
            "fileName": "my-project-screenshot1-full.png",
            "width": 514,
            "height": 300,
            "mimeType": "image/png"
        }
    },
    {
        "small": {
            "fileName": "my-project-screenshot2-small.png",
            "width": 429,
            "height": 200,
            "mimeType": "image/png"
        },
        "full": {
            "fileName": "my-project-screenshot2-full.png",
            "width": 1716,
            "height": 800,
            "mimeType": "image/png"
        }
    }
]
```

#### Contracts {: #contracts }

A list of contracts for the project. Currently, this is used only for token contracts.

The smart contracts that make up the protocol are sourced from [Moonscan](https://moonscan.io){target=\_blank} based on tagging, so they do not need to be listed here. If you have not properly labeled your contracts or are unsure if they are labeled according to the Moonbeam community standard, please refer to the [Configure the Data Source for Active Users and Transaction Volume](#configure-active-users) section.

The following table lists the properties found in the contract JSON object:

|  Property  |  Type  |                                  Description                                  |
|:----------:|:------:|:-----------------------------------------------------------------------------:|
| `contract` | String |                      The address for the smart contract                       |
|  `chain`   | String | The chain on which the contract is deployed (i.e., `moonbeam` or `moonriver`) |
|   `name`   | String |                           The name of the contract                            |

Here is a `contracts` array with a single smart contract for the WGLMR token:

```json
"contracts": [
    {
        "contract": "0xAcc15dC74880C9944775448304B263D191c6077F",
        "chain": "moonbeam",
        "name": "Wrapped GLMR Token"
    }
]
```

### Submit a Pull Request {: #submit-a-pull-request }

After you've populated the project data file and added your logos and screenshots, you should be ready to submit your pull request.

![All of the project files added on GitHub's browser-based editor](/images/learn/dapps-list/directory-5.webp)

From the web-based editor, take the following steps to commit your changes to the `app-directory-data` repository:

1. Click on the **Source Control** tab, which should show you how many pages have been added or changed
2. Review the files under the **Changes** section. Click the **+** button next to **Changes**, or as you review each file, click the **+** button next to the file name to add them to the list of **Staged Changes**

![Staging the changed files on GitHub's browser-based editor](/images/learn/dapps-list/directory-6.webp)

All of your files should now be under the **Staged Changes** section. All you have to commit and push the changes are:

1. Enter a descriptive commit message, such as "Add My Project", making sure to use your actual project name
2. Click **Commit & Push**

![Committing the staged files on GitHub's browser-based editor](/images/learn/dapps-list/directory-7.webp)

Now that you've committed the changes, you'll need to head over to the [`app-directory-data` repository](https://github.com/moonbeam-foundation/app-directory-data){target=\_blank} and open a pull request against the `develop` branch:

1. At the top of the repository page, click **Compare and Pull** button displayed on the banner, or
2. If the banner is not there anymore, you'll need to select your branch from the branches dropdown
3. Click the **Contribute** dropdown
4. Click the **Open pull request** button

![The main page of the app-directory-data repository on GitHub](/images/learn/dapps-list/directory-8.webp)

You'll be taken to the **Comparing changes** page, where you'll need to:

1. Make sure that you are merging your branch into the `develop` branch, which is the **base** branch
2. Add a title
3. Add a description of the changes
4. Click **Create pull request**

![Submit a pull request on the Comparing changes page of the app-directory-data repository on GitHub](/images/learn/dapps-list/directory-9.webp)

### The Review Process {: #review-process }

Submitted pull requests will be reviewed bi-weekly by the Moonbeam Foundation. During the review, and especially for new projects, the Foundation may have to verify that the GitHub user who created the pull request is a contributor and/or represents the specific project. One way projects can expedite this process is if the submitter's GitHub account is also a major contributor to the project itself on GitHub. Alternatively, teams should leave a note in the pull request comments indicating how we can get in touch with project team members to verify.

A comment will be added to the pull request if any changes are requested. After your pull request has been approved, it will be merged, and your project will be added to the Moonbeam DApp Directory!

## How to Update Your Project Listing {: #how-to-update-your-project-listing }

As your project evolves, you may need to update your project's listing or images related to your listing. You can create a new branch for your changes, find and modify your existing project's data from the root `projects` directory, and make the desired changes.

If you are no longer using a logo or screenshot, please remember to remove it from the `logos` or `screenshots` directory.

Once your changes have been made, you must follow the same instructions in the [Submit a Pull Request](#submit-a-pull-request) section so the changes can be [reviewed](#review-process) by the Moonbeam Foundation. Please note that pull requests are reviewed on a bi-weekly basis, so if the update is urgent, you can create a [forum post](https://forum.moonbeam.network){target=\_blank} asking for assistance.

## DApp Directory API {: #dapp-directory-api }

The DApp Directory also features a queryable API that you can use to integrate data from Moonbeam's DApp Directory into your application. The API is public and currently does not require authentication. The base URL for the API is as follows:

```bash
https://apps.moonbeam.network/api/ds/v1/app-dir/
```

### Query a Project {: #query-a-project}

You can retrieve all the information for a particular project by appending `/projects/INSERT_PROJECT_NAME` to the base URL. If you need clarification on the project name, you can omit the project name as shown below to retrieve data for every listed project and find the project in the response. 

```bash
https://apps.moonbeam.network/api/ds/v1/app-dir/projects
```

Here's an example of querying the API for StellaSwap, which returns the project description, social media information, user counts, relevant smart contract addresses, market data, images, and more. 

```bash
https://apps.moonbeam.network/api/ds/v1/app-dir/projects/stellaswap
```

You can visit the query URL directory in the browser, using a tool like Postman, or directly from the command line with Curl as follows: 

```bash
curl -H "Content-Type: application/json" -X GET 'https://apps.moonbeam.network/api/ds/v1/app-dir/projects/stellaswap'
```

??? code "API Response to Querying StellaSwap"

    ```json
    {
    "project":{
        "currentTx":{
            "moonbeam":2883079
        },
        "web3goIDs":[
            "StellaSwap"
        ],
        "name":"StellaSwap",
        "currentTVL":{
            "moonbeam":5046832.23328
        },
        "currentUsers":{
            "moonbeam":52455
        },
        "coinGeckoId":"stellaswap",
        "shortDescription":"The leading DEX and DeFi gateway on Moonbeam",
        "id":"stellaswap",
        "featured":true,
        "tags":[
            "DEX",
            "DeFi"
        ],
        "tvlChange7d":{
            "moonbeam":-1.61482567543498
        },
        "urls":{
            "telegram":"https://t.me/stellaswap",
            "website":"https://stellaswap.com/",
            "try":"https://stellaswap.com/",
            "twitter":"https://twitter.com/StellaSwap",
            "github":"https://github.com/stellaswap",
            "medium":"https://stellaswap.medium.com/"
        },
        "web3goContracts":[
            {
                "name":"StellaSwap: stDOT Oracle Master",
                "chain":"moonbeam",
                "contract":"0x3b23f0675ffc45153eca239664ccaefc5e816b9c"
            },
            {
                "name":"StellaSwap: stDOT Token",
                "chain":"moonbeam",
                "contract":"0xbc7e02c4178a7df7d3e564323a5c359dc96c4db4"
            },
            {
                "name":"StellaSwap: stDOT Controller",
                "chain":"moonbeam",
                "contract":"0x002d34d6a1b4a8e665fec43fd5d923f4d7cd254f"
            },
            {
                "name":"StellaSwap: stDOT Proxy Admin",
                "chain":"moonbeam",
                "contract":"0xe8a5c0039226269313c89c093a6c3524c4d39fa4"
            },
            {
                "name":"StellaSwap: madUSDC GLMR V2",
                "chain":"moonbeam",
                "contract":"0x2ad0e92461df950e2b1c72e2f7a865c81eaa3ce6"
            },
            {
                "name":"StellaSwap: Dual ETH - GLMR Rewarder V1",
                "chain":"moonbeam",
                "contract":"0x2ba130297d1966e077c2fb5e4b434e8802925277"
            },
            {
                "name":"StellaSwap: BCMC Rewarder V1",
                "chain":"moonbeam",
                "contract":"0x18e75887aa81e113636e18d5a78e3ff93787ec88"
            },
            {
                "name":"StellaSwap: Pulsar Position Manager V1",
                "chain":"moonbeam",
                "contract":"0x1ff2adaa387dd27c22b31086e658108588eda03a"
            },
            {
                "name":"StellaSwap: DualETH Pool LP Token V1",
                "chain":"moonbeam",
                "contract":"0xa3ee3a0a36dc915fdc93062e4b386df37d00217e"
            },
            {
                "name":"StellaSwap: Interlay Rewarder V1",
                "chain":"moonbeam",
                "contract":"0x3a7572220afaddc31a72a520642111776d92b2d2"
            },
            {
                "name":"StellaSwap: Router V1",
                "chain":"moonbeam",
                "contract":"0xd0a01ec574d1fc6652edf79cb2f880fd47d34ab1"
            },
            {
                "name":"StellaSwap: xStella - GLMR Rewarder 2nd V1",
                "chain":"moonbeam",
                "contract":"0xb4dba7fe6fcc613963d64204fcf789e9e376679a"
            },
            {
                "name":"StellaSwap: GLMR Rewarder First V1",
                "chain":"moonbeam",
                "contract":"0x69f9d134991e141c4244f397514ba05d67861cc0"
            },
            {
                "name":"StellaSwap: CELER Rewarder 0 V1",
                "chain":"moonbeam",
                "contract":"0xbebd88782a1145b71df3f4986ef7686154ce01d9"
            },
            {
                "name":"StellaSwap: MATICILO V1",
                "chain":"moonbeam",
                "contract":"0xfffa340944ff32f50c7935e2b5d22a7c3393b313"
            },
            {
                "name":"StellaSwap: ETHmad - GLMR V1",
                "chain":"moonbeam",
                "contract":"0x9fe074a56ffa7f4079c6190be6e8452911b7e349"
            },
            {
                "name":"StellaSwap: STELLA Token",
                "chain":"moonbeam",
                "contract":"0x0e358838ce72d5e61e0018a2ffac4bec5f4c88d2"
            },
            {
                "name":"StellaSwap: SFL - 4pool Wormhole V1",
                "chain":"moonbeam",
                "contract":"0xb1bc9f56103175193519ae1540a0a4572b1566f6"
            },
            {
                "name":"StellaSwap: BICO Trusted Forwarder V1",
                "chain":"moonbeam",
                "contract":"0x3d08ce1f9609bb02f47192ff620634d9eb0e7b56"
            },
            {
                "name":"StellaSwap: Gass Refund V1",
                "chain":"moonbeam",
                "contract":"0xee42d4861b56b32776e6fe9a2fe122af0e3f4a33"
            },
            {
                "name":"StellaSwap: xcDOT - GLMR V1",
                "chain":"moonbeam",
                "contract":"0xe76215efea540ea87a2e1a4bf63b1af6942481f3"
            },
            {
                "name":"StellaSwap: 4pool LP V1",
                "chain":"moonbeam",
                "contract":"0xda782836b65edc4e6811c7702c5e21786203ba9d"
            },
            {
                "name":"StellaSwap: SFL LP V1",
                "chain":"moonbeam",
                "contract":"0xa0aa99f71033378864ed6e499eb03612264e319a"
            },
            {
                "name":"StellaSwap: SFL - 4pool V1",
                "chain":"moonbeam",
                "contract":"0x422b5b7a15fb12c518aa29f9def640b4773427f8"
            },
            {
                "name":"StellaSwap: Acala - GLMR Rewarder V1",
                "chain":"moonbeam",
                "contract":"0x9de8171bebfa577d6663b594c60841fe096eff97"
            },
            {
                "name":"StellaSwap: Zap V1",
                "chain":"moonbeam",
                "contract":"0x01834cf26717f0351d9762cc9cca7dc059d140df"
            },
            {
                "name":"StellaSwap: GLMR Rewarder for UST - GLMR V1",
                "chain":"moonbeam",
                "contract":"0xc85ddcff71200f9673137e2f93ce504bdbf7db4e"
            },
            {
                "name":"StellaSwap: xStella Token",
                "chain":"moonbeam",
                "contract":"0x06a3b410b681c82417a906993acefb91bab6a080"
            },
            {
                "name":"StellaSwap: ETHmad - GLMR V2",
                "chain":"moonbeam",
                "contract":"0xa6ec79c97e533e7bddb00898e22c6908742e039b"
            },
            {
                "name":"StellaSwap: WBTC - USDT Contract V1",
                "chain":"moonbeam",
                "contract":"0xcae51da6dceacd84f79df4b88d9f92035d1479e9"
            },
            {
                "name":"StellaSwap: AVAXILO V1",
                "chain":"moonbeam",
                "contract":"0x96bef4719ae7c053113292e6aa7fc36e62b243e8"
            },
            {
                "name":"StellaSwap: Swap For Gas V1",
                "chain":"moonbeam",
                "contract":"0xb64dee2d182fed3dd6c273303fb08f11808c9c23"
            },
            {
                "name":"StellaSwap: Farming Centre V1",
                "chain":"moonbeam",
                "contract":"0x0d4f8a55a5b2583189468ca3b0a32d972f90e6e5"
            },
            {
                "name":"StellaSwap: FTMILO V1",
                "chain":"moonbeam",
                "contract":"0x096352f7ea415a336b41fc48b33142eff19a8ad8"
            },
            {
                "name":"StellaSwap: Acala Rewarder V1",
                "chain":"moonbeam",
                "contract":"0xb7b5d3659ad213478bc8bfb94d064d0efdda8f7c"
            },
            {
                "name":"StellaSwap: USDC Rewarder V1",
                "chain":"moonbeam",
                "contract":"0xa52123adc0bc5c4c030d1ff4f5dad966366a646c"
            },
            {
                "name":"StellaSwap: Vault V1",
                "chain":"moonbeam",
                "contract":"0x54e2d14df9348b3fba7e372328595b9f3ae243fe"
            },
            {
                "name":"StellaSwap: CELER Rewarder 1 V1",
                "chain":"moonbeam",
                "contract":"0x70cbd76ed57393e0cd81e796de850080c775d24f"
            },
            {
                "name":"StellaSwap: Stella Timelock V1",
                "chain":"moonbeam",
                "contract":"0xc6f73b028cd3154a5bb87f49aa43aa259a6522fb"
            },
            {
                "name":"StellaSwap: GLMR - MAI Vault V1",
                "chain":"moonbeam",
                "contract":"0x3a82f4da24f93a32dc3c2a28cfa9d6e63ec28531"
            },
            {
                "name":"StellaSwap: UST - GLMR V1",
                "chain":"moonbeam",
                "contract":"0x556d9c067e7a0534564d55f394be0064993d2d3c"
            },
            {
                "name":"StellaSwap: SFL - axlUSDC - 4pool V1",
                "chain":"moonbeam",
                "contract":"0xa1ffdc79f998e7fa91ba3a6f098b84c9275b0483"
            },
            {
                "name":"StellaSwap: Stable Router V1",
                "chain":"moonbeam",
                "contract":"0xb0dfd6f3fddb219e60fcdc1ea3d04b22f2ffa9cc"
            },
            {
                "name":"StellaSwap: ATOM - GLMR Rewarder New V1",
                "chain":"moonbeam",
                "contract":"0x5aa224966e302424ec13a4f51b80bcfc205984b6"
            },
            {
                "name":"StellaSwap: CELR Rewarder V1",
                "chain":"moonbeam",
                "contract":"0x05ad30253f0b20be35d84253d6aca8bd7ec0c66c"
            },
            {
                "name":"StellaSwap: Router V3",
                "chain":"moonbeam",
                "contract":"0xe6d0ed3759709b743707dcfecae39bc180c981fe"
            },
            {
                "name":"StellaSwap: xStella - GLMR Rewarder V1",
                "chain":"moonbeam",
                "contract":"0x896135ff51debe8083a2e03f9d44b1d3c77a0324"
            },
            {
                "name":"StellaSwap: XStella - MAI Vault V1",
                "chain":"moonbeam",
                "contract":"0x3756465c5b1c1c4cee473880c9726e20875284f1"
            },
            {
                "name":"StellaSwap: ATOM - USDC Rewarder New V1",
                "chain":"moonbeam",
                "contract":"0x5546e272c67fac10719f1223b1c0212fa3e41a8f"
            },
            {
                "name":"StellaSwap: SFL - athUSDC - 4pool V1",
                "chain":"moonbeam",
                "contract":"0x715d7721fa7e8616ae9d274704af77857779f6f0"
            },
            {
                "name":"StellaSwap: IDO Locker V1",
                "chain":"moonbeam",
                "contract":"0x4b1381b5b959a8ba7f44414c7d758e53d500a8a9"
            },
            {
                "name":"StellaSwap: Locker V1",
                "chain":"moonbeam",
                "contract":"0x8995066b7f1fb3abe3c88040b677d03d607a0b58"
            },
            {
                "name":"StellaSwap: ATOM - USDC - GLMR Rewarder V1",
                "chain":"moonbeam",
                "contract":"0xe06e720aaed5f5b817cb3743108ae0a12fe69e9b"
            },
            {
                "name":"StellaSwap: Mistake in Rewarder V1",
                "chain":"moonbeam",
                "contract":"0x168ceb7e49c21e3f37820a34590171214a765f5f"
            },
            {
                "name":"StellaSwap: LP 4pool - Wormhole V1",
                "chain":"moonbeam",
                "contract":"0xb326b5189aa42acaa3c649b120f084ed8f4dcaa6"
            },
            {
                "name":"StellaSwap: Farms V1",
                "chain":"moonbeam",
                "contract":"0xedfb330f5fa216c9d2039b99c8ce9da85ea91c1e"
            },
            {
                "name":"StellaSwap: Factory V1",
                "chain":"moonbeam",
                "contract":"0x68a384d826d3678f78bb9fb1533c7e9577dacc0e"
            },
            {
                "name":"StellaSwap: anyETH-madETH Pool",
                "chain":"moonbeam",
                "contract":"0xb86271571c90ad4e0c9776228437340b42623402"
            },
            {
                "name":"StellaSwap: Dual Farms V2",
                "chain":"moonbeam",
                "contract":"0xf3a5454496e26ac57da879bf3285fa85debf0388"
            },
            {
                "name":"StellaSwap: CELER Rewarder 01 - 02 V1",
                "chain":"moonbeam",
                "contract":"0x713f76076283fcd81babe06c76ff51485edf9d5e"
            },
            {
                "name":"StellaSwap: SCNFT Token",
                "chain":"moonbeam",
                "contract":"0x5f23a6a0b6b90fdeeb4816afbfb2ec0408fda59e"
            },
            {
                "name":"StellaSwap: ATOM - GLMR - GLMR Rewarder V1",
                "chain":"moonbeam",
                "contract":"0xe60c41de5537418fde05b804df077397dfa84d75"
            },
            {
                "name":"StellaSwap: Timelock Main V1",
                "chain":"moonbeam",
                "contract":"0x9a8693c6f7bf0f44e885118f3f83e2cdb4e611b8"
            },
            {
                "name":"StellaSwap: MAI - B4P - Wormhole V1",
                "chain":"moonbeam",
                "contract":"0xf0a2ae65342f143fc09c83e5f19b706abb37414d"
            },
            {
                "name":"StellaSwap: LP Token V1",
                "chain":"moonbeam",
                "contract":"0x7b17122b941d2173192c7d8d68faabdc88421326"
            },
            {
                "name":"StellaSwap: Multisig V1",
                "chain":"moonbeam",
                "contract":"0x4300e09284e3bb4d9044ddab31efaf5f3301daba"
            },
            {
                "name":"StellaSwap: Router V2",
                "chain":"moonbeam",
                "contract":"0x70085a09d30d6f8c4ecf6ee10120d1847383bb57"
            },
            {
                "name":"StellaSwap: DOTxc - GLMR V1",
                "chain":"moonbeam",
                "contract":"0x505b0a5458dd12605b84bb2928dd2bc5b44993b9"
            },
            {
                "name":"StellaSwap: SFL - MAI - 4pool V1",
                "chain":"moonbeam",
                "contract":"0x7fbe3126c03444d43fc403626ec81e3e809e6b46"
            },
            {
                "name":"StellaSwap: xStella - USDC Rewarder V1",
                "chain":"moonbeam",
                "contract":"0xfa16d5b8bf03677945f0a750c8d2a30001b2fa93"
            },
            {
                "name":"StellaSwap: madUSDC - GLMR V1",
                "chain":"moonbeam",
                "contract":"0x9200cb047a9c4b34a17ccf86334e3f434f948301"
            }
        ],
        "slug":"stellaswap",
        "createdAt":1699292612617,
        "tvlChange1d":{
            "moonbeam":-0.748278690902012
        },
        "logo":{
            "small":{
                "width":36,
                "fileName":"stellaswap-logo-small.jpeg",
                "mimeType":"image/jpeg",
                "height":36
            },
            "large":{
                "width":510,
                "fileName":"stellaswap-logo-large.jpeg",
                "mimeType":"image/jpeg",
                "height":510
            },
            "full":{
                "width":3000,
                "fileName":"stellaswap-logo-full.jpeg",
                "mimeType":"image/jpeg",
                "height":3000
            }
        },
        "chains":[
            "moonbeam"
        ],
        "usersChange7d":{
            "moonbeam":-17.2727272727273
        },
        "marketData":{
            "symbol":"stella",
            "marketCap":808908,
            "marketCapRank":2865,
            "priceChangePercentage1y":-43.01356,
            "currentPrice":0.01729378,
            "priceChangePercentage14d":-17.23772,
            "contracts":{
                "moonbeam":"0x0e358838ce72d5e61e0018a2ffac4bec5f4c88d2"
            },
            "priceChangePercentage60d":-39.75633,
            "priceChangePercentage30d":-26.13934,
            "priceChangePercentage24h":-4.63782,
            "priceChangePercentage200d":-74.57003,
            "marketCapChangePercentage24h":-4.62971,
            "priceChange24h":-0.0008410608839097,
            "marketCapChange24h":-39268.122562502,
            "priceChangePercentage7d":-7.91278
        },
        "projectCreationDate":1644828523000,
        "contracts":[
            {
                "chain":"moonbeam",
                "contract":"0x0e358838ce72d5e61e0018a2ffac4bec5f4c88d2"
            }
        ],
        "updatedAt":1722544694830,
        "category":"dex",
        "description":"StellaSwap is one of the first automated market-making (AMM), decentralized exchange (DEX) for the Moonbeam parachain network. The unique value proposition of StellaSwap is that we're committed in establishing a strong foundation with our native token, STELLA, as a governance token, diverse farms, a built in bridge and user-centered service. \r\n\r\nStellaSwap's main objective is to create a broader range of network effects to address the issues of liquidity in the DeFi space, instead of limiting ourselves to a single solution like many DEXs are doing now. This manifests itself in the diverse product suite of StellaSwap that will be explained in more details. Our products are structured in such a way that facilitates decentralized governance of STELLA holders, while continuing to innovate on the collective foundations by design.",
        "usersChange1d":{
            "moonbeam":-6.18556701030928
        }
    }
}
    ```

### Query a Category {: #query-a-category}

You can also query the API by [category](#category-and-tags). For example, you can retrieve information about all NFT projects with the following query:

```bash
https://apps.moonbeam.network/api/ds/v1/app-dir/projects?category=nfts
```

??? code "API Response to Querying NFT projects"

    ```json
    {
    "projects":[
        {
            "urls":{
                "telegram":"https://t.me/nfts2me",
                "website":"https://nfts2me.com/",
                "try":"https://nfts2me.com/",
                "twitter":"https://twitter.com/nfts2me",
                "medium":"https://nfts2me.medium.com/",
                "discord":"https://nfts2me.com/discord/"
            },
            "slug":"nfts2me",
            "createdAt":1699292617117,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"nfts2me-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":512,
                    "fileName":"nfts2me-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":512
                },
                "full":{
                    "width":3000,
                    "fileName":"nfts2me-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"NFTs2Me",
            "chains":[
                "moonbeam"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1673608509000,
            "shortDescription":"NFTs2Me is a toolkit for creating and managing NFT projects.",
            "contracts":[
                {
                    "chain":"moonbeam",
                    "contract":"0x2269bCeB3f4e0AA53D2FC43B1B7C5C5D13B119a5"
                }
            ],
            "updatedAt":1722498896566,
            "category":"nfts",
            "description":"NFTs2Me is a tool for creating and managing NFT projects. It includes features such as an art generator, delayed reveal, minting widget, token gating, and support for multiple blockchain platforms. It also offers customization options, an affiliate system, automatic logo and banner generation, and support for redeemable NFTs. It is user-friendly and suitable for those new to the world of NFTs.\n\nIn addition to these features, NFTs2Me also offers a minting widget and free IPFS hosting to make it simple to mint and store your NFTs securely and efficiently. The minting widget allows you to easily create and mint new NFTs, while the free IPFS hosting provides a secure and decentralized way to store your NFTs.",
            "id":"nfts2me",
            "tags":[
                "NFT",
                "Tool"
            ]
        },
        {
            "urls":{
                "telegram":"https://t.me/rmrkapp",
                "website":"https://singular.app/",
                "try":"https://singular.app/",
                "twitter":"https://twitter.com/RmrkSingular",
                "discord":"https://discord.gg/TjB6v5AGZz"
            },
            "slug":"singular-app",
            "createdAt":1699292616171,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"singular-app-logo-small.png",
                    "mimeType":"image/png",
                    "height":36
                },
                "large":{
                    "width":400,
                    "fileName":"singular-app-logo-large.png",
                    "mimeType":"image/png",
                    "height":400
                },
                "full":{
                    "width":3000,
                    "fileName":"singular-app-logo-full.png",
                    "mimeType":"image/png",
                    "height":3000
                }
            },
            "name":"Singular App",
            "chains":[
                "moonbeam"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1686240710000,
            "shortDescription":"The home of NFTs by @RmrkApp. Create and trade your nestable, equippable, soulbound, and multi-asset NFTs with us - no coding required.",
            "contracts":[
                
            ],
            "updatedAt":1722498914806,
            "category":"nfts",
            "description":"Singular is an NFT 2.0 marketplace that allows users to buy, sell, and trade both regular and advanced NFTs. Users can create and/or connect a wallet, browse digital items, and securely conduct transactions using blockchain technology.",
            "id":"singular-app",
            "tags":[
                "NFT Marketplaces"
            ]
        },
        {
            "urls":{
                "telegram":"https:/t.me/metacourtgg",
                "website":"https://www.metacourt.gg/",
                "try":"https://www.metacourt.gg/",
                "twitter":"https://twitter.com/metacourtgg",
                "medium":"https://metacourtgg.medium.com/",
                "discord":"https://discord.gg/9AnnfKCb39"
            },
            "slug":"metacourt",
            "createdAt":1699292616238,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"metacourt-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":512,
                    "fileName":"metacourt-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":512
                },
                "full":{
                    "width":3000,
                    "fileName":"metacourt-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"Metacourt",
            "chains":[
                "moonbeam"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1663756794000,
            "shortDescription":"Metacourt created NFTdeals for anyone who wants to become an influencer and trade their social media",
            "contracts":[
                
            ],
            "updatedAt":1722498888422,
            "category":"nfts",
            "description":"Influencer accelerator for anyone who wants to become an influencer in the space. We allow selling your social media through NFTs and joining influencer marketing campaigns.",
            "id":"metacourt",
            "tags":[
                "NFT Marketplaces"
            ]
        },
        {
            "urls":{
                "telegram":"https://t.me/tofuNFT",
                "website":"https://tofunft.com/",
                "try":"https://tofunft.com/",
                "twitter":"https://twitter.com/tofuNFT",
                "medium":"https://medium.com/tofunftofficial",
                "discord":"https://discord.com/invite/3wFUTZmTm7"
            },
            "slug":"tofunft",
            "createdAt":1699292615874,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"tofunft-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":400,
                    "fileName":"tofunft-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":400
                },
                "full":{
                    "width":3000,
                    "fileName":"tofunft-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"tofuNFT",
            "chains":[
                "moonbeam",
                "moonriver"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1644828523000,
            "shortDescription":"The largest multichain NFT marketplace",
            "contracts":[
                
            ],
            "updatedAt":1722498924881,
            "category":"nfts",
            "description":"tofuNFT.com is an NFT marketplace focused on GameFi and collectibles, rebranded from SCV’s NFT market. Enjoy exploring & trading with your buddies!",
            "id":"tofunft",
            "tags":[
                "NFT Marketplaces",
                "NFT"
            ]
        },
        {
            "urls":{
                "website":"https://d-book.io",
                "try":"https://d-book.io",
                "twitter":"https://twitter.com/dbook_io"
            },
            "slug":"d-book.io",
            "createdAt":1699292617021,
            "logo":{
                "small":{
                    "width":129,
                    "fileName":"d-book.io-logo-small.png",
                    "mimeType":"image/png",
                    "height":36
                },
                "large":{
                    "width":129,
                    "fileName":"d-book.io-logo-large.png",
                    "mimeType":"image/png",
                    "height":36
                },
                "full":{
                    "width":3000,
                    "fileName":"d-book.io-logo-full.png",
                    "mimeType":"image/png",
                    "height":3000
                }
            },
            "name":"D-book.io",
            "chains":[
                "moonbeam"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1682016612000,
            "shortDescription":"Buğra Ayan is a speaker,and university lecturer in Turkey who founded the Web3 Association Turkey.",
            "contracts":[
                {
                    "chain":"moonbeam",
                    "contract":"0x8d4BA02D0973749ad7c646DcaAa60BDC66F6F6D2"
                }
            ],
            "updatedAt":1722498866417,
            "category":"nfts",
            "description":"We are an NFT Book Platform that connects authors and the decentralized world, aiming for a transformation ecosystem.",
            "id":"d-book.io",
            "tags":[
                "NFT Marketplaces",
                "NFT"
            ]
        },
        {
            "urls":{
                "telegram":"https://t.me/BcmHuntGroup",
                "website":"https://bcmhunt.com/",
                "try":"https://bcmhunt.com/",
                "twitter":"https://twitter.com/bcmhunt",
                "medium":"https://medium.com/bcmhunt",
                "discord":"https://discord.com/invite/Ee9aJ287J2"
            },
            "slug":"blockchain-monster-hunt",
            "createdAt":1699292616780,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"blockchain-monster-hunt-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":510,
                    "fileName":"blockchain-monster-hunt-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":510
                },
                "full":{
                    "width":3000,
                    "fileName":"blockchain-monster-hunt-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"Blockchain Monster Hunt",
            "chains":[
                "moonbeam"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1644828523000,
            "shortDescription":"The First Multichain NFT Monster Hunt",
            "contracts":[
                
            ],
            "updatedAt":1722498855937,
            "category":"nfts",
            "description":"Blockchain Monster Hunt (BCMH) is the world’s first multi-chain game that runs entirely on the blockchain itself. Inspired by Pokémon-GO,BCMH allows players  to continuously explore brand new places on the blockchain to hunt and battle monsters. Each block on the blockchain is a unique digital space where a limited number of monsters (of the same DNA gene and rarity) may exist.  Players and collectors can hunt or battle for a chance to capture these unique monsters and to earn coins.",
            "id":"blockchain-monster-hunt",
            "tags":[
                "NFT",
                "Gaming",
                "GLMR Grants"
            ]
        },
        {
            "urls":{
                "website":"https://speedboat.studio/",
                "try":"https://speedboat.studio/",
                "twitter":"https://twitter.com/Speedboat_STDO",
                "medium":"https://medium.com/@speedboat_studio",
                "discord":"https://discord.gg/y7TQbtEWSV"
            },
            "slug":"speedboat.studio",
            "createdAt":1699292616328,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"speedboat.studio-logo-small.png",
                    "mimeType":"image/png",
                    "height":36
                },
                "large":{
                    "width":190,
                    "fileName":"speedboat.studio-logo-large.png",
                    "mimeType":"image/png",
                    "height":190
                },
                "full":{
                    "width":3000,
                    "fileName":"speedboat.studio-logo-full.png",
                    "mimeType":"image/png",
                    "height":3000
                }
            },
            "name":"Speedboat",
            "chains":[
                "moonbeam"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1657584952000,
            "shortDescription":"Your no-code Web3 toolkit",
            "contracts":[
                
            ],
            "updatedAt":1722498916466,
            "category":"nfts",
            "description":"Speedboat is a Web3 toolkit for everyone. Built on the idea that NFTs are not just expensive JPEGs, but programmable experiences.",
            "id":"speedboat.studio",
            "tags":[
                "NFT",
                "Tool"
            ]
        },
        {
            "urls":{
                "telegram":"https://t.me/+qGh0InPSPc1iMTNk",
                "website":"https://www.glmrapes.com/",
                "try":"https://www.glmrapes.com/",
                "twitter":"https://twitter.com/GLMRApes",
                "discord":"https://discord.com/invite/glmrapes"
            },
            "web3goContracts":[
                {
                    "name":"GLMR Apes: GLMR Ape",
                    "chain":"moonbeam",
                    "contract":"0x8fbe243d898e7c88a6724bb9eb13d746614d23d6"
                },
                {
                    "name":"GLMR Apes: GLMR Jungle",
                    "chain":"moonbeam",
                    "contract":"0xcb13945ca8104f813992e4315f8ffefe64ac49ca"
                }
            ],
            "currentTx":{
                "moonbeam":7830
            },
            "slug":"glmr-apes",
            "web3goIDs":[
                "GLMR Apes"
            ],
            "createdAt":1699292616827,
            "logo":{
                "small":{
                    "width":47,
                    "fileName":"glmr-apes-logo-small.png",
                    "mimeType":"image/png",
                    "height":36
                },
                "large":{
                    "width":528,
                    "fileName":"glmr-apes-logo-large.png",
                    "mimeType":"image/png",
                    "height":408
                },
                "full":{
                    "width":3000,
                    "fileName":"glmr-apes-logo-full.png",
                    "mimeType":"image/png",
                    "height":3000
                }
            },
            "name":"GLMR APES",
            "chains":[
                "moonbeam"
            ],
            "defiLLamaTvlExist":false,
            "usersChange7d":{
                "moonbeam":-66.6666666666667
            },
            "currentUsers":{
                "moonbeam":1531
            },
            "projectCreationDate":1644828523000,
            "shortDescription":"The first NFT collection on GLMR by & for the community",
            "contracts":[
                
            ],
            "updatedAt":1722547408370,
            "category":"nfts",
            "description":"GLIMMER APES is the first NFT collection on GLMR by & for the community. The longer you’re bonding with GLMR Apes and the friendlier their behavior. Join the troops as soon as possible to become an EARLY APE, take part in our giveaways and games and land in the GLMR APE VIP CLUB.",
            "id":"glmr-apes",
            "tags":[
                "NFT",
                "Gaming"
            ],
            "usersChange1d":{
                "moonbeam":0
            }
        },
        {
            "urls":{
                "website":"https://snakesoldiers.com",
                "try":"https://snakesoldiers.com",
                "twitter":"https://twitter.com/snakesoldiers",
                "github":"https://github.com/steven2308/snake-soldiers-contracts",
                "medium":"https://medium.com/@snakesoldiers/emoting-to-influence-the-hatch-df3eab7e45b8",
                "discord":"http://discord.gg/A6zQSz4YU4"
            },
            "slug":"snake-soldiers",
            "createdAt":1699292616971,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"snake-soldiers-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":400,
                    "fileName":"snake-soldiers-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":400
                },
                "full":{
                    "width":3000,
                    "fileName":"snake-soldiers-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"Snake Soldiers",
            "chains":[
                "moonbeam"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1691439275000,
            "shortDescription":"NFT game collection divided in 3 categories: Generals, Commanders and Soldiers🐍. Built on Moonbeam",
            "contracts":[
                {
                    "chain":"moonbeam",
                    "contract":"0x3ab955216BdD76f51fbe02A3fe237D6612BBD09F"
                }
            ],
            "updatedAt":1722498915320,
            "category":"nfts",
            "description":"Snake Soldiers is an NFT collection with a supply of at most 5k units, all unique and distributed among 3 ranks. Each snake will be usable inside a play to own game, where snakes will be the main characters, necessary to interact with the SerpenTerra ecosystem. This metaverse will be based on the RMRK 2.0 standard, making forward compatible and giving super powers to the NFTs.",
            "id":"snake-soldiers",
            "tags":[
                "NFT"
            ]
        },
        {
            "urls":{
                "telegram":"https://t.me/+LqmDOeGUQdRmYjVh%60%60",
                "website":"https://omni-x.io",
                "try":"https://omni-x.io",
                "twitter":"https://twitter.com/omnix_nft",
                "github":"https://github.com/Omni-X-NFT",
                "discord":"https://discord.gg/omni-x"
            },
            "slug":"omni-x",
            "createdAt":1699292617077,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"omni-x-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":107,
                    "fileName":"omni-x-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":108
                },
                "full":{
                    "width":3000,
                    "fileName":"omni-x-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"Omni-X",
            "chains":[
                "moonbeam"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1673811786000,
            "shortDescription":"The first natively omnichain NFT platform",
            "contracts":[
                
            ],
            "updatedAt":1722498898538,
            "category":"nfts",
            "description":"Omni X is an omnichain NFT protocol and marketplace that connects communities, creators, and enthusiasts across multiple blockchains. \n\nWe provide tooling for creating ONFT collections, bridging regular NFTs to ONFTs and grant access to unparalleled liquidity that allows users to buy and sell NFTs from any blockchain to any other blockchain.",
            "id":"omni-x",
            "tags":[
                "NFT Marketplaces",
                "Infrastructure"
            ]
        },
        {
            "urls":{
                "website":"https://www.publicpressure.io/",
                "try":"https://www.publicpressure.io/",
                "twitter":"https://twitter.com/jointhepressure",
                "discord":"https://discord.gg/publicpressure"
            },
            "slug":"publicpressure",
            "createdAt":1702283744356,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"publicpressure-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":400,
                    "fileName":"publicpressure-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":400
                },
                "full":{
                    "width":3000,
                    "fileName":"publicpressure-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"Public Pressure",
            "chains":[
                "moonriver"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1651597275000,
            "shortDescription":"Support your favorite artists, own their music, get rewarded.",
            "contracts":[
                
            ],
            "updatedAt":1722498907699,
            "category":"nfts",
            "description":"We are the web3 music platform powered by artists, labels and fans",
            "id":"publicpressure",
            "tags":[
                "NFT Marketplaces"
            ]
        },
        {
            "currentTx":{
                "moonbeam":8409
            },
            "web3goIDs":[
                "Moonbeans"
            ],
            "name":"Moonbeans",
            "currentUsers":{
                "moonbeam":1134
            },
            "coinGeckoId":"moonbeans",
            "shortDescription":"Galactic Co-Op & Profit sharing NFT platform and soon to be Metaverse",
            "id":"moonbeans",
            "tags":[
                "NFT Marketplaces"
            ],
            "urls":{
                "website":"https://moonbeans.io/",
                "twitter":"https://twitter.com/moonbeansio",
                "github":"https://github.com/m00nbeans",
                "discord":"https://discord.com/invite/qqE9aBPzQ9",
                "telegram":"https://t.me/moonbeansio",
                "try":"https://moonbeans.io/",
                "medium":"https://medium.com/@MoonBeans"
            },
            "web3goContracts":[
                {
                    "name":"Moonbeans: Beanie Distributor V2",
                    "chain":"moonbeam",
                    "contract":"0xda6367c6510d8f2d20a345888f9dff3eb3226b02"
                },
                {
                    "name":"Moonbeans: Marketplace V9",
                    "chain":"moonbeam",
                    "contract":"0x683724817a7d526d6256aec0d6f8ddf541b924de"
                },
                {
                    "name":"Moonbeans: Storefront Ownership V1",
                    "chain":"moonbeam",
                    "contract":"0x971dfedd548f2269e515957404cbbee1f507cd01"
                }
            ],
            "slug":"moonbeans",
            "createdAt":1699292615978,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"moonbeans-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":400,
                    "fileName":"moonbeans-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":400
                },
                "full":{
                    "width":3000,
                    "fileName":"moonbeans-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "chains":[
                "moonbeam",
                "moonriver"
            ],
            "defiLLamaTvlExist":false,
            "usersChange7d":{
                "moonbeam":0
            },
            "marketData":{
                "symbol":"beans",
                "marketCap":0,
                "priceChangePercentage1y":-62.22489,
                "currentPrice":0.062264,
                "priceChangePercentage14d":-13.93552,
                "contracts":{
                    
                },
                "priceChangePercentage60d":-44.93764,
                "priceChangePercentage30d":-33.587,
                "priceChangePercentage24h":-0.05451,
                "priceChangePercentage200d":-83.0363,
                "marketCapChangePercentage24h":0,
                "priceChange24h":-0.0000339560550113,
                "marketCapChange24h":0,
                "priceChangePercentage7d":-5.36696
            },
            "projectCreationDate":1644828523000,
            "contracts":[
                {
                    "chain":"moonbeam",
                    "contract":"0x65b09ef8c5a096c5fd3a80f1f7369e56eb932412"
                },
                {
                    "chain":"moonriver",
                    "contract":"0xC2392DD3e3fED2c8Ed9f7f0bDf6026fcd1348453"
                }
            ],
            "updatedAt":1722548296818,
            "category":"nfts",
            "description":"Moonbeans is a fully functional NFT marketplace launched on October 8th 2021, after releasing 465 Beanies into the Moonriver network to wreak havoc. The platform is still in beta, but has been performing incredibly well. With minimal fees for artists, traders, and project developers, Moonbeans aims to grow and aid the Moonrver network as a whole to develop, learn, and earn. With multiple collections now live (Beanies, Damned Pirates Society), minting (RivrMaids), Moonbeans is the heart of the Moonriver NFT ecosystem.",
            "usersChange1d":{
                "moonbeam":0
            }
        },
        {
            "urls":{
                "telegram":"https://t.me/blocsport",
                "website":"https://blocsport.one/",
                "try":"https://blocsport.one/",
                "twitter":"https://twitter.com/blocsport1",
                "medium":"https://blocsport1.medium.com/"
            },
            "slug":"blocsport-one",
            "createdAt":1699292616637,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"blocsport-one-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":400,
                    "fileName":"blocsport-one-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":400
                },
                "full":{
                    "width":3000,
                    "fileName":"blocsport-one-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"Blocsport.one",
            "chains":[
                "moonriver"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1644828523000,
            "shortDescription":"Web 3.0 metaverse, smart sports money, athlete NFT launchpad & assets tokenization",
            "contracts":[
                
            ],
            "updatedAt":1722498857332,
            "category":"nfts",
            "description":"Blocsport.one is a Swiss sports tech company founded in 2019 that is transforming the sports business by building a transparent and reliable sports ecosystem uniting athletes, clubs, and fans based on blockchain. Company owns NFTdeals.io exclusive marketplace and has the biometric-enabled football scouting DApp live. Blocsport.one helps the young promising athletes get the money and exposure for their career development, which is nobody else doing in the world.",
            "id":"blocsport-one",
            "tags":[
                "NFT"
            ]
        },
        {
            "urls":{
                "telegram":"https://t.me/mintverse",
                "website":"https://www.mintverse.com/",
                "try":"https://www.mintverse.com/",
                "twitter":"https://twitter.com/mintverse_",
                "medium":"https://medium.com/mintverse",
                "discord":"https://discord.com/invite/mhhnbvAaq9"
            },
            "slug":"mintverse",
            "createdAt":1702283733666,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"mintverse-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":400,
                    "fileName":"mintverse-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":400
                },
                "full":{
                    "width":3000,
                    "fileName":"mintverse-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"Mintverse",
            "chains":[
                "moonbeam"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1651597514000,
            "shortDescription":"Mint, Explore & Trade Liquid NFT Assets Across Multiple Chains",
            "contracts":[
                
            ],
            "updatedAt":1722498889300,
            "category":"nfts",
            "description":"Comprehensive NFT Aggregation Marketplace with a 0% trading fee",
            "id":"mintverse",
            "tags":[
                "NFT Marketplaces"
            ]
        },
        {
            "urls":{
                "telegram":"https://t.me/rmrkapp",
                "website":"https://upgradooor.app",
                "try":"https://upgradooor.app",
                "twitter":"https://x.com/rmrkapp",
                "github":"https://github.com/rmrk-team",
                "medium":"https://medium.com/rmrkapp"
            },
            "slug":"upgradooor",
            "createdAt":1699292616895,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"upgradooor-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":512,
                    "fileName":"upgradooor-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":512
                },
                "full":{
                    "width":3000,
                    "fileName":"upgradooor-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"Upgradooor",
            "chains":[
                "moonbeam",
                "moonriver"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1692259742000,
            "shortDescription":"Upgrade your NFT 1.0 collections to NFT 2.0 by wrapping them into advanced functionality",
            "contracts":[
                
            ],
            "updatedAt":1722498927244,
            "category":"nfts",
            "description":"As a collection issuer, use Upgradooor to initialize the process of upgrading your collection to NFT 2.0 if you are currently using ERC721.\n\nAs a holder, once the collection owner initiates the process, you can wrap any NFT you hold in that collection and instantly turn it into an equippable, multi-asset, composable NFT with no added risk.\n\nYou can always unwrap at will, and all the changes will still wait for you when you decide to re-claim the 2.0 wrapper again.\n\nUpgrading allows you to:\n\n- add more assets (outputs) to a legacy NFT, preventing needless airdrop spam\n- airdrop NFTs into the NFT itself, preventing detachment of context, and saving tremendous amounts of gas by letting people transfer just the parent NFT\n- define equippable settings and even achieve compatibility with other collections, for cross collection equippables and thus cross collection royalties and commissions\n- see your NFTs on Singular, and use GBM auctions as a unique and novel listing mechanic",
            "id":"upgradooor",
            "tags":[
                "NFT",
                "Tool"
            ]
        },
        {
            "urls":{
                "telegram":"https://t.me/moonfit_official_community",
                "website":"https://moonfit.xyz/",
                "try":"https://moonfit.xyz/",
                "twitter":"https://twitter.com/MoonFitOfficial",
                "discord":"https://discord.gg/hStdUVtHXp"
            },
            "slug":"moonfit",
            "createdAt":1702283734897,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"moonfit-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":400,
                    "fileName":"moonfit-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":400
                },
                "full":{
                    "width":3000,
                    "fileName":"moonfit-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"MoonFit",
            "chains":[
                "moonbeam"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1654692249000,
            "shortDescription":"Web3 & NFT Lifestyle App That Pays You Anytime You Burn Calories",
            "contracts":[
                
            ],
            "updatedAt":1722498891201,
            "category":"nfts",
            "description":"MoonFit is a Web3 Lifestyle App that promotes active living by rewarding users with tokens and NFTs anytime they burn calories through physical activities.",
            "id":"moonfit",
            "tags":[
                "NFT",
                "Gaming"
            ]
        },
        {
            "urls":{
                "telegram":"https://t.me/rmrkapp",
                "website":"https://rmrk.app/",
                "try":"https://rmrk.app/",
                "twitter":"https://twitter.com/rmrkapp",
                "discord":"https://discord.com/invite/bV9kQbVC99"
            },
            "slug":"rmrk",
            "createdAt":1699292615938,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"rmrk-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":400,
                    "fileName":"rmrk-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":400
                },
                "full":{
                    "width":3000,
                    "fileName":"rmrk-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"RMRK",
            "chains":[
                "moonbeam"
            ],
            "defiLLamaTvlExist":false,
            "marketData":{
                "symbol":"rmrk",
                "marketCap":5985029,
                "marketCapRank":1602,
                "priceChangePercentage1y":-64.99216,
                "currentPrice":0.62974,
                "priceChangePercentage14d":-24.26661,
                "contracts":{
                    "moonbeam":"0x524d524b4c9366be706d3a90dcf70076ca037ae3"
                },
                "priceChangePercentage60d":-51.72181,
                "priceChangePercentage30d":-30.11256,
                "priceChangePercentage24h":-2.58554,
                "priceChangePercentage200d":-75.55551,
                "marketCapChangePercentage24h":-2.50147,
                "priceChange24h":-0.01671434617594,
                "marketCapChange24h":-153554.8536219,
                "priceChangePercentage7d":-1.5052
            },
            "coinGeckoId":"rmrk",
            "projectCreationDate":1644828523000,
            "shortDescription":"Creators of NFTs 2.0 via ERC6059, ERC6220, ERC5773, EIP6381, and EIP6454.\nNFT equippables, future compatibility, reputation, and token balances.",
            "contracts":[
                
            ],
            "updatedAt":1722548302467,
            "category":"nfts",
            "description":"With the RMRK NFT Building Block System\nOur ERC NFT standards allow you to unlock the true potential of NFTs.\nTailored to work with each other, these EVM smart contracts will help you create your NFT projects of varying complexity.",
            "id":"rmrk",
            "tags":[
                "NFT",
                "Infrastructure"
            ]
        },
        {
            "urls":{
                "website":"https://www.mynft.com/",
                "try":"https://bridge.mynft.com/home",
                "twitter":"https://twitter.com/mynft"
            },
            "slug":"mynft",
            "createdAt":1699292616578,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"mynft-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":400,
                    "fileName":"mynft-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":400
                },
                "full":{
                    "width":3000,
                    "fileName":"mynft-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"myNFT",
            "chains":[
                "moonbeam"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1644828523000,
            "shortDescription":"The marketplace that puts the power back in your hands",
            "contracts":[
                
            ],
            "updatedAt":1722498895020,
            "category":"nfts",
            "description":"myNFT is the marketplace that puts the power back in your hands. It is a creative workshop, a trading platform and a discovery engine, helping you tell your story and share your passions, on your own terms. myNFT is built on decentralized technologies empowering you to create, trade, and discover. myNFT is built by Perpetual Altruism, a leader in the NFT space and the creator of charitable NFT publisher Cryptograph and the GBM auction system. Perpetual Altruism is backed by prominent investors and creators and is also the recipient of grants from the Web3 Foundation and the Moonbeam network for their work on the decentralized internet, which powers myNFT.",
            "id":"mynft",
            "tags":[
                "NFT Marketplaces",
                "GLMR Grants",
                "MOVR Grants"
            ]
        },
        {
            "urls":{
                "website":"https://readl.co/",
                "try":"https://readl.co/",
                "twitter":"https://twitter.com/readl_co",
                "medium":"https://medium.com/@readlnetwork",
                "discord":"https://discord.gg/XPTENepHqY"
            },
            "slug":"readl",
            "createdAt":1702283745749,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"readl-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":512,
                    "fileName":"readl-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":512
                },
                "full":{
                    "width":3000,
                    "fileName":"readl-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"Readl",
            "chains":[
                "moonriver"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1655885161000,
            "shortDescription":"Bringing the publishing industry to web3",
            "contracts":[
                
            ],
            "updatedAt":1722498910044,
            "category":"nfts",
            "description":"Readl is the protocol that provides publishers and storytellers with the infrastructure to publish their content on the blockchain, while providing a user-friendly platform to enjoy any story, in any format.",
            "id":"readl",
            "tags":[
                "NFT Marketplaces",
                "MOVR Grants"
            ]
        },
        {
            "urls":{
                "telegram":"https://t.me/rmrkapp",
                "website":"https://emotes.app",
                "try":"https://emotes.app",
                "twitter":"https://x.com/rmrkapp",
                "github":"https://github.com/rmrk-team",
                "medium":"https://medium.com/rmrkapp"
            },
            "slug":"emotes.app",
            "createdAt":1699292616951,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"emotes.app-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":512,
                    "fileName":"emotes.app-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":512
                },
                "full":{
                    "width":3000,
                    "fileName":"emotes.app-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"Emotes.app",
            "chains":[
                "moonbeam"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1692254489000,
            "shortDescription":"React on anyone's NFT - throw 💩 at those apes, give a 🤗 to those Pudgies!",
            "contracts":[
                
            ],
            "updatedAt":1722498871347,
            "category":"nfts",
            "description":"Emotes.app is a RMRK mini-app which allows you to send emotes / reactions to anyone's NFT. It utilizes RMRK's ERC7009 and is trivial to integrate into any project wanting to take advantage of the community's reactions to their NFTs.\n\nUse it to direct storylines, affect NFT egg hatching, or just do relative price comparison when influencers like one NFTs and dislike another!",
            "id":"emotes.app",
            "tags":[
                "NFT",
                "Social"
            ]
        },
        {
            "urls":{
                "telegram":"https://twitter.com/PolkaPets",
                "website":"https://www.polkapet.world/",
                "try":"https://www.polkapet.world/",
                "twitter":"https://twitter.com/PolkaPets",
                "medium":"https://polkapetworld.medium.com/"
            },
            "slug":"polkapet-world",
            "createdAt":1702283743596,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"polkapet-world-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":400,
                    "fileName":"polkapet-world-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":400
                },
                "full":{
                    "width":3000,
                    "fileName":"polkapet-world-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"PolkaPets",
            "chains":[
                "moonriver"
            ],
            "defiLLamaTvlExist":false,
            "marketData":{
                "priceChangePercentage60d":1206.42918,
                "symbol":"pets",
                "marketCap":0,
                "priceChangePercentage30d":619.39533,
                "priceChangePercentage200d":135.91624,
                "priceChangePercentage1y":355.00061,
                "currentPrice":0.00515699,
                "priceChangePercentage14d":-15.30948,
                "contracts":{
                    "moonriver":"0x1e0f2a75be02c025bd84177765f89200c04337da"
                },
                "priceChangePercentage7d":749.62625
            },
            "coinGeckoId":"polkapet-world",
            "projectCreationDate":1651157216000,
            "shortDescription":"Welcome to PolkaPet World",
            "contracts":[
                
            ],
            "updatedAt":1722548303208,
            "category":"nfts",
            "description":"An immersive NFT collection created in partnership with the biggest and best PolkaDot projects ",
            "id":"polkapet-world",
            "tags":[
                "NFT"
            ]
        },
        {
            "urls":{
                "website":"https://www.moonarines.com/",
                "try":"https://www.moonarines.com/",
                "discord":"https://discord.gg/bXhSyW8htW"
            },
            "slug":"moonarines",
            "createdAt":1702283733870,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"moonarines-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":400,
                    "fileName":"moonarines-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":400
                },
                "full":{
                    "width":3000,
                    "fileName":"moonarines-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"Moonarines",
            "chains":[
                "moonriver"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1654792422000,
            "shortDescription":"Be part of the conquest of the digital space",
            "contracts":[
                
            ],
            "updatedAt":1722498889804,
            "category":"nfts",
            "description":"The Moonarines are unique NFT characters starting soon on the Moonriver Network!\nWith the Moonarines, the NFT owners will be taken to an unforgettable adventure to explore the Cryptoverse!",
            "id":"moonarines",
            "tags":[
                "NFT"
            ]
        },
        {
            "urls":{
                "telegram":"https://t.me/NFTrade",
                "website":"https://nftrade.com/",
                "try":"https://nftrade.com/",
                "twitter":"https://twitter.com/NFTradeOfficial",
                "medium":"https://medium.com/@NFTrade",
                "discord":"https://discord.com/invite/SESqfsyw8k"
            },
            "slug":"nftrade",
            "createdAt":1699292616005,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"nftrade-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":400,
                    "fileName":"nftrade-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":400
                },
                "full":{
                    "width":3000,
                    "fileName":"nftrade-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"NFTrade",
            "chains":[
                "moonbeam",
                "moonriver"
            ],
            "defiLLamaTvlExist":false,
            "marketData":{
                "symbol":"nftd",
                "marketCap":234018,
                "marketCapRank":3653,
                "priceChangePercentage1y":-65.38449,
                "currentPrice":0.00502075,
                "priceChangePercentage14d":-7.09922,
                "contracts":{
                    
                },
                "priceChangePercentage60d":-27.37596,
                "priceChangePercentage30d":-14.12267,
                "priceChangePercentage24h":-2.22137,
                "priceChangePercentage200d":-56.66993,
                "marketCapChangePercentage24h":-2.16658,
                "priceChange24h":-0.00011406326237191,
                "marketCapChange24h":-5182.473845666,
                "priceChangePercentage7d":-6.88049
            },
            "coinGeckoId":"nftrade",
            "projectCreationDate":1644828523000,
            "shortDescription":"Create, Buy, Sell, Swap and Farm NFTs",
            "contracts":[
                
            ],
            "updatedAt":1722548304198,
            "category":"nfts",
            "description":"NFTrade is a multi-chain platform for NFT creation and trading. Seamlessly launch, mint, and swap non-fungible tokens. Earn digital collectibles. NFTrade places you at the heart of the NFT economy. Create, Buy, Sell, Swap and Farm NFTs. All chains, All NFTs, One Platform.",
            "id":"nftrade",
            "tags":[
                "NFT Marketplaces",
                "MOVR Grants"
            ]
        },
        {
            "urls":{
                "website":"https://www.pipcards.com/",
                "try":"https://www.pipcards.com/",
                "twitter":"https://twitter.com/pipcards",
                "discord":"https://discord.com/invite/hnSC7QjTHj"
            },
            "slug":"pipcards",
            "createdAt":1699292616371,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"pipcards-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":400,
                    "fileName":"pipcards-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":400
                },
                "full":{
                    "width":3000,
                    "fileName":"pipcards-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"PIP Cards",
            "chains":[
                "moonriver"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1651149583000,
            "shortDescription":"Post-generated NFT playing card decks",
            "contracts":[
                
            ],
            "updatedAt":1722498904704,
            "category":"nfts",
            "description":"PIPS is a first-of-its-kind NFT generative playing card project that will enable NFT holders to generate an entire deck of custom cards to be used cross-chain.",
            "id":"pipcards",
            "tags":[
                "NFT",
                "Gaming"
            ]
        },
        {
            "urls":{
                "website":"https://bithotel.io/",
                "twitter":"https://twitter.com/playbithotel",
                "github":"https://github.com/BitHotelOrg/bithotel-token-contracts",
                "discord":"https://discord.gg/RFFZNwxY9n",
                "telegram":"https://t.me/bithotelcommunity",
                "try":"https://bithotel.io/",
                "medium":"https://medium.com/@bithotelnftgame"
            },
            "slug":"bit-hotel",
            "createdAt":1702283710425,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"bit-hotel-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":500,
                    "fileName":"bit-hotel-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":500
                },
                "full":{
                    "width":3000,
                    "fileName":"bit-hotel-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"Bit Hotel",
            "chains":[
                "moonbeam"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1658743551000,
            "shortDescription":"Bit Hotel is a Social-first Play 2 Earn NFT Gaming Metaverse set in a Pixel-art Hotel.",
            "contracts":[
                {
                    "chain":"moonbeam",
                    "contract":"Not deployed yet"
                },
                {
                    "chain":"moonriver",
                    "contract":"Not deployed yet"
                }
            ],
            "updatedAt":1722498854706,
            "category":"nfts",
            "description":"In Bit Hotel users can compete to earn Bit Hotel tokens and acquire native NFTs. These NFTs have in-game utilities and consist of characters, hotel rooms, furniture and other assets that have their own unique perks. With over 250k Hotel Guests cross-channel, this nostalgic Hotel metaverse is taking people back to their 8bit upbringing.",
            "id":"bit-hotel",
            "tags":[
                "NFT",
                "Gaming"
            ]
        },
        {
            "tvlChange7d":{
                "moonriver":0.00190215150271202
            },
            "urls":{
                "website":"https://www.moonbeamdao.com/",
                "try":"https://www.moonbeamdao.com/",
                "twitter":"https://twitter.com/moonbeam_dao",
                "medium":"https://medium.com/@moonbeamdao",
                "discord":"https://discord.gg/AevrFzwZjk"
            },
            "web3goContracts":[
                {
                    "name":"MoonDAO: MDAO Token",
                    "chain":"moonbeam",
                    "contract":"0xc6342eab8b7cc405fc35eba7f7401fc400ac0709"
                }
            ],
            "currentTx":{
                "moonbeam":972
            },
            "slug":"moondao",
            "web3goIDs":[
                "MoonDAO"
            ],
            "createdAt":1699292616416,
            "tvlChange1d":{
                "moonriver":-0.0349944884006391
            },
            "logo":{
                "small":{
                    "width":25,
                    "fileName":"moondao-logo-small.png",
                    "mimeType":"image/png",
                    "height":36
                },
                "large":{
                    "width":330,
                    "fileName":"moondao-logo-large.png",
                    "mimeType":"image/png",
                    "height":475
                },
                "full":{
                    "width":3000,
                    "fileName":"moondao-logo-full.png",
                    "mimeType":"image/png",
                    "height":3000
                }
            },
            "name":"MoonDAO",
            "chains":[
                "moonbeam"
            ],
            "currentTVL":{
                "moonriver":76.75665
            },
            "currentUsers":{
                "moonbeam":229
            },
            "projectCreationDate":1648347145000,
            "shortDescription":"The first & only community art dao on moonbeam",
            "contracts":[
                
            ],
            "updatedAt":1722547637377,
            "category":"nfts",
            "description":"MoonDao is the first community Art Collection DAO on the Moonbeam network!\n\nWe aim to utilize input from our community to select high-end NFT’s. These NFT’s will be acquired with the MoonDao treasury and stored in the MoonDao Vault.\n\nMoon ownership grants access to DAO voting rights, future events, and additional holder perks outlined below. Welcome to the moon, we hope you stay.\n\n",
            "id":"moondao",
            "tags":[
                "NFT",
                "DAO"
            ]
        },
        {
            "urls":{
                "telegram":"https://t.me/raresama",
                "website":"https://raresama.com/",
                "try":"https://raresama.com/",
                "twitter":"https://twitter.com/RaresamaNFT",
                "discord":"https://discord.com/channels/938592318380982303/1010237900685840405"
            },
            "slug":"raresama",
            "createdAt":1699292615958,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"raresama-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":400,
                    "fileName":"raresama-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":400
                },
                "full":{
                    "width":3000,
                    "fileName":"raresama-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"Raresama",
            "chains":[
                "moonbeam"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1662528828000,
            "shortDescription":"Discover amazing Rare digital artwork",
            "contracts":[
                
            ],
            "updatedAt":1722498909462,
            "category":"nfts",
            "description":"Raresama brings the magic of owning a piece of artwork to your fingertips. Create or browse NFT art collections and enjoy a diverse mix of artists, genres, styles and movements.",
            "id":"raresama",
            "tags":[
                "NFT Marketplaces"
            ]
        },
        {
            "urls":{
                "telegram":"https://gal.xyz/telegram",
                "website":"https://galxe.com/",
                "try":"https://galxe.com/",
                "twitter":"https://twitter.com/Galxe",
                "medium":"https://blog.galxe.com/",
                "discord":"https://gal.xyz/discord"
            },
            "slug":"galxe",
            "createdAt":1699292616277,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"galxe-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":400,
                    "fileName":"galxe-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":400
                },
                "full":{
                    "width":3000,
                    "fileName":"galxe-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"Galxe",
            "chains":[
                "moonbeam"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1659868871000,
            "shortDescription":"Create Impactful Experiences With #Web3 Credentials. (Formerly Project Galaxy) ",
            "contracts":[
                
            ],
            "updatedAt":1722498876438,
            "category":"nfts",
            "description":"Galxe is the leading Web3 credential data network in the world. A collaborative credential infrastructure enabling brands and developers to engage communities and build robust products in Web3.",
            "id":"galxe",
            "tags":[
                "NFT",
                "Social",
                "Tool"
            ]
        },
        {
            "urls":{
                "telegram":"http://t.me/MoonsamaNFT",
                "website":"https://moonsama.com/",
                "try":"https://moonsama.com/",
                "twitter":"https://twitter.com/MoonsamaNFT",
                "discord":"discord.gg/moonsama"
            },
            "slug":"moonsama",
            "createdAt":1702283735408,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"moonsama-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":512,
                    "fileName":"moonsama-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":512
                },
                "full":{
                    "width":3000,
                    "fileName":"moonsama-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"Moonsama",
            "chains":[
                "moonriver",
                "moonbeam"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1651156798000,
            "shortDescription":"Let's build the multiverse",
            "contracts":[
                
            ],
            "updatedAt":1722498892389,
            "category":"nfts",
            "description":"Moonsama’s protocol for bi-directional bridging of on-chain digital assets and off-chain applications. This is how we connect web2.0 games, metaverses and blockchains. It enables new games, development and community fun from across the Kusamaverse and beyond!",
            "id":"moonsama",
            "tags":[
                "NFT",
                "Gaming"
            ]
        },
        {
            "urls":{
                "website":"https://smartstamp.com/",
                "try":"https://smartstamp.com/",
                "discord":"https://discord.gg/kajPqvZY"
            },
            "slug":"smartstamp",
            "createdAt":1699292617058,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"smartstamp-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":436,
                    "fileName":"smartstamp-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":436
                },
                "full":{
                    "width":3000,
                    "fileName":"smartstamp-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"SmartStamp",
            "chains":[
                "moonbeam",
                "moonriver"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1675081766000,
            "shortDescription":"SmartStamp is the pioneering new standard in identification and authentication for the art world.",
            "contracts":[
                
            ],
            "updatedAt":1722498915044,
            "category":"nfts",
            "description":"Developed over more than a decade, SmartStamp’s app uses patented AI technology that is designed to read and record artworks’ surface characteristics– offering artists, collectors, institutions, and all arts and culture stakeholders a way to securely and immutably link physical objects to their digital fingerprints on the blockchain. Using the SmartStamp app is as simple as taking a picture, making the groundbreaking security and timestamping power of blockchain technology accessible to anyone who can use a smartphone.",
            "id":"smartstamp",
            "tags":[
                "NFT"
            ]
        },
        {
            "urls":{
                "telegram":"https://t.me/yusernetwork",
                "website":"https://yuser.network/",
                "try":"https://yuser.network/",
                "twitter":"https://twitter.com/yuser",
                "medium":"https://medium.com/yuser",
                "discord":"https://discord.com/invite/uRRxnfAjhY"
            },
            "slug":"yuser",
            "createdAt":1699292616605,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"yuser-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":512,
                    "fileName":"yuser-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":512
                },
                "full":{
                    "width":3000,
                    "fileName":"yuser-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"Yuser",
            "chains":[
                "moonriver"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1644828523000,
            "shortDescription":"The first NFT social networking app- by creators, for creators",
            "contracts":[
                
            ],
            "updatedAt":1722498932483,
            "category":"nfts",
            "description":"Yuser’s mission is to build an ecosystem of interconnected applications that put power back into the hands of users by giving them full control over their content, data, and personal networks. Developers can connect via an API to instantly gain access to millions of users and incentivize them to try their product by paying them with a token.",
            "id":"yuser",
            "tags":[
                "NFT Marketplaces",
                "GLMR Grants",
                "MOVR Grants"
            ]
        },
        {
            "urls":{
                "telegram":"https://t.me/cryptosoots",
                "website":"https://raregems.io/my#",
                "try":"https://raregems.io/my#",
                "twitter":"https://twitter.com/RareGems_io"
            },
            "slug":"rare-gems",
            "createdAt":1702283745336,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"rare-gems-logo-small.png",
                    "mimeType":"image/png",
                    "height":36
                },
                "large":{
                    "width":360,
                    "fileName":"rare-gems-logo-large.png",
                    "mimeType":"image/png",
                    "height":360
                },
                "full":{
                    "width":3000,
                    "fileName":"rare-gems-logo-full.png",
                    "mimeType":"image/png",
                    "height":3000
                }
            },
            "name":"Rare Gems",
            "chains":[
                "moonriver",
                "moonbeam"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1652705611000,
            "shortDescription":"Multichain NFT marketplace.",
            "contracts":[
                
            ],
            "updatedAt":1722498909205,
            "category":"nfts",
            "description":"Multichain NFT marketplace\nCreated by \n@cryptosoots",
            "id":"rare-gems",
            "tags":[
                "NFT Marketplaces"
            ]
        },
        {
            "urls":{
                "telegram":"https://t.me/rmrkapp",
                "website":"https://wizard.rmrk.dev",
                "try":"https://wizard.rmrk.dev",
                "twitter":"https://x.com/rmrkapp",
                "github":"https://github.com/rmrk-team",
                "medium":"https://medium.com/rmrkapp"
            },
            "slug":"rmrk-wizard",
            "createdAt":1699292616919,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"rmrk-wizard-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":512,
                    "fileName":"rmrk-wizard-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":512
                },
                "full":{
                    "width":3000,
                    "fileName":"rmrk-wizard-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"RMRK Wizard",
            "chains":[
                "moonbeam",
                "moonriver"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1692255253000,
            "shortDescription":"A no-code-but-code wizard UI for building NFTs 2.0",
            "contracts":[
                
            ],
            "updatedAt":1722498911520,
            "category":"nfts",
            "description":"A simple UI to put together NFT 2.0 legos created by the RMRK.app team. Use this tool to get started developing advanced NFT collections by picking from a set of functions you need, and the tool will compose code for you which only needs final tweaks before being deployed!",
            "id":"rmrk-wizard",
            "tags":[
                "NFT",
                "Tool",
                "Developer Tools"
            ]
        },
        {
            "urls":{
                "telegram":"https://t.me/evelonapp",
                "website":"https://platform.evelon.app/",
                "try":"https://www.evelon.app/",
                "twitter":"https://twitter.com/EvelonApp"
            },
            "slug":"evelon-app",
            "createdAt":1699292616145,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"evelon-app-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":512,
                    "fileName":"evelon-app-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":512
                },
                "full":{
                    "width":3000,
                    "fileName":"evelon-app-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"Evelon.App",
            "chains":[
                "moonbeam"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1690486894000,
            "shortDescription":"Transform the way you create and bring to life your own unique DNFTs, with the revolutionary platform that combines cutting-edge AI technology.",
            "contracts":[
                
            ],
            "updatedAt":1722498873048,
            "category":"nfts",
            "description":"Evelon is a no code platform that allows you to create and deploy dynamic NFTs with ease. This project is a game changer in the world of NFTs and image generation. Evelon uses AI to generate high-quality images, making it possible to create NFTs with unique visuals that are both dynamic and engaging.",
            "id":"evelon-app",
            "tags":[
                "NFT",
                "Tool"
            ]
        },
        {
            "urls":{
                "website":"https://mintlabz.io/",
                "try":"https://app.mintlabz.io/",
                "twitter":"https://twitter.com/mintlabz",
                "medium":"https://blog.mintlabz.io/",
                "discord":"https://discord.com/invite/BRF2PEetea"
            },
            "slug":"mintlabz",
            "createdAt":1712311518649,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"mintlabz-logo-small.png",
                    "mimeType":"image/png",
                    "height":36
                },
                "large":{
                    "width":400,
                    "fileName":"mintlabz-logo-large.png",
                    "mimeType":"image/png",
                    "height":400
                },
                "full":{
                    "width":3000,
                    "fileName":"mintlabz-logo-full.png",
                    "mimeType":"image/png",
                    "height":3000
                }
            },
            "name":"Mintlabz",
            "chains":[
                "moonbeam"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1712189524,
            "shortDescription":"MintLabz is a complete crosschain NFT solution at zero cost.",
            "contracts":[
                
            ],
            "updatedAt":1722498889042,
            "category":"nfts",
            "description":"MintLabz aims to establish a digital NFT minting platform for third party projects to create NFT collections with utilities to reward the NFT holder. Our mission is to become the number one choice for providing complete cross-chain NFT solutions to B2B customers.",
            "id":"mintlabz",
            "tags":[
                "nfts"
            ]
        },
        {
            "urls":{
                "telegram":"https://t.me/golempark",
                "website":"https://golempark.com",
                "try":"https://golempark.com",
                "twitter":"https://twitter.com/golempark",
                "discord":"https://discord.gg/rNvtdHN8q7"
            },
            "slug":"golem-park",
            "createdAt":1699292617039,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"golem-park-logo-small.png",
                    "mimeType":"image/png",
                    "height":36
                },
                "large":{
                    "width":512,
                    "fileName":"golem-park-logo-large.png",
                    "mimeType":"image/png",
                    "height":512
                },
                "full":{
                    "width":3000,
                    "fileName":"golem-park-logo-full.png",
                    "mimeType":"image/png",
                    "height":3000
                }
            },
            "name":"Golem Park",
            "chains":[
                "moonbeam"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1676839105000,
            "shortDescription":"Golem Park is holders friendly NFT collection. P2E blockchain game, $GP Token, Staking Pools & more",
            "contracts":[
                {
                    "chain":"moonbeam",
                    "contract":"0x74746524f5A31F08e0528FaA704C2c5d8d116506"
                }
            ],
            "updatedAt":1722498878088,
            "category":"nfts",
            "description":"First Time In Crypto History Token Burning Campaign!\n30% Of Total Token Supply Will Be Burned In 30 Days.\n\nAfter Minting We Are Going To Release Deflationary $GP Token & 50% Of Total Supply Will Be Distributed To All $GP NFT Holders, 1 NFT = 5 000 000 Tokens. Then 30 Days Each Day We'll Burn 1% Of Total Token Supply To Ensure Token Price Will Go UP!\n\nWorld Of Golems is a decentralized Play-To-Earn blockchain game.\nOnce You Become Golem Park NFT Holder You Will Be Able To Participate in the WoG Game, Own Countries And Display Your Message On Them.\n\nThe Leaderboard Shows Of TOP 5 Wealthiest Countries & Every Month Owners Of These Countries Will Be Rewarded With $GLMR.",
            "id":"golem-park",
            "tags":[
                "NFT"
            ]
        },
        {
            "urls":{
                "telegram":"https://t.me/rarible",
                "website":"https://rarible.com/",
                "try":"https://rarible.com/",
                "twitter":"https://x.com/rarible",
                "discord":"https://discord.com/invite/rarible"
            },
            "slug":"rarible",
            "createdAt":1722498909701,
            "logo":{
                "small":{
                    "width":429,
                    "fileName":"rarible-small.png",
                    "mimeType":"image/png",
                    "height":121
                },
                "large":{
                    "width":858,
                    "fileName":"rarible-medium.png",
                    "mimeType":"image/png",
                    "height":242
                },
                "full":{
                    "width":1716,
                    "fileName":"rarible-large.png",
                    "mimeType":"image/png",
                    "height":485
                }
            },
            "name":"Rarible",
            "chains":[
                "moonbeam"
            ],
            "shortDescription":"Rarible - NFT Marketplace for Brands, Communities and Traders",
            "projectCreationDate":1721872843,
            "contracts":[
                
            ],
            "updatedAt":1722498909701,
            "category":"nfts",
            "description":"Discover, sell and buy NFTs on Rarible! Our aggregated NFT marketplace for Ethereum NFTs and Polygon NFTs powers brands, collections and creator marketplaces.",
            "id":"rarible",
            "featured":false,
            "tags":[
                "NFT"
            ]
        },
        {
            "urls":{
                "website":"https://neoncrisis.io/",
                "try":"https://neoncrisis.io/",
                "twitter":"https://twitter.com/NeonCrisisNFT",
                "discord":"https://discord.gg/MVVjT9k9eD"
            },
            "slug":"neoncrisis-io",
            "createdAt":1702283737907,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"neoncrisis-io-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":319,
                    "fileName":"neoncrisis-io-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":319
                },
                "full":{
                    "width":3000,
                    "fileName":"neoncrisis-io-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"Neon Crisis",
            "chains":[
                "moonriver"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1654792548000,
            "shortDescription":"6,008 heroes on the $MOVR network. A $RMRK powered metaverse featuring battle simulations, equipables, and more!",
            "contracts":[
                
            ],
            "updatedAt":1722498896060,
            "category":"nfts",
            "description":"",
            "id":"neoncrisis-io",
            "tags":[
                "NFT",
                "Gaming"
            ]
        },
        {
            "urls":{
                "telegram":"https://t.me/xp_network",
                "website":"https://xp.network/",
                "try":"https://xp.network/",
                "twitter":"https://twitter.com/xpnetwork_",
                "discord":"https://discord.com/invite/g3vkcsmd38"
            },
            "slug":"xp-network",
            "createdAt":1699292615205,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"xp-network-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":400,
                    "fileName":"xp-network-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":400
                },
                "full":{
                    "width":3000,
                    "fileName":"xp-network-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"XP Network",
            "chains":[
                "moonbeam"
            ],
            "defiLLamaTvlExist":false,
            "projectCreationDate":1673327644000,
            "shortDescription":"A powerful NFT bridge trusted by all major blockchains ",
            "contracts":[
                
            ],
            "updatedAt":1722498932103,
            "category":"nfts",
            "description":"We build software tools that enable experienced developers and non-coding blockchain community members to move their assets seamlessly and intuitively between versatile distributed ledgers. By doing so, we encourage unlimited growth of exchange and trade between otherwise isolated ecosystems. We enable them to enrich each other technologically with insights and discoveries. To gain access to new, previously inaccessible markets with users hungry for fresh ideas and technologies to invest in.",
            "id":"xp-network",
            "tags":[
                "NFT",
                "Bridges"
            ]
        },
        {
            "urls":{
                "website":"https://www.damnedpiratessociety.io/",
                "try":"https://www.damnedpiratessociety.io/",
                "twitter":"https://twitter.com/TheDPSproject",
                "discord":"https://discord.com/invite/TheDamnedPiratesSociety"
            },
            "web3goContracts":[
                {
                    "name":"Damned Pirates Society: DPSArtifact Token",
                    "chain":"moonriver",
                    "contract":"0xcd84ddadc45a25b02e1a6a5520171487a98e6155"
                },
                {
                    "name":"Damned Pirates Society: DPS Token",
                    "chain":"moonriver",
                    "contract":"0xb6e9e605aa159017173caa6181c522db455f6661"
                },
                {
                    "name":"Damned Pirates Society: DSPFlagship Token",
                    "chain":"moonriver",
                    "contract":"0x3822063a3f1aad3fd0b894e2a8f238ccca7c2d00"
                },
                {
                    "name":"Damned Pirates Society: DSPVoyage Token",
                    "chain":"moonriver",
                    "contract":"0x7b2e778453ab3a0d946c4620fb38a0530a434e15"
                },
                {
                    "name":"Damned Pirates Society: DOUBLOON Token",
                    "chain":"moonriver",
                    "contract":"0xe413a631e8a9a10958d9b7c64157449eae7c2064"
                }
            ],
            "currentTx":{
                "moonriver":20402
            },
            "slug":"damned-pirates-society",
            "web3goIDs":[
                "Damned Pirates Society"
            ],
            "createdAt":1699292616058,
            "logo":{
                "small":{
                    "width":36,
                    "fileName":"damned-pirates-society-logo-small.jpeg",
                    "mimeType":"image/jpeg",
                    "height":36
                },
                "large":{
                    "width":400,
                    "fileName":"damned-pirates-society-logo-large.jpeg",
                    "mimeType":"image/jpeg",
                    "height":400
                },
                "full":{
                    "width":3000,
                    "fileName":"damned-pirates-society-logo-full.jpeg",
                    "mimeType":"image/jpeg",
                    "height":3000
                }
            },
            "name":"Damned Pirates Society",
            "chains":[
                "moonriver"
            ],
            "defiLLamaTvlExist":false,
            "currentUsers":{
                "moonriver":2000
            },
            "projectCreationDate":1644828523000,
            "shortDescription":"Eclectic pirate-based NFT project with utility",
            "contracts":[
                
            ],
            "updatedAt":1722547421801,
            "category":"nfts",
            "description":"A long time ago the Fortune’s Grasp was carrying families to settle on The Islands and start a new life. In the middle of their voyage they encountered a fearsome maelstrom. The Captain and his crew worked tirelessly to keep the ship afloat. Badly damaged, the Ship limped to the edges of the storm. It was taking on water and the cries of terrified children could be heard above the crashing waves. Another ship appeared on the horizon, it’s light glowing brightly against the dark night. The Captain of the Fortune’s Grasp ordered his crew to evacuate the families, but the fifty crew members ignored the Captain, abandoning ship, taking all means of escape with them. The Captain, left on the sinking ship, cursed the cowardly crew for damning those innocent souls to the watery depths. Those Forsaken Fifty were marked with The Black Spot, doomed to row the high seas until the Reaper came to claim his mutinous crew to serve on the Ship Of The Damned. However, if they could convince another soul to take their place at the oars, protection would be offered by those Pirates who’ve cheated the Reaper before. Those who’ve served and survived are welcome in the Damned Pirates Society.\r\n\r\nThe Damned Pirate Society is an Profile Picture NFT with inbuilt utility. Stake your Pirate for Treasure Maps(TMAP) and save these for your Doubloon farming voyages on our upcoming, skill based gamified contracts.",
            "id":"damned-pirates-society",
            "tags":[
                "NFT",
                "Gaming",
                "GLMR Grants"
            ]
        }
    ],
    "count":40
}
    ```

Below are all possible categories and their respective parameters for querying the API. Ensure you query the API with the parameter formatted exactly as shown in lowercase.

| Category | API Parameter |
|:--------:|:-------------:|
| Bridges  |   `bridges`   |
|   DAO    |     `dao`     |
|   DEX    |     `dex`     |
|   DeFi   |    `defi`     |
|  Gaming  |   `gaming`    |
| Lending  |   `lending`   |
|   NFTs   |    `nfts`     |
|  Other   |    `other`    |
|  Social  |   `social`    |
| Wallets  |   `wallets`   |


### Query a Chain {: #query-a-chain}

The following queries can be used to query all of the listed projects on Moonbeam or Moonriver. Note that Moonbase Alpha is not a supported network in the DApp Directory.

=== "Moonbeam"

    ```bash
    https://apps.moonbeam.network/api/ds/v1/app-dir/projects?chain=moonbeam
    ```

=== "Moonriver"

    ```bash
    https://apps.moonbeam.network/api/ds/v1/app-dir/projects?chain=moonriver
    ```

<div class="page-disclaimer">
    You are responsible for checking and validating the accuracy and truthfulness of all content. You are also responsible for doing your own diligence to understand the applicable risks present, including selection, performance, security, accuracy, or use of any third-party information.  All information contained herein is subject to modification without notice.
</div>
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/learn/platform/glossary/
--- BEGIN CONTENT ---
---
title: Glossary
description: We've compiled a glossary of terms related to Polkadot that'll make it easier to learn more about the ecosystem.
categories: Reference
---

# Glossary

There's a great deal of terminology that's specific to Polkadot, Substrate, and the emerging Parity/Web3 ecosystem. We've compiled a list of terms we think you'll want to know as you review the Moonbeam documentation, plans, and tutorials.

### Collators {: #collators }

One of the key network participants needed to support parachains within the Polkadot Network.  In Moonbeam, collators are the nodes that are responsible for block production and for submitting produced blocks up to the Polkadot relay chain for finalization.

### Delegators {: #delegators }

Moonbeam token holders who stake tokens, vouching for specific collator candidates on the parachain. Any user that holds a minimum amount of tokens as [free balance](https://wiki.polkadot.com/learn/learn-accounts/#balance-types#balance-types){target=\_blank} can become a delegator by staking their tokens.

### Nominators {: #nominators }

Relay chain token holders who select to "back" a validator. They can receive part of the validator's reward, but are subject to slashing of their staked tokens in case the validator misbehaves. A nominator can back up to 16 validators, and their bond is fully distributed between the backed validators that were selected for the validator set.

### Nominated Proof of Stake {: #nominated-proof-of-stake }

The mechanism used by Polkadot for selecting its block validator set to maximize chain security. At its core, it is a Proof-of-Stake system (PoS) in which nominators back validators. The latter with the highest backing are selected to be part of the validator set for a session. The stake of a validator is slashed in case of misbehavior. Thus, nominators are expected to do due diligence on the validators they nominate.

### Parachains {: #parachains }

A blockchain which has a slot and is connected to Polkadot. Parachains receive shared security from Polkadot and the ability to interact with other parachains on the Polkadot network. They must lock DOT, the native relay chain token, to secure a slot for a specific period (up two years).

### Parathreads {: #parathreads }

A blockchain which can connect to Polkadot.  Parathreads are able to interact with other members of the Polkadot network, but they bid for block finalization (in DOT) on a block-to-block basis. They compete with other parathreads for block finalization, meaning that the block with the highest bid is selected to be finalize in that round.

### Polkadot {: #polkadot }

A network of connected blockchains that provides shared security and the ability to interact between chains.  Polkadot is built using the Substrate development framework.  Chains that connect to Polkadot are called parachains.

### Relay Chain {: #relay-chain }

The backbone blockchain supporting the Polkadot network.  Parachains connect to the relay chain and use it for shared security and message passing.  Validators on the relay chain help secure the parachains.

### Smart Contract {: #smart-contract }

A [smart contract](https://en.wikipedia.org/wiki/Smart_contract){target=\_blank} is a computer program or a transaction protocol that is intended to automatically execute, control, or document legally relevant events and actions according to the terms of a contract or an agreement. Smart contracts intend to reduce the need for trusted intermediators, arbitrations, and enforcement costs, as well as reduce fraud losses and malicious and accidental exceptions.

### Substrate {: #substrate }

A Rust-based blockchain development framework created by Parity Technologies based on their experience implementing multiple blockchain clients.  Substrate comes with many modules and functionalities that are needed when building a blockchain, including P2P networking, consensus mechanisms, staking, cryptocurrency, on-chain governance modules, and more.  It dramatically reduces the time and engineering effort required to implement a blockchain. Substrate is now part of the [Polkadot SDK](https://polkadot.com/platform/sdk/){target=\_blank}.

### Substrate Frame Pallets {: #substrate-frame-pallets }

Substrate Frame Pallets are a collection of Rust-based modules, providing the functionality required for building a blockchain.  

### Validators {: #validators }

A node that secures the Polkadot relay chain by staking DOT in the network, which is slashed if they misbehave. They finalize blocks from collators on parachains and also participate on consensus for the next relay chain block with other validators.

### WebAssembly/Wasm {: #webassemblywasm }

WebAssembly is an open standard that defines a portable binary code format. It is supported by different programming languages, compilers, and browsers.
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/builders/build/historical-updates/
--- BEGIN CONTENT ---
---
title: Historical Updates
description: An overview of the historical updates made on Moonbeam and Moonriver, such as migrations and bug fixes applied to the Moonbeam source code.
categories: Reference
---

# Historical Updates

## Introduction {: #introduction }

This page overviews historical updates on Moonbeam and Moonriver, such as bug fixes to the Moonbeam source code and data migrations applied.

This page aims to provide information about unexpected behaviors or data inconsistencies associated with updates that require forced data migrations.

## Bugs {: #bugs }

#### Invalid Transactions Stored {: #invalid-transactions-stored }

For invalid transactions where the transaction cost couldn't be paid, the EVM pallet inserted the transaction metadata into storage instead of discarding it because there was no transaction cost validation. As a result, the runtime storage was unnecessarily bloated with invalid transaction data.

This bug only impacted Moonriver and Moonbase Alpha and existed during the following runtimes and block ranges:

|    Network     | Introduced | Fixed | Impacted Block Range |
|:--------------:|:----------:|:-----:|:--------------------:|
|   Moonriver    |    RT49    | RT600 |      0 - 455106      |
| Moonbase Alpha |    RT40    | RT600 |      0 - 675175      |

For more information, you can review the [relative Frontier PR on GitHub](https://github.com/polkadot-evm/frontier/pull/465){target=\_blank}.

---

#### Ethereum Fees Weren't Sent to Treasury {: #ethereum-fees-to-treasury }

The Moonbeam transaction fee model before Runtime 3401 and the passage of [MB101](https://forum.moonbeam.network/t/proposal-mb101-burn-100-of-transaction-fees-on-moonbeam/2022){target=\_blank} mandated a 20% allocation of fees sent to the on-chain Treasury and 80% burned as a deflationary force. However, before runtime 800, Ethereum transactions did not correctly allocate 20% of the transaction fees to the on-chain Treasury.

This bug only impacted Moonriver and Moonbase Alpha and existed during the following runtimes and block ranges:

|    Network     | Introduced | Fixed | Impacted Block Range |
|:--------------:|:----------:|:-----:|:--------------------:|
|   Moonriver    |    RT49    | RT800 |      0 - 684728      |
| Moonbase Alpha |    RT40    | RT800 |      0 - 915684      |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/732){target=\_blank}.

---

#### Missing Refunds {: #missing-refunds }

Moonbeam is configured to set the existential deposit to 0, meaning that accounts do not need a minimum balance to be considered active. For Substrate-based chains with this configuration, some refunds were missing from zeroed accounts because the account was interpreted as not existing.

This bug existed during the following runtimes and block ranges:

|    Network     | Introduced | Fixed  | Impacted Block Range |
|:--------------:|:----------:|:------:|:--------------------:|
|    Moonbeam    |   RT900    | RT1001 |       0 - 5164       |
|   Moonriver    |    RT49    | RT1001 |     0 - 1052241      |
| Moonbase Alpha |    RT40    | RT1001 |     0 - 1285915      |

For more information, you can review the [relative Frontier PR](https://github.com/polkadot-evm/frontier/pull/509){target=\_blank} and the associated [Substrate PR on GitHub](https://github.com/paritytech/substrate/issues/10117){target=\_blank}.

---

#### Incorrect Collator Selection {: #incorrect-collator-selection }

The total delegations for collator candidates were not correctly updated when a delegation was increased via the `delegatorBondMore` extrinsic. This led to issues where the increased delegation amount wasn't included in the candidates' total amount bonded, which is used to determine which candidates are in the active set of collators. As a result, some candidates may not have been selected to be in the active set when they should have been, impacting their own and their delegators' rewards.

This bug existed during the following runtimes and block ranges:

|    Network     | Introduced | Fixed  | Impacted Block Range |
|:--------------:|:----------:|:------:|:--------------------:|
|    Moonbeam    |   RT900    | RT1300 |      0 - 524762      |
|   Moonriver    |    RT49    | RT1300 |     0 - 1541735      |
| Moonbase Alpha |    RT40    | RT1300 |     0 - 1761128      |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/1291){target=\_blank}.

---

#### New Account Event Bug {: #new-account-event }

The `System.NewAccount` event is emitted when a new account is created. However, a bug prevented this event from being emitted for some accounts at creation time. A hotfix was applied that patched the impacted accounts and emitted the `System.NewAccount` at a later time.

The hotfix was applied in the following block ranges:

|    Network     |                                                              Block Range                                                              |
|:--------------:|:-------------------------------------------------------------------------------------------------------------------------------------:|
|    Moonbeam    | [1041355 - 1041358 and 1100752](https://moonbeam.subscan.io/extrinsic?module=evm&call=hotfix_inc_account_sufficients){target=\_blank} |
|   Moonriver    |      [1835760 - 1835769](https://moonriver.subscan.io/extrinsic?module=evm&call=hotfix_inc_account_sufficients){target=\_blank}       |
| Moonbase Alpha |  [2097782 - 2097974](https://moonbase.subscan.io/extrinsic?address=&module=evm&call=hotfix_inc_account_sufficients){target=\_blank}   |

This bug existed during the following runtimes and block ranges:

|    Network     | Introduced | Fixed  | Impacted Block Range |
|:--------------:|:----------:|:------:|:--------------------:|
|    Moonbeam    |   RT900    | RT1401 |      0 - 915320      |
|   Moonriver    |    RT49    | RT1401 |     0 - 1705939      |
| Moonbase Alpha |    RT40    | RT1400 |     0 - 1962557      |

For more information, you can review the [relative Frontier PR on GitHub](https://github.com/moonbeam-foundation/frontier/pull/46/files){target=\_blank}.

---

#### Incorrect Timestamp Units {: #incorrect-timestamp-units }

EIP-2612 and Ethereum blocks deal with timestamps in seconds; however, the Substrate timestamp pallet that Moonbeam implements uses milliseconds. This only affected the EIP-2612 implementation, not the `block.timestamp` value.

This bug existed during the following runtimes and block ranges:

|    Network     | Introduced | Fixed  | Impacted Block Range |
|:--------------:|:----------:|:------:|:--------------------:|
|    Moonbeam    |   RT900    | RT1606 |     0 - 1326697      |
|   Moonriver    |    RT49    | RT1605 |     0 - 2077598      |
| Moonbase Alpha |    RT40    | RT1603 |     0 - 2285346      |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/1451){target=\_blank}.

---

#### Substrate Tips Missing Treasury Distribution {: #substrate-tips }

Tips for Substrate-based transactions weren't handled properly. The entire portion of the tip was burned because it was not handled in the runtime code. A fix was applied so that 20% was paid to the Treasury and 80% was burned, consistent with all other fee behavior at that time.

Note that RT3401 introduced a parameters pallet fee configuration allowing governance to adjust how fees are split between the Treasury and burning. After this runtime upgrade combined with the passage of [MB101](https://forum.moonbeam.network/t/proposal-mb101-burn-100-of-transaction-fees-on-moonbeam/2022){target=\_blank}, 100% of all transaction fees on both Moonbeam and Moonriver are now burned.

This bug existed during the following runtimes and block ranges:

|    Network     | Introduced | Fixed  | Impacted Block Range |
|:--------------:|:----------:|:------:|:--------------------:|
|    Moonbeam    |   RT900    | RT2403 |     0 - 4163078      |
|   Moonriver    |    RT49    | RT2401 |     0 - 4668844      |
| Moonbase Alpha |    RT40    | RT2401 |     0 - 4591616      |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/2291){target=\_blank}.

---

#### Incorrect Delegation Reward Calculation {: #incorrect-delegation-reward-calculation }

The reward payouts for all delegations and collators were underestimated whenever there were pending requests. Delegation rewards are calculated based on the amount of tokens bonded by each delegator with respect to the total stake of the given collator. By counting delegation amounts for pending requests, the rewards to collators and their delegations were less than they should have been.

This bug existed during the following runtimes and block ranges:

|    Network     | Introduced | Fixed  | Impacted Block Range |
|:--------------:|:----------:|:------:|:--------------------:|
|    Moonbeam    |   RT1001   | RT1802 |    5165 - 1919457    |
|   Moonriver    |   RT1001   | RT1801 |  1052242 - 2572555   |
| Moonbase Alpha |   RT1001   | RT1800 |  1285916 - 2748785   |

You can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/1719){target=\_blank} for more information.

---

#### Block Parent Hash Calculated Incorrectly {: #block-parent-hash-calculated-incorrectly }

After EIP-1559 support was introduced, which included the transition to new Ethereum transaction types, the block header parent hash was miscalculated to `H256::default`.

This bug only impacted Moonbase Alpha and only impacted the following block:

|    Network     | Introduced | Fixed  | Impacted Block |
|:--------------:|:----------:|:------:|:--------------:|
| Moonbase Alpha |   RT1200   | RT1201 |    1648995     |

While the root issue was fixed in RT1201, the incorrect hash was corrected in RT2601.

For more information on the root fix, you can review the [relative Frontier PR on GitHub](https://github.com/polkadot-evm/frontier/pull/570/){target=\_blank}. To take a look at the correction of the parent hash, check out the corresponding [Moonbeam PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/2524){target=\_blank}.

---

#### Incorrect Handling of EIP-1559 Gas Fees {: #incorrect-gas-fees-eip1559 }

With the introduction of EIP-1559 support, the logic for handling `maxFeePerGas` and `maxPriorityFeePerGas` was implemented incorrectly. As a result, the `maxPriorityFeePerGas` was added to the `baseFee` even if the total amount was over the `maxFeePerGas`.

This bug existed during the following runtimes and block ranges:

|    Network     | Introduced | Fixed  | Impacted Block Range |
|:--------------:|:----------:|:------:|:--------------------:|
|    Moonbeam    |   RT1201   | RT1401 |   415946 - 915320    |
|   Moonriver    |   RT1201   | RT1401 |  1471037 - 1705939   |
| Moonbase Alpha |   RT1200   | RT1400 |  1648994 - 1962557   |

For more information, you can review the [relative Frontier PR](https://github.com/moonbeam-foundation/frontier/pull/45){target=\_blank}.

---

#### Transaction Fees Paid to Collators {: #transaction-fees-paid-to-collators }

For blocks that included EIP-1559 transactions where a priority fee was applied, the transaction fees were incorrectly calculated and distributed to the block's collator. The fee model on Moonbeam for transactions and smart contract execution was previously handled so that 20% of the fees went to the on-chain Treasury and 80% were burned as a deflationary force. Due to this bug, the transaction fees of the impacted transactions were not burned as expected.

Note that RT3401 introduced a parameters pallet fee configuration allowing governance to adjust how fees are split between the Treasury and burning. After this runtime upgrade combined with the passage of [MB101](https://forum.moonbeam.network/t/proposal-mb101-burn-100-of-transaction-fees-on-moonbeam/2022){target=\_blank}, 100% of all transaction fees on both Moonbeam and Moonriver are now burned.

This bug existed during the following runtimes and block ranges:

|    Network     | Introduced | Fixed  | Impacted Block Range |
|:--------------:|:----------:|:------:|:--------------------:|
|    Moonbeam    |   RT1201   | RT1504 |   415946 - 1117309   |
|   Moonriver    |   RT1201   | RT1504 |  1471037 - 1910639   |
| Moonbase Alpha |   RT1200   | RT1504 |  1648994 - 2221772   |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/1528){target=\_blank}.

---

#### Incorrect State Root Hash {: #incorrect-state-root-hash }

The state root hash was miscalculated for non-legacy transactions as the transaction-type byte was not considered. With the support of [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930){target=\_blank} and [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559){target=\_blank}, the transaction types introduced are `0x01` (1) and `0x02` (2), respectively. These transaction types were omitted from the state root hash calculation.

This bug existed during the following runtimes and block ranges:

|    Network     | Introduced | Fixed  | Impacted Block Range |
|:--------------:|:----------:|:------:|:--------------------:|
|    Moonbeam    |   RT1201   | RT1701 |   415946 - 1581456   |
|   Moonriver    |   RT1201   | RT1701 |  1471037 - 2281722   |
| Moonbase Alpha |   RT1200   | RT1700 |  1648994 - 2529735   |

For more information, you can review the [relative Frontier PR](https://github.com/moonbeam-foundation/frontier/pull/86){target=\_blank} and [Moonbeam PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/1678/files){target=\_blank}.

---

#### Ethereum Transactions Duplicated in Storage {: #ethereum-transactions-duplicated-in-storage }

An upstream bug was introduced to Frontier in the Ethereum Pallet, causing pending transactions that existed during a runtime upgrade to be duplicated in storage across two different blocks. This only impacted the first two blocks after the runtime upgrade in which this bug was introduced.

Only Moonriver and Moonbase Alpha were impacted. The bug was introduced in the following runtimes and affected the following blocks:

|    Network     | Introduced |   Impacted Blocks   |
|:--------------:|:----------:|:-------------------:|
|   Moonriver    |   RT1605   | 2077599 and 2077600 |
| Moonbase Alpha |   RT1603   | 2285347 and 2285348 |

The following transactions were duplicated:

=== "Moonriver"

    ```js
    '0x2cceda1436e32ae3b3a2194a8cb5bc4188259600c714789bae1fedc0bbc5125f',
    '0x3043660e35e89cafd7b0e0dce9636f5fcc218fce2a57d1104cf21aabbff9a1c0',
    '0x514411fb5c08f7c5aa6c61c38f33edfa74ff7e160831f6140e8dd3783648dbca',
    '0xf1647c357d8e1b05c522d11cff1f5090a4df114595d0f4b9e4ac5bb746473eea',
    '0x4be94803fe7839d5ef13ddd2633a293b4a7dddbe526839c15c1646c72e7b0b23',
    '0x15fceb009bd49692b598859f9146303ed4d8204b38e35c147fcdb18956679dbe',
    '0xa7460d23d5c633feec3d8e8f4382240d9b71a0d770f7541c3c32504b5403b70c',
    '0x1c838b4c4e7796a9db5edfd0377aee6e0d89b623bf1d7803f766f4cf71daefb9',
    '0xfb233a893e62d717ed627585f14b1ee8b3e300ac4e2c3016eb63e546a60820f0',
    '0xfaf8908838683ad51894eb3c68196afb99ba2e2bb698a40108960ee55417b56a',
    '0xa53973acbeac9fe948015dcfad6e0cb28d91b93c8115347c178333e73fd332d3',
    '0x9df769c96c5fdd505c67fee27eaff3714bf8f3d45a2afc02dd2984884b3cecac',
    '0x8f912ae91b408f082026992a87060ed245dac6e382a84288bd38fc08dbac30fe',
    '0xb22af459d24cb25bc53785bdd0ae6a573e24f226c94fd8d2e4663b87d3b07a88',
    '0x8ab9cd2bde7d679f798528b0c75325787f5fc7997e00589445b35b3954a815aa',
    '0xd08a1f82f4d3dc553b4b559925f997ef8bb85cb24cb4d0b893f017129fb33b78',
    '0xa1d40bce7cc607c19ca4b37152b6d8d3a408e3de6b9789c5977fcdef7ef14d97',
    '0xe442227634db10f5d0e8c1da09f8721c2a57267edbf97c4325c4f8432fd48ade',
    '0x0b4f5d8338a7c2b1604c1c42e96b12dc2a9d5ab264eb74ff730354e9765de13f',
    '0x0b00fc907701003aad75560d8b1a33cbf4b75f76c81d776b8b92d20e1d2e9d31',
    '0x9c18bd783f28427d873970ff9deaf1549db2f9a76e3edd6bdeae11358e447ef4',
    '0x8b2523f163989969dd0ebcac85d14805756bc0075b89da1274fd2c53ccaa396a',
    '0x47e80a0c533265974a55ea62131814e31b10f42895709f7e531e3e7b69f1387c'
    ```

=== "Moonbase Alpha"

    ```js
    '0x006a6843eb35ad35a9ea9a99affa8d81f1ed500253c98cc9c080d84171a0afb3',
    '0x64c102f664eb435206ad4fcb49b526722176bcf74801c79473c3b5b2c281a243',
    '0xf546335453b6e35ce7e236ee873c96ba3a22602b3acc4f45f5d68b33a76d79ca',
    '0x4ed713ccd474fc33d2022a802f064cc012e3e37cd22891d4a89c7ba3d776f2db',
    '0xa5355f86844bb23fe666b10b509543fa377a9e324513eb221e0a2c926a64cae4',
    '0xc14791a3a392018fc3438f39cac1d572e8baadd4ed350e0355d1ca874a169e6a'
    ```

The duplicated transactions belong to the first block. So, on Moonriver, the transactions belong to block 2077599, and on Moonbase Alpha, the impacted transactions belong to block 2285347.

For more information, you can review the [relative Frontier PR on GitHub](https://github.com/polkadot-evm/frontier/pull/638){target=\_blank}.

---

#### Gas Limit Too High for Non-Transactional Calls {: #gas-limit-too-high-for-non-transactional-calls }

When a non-transactional call, such as `eth_call` or `eth_estimateGas`, is made without specifying a gas limit for a past block, the client defaults to using the gas limit multiplier (10x), which causes the gas limit validation to fail as it is validating against an upper bound of the block gas limit. So, if the gas limit is greater than the block gas limit for a given call, a gas limit too high error is returned.

This bug existed during the following runtimes and block ranges:

|    Network     | Introduced | Fixed  | Impacted Block Range |
|:--------------:|:----------:|:------:|:--------------------:|
|    Moonbeam    |   RT1701   | RT1802 |  1581457 - 1919457   |
|   Moonriver    |   RT1701   | RT1802 |  2281723 - 2616189   |
| Moonbase Alpha |   RT1700   | RT1802 |  2529736 - 2879402   |

You can review the [relative Frontier PR on GitHub](https://github.com/polkadot-evm/frontier/pull/935){target=\_blank} for more information.

---

#### Remote EVM Calls Return Identical Transaction Hashes {: #remote-evm-calls-return-identical-tx-hashes }

When multiple remote EVM calls were sent from different accounts with the same transaction payload and nonce, the same transaction hash was returned for each call. This was possible because remote EVM calls are executed from a keyless account, so if the senders all had the same nonce and were sending the same transaction object, there was no differentiation in the calculation of the transaction hash. This was fixed by adding a global nonce to the Ethereum XCM Pallet, which is the pallet that makes remote EVM calls possible.

This bug only existed on Moonbase Alpha during the following runtimes and block ranges:

|    Network     | Introduced | Fixed  | Impacted Block Range |
|:--------------:|:----------:|:------:|:--------------------:|
| Moonbase Alpha |   RT1700   | RT1900 |  2529736 - 3069634   |

You can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/1790){target=\_blank} for more information.

---

#### Gas Estimation Discrepancy {: #gas-estimation-discrepancy }

There was a difference between estimating the gas for a transaction using a non-transaction call, such as `eth_call`, and the execution of it on-chain. The discrepancy occurred because the non-transactional calls were not properly accounting for `maxFeePerGas` and `maxPriorityFeePerGas`, as such, the ([Proof of Validity](https://wiki.polkadot.com/general/glossary/#proof-of-validity){target=\_blank}) consumed by the Ethereum transaction was counted differently. This was fixed by properly accounting for these fields when estimating the size of the on-chain transaction.

This bug existed during the following runtimes and block ranges:

|    Network     | Introduced | Fixed  | Impacted Block Range |
|:--------------:|:----------:|:------:|:--------------------:|
|    Moonbeam    |   RT1201   | RT2501 |   415946 - 4543267   |
|   Moonriver    |   RT1201   | RT2500 |  1471037 - 5175574   |
| Moonbase Alpha |   RT1200   | RT2500 |  1648994 - 5053547   |

You can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/1790/){target=\_blank} for more information.

---

#### Incorrect Effective Gas Price In Transaction Receipts {: #incorrect-effective-gas-price }

The `effectiveGasPrice` value returned by `eth_getTransactionReceipt` was different from the on-chain value due to an incorrect calculation of the base fee. Specifically, the transaction receipt's value was computed using the `NextFeeMultiplier` from the block in which the transaction was included rather than the previous block, which is the correct source for computing the base fee.

This bug existed during the following runtimes and block ranges:

|    Network     | Introduced | Fixed  | Impacted Block Range |
|:--------------:|:----------:|:------:|:--------------------:|
|    Moonbeam    |   RT1201   | RT2801 |   415946 - 5899847   |
|   Moonriver    |   RT1201   | RT2801 |  1471037 - 6411588   |
| Moonbase Alpha |   RT1200   | RT2801 |  1648994 - 6209638   |

You can review the [relative Frontier PR](https://github.com/polkadot-evm/frontier/pull/1280){target=\_blank} and [Moonbeam PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/2610){target=\_blank} for more information.

---

#### Skipped Ethereum Transaction Traces {: #skipped-ethereum-transaction-traces }

Runtimes with the `evm-tracing` feature enabled introduced additional `ref_time` overhead due to special logic that traces Ethereum transactions (emitting events for each component: gasometer, runtime, EVM) used to fill information for RPC calls like `debug_traceTransaction` and `trace_filter`. 

Since the real `ref_time` in production runtimes is smaller, this could cause the block weight limits to be reached when replaying a block in an EVM-tracing runtime, resulting in skipped transaction traces. This was observed in Moonbeam block [9770044](https://moonbeam.subscan.io/block/9770044){target=\_blank}.

The fix consisted of resetting the previously consumed weight before tracing each Ethereum transaction. It's important to note that this issue only affected code under `evm-tracing`, which is not included in any production runtime.

This bug was fixed in the following runtime:

|    Network     | Fixed  | Impacted Block |
|:--------------:|:------:|:--------------:|
|    Moonbeam    | RT3501 |    9770044     |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/3210){target=\_blank}.

---

#### Notify Inactive Collator Fails for Long-Inactive Collators {: #notify-inactive-collator-fails }

The `notifyInactiveCollator` extrinsic, designed to remove collators from the pool if they haven't produced any blocks in the last two rounds, failed for collators who had been inactive for significantly longer than two rounds. The transaction would only succeed within the first few blocks of a new round.

The bug existed during the following runtimes and block ranges:

|    Network     | Introduced | Fixed  | Impacted Block Range |
|:--------------:|:----------:|:------:|:--------------------:|
| Moonbase Alpha |   RT2601   | RT3500 |  5474345 – 10750816  |
|   Moonriver    |   RT2602   | RT3501 |  5638536 – 10665393  |
|    Moonbeam    |   RT2602   | RT3501 |  4977160 – 10056989  |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/3128){target=\_blank}.
---

## Migrations {: #migrations }

Migrations are necessary when a storage item is changed or added and needs to be populated with data. The migrations listed below have been organized by the impacted pallet(s).

### Author Mapping Pallet {: #author-mapping }

#### Update the Mapping Storage Item {: #update-mapping-storage-item }

This migration updated the now deprecated `Mapping` storage item of the author mapping pallet to use a more secure hasher type. The hasher type was updated to [Blake2_128Concat](https://paritytech.github.io/substrate/master/frame_support/struct.Blake2_128Concat.html){target=\_blank} instead of [Twox64Concat](https://paritytech.github.io/substrate/master/frame_support/struct.Twox64Concat.html){target=\_blank}.

This migration was only applied to Moonriver and Moonbase Alpha and was executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|   Moonriver    |      RT800       |    684728     |
| Moonbase Alpha |      RT800       |    915684     |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/679){target=\_blank}.

---

#### Add Support for VRF Keys {: #add-support-for-vrf-keys }

When VRF key support was introduced, the `MappingWithDeposit` storage item of the author mapping pallet was updated to include a `keys` field to support VRF keys that can be looked up via the Nimbus ID. A migration was applied to update the existing storage items with this new field.

This migration was executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|    Moonbeam    |      RT1502      |    1107285    |
|   Moonriver    |      RT1502      |    1814458    |
| Moonbase Alpha |      RT1502      |    2112058    |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/1407){target=\_blank}.

---

#### One Nimbus ID per Account ID {: #one-nimbus-id-per-account-id }

A migration was applied to ensure that an account ID can have only one Nimbus ID. The migration accepted the first Nimbus ID owned by a given account and cleared any additional Nimbus IDs associated with the account. For any cleared associations, the bond for the association was returned.

This migration was executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|    Moonbeam    |      RT1606      |    1326697    |
|   Moonriver    |      RT1605      |    2077599    |
| Moonbase Alpha |      RT1603      |    2285347    |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/1525){target=\_blank}.

---

### Base Fee Pallet {: #base-fee }

#### Set Elasticity Storage Item Value {: #set-elasticity }

This migration sets the `Elasticity` storage item of the base fee pallet to zero, which results in a constant `BaseFeePerGas`.

This migration was executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|    Moonbeam    |      RT1300      |    524762     |
|   Moonriver    |      RT1300      |    1541735    |
| Moonbase Alpha |      RT1300      |    1761128    |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/1744){target=\_blank}.

---

### Democracy Pallet {: #democracy }

#### Preimage Storage Moved to New Preimage Pallet

A migration was applied, which moved preimages stored in the democracy pallet to a new preimage pallet. This migration on Moonbeam was required as a result of an [upstream change to Polkadot](https://github.com/paritytech/substrate/pull/11649/){target=\_blank}.

There was one preimage that was affected in Moonbeam, which was dropped from the scheduler queue and never executed: `0x14262a42aa6ccb3cae0a169b939ca5b185bc317bb7c449ca1741a0600008d306`. This preimage was [manually removed](https://moonbeam.subscan.io/extrinsic/2693398-8){target=\_blank} by the account that initially submitted the preimage.

This migration was executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|    Moonbeam    |      RT2000      |    3310369    |
|   Moonriver    |      RT2000      |    3202604    |
| Moonbase Alpha |      RT2000      |    2673234    |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/1962){target=\_blank}.

---

#### Remove Governance V1 Collectives {: #remove-gov-v1-collectives }

A migration was applied to remove the governance V1 collectives, which included the Council and Technical Committee. The governance V1 collectives were replaced with the OpenGov (governance V2) Technical Committee.

This migration was executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|    Moonbeam    |      RT2801      |    5899847    |
|   Moonriver    |      RT2801      |    6411588    |
| Moonbase Alpha |      RT2801      |    6209638    |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/2643){target=\_blank}.

A follow-up migration was required to properly clear the storage entries associated with the governance V1 collectives, which was executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|    Moonbeam    |      RT2901      |    6197065    |
|   Moonriver    |      RT2901      |    6699589    |
| Moonbase Alpha |      RT2901      |    6710531    |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/2711){target=\_blank}.

---

#### Remove Governance V1 Democracy Pallet {: #remove-gov-v1-collectives }

A migration was applied to remove the storage associated with the Democracy Pallet used in governance V1. The Democracy Pallet was replaced with the Preimage, Referenda, and Collective Voting OpenGov (governance V2) pallets.

This migration was executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|    Moonbeam    |      RT2901      |    6197065    |
|   Moonriver    |      RT2901      |    6699589    |
| Moonbase Alpha |      RT2901      |    6710531    |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/2685){target=\_blank}.

---

### EVM Pallet {: evm-pallet }
#### EVM Contract Metadata
A migration was introduced to automate the manual process of setting EVM contract metadata for contracts deployed more than two years ago that hadn't been interacted with after the introduction of metadata storage item. This migration replaces the need to manually call `createContractMetadata(address)` on these contracts to make them compatible with the current runtime. 

This migration was executed at the following runtimes and blocks:

|  Network  | Executed Runtime | Block Applied |
|:---------:|:----------------:|:-------------:|
| Moonbeam  |      RT3200      |    7985204    |
| Moonriver |      RT3200      |    8519187    |

---

### Moonbeam Orbiter Pallet {: #moonbeam-orbiter }

#### Remove the Minimum Bond Requirement for Orbiter Collators {: #remove-orbiter-minimum-bond }

A migration was applied to the Moonbeam Orbiter Pallet that sets the bonds of the existing orbiter collators to zero. This change enabled payouts to be even for future orbiter program expansions.

This migration was executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|    Moonbeam    |      RT2602      |    4977160    |
|   Moonriver    |      RT2602      |    5638536    |
| Moonbase Alpha |      RT2601      |    5474345    |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/2526){target=\_blank}.

---

### Parachain Staking Pallet {: #parachain-staking }

#### Update Collator State Storage Item {: #update-collator-state-storage-item }

A migration was applied that updated the `Collator` storage item of the parachain staking pallet to the new `Collator2` storage item. This change updated the collator state to include the following items:

- The `nominators` set is a list of all of the nominator (delegator) account IDs without their respective balance bonded
- A new `top_nominators` storage item that returns a list of all of the top nominators ordered by greatest bond amount to least
- A new `bottom_nominators` storage item that returns a list of all of the bottom nominators ordered by least bond amount to greatest
- The `total` storage item was replaced with `total_counted` and `total_backing`. The `total_counted` item returns the sum of the top nominations and the collator's self-bond, whereas the `total_backing` item returns the sum of all of the nominations and the collator's self-bond

This migration was only applied to Moonriver and Moonbase Alpha and was executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|   Moonriver    |       RT53       |     9696      |
| Moonbase Alpha |       RT52       |    238827     |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/505){target=\_blank}.

---

#### Patch Total Staked Amount {: #patch-total-staked-amount }

A migration was applied to the `total` staked amount of the `CollatorState` storage item in the Parachain Staking Pallet due to a potential bug that may have led to an incorrect amount.

This migration was only applied to Moonriver and Moonbase Alpha and was executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|   Moonriver    |       RT53       |     9696      |
| Moonbase Alpha |       RT52       |    238827     |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/502){target=\_blank}.

---

#### Support Delayed Nominator (Delegator) Exits {: #support-delayed-nominator-exits }

The exit queue for handling candidate exits had been updated to include support for delayed nominator (delegator) exits and revocations, which required a migration to update the `ExitQueue` parachain staking pallet storage item to `ExitQueue2`. The `NominatorState` storage item was also migrated to `NominatorState2` to prevent a nominator from performing more nominations when they already have scheduled an exit.

These migrations were only applied to Moonriver and Moonbase Alpha and were executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|   Moonriver    |      RT200       |    259002     |
| Moonbase Alpha |      RT200       |    457614     |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/610){target=\_blank}.

---

#### Purge Staking Storage Bloat {: #purge-staking-storage-bloat }

A migration was applied to purge staking storage bloat for the `Points` and `AtStake` storage items of the parachain staking pallet that are older than two rounds.

This migration was executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|    Moonbeam    |      RT1001      |     5165      |
|   Moonriver    |      RT1001      |    1052242    |
| Moonbase Alpha |      RT1001      |    1285916    |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/970){target=\_blank}.

---

#### Support Manual Exits and DPoS Terminology {: #support-manual-exits-dpos-terminology }

The parachain staking pallet was updated to include manual exits. If a candidate or delegator wanted to decrease or revoke their bond or leave the candidate or delegator pool, they would need to schedule a request first, wait for a delay period to pass, and then manually execute the request. As such, a migration was applied to replace the automatic exit queue, including the `ExitQueue2` storage item, with a manual exits API.

In addition, a change was made to switch from Nominated Proof of Stake (NPoS) to Delegated Proof of Stake (DPoS) terminology; this marked the sweeping change from "nominate" to "delegate". This required the migration of the following parachain staking pallet storage items:

- `CollatorState2` was migrated to `CandidateState`
- `NominatorState2` was migrated to `DelegatorState`

These migrations were executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|    Moonbeam    |      RT1001      |     5165      |
|   Moonriver    |      RT1001      |    1052242    |
| Moonbase Alpha |      RT1001      |    1285916    |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/810){target=\_blank}.

---

#### Increase Max Delegations per Candidate {: #increase-max-delegations-per-candidate }

A migration was applied to increase the maximum number of delegations per candidate in the parachain staking pallet. It increased the delegations from 100 to 500 on Moonbase Alpha and Moonriver and from 100 to 1000 on Moonbeam.

This migration was executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|    Moonbeam    |      RT1101      |    171061     |
|   Moonriver    |      RT1101      |    1188000    |
| Moonbase Alpha |      RT1100      |    1426319    |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/1096){target=\_blank}.

---

#### Split Candidate Delegations into Top and Bottom {: #split-candidate-delegations-top-bottom }

This migration splits the deprecated `CandidateState` storage item of the parachain staking pallet into the following three new storage items to avoid unnecessary storage reads:

- `CandidateInfo`
- `TopDelegations`
- `BottomDelegations`

This migration was executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|    Moonbeam    |      RT1201      |    415946     |
|   Moonriver    |      RT1201      |    1471037    |
| Moonbase Alpha |      RT1200      |    1648994    |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/1117){target=\_blank}.

---

#### Patch Incorrect Total Delegations {: #patch-incorrect-total-delegations }

There was a migration applied to fix the [Incorrect Collator Selection](#incorrect-collator-selection) bug and patch the delegations total for all candidates.

This migration was executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|    Moonbeam    |      RT1300      |    524762     |
|   Moonriver    |      RT1300      |    1541735    |
| Moonbase Alpha |      RT1300      |    1761128    |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/1291){target=\_blank}.

---

#### Split Delegator State into Delegation Scheduled Requests {: #split-delegator-state }

A migration was applied that moved pending delegator requests from the `DelegatorState` storage item of the parachain staking pallet into a new `DelegationScheduledRequests` storage item.

This migration was executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|    Moonbeam    |      RT1502      |    1107285    |
|   Moonriver    |      RT1502      |    1814458    |
| Moonbase Alpha |      RT1502      |    2112058    |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/1408){target=\_blank}.

---

#### Replace Staking Reserves with Locks {: #replace-staking-reserves }

A migration was applied that changed users' staking reserved balances to locked balances. The locked balance is the same type as democracy-locked funds, allowing users to use their staked funds to participate in democracy.

This migration was executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|    Moonbeam    |      RT1701      |    1581457    |
|   Moonriver    |      RT1701      |    2281723    |
| Moonbase Alpha |      RT1700      |    2529736    |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/1604){target=\_blank}.

---

#### Auto-Compounding Support {: #auto-compounding-support }

To support auto-compounding, two migrations were applied to the `AtStake` storage item in the parachain staking pallet:

- `RemovePaidRoundsFromAtStake` - to remove any stale `AtStake` entries relating to already paid-out rounds with candidates that didn't produce any blocks. This migration is a prerequisite for the `MigrateAtStakeAutoCompound` migration
- `MigrateAtStakeAutoCompound` - migrates the snapshots for unpaid rounds for `AtStake` entries

These migrations were executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|    Moonbeam    |      RT1901      |    2317683    |
|   Moonriver    |      RT1901      |    2911863    |
| Moonbase Alpha |      RT1900      |    3069635    |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/1878){target=\_blank}.

---

#### Switch to Block-Based Staking Rounds {: #block-based-staking-rounds }

A migration was applied to switch from time-based staking rounds to fixed block-based rounds.

This migration was executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|    Moonbeam    |      RT2801      |    5899847    |
|   Moonriver    |      RT2801      |    6411588    |
| Moonbase Alpha |      RT2801      |    6209638    |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/2690){target=\_blank}.

---

#### Renaming of Parachain Bond Reserve Events {: #renaming-of-parachain-bond-reserve-events }

Prior to Runtime 3300, the `ReservedForParachainBond` event was emitted once per round to indicate parachain bond reserve funding through inflation. In Runtime 3300, this same event was renamed to `InflationDistributed`.

This change took effect at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|    Moonbeam    |      RT3300      |    8381443    |
|   Moonriver    |      RT3300      |    8894417    |
| Moonbase Alpha |      RT3300      |    9062316    |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/2976){target=\_blank}.

---

### Referenda Pallet {: #referenda-pallet }

#### Refunds for Submission Deposits {: #refunds-for-submission-deposits }

A migration was introduced to support refunds for submission deposits on closed referenda that updated the `ReferendumInfo` type. The following invariants of `ReferendumInfo` were changed so that the second parameter, `Deposit<AccountId, Balance>`, is now optional, `Option<Deposit<AccountId, Balance>>`: `Approved`, `Rejected`, `Cancelled`, and `TimedOut`.

This stemmed from an upstream change to the [Substrate](https://github.com/paritytech/substrate/pull/12788){target=\_blank} repository.

This migration was executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|    Moonbeam    |      RT2302      |    3456477    |
|   Moonriver    |      RT2302      |    4133065    |
| Moonbase Alpha |      RT2301      |    4172407    |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/2134){target=\_blank}.

---

#### Restore Corrupted Referenda Deposits {: restore-corrupted-referenda-deposits }

A migration was introduced to support restoring referenda deposits affected by corrupted storage values. The issue arose when a migration was applied twice due to a pallet version error, resulting in invalid values and non-refundable submission deposits. As the number of values to correct was finite and small, this migration created a list to update them by hand.

This migration was only applied to Moonbeam and was executed at the following runtimes and blocks:

| Network  | Executed Runtime | Block Applied |
|:--------:|:----------------:|:-------------:|
| Moonbeam |      RT3100      |    7303601    |

### XCM-Related Pallets {: #xcm-related-pallets }

#### Update Transact Info Storage Item {: #update-transaction-info }

There was a migration applied to the `TransactInfo` storage item of the XCM Transactor Pallet that changed the following items:

- `max_weight` is added to prevent transactors from stalling the queue in the destination chain
- Removes `fee_per_byte`, `metadata_size`, and `base_weight` as these items are not necessary for XCM transactions
- `fee_per_second` replaces `fee_per_weight` to better reflect cases (like Kusama) in which the `fee_per_weight` unit is lower than one

This migration was executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|    Moonbeam    |      RT1201      |    415946     |
|   Moonriver    |      RT1201      |    1471037    |
| Moonbase Alpha |      RT1200      |    1648994    |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/1114){target=\_blank}.

---

#### Add Support for Kusama Asset Hub (Statemine) Prefix Breaking Change {: #add-support-statemine-prefix }

The following three migrations were added to the asset manager pallet to avoid issues with Kusama Asset Hub's (previously referred to as Statemine) [breaking change to the way it represents assets](https://github.com/paritytech/cumulus/pull/831){target=\_blank} and possible future breaking changes:

- `UnitsWithAssetType` - updates the `AssetTypeUnitsPerSecond` storage item to a mapping of the `AssetType` to `units_per_second`, instead of the mapping `AssetId` to `units_per_second`. This is done to avoid additional migrations whenever a breaking change arises
- `PopulateAssetTypeIdStorage` - creates a new `AssetTypeId` storage item that holds the `AssetType` to `AssetId` mapping, which allows the decoupling of `assetIds` and `AssetTypes`
- `ChangeStateminePrefixes` - updates already registered Kusama Asset Hub (Statemine) assets to their new form

These migrations were executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|    Moonbeam    |      RT1201      |    415946     |
|   Moonriver    |      RT1201      |    1471037    |
| Moonbase Alpha |      RT1200      |    1648994    |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/1159){target=\_blank}.

---

#### Add New Supported Fee Payment Assets Storage Item {: #add-supported-fee-payment-assets }

A migration was applied to the asset manager pallet, creating a new `SupportedFeePaymentAssets` storage item by reading the supported asset data from the `AssetTypeUnitsPerSecond` storage item. This storage item will hold all the assets we accept for XCM fee payment. It will be read when an incoming XCM message is received, and if the asset is not in storage, the message will not be processed.

This migration was executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|    Moonbeam    |      RT1300      |    524762     |
|   Moonriver    |      RT1300      |    1541735    |
| Moonbase Alpha |      RT1300      |    1761128    |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/1118){target=\_blank}.

---

#### Update the XCM Transactor Storage from V2 to V3 {: #update-xcm-transactor }

With the support of XCM V3, a migration was applied to update the XCM Transactor pallet's storage from XCM V2 to V3. The `transactInfoWithWeightLimit` and `destinationAssetFeePerSecond` storage items were updated to support XCM V3 multilocations.

This migration was executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|    Moonbeam    |      RT2302      |    3456477    |
|   Moonriver    |      RT2302      |    4133065    |
| Moonbase Alpha |      RT2301      |    4172407    |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/2145){target=\_blank}.

---

#### Remove Mintable XC-20s {: #remove-local-assets }

Mintable XC-20s were deprecated in favor of XCM-enabled ERC-20s; as such, a migration was applied to remove the local assets pallet and clear the assets in storage.

This migration was executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|    Moonbeam    |      RT2801      |    5899847    |
|   Moonriver    |      RT2801      |    6411588    |
| Moonbase Alpha |      RT2801      |    6209638    |

For more information, you can review the [relative PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/2634){target=\_blank}.

---

#### Manage Foreign Assets via Smart Contracts  {: #foreign-assets-migration }

A migration was applied to transition existing foreign assets to a new design that manages XCM derivative assets on Moonbeam through EVM smart contracts instead of the previous implementation using the Asset and Asset Manager pallets. The migration process involved several extrinsics in the Moonbeam Lazy Migration pallet:

- **`approve_assets_to_migrate`** - sets the list of asset IDs approved for migration
- **`start_foreign_asset_migration`** - initiates migration for a specific foreign asset by freezing the original asset and creating a new EVM smart contract
- **`migrate_foreign_asset_balances`** - migrates asset balances in batches from old assets pallet to the new system
- **`migrate_foreign_asset_approvals`** - migrates asset approvals in batches while unreserving deposits from the old approval system
- **`finish_foreign_asset_migration`** - completes migration after all balances and approvals are migrated and performs final cleanup

This migration preserves compatibility with existing foreign assets by identifying each foreign asset with the same AssetID integer as before. This migration was executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|    Moonbeam    |      RT3501      |    10056989   |
|   Moonriver    |      RT3501      |    10665393   |
| Moonbase Alpha |      RT3500      |    10750816   |

For more information, you can review the relative PRs on GitHub: [2869](https://github.com/moonbeam-foundation/moonbeam/pull/2869){target=\_blank} and [3020](https://github.com/moonbeam-foundation/moonbeam/pull/3020){target=\_blank}.

---

### Nimbus Author Filter Pallet {: #nimbus }

#### Replace Eligible Ratio with Eligible Count {: #replace-eligible-ratio }

A breaking change was applied to the Nimbus repository, deprecating `EligibleRatio` in favor of the `EligibleCount` config. As a result, a migration was applied to the Moonbeam repository, populating the new `EligibleCount` value as a percentage of the potential authors defined at that block height if the `EligibleRatio` value existed. Otherwise, the value was set to a default value of `50`.

This migration was executed at the following runtimes and blocks:

|    Network     | Executed Runtime | Block Applied |
|:--------------:|:----------------:|:-------------:|
|    Moonbeam    |      RT1502      |    1107285    |
|   Moonriver    |      RT1502      |    1814458    |
| Moonbase Alpha |      RT1502      |    2112058    |

For more information, you can review the [relative Nimbus PR](https://github.com/moonbeam-foundation/nimbus/pull/45){target=\_blank} and [Moonbeam PR on GitHub](https://github.com/moonbeam-foundation/moonbeam/pull/1400){target=\_blank}.
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/builders/build/runtime-upgrades/
--- BEGIN CONTENT ---
---
title: Runtime Upgrades
description: A historical record of each runtime upgrade and the block at which the runtime was executed for Moonbeam, Moonriver, and the Moonbase Alpha TestNet.
categories: Reference
---

# Runtime Upgrades

## Introduction {: #introduction }

Moonbeam runtime upgrades allow for the maintenance and evolution of the chain logic without the need for a hard fork. These runtime upgrades can introduce new features, improve performance, fix bugs, and respond to changing requirements.

This page provides a historical record of runtime upgrades by block for each of the Moonbeam-based networks.

## Runtime Upgrades by Block {: #runtime-upgrades-by-block }

The following table contains a list of the runtime upgrades and the block at which the upgrade occurred for each network. Runtime upgrades occur first on Moonbase Alpha before being released on Moonriver and then on Moonbeam. You can read the release notes for each runtime on the [Moonbeam releases GitHub page](https://github.com/moonbeam-foundation/moonbeam/releases){target=\_blank}.

Not all runtime upgrades are released on each network, as sometimes after releasing the initial runtime upgrade, the need for a subsequent upgrade arises. If a runtime upgrade version has been skipped or hasn't been released yet (only applicable to the latest runtime upgrade), you'll see a `-` in that row.


|                                         Runtime                                          |                                Moonbeam                                |                                Moonriver                                |                             Moonbase Alpha                             |
|:----------------------------------------------------------------------------------------:|:----------------------------------------------------------------------:|:-----------------------------------------------------------------------:|:----------------------------------------------------------------------:|
|                                            40                                            |                                   -                                    |                                    -                                    |        [0](https://moonbase.subscan.io/block/0){target=\_blank}        |
|                                            44                                            |                                   -                                    |                                    -                                    |   [142863](https://moonbase.subscan.io/block/142863){target=\_blank}   |
|                                            47                                            |                                   -                                    |                                    -                                    |   [209144](https://moonbase.subscan.io/block/209144){target=\_blank}   |
|                                            49                                            |                                   -                                    |        [0](https://moonriver.subscan.io/block/0){target=\_blank}        |                                   -                                    |
|                                            52                                            |                                   -                                    |                                    -                                    |   [238827](https://moonbase.subscan.io/block/238827){target=\_blank}   |
|                                            53                                            |                                   -                                    |     [9696](https://moonriver.subscan.io/block/9696){target=\_blank}     |                                   -                                    |
|                                           155                                            |                                   -                                    |    [67938](https://moonriver.subscan.io/block/67938){target=\_blank}    |   [278703](https://moonbase.subscan.io/block/278703){target=\_blank}   |
|                                           159                                            |                                   -                                    |   [166749](https://moonriver.subscan.io/block/166749){target=\_blank}   |   [383465](https://moonbase.subscan.io/block/383465){target=\_blank}   |
|                                           200                                            |                                   -                                    |   [259002](https://moonriver.subscan.io/block/259002){target=\_blank}   |   [457614](https://moonbase.subscan.io/block/457614){target=\_blank}   |
|                                           300                                            |                                   -                                    |   [344698](https://moonriver.subscan.io/block/344698){target=\_blank}   |   [485543](https://moonbase.subscan.io/block/485543){target=\_blank}   |
|                                           400                                            |                                   -                                    |   [400458](https://moonriver.subscan.io/block/400458){target=\_blank}   |   [610935](https://moonbase.subscan.io/block/610935){target=\_blank}   |
|                                           501                                            |                                   -                                    |   [430442](https://moonriver.subscan.io/block/430442){target=\_blank}   |   [653692](https://moonbase.subscan.io/block/653692){target=\_blank}   |
|                                           600                                            |                                   -                                    |   [455107](https://moonriver.subscan.io/block/455107){target=\_blank}   |   [675176](https://moonbase.subscan.io/block/675176){target=\_blank}   |
|                                           701                                            |                                   -                                    |   [581187](https://moonriver.subscan.io/block/581187){target=\_blank}   |   [797200](https://moonbase.subscan.io/block/797200){target=\_blank}   |
|                                           800                                            |                                   -                                    |   [684728](https://moonriver.subscan.io/block/684728){target=\_blank}   |   [915684](https://moonbase.subscan.io/block/915684){target=\_blank}   |
|                                           900                                            |        [0](https://moonbeam.subscan.io/block/0){target=\_blank}        |   [923864](https://moonriver.subscan.io/block/923864){target=\_blank}   |  [1075626](https://moonbase.subscan.io/block/1075626){target=\_blank}  |
|                                           901                                            |                                   -                                    |                                    -                                    |  [1130271](https://moonbase.subscan.io/block/1130271){target=\_blank}  |
|                                           902                                            |                                   -                                    |                                    -                                    |  [1175311](https://moonbase.subscan.io/block/1175311){target=\_blank}  |
|                                           1001                                           |     [5165](https://moonbeam.subscan.io/block/5165){target=\_blank}     |  [1052242](https://moonriver.subscan.io/block/1052242){target=\_blank}  |  [1285916](https://moonbase.subscan.io/block/1285916){target=\_blank}  |
|                                           1002                                           |    [32532](https://moonbeam.subscan.io/block/32532){target=\_blank}    |  [1141593](https://moonriver.subscan.io/block/1141593){target=\_blank}  |  [1396972](https://moonbase.subscan.io/block/1396972){target=\_blank}  |
|                                           1101                                           |   [171061](https://moonbeam.subscan.io/block/171061){target=\_blank}   |  [1188000](https://moonriver.subscan.io/block/1188000){target=\_blank}  |  [1426319](https://moonbase.subscan.io/block/1426319){target=\_blank}  |
|                                           1102                                           |   [214641](https://moonbeam.subscan.io/block/214641){target=\_blank}   |  [1295420](https://moonriver.subscan.io/block/1295420){target=\_blank}  |  [1517440](https://moonbase.subscan.io/block/1517440){target=\_blank}  |
|                                           1103                                           |   [312036](https://moonbeam.subscan.io/block/312036){target=\_blank}   |  [1389122](https://moonriver.subscan.io/block/1389122){target=\_blank}  |  [1591913](https://moonbase.subscan.io/block/1591913){target=\_blank}  |
|                                           1200                                           |                                   -                                    |                                    -                                    |  [1648994](https://moonbase.subscan.io/block/1648994){target=\_blank}  |
|                                           1201                                           |   [415946](https://moonbeam.subscan.io/block/415946){target=\_blank}   |  [1471037](https://moonriver.subscan.io/block/1471037){target=\_blank}  |  [1679619](https://moonbase.subscan.io/block/1679619){target=\_blank}  |
|                                           1300                                           |   [524762](https://moonbeam.subscan.io/block/524762){target=\_blank}   |  [1541735](https://moonriver.subscan.io/block/1541735){target=\_blank}  |  [1761128](https://moonbase.subscan.io/block/1761128){target=\_blank}  |
|                                           1400                                           |                                   -                                    |                                    -                                    |  [1962557](https://moonbase.subscan.io/block/1962557){target=\_blank}  |
|                                           1401                                           |   [915320](https://moonbeam.subscan.io/block/915320){target=\_blank}   |  [1705939](https://moonriver.subscan.io/block/1705939){target=\_blank}  |  [1967358](https://moonbase.subscan.io/block/1967358){target=\_blank}  |
|                                           1502                                           |  [1107285](https://moonbeam.subscan.io/block/1107285){target=\_blank}  |  [1814458](https://moonriver.subscan.io/block/1814458){target=\_blank}  |  [2112058](https://moonbase.subscan.io/block/2112058){target=\_blank}  |
|                                           1503                                           |  [1115896](https://moonbeam.subscan.io/block/1115896){target=\_blank}  |  [1909326](https://moonriver.subscan.io/block/1909326){target=\_blank}  |  [2220736](https://moonbase.subscan.io/block/2220736){target=\_blank}  |
|                                           1504                                           |  [1117310](https://moonbeam.subscan.io/block/1117310){target=\_blank}  |  [1910640](https://moonriver.subscan.io/block/1910640){target=\_blank}  |  [2221773](https://moonbase.subscan.io/block/2221773){target=\_blank}  |
|                                           1603                                           |                                   -                                    |                                    -                                    |  [2285347](https://moonbase.subscan.io/block/2285347){target=\_blank}  |
|                                           1605                                           |                                   -                                    |  [2077599](https://moonriver.subscan.io/block/2077599){target=\_blank}  |  [2318567](https://moonbase.subscan.io/block/2318567){target=\_blank}  |
|                                           1606                                           |  [1326697](https://moonbeam.subscan.io/block/1326697){target=\_blank}  |  [2105127](https://moonriver.subscan.io/block/2105127){target=\_blank}  |  [2379759](https://moonbase.subscan.io/block/2379759){target=\_blank}  |
|                                           1700                                           |                                   -                                    |                                    -                                    |  [2529736](https://moonbase.subscan.io/block/2529736){target=\_blank}  |
|                                           1701                                           |  [1581457](https://moonbeam.subscan.io/block/1581457){target=\_blank}  |  [2281723](https://moonriver.subscan.io/block/2281723){target=\_blank}  |  [2534200](https://moonbase.subscan.io/block/2534200){target=\_blank}  |
|                                           1702                                           |  [1821212](https://moonbeam.subscan.io/block/1821212){target=\_blank}  |  [2524247](https://moonriver.subscan.io/block/2524247){target=\_blank}  |                                   -                                    |
|                                           1800                                           |                                   -                                    |                                    -                                    |  [2748786](https://moonbase.subscan.io/block/2748786){target=\_blank}  |
|                                           1801                                           |                                   -                                    |  [2572556](https://moonriver.subscan.io/block/2572556){target=\_blank}  |  [2830542](https://moonbase.subscan.io/block/2830542){target=\_blank}  |
|                                           1802                                           |  [1919458](https://moonbeam.subscan.io/block/1919458){target=\_blank}  |  [2616190](https://moonriver.subscan.io/block/2616190){target=\_blank}  |  [2879403](https://moonbase.subscan.io/block/2879403){target=\_blank}  |
|                                           1803                                           |  [2073477](https://moonbeam.subscan.io/block/2073477){target=\_blank}  |  [2767174](https://moonriver.subscan.io/block/2767174){target=\_blank}  |  [3004714](https://moonbase.subscan.io/block/3004714){target=\_blank}  |
|                                           1900                                           |                                   -                                    |                                    -                                    |  [3069635](https://moonbase.subscan.io/block/3069635){target=\_blank}  |
|                                           1901                                           |  [2317683](https://moonbeam.subscan.io/block/2317683){target=\_blank}  |  [2911863](https://moonriver.subscan.io/block/2911863){target=\_blank}  |  [3073562](https://moonbase.subscan.io/block/3073562){target=\_blank}  |
|                                           2000                                           |  [2673234](https://moonbeam.subscan.io/block/2673234){target=\_blank}  |  [3202604](https://moonriver.subscan.io/block/3202604){target=\_blank}  |  [3310369](https://moonbase.subscan.io/block/3310369){target=\_blank}  |
|                                           2100                                           |  [3011798](https://moonbeam.subscan.io/block/3011798){target=\_blank}  |  [3588831](https://moonriver.subscan.io/block/3588831){target=\_blank}  |  [3609708](https://moonbase.subscan.io/block/3609708){target=\_blank}  |
|                                           2201                                           |  [3290853](https://moonbeam.subscan.io/block/3290853){target=\_blank}  |  [3858885](https://moonriver.subscan.io/block/3858885){target=\_blank}  |  [3842850](https://moonbase.subscan.io/block/3842850){target=\_blank}  |
|                                           2301                                           |                                   -                                    |                                    -                                    |  [4172407](https://moonbase.subscan.io/block/4172407){target=\_blank}  |
|                                           2302                                           |  [3456477](https://moonbeam.subscan.io/block/3456477){target=\_blank}  |  [4133065](https://moonriver.subscan.io/block/4133065){target=\_blank}  |  [4193323](https://moonbase.subscan.io/block/4193323){target=\_blank}  |
|                                           2401                                           |                                   -                                    |  [4668844](https://moonriver.subscan.io/block/4668844){target=\_blank}  |  [4591616](https://moonbase.subscan.io/block/4591616){target=\_blank}  |
|                                           2402                                           |                                   -                                    |                                    -                                    |  [4772817](https://moonbase.subscan.io/block/4772817){target=\_blank}  |
|                                           2403                                           |  [4163078](https://moonbeam.subscan.io/block/4163078){target=\_blank}  |  [4770488](https://moonriver.subscan.io/block/4770488){target=\_blank}  |  [4804425](https://moonbase.subscan.io/block/4804425){target=\_blank}  |
|                                           2500                                           |                                   -                                    |  [5175574](https://moonriver.subscan.io/block/5175574){target=\_blank}  |  [5053547](https://moonbase.subscan.io/block/5053547){target=\_blank}  |
|                                           2501                                           |  [4543267](https://moonbeam.subscan.io/block/4543267){target=\_blank}  |  [5211264](https://moonriver.subscan.io/block/5211264){target=\_blank}  |  [5194594](https://moonbase.subscan.io/block/5194594){target=\_blank}  |
| [2601](https://forum.moonbeam.network/t/runtime-rt2600-schedule/1372/5){target=\_blank}  |                                   -                                    |                                    -                                    |  [5474345](https://moonbase.subscan.io/block/5474345){target=\_blank}  |
| [2602](https://forum.moonbeam.network/t/runtime-rt2600-schedule/1372/13){target=\_blank} |  [4977160](https://moonbeam.subscan.io/block/4977160){target=\_blank}  |  [5638536](https://moonriver.subscan.io/block/5638536){target=\_blank}  |  [5576588](https://moonbase.subscan.io/block/5576588){target=\_blank}  |
| [2700](https://forum.moonbeam.network/t/runtime-rt2700-schedule/1441/3){target=\_blank}  |  [5504531](https://moonbeam.subscan.io/block/5504531){target=\_blank}  |  [6041969](https://moonriver.subscan.io/block/6041969){target=\_blank}  |  [5860584](https://moonbase.subscan.io/block/5860584){target=\_blank}  |
| [2801](https://forum.moonbeam.network/t/runtime-rt2801-schedule/1616/4){target=\_blank}  |  [5899847](https://moonbeam.subscan.io/block/5899847){target=\_blank}  |  [6411588](https://moonriver.subscan.io/block/6411588){target=\_blank}  |  [6209638](https://moonbase.subscan.io/block/6209638){target=\_blank}  |
| [2901](https://forum.moonbeam.network/t/runtime-rt2901-schedule/1695/3){target=\_blank}  |  [6197065](https://moonbeam.subscan.io/block/6197065){target=\_blank}  |  [6699589](https://moonriver.subscan.io/block/6699589){target=\_blank}  |  [6710531](https://moonbase.subscan.io/block/6710531){target=\_blank}  |
|                                           2902                                           |                                   -                                    |                                    -                                    |  [6732678](https://moonbase.subscan.io/block/6732678){target=\_blank}  |
| [3000](https://forum.moonbeam.network/t/runtime-rt3000-schedule/1752/2){target=\_blank}  |                                   -                                    |  [7043011](https://moonriver.subscan.io/block/7043011){target=\_blank}  |  [7299818](https://moonbase.subscan.io/block/7299818){target=\_blank}  |
|                                           3001                                           |  [6593037](https://moonbeam.subscan.io/block/6593037){target=\_blank}  |                                    -                                    |                                   -                                    |
|  [3100](https://forum.moonbeam.network/t/runtime-rt3100-schedule/1801){target=\_blank}   |  [7303601](https://moonbeam.subscan.io/block/7303601){target=\_blank}  |  [7829527](https://moonriver.subscan.io/block/7829527){target=\_blank}  |  [8034666](https://moonbase.subscan.io/block/8034666){target=\_blank}  |
| [3102](https://forum.moonbeam.network/t/runtime-rt3100-schedule/1801/10){target=\_blank} |  [7586782](https://moonbeam.subscan.io/block/7586782){target=\_blank}  |                                    -                                    |                                   -                                    |
|  [3200](https://forum.moonbeam.network/t/runtime-rt3200-schedule/1881){target=\_blank}   |  [7985204](https://moonbeam.subscan.io/block/7985204){target=\_blank}  |  [8519187](https://moonriver.subscan.io/block/8519187){target=\_blank}  |  [8722328](https://moonbase.subscan.io/block/8722328){target=\_blank}  |
|  [3300](https://forum.moonbeam.network/t/runtime-rt3300-schedule/1897){target=\_blank}   |  [8381443](https://moonbeam.subscan.io/block/8381443){target=\_blank}  |  [8894417](https://moonriver.subscan.io/block/8894417){target=\_blank}  |  [9062316](https://moonbase.subscan.io/block/9062316){target=\_blank}  |
|  [3400](https://forum.moonbeam.network/t/runtime-rt3400-schedule/1954){target=\_blank}   |  [9376921](https://moonbeam.subscan.io/block/9376921){target=\_blank}  |  [9774989](https://moonriver.subscan.io/block/9774989){target=\_blank}  |  [9830392](https://moonbase.subscan.io/block/9830392){target=\_blank}  |
| [3401](https://forum.moonbeam.network/t/runtime-rt3400-schedule/1954/6){target=\_blank}  |  [9661355](https://moonbeam.subscan.io/block/9661355){target=\_blank}  | [10269872](https://moonriver.subscan.io/block/10269872){target=\_blank} | [10422450](https://moonbase.subscan.io/block/10422450){target=\_blank} |
|  [3500](https://forum.moonbeam.network/t/runtime-rt3501-schedule/2010){target=\_blank}   |                                   -                                    |                                    -                                    | [10750816](https://moonbase.subscan.io/block/10750816){target=\_blank} |
|  [3501](https://forum.moonbeam.network/t/runtime-rt3501-schedule/2010){target=\_blank}   | [10056989](https://moonbeam.subscan.io/block/10056989){target=\_blank} | [10665393](https://moonriver.subscan.io/block/10665393){target=\_blank} | [10833906](https://moonbase.subscan.io/block/10833906){target=\_blank} |
|  [3600](https://forum.moonbeam.network/t/runtime-rt3600-schedule/2071){target=\_blank}   |                                   [10746745](https://moonbeam.subscan.io/block/10746745){target=\_blank}                                    |        [11251274](https://moonriver.subscan.io/block/11251274){target=\_blank} | [11452321](https://moonbase.subscan.io/block/11452321){target=\_blank} |
|  [3601](https://forum.moonbeam.network/t/proposals-mr77-mb110-whitelisted-authorize-upgrade-to-rt3601-on-moonriver-and-moonbeam/2139){target=\_blank}   |                                   [10999397](https://moonbeam.subscan.io/block/10999397){target=\_blank}                                    |        [11692212](https://moonriver.subscan.io/block/11692212){target=\_blank} | - |
| [3700](https://forum.moonbeam.network/t/runtime-rt3700-schedule/2129){target=\_blank}    |                                   -                                    |                                    -                                    | [12152458](https://moonbase.subscan.io/block/12152458){target=\_blank} |
| [3701](https://forum.moonbeam.network/t/runtime-rt3700-schedule/2129){target=\_blank}    |                                   [11426910](https://moonbeam.subscan.io/block/11426910)                                    |                                    [12003279](https://moonriver.subscan.io/block/12003279){target=\_blank}                                   | [12242104](https://moonbase.subscan.io/block/12242104){target=\_blank} |
| [3702](https://forum.moonbeam.network/t/proposals-mr81-mb118-authorize-upgrade-to-rt3702-on-moonriver-and-moonbeam-via-whitelist/2173){target=\_blank}                                           | [11499659](https://moonbeam.subscan.io/block/11499659){target=\_blank} | [12156948](https://moonriver.subscan.io/block/12156948){target=\_blank} | [12683255](https://moonbase.subscan.io/block/12683255){target=\_blank} |
| [3800](https://forum.moonbeam.network/t/runtime-rt3800-schedule/2188){target=\_blank}    |                                   [12120762](https://moonbeam.subscan.io/block/12120762){target=\_blank}                                    | [12540836](https://moonriver.subscan.io/block/12540836){target=\_blank} | [12853655](https://moonbase.subscan.io/block/12853655){target=\_blank} |
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/builders/ethereum/canonical-contracts/
--- BEGIN CONTENT ---
---
title: Canonical Contract Addresses on Moonbeam
description: Overview of the canonical contracts available on Moonbeam, Moonriver, & Moonbase Alpha, including common-good contracts and precompiles.
keywords: canonical, ethereum, moonbeam, precompiled, contracts
categories: Reference, Precompiles, Ethereum Toolkit
---

# Canonical Contracts

## Common-good Contracts {: #common-goods-contracts }

The following contracts addresses have been established:

=== "Moonbeam"
    |                                                         Contract                                                         |                  Address                   |
    |:------------------------------------------------------------------------------------------------------------------------:|:------------------------------------------:|
    |      [WGLMR](https://moonbeam.moonscan.io/address/0xAcc15dC74880C9944775448304B263D191c6077F#code){target=\_blank}       | 0xAcc15dC74880C9944775448304B263D191c6077F |
    |    [Multicall](https://moonbeam.moonscan.io/address/0x83e3b61886770de2F64AAcaD2724ED4f08F7f36B#code){target=\_blank}     | 0x83e3b61886770de2F64AAcaD2724ED4f08F7f36B |
    |    [Multicall2](https://moonbeam.moonscan.io/address/0x6477204E12A7236b9619385ea453F370aD897bb2#code){target=\_blank}    | 0x6477204E12A7236b9619385ea453F370aD897bb2 |
    |    [Multicall3](https://moonbeam.moonscan.io/address/0xca11bde05977b3631167028862be2a173976ca11#code){target=\_blank}    | 0xcA11bde05977b3631167028862bE2a173976CA11 |
    | [Multisig Factory](https://moonbeam.moonscan.io/address/0xa6B71E26C5e0845f74c812102Ca7114b6a896AB2#code){target=\_blank} | 0xa6B71E26C5e0845f74c812102Ca7114b6a896AB2 |
    |                           [EIP-1820](https://eips.ethereum.org/EIPS/eip-1820){target=\_blank}                            | 0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24 |

=== "Moonriver"
    |                                                         Contract                                                          |                  Address                   |
    |:-------------------------------------------------------------------------------------------------------------------------:|:------------------------------------------:|
    |       [WMOVR](https://moonriver.moonscan.io/token/0x98878b06940ae243284ca214f92bb71a2b032b8a#code){target=\_blank}        | 0x98878B06940aE243284CA214f92Bb71a2b032B8A |
    |    [Multicall](https://moonriver.moonscan.io/address/0x30f283Cc0284482e9c29dFB143bd483B5C19954b#code){target=\_blank}*    | 0x30f283Cc0284482e9c29dFB143bd483B5C19954b |
    |    [Multicall2](https://moonriver.moonscan.io/address/0xaef00a0cf402d9dedd54092d9ca179be6f9e5ce3#code){target=\_blank}    | 0xaef00a0cf402d9dedd54092d9ca179be6f9e5ce3 |
    |    [Multicall3](https://moonriver.moonscan.io/address/0xca11bde05977b3631167028862be2a173976ca11#code){target=\_blank}    | 0xcA11bde05977b3631167028862bE2a173976CA11 |
    | [Multisig Factory](https://moonriver.moonscan.io/address/0xa6B71E26C5e0845f74c812102Ca7114b6a896AB2#code){target=\_blank} | 0xa6B71E26C5e0845f74c812102Ca7114b6a896AB2 |
    |                            [EIP-1820](https://eips.ethereum.org/EIPS/eip-1820){target=\_blank}                            | 0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24 |

    _*Deployed by SushiSwap_

=== "Moonbase Alpha"
    |                                                         Contract                                                         |                  Address                   |
    |:------------------------------------------------------------------------------------------------------------------------:|:------------------------------------------:|
    |       [WDEV](https://moonbase.moonscan.io/address/0xD909178CC99d318e4D46e7E66a972955859670E1#code){target=\_blank}       | 0xD909178CC99d318e4D46e7E66a972955859670E1 |
    |    [Multicall](https://moonbase.moonscan.io/address/0x4E2cfca20580747AdBA58cd677A998f8B261Fc21#code){target=\_blank}*    | 0x4E2cfca20580747AdBA58cd677A998f8B261Fc21 |
    |    [Multicall2](https://moonbase.moonscan.io/address/0x37084d0158C68128d6Bc3E5db537Be996f7B6979#code){target=\_blank}    | 0x37084d0158C68128d6Bc3E5db537Be996f7B6979 |
    |    [Multicall3](https://moonbase.moonscan.io/address/0xca11bde05977b3631167028862be2a173976ca11#code){target=\_blank}    | 0xcA11bde05977b3631167028862bE2a173976CA11 |
    | [Multisig Factory](https://moonbase.moonscan.io/address/0xa6B71E26C5e0845f74c812102Ca7114b6a896AB2#code){target=\_blank} | 0xa6B71E26C5e0845f74c812102Ca7114b6a896AB2 |
    |                           [EIP-1820](https://eips.ethereum.org/EIPS/eip-1820){target=\_blank}                            | 0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24 |

    _*Deployed in the [UniswapV2 Demo Repo](https://github.com/papermoonio/moonbeam-uniswap/tree/main/uniswap-contracts-moonbeam){target=\_blank}_

## Precompiled Contracts {: #precompiled-contracts }

There are a set of precompiled contracts included on Moonbeam, Moonriver, and Moonbase Alpha that are categorized by address and based on the origin network. If you were to convert the precompiled addresses to decimal format, and break them into categories by numeric value, the categories are as follows:

- **0-1023** - [Ethereum MainNet precompiles](#ethereum-mainnet-precompiles)
- **1024-2047** - precompiles that are [not in Ethereum and not Moonbeam specific](#non-moonbeam-specific-nor-ethereum-precomiles)
- **2048-4095** - [Moonbeam specific precompiles](#moonbeam-specific-precompiles)

### Ethereum MainNet Precompiles {: #ethereum-mainnet-precompiles }

=== "Moonbeam"
    |                                                          Contract                                                           |                  Address                   |
    |:---------------------------------------------------------------------------------------------------------------------------:|:------------------------------------------:|
    |      [ECRECOVER](/builders/ethereum/precompiles/utility/eth-mainnet/#verify-signatures-with-ecrecover){target=\_blank}      | 0x0000000000000000000000000000000000000001 |
    |              [SHA256](/builders/ethereum/precompiles/utility/eth-mainnet/#hashing-with-sha256){target=\_blank}              | 0x0000000000000000000000000000000000000002 |
    |          [RIPEMD160](/builders/ethereum/precompiles/utility/eth-mainnet/#hashing-with-ripemd-160){target=\_blank}           | 0x0000000000000000000000000000000000000003 |
    |            [Identity](/builders/ethereum/precompiles/utility/eth-mainnet/#the-identity-function){target=\_blank}            | 0x0000000000000000000000000000000000000004 |
    |    [Modular Exponentiation](/builders/ethereum/precompiles/utility/eth-mainnet/#modular-exponentiation){target=\_blank}     | 0x0000000000000000000000000000000000000005 |
    |                  [BN128Add](/builders/ethereum/precompiles/utility/eth-mainnet/#bn128add){target=\_blank}                   | 0x0000000000000000000000000000000000000006 |
    |                  [BN128Mul](/builders/ethereum/precompiles/utility/eth-mainnet/#bn128mul){target=\_blank}                   | 0x0000000000000000000000000000000000000007 |
    |              [BN128Pairing](/builders/ethereum/precompiles/utility/eth-mainnet/#bn128pairing){target=\_blank}               | 0x0000000000000000000000000000000000000008 |
    | [Blake2](https://polkadot-evm.github.io/frontier/rustdocs/pallet_evm_precompile_blake2/struct.Blake2F.html){target=\_blank} | 0x0000000000000000000000000000000000000009 |
    |                 [P256Verify](https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7212.md){target=\_blank}                 | 0x0000000000000000000000000000000000000100 |

=== "Moonriver"
    |                                                          Contract                                                           |                  Address                   |
    |:---------------------------------------------------------------------------------------------------------------------------:|:------------------------------------------:|
    |      [ECRECOVER](/builders/ethereum/precompiles/utility/eth-mainnet/#verify-signatures-with-ecrecover){target=\_blank}      | 0x0000000000000000000000000000000000000001 |
    |              [SHA256](/builders/ethereum/precompiles/utility/eth-mainnet/#hashing-with-sha256){target=\_blank}              | 0x0000000000000000000000000000000000000002 |
    |          [RIPEMD160](/builders/ethereum/precompiles/utility/eth-mainnet/#hashing-with-ripemd-160){target=\_blank}           | 0x0000000000000000000000000000000000000003 |
    |            [Identity](/builders/ethereum/precompiles/utility/eth-mainnet/#the-identity-function){target=\_blank}            | 0x0000000000000000000000000000000000000004 |
    |    [Modular Exponentiation](/builders/ethereum/precompiles/utility/eth-mainnet/#modular-exponentiation){target=\_blank}     | 0x0000000000000000000000000000000000000005 |
    |                  [BN128Add](/builders/ethereum/precompiles/utility/eth-mainnet/#bn128add){target=\_blank}                   | 0x0000000000000000000000000000000000000006 |
    |                  [BN128Mul](/builders/ethereum/precompiles/utility/eth-mainnet/#bn128mul){target=\_blank}                   | 0x0000000000000000000000000000000000000007 |
    |              [BN128Pairing](/builders/ethereum/precompiles/utility/eth-mainnet/#bn128pairing){target=\_blank}               | 0x0000000000000000000000000000000000000008 |
    | [Blake2](https://polkadot-evm.github.io/frontier/rustdocs/pallet_evm_precompile_blake2/struct.Blake2F.html){target=\_blank} | 0x0000000000000000000000000000000000000009 |
    |                 [P256Verify](https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7212.md){target=\_blank}                 | 0x0000000000000000000000000000000000000100 |

=== "Moonbase Alpha"
    |                                                          Contract                                                           |                  Address                   |
    |:---------------------------------------------------------------------------------------------------------------------------:|:------------------------------------------:|
    |      [ECRECOVER](/builders/ethereum/precompiles/utility/eth-mainnet/#verify-signatures-with-ecrecover){target=\_blank}      | 0x0000000000000000000000000000000000000001 |
    |              [SHA256](/builders/ethereum/precompiles/utility/eth-mainnet/#hashing-with-sha256){target=\_blank}              | 0x0000000000000000000000000000000000000002 |
    |          [RIPEMD160](/builders/ethereum/precompiles/utility/eth-mainnet/#hashing-with-ripemd-160){target=\_blank}           | 0x0000000000000000000000000000000000000003 |
    |            [Identity](/builders/ethereum/precompiles/utility/eth-mainnet/#the-identity-function){target=\_blank}            | 0x0000000000000000000000000000000000000004 |
    |    [Modular Exponentiation](/builders/ethereum/precompiles/utility/eth-mainnet/#modular-exponentiation){target=\_blank}     | 0x0000000000000000000000000000000000000005 |
    |                  [BN128Add](/builders/ethereum/precompiles/utility/eth-mainnet/#bn128add){target=\_blank}                   | 0x0000000000000000000000000000000000000006 |
    |                  [BN128Mul](/builders/ethereum/precompiles/utility/eth-mainnet/#bn128mul){target=\_blank}                   | 0x0000000000000000000000000000000000000007 |
    |              [BN128Pairing](/builders/ethereum/precompiles/utility/eth-mainnet/#bn128pairing){target=\_blank}               | 0x0000000000000000000000000000000000000008 |
    | [Blake2](https://polkadot-evm.github.io/frontier/rustdocs/pallet_evm_precompile_blake2/struct.Blake2F.html){target=\_blank} | 0x0000000000000000000000000000000000000009 |
    |                 [P256Verify](https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7212.md){target=\_blank}                 | 0x0000000000000000000000000000000000000100 |

### Non-Moonbeam Specific nor Ethereum Precompiles {: #non-moonbeam-specific-nor-ethereum-precompiles }

=== "Moonbeam"
    |                                                                      Contract                                                                      |                  Address                   |
    |:--------------------------------------------------------------------------------------------------------------------------------------------------:|:------------------------------------------:|
    |                    [SHA3FIPS256](/builders/ethereum/precompiles/utility/eth-mainnet/#hashing-with-sha3fips256){target=\_blank}                     | 0x0000000000000000000000000000000000000400 |
    |                                                                 Dispatch [Removed]                                                                 | 0x0000000000000000000000000000000000000401 |
    | [ECRecoverPublicKey](https://polkadot-evm.github.io/frontier/rustdocs/pallet_evm_precompile_simple/struct.ECRecoverPublicKey.html){target=\_blank} | 0x0000000000000000000000000000000000000402 |

=== "Moonriver"
    |                                                                      Contract                                                                      |                  Address                   |
    |:--------------------------------------------------------------------------------------------------------------------------------------------------:|:------------------------------------------:|
    |                    [SHA3FIPS256](/builders/ethereum/precompiles/utility/eth-mainnet/#hashing-with-sha3fips256){target=\_blank}                     | 0x0000000000000000000000000000000000000400 |
    |                                                                 Dispatch [Removed]                                                                 | 0x0000000000000000000000000000000000000401 |
    | [ECRecoverPublicKey](https://polkadot-evm.github.io/frontier/rustdocs/pallet_evm_precompile_simple/struct.ECRecoverPublicKey.html){target=\_blank} | 0x0000000000000000000000000000000000000402 |

=== "Moonbase Alpha"
    |                                                                           Contract                                                                            |                  Address                   |
    |:-------------------------------------------------------------------------------------------------------------------------------------------------------------:|:------------------------------------------:|
    |                          [SHA3FIPS256](/builders/ethereum/precompiles/utility/eth-mainnet/#hashing-with-sha3fips256){target=\_blank}                          | 0x0000000000000000000000000000000000000400 |
    |                                                                      Dispatch [Removed]                                                                       | 0x0000000000000000000000000000000000000401 |
    |      [ECRecoverPublicKey](https://polkadot-evm.github.io/frontier/rustdocs/pallet_evm_precompile_simple/struct.ECRecoverPublicKey.html){target=\_blank}       | 0x0000000000000000000000000000000000000402 |

### Moonbeam-Specific Precompiles {: #moonbeam-specific-precompiles }

=== "Moonbeam"
    |                                                                           Contract                                                                            |                               Address                               |
    |:-------------------------------------------------------------------------------------------------------------------------------------------------------------:|:-------------------------------------------------------------------:|
    |      [Parachain Staking](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/parachain-staking/StakingInterface.sol){target=\_blank}      |              {{networks.moonbeam.precompiles.staking}}              |
    |     [Crowdloan Rewards](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/crowdloan-rewards/CrowdloanInterface.sol){target=\_blank}     |             {{networks.moonbeam.precompiles.crowdloan}}             |
    |             [ERC-20 Interface](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/balances-erc20/ERC20.sol){target=\_blank}              |               {{networks.moonbeam.precompiles.erc20}}               |
    |                                                                      Democracy [Removed]                                                                      |             {{networks.moonbeam.precompiles.democracy}}             |
    |                    [X-Tokens](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xtokens/Xtokens.sol){target=\_blank}                    |              {{networks.moonbeam.precompiles.xtokens}}              |
    |            [Relay Encoder](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/relay-encoder/RelayEncoder.sol){target=\_blank}            |           {{networks.moonbeam.precompiles.relay_encoder}}           |
    |    [XCM Transactor V1](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-transactor/src/v1/XcmTransactorV1.sol){target=\_blank}     |         {{networks.moonbeam.precompiles.xcm_transactor_v1}}         |
    |      [Author Mapping](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/author-mapping/AuthorMappingInterface.sol){target=\_blank}      |          {{networks.moonbeam.precompiles.author_mapping}}           |
    |                       [Batch](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/batch/Batch.sol){target=\_blank}                        |               {{networks.moonbeam.precompiles.batch}}               |
    |                [Randomness](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/randomness/Randomness.sol){target=\_blank}                |            {{networks.moonbeam.precompiles.randomness}}             |
    |               [Call Permit](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/call-permit/CallPermit.sol){target=\_blank}               |            {{networks.moonbeam.precompiles.call_permit}}            |
    |                       [Proxy](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/proxy/Proxy.sol){target=\_blank}                        |               {{networks.moonbeam.precompiles.proxy}}               |
    |                [XCM Utilities](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-utils/XcmUtils.sol){target=\_blank}                |             {{networks.moonbeam.precompiles.xcm_utils}}             |
    |    [XCM Transactor V2](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-transactor/src/v2/XcmTransactorV2.sol){target=\_blank}     |         {{networks.moonbeam.precompiles.xcm_transactor_v2}}         |
    |       [Council Collective [Removed]](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}       |        {{networks.moonbeam.precompiles.collective_council}}         |
    | [Technical Committee Collective [Removed]](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank} |     {{networks.moonbeam.precompiles.collective_tech_committee}}     |
    |       [Treasury Council Collective](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}        |        {{networks.moonbeam.precompiles.collective_treasury}}        |
    |                 [Referenda](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/referenda/Referenda.sol){target=\_blank}                  |             {{networks.moonbeam.precompiles.referenda}}             |
    |      [Conviction Voting](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/conviction-voting/ConvictionVoting.sol){target=\_blank}      |         {{networks.moonbeam.precompiles.conviction_voting}}         |
    |                   [Preimage](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/preimage/Preimage.sol){target=\_blank}                   |             {{networks.moonbeam.precompiles.preimage}}              |
    |          [OpenGov Tech Committee](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}          | {{networks.moonbeam.precompiles.collective_opengov_tech_committee}} |
    |   [Precompile Registry](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/precompile-registry/PrecompileRegistry.sol){target=\_blank}   |             {{networks.moonbeam.precompiles.registry}}              |
    |                          [GMP](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/gmp/Gmp.sol){target=\_blank}                           |                {{networks.moonbeam.precompiles.gmp}}                |
    |    [XCM Transactor V3](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-transactor/src/v3/XcmTransactorV3.sol){target=\_blank}     |         {{networks.moonbeam.precompiles.xcm_transactor_v3}}         |
    |                   [Identity](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/identity/Identity.sol){target=\_blank}                   |             {{networks.moonbeam.precompiles.identity}}              |
    |                  [XCM Interface](https://github.com/Moonsong-Labs/moonkit/blob/main/precompiles/pallet-xcm/XcmInterface.sol){target=\_blank}                  |           {{networks.moonbeam.precompiles.xcm_interface}}           |

=== "Moonriver"
    |                                                                           Contract                                                                            |                               Address                                |
    |:-------------------------------------------------------------------------------------------------------------------------------------------------------------:|:--------------------------------------------------------------------:|
    |      [Parachain Staking](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/parachain-staking/StakingInterface.sol){target=\_blank}      |              {{networks.moonriver.precompiles.staking}}              |
    |     [Crowdloan Rewards](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/crowdloan-rewards/CrowdloanInterface.sol){target=\_blank}     |             {{networks.moonriver.precompiles.crowdloan}}             |
    |             [ERC-20 Interface](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/balances-erc20/ERC20.sol){target=\_blank}              |               {{networks.moonriver.precompiles.erc20}}               |
    |                                                                      Democracy [Removed]                                                                      |             {{networks.moonriver.precompiles.democracy}}             |
    |                    [X-Tokens](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xtokens/Xtokens.sol){target=\_blank}                    |              {{networks.moonriver.precompiles.xtokens}}              |
    |            [Relay Encoder](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/relay-encoder/RelayEncoder.sol){target=\_blank}            |           {{networks.moonriver.precompiles.relay_encoder}}           |
    |    [XCM Transactor V1](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-transactor/src/v1/XcmTransactorV1.sol){target=\_blank}     |         {{networks.moonriver.precompiles.xcm_transactor_v1}}         |
    |      [Author Mapping](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/author-mapping/AuthorMappingInterface.sol){target=\_blank}      |          {{networks.moonriver.precompiles.author_mapping}}           |
    |                       [Batch](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/batch/Batch.sol){target=\_blank}                        |               {{networks.moonriver.precompiles.batch}}               |
    |                [Randomness](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/randomness/Randomness.sol){target=\_blank}                |            {{networks.moonriver.precompiles.randomness}}             |
    |               [Call Permit](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/call-permit/CallPermit.sol){target=\_blank}               |            {{networks.moonriver.precompiles.call_permit}}            |
    |                       [Proxy](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/proxy/Proxy.sol){target=\_blank}                        |               {{networks.moonriver.precompiles.proxy}}               |
    |                [XCM Utilities](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-utils/XcmUtils.sol){target=\_blank}                |             {{networks.moonriver.precompiles.xcm_utils}}             |
    |    [XCM Transactor V2](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-transactor/src/v2/XcmTransactorV2.sol){target=\_blank}     |         {{networks.moonriver.precompiles.xcm_transactor_v2}}         |
    |       [Council Collective [Removed]](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}       |        {{networks.moonriver.precompiles.collective_council}}         |
    | [Technical Committee Collective [Removed]](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank} |     {{networks.moonriver.precompiles.collective_tech_committee}}     |
    |       [Treasury Council Collective](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}        |        {{networks.moonriver.precompiles.collective_treasury}}        |
    |                 [Referenda](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/referenda/Referenda.sol){target=\_blank}                  |             {{networks.moonriver.precompiles.referenda}}             |
    |      [Conviction Voting](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/conviction-voting/ConvictionVoting.sol){target=\_blank}      |         {{networks.moonriver.precompiles.conviction_voting}}         |
    |                   [Preimage](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/preimage/Preimage.sol){target=\_blank}                   |             {{networks.moonriver.precompiles.preimage}}              |
    |          [OpenGov Tech Committee](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}          | {{networks.moonriver.precompiles.collective_opengov_tech_committee}} |
    |   [Precompile Registry](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/precompile-registry/PrecompileRegistry.sol){target=\_blank}   |             {{networks.moonriver.precompiles.registry}}              |
    |                          [GMP](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/gmp/Gmp.sol){target=\_blank}                           |                {{networks.moonriver.precompiles.gmp}}                |
    |    [XCM Transactor V3](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-transactor/src/v3/XcmTransactorV3.sol){target=\_blank}     |         {{networks.moonriver.precompiles.xcm_transactor_v3}}         |
    |                   [Identity](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/identity/Identity.sol){target=\_blank}                   |             {{networks.moonriver.precompiles.identity}}              |
    |                  [XCM Interface](https://github.com/Moonsong-Labs/moonkit/blob/main/precompiles/pallet-xcm/XcmInterface.sol){target=\_blank}                  |           {{networks.moonriver.precompiles.xcm_interface}}           |

=== "Moonbase Alpha"
    |                                                                           Contract                                                                            |                               Address                               |
    |:-------------------------------------------------------------------------------------------------------------------------------------------------------------:|:-------------------------------------------------------------------:|
    |      [Parachain Staking](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/parachain-staking/StakingInterface.sol){target=\_blank}      |              {{networks.moonbase.precompiles.staking}}              |
    |     [Crowdloan Rewards](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/crowdloan-rewards/CrowdloanInterface.sol){target=\_blank}     |             {{networks.moonbase.precompiles.crowdloan}}             |
    |             [ERC-20 Interface](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/balances-erc20/ERC20.sol){target=\_blank}              |               {{networks.moonbase.precompiles.erc20}}               |
    |                                                                      Democracy [Removed]                                                                      |             {{networks.moonbase.precompiles.democracy}}             |
    |                    [X-Tokens](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xtokens/Xtokens.sol){target=\_blank}                    |              {{networks.moonbase.precompiles.xtokens}}              |
    |            [Relay Encoder](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/relay-encoder/RelayEncoder.sol){target=\_blank}            |           {{networks.moonbase.precompiles.relay_encoder}}           |
    |    [XCM Transactor V1](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-transactor/src/v1/XcmTransactorV1.sol){target=\_blank}     |         {{networks.moonbase.precompiles.xcm_transactor_v1}}         |
    |      [Author Mapping](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/author-mapping/AuthorMappingInterface.sol){target=\_blank}      |          {{networks.moonbase.precompiles.author_mapping}}           |
    |                       [Batch](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/batch/Batch.sol){target=\_blank}                        |               {{networks.moonbase.precompiles.batch}}               |
    |                [Randomness](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/randomness/Randomness.sol){target=\_blank}                |            {{networks.moonbase.precompiles.randomness}}             |
    |               [Call Permit](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/call-permit/CallPermit.sol){target=\_blank}               |            {{networks.moonbase.precompiles.call_permit}}            |
    |                       [Proxy](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/proxy/Proxy.sol){target=\_blank}                        |               {{networks.moonbase.precompiles.proxy}}               |
    |                [XCM Utilities](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-utils/XcmUtils.sol){target=\_blank}                |             {{networks.moonbase.precompiles.xcm_utils}}             |
    |    [XCM Transactor V2](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-transactor/src/v2/XcmTransactorV2.sol){target=\_blank}     |         {{networks.moonbase.precompiles.xcm_transactor_v2}}         |
    |       [Council Collective [Removed]](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}       |        {{networks.moonbase.precompiles.collective_council}}         |
    | [Technical Committee Collective [Removed]](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank} |     {{networks.moonbase.precompiles.collective_tech_committee}}     |
    |       [Treasury Council Collective](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}        |        {{networks.moonbase.precompiles.collective_treasury}}        |
    |                 [Referenda](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/referenda/Referenda.sol){target=\_blank}                  |             {{networks.moonbase.precompiles.referenda}}             |
    |      [Conviction Voting](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/conviction-voting/ConvictionVoting.sol){target=\_blank}      |         {{networks.moonbase.precompiles.conviction_voting}}         |
    |                   [Preimage](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/preimage/Preimage.sol){target=\_blank}                   |             {{networks.moonbase.precompiles.preimage}}              |
    |          [OpenGov Tech Committee](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}          | {{networks.moonbase.precompiles.collective_opengov_tech_committee}} |
    |   [Precompile Registry](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/precompile-registry/PrecompileRegistry.sol){target=\_blank}   |             {{networks.moonbase.precompiles.registry}}              |
    |                          [GMP](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/gmp/Gmp.sol){target=\_blank}                           |                {{networks.moonbase.precompiles.gmp}}                |
    |    [XCM Transactor V3](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-transactor/src/v3/XcmTransactorV3.sol){target=\_blank}     |         {{networks.moonbase.precompiles.xcm_transactor_v3}}         |
    |                   [Identity](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/identity/Identity.sol){target=\_blank}                   |             {{networks.moonbase.precompiles.identity}}              |
    |                  [XCM Interface](https://github.com/Moonsong-Labs/moonkit/blob/main/precompiles/pallet-xcm/XcmInterface.sol){target=\_blank}                  |           {{networks.moonbase.precompiles.xcm_interface}}           |
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/builders/ethereum/json-rpc/eth-rpc/
--- BEGIN CONTENT ---
---
title: Standard Ethereum JSON-RPC Methods
description: Explore a comprehensive list of standard Ethereum JSON-RPC methods that can be used to interface with Moonbeam nodes programmatically.
categories: JSON-RPC APIs, Reference, Ethereum Toolkit
---

# Supported Ethereum RPC Methods

## Introduction {: #introduction }

The Moonbeam team has collaborated closely with [Parity](https://www.parity.io){target=\_blank} on developing [Frontier](/learn/platform/technology/#frontier){target=\_blank}, an Ethereum compatibility layer for Substrate-based chains. This layer enables developers to run unmodified Ethereum dApps on Moonbeam seamlessly.

Nevertheless, not all Ethereum JSON-RPC methods are supported; some of those supported return default values (those related to Ethereum's PoW consensus mechanism in particular). This guide provides a comprehensive list of supported Ethereum JSON-RPC methods on Moonbeam. Developers can quickly reference this list to understand the available functionality for interfacing with Moonbeam's Ethereum-compatible blockchain.

## Standard Ethereum JSON-RPC Methods {: #basic-rpc-methods }

The basic JSON-RPC methods from the Ethereum API supported by Moonbeam are:

- **[eth_protocolVersion](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_protocolversion){target=\_blank}** — returns `1` by default
- **[eth_syncing](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_syncing){target=\_blank}** — returns an object with data about the sync status or `false`
- **[eth_hashrate](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_hashrate){target=\_blank}** — returns `"0x0"` by default
- **[eth_coinbase](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_coinbase){target=\_blank}** — returns the latest block author. Not necessarily a finalized block
- **[eth_mining](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_mining){target=\_blank}** — returns `false` by default
- **[eth_chainId](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_chainid){target=\_blank}** — returns the chain ID used for signing at the current block
- **[eth_gasPrice](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_gasprice){target=\_blank}** — returns the base fee per unit of gas used. This is currently the minimum gas price for each network
- **[eth_accounts](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_accounts){target=\_blank}** — returns a list of addresses owned by the client
- **[eth_blockNumber](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_blocknumber){target=\_blank}** — returns the highest available block number
- **[eth_getBalance](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getbalance){target=\_blank}** — returns the balance of the given address. Instead of providing a block number as a parameter, you can provide a [default block parameter](#default-block-parameters)
- **[eth_getStorageAt](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getstorageat){target=\_blank}** — returns the content of the storage at a given address. Instead of providing a block number as a parameter, you can provide a [default block parameter](#default-block-parameters)
- **[eth_getBlockByHash](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getblockbyhash){target=\_blank}** — returns information about the block of the given hash, including `baseFeePerGas` on post-London blocks
- **[eth_getBlockByNumber](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getblockbynumber){target=\_blank}** — returns information about the block specified by block number, including `baseFeePerGas` on post-London blocks. Instead of providing a block number as the first parameter, you can provide a [default block parameter](#default-block-parameters)
- **[eth_getBlockReceipts](https://www.alchemy.com/docs/node/ethereum/ethereum-api-endpoints/eth-get-block-receipts){target=\_blank}** — returns all transaction receipts for a given block
- **[eth_getTransactionCount](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_gettransactioncount){target=\_blank}** — returns the number of transactions sent from the given address (nonce). Instead of providing a block number as a parameter, you can provide a [default block parameter](#default-block-parameters)
- **[eth_getBlockTransactionCountByHash](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getblocktransactioncountbyhash){target=\_blank}** — returns the number of transactions in a block with a given block hash
- **[eth_getBlockTransactionCountByNumber](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getblocktransactioncountbynumber){target=\_blank}** — returns the number of transactions in a block with a given block number
- **[eth_getUncleCountByBlockHash](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getunclecountbyblockhash){target=\_blank}** —  returns `"0x0"` by default
- **[eth_getUncleCountByBlockNumber](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getunclecountbyblocknumber){target=\_blank}** — returns `"0x0"` by default
- **[eth_getCode](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getcode){target=\_blank}** — returns the code at the given address at the given block number. Instead of providing a block number as a parameter, you can provide a [default block parameter](#default-block-parameters)
- **[eth_sendTransaction](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_sendtransaction){target=\_blank}** — creates a new message call transaction or a contract creation, if the data field contains code. Returns the transaction hash or the zero hash if the transaction is not yet available
- **[eth_sendRawTransaction](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_sendrawtransaction){target=\_blank}** — creates a new message call transaction or a contract creation for signed transactions. Returns the transaction hash or the zero hash if the transaction is not yet available
- **[eth_call](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_call){target=\_blank}** — executes a new message call immediately without creating a transaction on the blockchain, returning the value of the executed call
    - Moonbeam supports the use of the optional _state override set_ object. This address-to-state mapping object allows the user to specify some state to be ephemerally overridden before executing a call to `eth_call`. The state override set is commonly used for tasks like debugging smart contracts. Visit the [go-ethereum](https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-eth#:~:text=Object%20%2D%20State%20override%20set){target=\_blank} documentation to learn more
    - Instead of providing a block number as a parameter, you can provide a [default block parameter](#default-block-parameters)
- **[eth_estimateGas](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_estimategas){target=\_blank}** — returns an estimated amount of gas necessary for a given transaction to succeed. You can optionally specify a `gasPrice` or `maxFeePerGas` and `maxPriorityFeePerGas`. Instead of providing a block number as a parameter, you can provide a [default block parameter](#default-block-parameters)
- **[eth_maxPriorityFeePerGas](https://www.alchemy.com/docs/node/ethereum/ethereum-api-endpoints/eth-max-priority-fee-per-gas){target=\_blank}** - returns an estimate of how much priority fee, in Wei, is needed for inclusion in a block
- **[eth_feeHistory](https://www.alchemy.com/docs/node/ethereum/ethereum-api-endpoints/eth-fee-history){target=\_blank}** — returns `baseFeePerGas`, `gasUsedRatio`, `oldestBlock`, and `reward` for a specified range of up to 1024 blocks
- **[eth_getTransactionByHash](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_gettransactionbyhash){target=\_blank}** — returns the information about a transaction with a given hash. EIP-1559 transactions have `maxPriorityFeePerGas` and `maxFeePerGas` fields
- **[eth_getTransactionByBlockHashAndIndex](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_gettransactionbyblockhashandindex){target=\_blank}** — returns information about a transaction at a given block hash and a given index position. EIP-1559 transactions have `maxPriorityFeePerGas` and `maxFeePerGas` fields
- **[eth_getTransactionByBlockNumberAndIndex](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_gettransactionbyblocknumberandindex){target=\_blank}** — returns information about a transaction at a given block number and a given index position. EIP-1559 transactions have `maxPriorityFeePerGas` and `maxFeePerGas` fields. Instead of providing a block number as a parameter, you can provide a [default block parameter](#default-block-parameters)
- **[eth_getTransactionReceipt](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_gettransactionreceipt){target=\_blank}** — returns the transaction receipt of a given transaction hash
- **[eth_getUncleByBlockHashAndIndex](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getunclebyblockhashandindex){target=\_blank}** — returns `null` by default
- **[eth_getUncleByBlockNumberAndIndex](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getunclebyblocknumberandindex){target=\_blank}** — returns `null` by default
- **[eth_getLogs](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getlogs){target=\_blank}** — returns an array of all logs matching a given filter object. Instead of providing a block number as a parameter, you can provide a [default block parameter](#default-block-parameters)
- **[eth_newFilter](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_newfilter){target=\_blank}** — creates a filter object based on the input provided. Returns a filter ID
- **[eth_newBlockFilter](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_newblockfilter){target=\_blank}** — creates a filter in the node to notify when a new block arrives. Returns a filter ID
- **[eth_newPendingTransactionFilter](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_newpendingtransactionfilter){target=\_blank}** - creates a filter in the node to notify when new pending transactions arrive. Returns a filter ID
- **[eth_getFilterChanges](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getfilterchanges){target=\_blank}** — polling method for filters (see methods above). Returns an array of logs that occurred since the last poll
- **[eth_getFilterLogs](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getfilterlogs){target=\_blank}** — returns an array of all the logs matching the filter with a given ID
- **[eth_uninstallFilter](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_uninstallfilter){target=\_blank}** — uninstall a filter with a given ID. It should be used when polling is no longer needed. Filters timeout when they are not requested using `eth_getFilterChanges` after some time

## Default Block Parameters {: #default-block-parameters }

Moonbeam supports several default block parameters that allow you to query a subset of JSON-RPC methods at significant block heights. Moonbeam supports the following default block parameters: 

- `finalized` - Refers to the most recent block that Polkadot validators have finalized
- `safe` - Synonymous with `finalized` in Moonbeam. In Ethereum, `safe` refers to the most recent block that is considered safe by the network, meaning it is unlikely to be reverted but has not yet been finalized. With Moonbeam's fast and deterministic finality, `finalized` and `safe` refer to the same blocks. 
- `earliest` - Refers to the genesis block of the blockchain
- `pending` - Represents the latest state, including pending transactions that have not yet been mined into a block. This is a live view of the mempool
- `latest` - Refers to the latest confirmed block in the blockchain, which may not be finalized

## Unsupported Ethereum JSON-RPC Methods {: #unsupported-rpc-methods }

Moonbeam does not support the following Ethereum API JSON-RPC methods:

 - **[eth_getProof](https://www.alchemy.com/docs/node/ethereum/ethereum-api-endpoints/eth-get-proof){target=\_blank}** - returns the account and storage values of the specified account including the Merkle-proof
 - **[eth_blobBaseFee](https://www.quicknode.com/docs/ethereum/eth_blobBaseFee){target=\_blank}** - returns the expected base fee for blobs in the next block
 - **[eth_createAccessList](https://www.alchemy.com/docs/node/ethereum/ethereum-api-endpoints/eth-create-access-list){target=\_blank}** - creates an EIP-2930 type `accessList` based on a given transaction object
 - **[eth_sign](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_sign){target=\_blank}** - allows the user to sign an arbitrary hash to be sent at a later time. Presents a [security risk](https://support.metamask.io/privacy-and-security/what-is-eth_sign-and-why-is-it-a-risk/){target=\_blank} as the arbitrary hash can be fraudulently applied to other transactions
 - **[eth_signTransaction](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_signtransaction){target=\_blank}** - allows the user to sign a transaction to be sent at a later time. It is rarely used due to associated security risks

## Additional RPC Methods {: #additional-rpc-methods }

Check out some of the non-standard Ethereum and Moonbeam-specific RPC methods:

- [Debug and Trace](/builders/ethereum/json-rpc/debug-trace/)
- [Event Subscription](/builders/ethereum/json-rpc/pubsub/)
- [Custom Moonbeam](/builders/ethereum/json-rpc/moonbeam-custom-api/)
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/builders/ethereum/json-rpc/moonbeam-custom-api/
--- BEGIN CONTENT ---
---
title: Moonbeam-specific RPC Methods
description: Discover Moonbeam's specialized API endpoints, featuring custom JSON-RPC methods designed exclusively for Moonbeam functionality.
categories: JSON-RPC APIs, Reference
---

# Moonbeam Custom API

## Introduction {: #introduction }

Moonbeam nodes include support for custom JSON-RPC endpoints: 

- `moon_isBlockFinalized` 
- `moon_isTxFinalized`
- `moon_getEthSyncBlockRange`

These endpoints provide valuable functionality for checking the finality of on-chain events.

To begin exploring Moonbeam's custom JSON-RPC endpoints, you can try out the provided curl examples below. These examples demonstrate how to query the public RPC endpoint of Moonbase Alpha. However, you can easily modify them to use with your own Moonbeam or Moonriver endpoint by changing the URL and API key. If you haven't already, you can obtain your endpoint and API key from one of our supported [Endpoint Providers](/builders/get-started/endpoints/){target=\_blank}.

## Supported Custom RPC Methods {: #rpc-methods }

???+ function "moon_isBlockFinalized"

    Checks for the finality of the block given by its block hash.

    === "Parameters"

        - `block_hash` *string* - the hash of the block, accepts either Substrate-style or Ethereum-style block hash as its input

    === "Returns"

        Returns a boolean: `true` if the block is finalized, `false` if the block is not finalized or not found.

    === "Example"

        ```bash
        curl -H "Content-Type: application/json" -X POST --data '{
          "jsonrpc": "2.0",
          "id": "1",
          "method": "moon_isBlockFinalized",
          "params": ["INSERT_BLOCK_HASH"]
        }' {{ networks.moonbase.rpc_url }}
        ```

???+ function "moon_isTxFinalized"

    Checks for the finality of a transaction given its EVM transaction hash.

    === "Parameters"

        - `tx_hash` *string* - the EVM transaction hash of the transaction 

    === "Returns"

        Returns a boolean: `true` if the transaction is finalized, `false` if the transaction is not finalized or not found.

    === "Example"

        ```bash
        curl -H "Content-Type: application/json" -X POST --data '{
          "jsonrpc": "2.0",
          "id": "1",
          "method": "moon_isTxFinalized",
          "params": ["INSERT_TRANSACTION_HASH"]
        }' {{ networks.moonbase.rpc_url }}
        ```

???+ function "moon_getEthSyncBlockRange"

    Returns the range of blocks that are fully indexed in Frontier's backend.

    === "Parameters"

        None

    === "Returns"

        Returns the range of blocks that are fully indexed in Frontier's backend. An example response below includes the Substrate block hashes of block `0` and the latest fully indexed block:

        ```[
        "0x91bc6e169807aaa54802737e1c504b2577d4fafedd5a02c10293b1cd60e39527",
        "0xb1b49bd709ca9fe0e751b8648951ffbb2173e1258b8de8228cfa0ab27003f612"
        ]```

    === "Example"

        ```bash
        curl -H "Content-Type: application/json" -X POST --data '{
          "jsonrpc": "2.0",
          "id": "1",
          "method": "moon_getEthSyncBlockRange",
          "params": []
        }' {{ networks.moonbase.rpc_url }}
        ```
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/builders/ethereum/precompiles/overview/
--- BEGIN CONTENT ---
---
title: Solidity Precompiles
description: An overview of the available Solidity precompiles on Moonbeam. Precompiles enable you to interact with Substrate features using the Ethereum API.
categories: Reference, Basics
---

# Overview of the Precompiled Contracts on Moonbeam

## Overview {: #introduction }

On Moonbeam, a precompiled contract is native Substrate code that has an Ethereum-style address and can be called using the Ethereum API, like any other smart contract. The precompiles allow you to call the Substrate runtime directly which is not normally accessible from the Ethereum side of Moonbeam.

The Substrate code responsible for implementing precompiles can be found in the [EVM pallet](/learn/platform/technology/#evm-pallet){target=\_blank}. The EVM pallet includes the [standard precompiles found on Ethereum and some additional precompiles that are not specific to Ethereum](https://github.com/polkadot-evm/frontier/tree/master/frame/evm/precompile){target=\_blank}. It also provides the ability to create and execute custom precompiles through the generic [`Precompiles` trait](https://polkadot-evm.github.io/frontier/rustdocs/pallet_evm/trait.Precompile.html){target=\_blank}. There are several custom Moonbeam-specific precompiles that have been created, all of which can be found in the [Moonbeam codebase](https://github.com/moonbeam-foundation/moonbeam/tree/master/precompiles){target=\_blank}. It is important to highlight that the precompiles from this list with the `CallableByContract` check are not callable inside the contract constructor.

The Ethereum precompiled contracts contain complex functionality that is computationally intensive, such as hashing and encryption. The custom precompiled contracts on Moonbeam provide access to Substrate-based functionality such as staking, governance, XCM-related functions, and more.

The Moonbeam-specific precompiles can be interacted with through familiar and easy-to-use Solidity interfaces using the Ethereum API, which are ultimately used to interact with the underlying Substrate interface. This flow is depicted in the following diagram:

![Precompiled Contracts Diagram](/images/builders/ethereum/precompiles/overview/overview-1.webp)

!!! note
    There can be some unintended consequences when using the precompiled contracts on Moonbeam. Please refer to the [Security Considerations](/learn/core-concepts/security/){target=\_blank} page for more information.

## Precompiled Contract Addresses {: #precompiled-contract-addresses }

The precompiled contracts are categorized by address and based on the origin network. If you were to convert the precompiled addresses to decimal format, and break them into categories by numeric value, the categories are as follows:

- **0-1023** - [Ethereum MainNet precompiles](#ethereum-mainnet-precompiles)
- **1024-2047** - precompiles that are [not in Ethereum and not Moonbeam specific](#non-moonbeam-specific-nor-ethereum-precomiles)
- **2048-4095** - [Moonbeam specific precompiles](#moonbeam-specific-precompiles)

### Ethereum MainNet Precompiles {: #ethereum-mainnet-precompiles }

=== "Moonbeam"
    |                                                          Contract                                                           |                  Address                   |
    |:---------------------------------------------------------------------------------------------------------------------------:|:------------------------------------------:|
    |      [ECRECOVER](/builders/ethereum/precompiles/utility/eth-mainnet/#verify-signatures-with-ecrecover){target=\_blank}      | 0x0000000000000000000000000000000000000001 |
    |              [SHA256](/builders/ethereum/precompiles/utility/eth-mainnet/#hashing-with-sha256){target=\_blank}              | 0x0000000000000000000000000000000000000002 |
    |          [RIPEMD160](/builders/ethereum/precompiles/utility/eth-mainnet/#hashing-with-ripemd-160){target=\_blank}           | 0x0000000000000000000000000000000000000003 |
    |            [Identity](/builders/ethereum/precompiles/utility/eth-mainnet/#the-identity-function){target=\_blank}            | 0x0000000000000000000000000000000000000004 |
    |    [Modular Exponentiation](/builders/ethereum/precompiles/utility/eth-mainnet/#modular-exponentiation){target=\_blank}     | 0x0000000000000000000000000000000000000005 |
    |                  [BN128Add](/builders/ethereum/precompiles/utility/eth-mainnet/#bn128add){target=\_blank}                   | 0x0000000000000000000000000000000000000006 |
    |                  [BN128Mul](/builders/ethereum/precompiles/utility/eth-mainnet/#bn128mul){target=\_blank}                   | 0x0000000000000000000000000000000000000007 |
    |              [BN128Pairing](/builders/ethereum/precompiles/utility/eth-mainnet/#bn128pairing){target=\_blank}               | 0x0000000000000000000000000000000000000008 |
    | [Blake2](https://polkadot-evm.github.io/frontier/rustdocs/pallet_evm_precompile_blake2/struct.Blake2F.html){target=\_blank} | 0x0000000000000000000000000000000000000009 |
    |                 [P256Verify](https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7212.md){target=\_blank}                 | 0x0000000000000000000000000000000000000100 |

=== "Moonriver"
    |                                                          Contract                                                           |                  Address                   |
    |:---------------------------------------------------------------------------------------------------------------------------:|:------------------------------------------:|
    |      [ECRECOVER](/builders/ethereum/precompiles/utility/eth-mainnet/#verify-signatures-with-ecrecover){target=\_blank}      | 0x0000000000000000000000000000000000000001 |
    |              [SHA256](/builders/ethereum/precompiles/utility/eth-mainnet/#hashing-with-sha256){target=\_blank}              | 0x0000000000000000000000000000000000000002 |
    |          [RIPEMD160](/builders/ethereum/precompiles/utility/eth-mainnet/#hashing-with-ripemd-160){target=\_blank}           | 0x0000000000000000000000000000000000000003 |
    |            [Identity](/builders/ethereum/precompiles/utility/eth-mainnet/#the-identity-function){target=\_blank}            | 0x0000000000000000000000000000000000000004 |
    |    [Modular Exponentiation](/builders/ethereum/precompiles/utility/eth-mainnet/#modular-exponentiation){target=\_blank}     | 0x0000000000000000000000000000000000000005 |
    |                  [BN128Add](/builders/ethereum/precompiles/utility/eth-mainnet/#bn128add){target=\_blank}                   | 0x0000000000000000000000000000000000000006 |
    |                  [BN128Mul](/builders/ethereum/precompiles/utility/eth-mainnet/#bn128mul){target=\_blank}                   | 0x0000000000000000000000000000000000000007 |
    |              [BN128Pairing](/builders/ethereum/precompiles/utility/eth-mainnet/#bn128pairing){target=\_blank}               | 0x0000000000000000000000000000000000000008 |
    | [Blake2](https://polkadot-evm.github.io/frontier/rustdocs/pallet_evm_precompile_blake2/struct.Blake2F.html){target=\_blank} | 0x0000000000000000000000000000000000000009 |
    |                 [P256Verify](https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7212.md){target=\_blank}                 | 0x0000000000000000000000000000000000000100 |

=== "Moonbase Alpha"
    |                                                          Contract                                                           |                  Address                   |
    |:---------------------------------------------------------------------------------------------------------------------------:|:------------------------------------------:|
    |      [ECRECOVER](/builders/ethereum/precompiles/utility/eth-mainnet/#verify-signatures-with-ecrecover){target=\_blank}      | 0x0000000000000000000000000000000000000001 |
    |              [SHA256](/builders/ethereum/precompiles/utility/eth-mainnet/#hashing-with-sha256){target=\_blank}              | 0x0000000000000000000000000000000000000002 |
    |          [RIPEMD160](/builders/ethereum/precompiles/utility/eth-mainnet/#hashing-with-ripemd-160){target=\_blank}           | 0x0000000000000000000000000000000000000003 |
    |            [Identity](/builders/ethereum/precompiles/utility/eth-mainnet/#the-identity-function){target=\_blank}            | 0x0000000000000000000000000000000000000004 |
    |    [Modular Exponentiation](/builders/ethereum/precompiles/utility/eth-mainnet/#modular-exponentiation){target=\_blank}     | 0x0000000000000000000000000000000000000005 |
    |                  [BN128Add](/builders/ethereum/precompiles/utility/eth-mainnet/#bn128add){target=\_blank}                   | 0x0000000000000000000000000000000000000006 |
    |                  [BN128Mul](/builders/ethereum/precompiles/utility/eth-mainnet/#bn128mul){target=\_blank}                   | 0x0000000000000000000000000000000000000007 |
    |              [BN128Pairing](/builders/ethereum/precompiles/utility/eth-mainnet/#bn128pairing){target=\_blank}               | 0x0000000000000000000000000000000000000008 |
    | [Blake2](https://polkadot-evm.github.io/frontier/rustdocs/pallet_evm_precompile_blake2/struct.Blake2F.html){target=\_blank} | 0x0000000000000000000000000000000000000009 |
    |                 [P256Verify](https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7212.md){target=\_blank}                 | 0x0000000000000000000000000000000000000100 |

### Non-Moonbeam Specific nor Ethereum Precompiles {: #non-moonbeam-specific-nor-ethereum-precompiles }

=== "Moonbeam"
    |                                                                      Contract                                                                      |                  Address                   |
    |:--------------------------------------------------------------------------------------------------------------------------------------------------:|:------------------------------------------:|
    |                    [SHA3FIPS256](/builders/ethereum/precompiles/utility/eth-mainnet/#hashing-with-sha3fips256){target=\_blank}                     | 0x0000000000000000000000000000000000000400 |
    |                                                                 Dispatch [Removed]                                                                 | 0x0000000000000000000000000000000000000401 |
    | [ECRecoverPublicKey](https://polkadot-evm.github.io/frontier/rustdocs/pallet_evm_precompile_simple/struct.ECRecoverPublicKey.html){target=\_blank} | 0x0000000000000000000000000000000000000402 |

=== "Moonriver"
    |                                                                      Contract                                                                      |                  Address                   |
    |:--------------------------------------------------------------------------------------------------------------------------------------------------:|:------------------------------------------:|
    |                    [SHA3FIPS256](/builders/ethereum/precompiles/utility/eth-mainnet/#hashing-with-sha3fips256){target=\_blank}                     | 0x0000000000000000000000000000000000000400 |
    |                                                                 Dispatch [Removed]                                                                 | 0x0000000000000000000000000000000000000401 |
    | [ECRecoverPublicKey](https://polkadot-evm.github.io/frontier/rustdocs/pallet_evm_precompile_simple/struct.ECRecoverPublicKey.html){target=\_blank} | 0x0000000000000000000000000000000000000402 |

=== "Moonbase Alpha"
    |                                                                           Contract                                                                            |                  Address                   |
    |:-------------------------------------------------------------------------------------------------------------------------------------------------------------:|:------------------------------------------:|
    |                          [SHA3FIPS256](/builders/ethereum/precompiles/utility/eth-mainnet/#hashing-with-sha3fips256){target=\_blank}                          | 0x0000000000000000000000000000000000000400 |
    |                                                                      Dispatch [Removed]                                                                       | 0x0000000000000000000000000000000000000401 |
    |      [ECRecoverPublicKey](https://polkadot-evm.github.io/frontier/rustdocs/pallet_evm_precompile_simple/struct.ECRecoverPublicKey.html){target=\_blank}       | 0x0000000000000000000000000000000000000402 |

### Moonbeam Specific Precompiles {: #moonbeam-specific-precompiles }

=== "Moonbeam"
    |                                                                                        Contract                                                                                        |                               Address                               |
    |:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|:-------------------------------------------------------------------:|
    |                  [Parachain Staking](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/parachain-staking/StakingInterface.sol){target=\_blank}                  |              {{networks.moonbeam.precompiles.staking}}              |
    |                 [Crowdloan Rewards](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/crowdloan-rewards/CrowdloanInterface.sol){target=\_blank}                 |             {{networks.moonbeam.precompiles.crowdloan}}             |
    |                         [ERC-20 Interface](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/balances-erc20/ERC20.sol){target=\_blank}                          |               {{networks.moonbeam.precompiles.erc20}}               |
    |                                                                      Democracy [Removed]                                                                      |             {{networks.moonbeam.precompiles.democracy}}             |
    |                                [X-Tokens](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xtokens/Xtokens.sol){target=\_blank}                                |              {{networks.moonbeam.precompiles.xtokens}}              |
    |                        [Relay Encoder](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/relay-encoder/RelayEncoder.sol){target=\_blank}                        |           {{networks.moonbeam.precompiles.relay_encoder}}           |
    |                [XCM Transactor V1](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-transactor/src/v1/XcmTransactorV1.sol){target=\_blank}                 |         {{networks.moonbeam.precompiles.xcm_transactor_v1}}         |
    |                  [Author Mapping](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/author-mapping/AuthorMappingInterface.sol){target=\_blank}                  |          {{networks.moonbeam.precompiles.author_mapping}}           |
    |                                   [Batch](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/batch/Batch.sol){target=\_blank}                                    |               {{networks.moonbeam.precompiles.batch}}               |
    |                            [Randomness](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/randomness/Randomness.sol){target=\_blank}                            |            {{networks.moonbeam.precompiles.randomness}}             |
    |                           [Call Permit](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/call-permit/CallPermit.sol){target=\_blank}                           |            {{networks.moonbeam.precompiles.call_permit}}            |
    |                                   [Proxy](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/proxy/Proxy.sol){target=\_blank}                                    |               {{networks.moonbeam.precompiles.proxy}}               |
    |                            [XCM Utilities](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-utils/XcmUtils.sol){target=\_blank}                            |             {{networks.moonbeam.precompiles.xcm_utils}}             |
    |                [XCM Transactor V2](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-transactor/src/v2/XcmTransactorV2.sol){target=\_blank}                 |         {{networks.moonbeam.precompiles.xcm_transactor_v2}}         |
    |                   [Council Collective [Removed]](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}                   |        {{networks.moonbeam.precompiles.collective_council}}         |
    |             [Technical Committee Collective [Removed]](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}             |     {{networks.moonbeam.precompiles.collective_tech_committee}}     |
    |                   [Treasury Council Collective](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}                    |        {{networks.moonbeam.precompiles.collective_treasury}}        |
    |                             [Referenda](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/referenda/Referenda.sol){target=\_blank}                              |             {{networks.moonbeam.precompiles.referenda}}             |
    |                  [Conviction Voting](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/conviction-voting/ConvictionVoting.sol){target=\_blank}                  |         {{networks.moonbeam.precompiles.conviction_voting}}         |
    |                               [Preimage](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/preimage/Preimage.sol){target=\_blank}                               |             {{networks.moonbeam.precompiles.preimage}}              |
    |                      [OpenGov Tech Committee](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}                      | {{networks.moonbeam.precompiles.collective_opengov_tech_committee}} |
    |               [Precompile Registry](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/precompile-registry/PrecompileRegistry.sol){target=\_blank}               |             {{networks.moonbeam.precompiles.registry}}              |
    |                                      [GMP](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/gmp/Gmp.sol){target=\_blank}                                       |                {{networks.moonbeam.precompiles.gmp}}                |
    |                [XCM Transactor V3](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-transactor/src/v3/XcmTransactorV3.sol){target=\_blank}                 |         {{networks.moonbeam.precompiles.xcm_transactor_v3}}         |
    |                               [XCM interface](https://github.com/Moonsong-Labs/moonkit/blob/main/precompiles/pallet-xcm/XcmInterface.sol){target=\_blank}                               |             {{networks.moonbeam.precompiles.xcm_interface}}              |
    |                               [Identity](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/identity/Identity.sol){target=\_blank}                               |             {{networks.moonbeam.precompiles.identity}}              |
    

=== "Moonriver"
    |                                                                           Contract                                                                            |                               Address                                |
    |:-------------------------------------------------------------------------------------------------------------------------------------------------------------:|:--------------------------------------------------------------------:|
    |      [Parachain Staking](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/parachain-staking/StakingInterface.sol){target=\_blank}      |              {{networks.moonriver.precompiles.staking}}              |
    |     [Crowdloan Rewards](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/crowdloan-rewards/CrowdloanInterface.sol){target=\_blank}     |             {{networks.moonriver.precompiles.crowdloan}}             |
    |             [ERC-20 Interface](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/balances-erc20/ERC20.sol){target=\_blank}              |               {{networks.moonriver.precompiles.erc20}}               |
    |                                                                     Democracy [Disabled]                                                                      |             {{networks.moonriver.precompiles.democracy}}             |
    |                    [X-Tokens](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xtokens/Xtokens.sol){target=\_blank}                    |              {{networks.moonriver.precompiles.xtokens}}              |
    |            [Relay Encoder](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/relay-encoder/RelayEncoder.sol){target=\_blank}            |           {{networks.moonriver.precompiles.relay_encoder}}           |
    |    [XCM Transactor V1](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-transactor/src/v1/XcmTransactorV1.sol){target=\_blank}     |         {{networks.moonriver.precompiles.xcm_transactor_v1}}         |
    |      [Author Mapping](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/author-mapping/AuthorMappingInterface.sol){target=\_blank}      |          {{networks.moonriver.precompiles.author_mapping}}           |
    |                       [Batch](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/batch/Batch.sol){target=\_blank}                        |               {{networks.moonriver.precompiles.batch}}               |
    |                [Randomness](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/randomness/Randomness.sol){target=\_blank}                |            {{networks.moonriver.precompiles.randomness}}             |
    |               [Call Permit](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/call-permit/CallPermit.sol){target=\_blank}               |            {{networks.moonriver.precompiles.call_permit}}            |
    |                       [Proxy](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/proxy/Proxy.sol){target=\_blank}                        |               {{networks.moonriver.precompiles.proxy}}               |
    |                [XCM Utilities](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-utils/XcmUtils.sol){target=\_blank}                |             {{networks.moonriver.precompiles.xcm_utils}}             |
    |    [XCM Transactor V2](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-transactor/src/v2/XcmTransactorV2.sol){target=\_blank}     |         {{networks.moonriver.precompiles.xcm_transactor_v2}}         |
    |       [Council Collective [Removed]](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}       |        {{networks.moonriver.precompiles.collective_council}}         |
    | [Technical Committee Collective [Removed]](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank} |     {{networks.moonriver.precompiles.collective_tech_committee}}     |
    |       [Treasury Council Collective](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}        |        {{networks.moonriver.precompiles.collective_treasury}}        |
    |                 [Referenda](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/referenda/Referenda.sol){target=\_blank}                  |             {{networks.moonriver.precompiles.referenda}}             |
    |      [Conviction Voting](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/conviction-voting/ConvictionVoting.sol){target=\_blank}      |         {{networks.moonriver.precompiles.conviction_voting}}         |
    |                   [Preimage](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/preimage/Preimage.sol){target=\_blank}                   |             {{networks.moonriver.precompiles.preimage}}              |
    |          [OpenGov Tech Committee](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}          | {{networks.moonriver.precompiles.collective_opengov_tech_committee}} |
    |   [Precompile Registry](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/precompile-registry/PrecompileRegistry.sol){target=\_blank}   |             {{networks.moonriver.precompiles.registry}}              |
    |                          [GMP](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/gmp/Gmp.sol){target=\_blank}                           |                {{networks.moonriver.precompiles.gmp}}                |
    |    [XCM Transactor V3](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-transactor/src/v3/XcmTransactorV3.sol){target=\_blank}     |         {{networks.moonriver.precompiles.xcm_transactor_v3}}         |
    |                               [XCM interface](https://github.com/Moonsong-Labs/moonkit/blob/main/precompiles/pallet-xcm/XcmInterface.sol){target=\_blank}                               |             {{networks.moonriver.precompiles.xcm_interface}}              |
    |                   [Identity](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/identity/Identity.sol){target=\_blank}                   |             {{networks.moonriver.precompiles.identity}}              |

=== "Moonbase Alpha"
    |                                                                            Contract                                                                            |                               Address                               |
    |:--------------------------------------------------------------------------------------------------------------------------------------------------------------:|:-------------------------------------------------------------------:|
    |      [Parachain Staking](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/parachain-staking/StakingInterface.sol){target=\_blank}      |              {{networks.moonbase.precompiles.staking}}              |
    |     [Crowdloan Rewards](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/crowdloan-rewards/CrowdloanInterface.sol){target=\_blank}     |             {{networks.moonbase.precompiles.crowdloan}}             |
    |             [ERC-20 Interface](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/balances-erc20/ERC20.sol){target=\_blank}              |               {{networks.moonbase.precompiles.erc20}}               |
    |                                                                      Democracy [Removed]                                                                       |             {{networks.moonbase.precompiles.democracy}}             |
    |                    [X-Tokens](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xtokens/Xtokens.sol){target=\_blank}                    |              {{networks.moonbase.precompiles.xtokens}}              |
    |            [Relay Encoder](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/relay-encoder/RelayEncoder.sol){target=\_blank}            |           {{networks.moonbase.precompiles.relay_encoder}}           |
    |    [XCM Transactor V1](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-transactor/src/v1/XcmTransactorV1.sol){target=\_blank}     |         {{networks.moonbase.precompiles.xcm_transactor_v1}}         |
    |      [Author Mapping](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/author-mapping/AuthorMappingInterface.sol){target=\_blank}      |          {{networks.moonbase.precompiles.author_mapping}}           |
    |                       [Batch](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/batch/Batch.sol){target=\_blank}                        |               {{networks.moonbase.precompiles.batch}}               |
    |                [Randomness](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/randomness/Randomness.sol){target=\_blank}                |            {{networks.moonbase.precompiles.randomness}}             |
    |               [Call Permit](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/call-permit/CallPermit.sol){target=\_blank}               |            {{networks.moonbase.precompiles.call_permit}}            |
    |                       [Proxy](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/proxy/Proxy.sol){target=\_blank}                        |               {{networks.moonbase.precompiles.proxy}}               |
    |                [XCM Utilities](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-utils/XcmUtils.sol){target=\_blank}                |             {{networks.moonbase.precompiles.xcm_utils}}             |
    |    [XCM Transactor V2](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-transactor/src/v2/XcmTransactorV2.sol){target=\_blank}     |         {{networks.moonbase.precompiles.xcm_transactor_v2}}         |
    |       [Council Collective [Removed]](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}       |        {{networks.moonbase.precompiles.collective_council}}         |
    | [Technical Committee Collective [Removed]](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank} |     {{networks.moonbase.precompiles.collective_tech_committee}}     |
    |       [Treasury Council Collective](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}        |        {{networks.moonbase.precompiles.collective_treasury}}        |
    |                 [Referenda](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/referenda/Referenda.sol){target=\_blank}                  |             {{networks.moonbase.precompiles.referenda}}             |
    |      [Conviction Voting](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/conviction-voting/ConvictionVoting.sol){target=\_blank}      |         {{networks.moonbase.precompiles.conviction_voting}}         |
    |                   [Preimage](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/preimage/Preimage.sol){target=\_blank}                   |             {{networks.moonbase.precompiles.preimage}}              |
    |          [OpenGov Tech Committee](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/collective/Collective.sol){target=\_blank}          | {{networks.moonbase.precompiles.collective_opengov_tech_committee}} |
    |   [Precompile Registry](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/precompile-registry/PrecompileRegistry.sol){target=\_blank}   |             {{networks.moonbase.precompiles.registry}}              |
    |                          [GMP](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/gmp/Gmp.sol){target=\_blank}                           |                {{networks.moonbase.precompiles.gmp}}                |
    |    [XCM Transactor V3](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/xcm-transactor/src/v3/XcmTransactorV3.sol){target=\_blank}     |         {{networks.moonbase.precompiles.xcm_transactor_v3}}         |
    |                               [XCM Interface](https://github.com/Moonsong-Labs/moonkit/blob/main/precompiles/pallet-xcm/XcmInterface.sol){target=\_blank}                               |             {{networks.moonbeam.precompiles.xcm_interface}}              |
    |                   [Identity](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/identity/Identity.sol){target=\_blank}                   |             {{networks.moonbase.precompiles.identity}}              |
--- END CONTENT ---

Doc-Content: https://docs.moonbeam.network/builders/get-started/endpoints/
--- BEGIN CONTENT ---
---
title: Moonbeam API Providers and Endpoints
description: Use one of the supported API providers to connect to a public endpoint or create custom JSON-RPC and WSS endpoints for Moonbeam-based networks.
categories: JSON-RPC APIs, Reference
---

# Network Endpoints

## Public Endpoints {: #public-endpoints }

Moonbeam-based networks have two endpoints available for users to connect to: one for HTTPS and one for WSS.

The endpoints in this section are for development purposes only and are not meant to be used in production applications.

If you are looking for an API provider suitable for production use, you can check out the [Endpoint Providers](#endpoint-providers) section of this guide.

### Moonbeam {: #moonbeam }

=== "HTTPS"
    |  Provider   |                              RPC URL                               |   Limits    |
    |:-----------:|:------------------------------------------------------------------:|:-----------:|
    |   Dwellir   |         <pre>```https://moonbeam-rpc.dwellir.com```</pre>          | 20 req/sec  |
    | OnFinality  |     <pre>```https://moonbeam.api.onfinality.io/public```</pre>     | 40 req/sec  |
    | UnitedBloc  |          <pre>```https://moonbeam.unitedbloc.com```</pre>          | 32 req/sec  |
    | RadiumBlock | <pre>```https://moonbeam.public.curie.radiumblock.co/http```</pre> | 200 req/sec |
    |    1RPC     |               <pre>```https://1rpc.io/glmr```</pre>                | 10k req/day |
    |    Grove    |         <pre>```https://moonbeam.rpc.grove.city/v1/01fdb492```</pre>         | 5k req/day  |



=== "WSS"
    |  Provider   |                            RPC URL                             |   Limits    |
    |:-----------:|:--------------------------------------------------------------:|:-----------:|
    |   Dwellir   |        <pre>```wss://moonbeam-rpc.dwellir.com```</pre>         | 20 req/sec  |
    | OnFinality  |  <pre>```wss://moonbeam.api.onfinality.io/public-ws```</pre>   | 40 req/sec  |
    | UnitedBloc  |         <pre>```wss://moonbeam.unitedbloc.com```</pre>         | 32 req/sec  |
    | RadiumBlock | <pre>```wss://moonbeam.public.curie.radiumblock.co/ws```</pre> | 200 req/sec |
    |    1RPC     |              <pre>```wss://1rpc.io/glmr```</pre>               | 10k req/day |

### Moonriver {: #moonriver }

=== "HTTPS"
      |  Provider   |                               RPC URL                               |   Limits    |
      |:-----------:|:-------------------------------------------------------------------:|:-----------:|
      |   Dwellir   |         <pre>```https://moonriver-rpc.dwellir.com```</pre>          | 20 req/sec  |
      | OnFinality  |     <pre>```https://moonriver.api.onfinality.io/public```</pre>     | 40 req/sec  |
      | UnitedBloc  |          <pre>```https://moonriver.unitedbloc.com```</pre>          | 32 req/sec  |
      | RadiumBlock | <pre>```https://moonriver.public.curie.radiumblock.co/http```</pre> | 200 req/sec |
      |    Grove    |        <pre>```https://moonriver.rpc.grove.city/v1/01fdb492```</pre>        | 5k req/day  |

=== "WSS"
    |  Provider   |                             RPC URL                             |   Limits    |
    |:-----------:|:---------------------------------------------------------------:|:-----------:|
    |   Dwellir   |        <pre>```wss://moonriver-rpc.dwellir.com```</pre>         | 20 req/sec  |
    | OnFinality  |  <pre>```wss://moonriver.api.onfinality.io/public-ws```</pre>   | 40 req/sec  |
    | UnitedBloc  |         <pre>```wss://moonriver.unitedbloc.com```</pre>         | 32 req/sec  |
    | RadiumBlock | <pre>```wss://moonriver.public.curie.radiumblock.co/ws```</pre> | 200 req/sec |

### Moonbase Alpha {: #moonbase-alpha }

=== "HTTPS"
    |      Provider       |                              RPC URL                               |   Limits    |
    |:-------------------:|:------------------------------------------------------------------:|:-----------:|
    |       Dwellir       |         <pre>```https://moonbase-rpc.dwellir.com```</pre>          | 20 req/sec  |
    |     OnFinality      |  <pre>```https://moonbeam-alpha.api.onfinality.io/public```</pre>  | 40 req/sec  |
    | Moonbeam Foundation |     <pre>```https://rpc.api.moonbase.moonbeam.network```</pre>     | 25 req/sec  |
    |     UnitedBloc      |          <pre>```https://moonbase.unitedbloc.com```</pre>          | 32 req/sec  |
    |     RadiumBlock     | <pre>```https://moonbase.public.curie.radiumblock.co/http```</pre> | 200 req/sec |

=== "WSS"
    |      Provider       |                              RPC URL                              |   Limits    |
    |:-------------------:|:-----------------------------------------------------------------:|:-----------:|
    |       Dwellir       |          <pre>```wss://moonbase-rpc.dwellir.com```</pre>          | 20 req/sec  |
    |     OnFinality      | <pre>```wss://moonbeam-alpha.api.onfinality.io/public-ws```</pre> | 40 req/sec  |
    | Moonbeam Foundation |     <pre>```wss://wss.api.moonbase.moonbeam.network```</pre>      | 25 req/sec  |
    |     UnitedBloc      |          <pre>```wss://moonbase.unitedbloc.com```</pre>           | 32 req/sec  |
    |     RadiumBlock     |  <pre>```wss://moonbase.public.curie.radiumblock.co/ws```</pre>   | 200 req/sec |


#### Relay Chain {: #relay-chain }

To connect to the Moonbase Alpha relay chain, you can use the following WS Endpoint:

| Provider |                          RPC URL                           |
|:--------:|:----------------------------------------------------------:|
| OpsLayer | <pre>```wss://relay.api.moonbase.moonbeam.network```</pre> |

## RPC Endpoint Providers {: #endpoint-providers }

You can create your own endpoint suitable for development or production use using any of the following API providers:

- [1RPC](#1rpc)
- [Blast](#blast)
- [Chainstack](#chainstack)
- [dRPC](#drpc)
- [Dwellir](#dwellir)
- [GetBlock](#getblock)
- [Grove](#grove)
- [OnFinality](#onfinality)
- [UnitedBloc](#unitedbloc)

### 1RPC {: #1rpc}

[1RPC](https://www.1rpc.io){target=_blank} is a free and private RPC relay that protects user privacy by preventing data collection, user tracking, phishing attempts from other parties. It tunnels user requests via distributed relays to other RPC providers whilst preventing the tracking of user metadata such as IP address, device information and wallet linkability with secure enclave technology.

1RPC is created to be an open initiative from the blockchain infrastructure community. They are motivated by a common good mission to help build a better Web3 and encourage anyone who values user privacy to join this open collaboration.

Head over to [1RPC](https://www.1rpc.io){target=_blank} official site to set it up!

![1RPC](/images/builders/get-started/endpoints/endpoints-1.webp)

### Blast {: #blast}

As a user of [Blast](https://blastapi.io){target=_blank} powered by Bware Labs, you will be able to obtain your own free endpoint allowing you to interact with Moonbeam, just by performing a few simple clicks within a user-friendly interface.

To get started, you'll need to head to [Blast](https://blastapi.io){target=_blank}, and launch the app, and connect your wallet. Once your wallet is connected you will be able to create a project and then generate your own custom endpoint. To generate an endpoint:

1. Create a new project
2. Click on **Available Endpoints**
3. Select Moonbeam network for your endpoint
4. Confirm the selected network and Press **Activate**
5. You'll now see Moonbeam under **Active Endpoints**. Click on the network and you'll see your custom RPC and WSS endpoints on the next page

![Bware Labs](/images/builders/get-started/endpoints/endpoints-2.webp)

### Chainstack {: #chainstack }

[Chainstack](https://chainstack.com/){target=_blank}, the Web3 infrastructure provider, offers free and paid endpoints for Moonbeam. The free Developer plan starts with 3 million monthly requests and 25 requests per second (RPS). You can easily scale with the paid plans.

To start with a free Developer plan endpoint, sign up using an email or any social account, like GitHub or X (Twitter).

1. Visit [Chainstack](https://console.chainstack.com/){target=_blank}
2. Sign up
3. Deploy a Moonbeam node

![Chainstack](/images/builders/get-started/endpoints/endpoints-3.webp)

### dRPC.org {: #drpc }

dRPC.org offers public and paid [Moonbeam RPC](https://drpc.org/chainlist/moonbeam){target=_blank} endpoints, providing an efficient, low-latency connection to blockchain nodes. The paid tiers include higher request limits, lower latency, and advanced analytics for optimized performance.

How to use dRPC:

1. Sign up or log in at [dRPC.org](https://drpc.org/){target=_blank}
2. In the dashboard, create an API key
3. Click the key and select the desired endpoint

For 24/7 support, join dRPC's [Discord](https://drpc.org/discord){target=_blank}.

### Dwellir {: #dwellir }

[Dwellir](https://www.dwellir.com){target=_blank} is a blockchain operation service that ensures global scalability, low latency, and a 99.99% uptime guarantee, providing fast and reliable node operations wherever your business stands. The public endpoint service is geographically distributed bare metal servers globally. As the service is public, there are no sign-up or API keys to manage.

To get started with a developer endpoint or dedicated node, you'll need to contact us:

1. Visit [Dwellir](https://www.dwellir.com/contact){target=_blank}
2. Submit your **email** and your node request

![Dwellir](/images/builders/get-started/endpoints/endpoints-4.webp)

### GetBlock {: #getblock }

[GetBlock](https://getblock.io){target=_blank} is a service that provides instant API access to Moonbeam and Moonriver and is available through shared and dedicated nodes. [Dedicated nodes](https://docs.getblock.io/getting-started/plans-and-limits/choosing-your-plan#dedicated-nodes){target=_blank} provide access to a private server with fast speeds and without rate limits. [Shared nodes](https://docs.getblock.io/getting-started/plans-and-limits/choosing-your-plan#shared-nodes){target=_blank} provide a free API/add-on based endpoint for you to get started quickly.

To get started with GetBlock, you can go to the [GetBlock registration page](https://account.getblock.io/sign-up){target=_blank} and sign up for a new account. Then, from your account **Dashboard**, you can view and manage your existing endpoints for multiple protocols, and also create new ones.

Creating a new API/add-on based endpoint is simple, all you have to do is:

1. Fill the information for the desired protocol from the list of available blockchains
2. Choose the network you want your endpoint to point to (**Mainnet**, **Testnet**, etc)
3. Select **JSON-RPC** from the **API/Add-on** dropdown
4. Click the **Get** button at the far right and you're all set to go! 

![GetBlock](/images/builders/get-started/endpoints/endpoints-5.webp)

### Grove {: #grove }

[Grove](https://grove.city){target=_blank} is a decentralized RPC network that provides reliable Web3 infrastructure with enterprise-grade performance and security. Grove offers both free and paid tiers, with the free tier providing generous limits for development use, while paid plans offer higher throughput, dedicated support, and advanced features for production applications. Grove's decentralized approach ensures high availability and censorship resistance by distributing requests across multiple node operators. The network supports both JSON-RPC and WebSocket connections for real-time applications. To get started with Grove:

1. Visit the [Grove Portal](https://portal.grove.city/){target=_blank} and sign up for an account
2. From your dashboard, create a new application
3. Copy your Moonbeam or Moonriver endpoints
4. Start making requests to your custom Grove endpoint

Grove provides detailed analytics, request monitoring, and flexible rate limiting to help you optimize your application's performance.

![Grove](/images/builders/get-started/endpoints/endpoints-6.webp)

### OnFinality {: #onfinality }

[OnFinality](https://onfinality.io){target=_blank} provides a free API key based endpoint for customers in place of a public endpoint. Additionally, OnFinality offers paid tiers of service that offer increased rate limits and higher performance than those offered by the free tier. You also receive more in depth analytics of the usage of your application.

To create a custom OnFinality endpoint, go to [OnFinality](https://onfinality.io){target=_blank} and sign up, or if you already have signed up you can go ahead and log in. From the OnFinality **Dashboard**, you can:

1. Click on **API Service**
2. Select the network from the dropdown
3. Your custom API endpoint will be generated automatically

![OnFinality](/images/builders/get-started/endpoints/endpoints-7.webp)

### UnitedBloc {: #unitedbloc }

[UnitedBloc](https://medium.com/unitedbloc/unitedbloc-rpc-c84972f69457){target=_blank} is a collective of community collators from both Moonbeam and Moonriver. To provide value for the community, they offer public RPC services for the Moonbeam, Moonriver, and Moonbase Alpha networks.

The public endpoint service is served by eight geographically distributed bare metal servers globally balanced via GeoDNS and regionally load balanced with NGINX. As the service is public, there are no sign-up or API keys to manage.

The collators involved in this initiative are:

 - Blockshard (CH)
 - BloClick (ES)
 - BrightlyStake (IN)
 - CertHum (US)
 - GPValidator (PT)
 - Hetavalidation (AU)
 - Legend (AE)
 - PathrockNetwork (DE)
 - Polkadotters (CZ)
 - SIK | crifferent.de (DE)
 - StakeBaby (GR)
 - StakeSquid (GE)
 - TrueStaking (US)

They also provide a [public Grafana dashboard](https://monitoring.unitedbloc.com:3030/public-dashboards/7444d2ab76ee45eda181618b0f0ecb98?orgId=1){target=_blank} with some cool metrics.

Check the [public endpoints section](#public-endpoints) to get the relevant URL. You can contact them via their [Telegram channel](https://t.me/+tRvy3z5-Kp1mMGMx){target=_blank}, or read more about their initiative on their [blogpost page](https://medium.com/unitedbloc/unitedbloc-rpc-c84972f69457){target=_blank}.

## Lazy Loading with RPC Endpoint Providers {: #lazy-loading-with-RPC-Endpoint-Providers }

Lazy loading lets a Moonbeam node operate while downloading network state in the background, eliminating the need to wait for full synchronization before use. To spin up a Moonbeam node with lazy loading, you'll need to either [download the Moonbeam release binary](/node-operators/networks/run-a-node/systemd/#the-release-binary){target=_blank} or [compile the binary](/node-operators/networks/run-a-node/compile-binary/#compile-the-binary){target=_blank}. You can activate lazy loading with the following flag:

`--lazy-loading-remote-rpc 'INSERT-RPC-URL'`

Lazy loading is highly resource-intensive, requiring many RPC requests to function. To avoid being throttled, it's recommended that you use a [dedicated endpoint](#endpoint-providers) (i.e., an endpoint with an API key) rather than a public endpoint. You will likely be rate-limited if you use lazy loading with a public endpoint. Upon spooling up a node with this feature, you'll see output like the following:

<div id="termynal" data-termynal>
  <span data-ty>[Lazy loading 🌗]
    <br>You are now running the Moonbeam client in lazy loading mode, where data is retrieved
    <br>from a live RPC node on demand.
    <br>Using remote state from: https://moonbeam.unitedbloc.com
    <br>Forking from block: 8482853
    <br>To ensure the client works properly, please note the following:
    <br>    1. *Avoid Throttling*: Ensure that the backing RPC node is not limiting the number of
    <br>    requests, as this can prevent the lazy loading client from functioning correctly;
    <br>    2. *Be Patient*: As the client may take approximately 20 times longer than normal to
    <br>    retrieve and process the necessary data for the requested operation.
    <br>The service will start in 10 seconds...</span>
</div>

### Overriding State with Lazy Loading

By default, you won't see detailed logging in the terminal. To override this setting and show lazy loading logs, you can add the following flag to your command to start the Moonbeam node: `-l debug`. You can further customize your use of the lazy loading functionality with the following optional parameters:

- **`--lazy-loading-block`** - specifies a block hash from which to start loading data. If not provided, the latest block will be used
- **`--lazy-loading-delay-between-requests`** - the delay (in milliseconds) between RPC requests when using lazy loading. This parameter controls the amount of time to wait between consecutive RPC requests. This can help manage request rate and avoid overwhelming the server. Default value is `100` milliseconds
- **`--lazy-loading-max-retries-per-request`** - the maximum number of retries for an RPC request when using lazy loading. Default value is `10` retries
- **`--lazy-loading-runtime-override`** - path to a WASM file to override the runtime when forking. If not provided, it will fetch the runtime from the block being forked
- **`--lazy-loading-state-overrides`** - path to a JSON file containing state overrides to be applied when forking

#### Simple Storage Item Override

The state overrides file should define the respective pallet, storage item, and value that you seek to override as follows:

```json
[
 {
     "pallet": "System",
     "storage": "SelectedCandidates",
     "value": "0x04f24ff3a9cf04c71dbc94d0b566f7a27b94566cac"
 }
]
```

#### Override an Account's Free Balance

To override the balance of a particular account, you can override the account storage item of the system pallet for the respective account as follows:

```json
[
  {
    "pallet": "System",
    "storage": "Account",
    "key": "TARGET_ADDRESS",
    "value": "0x460c000002000000010000000600000069e10de76676d0800000000000000000040a556b0e032de12000000000000000004083a09e15c74c1b0100000000000000000000000000000000000000000000080"
  }
]
```

??? note "Details about overriding account balances"

    Overriding an account balance, as shown above, can be a complex process. However, this guide will break it down into steps that are easy to follow. Before making any changes, you should obtain the existing value corresponding to the key (i.e., the account in this case). You can go to [**Chain State** on Polkadot.js Apps](https://polkadot.js.org/apps/?rpc=wss://wss.api.moonbeam.network#/chainstate){target=_blank} and query the System pallet by providing the account you'd like to query. Upon submitting the query, you'll get back a readable account structure like so:

    ```text
    {
      nonce: 3,142
      consumers: 2
      providers: 1
      sufficients: 6
      data: {
        free: 1,278,606,392,142,175,328,676
        reserved: 348,052,500,000,000,000,000
        frozen: 20,413,910,106,633,175,872
        flags: 170,141,183,460,469,231,731,687,303,715,884,105,728
      }
    }
    ```

    While this is useful as a reference, the information you're looking for is the encoded storage key, which is accessible even without submitting the chain state query. In this instance, the encoded storage key corresponding to the system pallet and the selected account `0x3B939FeaD1557C741Ff06492FD0127bd287A421e` is:

    ```text
    0x26aa394eea5630e07c48ae0c9558cef7b99d880ec681799c0cf30e8886371da9b882fedb4f75b055c709ec5b66b5d9933b939fead1557c741ff06492fd0127bd287a421e
    ```

    Note that this encoded storage key will change alongside any input changes, such as a different account being queried. Then, head over the **Raw Storage** tab on [Polkadot.js Apps](https://polkadot.js.org/apps/#/chainstate/raw){target=_blank}. Input the above storage key and submit the query. The response is the SCALE encoded account struct, a part of which contains the free balance information to be modified as part of this example: 

    ```text
    0x460c0000020000000100000006000000a4d92a6a4e6b3a5045000000000000000040a556b0e032de12000000000000004083a09e15c74c1b010000000000000000000000000000000000000000000080
    ```

    There is quite a bit of data encoded in the value field because it is a complex struct comprised of multiple values. The struct is comprised of:

    ```text
    struct AccountInfo {
        nonce: u32,             // Transaction count
        consumers: u32,         // Number of consumers 
        providers: u32,         // Number of providers
        sufficients: u32,       // Number of sufficients
        data: AccountData {     // The balance info
            free: u128,         // Free balance
            reserved: u128,     // Reserved balance
            frozen: u128,       // Frozen balance
            flags: u128         // Account flags
        }
    }
    ```

    You can associate each part of the SCALE encoded struct with the corresponding piece of Alice's account information that it represents:

    ```text
    0x460c0000        // nonce (u32): 3,142 
    02000000          // consumers (u32): 2
    01000000          // providers (u32): 1  
    06000000          // sufficients (u32): 6

    a4d92a6a4e6b3a5045000000000000000  
    // free (u128): 1,278,606,392,142,175,328,676

    40a556b0e032de1200000000000000000  
    // reserved (u128): 348,052,500,000,000,000,000  

    4083a09e15c74c1b01000000000000000  
    // frozen (u128): 20,413,910,106,633,175,872

    00000000000000000000000000000080   
    // flags (u128): 170,141,183,460,469,231,731,687,303,715,884,105,728
    ```

    Remember that the values are little endian encoded. To convert the hexadecimal little endian encoded values to decimal, you can use [Substrate Utilities converter](https://www.shawntabrizi.com/substrate-js-utilities/){target=_blank}, using the **Balance to Hex (Little Endian)** converter.

    In this example, the existing free balance of `1,278,606,392,142,175,328,676` Wei or approximately `1278.60` DEV is `a4d92a6a4e6b3a5045`. The following example will change the value to `500,000` DEV, which is `500,000,000,000,000,000,000,000` Wei or `0x000080d07666e70de169` encoded as a hexadecimal little endian value. When properly padded to fit into the SCALE encoded storage value, it becomes `69e10de76676d08000000000000000000`, such that the table now looks like:

    ```text
    0x460c0000        // nonce (u32): 3,142 
    02000000          // consumers (u32): 2
    01000000          // providers (u32): 1  
    06000000          // sufficients (u32): 6

    69e10de76676d08000000000000000000
    // free (u128): 500,000,000,000,000,000,000,000

    40a556b0e032de1200000000000000000  
    // reserved (u128): 348,052,500,000,000,000,000  

    4083a09e15c74c1b01000000000000000  
    // frozen (u128): 20,413,910,106,633,175,872

    00000000000000000000000000000080   
    // flags (u128): 170,141,183,460,469,231,731,687,303,715,884,105,728
    ```

    Therefore, the SCALE encoded override value is as follows:

    ```text
    0x460c000002000000010000000600000069e10de76676d0800000000000000000040a556b0e032de12000000000000000004083a09e15c74c1b0100000000000000000000000000000000000000000000080
    ```

    You can now specify the SCALE encoded override value in your `state-overrides.json` file as follows:

    ```json
    [
      {
        "pallet": "System",
        "storage": "Account",
        "key": "0x3b939fead1557c741ff06492fd0127bd287a421e",
        "value": "0x460c000002000000010000000600000069e10de76676d0800000000000000000040a556b0e032de12000000000000000004083a09e15c74c1b0100000000000000000000000000000000000000000000080"
      }
    ]
    ```

    To run lazy loading with the balance state override, you can use the following command: 

    ```bash
    --lazy-loading-remote-rpc 'INSERT_RPC_URL' --lazy-loading-state-overrides ./state-overrides.json
    ```

#### Override an ERC-20 Token Balance

To override an ERC-20 token balance, identify the storage slot in the EVM’s AccountStorages where the `balanceOf` data for the given token contract and account is stored. This storage slot is determined by the token contract’s H160 address and the corresponding H256 storage key. Once you have this slot, specify the new balance value in the `state-overrides.json` file to implement the override.

In the example below, we override the token balance of the [Wormhole USDC Contract (`0x931715FEE2d06333043d11F658C8CE934aC61D0c`)](https://moonscan.io/address/0x931715FEE2d06333043d11F658C8CE934aC61D0c){target=_blank} for the account `0x3b939fead1557c741ff06492fd0127bd287a421e` to $5,000 USDC. Since Wormhole USDC uses 6 decimal places, $5,000 corresponds to `5000000000` in integer form, which is `0x12a05f200` in hexadecimal.

```json
[
    {
        "pallet": "EVM",
        "storage": "AccountStorages",
        "key": [
            "0x931715FEE2d06333043d11F658C8CE934aC61D0c",
            "0x8c9902c0f94ae586c91ba539eb52087d3dd1578da91158308d79ff24a8d4f342"
        ],
        "value": "0x000000000000000000000000000000000000000000000000000000012a05f200"
    }
]
```

You can calculate the exact storage slot to override for your own account with the following script:

```js
import { ethers } from 'ethers';

function getBalanceSlot(accountAddress) {
  // Convert address to bytes32 and normalize
  const addr = ethers.zeroPadValue(accountAddress, 32);

  // CAUTION! The storage slot used here is 5, which
  // is specific to Wormhole contracts
  // The storage slot index for other tokens may vary
  const packedData = ethers.concat([
    addr,
    ethers.zeroPadValue(ethers.toBeHex(5), 32),
  ]);

  // Calculate keccak256
  return ethers.keccak256(packedData);
}

// Example usage
const address = 'INSERT_ADDRESS';
console.log(getBalanceSlot(address));
```

You can apply the same process for other ERC-20 token contracts. The following sections demonstrate overrides for the `0x3B939FeaD1557C741Ff06492FD0127bd287A421e` account with various ERC-20 tokens. Remember to update the H160 token contract address whenever you switch to a different token. Also, you will need to recalculate the H256 storage slot for each distinct account whose balance you want to override.

??? code "Example: Override Wormhole BTC Token Balance"

    ```json
    [
        {
            "pallet": "EVM",
            "storage": "AccountStorages",
            "key": [
                "0xE57eBd2d67B462E9926e04a8e33f01cD0D64346D",
                "0x8c9902c0f94ae586c91ba539eb52087d3dd1578da91158308d79ff24a8d4f342"
            ],
            "value": "0x000000000000000000000000000000000000000000000000000000012a05f200"
        }
    ]
    ```

??? code "Example: Override Wormhole ETH Token Balance"

    ```json
    [
        {
            "pallet": "EVM",
            "storage": "AccountStorages",
            "key": [
                "0xab3f0245B83feB11d15AAffeFD7AD465a59817eD",
                "0x8c9902c0f94ae586c91ba539eb52087d3dd1578da91158308d79ff24a8d4f342"
            ],
            "value": "0x000000000000000000000000000000000000000000000000000000012a05f200"
        }
    ]
    ```

??? code "Example: Override WELL Token Balance"

    Because the [WELL token](https://moonbeam.moonscan.io/token/0x511ab53f793683763e5a8829738301368a2411e3){target=_blank} does not use a proxy implementation contract, the storage slot calculation differs. Instead of slot `5`, the balance mapping resides at slot `1`. You can determine the exact storage slot to override the WELL token balance for your own account using the following script:

    ```js
    import { ethers } from 'ethers';

    function getBalanceSlot(accountAddress) {
      // Convert address to bytes32 and normalize
      const addr = ethers.zeroPadValue(accountAddress, 32);

      // Caution! The storage slot index used here is 1
      // The storage slot index for other tokens may vary
      const packedData = ethers.concat([
        addr,
        ethers.zeroPadValue(ethers.toBeHex(1), 32),
      ]);

      // Calculate keccak256
      return ethers.keccak256(packedData);
    }

    // Example usage
    const address = 'INSERT_ADDRESS';
    console.log(getBalanceSlot(address));
    ```

    Thus, the storage override would be:

    ```json
    [
        {
            "pallet": "EVM",
            "storage": "AccountStorages",
            "key": [
                "0x511aB53F793683763E5a8829738301368a2411E3",
                "0x728d3daf4878939a6bb58cbc263f39655bb57ea15db7daa0b306f3bf2c3f1227"
            ],
            "value": "0x000000000000000000000000000000000000000000000000000000012a05f200"
        }
    ]
    ```

## Tracing RPC Endpoint Providers {: #tracing-providers }

Tracing RPC endpoints allow you to access non-standard RPC methods, such as those that belong to Geth's `debug` and `txpool` APIs and OpenEthereum's `trace` module. To see a list of the supported non-standard RPC methods on Moonbeam for debugging and tracing, please refer to the [Debug API & Trace Module](/builders/ethereum/json-rpc/debug-trace/){target=_blank} guide.

The following providers provide tracing RPC endpoints:

- [OnFinality](#onfinality-tracing)

### OnFinality {: #onfinality-tracing }

[OnFinality](https://onfinality.io){target=_blank}'s Trace API can be used to quickly get started tracing and debugging transactions on Moonbeam and Moonriver. It is only available to users on their [Growth and Ultimate plans](https://onfinality.io/pricing){target=_blank}.

To use the Trace API, you simply call the trace method of your choice from your [private RPC endpoint](#onfinality). For a list of the supported networks and trace methods, please check out [OnFinality's Trace API documentation](https://documentation.onfinality.io/support/trace-api#TraceAPI-SupportedNetworks){target=_blank}.

Please note that if you are tracing historic blocks, it is recommended to use your own dedicated trace node to backfill any data, and then once you're caught up, you can switch to using the Trace API. You can check out the [How to Deploy a Trace Node for Moonbeam on OnFinality](https://onfinality.medium.com/how-to-deploy-a-trace-node-for-moonbeam-on-onfinality-85683181d290){target=-_blank} post for more information on how to spin up your own dedicated trace node.
--- END CONTENT ---