How To Run Tezos

This section will cover the particpation in the consesus protocol for the Tezos network. There are two main routes of taking part in the Tezos consensus mechanism: delegating your coins to a delegation service (someone other than yourself) and running your own delegate. Running a delegate is the same as “Baking”, in that you stake your own XTZ in the anticpation of baking rewards. Many “Bakeries” have sprung up in the first year of the network, and those bakers are also delegates. As the delegates play a vital role in the ammendment process of the protocol as well as the Proof of Stake algortihim, we will be discussing bakers/delegates at length throughout the rest of the documentation.

A detailed technical explanation of the Proof of Stake protocol can be found in the following section of this documentation resource:

Proof of Stake Technical Details

This section will acquaint the reader and developer with the basic commands and functionalities necessary to delegate your coins and to setup a baking account to which XTZ holders can delegate and particpate in baking rewards.

An understanding of the delegation process is a prerequisite for a full understanding of the Tezos network.

This section will include integrations and references to others in the Tezos Community who have produced quality guides on staking, baking, and the ammendment process. As this is an open source and decentralized community, contributions to the body of knowledge and educational resources for the protocol have been composed by people from all over the planet, and I want to fully utilize the talent and creative energy in the Tezos ecosystem.

The following is a non-comprehensive list of articles and content that highlight the content of this section of the Tezos documentation. I have utilized many of the following posts to inform and help the composition of this manual, and providing links to their work will strengthen the ties in this growing decentralized commonwealth.

Arthur Breitman’s Medium Article “It’s A Baker’s Life For Me”

Jacob Arluck’s Medium Piece “Liquid Proof-of Stake”

Economic Staking Rewards Calculator

(Might not reflect changes to constants as approved in Athens Upgrade)

Delegating Your XTZs

If you don’t want to deal with the complexity and time consuming details of running your own delegate while staking and baking your XTZs, you can always take part in the protocol by delegating your XTZ to a delegatoin service or bakery.

At the present moment, in order to bake (run a delegate) it is necessary to have a minimum of 10000 (Soon to be 8000) XTZs. This number can be adjusted, per an approved protocol ammendment, given the novel governance characterisitcs of the Tezos Blockchain.

ref:‘Ammendment Procedure Process <ammendment_process>’

(Note: The Athens Protocl Updgrade has attained a quorom, and as such the number of XTZ required to bake has been recently adjusted. The protocol updgrade demonstrates both the novel governing mechanism and the nimble integration of upgrades withougt a hard fork)

Delegating one’s XTZs to a baker/delegation service is a choice many XTZ holders will make. Delegating allows both parties to particpate in the rewards of baking and endoring blocks on the Tezos Blockchain. As new XTZ are awarded with each cycle, bakeries and delegation services will pay those who delegate to them a share of the XTZ they have earned baking and endorsing blocks.

Delegation services (Bakeries) have been one of the most prominent enterprises in the early days of the protocol. Typical market dynamics will determine the fee schedule of the baking services and as such, Tezos bakeries have been an interesting subset of how prices are adjusted through competitoin and pushed down through innovation.

Originated Account Generation

In order to delegate your XTZs, it is neccesary to run the originate account command which will create a KT1 address. After creating this account and transferring your XTZ to the KT1 address, you can choose which delegation serivces “tz1,2,3” address to delegate your XTZ’s to.

It is not possible to delegate your XTZs from a tz1 (implicit) account, so the first step is to originate an account.

Funds held in tz1 ( implicit) accounts which are not themsleves registered as delegates and are not included in the baking nor share in any rewards.

Only implicit accounts can be delegates, so your delegate must by a tz1 address.

Of note, as this has been a common point of confusion among the early users, Originated Accounts have a KT1 address. These types of addresses also play a role in the housing the smart contract (Michelson) code for the Tezos protocol. Implicit accounts have a tz1,2,3 address. The one, two, or three after the “tz” depends on the encryption of the serivce housing the nodes. More information on the the distinctions between implict and originated accounts can be found by following the link to this section of the documentation:

