Protocol Parameters updates by IOG within Transitional Praos implementation

My 2 cents: Removing the concept of pool identity makes sense to me. If users were presented with “option 1, 2, n” instead of “1pct, 1pct2, bloom” then we would at least help removing brand identity which makes people stick with pools run by the same entity/person.

That would be more effective especially before we reach k=1000 when delegators will be forced to reallocate their stake and leave saturated pools.


In complete agreement with the essence of this post, to propose and establish an approval layer on changes to the protocol. As said, we’re in Praos transition and changes to parameters like nOpt and a0 made now will have long lasting influence, possibly negative, on the health of the network. Establishing an approval layer is the first step in fading out BFT level changes in favor of community level governance.


Yes, I agree with urgent need to establish an approval layer.


My two cents as a newbie. Go easy on me top dogs.

Stake monopolies are a big problem.

However I do not think the root cause is how IOHK set the parameters. They have the data scientists and are experts. Adding manual bureaucracy in a pre-voltaire world could cause more issues. I agree completely with the first bullet on publishing rationale on how parameters are set, what are the limitations and what were the justifications. A post parameter change analysis would be good too i.e. what happened after we moved nOpt to 150 to 500.

The gap here is the knowledge of delegators. The official wallets should link delegators to a page hosted by the CF with guidance on how to make good staking decisions. That way delegators can make informed decisions at the point of delegation.

This to me would be a very easy upgrade to Daedalus & Yoroi and the CF, IOHK and Emurgo can work as a team to add this in.

Can that be a CIP?


I would say it’s rather expecting an average trader would be interested in decentralisation, as well as clarifying what assumptions honest majority really means - because there is an expectation of what delegators will do , which seems to be contradicted by real world social dynamics.

These are genuine defects with social behaviour and expectations (hence, the referral blog from research team itself in the original post, which exemplifies what expectation was from underlying research teams). To me personally, the mentioned blog does a good job of highlighting the guidance, but unless that guidance is forced in code (not at wallet layer) - there isnt much that tweaking existing parameters can achieve. Also, long term - yes, it will be chaotic, which is all the more reason why we need to start having an approval system now, when IOG can still at the end control the outcomes, rather than doing it later directly by pushing it in the hands of community when BFT nodes no longer hold any power


Delegator education seems to be the key here. Question is how to have enough of it to influence awareness about the ecosystem and what optimal health of the network looks like and what role they play. I tell my stakeholders, not only are you improving your financial well being with the stake’s reward system, you are also a material participant in the fundamental mechanics of the blockchain. Your choice matters and it’s my job to help you understand how. That is why I sometimes promote other pools when I see that their desires and needs are better suited or that the network would benefit from it. Since I’m only 40% saturated at k=500, I obviously have room to grow for realization of the delegation design spec per section 5.6.1 “Pool Desirability and Ranking” whereas:

"We predict that pools with rank ≤ k will eventually be saturated, whereas pools with rank

k will lose all members and only consist of the owner(s)"

Amendments to the Design Spec have been attempted, here’s a link to the original.

I have seen the delegator community rise and make better choices over time. The more they understand, the more I find them making better staking choices while helping others do the same, and so on.

I find myself fantasizing about a wallet interface that elegantly encourages decentralization graphically by showing the delegator where the stake is ideally placed for optimal network health based on parameters of the protocol, delegation design spec and a playlist filter for inclusion in or support of things like Mission Driven Pools, Dev Pools,etc. The question is does the protocol actually know where the best place for that stake is or does it only care about saturating k=500 pools, ensuring immutability af 3k/f slots and maintaining probability that enforces ~5% ROS.

Some remains to be seen, some hopefully we can influence for the better. At the very least a community based approval layer that truly decentralizes the future of the blockchain.


I agree with essentially everything highlighted and am hopeful that we can convince IOG to provide justification for parameter changes. I’m a bit less optimistic that we will be able to convince IOG to relinquish its power anytime soon and provide a path for the ecosystem to submit CIPs which would be voted on by the community rather than decided by IOG. I’m also a bit less optimistic that we will see any form of an identity system (at least one that is effective) anytime in the near term. There are a number of problems within the space (such as pool splitting) where the most obvious solution involves some form of an identity solution, but I assume that an effective dID is much more difficult to create than most people think.

From what I’ve been able to tell, IOG appears to be moving more away from “research and discuss the fundamentals” and more toward a “build fast and break things” approach, especially on the governance side of things. To me, this is partially understandable given the competition that is looming in the space and the urgency to deliver a product, however, this also means that there is a general lack of communication with the community as things are liable to change at a moments notice.

