FAQ
The following details frequently asked questions from our validator community.
NOTE: This section will be continually updated as new questions are received. Check back in regularly to ensure you are staying up-to-date!
What are the responsibilities of a validator?
The responsibilities for running an Arch validator are threefold:
Each Arch node operator must adhere to a strict code of conduct (outlined in the validator agreement you will have already signed). Bad behavior will be punishable via a slashing event or eviction from the validator pool.
Ensure that the correct version of software is being run. The client must remain up-to-date with the most recent major version of the binary and the operator must ensure that the private keys of their validator are not compromised.
Each Arch node must actively participate in governance (voting); not only does this imply that they are actively participating in consensus but also in proposals set forth to upgrade the network.
Do validators need to be publicly identified?
It is helpful to provide an entity name so that people are able to associate your validator with a known service or website (a DNS lookup will be required to ensure that the validator is the entity they claim to be) though there will be no public relationship between your entity name and Peer ID.
How do I upgrade my node to a new version?
Refer to our Upgrading Your Node section of the Testnet Onboarding Guide.
How does staking work?
Staking will not be active during the Testnet phase and as such details including incentives and slashing conditions will be touched on in future versions of this document.
What are the incentives to run a node?
Transaction fees. Arch-aware Dapps intake BTC as a fee payment for instructions processed by the Network. These BTC fees are converted to Arch token which are distributed amongst the Arch validator pool as an incentive for dedicating their compute resources to the network.
A breakdown about the math behind this distribution and fee structure will be covered in future versions of this document.