Deploy on Mainnet
CLI commands for deploying an Avalanche L1 on Mainnet.
Deploying an Avalanche L1 to Mainnet has many risks. Doing so safely requires a laser focus on security. This tutorial does its best to point out common pitfalls, but there may be other risks not discussed here.
This tutorial is an educational resource and provides no guarantees that following it results in a secure deployment. Additionally, this tutorial takes some shortcuts that aid the understanding of the deployment process at the expense of security. The text highlights these shortcuts and they shouldn't be used for a production deployment.
After managing a successful Avalanche L1 deployment on the Fuji Testnet
, you're ready to deploy your Avalanche L1 on Mainnet. If you haven't done so, first Deploy an Avalanche L1 on Testnet.
This tutorial shows how to do the following on Mainnet
.
- Create an Avalanche L1.
- Deploy a virtual machine based on Subnet-EVM.
- Join a node to the newly created Avalanche L1.
- Add a node as a validator to the Avalanche L1.
All IDs in this article are for illustration purposes only. They are guaranteed to be different in your own run-through of this tutorial.
Prerequisites
- 5+ nodes running and fully bootstrapped on
Mainnet
- Avalanche-CLI is installed on each validator node's box
- A Ledger device
- You've created an Avalanche L1 configuration and fully tested a Fuji Testnet Avalanche L1 deployment
Although only one validator is strictly required to run an Avalanche L1, running with less than five validators is extremely dangerous and guarantees network downtime. Plan to support at least five validators in your production network.
Getting Your Mainnet NodeIDs
You need to collect the NodeIDs for each of your validators. This tutorial uses these NodeIDs in several commands.
To get the NodeID of a Mainnet
node, call the info.getNodeID endpoint. For example:
The response should look something like:
In the sample response, NodeID-5mb46qkSBj81k9g9e4VFjGGSbaaSLFRzD
is the NodeID. Note that the NodeID-
prefix is part of the NodeID.
Setting up Your Ledger
In the interest of security, all Avalanche-CLI Mainnet
operations require the use of a connected Ledger device. You must unlock your Ledger and run the Avalanche App. See How to Use Ledger for help getting set up.
Avalanche-CLI supports the Ledger Nano X
, Nano S
, and Nano S Plus
.
Ledger devices support TX signing for any address inside a sequence automatically generated by the device.
By default, Avalanche-CLI uses the first address of the derivation, and that address needs funds to issue the TXs to create the Avalanche L1 and add validators.
To get the first Mainnet
address of your Ledger device, first make sure it is connected, unblocked, and running the Avalanche app. Then execute the key list
command:
The command prints the P-Chain address for Mainnet
, P-avax1ucykh6ls8thqpuwhg3vp8vvu6spg5e8tp8a25j
, and its balance. You should fund this address with at least 2.5 AVAX to cover TX fees. the TX fee for creating your Avalanche L1 costs 2 AVAX. Adding validators costs 0.001 AVAX each. For more details, see Fees
You can use the key list
command to get any Ledger address in the derivation sequence by changing the index parameter from 0
to the one desired, or to a list of them (for example: 2
, or 0,4,7
). Also, you can ask for addresses on Fuji
with the --fuji
parameter, and local networks with the --local
parameter.
Funding the Ledger
A new Ledger device has no funds on the addresses it controls. You'll need to send funds to it by exporting them from C-Chain to the P-Chain using Core web connected to Core extension.
You can load the Ledger's C-Chain address in Core extension, or load in a different private key to Core extension, and then connect to Core web .
You can move test funds from the C-Chain to the P-Chain by clicking Stake on Core web , then Cross-Chain Transfer (find more details on this tutorial).
Deploy the Avalanche L1
With your Ledger unlocked and running the Avalanche app, run
This is going to start a new prompt series.
This tutorial is about deploying to Mainnet
, so navigate with the arrow keys to Mainnet
and hit enter.
After that, CLI shows the Mainnet
Ledger address used to fund the deployment:
The first Ledger address must have the funds to issue the transactions broadcast in this workflow.
This tutorial creates a permissioned Avalanche L1. As such, you must specify which P-Chain addresses can control the Avalanche L1. These addresses are known as Control Keys
. The CLI can automatically set your Ledger's address as the sole control key or the user may specify a custom list.
In production Avalanche L1s, you should always use multiple control keys running in a multisig configuration. This tutorial uses a single control key for illustrative purposes only.
For instructions on controlling your Avalanche L1 with a multisig, see the Multisig Deployment Tutorial.
For this tutorial, opt to use the first Ledger address, so enter at Use ledger address
. Only this address is going to be able to add or remove validators, or create blockchains on the Avalanche L1.
Next, the CLI generates a TX for creating the SubnetID and asks the user to sign it by using the Ledger.
This activates a Please review
window on the Ledger. Navigate to the Ledger's APPROVE
window by using the Ledger's right button, and then authorize the request by pressing both left and right buttons.
If the Ledger doesn't have enough funds, the user may see an error message:
If successful, the CLI next asks you to sign a chain creation TX.
This activates a Please review
window on the Ledger. Navigate to the Ledger's APPROVE
window by using the Ledger's right button, and then authorize the request by pressing both left and right buttons.
After that, CLI creates the blockchain within the Avalanche L1, and a summary window for the deployment appears:
Well done. You have just created your own Avalanche L1 running on Mainnet
. Now it's time to add your validators.
Request to Join an Avalanche L1 as a Validator
The new Avalanche L1 created in the previous steps doesn't have any dedicated validators yet. To request permission to validate an Avalanche L1, the following steps are required:
Adding a validator on an Avalanche L1 requires that the node is already a validator on the primary network, which means that your node has fully bootstrapped.
See here on how to become a validator.
First, request permission to validate by running the join
command along with the Avalanche L1 name:
Note: Running join
does not guarantee that your node is a validator of the Avalanche L1! The owner of the Avalanche L1 must approve your node to be a validator afterwards by calling addValidator
as described in the next section.
Select Mainnet
When you join
command, you are first prompted with the network selection. Choose Mainnet
:
Setup Node Automatically
There are now two choices possible: automatic and Manual configuration. As mentioned earlier, "Automatic" attempts to edit your config file and sets up your plugin directory, while "Manual" just prints the required config to the screen. If you are running the CLI on the same box as your validator, you should run the commands in automated mode. If you don't want to run Avalanche-CLI on the same box as your validator, use the manual commands.
Select automatic.
Set Config File
Provide a path to a config file. If this command runs on the box where your validator is running, then you could point this to the actually used config file, for example /etc/avalanchego/config.json
- just make sure the tool has write access to the file. Or you could just copy the file later. In any case, the tool is going to either try to edit the existing file specified by the given path, or create a new file. Again, set write permissions.
Set Plugin Directory
Next, provide the plugin directory. Each VM runs its own binary, called a plugin. Therefore, you need to copy your VM's plugin binary into AvalancheGo's plugin directory. This directory depends on your AvalancheGo install location.
The tool doesn't know where exactly it's located so it requires the full path. With the path given, it's going to copy the VM binary to the provided location:
Hitting Yes
writes the necessary file:
Restart the Node
It's required to restart the node.
Setup Node Manually
By choosing "Manual" instead, the tool prints instructions. The user is going to have to follow these instructions and apply them to the node. Note that the IDs for the VM and Avalanche L1 are different for each Avalanche L1 deployment and you shouldn't copy them from this tutorial.
Add a Validator
If the join
command isn't successfully completed before addValidator
is completed, the Avalanche L1 could experience degraded performance or even halt.
Now that the node has joined the Avalanche L1, an Avalanche L1 control key holder must call addValidator
to grant the node permission to be a validator in your Avalanche L1.
To whitelist a node as a recognized validator on the Avalanche L1, run:
You need to repeat this process for every validator you add to the network.
You can run the addValidator
transactions from the same box that deployed the Avalanche L1.
Submit addValidator TX to Mainnet
First choose Mainnet
as the network to add the Avalanche L1 validator to.
Because this operation issues a new transaction, the CLI needs the control keys to sign the operation. Because this tutorial only uses one control key in the Avalanche L1, the process looks slightly different if you use multiple controls keys. The address needs to pay a TX fee of 0.001 AVAX.
Set NodeID
Now enter the NodeID of the validator.
Note, this ID is intentionally modified to prevent replication.
Set Stake Weight
Select 30 as the stake weight.
The stake weight of all your validators should sum to at least 100.
Set Validation Start Time
Next, specify when the validator is going to start validating. The time must be in the future. You can use the custom option to enter a specific date in YYYY-MM-DD HH:MM:SS
format. Follow the default this time:
Set Validation duration
Finally, specify how long it's going to be validating:
If you choose Custom
here, you need to enter a duration, which is a time span expressed in hours. For example, say 200 days = 24 \* 200 = 4800h
The CLI shows the user an actual date:
Confirm if correct.
Issue the TX
At this point the prompt series is complete and the CLI attempts the transaction:
The CLI shows the Ledger address:
At this point, if the Ledger address isn't the control key for the Avalanche L1, the user receives an error:
If the Ledger doesn't have enough funds, the following error message appears:
Otherwise, both the CLI and the Ledger request to sign the TX:
This activates a Please review
window on the Ledger. Navigate to the Ledger's APPROVE
window by using the Ledger's right button, and then authorize the request by pressing both left and right buttons.
This might take a couple of seconds. After, it prints:
This means the node is now a validator on the given Avalanche L1 on Mainnet
! However, your work isn't complete. You must finish the Request to Join an Avalanche L1 as a Validator section otherwise your Avalanche L1 risks downtime.
You can get the P-Chain TX id information on Avalanche Explorer
Avalanche L1 Export
Because you need to setup multiple validators on multiple different machines, you need to export your Avalanche L1's configuration and import it on each validator.
The file is in text format and you shouldn't change it. You can use it to import the configuration on a different machine.
Avalanche L1 Import
To import a VM configuration, move the file you exported in the previous section to your desired machine and issue the import
command with the path to the file.
After this the whole Avalanche L1 configuration should be available on the target machine:
Going Live
Once all of your validators have joined the network, you are ready to issue transactions to your Avalanche L1.
For the safety of your validators, you should setup dedicated API nodes to process transactions, but for test purposes, you can issue transactions directly to one of your validator's RPC interface.
Last updated on