As announced about 5 days ago K is increasing on the network from 150 to 500 and then 1000. This is a massive change to the network parameters and will impact all delegators and pool operators. I was curious what rewards would look like for oversaturated pools and how quickly rewards would fall of, so, as usual, I coded it up to satisfy my curiosity and wanted to share.
The Green line represents the ROI (annualized) for a pool across a wide simulated range of stake (I assume optimal performance). The RED vertical bar shows you the live stake in the LOVE pool as of today. As you can see, the LOVE pool is well under the saturation point of around 212M and also notice there is a fairly linear drop off in ROI over 212M.
The blue line represents K=500 which is where we will be starting December 6th. If you are delegating you will want to make sure you are in a pool that has less than 64M ADA staked. As you can see from the plot, the drop off is exponential so youâll want to keep a very close eye on your pools to make sure they donât accidentally get saturated after you delegate and before the end of the epoch. And finally, the Orange line represents what the curve will look like next March when saturation moves down to around 33M.
It is going to be an interesting social experiment to see how many pools stay saturated or become saturated by confused or uneducated delegators thus pushing the entire pool into sub-par returns. I know many delegators are HODLers and probably setup their delegation and wonât notice until their rewards seem far lower than they expect.
Just as a side note, the other end of the curve is also interesting. Starting at 0 stake (obviously 0 rewards) we can see the effect of the fixed fee on smaller pools. When a pool only has 1M on it these fixed fees become a larger percentage taken from the delegators, and thus limiting the maximum return of the pool regardless of how low their variable fees are. Once pools get over about 10M that effect is very small.
You can find these charts for pools you delegate to on PoolTool.io. As we get closer to the transition we will start painting live stake red at these lower saturation points and will adjust our mobile app alerts so that you will be warned if your pool becomes saturated. If you donât have the mobile app already I highly recommend you get it, and subscribe to alerts for your pools, as you donât want to get caught on the back side of that exponential curve!
@werkof Interesting charts, thank you! What do the different bar colors correspond to (a large red clump and a smaller blue clump is noticable)? Is there a way to sort data by SPO rather than pool to see how much of the âintendedâ effect of increasing k is taking place vs simply pool splitting?
Shamless plug⌠An Alternative to a0 and k
I have to admit the colors and readability became worse by increasing the shown pools from top150 to 500
Basically there are certain categories of pools who form larger clusters, who received a dedicated color in this graph.
There is an alternative horizontal structured presentation of the same data at
where you can better see/read which pools this effectively are, and to which pool-cluster they belong.
The tricky and still not perfect thing in this graph is the identification of the pool-clusters (SPOs)
First it is about identifying the real groups.
Then it would need some formula, calculating epoch by epoch each pool-clusters and the total decentralisation factor, to see if and how it changed over time and after k500.
I know this existing presentation gives only a subjective view on how the strong vs light coloured bars changed.
for example this compares a k150 epoch with the most recent one
in the horizontal graph linked above you can see the related pools clusters.
red : IOG
orange: 1PCT
blue: ZZZ
brown: LEO
green: OCEA
now with switch to k500 most of them (except IOG and Binance) created more smaller pools.
Also some previous single pools, now splited up to 2-3 new pools. (not marked with dedicated colors yet in this graph)
Also to mention a noticeable amount of delegators moved to individual small pools, and so let them and decentralisation grow
I personally canât wait until there is more distribution across the pools. I wonder if the k parameter will come up during the voting for Fund3 or Fund4.
In most official communication they speak of âend of march 2021â and as excited as i am for excess stake flowing into the smaller pools, im not hoping for these chunks to help STAYK get full. im continuing my efforts to help get attention and stress the importance of the decentralized aspect of the ecosystem!
While it has been a matter of considerable internal discussion, we have also concluded that any change in k should come after changing the formula for a0 to deliver the desired results (especially encouraging stake to flow to smaller single pools rather than split pools). Since this is a full formula modification, and no longer a simple epoch boundary change, it needs to be released as part of a hard fork. Given our product pipelines and the teamâs current focus on continuing the Goguen rollout and available dates, we look at making this change again in a Q3 time frame.
I wonder how they are going to accomplish that. Are they going to pick up the fact that pools are named ADLT, ADLT2, ⌠ADLTn and offer them less blocks? Those bigger establishments will just change their name structure if the proposed solution is as simple as that. They could potentially see if the nodes are on the same infrastructure somehow, but there are ways around that too. Hopefully they come up with something good or small pools are going to struggle.
Correct em if im wrong, but since the k factr states the desired number of nearly saturated pools, isnt it just sensible to see that while we have 1800 pools now, roughly all the supply will eventually be spread across those 1800 pools. maybe just locking the creation of new pools untill stable and reliable but empty pools are closer to saturation? its rigorous but should at least stimulate growth of smaller pools rather then incentivise the splitting of pools?
I think locking the pool size probably wouldnât look good in terms of decentralization. However there has to be a way to change the pool selecting algorithm to be more random and less skewed towards the largest pools. As long as the node is reliable and up Iâm not sure why it matters that there are a lot of delegators or stake associated to a node.
The point is avoiding the creation of big pool groups, since there is no âidentityâ in the blockchain is practically impossible to say that two groups belong to the same person or not.
Of course I hope that when k will increase most of the oversaturated ADA will flow to small pools, like mine.
