Tempus Fugit — Understanding Cycles, Snapshots, Locking and Unlocking Periods in the Tezos Protocol

Today’s article has been triggered by the community asking us via email and via our Telegram group questions regarding the concepts of cycles, snapshots, locking and unlocking periods (preserved cycles). Even if most of the questions related to time are of especial interest to delegators, the following sections will not only define basic concepts related to what time means for the Tezos Protocol, but also illustrate what implications they have for both bakers and delegators. As the title says, tempus fugit, let’s dig right into it.

Note: There is a summary at the end. Jump right to the bottom if you’re not too interested in the details of the Tezos Protocol.

Zug Clocktower — by Raphael Sommer

What are Cycles?

A cycle in the Tezos Protocol is a way of measuring time. Just as the documentation specifies, every cycle equals to 4,096 blocks. Normally, it can become a bit unintuitive to measure time by blocks or cycles instead of commonly used units such as minutes, hours or days. Furthermore, the time it takes for every block to be produced is not a constant value, it varies.

There are some values that are prefixed by the protocol: the time between blocks is at least 1 minute. This means that, in the most optimistic scenario, a cycle will last 4096 minutes, which is equal to 2 days, 20 hours and 16 minutes. Ever since the betanet launch, on the 30th of June 2018, we can see that the time between blocks has varied slightly day after day.

The graphs below show the average delay between blocks July, August, and September 2018:

As we can see, in most cases, the time between blocks is > 60 seconds. There was one, day the 2018-07-22 where a total of 1440 blocks were produced, making the average time between blocks exactly 60 seconds. There were a couple of outliers, for example on 2018-07-11 the average time between blocks was 103.97 seconds. Considering the data from 30th of June until 16th of October, the average time between blocks has been ~63.19 seconds.

It is commonly said that a cycle lasts 2–3 natural days. A more accurate statement would be that a cycle lasts at least 2 days, 20 hours and 16 minutes but could, theoretically, last an undefined number of days, or whatever it takes for the network to produce 4096 blocks. If we would take the average time of 63.19 seconds per block:

63.19 * 4096 = 258,826.24 (258,827)
258,827 Seconds = 2 days, 23 hours, 53 minutes and 47 seconds

A cycle would take 2 days, 23 hours, 53 minutes, which is slightly higher than the most optimistic case.

*Source: The datasets I used for making the calculations and plots was retrieved from TzScan.

What are Snapshots?

More precisely, roll snapshots are records of the state of rolls distribution at a specific block height, which shows how many rolls every baker represents in relation to the total rolls (1 roll = 10,000 XTZ).

Rolls distribution is a dynamic value, highly susceptible to change, for instance, every time 10,000 XTZ are delegated or changes baker. However, snapshots are taken every 256 blocks or 16 times per cycle.

When do new delegations start contributing to bakings and endorsements?

Roll snapshots are relevant to understand because they are tightly related to baking and endorsing rights:

The right to publish a block in cycle n is assigned to a randomly selected roll in a randomly selected roll snapshot from cycle n - PRESERVED_CYCLES — 2

PRESERVED_CYCLES is currently 5. To break down the previous sentence, let’s use an example:

• Imagine we are planning to assign the baking rights of a block in cycle 21. In order to find out which baker should receive the highest priority for baking such block, we will need to consider all the snapshots from cycle 21 — 5 — 2 = 14. We would randomly select a snapshot from that cycle, one of the 16 made, and from the selected snapshot we would randomly chose a roll. The baker representing that roll is the baker who receives the highest priority to bake the block.

In other words, newly made or changed delegations will be considered, the earliest, for baking and endorsement slots in 7 cycles from the cycle the delegation was made or modified.

Why are Snapshots taken every 256 blocks?

According to the documentation, this frequency has been chosen to avoid two issues:

• Taking snapshots too frequently would cause an excessive memory consumption, as every validating node needs to store these records.
• Taking snapshots too infrequently would open the possibility for buyers to benefit from baking slots and its rewards, without been exposed long-term to the token, by buying before a snapshot and selling after the snapshot.

For illustration, let’s imagine that snapshots are taken every 6 months. A very witty crypto enthusiast named Thurar wants to make some profit using baking services, but he does not want to own XTZ, as he is skeptical about the network overall.

Thurar, knowing that the next snapshot will be taken in 1 day, buys 100,000 XTZ and delegates to a baker named Liptium Crabs. The next day, the snapshot happens, which includes Thurar’s 10 rolls. Right after the snapshot, he sells the 100,000 XTZ:

Assuming that the variation of prices varies very little within one day, Thurar is now entitled to the rewards proportional to those 10 rolls in relation to the total staked of the Lyptium Crabs, without being exposed to the value of XTZ for the remaining 179 days.

Nonetheless, such behaviour is still possible with the current frequency of snapshots of every ~4 hours. However, buying and selling every snapshot is significantly more inconvenient than in the previous case. As mentioned before, there are 16 snapshots per cycle, which means that if Thurar sells the 100,000 XTZ right after one snapshot during that cycle is taken, there is a 1/16 chance of this snapshot(that includes Thurar’s rolls) being selected for baking rights.

