The primary addValidator command adds an Avalanche node as a validator in the Avalanche Primary Network with AddPermissionlessValidatorTx.
This command requires the node's BLS key and proof of possession key, more information regarding BLS can be found here.
To get a node's BLS key and proof of possession key, call info.getNodeID API as shown here
Usage:
avalanche primary addValidator [flags]
Flags:
--nodeID string the node ID of the validator-k, --key string select the key to use [fuji deploy only] --weight uint set the staking weight of the validator --start-time string UTC start time when this validator starts validating, in 'YYYY-MM-DD HH:MM:SS' format --staking-period duration how long this validator will be staking --fuji fuji join on fuji (alias for `testnet`) --testnet testnet join on testnet (alias for `fuji`) --mainnet mainnet join on mainnet-g, --ledger use ledger instead of key (always true on mainnet, defaults to false on fuji) --ledger-addrs strings use the given ledger addresses --public-key string set the BLS public key of the validator --proof-of-possession string set the BLS proof of possession of the validator --delegation-fee uint set the delegation fee (20 000 is equivalent to 2%)
The blockchain command suite provides a collection of tools for developing and deploying Avalanche L1s.
To get started, use the blockchain create command wizard to walk through the configuration of your very first Avalanche L1. Then, go ahead and deploy it with the blockchain deploy command. You can use the rest of the commands to manage your Avalanche L1 configurations and live deployments.
The blockchain addValidator command whitelists a primary network validator to validate the provided deployed Avalanche L1.
To add the validator to the Avalanche L1's allow list, you first need to provide the blockchainName and the validator's unique NodeID. The command then prompts for the validation start time, duration, and stake weight. You can bypass these prompts by providing the values with flags.
This command currently only works on Avalanche L1s deployed to either the Fuji Testnet or Mainnet.
--default-validator-params use default weight/start/duration params for subnet validator --devnet devnet add subnet validator on devnet --endpoint string use the given endpoint for network operations-e, --ewoq use ewoq key [fuji/devnet only] --fuji fuji add subnet validator on fuji (alias for `testnet`)-h, --help help for addValidator-k, --key string select the key to use [fuji/devnet only]-g, --ledger use ledger instead of key (always true on mainnet, defaults to false on fuji/devnet) --ledger-addrs strings use the given ledger addresses --local local add subnet validator on local --mainnet mainnet add subnet validator on mainnet --nodeID string set the NodeID of the validator to add --output-tx-path string file path of the add validator tx --staking-period duration how long this validator will be staking --start-time string UTC start time when this validator starts validating, in 'YYYY-MM-DD HH:MM:SS' format --subnet-auth-keys strings control keys that will be used to authenticate add validator tx --testnet testnet add subnet validator on testnet (alias for `fuji`) --weight uint set the staking weight of the validator to add
--fuji remove validator in existing fuji deployment (alias for `testnet`)-k, --key string select the key to use [fuji only]-g, --ledger use ledger instead of key (always true on mainnet, defaults to false on fuji) --ledger-addrs strings use the given ledger addresses --local remove validator in existing local deployment --mainnet remove validator in existing mainnet deployment --nodeID string set the NodeID of the validator to remove --output-tx-path string file path of the removeValidator tx --subnet-auth-keys strings control keys that will be used to authenticate removeValidator tx --testnet remove validator in existing testnet deployment (alias for `fuji`)
--control-keys strings addresses that may make subnet changes --devnet devnet change subnet owner on devnet --endpoint string use the given endpoint for network operations-e, --ewoq use ewoq key [fuji/devnet] --fuji fuji change subnet owner on fuji (alias for `testnet`)-h, --help help for changeOwner-k, --key string select the key to use [fuji/devnet]-g, --ledger use ledger instead of key (always true on mainnet, defaults to false on fuji/devnet) --ledger-addrs strings use the given ledger addresses --local local change subnet owner on local --mainnet mainnet change subnet owner on mainnet --output-tx-path string file path of the transfer subnet ownership tx-s, --same-control-key use the fee-paying key as control key --subnet-auth-keys strings control keys that will be used to authenticate transfer subnet ownership tx --testnet testnet change subnet owner on testnet (alias for `fuji`) --threshold uint32 required number of control key signatures to make subnet changes
AvalancheGo nodes support several different configuration files. Avalanche L1s have their own Avalanche L1 config which applies to all chains/VMs in the Avalanche L1. Each chain within the Avalanche L1 can have its own chain config. This command allows you to set both config files.
--chain-config string path to the chain configuration-h, --help help for configure --per-node-chain-config string path to per node chain configuration for local network --subnet-config string path to the subnet configuration
The blockchain create command builds a new genesis file to configure your Avalanche L1. By default, the command runs an interactive wizard. It walks you through all the steps you need to create your first Avalanche L1.
The tool supports deploying Subnet-EVM and custom VMs. You can create a custom, user-generated genesis with a custom VM by providing the path to your genesis and VM binaries with the --genesis and --vm flags.
By default, running the command with a blockchainName that already exists causes the command to fail. If you'd like to overwrite an existing configuration, pass the -f flag.
--custom use a custom VM template --custom-vm-branch string custom vm branch --custom-vm-build-script string custom vm build-script --custom-vm-path string file path of custom vm to use --custom-vm-repo-url string custom vm repository url --evm use the Subnet-EVM as the base template --evm-chain-id uint chain ID to use with Subnet-EVM --evm-defaults use default settings for fees/airdrop/precompiles with Subnet-EVM --evm-token string token name to use with Subnet-EVM-f, --force overwrite the existing configuration if one exists --from-github-repo generate custom VM binary from github repository --genesis string file path of genesis to use-h, --help help for create --latest use latest Subnet-EVM released version, takes precedence over --vm-version --pre-release use latest Subnet-EVM pre-released version, takes precedence over --vm-version --relayer run AWM relayer when deploying the vm --teleporter generate a teleporter-ready vm (default true) --vm string file path of custom vm to use. alias to custom-vm-path --vm-version string version of Subnet-EVM template to use --warp generate a vm with warp support (needed for teleporter)
The blockchain deploy command deploys your Avalanche L1 configuration locally, to Fuji Testnet, or to Mainnet.
At the end of the call, the command prints the RPC URL you can use to interact with the Avalanche L1.
Avalanche-CLI only supports deploying an individual Avalanche L1 once per network. Subsequent attempts to deploy the same Avalanche L1 to the same network (local, Fuji, Mainnet) aren't allowed. If you'd like to redeploy an Avalanche L1 locally for testing, you must first call avalanche network clean to reset all deployed chain state. Subsequent local deploys redeploy the chain with fresh state. You can deploy the same Avalanche L1 to multiple networks, so you can take your locally tested Avalanche L1 and deploy it on Fuji or Mainnet.
--avalanchego-path string use this avalanchego binary path --avalanchego-version string use this version of avalanchego (ex: v1.17.12) (default "latest") --control-keys strings addresses that may make subnet changes --devnet deploy to a devnet network --endpoint string use the given endpoint for network operations-e, --ewoq use ewoq key [fuji/devnet deploy only]-f, --fuji testnet deploy to fuji (alias to testnet-h, --help help for deploy-k, --key string select the key to use [fuji/devnet deploy only]-g, --ledger use ledger instead of key (always true on mainnet, defaults to false on fuji/devnet) --ledger-addrs strings use the given ledger addresses-l, --local deploy to a local network-m, --mainnet deploy to mainnet --mainnet-chain-id string use different ChainID for mainnet deployment --output-tx-path string file path of the blockchain creation tx-s, --same-control-key use creation key as control key --subnet-auth-keys strings control keys that will be used to authenticate chain creation-u, --subnet-id string deploy into given subnet id-t, --testnet fuji deploy to testnet (alias to fuji) --threshold uint32 required number of control key signatures to make subnet changes
The blockchain describe command prints the details of an Avalanche L1 configuration to the console. By default, the command prints a summary of the configuration. By providing the --genesis flag, the command instead prints out the raw genesis file.
The blockchain import command imports configurations into Avalanche-CLI.
This command supports importing from a file created on another computer, or importing from Avalanche L1s running public networks (for example, created manually or with the deprecated Avalanche-CLI)
To import from a file, you can optionally provide the path as a command-line argument. Alternatively, running the command without any arguments triggers an interactive wizard. To import from a repository, go through the wizard. By default, an imported Avalanche L1 doesn't overwrite an existing Avalanche L1 with the same name. To allow overwrites, provide the --force flag.
--branch string the repo branch to use if downloading a new repo-f, --force overwrite the existing configuration if one exists-h, --help help for import --repo string the repo to import (ex: ava-labs/avalanche-plugins-core) or url to download the repo from --subnet string the subnet configuration to import from the provided repo
The blockchain import public command imports an Avalanche L1 configuration from a running network.
The genesis file should be available from the disk for this to work. By default, an imported Avalanche L1 doesn't overwrite an existing Avalanche L1 with the same name. To allow overwrites, provide the --force flag.
Usage:
avalanche blockchain import public [blockchainPath] [flags]
Flags:
--custom use a custom VM template --evm import a subnet-evm-f, --force overwrite the existing configuration if one exists --fuji fuji import from fuji (alias for `testnet`) --genesis-file-path string path to the genesis file-h, --help help for public --mainnet mainnet import from mainnet --node-url string [optional] URL of an already running subnet validator --subnet-id string the subnet ID --testnet testnet import from testnet (alias for `fuji`)
The blockchain join command configures your validator node to begin validating a new Avalanche L1.
To complete this process, you must have access to the machine running your validator. If the CLI is running on the same machine as your validator, it can generate or update your node's config file automatically. Alternatively, the command can print the necessary instructions to update your node manually. To complete the validation process, the Avalanche L1's admins must add the NodeID of your validator to the Avalanche L1's allow list by calling addValidator with your NodeID.
After you update your validator's config, you need to restart your validator manually. If you provide the --avalanchego-config flag, this command attempts to edit the config file at that path.
This command currently only supports Avalanche L1s deployed on the Fuji Testnet and Mainnet.
--avalanchego-config string file path of the avalanchego config file --fail-if-not-validating fail if whitelist check fails --force-whitelist-check if true, force the whitelist check --force-write if true, skip to prompt to overwrite the config file --fuji fuji join on fuji (alias for `testnet`)-h, --help help for join --mainnet mainnet join on mainnet --nodeID string set the NodeID of the validator to check --plugin-dir string file path of avalanchego's plugin directory --print if true, print the manual config without prompting --skip-whitelist-check if true, skip the whitelist check --testnet testnet join on testnet (alias for `fuji`)
The blockchain list command prints the names of all created Avalanche L1 configurations. Without any flags, it prints some general, static information about the Avalanche L1. With the --deployed flag, the command shows additional information including the VMID, BlockchainID and SubnetID.
Usage:
avalanche blockchain list [flags]
Flags:
--deployed show additional deploy information-h, --help help for list
--alias string We publish to a remote repo, but identify the repo locally under a user-provided alias (e.g. myrepo). --force If true, ignores if the subnet has been published in the past, and attempts a forced publish.-h, --help help for publish --no-repo-path string Do not let the tool manage file publishing, but have it only generate the files and put them in the location given by this flag. --repo-url string The URL of the repo where we are publishing --subnet-file-path string Path to the Subnet description file. If not given, a prompting sequence will be initiated. --vm-file-path string Path to the VM description file. If not given, a prompting sequence will be initiated.
--fuji fuji print stats on fuji (alias for `testnet`)-h, --help help for stats --mainnet mainnet print stats on mainnet --testnet testnet print stats on testnet (alias for `fuji`)
Apply generated upgrade bytes to running Avalanche L1 nodes to trigger a network upgrade.
For public networks (Fuji Testnet or Mainnet), to complete this process, you must have access to the machine running your validator. If the CLI is running on the same machine as your validator, it can manipulate your node's configuration automatically. Alternatively, the command can print the necessary instructions to upgrade your node manually.
After you update your validator's configuration, you need to restart your validator manually. If you provide the --avalanchego-chain-config-dir flag, this command attempts to write the upgrade file at that path. Refer to this doc for related documentation.
--avalanchego-chain-config-dir string avalanchego's chain config file directory (default "/Users/connor/.avalanchego/chains") --config create upgrade config for future subnet deployments (same as generate) --force If true, don't prompt for confirmation of timestamps in the past --fuji fuji apply upgrade existing fuji deployment (alias for `testnet`)-h, --help help for apply --local local apply upgrade existing local deployment --mainnet mainnet apply upgrade existing mainnet deployment --print if true, print the manual config without prompting (for public networks only) --testnet testnet apply upgrade existing testnet deployment (alias for `fuji`)
--force If true, overwrite a possibly existing file without prompting-h, --help help for export --upgrade-filepath string Export upgrade bytes file to location of choice on disk
The blockchain upgrade generate command builds a new upgrade.json file to customize your Avalanche L1. It guides the user through the process using an interactive wizard.
The blockchain upgrade vm command enables the user to upgrade their Avalanche L1's VM binary. The command can upgrade both local Avalanche L1s and publicly deployed Avalanche L1s on Fuji and Mainnet.
The command walks the user through an interactive wizard. The user can skip the wizard by providing command line flags.
The node command suite provides a collection of tools for creating and maintaining validators on the Avalanche Network.
To get started, use the node create command wizard to walk through the configuration to make your node a primary validator on Avalanche public network. You can use the rest of the commands to maintain your node and make your node an Avalanche L1 Validator.
(ALPHA Warning) This command is currently in experimental mode.
The node create command sets up a validator on a cloud server of your choice. The validator will be validating the Avalanche Primary Network and Avalanche L1 of your choice. By default, the command runs an interactive wizard. It walks you through all the steps you need to set up a validator. Validators can be deployed in multiple regions/zones simultaneously. Once this command is run, you will have to wait for the validator to finish bootstrapping on the primary network before running further commands on it, for example validating an Avalanche L1. You can check the bootstrapping status by running avalanche node status.
The created node will be part of group of validators called <clusterName> and users can call node commands with <clusterName> so that the command will apply to all nodes in the cluster.
Usage:
avalanche node create [clusterName] [flags]
Flags:
--alternative-key-pair-name string key pair name to use if default one generates conflicts --authorize-access authorize CLI to create cloud resources --avalanchego-version-from-subnet string install latest avalanchego version, that is compatible with the given subnet, on node/s --aws create node/s in AWS cloud --aws-profile string aws profile to use (default "default") --custom-avalanchego-version string install given avalanchego version on node/s --devnet create node/s into a new Devnet --devnet-api-nodes int number of API nodes(nodes without stake) to create in the new Devnet --fuji create node/s in Fuji Network --gcp create node/s in GCP cloud --gcp-credentials string use given GCP credentials --gcp-project string use given GCP project-h, --help help for create --latest-avalanchego-pre-release-version install latest avalanchego pre-release version on node/s --latest-avalanchego-version install latest avalanchego release version on node/s --node-type string cloud instance type. Use 'default' to use recommended default instance type --num-nodes ints number of nodes to create per region(s). Use comma to separate multiple numbers for each region in the same order as --region flag --region strings create node(s) in given region(s). Use comma to separate multiple regions --same-monitoring-instance host monitoring for a cloud servers on the same instance --separate-monitoring-instance host monitoring for all cloud servers on a separate instance --skip-monitoring don't set up monitoring in created nodes --ssh-agent-identity string use given ssh identity(only for ssh agent). If not set, default will be used --use-ssh-agent use ssh agent(ex: Yubikey) for ssh auth --use-static-ip attach static Public IP on cloud servers (default true)
(ALPHA Warning) This command is currently in experimental mode.
The node devnet command suite provides a collection of commands related to devnets. You can check the updated status by calling avalanche node status <clusterName>
The node devnet deploy command deploys an Avalanche L1 into a devnet cluster, creating Avalanche L1 and blockchain TXs for it. It saves the deploy info both locally and remotely.
--alternative-key-pair-name string key pair name to use if default one generates conflicts --authorize-access authorize CLI to create cloud resources --avalanchego-version string install given avalanchego version on node/s --aws create node/s in AWS cloud --aws-profile string aws profile to use (default "default") --chain-config string path to the chain configuration for subnet --custom-subnet use a custom VM as the subnet virtual machine --custom-vm-branch string custom vm branch --custom-vm-build-script string custom vm build-script --custom-vm-repo-url string custom vm repository url --default-validator-params use default weight/start/duration params for subnet validator --devnet-api-nodes int number of API nodes(nodes without stake) to create in the new Devnet --evm-chain-id uint chain ID to use with Subnet-EVM --evm-defaults use default settings for fees/airdrop/precompiles with Subnet-EVM --evm-subnet use Subnet-EVM as the subnet virtual machine --evm-token string token name to use with Subnet-EVM --evm-version string version of Subnet-EVM to use --force-subnet-create overwrite the existing subnet configuration if one exists --gcp create node/s in GCP cloud --gcp-credentials string use given GCP credentials --gcp-project string use given GCP project-h, --help help for wiz --latest-avalanchego-pre-release-version install latest avalanchego pre-release version on node/s --latest-avalanchego-version install latest avalanchego release version on node/s --latest-evm-version use latest Subnet-EVM released version --latest-pre-released-evm-version use latest Subnet-EVM pre-released version --node-config string path to avalanchego node configuration for subnet --node-type string cloud instance type. Use 'default' to use recommended default instance type --num-nodes ints number of nodes to create per region(s). Use comma to separate multiple numbers for each region in the same order as --region flag --region strings create node/s in given region(s). Use comma to separate multiple regions --same-monitoring-instance host monitoring for a cloud servers on the same instance --separate-monitoring-instance host monitoring for all cloud servers on a separate instance --skip-monitoring don't set up monitoring in created nodes --ssh-agent-identity string use given ssh identity(only for ssh agent). If not set, default will be used. --subnet-config string path to the subnet configuration for subnet --subnet-genesis string file path of the subnet genesis --use-ssh-agent use ssh agent for ssh --use-static-ip attach static Public IP on cloud servers (default true) --validators strings deploy subnet into given comma separated list of validators. defaults to all cluster nodes
(ALPHA Warning) This command is currently in experimental mode.
The node ssh command execute a given command using ssh on all nodes in the cluster. If no command is given, just prints the ssh command line to be used to connect to each node.
(ALPHA Warning) This command is currently in experimental mode.
The node status command gets the bootstrap status of all nodes in a cluster with the Primary Network. If no cluster is given, defaults to node list behaviour.
To get the bootstrap status of a node with an Avalanche L1, use the --subnet flag.
Usage:
avalanche node status [clusterName] [flags]
Flags:
-h, --help help for status --subnet string specify the subnet the node is syncing with
(ALPHA Warning) This command is currently in experimental mode.
The node stop command stops a running node in cloud server
Note that a stopped node may still incur cloud server storage fees.
Usage:
avalanche node stop [clusterName] [flags]
Flags:
--authorize-access authorize CLI to release cloud resources --authorize-remove authorize CLI to remove all local files related to cloud nodes-h, --help help for stop
(ALPHA Warning) This command is currently in experimental mode.
The node sync command enables all nodes in a cluster to be bootstrapped to an Avalanche L1. You can check the Avalanche L1 bootstrap status by calling avalanche node status <clusterName> --subnet <blockchainName>
(ALPHA Warning) This command is currently in experimental mode.
The node update command suite provides a collection of commands for nodes to update their AvalancheGo version or VM version/config. You can check the status after update by running avalanche node status
(ALPHA Warning) This command is currently in experimental mode.
The node update subnet command updates all nodes in a cluster with latest Avalanche L1 configuration and You can check the updated Avalanche L1 bootstrap status by calling avalanche node status <clusterName> --subnet <blockchainName>
(ALPHA Warning) This command is currently in experimental mode.
The node validate command suite provides a collection of commands for nodes to join the Primary Network and Avalanche L1s as validators. If any of the commands is run before the nodes are bootstrapped on the Primary Network, the command will fail.
You can check the bootstrap status by running avalanche node status <clusterName>.
-f, --fuji testnet set up validator in fuji (alias to testnet-h, --help help for primary-k, --key string select the key to use [fuji only]-g, --ledger use ledger instead of key (always true on mainnet, defaults to false on fuji) --ledger-addrs strings use the given ledger addresses-m, --mainnet set up validator in mainnet --stake-amount uint how many AVAX to stake in the validator --staking-period duration how long validator validates for after start time-t, --testnet fuji set up validator in testnet (alias to fuji)
(ALPHA Warning) This command is currently in experimental mode.
The node validate subnet command enables all nodes in a cluster to be validators of an Avalanche L1. If the command is run before the nodes are Primary Network validators, the command will first make the nodes Primary Network validators before making them Avalanche L1 validators. If The command is run before the nodes are bootstrapped on the Primary Network, the command will fail. You can check the bootstrap status by calling avalanche node status <clusterName>. If The command is run before the nodes are synced to the Avalanche L1, the command will fail. You can check the Avalanche L1 sync status by calling avalanche node status <clusterName> --subnet <blockchainName>.
--default-validator-params use default weight/start/duration params for subnet validator-d, --devnet set up validator in devnet --endpoint string use the given endpoint for network operations-e, --ewoq use ewoq key [fuji/devnet only]-f, --fuji testnet set up validator in fuji (alias to testnet-h, --help help for subnet-k, --key string select the key to use [fuji/devnet only]-g, --ledger use ledger instead of key (always true on mainnet, defaults to false on fuji/devnet) --ledger-addrs strings use the given ledger addresses-m, --mainnet set up validator in mainnet --stake-amount uint how many AVAX to stake in the validator --staking-period duration how long validator validates for after start time --start-time string UTC start time when this validator starts validating, in 'YYYY-MM-DD HH:MM:SS' format-t, --testnet fuji set up validator in testnet (alias to fuji)
(ALPHA Warning) This command is currently in experimental mode.
The node whitelist command suite provides a collection of tools for granting access to the cluster.
Nodes created by Avalanche-CLI are protected by Cloud Security Group and only defined IP addresses are allowed to access. User IP is whitelisted automatically when cluster is created, but this command can be used in case of IP address changes or granting access to additional IPs. This command detects user current IP address automatically if no IP address is provided.
Secure SSH protocol is used to communicate with cloud instances. node whitelist command authorizes SSH public key on all nodes in the cluster if --ssh params is specified. Please keep your SSH private keys safe and secure, only share public keys to grant shell access to cloud instances running avalanchego.
(ALPHA Warning) This command is currently in experimental mode.
The node export command exports cluster configuration including their nodes to a text file. If no file is specified, the configuration is printed to the stdout. Use --include-secrets to include keys in the export. In this case this command can be used to backup your cluster configuration. Please keep the file secure as it contains sensitive information.
Exported cluster configuration without secrets it can be imported by another user using node import command.
Usage:
avalanche node export [clusterName] [flags]
Flags:
--file string specify the file to export the cluster configuration to --force overwrite the file if it exists -h, --help help for export --include-secrets include keys in the export
(ALPHA Warning) This command is currently in experimental mode.
The node import command imports cluster configuration and cluster nodes from a text file. This file should be created using the node export command.
This command is useful with node whitelist command. With your SSH public key and IP whitelisted by cluster owner you will be able to execute commands and use avalanche-cli to manage this cluster. Please note, that this imported cluster will be considered as EXTERNAL by avalanche-cli so some commands affecting cloud nodes like node create or node destroy will be not applicable for it.
Usage:
avalanche node import [clusterName] [flags]
Flags:
--file string specify the file to export the cluster configuration to -h, --help help for import
(ALPHA Warning) This command is currently in experimental mode.
The node resize command can be used to resize cluster instance size and/or size of the cloud persistent storage attached to the instance. In another words, it can change amount of CPU, memory and disk space available for the cluster nodes.
Please note that disk resize operation can affect disk performance during cloud operation to resize it. Please note that instance resize operation will replace cluster instances one by one, which might affect cluster stability.
Usage:
avalanche node resize [clusterName] [flags]
Flags:
--aws-profile string aws profile to use (default "default") --disk-size string Disk size to resize in Gb (e.g. 1000Gb) -h, --help help for resize --node-type string Node type to resize (e.g. t3.2xlarge)
The network command suite provides a collection of tools for managing local Avalanche L1 deployments.
When you deploy an Avalanche L1 locally, it runs on a local, multi-node Avalanche network. The blockchain deploy command starts this network in the background. This command suite allows you to shutdown, restart, and clear that network.
This network currently supports multiple, concurrently deployed Avalanche L1s.
The network clean command shuts down your local, multi-node network. All deployed Avalanche L1s shutdown and delete their state. You can restart the network by deploying a new Avalanche L1 configuration.
Usage:
avalanche network clean [flags]
Flags:
--hard Also clean downloaded avalanchego and plugin binaries-h, --help help for clean
The network start command starts a local, multi-node Avalanche network on your machine.
By default, the command loads the default snapshot. If you provide the --snapshot-name flag, the network loads that snapshot instead. The command fails if the local network is already running.
Usage:
avalanche network start [flags]
Flags:
--avalanchego-path string use this avalanchego binary path --avalanchego-version string use this version of avalanchego (ex: v1.17.12) (default "latest")-h, --help help for start --snapshot-name string name of snapshot to use to start the network from (default "default-1654102509")
The network stop command shuts down your local, multi-node network.
All deployed Avalanche L1s shutdown gracefully and save their state. If you provide the --snapshot-name flag, the network saves its state under this named snapshot. You can reload this snapshot with network start --snapshot-name <snapshotName>. Otherwise, the network saves to the default snapshot, overwriting any existing state. You can reload the default snapshot with network start.
Usage:
avalanche network stop [flags]
Flags:
-h, --help help for stop --snapshot-name string name of snapshot to use to save network state into (default "default-1654102509")
-h, --help help for sign --input-tx-filepath string Path to the transaction file for signing-k, --key string select the key to use [fuji only]-g, --ledger use ledger instead of key (always true on mainnet, defaults to false on fuji) --ledger-addrs strings use the given ledger addresses
The key command suite provides a collection of tools for creating and managing signing keys. You can use these keys to deploy Avalanche L1s to the Fuji Testnet, but these keys are NOT suitable to use in production environments. DO NOT use these keys on Mainnet.
The key create command generates a new private key to use for creating and controlling test Avalanche L1s. Keys generated by this command are NOT cryptographically secure enough to use in production environments. DO NOT use these keys on Mainnet.
The command works by generating a secp256 key and storing it with the provided keyName. You can use this key in other commands by providing this keyName.
If you'd like to import an existing key instead of generating one from scratch, provide the --file flag.
Usage:
avalanche key create [keyName] [flags]
Flags:
--file string import the key from an existing key file-f, --force overwrite an existing key with the same name-h, --help help for create
The key delete command deletes an existing signing key.
To delete a key, provide the keyName. The command prompts for confirmation before deleting the key. To skip the confirmation, provide the --force flag.
Usage:
avalanche key delete [keyName] [flags]
Flags:
-f, --force delete the key without confirmation-h, --help help for delete
The key export command exports a created signing key. You can use an exported key in other applications or import it into another instance of Avalanche-CLI.
By default, the tool writes the hex encoded key to stdout. If you provide the --output flag, the command writes the key to a file of your choosing.
Usage:
avalanche key export [keyName] [flags]
Flags:
-h, --help help for export-o, --output string write the key to the provided file path
The key list command prints information for all stored signing keys or for the ledger addresses associated to certain indices.
Usage:
avalanche key list [flags]
Flags:
-a, --all-networks list all network addresses-c, --cchain list C-Chain addresses (default true)-f, --fuji list testnet (fuji) network addresses-h, --help help for list-g, --ledger uints list ledger addresses for the given indices (default [])-l, --local list local network addresses-m, --mainnet list mainnet network addresses --pchain list P-Chain addresses (default true) --subnet string provide balance information for the given subnet (Subnet-Evm based only)-t, --testnet list testnet (fuji) network addresses-n, --use-nano-avax use nano Avax for balances --xchain list X-Chain addresses (default true)
The key transfer command allows to transfer funds between stored keys or ledger addresses.
Usage:
avalanche key transfer [options] [flags]
Flags:
-o, --amount float amount to send or receive (AVAX units)-f, --force avoid transfer confirmation-u, --fuji transfer between testnet (fuji) addresses --fund-p-chain fund P-Chain account on target --fund-x-chain fund X-Chain account on target-h, --help help for transfer-k, --key string key associated to the sender or receiver address-i, --ledger uint32 ledger index associated to the sender or receiver address (default 32768)-l, --local transfer between local network addresses-m, --mainnet transfer between mainnet addresses-g, --receive receive the transfer-r, --receive-recovery-step uint receive step to use for multiple step transaction recovery-s, --send send the transfer-a, --target-addr string receiver address-t, --testnet transfer between testnet (fuji) addresses
