# Commitments and stakers ### Commitments: Because of the linear trversal costs, commitments are no longer automatically removed in case of failed games. They persist until it is time for their levels to be cemented. A commitment is [**cementable**](https://gitlab.com/tezos/tezos/-/blob/master/src/proto_alpha/lib_protocol/sc_rollup_stake_storage.ml#L578) if it is not dangling A commitment is **dangling** if either: - it has no predecesor - that is its predecesor has been removed from the storage but it is not the lcc, or - it has no stakers. ### Stakers Stakers can be identified by their address or by their `staker_index`. There are two storages: - `Storage.Sc_rollup.Staker_index` associates to an address (a `Signature.public_key_hash`) its `staker_index` (a `Z.t`) - `Storage.Sc_rollup.Stakers` associates to a `staker_index` (a `Z.t`) the ) the commitment staker is staked on. If this commitment is at lcc or earlier the stake can be withdrawn. Note that the `staker_index` is a *uuid* and at different times a certain address could have various `staker_index`. More precisely each time a staker is removed, both its address and `staker_index` are removed from storage. Each time a commitment is staked, a new `staker_index` is created and associated to the address that made this commitment. This has two advantages: * the id of a straker is an integer * if a staker is slahed at one point, that address can rejoin later with a different `staker_index`. ## [Cementation](https://gitlab.com/tezos/tezos/-/blob/master/src/proto_alpha/lib_protocol/sc_rollup_stake_storage.ml#L739): In order for a certain commitment be cemmented the following things happen: 1. the `assert_cement_commitment_met` checks the given commitment has the lcc as the predecessor and it is the only cementable commitment at that level. It also collects all the dangling commitments at that level. 2. If all goes ok, the commitment becomes the new lcc. 3. the storage is cleaned, that is the commitment and all the dangling commitments and their metadata are removed from storage. Note this might produce new dangling commitments, i.e. tag any commitment whose predecessor is currently dangling as a dangling commitment. 4. the "cemented commitments" storage is update TODO: the `assert_cement_commitment_met` should be refactored for efficiency. ## [Removing stakers](https://gitlab.com/tezos/tezos/-/blob/master/src/proto_alpha/lib_protocol/sc_rollup_stake_storage.ml#L765) If a staker is removed because of a game it lost, the commitments it is staked on are not removed but could possibly become dangling and then will eventually be removed when the time for cementation comes.