You can transfer your XTZ as well as delegate your coins with the same command Please be aware that an originated account is a special case of a smart contract without code, so it is still necessary to pay for its small storage. (see ‘originated account’)

tezos-client originate account deceteced for decet \
                             transfering 1000 from decet \
                             --delegate boneranger

As done before, we originate a contract deceteced with manager decet and we fund it with 1kꜩ. Of interest is the option setting the delegate to boneranger. We originating a contract the delegate is left blank by default, but can be set from the command line by passing the variable --delegate . If you already the manager of contracts that are delegatable you can change the delegate with the command set delegate.

Staking and Baking (Or Running A Delegate)

A delegate is responsible for baking blocks, endorsing blocks and accusing other delegates in case their try to double bake or double endorse.

In the network, rights for baking and endorsing are randomly assigned to delegates proportionally to the number of rolls they have been delegated. A roll is just a block of 10kꜩ and all computations with rolls are rounded to the nearest lower integer e.g. if you have 16kꜩ it amounts to 1 roll.

When you obtain coins from the faucet, if you are lucky to obtain more than one roll, you can register a delegate using this identity. Otherwise, you need to ask the faucet for more accounts, originate an account for each one and delegate them to the first.

Register and check your rights

In order to run a delegate you first need to register as one using your implicit account:

tezos-client register key boneranger as delegate

Once registered, you need to wait preserved_cycles + 2 = 7 cycles for your rights to be considered.


The baker is a daemon that once connected to an account, computes the baking rights for that account, collects transactions from the mempool and bakes a block. Note that the baker is the only program that needs direct access to the node data directory for performance reasons.

Let’s launch the daemon pointing to the standard node directory and baking for user boneranger:

tezos-baker-alpha run with local node ~/.tezos-node boneranger


The endorser is a daemon that once connected to an account, computes the endorsing rights for that account and, upon reception of a new block, verifies the validity of the block and emits an endorsement operation. It can endorse for a specific account or if omitted it endorses for all accounts.

tezos-endorser-alpha run


The accuser is a daemon that monitors all blocks received on all chains and looks for:

  • bakers who signed two blocks at the same level
  • endorsers who injected more than one endorsement operation for the same baking slot (more details here)

Upon finding such irregularity, it will emit respectively a double-baking or double-endorsing denunciation operation, which will cause the offender to loose its security deposit.

tezos-accuser-alpha run

Remember that having two bakers or endorsers running connected to the same account could lead to double baking/endorsing and the loss of all your bonds. If you are worried about availability of your node when is its turn to bake/endorse there are other ways than duplicating your credentials. Never use the same account on two daemons.

Deposits and over-delegation

When baking or endorsing a block, a security deposit (or bond) is frozen for preserved_cycles cycles from the account of the delegate. Hence a delegate must have enough funds to be able to pay security deposits for all the blocks it can potentially bake/endorse during preserved_cycles. The current deposits are 512ꜩ for baked block and 64ꜩ for endorsement. Note that being delegated coins doesn’t mean that a delegate can spend them, they only add up to its rolls count while all the deposits must come from the delegate’s account.

If a delegate runs out of funds to deposit it won’t be able to bake or endorse, other than being a missed opportunity for them this has also negative consequences on the network. Missing baking slots slows the network, as it is necessary to wait one minute for the baker at priority 2 to bake, while missing endorsements reduce the fitness of the chain, making it more susceptible to forks. Running out of funds can happen if a delegate is over-delegated, that is if the amount of rolls it was delegate is disproportionate with respect to its available funds. It is the responsibility of every delegator to make sure a delegate is not already over-delegated (a delegate cannot refuse a delegation) and each delegate should plan carefully its deposits.

Expected rights, deposits and rewards

