# Security deposit calculation

Could someone please lay out a precise calculation of the expected security deposit percentage as a fraction of the bakers staking balance ?

Some people say it’s 8.25% but it is likely to depend on the percentage of the network actually staking so it would be great to have a clear and plain answer here thank you!

Regarding the security deposit/bond requirement, it is explained on the tezos official documentation:

Security deposits¶ The cost of a security deposit is BLOCK_SECURITY_DEPOSIT = 512 XTZ per block created and ENDORSEMENT_SECURITY_DEPOSIT = 64 XTZ per endorsement. Each delegate key has an associated security deposit account. When a delegate bakes or endorses a block the security deposit is automatically moved to the deposit account where it is frozen for PRESERVED_CYCLES cycles, after which it is automatically moved back to the baker’s main account. Since deposits are locked for a period of PRESERVED_CYCLES one can compute that at any given time, about ((BLOCK_SECURITY_DEPOSIT + ENDORSEMENT_SECURITY_DEPOSIT * ENDORSERS_PER_BLOCK) * (PRESERVED_CYCLES + 1) * BLOCKS_PER_CYCLE) / 763e6 = 8.25% of all tokens should be held as security deposits. It also means that a delegate should own over 8.25% of the amount of token delegated to them in order to not miss out on creating any block.

This is where the “8.25%” number comes from. However it assumes a specific number of the total XTZ actively staking to be 763,000,000 which is not the actual situation.

You can also interpret this number as the security deposit of “the entire network” in some sense however this does not tell you accurately what is the capital requirement for an individual baker.

The actual number of xtz staking can be obtained in real time on tzstats here.

Currently the amount staking at height 313728 is 503,461,245.334 xtz.

Using that number the effective percentage of xtz that is needed as security deposit is roughly 12.5%.

Note also one more time that this number is just an expectation because the realized number depends directly on the number of rights that a baker is allocated from cycle to cycle and that number fluctuates randomly (with less variance as the number of rolls grows though) so the bond requirement fluctuates accordingly.

• good explanation. but what does it mean then if the number increased while a baker is running, until further xtz are secured that baker wont bake anymore? Then who and how it would be made sure continuous xtz are automatically flowing into baker account to match the current requirement? Commented Feb 19, 2019 at 15:15
• @kahmed please ask a new question and also make your question more clear. What is the « number » you are refering to ?
– Ezy
Commented Feb 19, 2019 at 15:23
• well, its exactly on this point so didn't wanna create a new thread. The number referring to "8.25" . say it fluctuated up to 10% then what would happen and the baker have to deposit more xtz to match it or can't bake? Also, not sure how you came up with 12.5%? Commented Feb 19, 2019 at 15:33
• @kahmed the deposit for a given specific baker is dependent on the number of baking rights as explained in the answer that’s it. It will not go « up or down » when the baking rights are allocated. The 12.5% is just the % obtained using 503m xtz instead of 763m xtz as explained in the answer.
– Ezy
Commented Feb 19, 2019 at 15:38
• so as a very first time baker assuming just a single right what I start with 512 xtz + 64 = 576? Commented Feb 19, 2019 at 16:20

Since Ithaca, Tezos has switched to the Tenderbake consensus algorithm so the accepted answer is no longer valid.

The frozen deposit represents 10% of the highest active stake during the last 7 cycles.

The active stake of a delegate during one cycle is the amount of tez with which it participates in consensus. In general, this corresponds to the delegate’s staking balance, that is, the sum of its own balance and the balance of all accounts delegating to it.

But the active stake can't go over 10 times the delegate’s own balance. Otherwise, there would not be enough funds available for the security deposit. When it does go over, the baker is said to be overdelegated.

The baker may also make it look like its own balance is lower by setting a deposits limit. Then, the active stake can't go over 10 times the deposit limit.

To make calculations for a given cycle, the protocol looks at balances from 6 cycles ago.

Example 1 (most common): a baker has 10k tez in its account and 30k tez delegated to it. The baker didn't set any deposit limit. Its active stake is 40k tez and its security deposit is 4k tez (which is 10% of 40k tez).

Example 2: an overdelegated baker has 10k tez in its account and 190k tez delegated to it. Its active stake is 100k tez (the extra 100k tez are not taken into account). Its security deposit is 10k tez (its entire balance).

Example 3: a baker has 10k tez in its account and 30k tez delegated to it. It has set its deposits limit to 20k tez. Its active sake is 20k tez and its security deposit is 2k tez.

A more rigorous explanation can be found in the Octez documentation.