The Minter is based on Tendermint, which relies on a set of validators to secure the network. The role of validators is to run a full-node and participate in consensus by broadcasting votes which contain cryptographic signatures signed by their private key. Validators commit new blocks in the blockchain and receive revenue in exchange for their work. They must also participate in governance by voting on proposals. Validators are weighted according to their total stake.
The Minter is a public Delegated Proof-Of-Stake (dPoS) blockchain, meaning that validator's weight is determined by the amount of staking tokens (BIPs) bonded as collateral. These BIPs can be staked directly by the validator or delegated to them by BIP holders.
Any user in the system can declare its intention to become a validator by sending a "declare-candidacy" transaction. From there, they become validator candidates.
The weight (i.e. total stake) of a candidate determines wether or not it is a validator, and also how frequently this node will have to propose a block and how much revenue it will obtain. Initially, only the top 16 validator candidates with the most weight will be validators. If validators double sign, are frequently offline or do not participate in governance, their staked BIPs (including BIPs of users that delegated to them) can be destroyed, or 'slashed'.
A full-node is a program that fully validates transactions and blocks of a blockchain. It is distinct from a light-node that only processes block headers and a small subset of transactions. Running a full-node requires more resources than a light-node but is necessary in order to be a validator. In practice, running a full-node only implies running a non-compromised and up-to-date version of the software with low network latency and without downtime.
Of course, it is possible and encouraged for any user to run full-nodes even if they do not plan to be validators.
Delegators are BIP holders who cannot, or do not want to run validator operations themselves. Through Minter Console, a user can delegate BIPs to a validator and obtain a part of its revenue in exchange (for more detail on how revenue is distributed, see What is the incentive to stake? and What is a validator's commission? sections below).
Because they share revenue with their validators, delegators also share responsibility. Should a validator misbehave, each of its delegators will be partially slashed in proportion to their stake. This is why delegators should perform due diligence on validator candidates before delegating, as well as spreading their stake over multiple validators.
Delegators play a critical role in the system, as they are responsible for choosing validators. Being a delegator is not a passive role: Delegators should actively monitor the actions of their validators and participate in governance.
Delegators are free to choose validators according to their own subjective criteria. This said, criteria anticipated to be important include:
Staking BIPs 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, BIPs undergo a 30-days 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 rewards, fee rewards, and the right to participate in governance (in future releases). 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 BIPs to this validator gets penalized in proportion to its stake. Delegators are therefore incentivized to delegate to validators that they anticipate will function safely.
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' BIPs. 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 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 BIPs and a validator's total stake is 10 BIP s, then this validator will be chosen 10% of the time as the next proposer.
Note that a commission on delegators' revenue is applied by the validator before it is distributed.
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. The Minter enforces the parameter that each validator sets. These parameters can only be defined when initially declaring candidacy.
Validator minter.stakeholder.space has commission rate equivalent 10%.
Block rewards are distributed proportionally to all validators relative to their total stake. This means that even though each validator gains MNTs with each provision, all validators will still maintain equal weight.
However, before this reward is distributed to delegators inside the staking pool, the validator can apply a commission. In other words, delegators have to pay a commission to their validators on the revenue they earn.
Lets consider a validator whose stake (i.e. self-bonded stake + delegated stake) is 10% of the total stake of all validators. This validator has 20% self-bonded stake and applies a commission of 10%. Now let us consider a block with the following revenue:
10% from this amounts going to DAO account.
10% from this amounts going to Minter Team.
As a result, 274.4 BIPs to be distributed among all staking pools.
Our validator’s staking pool represents 10% of the total stake, which means the pool obtains 27.44 BIPs. Now let us look at the internal distribution of revenue:
Then, each delegator can claim it's part BIPs in proportion to their stake in the validator's staking pool.
To be more friendly to our delegators, we've made revenue calculator. It can help you approximately estimate your future revenue, in case you will delegate to our Validator.
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 2 main faults that can result in slashing of funds for a validator and its delegators:
Note that even if a validator does not intentionally misbehave, it can still be slashed if its node crashes, looses connectivity, gets DDOSed, or if its private key is compromised.
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 BIPs, delegators should want their validator to have self-bonded BIPs 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 BIPs. If a validator's self-bond goes below the limit that it predefined, this validator and all of its delegators will unbond.