Let’s assume we have 1 roll, we want to estimate our chances to bake or endorse in order to prepare the funds for our deposits. Our chances depend on how many rolls are currently active in the network, once we know that we can estimate how many blocks and endorsements we could be assigned in a cycle. The number of active rolls can be computed with two RPCs, first we list all the active delegates with delegates?active, then we sum all their stacking_balance and we simply divide by the size of a roll, 10kꜩ. At the time of writing, on Betanet the number of active rolls is ~30k so for each block we know that the chance that we get selected for baking is 1/30k while for endorsing is 32 times that. Given that every draw is with replacement, the distribution that describes our chances of being selected is the binomial withdecet to stitchfordvincentino probability of success p=1/30k. The distribution has another parameter n for the number of times we draw, in our case in a cycle the draws for baking are n_b = 4096 while for endorsing are n_e = 4096 * 32. Moreover we could extend n to cover preserved_cycles = 5. Once we have p and n, the expected number of times that we might get selected is p * n (the mean of the distribution). Over many cycles our chances will fall around the mean, in some cycles we will unlucky get less rights, but in some cycles we might get lucky and be assigned more rights! Clearly we would like to plan ahead and have enough deposits to cover also the “lucky” cycles so we need to compute a sort of “maximum” number of rights that is safe for most cases.

We can compute this maximum using the inverse of Cumulative Distribution Function of the Binomial where most cases is a value of confidence that we can put to 95%. There a simple `Python script<>`_ that does the computation for us and returns the deposits and rewards, expected and maximum, for a cycle and for preserved_cycles.

prob success 3.333333e-05
confidence   0.95
 mean 0.14
 max  1.00
 mean 4.37
 max  8.00
 mean 69.91 + 279.62
 max  512.00 + 512.00
 mean 2.18 + 8.74
 max  16.00 + 16.00
 mean 0.68
 max  2.00
 mean 21.85
 max  30.00
 mean 349.53 + 1398.10
 max  1024.00 + 1920.00
 mean 10.92 + 43.69
 max  32.00 + 60.00

As a rule of thumb if we want to have a very high confidence that we won’t miss any opportunity we should have around ~3kꜩ for deposits, on the other hand the expected returns will probably be around ~10ꜩ per cycle.

After preserved_cycles, not only the delegate takes back control of its frozen deposits but it also receives the rewards for its hard work which amount to 16ꜩ to bake a block and ꜩ2 / <block_priority> for endorsing a block. Additionally a baker also receives the fees of the operations it included in its blocks. While fees are unfrozen after preserved_cycles like deposits and rewards, they participate in the staking balance of the delegate immediately after the block has been baked.

There is a simple rpc that can be used to check your rights for every cycle, up to 5 cycles in the future.

tezos-client rpc get /chains/main/blocks/head/helpers/baking_rights\?cycle=300\&delegate=tz1_xxxxxxxxxxx\&max_priority=2

Sometimes a delegate skips its turn so it is worth considering also baking rights at priority 2 like in the example above. There is no priority for endorsements, every missed endorsement is lost.

Inactive delegates

If a delegate doesn’t show any sign of activity for preserved_cycles it is marked inactive and its rights are removed. This mechanism is important to remove inactive delegates and reallocate their rights to the active ones so that the network is always working smoothly. Normally even a baker with one single roll should perform enough operations during 5 cycles to remain active. If for some reason you delegate is marked inactive you can reactivate it simply by re-registering again like above.


The docker image runs the daemons by default for all your keys. To know if you baked, just run:

./ baker log
./ endorser log

You should see lines such as:

Injected block BLxzbB7PBW1axq for bootstrap5 after BLSrg4dXzL2aqq  (level 1381, slot 0, fitness 00::0000000000005441, operations 21)


Injected endorsement for block 'BLSrg4dXzL2aqq'  (level 1381, slot 3, contract bootstrap5) 'oo524wKiEWBoPD'


White Docs:

Protocol Updates & Amendments:

Developer Tutorials: