There is no minimum. The top 100 validator candidates with the highest total stake (where total stake = self-bonded stake + delegators stake) are the validators.
Delegators are free to choose validators according to their own subjective criteria. This said, criteria anticipated to be important include:
- Amount of self-bonded INJs: Number of INJs a validator self-bonded to its staking pool. A validator with a higher amount of self-bonded INJs has more skin in the game, making it more liable for its actions.
- Amount of delegated INJs: Total number of INJs delegated to a validator. A high stake shows that the community trusts this validator, but it also means that this validator is a bigger target for hackers. Indeed, hackers are incentivized to hack bigger validators as they receive a reward proportionate to the stake of the validator they can prove to have compromised. Validators are expected to become less and less attractive as their amount of delegated INJs grows.
- Commission rate: Commission applied on revenue by validators before it is distributed to their delegators
- Track record: Delegators will likely look at the track record of the validators they plan to delegate to. This includes seniority, past votes on proposals, historical average uptime and how often the node was compromised.
Apart from these criteria that will be displayed in the Injective UI, there will be a possibility for validators to signal a website address to complete their resume. Validators will need to build reputation one way or another to attract delegators. For example, it would be a good practice for validators to have their setup audited by third parties. Note though, that the Tendermint Team will not approve or conduct any audit itself.
No, they do not. Each delegator will value validators based on their own criteria. Validators will be able (and are advised) to register a website address when they nominate themselves so that they can advertise their operation as they see fit. Some delegators may prefer a website that clearly displays the team running the validator and their resume, while others might prefer anonymous validators with positive track records. Most likely both identified and anonymous validators will coexist in the validator set.
Validators have two main responsibilities:
- Be able to constantly run a correct version of the software: validators need to make sure that their servers are always online and their private keys are not compromised.
- Actively participate in governance: validators are required to vote on every proposal.
Additionally, validators are expected to be active members of the community. They should always be up-to-date with the current state of the ecosystem so that they can easily adapt to any change.
Validators and delegators on the Injective chain can vote on proposals to change operational parameters (such as the block gas limit), coordinate upgrades, as well as vote on amendments to the human-readable constitution that govern the Injective chain.
Validators play a special role in the governance system. Being the pillars of the system, they are required to vote on every proposal. It is especially important since delegators who do not vote will inherit the vote of their validator. Each time a validator does not vote on a proposal, it will get slashed by a minimal amount.
Staking INJs can be thought of as a safety deposit on validation activities. When a validator or a delegator wants to retrieve part or all of their deposit, they send an unbonding transaction. Then, INJs undergo a three weeks unbonding period during which they are liable to being slashed for potential misbehaviors committed by the validator before the unbonding process started.
Validators, and by association delegators, receive block provisions, block rewards, fee rewards, and the right to participate in governance. If a validator misbehaves, a certain portion of its total stake is slashed (the severity of the penalty depends on the type of misbehavior). This means that every user that bonded INJs to this validator gets penalized in proportion to its stake. Delegators are therefore incentivized to delegate to validators that they anticipate will function safely.
No. By delegating to a validator, a user delegates staking power. The more staking power a validator has, the more weight it has in the consensus and governance processes. This does not mean that the validator has custody of its delegators' INJs. By no means can a validator run away with its delegator’s funds.
Even though delegated funds cannot be stolen by their validators, delegators are still liable if their validators misbehave. In such a case, each delegators' stake will be partially slashed in proportion to their relative stake.
The validator that is selected to propose the next block is called proposer. Each proposer is selected deterministically, and the frequency of being chosen is equal to the relative total stake (where total stake = self-bonded stake + delegators stake) of the validator. For example, if the total bonded stake across all validators is 100 INJs and a validator's total stake is 10 INJs, then this validator will be chosen 10% of the time as the next proposer.
No, they do not. A validators total stake is equal to the sum of its own self-bonded stake and of its delegated stake. This means that a validator can compensate its low amount of self-bonded stake by attracting more delegators. This is why reputation is very important for validators.
Even though there is no obligation for validators to self-bond INJs, delegators should want their validator to have self-bonded INJs in their staking pool. In other words, validators should have skin in the game.
In order for delegators to have some guarantee about how much skin-in-the-game their validator has, the latter can signal a minimum amount of self-bonded INJs. If a validator's self-bond goes below the limit that it predefined, this validator and all of its delegators will unbond.
For now the community is expected to behave in a smart and self-preserving way. When a mining pool in Bitcoin gets too much mining power the community usually stops contributing to that pool. The Injective chain will rely on the same effect initially. In the future, other mechanisms will be deployed to smoothen this process as much as possible:
- Penalty-free re-delegation: This is to allow delegators to easily switch from one validator to another, in order to reduce validator stickiness.
- Hack bounty: This is an incentive for the community to hack validators. There will be bounties proportionate to the size of the validator, so that a validator becomes a bigger target as its stake grows.
- UI warning: Users will be warned by the Cosmos UI if they want to delegate to a validator that already has a significant amount of staking power.
Block provisions are distributed proportionally to all validators relative to their total stake. This means that even though each validator gains INJ with each provision, all validators will still maintain equal weight.
Let us take an example where we have 10 validators with equal staking power and a commission rate of 1%. Let us also assume that the provision for a block is 1000 INJs and that each validator has 20% of self-bonded INJs. These tokens do not go directly to the proposer. Instead, they are evenly spread among validators. So now each validator’s pool has 100 INJs. These 100 INJs will be distributed according to each participant’s stake:
- Commission: 100*80%*1% = 0.8 INJs
- Validator gets: 100*20% + Commission = 20.8 INJs
- All delegators get: 100*80% - Commission = 79.2 INJs
Then, each delegator can claim its part of the 79.2 INJs in proportion to their stake in the validator’s staking pool. Note that the validator's commission is not applied on block provisions. Note that block rewards (paid in Photons) are distributed according to the same mechanism.
If a validator misbehaves, its bonded stake along with its delegators' stake and will be slashed. The severity of the punishment depends on the type of fault. There are 3 main faults that can result in slashing of funds for a validator and its delegators:
- Double signing: If someone reports on chain A that a validator signed two blocks at the same height on chain A and chain B, this validator will get slashed on chain A
- Unavailability: If a validator’s signature has not been included in the last X blocks, the validator will get slashed by a marginal amount proportional to X. If X is above a certain limit Y, then the validator will get unbonded
- Non-voting: If a validator did not vote on a proposal and once the fault is reported by someone, its stake will receive a minor slash.
Note that even if a validator does not intentionally misbehave, it can still be slashed if its node crashes, loses connectivity, gets DDOSed, or if its private key is compromised. A complete document on the economics of the network will be published soon.
Each member of a validator’s staking pool earns different types of revenue:
- Block provisions: Native tokens of applications run by validators (e.g. INJs on the Injective chain) are inflated to produce block provisions. These provisions exist to incentivize INJ holders to bond their stake, as non-bonded INJ will be diluted over time.
This total revenue is divided among validators' staking pools according to each validator’s weight. Then, within each validator's staking pool the revenue is divided among delegators in proportion to each delegator’s stake. Note that a commission on delegators' revenue is applied by the validator before it is distributed.
Validators earn proportionally more revenue than their delegators because of commissions.
Validators also play a major role in governance. If a delegator does not vote, it inherits the vote from its validator. This gives validators a major responsibility in the ecosystem.
Revenue received by a validator’s pool is split between the validator and its delegators. The validator can apply a commission on the part of the revenue that goes to its delegators. This commission is set as a percentage. Each validator is free to set its initial commission, maximum daily commission change rate and maximum commission. The Injective Chain enforces the parameter that each validator sets. These parameters can only be defined when initially declaring candidacy, and may only be constrained further after being declared.