Tezos Staking: Baker Metrics Overview

On the TzKT bakers list, you can find a complete list of Tezos bakers that you can filter and sort according to your preferences. Here are descriptions of the displayed baker criteria (metrics), as well as the formulas used to calculate these metrics.

Bakers metrics on Baking Bad

Insurance

This field indicates whether the Tezos baker is insured by Baking Bad or not. Insurance means that all the delegators (clients) of that baker will be compensated for any baker’s fault. The most common use cases are:

  • if the baker stops paying (becomes a scammer), Baking Bad keeps paying staking rewards from the insurance deposit for the next ~12 cycles (depending on baker’s payout delay setting);
  • if the baker misses blocks and endorsements and his node performance is below 90%, then Baking Bad compensates the losses;
  • if the baker suddenly changes his terms (e.g. increases fee) without notifying at least ~12 cycles before, Baking Bad compensates for the difference in staking rewards using the old fee value for the next ~12 cycles (depending on baker’s payout delay setting).

So in other words, delegators of the insured baker will never lose their rewards, and in case of any misbehavior they will have enough time to safely change the Tezos baker. See more details about Baking Bad insurance here.

The numbers indicate how much losses the insurance deposit covers. For example, if you see a green checkmark, then delegators will be compensated for all losses, but if you see “50”, then only for half of the losses, since the insurance deposit isn’t large enough.

Staking

This is the Tezos baker’s staking balance, which includes his own XTZ funds (bonds) and all the delegated funds. This value is taken right from the blockchain and actually indicates how large the Tezos baker is and how often he will get the rights to produce and confirm blocks.

In the long run there is no fundamental difference between Tezos bakers with large or small staking balances. But in the short term, you can see that large Tezos bakers have more “stable” staking rewards from cycle to cycle (like +22tez, +23tez, +21tez), and small bakers have less “stable” staking rewards (like +10tez, +5tez, +51tez). This happens due to the randomness in the distribution of baking rights in Tezos, which means the more rolls, the less variance, and the less rolls, the more variance. More info about rights distribution in Tezos docs.

var stakingBalance = (ownBalance - frozenRewards) + delegatedBalance; //yes, without frozen rewards

Free space

This is how much XTZ you can delegate to the baker. A negative value indicates that the baker is likely overdelegated, which is very unwanted as he will miss blocks and endorsements.

What is “overdelegation” and why does a baker have limited staking capacity?

Each time a baker produces a new block or confirms an existing block, a certain amount of his own bonds are blocked for 5 cycles as a security deposit. If the available XTZ balance is not enough (because the entire balance has already been blocked), the baker skips block/endorsement. That’s not good.

That’s why Tezos bakers should control their staking balance because if it is too large, they receive too many baking rights which cannot be covered by their bond. As a result, they miss blocks.

Here is our approach to estimate Tezos baker’s capacity (this is the right way to get stakingCapacity and freeSpace values):

//protocol constants
var blockSecurityDeposit = 640; //tez
var endorsementSecurityDeposit = 2.5; //tez
var endorsersPerBlock = 256;
var preservedCycles = 5;
var blocksPerCycle = 8192;
var tokensPerRoll = 8000; //tez

//how much tez can be locked in total (by all bakers) as a security deposit
var totalLocked =
        (blockSecurityDeposit + endorsementSecurityDeposit * endorsersPerBlock) * blocksPerCycle * (preservedCycles + 1);

//how much of that the baker can cover with his balance
var bakerBalance = ...;
var bakerShare = bakerBalance / totalLocked;

//number of rolls, participating in staking
var allBakers = [...];
var totalRolls = 0;
foreach (var baker in allBakers)
    totalRolls += baker.rolls;

//how many rolls and staking balance the baker should have in order to lock the whole balance
var bakerRollsCapacity = totalRolls * bakerShare;
var bakerStakingCapacity = bakerRollsCapacity * tokensPerRoll;

We’ve just calculated the staking capacity, but keep in mind that we’ve got the expectation, not the exact value. It’s impossible to get a 100% accurate value due to randomness in Tezos, so sometimes it can be a little less, sometimes a little more.

Therefore we give bakers the maxStakingThreshold setting (aka overDelegationThreshold in Bakers Registry) to control the displayed freeSpace value. For example, if the baker wants to ensure he will never miss a block due to overdelegation, he can set maxStakingThreshold = 0.8, so that the displayed value will be 20% less than the expectation. On the other hand, maxStakingThreshold = 1.3 will indicate that the baker is ready to increase his bonds on-demand and wants to show greater value. So, the resulting formulas are:

var maxStakingBalance = bakerStakingCapacity * maxStakingThreshold;
var freeSpace = maxStakingBalance - currentStakingBalance;

Fee

This is how much the Tezos baker charges from the staking rewards he distributes between his clients (delegators). The displayed value is relevant for the cycle current + 7 instead of the current one because if you delegate to the baker right now, you will appear in his delegators list and your balance will participate in Tezos staking only after 2 + preservedCycles = 7 cycles.

It may seem that the lower the fee the greater the profit, and in most cases it’s true, but you should also take into account the following factors:

  • if the baker has a low fee, but pays XTZ inaccurately or even misses payouts, it doesn’t make any sense;
  • if you see a low fee, this may be just a discount (promotion) period;
  • if you see a low fee, this doesn’t mean that it won’t change;
  • Tezos bakers change fees quite often, so you should constantly monitor updates.

Therefore, pay attention to other metrics as well.

##Min delegation

Many bakers have a minimum delegation amount requirement, below which they do not pay rewards. Ensure that your delegation is bigger than this amount, otherwise you wouldn’t get any rewards from it.

First payout

This column shows when baker starts to pay to its delegate. Standart payout delay is 12 cycles, which is equal to 37 days. Some bakers prefers to pay its delegates in advance, before actual rewards will be accrued to the bakers account and get unfrozen.

Payout amounts

This value indicates how accurate the baker’s payouts are. There are four possible options:

  • precise - payout amounts are equal to the expected ones and everything’s fine;
  • inaccurate - payout amounts are NOT equal to the expected ones (delegators are underpaid or overpaid);
  • suspicious - a warning that the baker has missed recent payouts, and you should be careful;
  • no data - not enough data to determine payout accuracy (baker is closed, dead, or new and doesn’t have payment history yet).

Here are several code snippets used to calculate expected and received payouts:

var delegatorBalance = ...; //delegator's balance on the specific cycle (from the snapshot)
var bakerStakingBalance = ...; //baker's staking balance on the specific cycle (from the snapshot)
var bakerCycleRewards = ...; //how much the baker earned for the specific cycle
var bakerFee = ...; //baker's fee on the specific cycle

//expected payout, aka delegator's reward for the specific cycle
var expectedPayout = Math.Round(delegatorBalance / bakerStakingBalance * bakerCycleRewards * (1 - bakerFee), 6);

var bakerChargesTxFee = true;
var bakerChargesAllocationFee = false;
var paymentTransactions = [...];

//how much delegator received from the baker for the specific cycle
var receivedPayout = 0;
foreach (var tx in paymentTransactions)
{
    receivedPayout += tx.Amount;
    if (bakerChargesTxFee) receivedPayout += tx.Fee;
    if (bakerChargesAllocationFee) receivedPayout += tx.AllocationFee;
}

var isAccurate = receivedPayout == expectedPayout;

Notes:

  • This metric is calculated based on a randomly picked delegator (changes every few weeks);
  • Inaccurate payouts often mean rounding issues, in that case, if some delegator is overpaid then the other one is underpaid;
  • Tezos bakers who do care about math (i.e. remain precise) are likely to care much about other staking aspects too.

Payout period

This value indicates whether the baker pays according to his payment schedule or not. There are four possible options:

  • stable - baker pays on time, everything’s fine;
  • unstable - baker pays unpredictable: sometimes later, sometimes earlier;
  • suspicious - a warning that the baker has missed recent payouts, and you should be careful;
  • no data - not enough data to determine payout timing (baker is closed, dead, or new and doesn’t have payment history yet).

Notes:

  • This metric is calculated based on a randomly picked delegator (changed every few weeks);
  • Several exotic schemes (e.g. payouts made once a month or on-demand) are also marked as unstable;
  • Punctual Tezos bakers (which remain stable) are likely to care much about other baking aspects too.

Latest voting

This is how the baker participates in the voting process (Tezos on-chain governance).

The voting process consists of four steps/periods:

  1. proposal - bakers upvote proposals (one or multiple) pushed by other bakers/developers which contain protocol improvements.
  2. exploration - bakers vote for or against testing the selected proposal (the most upvoted one).
  3. testing - bakers run the proposal on the test chain to determine whether everything’s working properly.
  4. promotion - bakers vote for or against applying the proposal to the mainnet.

As you can see there are three “active” periods when Tezos bakers have to ballot: proposal, exploration, promotion. That’s why you see three slots/icons in the voting column - they correspond to those three active voting periods. There are four possible options for every period:

  • thumb up - baker voted Yay (or upvoted the proposal);
  • thumb down - baker voted Nay;
  • right chevrons - baker said Pass (or skipped the proposal period);
  • exclamation mark - baker didn’t participate at all.

Notes:

  • Tezos bakers who are actively involved in the governance are thus committed to the growth and prosperity of the Tezos network. These bakers are also more likely to be interested in long-term operation.
  • If a baker votes Nay, this definitely doesn’t mean that he is a bad guy. Each vote is good, as it reflects the personal opinion. The more different points of view, the more valuable the voting result.