On the other hand, selling at the end of the cycle would mean that Thurar has been exposed to the value of XTZ for 2–3 days. In order to produce substantial rewards from baking without risk, Thurar needs to continuously expose himself to the asset for many cycles.

In conclusion, taking snapshots more or less frequently causes a tradeoff between memory consumption and convenience for risk-free baking.

What are Locking and Unlocking Periods?

The words locking and unlocking are synonyms to the words freezing and unfreezing which are part of the Tezos official terminology. In Cryptium Labs we use the first two to describe the periods in which security deposits or rewards are out of reach.

Security deposits being locked/unlocked is especially relevant to bakers. When the time for baking comes, 512 XTZ are automatically moved from the baker’s balance to its associated security deposit account. When an endorsing slot comes, 64 XTZ will be moved. After being added as a security deposit, those funds will be frozen for 5 cycles or PRESERVED_CYCLES. After that time, they will be moved back to the baker’s account. A continuously active baker, who naturally receives slots every cycle, would constantly have its security deposits for bakings and endorsements sent back to the associated security deposit account.

Especially relevant to delegators, the 5 cycles also apply to the rewards related to bakings and endorsements. Rewards that are generated in every cycle and unlocked after 5 full cycles will return to the baker’s main account, from where it will be the baker’s responsibility to distribute it to its delegators according to the service terms.

For example, let’s say Leenkath has 100,000 XTZ and wishes to delegate to the baker Lyptium Crabs. Leenkath makes the delegation during cycle 21. Knowing how baking and endorsement rights are assigned, following the formula n - PRESERVED_CYCLES — 2 resulting in the cycle from which the snapshots are taken:

# we are interested in knowing when the delegation made in cycle 21 was snapshoted:
n - PRESERVED_CYCLES - 2 = 21
n - 5 - 2 = 21
n = 28

Leenkath’s delegation rolls will start contributing to baking and endorsing slots in cycle 28 (7 cycles from the cycle the delegation was made, ~21 natural days).

In the case of bakers that have few rolls, there could be cycles where there would be no bakings or endorsements. But let’s assume that Lyptium Crabs has enough rolls they receive baking and endorsement rights for every cycle.

Following the example above, Leenkath’s delegation contributed to the bakings and endorsements of cycle 28, she is now eligible for a portion of the total rewards generated in that cycle. For illustration:

# imagine that Lyptium Crabs earned after cycle 28:
20 * 16 = 80 XTZ (total bakings, no fees)
60 * 2 = 120 XTZ (total endorsements)
Total earnings = 200 XTZ

The earnings of 200 XTZ were generated at the end of cycle 28. However, they are not transferred to Lyptium Crab’s main account yet, they are instead locked for 5 cycles (~14 natural days), together with the security deposits that were transferred to secure each baking and endorsing slot.

Once PRESERVED_CYCLES passes, in the following cycle, rewards will be transferred automatically to the baker’s main address and will be available for paying its delegators. If bakings were made in Cycle 28, they will be unlocked after cycle28 + 5 = 33, from the beginning of cycle 34, Lyptium Crabs has full access to the 200 XTZ generated in rewards. When should Leenkath check if she has received the rewards and how she is supposed to receive them? This depends on what service terms Lyptium Crabs has.

To finish with the example, this baker pays automatically to Leenkath’s KT1 address (the delegation) within the cycle the rewards are made available. So if Leenkath did not receive the rewards before the en of cycle 34, she should be reaching out to them!

Summary

In this article we clarified the following concepts:

• Cycles represent every 4096 blocks on the Tezos network, which equals to 4096 minutes (or 2 days, 20 hours and 16 minutes) in the best case, when the time between blocks is the minimum (1 minute). However, considering the data from the past months, the average time between blocks has been 63.19 seconds, making every cycle last 2 days, 23 hours and 53 minutes.
• Snapshots are records of the state of rolls distributions. Snapshots are currently taken 16 times per cycle or every 256 blocks (~ 4 hours). They are necessary to facilitate the assignment of baking and endorsement rights. Regardless of rolls distribution being highly subjective to change after every new or change of delegations, the current frequency of snapshots has been determined taking the tradeoff between memory consumption and convenience for risk-free baking into consideration.
• n — PRESERVED_CYCLES — 2 allows you to find out in which cycle, in the most optimistic case, a newly made delegation or change of baker of an existing delegation will be considered for the assignment of baking and endorsement rights. In the example used above, a delegation was made on cycle 21. Following the formula n — 5 — 2 = 21 gives n = 28, so a delegation made during cycle 21 will start contributing the earliest on cycle 28. In short, it at least 7 cycles (~ 21 days) for the delegation to be considered.
• Locking periods refer to the time security deposits for bakings and endorsements, and rewards generated in a cycle are frozen. Also known as PRESERVED_CYCLES, with the duration of 5 cycles (~14 days), security deposits and rewards are unmovable during that time. From the following cycle after the 5 cycles end, the security deposits and rewards are automatically transferred to the baker’s main account. Following the previous example, rewards generated in cycle 28 will be unlocked in cycle 34.