# General Concepts

# What is a validator?

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.

# What is 'staking'?

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'.

# What is a full-node?

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.

# What is a delegator?

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.

# How delegators ought to choose their 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 BIPs: Number of BIPs a validator self-bonded to its staking pool. A validator with higher amount of self-bonded BIPs has more skin in the game, making it more liable for its actions.
  • Amount of delegated BIPs: Total number of BIPs 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.
  • 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. Validators will need to build reputation one way or another to attract delegators.

# Responsibilities

# What are the responsiblities of a validator?

Validators have one main responsibility:
  • 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.

# What does staking imply?

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.

# Can a validator run away with its delegators' BIPs?

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.

# How often will a validator be chosen to propose the next block? Does it go up with the quantity of BIPs staked?

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.

# Incentives

# What is the incentive to stake?

Each member of a validator's staking pool earns different types of revenue:
  • Block rewards: For the Minter test network, block rewards are paid in MNTs.
  • Transaction fees: The Minter maintains a whitelist of token that are accepted as fee payment. 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.

# What is a validator's commission?

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%.

# How are block rewards distributed?

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:

  • 333BIPs as block reward
  • 10 BIPs as transaction fees.

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:

  • Commission = 10% * 80% * 27.44 BIPs = 2.744 BIPs
  • Validator’s revenue = 20% * 27.44 BIPs + Commission = 8.232  BIPs
  • Delegators’ total revenue = 80% * 27.44 BIPs - Commission = 19.208 BIPs

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.

# What are the slashing conditions?

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:

  • 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 12 blocks, 1% of stake will get slashed and validator will be turned off

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.

# Do validators need to self-bond BIPs?

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.