Skip to main content

Vara Validator FAQs

Here is a list of frequently asked questions about running a Vara validator node.

What is Vara Network?

Vara Network is a fast and scalable Layer-1 decentralized network powered by Gear Protocol.


What are the public RPC endpoints?

  • RPC Node:

    • wss://
  • Archive RPC Node:

    • wss://

What bootnode should I use to connect to the network?

Here are addresses of official Vara bootnodes:

  • /dns4/
  • /dns4/

These nodes are already included in the Vara chain spec, which will be used by default when you start your node with --chain vara

What is the block time of the Vara Network?

It is operating at a rate of one block every 3 seconds.

How long does an era last?

12 hours.

An era is a period during which a specific set of active validators exists. Each era has six epochs (or sessions). During the last epoch, the active set of the next era is elected. And after the end of each era, the rewards are calculated and are ready to be distributed to the validators and nominators.

How long does an epoch / a session last?

2 hours.

What is the total issuance of $VARA?

10 Billion.

What is the precision of the $VARA token?

12 decimals.

What is a validator in Vara Network?

Validators are essential contributors to a successful blockchain network. When chosen to be part of a validator set, they help produce blocks and receive rewards for their input.

A validator node is required to be responsive, perform its expected duties in a timely manner, and avoid any slashable behavior.

How to run a validator node?

Please follow this guide to get started: Run Vara Validator.

What are the hardware requirements to run a validator node?

  • OS: Ubuntu 20.04 or later, Amazon Linux 2 or later
  • CPU: 4vCPUs @ 3.4GHz; (it could be Intel Ice Lake, Xeon or Core series, even AMD Zen3)
  • Memory: 16GB RAM
  • Storage: minimum 160GB SSD storage. Should be increased as the blockchain grows.

You can find related information on the Vara wiki page: Run Vara Validator > Hardware requirements

Where do I download the node binary?

Navigate to and download the most recent stable release.

You can also get it from github release page:

How fast should I upgrade node binary?

All nodes must upgrade to the latest version within 12 hours of its release if it is labeled “critical” or “high” priority and 24 hours if it is labeled “medium” or “low” priority.

Is there official docker image?

Yes, you can pull the latest image from GitHub Container Registry

docker pull

or find more tags here:

How do I check if my node is validator or not?

Navigate to, and you will find a list of the active validators

What is slashing?

Slashing is a mechanism to punish validators who act maliciously or negligently. If a validator tries to corrupt the network or is offline too often, a part of their staked fund (and those of their nominators) can be slashed.

What can lead to a validator's stake being slashed?

Your validator node can be slashed under the following scenarios:

  1. Equivocation: This occurs when a validator signs two or more blocks at the same height on the same chain. It's a serious offense because it can lead to the creation of two different versions of the blockchain, a situation known as a fork.

  2. Unresponsiveness: Validators are expected to be online and participate in the network consensus. If a validator is offline for an extended period and misses a certain number of votes, a portion of their stake can be slashed. This is generally considered a minor offense, and the slashing is less severe than for equivocation or producing invalid blocks.

  3. Invalid Block: Validators are expected to validate blocks correctly. If a validator produces a block that the network deems invalid, it can result in slashing. Note that it's unlikely to produce an invalid block unless you are running a modified node binary, therefore it's recommended to always download the binary from the official release page.

How is the liveness slashing penalty calculated?

If a single validator is offline there’s no obvious reason to suspect malicious intent. The validator is not slashed, which means they also keep all their nominations. They are chilled. In practice, the protocol considers it problematic when 10% of the validator set is offline—that’s when slashing conditions kick in.

liveness slashing penalty

The penalty starts relatively small, 0.021% slashed if 10% are offline. But penalties increase linearly from there until the maximum penalty of 7% is hit when 44% of the network is offline.

How is the equivocation / double-sign slashing penalty calculated?

Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down, but validator operators should be extremely careful in setting these up. If they do not have good coordination to manage signing machines, equivocation is possible, and equivocation offenses are slashed at much higher rates than equivalent offline offenses.

equivocation slashing penalty

GRANDPA equivocation has the harshest slashing penalty of all offenses, and it also exemplifies slashing based on the threat to the network—if 33% or more of the validator set commits a GRANDPA equivocation, the offenders lose 100% of their stake.

How to stop validating?

If you wish to remain a validator or nominator (e.g. you're only stopping for planned downtime or server maintenance), submitting the chill extrinsic in the staking pallet should suffice. It is only if you wish to unbond funds or reap an account that you should continue with the following.

To ensure a smooth stop to validation, make sure you should do the following actions:

  • Chill your validator
  • Purge validator session keys
  • Unbond your tokens

These can all be done with PolkadotJS Apps interface or with extrinsics.

How long does it take to unbond tokens?

The unbonding duration is 14 era, i.e. 7 days.

What is the max number of nominators I can have?

For each validator only the 256 biggest nominators can claim their reward. If you have more than 256 nominators, it is called oversubscription. Nominators should generally avoid nominating oversubscribed validators.

Can I run multiple validators?

Yes, you can run multiple validators in Vara Network. Each validator will need its own separate stash and controller keys, as well as enough staked fund (either self-staked or nominated by others) to be in the active validator set.

Running multiple validators can increase your chances of earning rewards, but it also increases your responsibilities and potential risk of slashing. Remember, each validator node requires maintenance, a stable internet connection, and a secure setup to prevent downtime and malicious attacks.

It's important to note that running multiple validators doesn't mean running multiple nodes on the same server or under the same network conditions. This could lead to simultaneous failures, which could result in multiple nodes being slashed at the same time. Ideally, each validator node should be run on separate servers and potentially in different geographic locations for redundancy and resilience.

How to achieve high availability for my validator node?

To maintain high availability for your validator node, it may seem tempting to use redundant validator setups. However, incorrect setups can be risky because validator session keys should be confined to one node. Duplication across nodes may cause equivocation slashes, leading to the loss of all staked funds.

Fortunately, a validator doesn't require constant uptime, as there's some tolerance within eras for offline periods and upgrades, and the slashing penalties due to downtime are much less severe than that caused by equivocation.

Therefore, only attempt a high availability set-up when you know what you're doing.

How do I monitor my node?

  • Telemetry This tracks your node details including the version you are running, block height, CPU & memory usage, block propagation time, etc.

Add --telemetry-url "wss:// 1" to the node startup parameter, then your node will show up on the telemetry dashboard.

  • Prometheus-based monitoring stack, including Grafana for dashboards and log aggregation. It includes alerting, querying, visualization, and monitoring features and works for both cloud and on-premise systems.

You need to specify the prometheus port, for example --prometheus-port 9615, then the node metrics will be available at

What is the expected uptime from validators?

Ideally, a validator node should strive for 100% uptime to avoid any penalties and to perform its duties on the network effectively. In practice 99.5% uptime is considered safe, i.e. you should keep the daily average downtime within 15 minutes.

What is the minimum bond requirement for a validator?

The minimum self-stake required is 100k VARA.

Note that the actual amount of staked token (self-stake plus nominations) required to become a validator may be significantly higher due to competition from other validators.

What is the least staking amount required for a validator to be elected?

The total amount of token that needs to be staked for a validator to be elected (self-stake plus nominations) is determined by the amount staked on other validators. If there are more validators who have a higher total stake, those validators will be chosen instead.

You can get the details by running the subquery/tutorials-validator-threshold indexer on Vara Network.

How often are staking rewards distributed?

Staking rewards are distributed at the end of each era, i.e., every 12 hours.

How are staking rewards calculated?

Rewards for validators and nominators are computed per era (an era is a period of 12 hours) based on era points. An era point is a reward point earned by a validator for performing certain actions such as producing a block.

The total reward pool for an era is split between validators (and their nominators) proportionally to the number of era points they have earned. The more era points a validator earns, the larger the portion of the reward pool they (and their nominators) receive.

The validator's own reward is then calculated based on their commission, which is a percentage of the total reward that they take before distributing the rest to their nominators. Nominators' rewards are distributed based on the amount of fund they have staked.

How should I decide the commission rate?

The commission is the percentage of rewards you keep before they are given out to nominators. With 0% commission, nominators get all the rewards; with 100% commission, they get NO rewards.

In general, in order to stay attractive to nominators you should keep the commission low. However, you also need to ensure that the commission rate you set allows you to sustainably operate your validator node. It's a balance of competitive positioning, sustainability, and profitability.

How many validators will there be in each era?

The ideal number of active validators is defined by the staking.validatorsCount storage item, and is subject to change as the network matures.

You can query the storage item by visiting PolkadotJS Apps > Developer > Chain state > staking > validatorCount

querying chainstate

In each era, if there are more validators than the ideal threshold, the inactive validators will stay in the waiting list until they are elected.

What files should I backup before migrating the validator node to another machine?

It is recommended to have backups of the following files and directories in case your current node becomes inaccessible due to extreme conditions:

  1. Validator Session Keys: If you are running a validator node, please backup the secret seeds of your session keys for minimal downtime migration. These files are located in the ~/.local/share/gear/chains/vara_network/keystore directory. You must submit an extrinsic to replace the keys if they are leaked or lost.

  2. Network Key(optional): The network key uniquely identifies your node in the peer-to-peer network. It is located at ~/.local/share/gear/chains/vara_network/network/secret_ed25519. If this file is lost, a new peer identity will be randomly generated when the node starts.

  3. Blockchain Database(optional): The blockchain database resides in the ~/.local/share/gear/chains/vara_network/db directory. It can be deleted and synchronized from scratch at any time, but keep in mind that this process may take some time.


Please make sure the old node is stopped before you launch the new node, otherwise replicating session keys across multiple nodes may lead to equivocation slashes.