Where do you want to manage your validator set?

This article explains where to deploy the validator manager contract with pros and cons.

TL;DR:

• If you want full control of your validator set using Proof of Authority (permissioned network) and don't plan to move to Proof of Stake (permissionless network), deploy on your L1.
• If you plan to eventually turn the network permissionless (Proof of Stake), deploy on C-Chain.

The E-Upgrade (Avalanche9000) introduced the ability for L1s to manage their validator sets using a smart contract known as the Validator Manager contract. This allows projects to encode custom logic for validator selection, reward distribution, staking requirements, and other aspects of validator management.

Pre-built Validator Manager Contracts:

• Proof of Authority (PoA)
• Proof of Stake (PoS) using an ERC20 token
• Proof of Stake (PoS) using a native token

When you deploy an L1 through AvaCloud, it starts with a PoA validator manager contract. The owner address configured during deployment can add or remove validators. This can be upgraded later if the project wants to transition from PoA to PoS. One advantage of the E-Upgrade is that the validator manager contract can be deployed on any L1 within Avalanche, so AvaCloud offers a choice of deploying the Validator Manager either on the L1, or on C-Chain. Although the Validator Manager contract can be upgraded, its location cannot. That is why selecting the location of the contract needs to be carefully considered.

Deploying on L1

Pro:

• Validation management is contained on the L1
• No required interaction with C-Chain
• Increased independence (if C-Chain has issues, L1 will continue to work unaffected)
• No need to hold or handle AVAX to manage the validator set

Con:

• Validator management is dependent on L1 liveness, which might be a problem if 3rd party validators are involved or permissioned model (PoS) is planned

Deploying on C-Chain:

Pro:

• If staking token originates on C-Chain, having the manager there simplifies the process for validators
• If you run a permissionless network (or plan to), having the validator set be managed on the C-Chain is a mitigation against missing validators that could halt your chain indefinitely (since adding/removing validators would require a transaction to be posted on halted L1)

Con:

• Dependency on C-Chain, reduced independence
• Operators will need to hold and handle AVAX to manage the validator
• More complexity

It is possible to deploy multiple Validator Manager contracts on a single L1, so that L1 can centrally manage a whole set of L1s which might be required for various business reasons. This is not supported by AvaCloud out of the box, so if you need a solution like that, please contact us.