I’ve discussed what I believe are problems with the current reward function, assumptions in the underlying research, and proof of stake in general Criticisms of Proof of Stake. I’ve also put forward a suggestion for, what I believe to be, a rather substantial improvement An Alternative to a0 and k, that essentially uses a constant reward (percentage) and a variable saturation as opposed to a constant saturation and variable reward as exists with the current rewards function. To prevent hijacking the thread, anyone who is more interested in discussing network parameters, pool splitting, and the like are welcome to brainstorm solutions in the attached posts.


Interesting ideas, looking forward to seeing where those go. Looks like there is consensus around a need to monitor protocol changes submitted by IOG without a approval layer well integrated into governance.

There is much hope in this thread for enlightened self interest when the best you will get is self interest. The protocol assumes self interest, and you get a Nash equilibrium because of it… So let’s not expect something irrational.

Personally I’ve yet to be convinced that the pool distribution we see is a problem. Nor that the identity mechanics are a problem. SPO’s are motivated to brand and provide a reliable and trustworthy service.

They need to compete with the likes of Binance and multiple pools? Sure, get used to a competitive world. There is no way to stop this without a central registration authority and we see how well that works in PKI. Even if it could be done who would arbitrate and decide? How would you stop someone providing funds to another party? It’s a pipe dream, forget about it and move on.

The need for transparency on changes to protocol parameters and careful transition to governance by the community obviously makes sense and should be pursued as part of Voltaire.

k=1000 benefits the system as a whole and grows the environment. Bring it on. We want to be thinking about k=10000 before long.

Cardano has always been about formally-verified and transparent decision making based on research, and this aspect (atleast for public eyes) been lacking for the updates (in terms of number) to protocol parameters. I cannot care less about what magical numbers are decided, as in my view, things would not change much by just tweaking around existing parameters. When we have to write blog articles and hope that delegators will make an informed choice , it goes quite against the methodology.

Note that the most troublesome part of ITN networking is yet to be enabled - P2P networking. While we expect the experience to be much much smoother, there will be increased demands involved, and much more professionalism expected down the line from an average SPO as SC layer is unlocked. So no - while there is a large business/competitiveness/etc quarrels happening around, this post is not about success or competitiveness of SPOs themselves, but addressing current gaps. There are multiple other things that I do not touch in my post, knowing that it will quickly derail the conversation from the missing governance and proven research layer accumulating for what’s missing.


Note that the most troublesome part of ITN networking is yet to be enabled - P2P networking. While we expect the experience to be much much smoother, there will be increased demands involved, and much more professionalism expected down the line from an average SPO as SC layer is unlocked

Agree with all of this. And the fact that it will be harder is good.

I contend we want low barriers to entry but for it to be demanding to succeed. That leads to a highly competitive market and allows SPOs to differentiate based on uptime.

SC’s mean hardware performance and operational excellence will become increasingly important and those left standing will be true businesses.

Understand that when we start to really challenge existing finance and Wall Street we are going to have the fight of our lives. They are not going to just roll over and let us take their lunch.

So let’s start getting a bit serious ourselves.

P.S. And lets keep having some fun on the way as part of the best Crypto community there is :slight_smile:

1 Like

I totally agree and concerned on technical requirements, skillsets needed to operate nodes effectively and securely as this just by itself may pose a major risk to the health of the network after d reaches 0… this must be addressed urgently as any misstep could be quite damaging.

Node operations are a big deal as utility infrastructure will become even more critical as our ecosystem grows sustainably.

Another aspect someone brought up above is about delegation. In the short-mid term making delegators merely the driving factor may prove to not be ideal as delegator comprises a very diversified community with many different viewpoints and expectations… This is a very uneven community, we must acknowledge that. In the future delegators will get more educated, new profiles,… this process takes time.

There is no easy answer but a more inclusive and open dialogue involving multiple parties, different viewpoints are needed. Rushing up a decision is not ideal. Without jumping into conclusions, not only establishing the right framework but also finding a healthy balance between these variables may prove key: identity (anonymity), fair ranking parameters, rewards and pledge, network must not incentivize workarounds and “bad” behaviors.

March 31st is right around the corner, and undoing whatever is rushed would be troubling…

A post was split to a new topic: Requirement for Stakepool setup

Unfortunately, the reason a Nash equilibrium was achieved in the paper IOG published (Reward Sharing Schemes for Stake Pools - IOHK Research) is because their model enforced a single pool per operator. Hence, the need for an identity solution and single pool mandates if we expect to achieve a similar outcome in practice. This isn’t to say that the system will fall apart on its current trajectory, but IMO this implies that k is essentially just a vanity metric for “decentralization.”

1 Like

