In this chapter, we will dig deeper into the fees of the Tezos network and the baking and endorsing rewards. The calculations you'll learn about are helpful from the simplest transaction issuance to the most complex application built on Tezos. That is why it is important to understand the basics of fees and gas optimizations. Of course, this will be particularly useful if you are a baker or an endorser.
Each transaction on Tezos has a cost for the user. To account for this, the user must include a gas fee when submitting transactions. Bakers will then choose transactions using a minimal fee filter. If the baker chooses a transaction, he will add it to the block and propagate it. The fee is therefore used to pay the bakers. They are calculated by using the following formula :
- Minimal Fees:
- Size of the operation (in bytes ""):
(The size "" is the number of bytes in the complete serialized operation).
- Gas used for the operation (in gas unit ""):
- Minimal nano-tez per byte:
- Minimal nano-tez per gas unit:
Gas unit cost in Tez is defined by the protocol. It does not depend on the fee market; it does not depend on arbitrary defaults in config files; etc 
The transaction default values are:
In a Tezos operation, we can add additional information such as smart contracts deployment, smart contract call, etc. These have a storage cost which is represented in tez per byte. Since the Delphi update to the protocol  this minimal cost has been reduced from 1ꜩ to 0.25 ꜩ per kilobyte (250 µꜩ/B). The minimal price of creating a new account has thus been lowered from 0.257 tez to 0.06425 tez (the cost of creating an account is important to protect the system from spams and Sybil attacks ).
On the Tezos blockchain, gas refers to the cost necessary to perform a transaction on the network. Bakers set the price in gas based on supply and demand for computational power on the network (needed to process smart contract calls and other transactions).
Gas is used to determine the complexity of the transaction execution and also to avoid the risks of infinite loops. It is one of the main factors a baker considers before choosing transactions. Before including a transaction, the baker reviews the amount of gas required and its cost per unit. If this ratio is adequate, the baker selects the transaction.
Each Delphi transaction has a gas limit: 1,040,000 . If the contract execution, or deployment, exceeds this limit, the contract is considered unusable. This limit is useful to guarantee that the bakers will be able to validate the block in a limited amount of time . The gas limit may seem relatively low, but its value is a network's inclusion metric: any user should be able to run a node and bake a block within the allotted time. Even slow nodes can participate.
The Delphi update also increased the number of computation per unit of gas. The minimal amount of gas units to achieve operations has been reduced from 10,000 to 1,000. With this update, the execution cost of smart contracts decreased by approximately 75% . This evolution allowed more complex smart contracts' executions and was a demonstration of Tezos's adaptability.
Note that a baker also takes into account the gas limit per block. In Delphi, the limit is 10,400,000 (10 times the gas limit per operation). So, of course, it limits the number of transactions to include in a block. However, for the storage cost, it isn't a fee that rewards the baker. Actually, this particular fee is "burned", meaning nobody receives it.
Smart contract execution and optimization
There are two limits to take into account when developing a smart contract. The gas limit is an important parameter for the usability of the smart contract. But there is also a second major limit: each serialized operation has a maximum size of 16,384 bytes. It is, therefore, impossible to upload a smart contract bigger than this limit (origination).
One must account for these two variables to optimize a contract:
The gas consumption
Many options are possible . However, note that a large proportion of the gas is spent on the conversions from byte sequences to protocol-specific typed representations (and vice versa). These conversions can be:
- parsing of bytes
- checking the correctness of types
- conversion back to bytes
Follow this link for more details on the cost of gas.
The contract size
The formula below calculates an approximation of a contract's size:
An assumed constant value per instruction:
The number of instructions:
The sum of the sizes of all variable-size constants (strings, bytes) in the contract:
Then the contract's size "" is:
So, the size optimization comes down to decreasing the number of instructions and the variable-size constants. 
To maintain the network, Tezos needs bakers and endorsers. They stake their tokens and use their computing power to create blocks, manage transactions, vote, and secure the network. In exchange for these tasks, bakers are rewarded with a fee.
Since the Carthage update, the reward system has been updated to make the network more robust against non-cooperative baking strategies.
When a baker bakes a block, he receives a reward composed of all the transactions fees contained in the block in addition to a network reward computed by the following formula:
"": the number of endorsements the block receives
32 endorsements are required to validate a block.
"": the baking reward per endorsement
"": the network baking reward per block
For a high-priority baking:
For a low-priority baking:
This Carthage update allows focusing the baker's efforts on the priority blocks.
If we apply the block reward formula on a priority block, we get 40ꜩ:
Selected endorsers are also rewarded. One block needs 32 endorsers slots, while one endorser can have more than one. The total reward for an endorser "" is then easy to calculate.
- "": the endorser's total reward
- "": the endorser's number of slots
- "": the endorsement reward per block
For a high-priority block:
For a low-priority block:
The total available reward for endorsing a high-priority block is fixed to the same amount as the baking of that block: 40ꜩ.
That value is distributed among all the endorsers, proportionally to their slots.
The operation is the same for a low-priority block.
For more detail about the Tezos baking process, please refer to the "Baking" module.
It's important to note that the Tez token is based on a model with inflation. By adding up the baking and endorsing block rewards, each new high-priority block generates 80 new Tez. A new block is created roughly every 30 seconds. This represents 42 Million Tez per year ( 80 ꜩ 60 mins 24 hours 365 days). At the Tezos launch, the network was composed of 763 Million Tez. Therefore the inflation rate of the Tez token is approximatively 5.5%:
What have we learned so far?
Thanks to this chapter, you should now have a better understanding of how Tezos economics work. This understanding can now help to build viable Tezos smart contracts.
This chapter is the last one of the Tezos Basics module. The next chapter is the examination.