The consensus algorithm in Tezos is based on the proof-of-stake mechanism. Proof-of-stake means that participants in the consensus algorithm are chosen in function of their stake (the amount of tokens a participant has). The same mechanism is used in the Tezos governance.

If one does not have enough stake to participate on its own or does not want to set up the needed infrastructure, (s)he can use delegation. Therefore, in Tezos, it is the delegates that may participate in consensus. Delegates’ rights to participate are determined by a follow-the-coin strategy. This procedure is random, in that its result cannot be predicted too much in advance. The randomness is obtained from information already found on the blockchain. Thus, the procedure is also deterministic: delegates’ rights are uniquely determined from the random element.


A delegate is any implicit account registered as such by emitting a delegate registration operation.

Any accounts (implicit or originated) can specify a delegate through a delegation operation.

Any account can change or revoke its delegate at any time. However, the change only becomes effective after PRESERVED_CYCLES + 2 cycles. The value PRESERVED_CYCLES is a protocol constant.

A delegate participates in consensus and in governance with a weight proportional with their delegated stake, which includes the balances of all the accounts that delegate to it, and also the balance of the delegate itself.

Delegates place security deposits that may be forfeited in case they do not follow (some particular rules of) the protocol. Security deposits are deduced from the delegates’ own balance. Therefore delegates may be subject to over-delegation.

Active and passive delegates

A delegate can be marked as either active or passive. A passive delegate cannot participate in the consensus algorithm.

A delegate is marked as active at its registration.

A delegate becomes passive for cycle n when they fail to participate in the consensus algorithm in the past PRESERVED_CYCLES cycles, that is, in cycles n-1, n-2, …, n - PRESERVED_CYCLES.

Delegates’ rights selection

Tezos being proof-of-stake, the delegates’ rights are selected at random based on their stake. In theory, it would be possible to give each token a serial number and track the specific tokens assigned to specific delegates. However, it would be too demanding of nodes to track assignments at such a granular level. Instead, Tezos works with sets of tokens which are called rolls.


A roll holds TOKENS_PER_ROLL tokens. When tokens are moved, or a delegate for an account is changed, the rolls change delegate according to the following algorithm.

Each delegate has a stack of roll identifiers plus some “change” which is always an amount smaller than TOKENS_PER_ROLL. When tokens are moved from one delegate to the other, first, the change is used. If it is not enough, rolls need to be “broken” which means that they move from the delegate stack to a global, unallocated, roll stack. This is done until the amount is covered, and some change possibly remains.

Then, the other delegate is credited. First, the amount is added to the “change”. If it becomes greater than TOKENS_PER_ROLL, then rolls are unstacked from the global unallocated roll stack onto the delegate stack. If the global stack is empty, a fresh roll is created.

This preserves the property that if the delegate is changed through several transactions, the roll assignment is preserved, even if each operation moves less than a full roll.

The advantage of tracking tokens in this way is that a delegate creating a malicious fork cannot easily change the specific rolls assigned to them, even if they control the underlying tokens and shuffle them around.

Random seed

Each cycle n is associated with a random seed. The random seed for cycle n is a 256-bit number generated at the very end of cycle n-1 from nonces to which delegates commit during cycle n-2. One block out of every BLOCKS_PER_COMMITMENT can contain a commitment. A commitment is the hash of a nonce. The commitment is generated by the block proposer and is included in the block header.

The committed nonce must be revealed by the original block proposer during cycle n-1 under penalty of forfeiting the rewards and fees of the block that included the commitment. The associated security deposit is not forfeited.

A nonce revelation is an operation, and multiple nonce revelations can thus be included in a block. A reward SEED_NONCE_REVELATION_TIP is given for including a revelation. Revelations are free operations which do not compete with transactions for block space. Up to MAX_ANON_OPS_PER_BLOCK revelations, wallet activations and denunciations can be contained in any given block.

The seed for cycle n is obtained as follows: the seed of cycle n-1 is hashed with a constant and then with each nonce revealed in cycle n-1.

Slot selection

To return to the rights selection mechanism, we first introduce a new terminology, roll snapshot, to denote the stored (in the context) distribution of rolls for a given block. Roll snapshots are taken (and stored) every BLOCKS_PER_ROLL_SNAPSHOT blocks.

The delegates’ rights at a given level and for a particular role in the protocol are expressed in terms of slots that the delegate receives for that role. The slot owner is obtained by running a PRNG (pseudo-random number generator) with the following input:

  • the level

  • the role (a string)

  • the slot (a non-negative integer)

Let n be the cycle the level belongs to. The seed of the PRNG is the random seed associated with cycle n-PRESERVED_CYCLES. The PRNG first selects a snapshot from cycle n-PRESERVED_CYCLES-2 and then it selects a roll in the selected snapshot. The slot owner is then the roll owner.

Protocol constants

Protocols are parameterized by several parameters called protocol constants, which may vary from one protocol to another or from one network to another (for instance, test networks move faster). An example of a parameter is the number of tez constituting a roll. This number is given by the constant named TOKENS_PER_ROLL.

The list of protocol constants can be found in the API of the Constants module.

The values of protocol constants can be found using a specific RPC call, as shown in this example.

In particular, the protocol constants related to the proof-of-stake mechanism are detailed below.

Proof-of-stake parameters

Parameter name

Parameter value


8192 blocks


5 cycles


64 blocks


132 revelations


1/8 ꜩ


8,000 ꜩ


512 blocks

Further External Resources

The original design of the proof-of-stake mechanism in Tezos can be found in the whitepaper.

Another presentation of the Tezos’ proof-of-stake mechanism can be found in the Tezos agora wiki entry.