We’ve seen a very positive responsive to the launch of the Daedalus Rewards wallet for the incentivized network this week. We’ve also seen plenty of questions from the community wondering what some of the key terms used mean and what they mean when it comes to assessing stake pools and deciding upon delegation. So we thought we’d pull together a bit of a glossary. We hope this helps!
Expect more content related to delegation and the Incentivized Testnet to come your way soon. Meanwhile, feel free to drop any further questions you have below !
Term
Definition
Balance wallet
A Balance wallet is a wallet that stores your initial testnet ada balance, copied from the mainnet via the balance snapshot. The stake from this wallet cannot be delegated but can be transferred to and delegated from a Rewards wallet.
Rewards wallet
A Rewards wallet is a wallet that stores ada which can be used in stake delegation. The stake from a single Rewards wallet can only be delegated to a single stake pool. To delegate to more than one stake pool, you will need to create multiple Rewards wallets and distribute ada among them.
Epoch
An epoch is the period of time over which the blockchain produces its next set of blocks. On the Incentivized Testnet, an epoch lasts one day. Rewards are calculated at the end of each epoch and then distributed to delegators and stake pool operators. At the end of each epoch, the stake pools who will produce blocks in the next epoch are nominated (nomination affects performance, see below).
Controlled stake
This is the total amount of stake that a stake pool controls. It combines the stake that is owned by the pool operator with any stake that has been delegated to the pool by other ada holders. It can be measured as a total ada amount (e.g. 3M ada), or as a percentage of the total supply of ada within the network (e.g. 5%).
Performance
The performance of a stake pool, given as a percentage, is measured by how many blocks the stake pool has produced (and that are recorded on the main chain) compared to how many it was nominated to produce. For example, if a pool only produces half the number of blocks that it was nominated for, its performance rating is 50%. This could happen because the pool has a poor network connection, or has been turned off by its operator. Performance ratings make more sense over a longer period of time. If a pool has not yet been selected to produce a block in the current epoch, its performance rating will be 0%, even if it is likely to produce blocks later in the epoch. Performance ratings of over 100% are possible if a pool creates more blocks than it was nominated to produce.Since this is a testnet, performance ratings should only be used as a guide, and may be affected by network uptime, updates, or parameter changes.
Produced blocks
This is the number of blocks that have been produced by a stake pool in the current epoch. Stake pools are rewarded in ada for each block that they produce.
Block
A block is the basic unit of work in a blockchain. Stake pools compete to produce new cryptographically-verified blocks that are used to certify the validity of the cryptocurrency. Blocks are linked into a chain, with each block depending on the previous one (the blockchain). Network nodes (in the form of stake pools) collectively agree on which block should be the next one in the chain.
Profit margin
The profit margin is the percentage of total ada rewards that the stake pool operator takes before sharing the rest of the rewards between all the delegators to the pool. A lower profit margin for the operator means they are taking less, which means that delegators can expect to receive more of the rewards for their delegated stake. A private pool is a pool with a profit margin of 100%, meaning that all the rewards will go to the operator and none to the delegators.
Cost per epoch
This is a fixed fee, in ada, which the stake pool operator takes every epoch from the pool rewards to cover the costs of running a stake pool. The cost per epoch is subtracted from the total ada rewarded to a pool before the operator takes their profit margin. Whatever remains is shared with delegators.
Saturation
Saturation is a term used to indicate that a particular stake pool has more stake delegated to it than is ideal for the network. Saturation is displayed as a percentage. Once a stake pool reaches 100% saturation, it will offer diminishing rewards.The saturation mechanism was designed to prevent centralization by encouraging delegators to delegate to different stake pools, and operators to set up alternative pools so that they can continue earning maximum rewards. Saturation, therefore, exists to preserve the interests of both ada holders delegating their stake and stake pool operators.
A note on profit margin and cost per epoch
While it might seem like delegators should always pick a low-profit-margin and low-cost-per-epoch stake pool to receive the highest returns, this isn’t necessarily the best option. It costs money to run a stake pool, and if stake pool operators cannot cover their costs then the stake pool may perform badly or stop running entirely. Users should consider this when choosing a stake pool, especially if they want to ‘set and forget’ their delegation preferences. A more moderately-priced pool may be a better long-term option. It is always sensible to check a pool’s performance and other information before delegating to it.
As a pool operator, thank you for explaining in the performance section that a pool who has not yet been selected will also have a 0% performance.
I definitely wish it showed N/A since a pool that hasn’t had a chance yet to perform isn’t really at a 0% performance. The 0% kind of implies that the pool has failed repeatedly to the uninformed when in fact the pool just needs more stake to get a chance to perform. The 0% will only reinforce that lack of stack since people will choose against it thinking it has previously failed to produce when selected.
If we want decentralization, maybe we should consider “N/A” instead of “0%” in this scenario. Just an idea.
I think the most interesting variable is missing, let’s call it “relative stakers rewards”. Take the staker’s rewards from the last epoch of the pool (total rewards minus pool taxes) and divide it by the total stake of the pool. This takes into account if a pool is over the saturation (less rewards per stake) and also if a pool has high absolute or relative taxes (less stakers rewards). The drawback would be that it lags behind by one epoch, but on the other hand the actual performance is missing saturation and tax information and is therefore not really helpful for the delegator. A “relative stakers reward” could also be helpful in the understanding of an expectation value for the rewards. One pool could have a value of 3 ADA / 10.000 ADA, another one of 3.1 ADA / 10.000 ADA. The meaning would be clear to every delegator at once.
Maybe, in favor of small pools, a second variable, let’s say “10 epoch average relative stakers rewards” could smooth out the single spikes of high relative rewards in one epoch and zero rewards in another for the small pools.
I just saw that CLIO1 went from around 30 million ADA to 338 million ADA during th last 24 hours, it is shown both in adapools.org and in pooltool.io. In Daedalus still 30 million ADA is shown. It seems that the values ar not updated often enough. CLIO1 is now way above the saturation point and no (financially) good choice any more for delegators.
Edit: 20 min later CLIO1 is at 50 million ADA in Daedalus.
Edit2: Right before the end of epoch 12 there were still 50M ADA shown as stake for CLIO1. Now, right at the beginning of epoch 13 it shows 338M ADA. But in the meantime most of the stake is already removed. Adapools and pooltool both show 118M ADA.
this information should be embedded as a tool tip within daedalus itself, a little ? mark icon after the colon which then brings each description up on a hover
also there needs to be some information as far as saturation is concerned
also the ranking needs to redefine to include reliability and return (saturation)… all the pools are the top are heavily saturated and offer terrible returns and this issue just gets compounded with the current ranking
ideally saturation should also work into the performance metric, if returns are heavily compromised due to pool saturation then that is hardly a high performance pool, it’s the opposite
also profit without any further explanation doesn’t indicate if it’s the delegators profit or the pool operator, tooltips here really should be implemented asap
I got a maybe easy to answer question.
I am not sure of the meaning of block height. Could anyone explain please. I found it on pooltool.io
They explain it as the current block height reported every minute - i have to confess it was not very enlightened to me… I can only guess…
The block height is the number of blocks on the chain since genesis. So it shows whether the stake pool is up to date. Given stake pool sends it to pooltool to show its own block height. Min. time interval 10s afaik
Why 0% Performance will get all stake pools at the end of the epoch when they are not elected to produce blocks? When for example a bad stake pool performer can only produce 1% of the elected blocks to produce and they will be still ahead (in the stake pool list in Daedalus wallet) from all other stake pools which they didn’t have a chance to produce blocks but they are rated as 0% Performance and will be put at the bottom of the stake pool list?! This doesn’t make sense at all. I hope a better ranking system will be created to show the good real performance of all stake pools.
The following is just a thought:
Could the protocol have such a tool like pooltool.io that shows a pool is at the same height as the rest of the best performing pools and is ready to create a block if called on?
I think it could be possible - I remember I had read something that the protocol will create blocks with or without the selected slot leader and this is a little confusing to me yet maybe it is possible that if a node does not create their block than it falls to the next node that is like second choice to ensure a block does get built if this is the case than a tool showing the height from the pools (like pooltool in a way) would be very beneficial not to just the delegates but also to the protocol - ensuring blocks get created with the protocol knowing the nodes are up to date and ready for the job.
Just a thought.
Thanks CardanoUnbrella,
I know this command, but what I was looking is to find out if my stake pool was nominated to produce blocks in past and missed to produce blocks.
From your node use jcli rest v0 leaders logs get -h http://127.0.0.1:${REST_PORT}/api
At the beginning of each epoch this will show you if you have been selected for the chance to create a block. Of course you must be in online and insynch to do so.
I use this to sort my blocks by blockdate, just change the epoch from 21 to whatever epoch it is
jcli rest v0 leaders logs get -h http://127.0.0.1:3101/api | grep scheduled_at | awk ‘{print $NF}’|awk ‘NR%2{printf "%s ",$0;next;}1’ |sed -e ‘s/"//g’ | sed -e ‘s/^21.//g’ | sed -e ‘s/T/ /g’ | sed -e ‘s/+00:00//g’ | sort -n -k1 > epoch21.txt