For a successful operator, the cost of splitting a pool is almost zero. This is because the required pledge is 0. Matters get worse because the min fix cost (i.e. 340 ADA) is well, fixed. It does not take the change of ADA price into account. Running decent hardware with N hours high skilled work may cost a fix amount of $ but not a fix amount of ADA. In short, the fix cost should be more flexible IMHO.

Also, a pool gets saturated at a certain max stake, but not as a function of the owner’s pledge. Some large pools have ridiculously little skin in the game (perhaps due to their splitting). Rewards could diminish when pledge drops below 3% of the pools active stake (e.g). This would be akin some sort of “healthy band” between min pledge max active stake.

Perhaps this is what a0 is about, when it gets implemented. In any case, because “Pool operators that run multiple pools with small pledge hurt delegators and smaller operators”, should IMHO discouraged more effectively let alone be endorsed by Daedalus ranking.


I think we need to be careful not to let perfect be the enemy of good here.

We are in a situation where there is a clear window of opportunity until our main competitors solve their scaling problems. We have finite resources to allocate as a community (including IOHK) and we may need to prioritise other areas and return to this, assuming that the faults identified are not critical in the near term?


I’d say this is true, except that this isn’t the first post calling for these types of changes. People have been calling for modifications to the reward scheme since before Shelley was actually released, my own suggestion for a CIP being posted back in November. True there is competition, but the competition isn’t going away and it is only going to get harder. So when is a “good” time to allocate resources to the issue?

I’d argue that we have too may resources and not enough tools. The rewards function has come up so much because, up until recently, it’s one of the few things that the community can actually contribute to. Goguen still isn’t completely out and there’s no smart contract functionality, Catalyst just got started after multiple delays of Fund 2, Marlowe and Plutus aren’t ready yet, NFTs are just being made available. I’m not blaming IOG for this, they’ve got their hands full and are doing the best they can. I’m just saying that if the only thing the community has really seen is Shelley, then they’re going to focus on what’s in front of them. And why not? The reward scheme is a low hanging fruit that, technically speaking, isn’t that difficult to fix/change, it’s more of a matter of getting consensus amongst the community.

1 Like

That is actually pretty genius! It allows small pools to compete, incentivizes them to reinvest rewards into pledge, and forces pools such as BNP to pledge too.

Using 1% as the pledge to stake ratio, a pool with 10K pledged could hold 1M in delegation before it gets “saturated”, 100K would be enough to run a 10M pool, and so on. Absolutely brilliant.


Totally agree that we urgently need to have a solution in place before BFT nodes no longer hold power. It is only natural for the community to be pushing for responsibility in approving any changes and requesting the research work that was completed for any changes prior to changes being made.

We are not a passive community, nor should we be in this transition process. Let’s keep pushing on this to get a CIP draft for this community layer approval or add to the draft of CIP-0009 detailing the change process to protocol parameters.

Process for Making Changes to Protocol Parameters


Changes will affect many stakeholders and must therefore be subject to open community debate and discussion.

Ultimately, the Voltaire protocol voting mechanism will be used to achieve fully automated, decentralised and transparent governance.
In the interim, the CIP process will be used.

Signalling Protocol Parameter Changes

Changes to the parameters need to be signalled to the community well in advance, so that they can take appropriate action. For the most significant parameters, a minimum of 4-6 weeks elapsed time between announcement and enactment is appropriate. This period must be included in the CIP. Announcements will be made as soon
as practical after the conclusion of the vote.

Applying Protocol Parameter Changes

Protocol parameter changes must be submitted and endorsed within the first 24 hours of the epoch before they are required to come into effect.
For example, a change that is intended for epoch 300 must be submitted and endorsed in the first 24 hours of epoch 299.
Once a change has been submitted and endorsed by a sufficient quorum of keyholders (currently 5 of the 7 genesis keys), it cannot be revoked.

1 Like

Good points IMHO. I think that the fixed cost in particular needs to be paid attention to. The ratio to smaller stake pool rewards vs more saturated pools is very harmful to small pool operations’ rewards by comparison (i.e. much higher % chunk) and there is nothing we can do to change it.

There is no means to gain any competitive edge and so you end up with another race to the bottom with margin approaching 0% to get a boost in Daedalus. Margin is widely known among SPOs to have much less impact on delegate rewards, but is not perceived this way by the wider community because of Daedalus ranking.

Fixed cost also does not scale with the amount of stake / capital “invested” into a pool and therefore fiat. Margin does.

This parameter has been making decentralization difficult for a long time and I hope that it is lowered soon so that margin can actually function as the competitive parameter, along with whatever changes are made to a0 if any.