Based on the current parameters of the Cardano network, we can calculate how many slots (i.e. opportunities for blocks) a given pool is expected to receive per epoch (5 days), based on the size of the pool. But first, let’s introduce some of the basics behind how blocks are created:

The difference between slots and blocks

At the beginning of each epoch, slot leader election occurs (based on the stake snapshot taken in the previous epoch). During the election process, each pool is randomly elected for the chance to mint blocks on the Cardano blockchain by way of slots, which are specific times within the epoch that the pool has the opportunity to mint a block. In mainnet, there are 432,000 slots in an epoch (one per second). However, not every slot will have a leader, or chance to mint a block. This is referred to as active slots. Only 5% of slots are active, which means approximately 21,600 blocks (the actual number varies a small amount between epochs) will be minted per epoch. The number of slots a pool is elected for is based solely on the size of the pool.

This election process is not coordinated between pools, so there is a chance that two (or more) pools get elected to the same slot. This is called a slot battle. During the incentivized testnet (ITN), slot battles were won by whichever pool’s block was distributed to most of the network the quickest. This caused many pools to move their hardware to a central location (Frankfurt, Germany), in order to minimize their latency to the majority of the network and win more slot battles, which is obviously bad for decentralization. Thankfully, this process is changing for mainnet, where slot battles will be won by random chance.

Another way pools miss blocks is due to height battles. This occurs when two pools are scheduled to make blocks in two very close slots and one of them ends up getting skipped because there wasn’t enough time for the first block to propagate to the node building the second block. Similar to slot battles, height battles also drove location centralization of pool nodes during the ITN in order to minimize latency with other nodes. With slot time decreasing to 1 second and active slots decreasing to 5% this should be less of an issue in mainnet.

Calculating expected slots per epoch based on pool size

In order to calculate how many slots a pool of a given size should be expected to get per epoch, we’re going to have to do a little math. This value is determined by the following factors:

  • Total number of blocks per epoch, B: We established earlier, there are approximately 21,600 blocks minted per epoch.

  • The centralization factor, d: During the Shelley transition, the decentralization process is a slow handover from IOHK to pool operators. For the first epoch, pools will only mint 10% (2,160) of the total blocks (d = 0.9). As long as the transition runs smoothly, the d value will decrease by 0.02 (2%) every epoch until reaching 0% and full decentralization. You can find more information about this timeline here

  • Pool size, s: The amount of ADA staked in the pool during the snapshot taken in the previous epoch. For example, the pool size for Epoch 2 (the first epoch in mainnet that pools produce blocks) is based on the stake that was in the pool at the beginning of Epoch 1.

  • Total staked ADA, S: This is the total amount of staked ADA across all the pools.

To calculate the number of slots a pool should expect to get, we’re going to divide the total number of blocks created in an epoch between all the pools based on their size:

  • Expected slots, E = B * (1 - d) * s / S

To look at this equation another way, how big does a pool need to be to get elected for 1 slot per epoch? 5 slots? 10 slots? To answer this question, we solve the above equation for s:

s = (E * S) / (B * (1 - d))

Based on the snapshot for Epoch 211 (which happened at the beginning of Epoch 210):

s = (1 slot * 10.20 billion ADA) / (21,600 blocks * (1 - 0.9)) = 4.72 million ADA

This means any pool with less than 4.72 million ADA is likely to not get elected to any slots during an epoch. This does not mean they’ll never get any slots, or that you shouldn’t delegate to the pool - there will just be a high variance in your return.

Any pool over 66M ADA (as long as the k value is 500) is saturated and will receive reduced rewards. You should not delegate to saturated pools.

Important Notes

  • More blocks per epoch does not equate to higher return on stake (ROS). Pools of every size (as long as they are not saturated) will average the same ROS if they have perfect performance (not missing blocks due to server issues) and fees. A smaller pool will divide bigger shares of the reward amongst its stakers (since there are fewer of them), but they will statistically get chosen to produce less blocks. A larger pool will mint more blocks but payout smaller rewards. These both even out to the same reward for a delegator.

  • Slot election is a random process and can vary significantly if a pool gets a “lucky” or “unlucky” draw. If a pool gets drawn for more slots than expected on a given epoch, that does not mean they are better than a pool of the same size that got drawn for less slots.

  • Be aware when looking at ROS calculations based on a single epoch. ROS is an estimate of the percentage return on your staked ADA over an entire year. Calculating this based on a single epoch is wildly inaccurate due to the previous point. If a small pool that should be expected to get 1 slot actually drew 3 slots in their first epoch, their ROS could be three times higher (~15%) than you are actually likely to receive over a year. This is because there hasn’t been enough time for their random draws to even out to the expected return of around 5%.

  • You can’t increase your ROS by pool hopping. It takes two epochs for changes in your stake delegation to take effect. If your pool got a bad slot draw, you can’t leave and join another pool with a better draw and receive the awards.

  • Pools are going to miss blocks due to slot and height battles, through no fault of their own. As mentioned earlier, slot battles are determined by random chance in the mainnet, so there’s nothing a pool can do to increase their win rate. While pool performance is the most important metric to consider when choosing a stake pool, you must remeber that every pool is going to miss a block here and there due to slot battles. This is not the same as missing a block due to poorly managed pool hardware.

As always, let us know if you have any questions, comments, or suggestions. Also, check out our guide on Choosing a Stake Pool, as well as our staking tutorials for Daedalus and Yoroi wallets. If you have questions about staking or anything else related to Cardano, feel free to join our Telegram channel. Follow us on Twitter and Reddit to be notified of future posts!

The sources for our parameters came from the mainnet-config files and from this IOHK whitepaper. Pool distribution data was obtained from PoolTool

You May Also Enjoy