Cardano Expected Blocks per Epoch

Based on the current parameters of the Cardano Shelley network, we can calculate how many slots (and therefore, 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 of 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

Note: The values below are based on the snapshot values that will be used for rewards in Epoch 2. We will keep this post updated for the coming epochs as we near full decentralization.

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.1 (10%) each epoch until reaching 0% and full decentralization.
• 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 2 (which happened at the beginning of Epoch 1):

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

This means any pool with less than 2.81 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. To calculate how many slots a pool should get elected for, just divide the pool size by 2.81 million. Below are a few examples.

Expected slots given pool size for the parameters in the given example.

Any pool over 207 M (as long as the k value is 150) 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 (~13.8%) 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 4.6%.
• 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. If you have questions about staking through Daedalus, check out our staking tutorial. We also recommend you check out our Shelley summary post that walks through the events of the first few epochs of the Shelley launch.

The sources for our parameters came from the mainnet-config files and from this IOHK whitepaper.