Behaviour of the Cardano network
One question we receive most frequently is that of the reward. Lots of delegators are interested in knowing how much their delegation reward will be and of course, why it is not always the same amount. Even a well maintained and smoothly running pool will not always be able to produce the same rewards, due to how the Cardano reward system is functioning.
The behavior of the Cardano network largely controlled by parameters.
They control everything from the reward per block and the speed at which new ADA are mined to the fraction of block minted by the community pools, and the fraction of minted ADA flowing into the Catalyst fund.
Here we will point out some of the critical parameters, and what their function is.
Parameters influencing rewards:
Rho : expansion parameter
The Rho parameter determines the amount of ADA that will be minted in an Epoch. The total reward pot per epoch is equal to the Rho multiplied by the number of ADA left unminted at the begining of the Epoch.
At the time of writing Rho is set to 0.3% and the number of ADA unminted is ~ 13.2 Billion ADA. So the number for newly minted ADA per Epoch is ~ 39.6M ADA
Because the minted ADA per Epoch is be determined based on the amount of available ADA, the rewards pot will become gradually smaller each Epoch, with Rho (0.3%) per Epoch, but will never go to zero completely.
Tau : tax percentage
Of all newly minted ADA, a percentage goes to the Catalysts fund. These ADA will be used for further development of the network. The ADA holders are able to vote on which projects will be funded. Tau is the percentage of the newly minted ADA that goes to the Catalyst fund. At the time of writing Tau is 20%, whereby ~7.9M ADA per Epoch are flowing into the funds intended for further development.
k : ideal number of stake pools (nOpt)
The k-parameter determines the optimal number of stake pools on the network.
K influences the how much stake can be in a stake-pool before the rewards are capped. The maximum stake is given by the total amount of minted ADA, divided by k. At the time of writing k = 500, with the plan of increasing it to 1000 in March of 2021. With k = 500, and the total minted ADA at 31.8B ADA, the maximum amount of stake in a stake before the reward gets capped is : ~63.6M ADA
Previous plans to change to k = 1000 have been postponed until further notice.
a0 : pledge influence
The a0 parameter determines the influence of the pledge on reward of a pool.
The reward per block for a pool with full pledge (pledge = max stake) is a0 higher than a pool with 0 pledge. At the time of writing the a0 = 0.3. This means a pool with full pledge gets a 30% higher block reward than pool with 0 pledge.
Block assignment on the Cardano network
How is Block Production distributed in Blockchain networks?
In any blockchain, one of the biggest problems to solve is: "who gets to create the next block". Since blockchains are decentralized, there is no central authority to assign the blocks, and network has to solve this problem by design.
If one player produces more than 51% of the blocks in a Blockchain network, they would effectively take over the chain, it is in the interest of everybody to prevent this from happening.
In a Proof of Work (PoW) blockchain, the next block will be created by the first miner that solves the cryptographic puzzle. With this principle, the blocks will be assigned randomly amongst the miners proportional to their calculation power. This is called hash rate. This leads to miners constantly increasing their hash rate and power consumption, to try to take a bigger piece of the pie.
In Proof of Stake (PoS), the blocks are distributed proportional to the amount of "skin in the game" the players have. By owning the native token of a blockchain (in our case of Cardano: $ADA), owns the rights to create a share of the blocks on the chain. Hereby there is no need for an arms race of hash power. This means a PoS chain does not need to increase power usage in order to function.
In most PoS blockchains the rights to create a share of the blocks is delegated from the token holders to a so called Stake Pool. This is a player on the network that has the technical know-how and infrastructure to reliably produce blocks. The token holders that delegate to a stake pool will share in the block rewards.
So, how does this work in the Cardano Blockchain?
On the Cardano network, time is split into Epochs and an Epoch consists of a number of slots. An Epoch is 5 days long, and every second is a slot, so there are a total of 60s*60m*24h*5d = 432'000 slots in an epoch.
At the boundary between epochs, the state of the network is put into a snapshot. The delegation state of each wallet on the network is recorded. This means that from that snapshot we can also calculate how much of the total ADA is delegated to every stake pool. The data from the snapshot is used for the Epoch 5 days later. The likelihood that a pool produces a block in any given slot, is adjusted to the delegation state of the pool at the time of the snapshot.
Whether or not a pool produces a block in a given slot is determined by the pools Verifiable Random Function (VRF) key, the delegated ADA at the time of the snapshot and the Epoch Nonce, which is generated uniquely for every Epoch, 36 hour before the Epoch starts.
Because of this method every pool is able to calculate in which slot they will produce blocks, before the epoch even starts.
With the current settings on the Cardano parameters, on average a slot is produced every 20 seconds.
Orphans: Slot Battles and Height Battles
An Orphan block is a valid block, that is not accepted by the blockchain. In the Cardano network, there are two main reasons why this can happen. They are revered to as Slot Battles and Height Battles.
The most common event is the Slot Battle. As described above, every pool individually calculates whether or not it produces a block in a specific slot. The current Cardano parameters are set in such a way that in ~5% of the slots, a block is produced. Since there is no central authority coordinating who produced which block, there is a small likelihood that two or more pools produce a block in the same slot. About 2.5% of all blocks end in a slot battle.
Only one of these blocks will be adopted by the chain, even though all of them are principally valid. Which of the blocks is selected is determined by the height so called VRF output. There is no way for the pool to influence this.
A less common type of orphan block is due to a so called Height Battle.
The blocks in the chain are sequential. Accordingly every block builds on the previous one. This means that at the moment a pool builds a block, it needs to be aware of all blocks that have already been produced.
When a pool produces a block, it sends it out into the network through its relays. It will then propagate through the network. If the pool that builds the next block, has not received the previous block yet, a height battle occurs.
Usually this happens when the blocks are creates in sequential slots, so that there is only 1 second to the first block to propagate through the network.
We should see this as both blocks having the same parent block, and therefore the same block number. Also, the second block will contain all transaction of the first block again.
In the Cardano protocol the second block will always be accepted, and therefore the first block will automatically be orphaned.
Height Battles will occur from time to time, but are most likely to occur when the difference between the slot of the first and the second block are only 1 second appart. The stake pool operator can influence Height Battles by making sure their block producer is well connected to their relays, and make sure their relay have a good diversity of outgoing connections.
The CAPEX infrastructure runs on 6 relays nodes, which all have 15-20 outgoing connections. By this we ensure that our blocks are propagated through the network quickly, to minimize the chances they can orphaned because of height battles.
A useful helper
We are very thankful for pooltool.io. This useful project gives you a lot of information on the pool you delegated to. If you haven't checked it out yet, take a look at https://pooltool.io/. As you can see in the screenshot below, all details that are visible in your wallet when you delegated are on the lower section. The really nifty stuff happens when you click on the blue arrow on the right side of the screen.
We are not going to go through every single function here, but here is some guidance on how to find answers to frequently asked questions from our delegators.
The first thing you will see when hitting that blue arrow is the Epoch History. You can see the blue line represents the amount of delegated ADA to our pool and the pink bars that represent the ROS (Return on Stake). As you can see, although the amount of delegated ADA changed, the ROS is pretty stable on our CAPEX pool. The amount of delegated ADA is for sure a factor in ROS, but as already explained above, only one of many influencing parameters.