The Cardano Foundation's Response to the Parameter Committee Recommendation in PCP-001

Recommendation of the Parameter Committee

We appreciate the recommendations of the Parameters Committee in PCP-001 dated July 27th.

Poll Analysis

The Mainnet Poll

The actual mainnet poll took place in epochs 412-415 in May 2023.

From the currently about 3000 pools registered on mainnet, about 1100 regularly generate blocks. 796 of these pools participated in the first SPO poll on mainnet.

This means 27% of all existing pools and 72% of all producing pools have cast a vote.

Active Stake participation

Because the Cardano protocol and the block production are based on Proof of Stake, it is more important to focus on the stake participation.

From the active stake of all pools that could vote in epoch 412-413, 10,850b ada were counted in the snapshot at the end of epoch 415, which corresponds to a participation rate of 49.4%.

Redelegation Epochs

One goal in the planning and design of the poll was to allow delegates to respond to a vote from their current pool if they disagree with it at all. Therefore, after the two response epochs of the pools, there were two more epochs at which delegates could choose another pool.

A final analysis of the on-chain activities has shown quite clearly that delegators have not made significant use of this option, either in absolute or stake numbers. It is unclear whether confidence in the current pool or a certain passivity are the main reasons.

The question

For this first poll, a single question with combined answer options was deliberately chosen. It would have been possible to ask two separate questions about the two parameters, which would make sense for a general survey of preferred values. In CIP-1694, this would correspond to an Action Type 7 poll without automatic on-chain execution. However, for real polls that are implemented automatically on-chain, it would be risky to poll the parameter values independently, because there could be individual parameter values that have mutual effects, correlations, and dependencies. To avoid this various parameter sets can be brought to the vote, taking care that the particular set with all its parameter values is coherent and does not pose any risk or harm to the chain.

The question asked and the answer options were:

Which setup would you prefer to be put in place from Q3 2023 onwards?

  • Keep k at 500 and minPoolCost at 340 ada

  • Keep k at 500 and halve minPoolCost to 170 ada

  • Increase k to 1000 and keep minPoolCost at 340 ada

  • Increase k to 1000 and halve minPoolCost to 170 ada

  • I would prefer to abstain

  • None of the provided option

The results

The participating 49.4% of stake answered the question as follows:

More details on the SPO Poll results can be seen in the two amazingly creative dashboards of the community explorers at Polls | Cardano Explorer and SPO Polls - Cardanoscan

A very interesting and helpful post also came in the form of a data analysis on the potential impact of increasing k. Community Member combined 3 data sets

The goal was to try to get some sense of what would happen with the various pools if K would be increased. How many Single pools would saturate and how much stake would that be. The same for the Multi pool groups.

Read more about at

The comments

On the initiative of some Stake Pool operators, individual responses were submitted with supplementary comments. So far, no one from the community grouped or ranked these opinions.

Since we don’t want the actual survey result to be mixed by comments with a second result based on individual comments, nor do we want blockchain to be used as a chat and comment platform, we list here only the unique comments without trying to summarise or interpret them in any way.

In fact, there are many interesting and important thoughts in the comments, which also represents the diversity of views.

A list of all comments can be found here

The effect of minPoolCost

minPoolCost was introduced with the Shelley launch in August 2020 to fulfil two tasks:

  • It should support the pledge factor a0 as a Sybil attack mitigation.
  • It should guarantee the pool operators a minimum budget for the professional operation of the servers.

The next chart shows all 1075 stake pool fees for Epoch 415 (1075 pools produced at least one block)

Dark green is the part coming from the currently set minPoolCost (340 or more ada)
Light green comes from the configured margin % (0-100%)

It is important to note: By potentially halving minPoolCost we don’t enforce but allow the operators to reduce their “floor” income. We can clearly expect a high competitive pressure for small pool operators (right half in the chart) to go to the new minimum, and so halve their operational budget. The larger pools are not so much affected by it.

The next chart is calculating the current operator fees per month, assuming an ada price of 0.3 USD. It is likely that especially the smaller pools - which mainly demand a reduction of minPoolCost - will have to offer the new lower limit. The dotted line shows a new fee rewards curve that will probably result from this.


Since the rewards per block have decreased from 1800 to 500 ada nowadays, this 340 ada minPoolCost has a much stronger effect, especially for those small pools that generate only one or very few blocks per epoch.

The following table shows what portion of the revenue the minPoolCost collects, depending on the number of blocks generated by the pool per epoch. For this purpose, the current value of 340 ada is contrasted with 3 theoretically lower values of 170, 85 and 0 ada.


The same data in a chart looks like this and also shows the little but constant effect on the delegator rewards, if minPoolCost would be lowered.

The most frequently mentioned suggestion, within poll comments, to mitigate this significant competitive disadvantage of minPoolCost for small pools is to replace minPoolCost with a minMargin. This is therefore not a simple change of one of the existing parameters but would only be feasible by means of a hardfork and the introduction of a new parameter, which shall not be part of this analysis.

Reducing minPoolCost lowers the effect of the two original purposes, but in return clearly brings a significant improvement in competitiveness for small pools. One issue raised in the comments is that small pools need some time to improve their RoS (Return on Staking) value. This should be as good as possible when delegators are persuaded to seek a new pool. This could occur if the k-value is increased and thus the saturation point of currently filled pools is lowered.


The Cardano Foundation is in favour of respecting the decision that resulted from the SPO poll. Given the potential impact of these changes, we think that the recommendation of the parameter committee for a staged implementation is reasonable.We therefore support the halving of minPoolCost as a first gradual step, followed by an evaluation of the effects and further adaptations in Q3/Q4 .


I would appreciate reading any historical documentation about why minPoolCost was thought to be necessary by the design architects. There is no mention of minPoolCost in any of the Ouroboros research papers. Given how detailed the proofs in the Ouroboros papers are, I would have expected some very detailed reasons for, and calculations about, minPoolCost.

Regarding the first quoted dot point above: I can see how minPoolCost might contribute to Sybil attack mitigation. But, the extensive proofs in the Ouroboros research papers clearly determined that such a parameter was not necessary since their analysis did not include it.

Regarding the second quoted dot point above. I would argue that minPoolCost does not guarantee a minimum budget for pool operators because they will only get this minPoolCost amount if they make a block. And, they can only make a block if they get enough delegation. And, they can only get enough delegation if they offer competitive fees. And, with minPoolCost at 340 Ada, they are unable to offer competitive fees until they get more than 10 million Ada stake. So minPoolCost doesn’t guarantee pool operators any minimum budget, instead it guarantees that small pools will remain uncompetitive and too small to get any minimum budget.

minPooCost of 340 guarantees that delegators must financially harm themselves if they delegate to a small pool.

I agree. A more complex change like this will be more difficult to reach consensus about. If we get sidetracked about such complexities now then we will still be arguing about these problems in another 2 years time. We should make some simply achievable changes now to mitigate the problem and consider more complex changes later.


Aug 17, 2023 | Voltaire era: Parameter committee intermediate state Post #49 :

This transgression against free market and decentralization principles built into the architecture of Cardano for the benefit of genesis keyholders (like CF), ICO investors, and popular incumbents is an irreversible & permanent limit on the social and moral superiority of Cardano. Readers, my DM’s are open if you care about principles and you are ready for ‘what is next’.


The key to understanding here is that a pool is not to be seen as one pool, but as the amount of stakes it represents. Thus, the “minumum budget” is meant for a pool with network-significant block-production. Not “guaranteed budget for everyone”

That is, there is a parameter that defines the desired number of pools. Even though everyone can run their own node and pool at any given time, that in no way means that there is a realistic way for everyone to have a viable and cost-covering pool at any given time.

Afaik mPC as a Sybil attack protection was added as a complementary factor because the much in theory explored pledge factor, then had to have a real world value assigned. And this value had to be set between very much or not relevant at all. If very much, then you would have a very exclusive whale favorishing environment. (unlike mPC, where even a non-financially strong pool owner can build a fully saturated pool.) If the pledge is set to less relevant values instead, mPC can act as an additional complementary factor.

Said this, as many other factors they often come with benefits but also consequences. In a diverse ecosystem, this hits some more and some less.

At this point we get into the area of discussing and understanding how many such cases (operators and pools) we need, and how much leeway a constantly decreasing reward budget leaves when approaching the k-question.


We appreciate the well written summary of your decision, however, it doesn’t address the actions that will be taken.

Is this just CF that is supporting a halving of minPoolCost? What about other Genesis key holders? Do they need to also consider the recommendations in PCP-001 before any action is taken?

Secondly, have you decided on a timeframe to enact the havling? Or does that require further discussion?


Please stop promoting your own blockchain here, we now it by now…


But, a fundamental principle of Cardano is that of fairness and equal access to all. Equal ability to compete and build a viable pool. I get that not everyone can be a winner, but we do at least expect a fair playing ground.

Setting minPoolCost so high amounts to anti-competitive regulation which means that the only way a new entrant can compete with incumbents is by convincing potential delegators to financially harm themselves. Alternatively, a new stake pool operator needs to falsely represent, or actively hide, the fact that delegators will be financially harmed by supporting their pool.

This high minPoolCost is an unfairness that was unwittingly baked into the design and it is a blight on Cardano that runs counter to it’s core philosophy. After all the Ourboros research was done, someone thought minPoolCost might be a good addition, but it isn’t. It results in the same incumbency protectionism problem from the TradFi world that we are trying to get away from.


understandable points of view

We can also try to look at it from a historical point of view, not just from the current situation.

In the beginning, there were no saturated pools. Everyone had to start with an almost empty, somewhat pledged pool. So at that point, there was no such economic (dis)advantage, except for the big whales who were able to significantly pledge and/or saturate their pools from day one.

So for the Shelley launch there was a decision to not make the pledge as relevant as it could have been, to make it fairer and more accessible to operators with fewer pledge options.

The mPC was added afaik at that time to compensate for the relatively weak setting of the deposit factor. (Tradeoff: fair accessibility vs security )

Now, after many epochs and a fairly complete bootstrap process of the pool landscape, the situation has clearly changed. mPC became a significant challenge in building a pool. So, you could say that over time (!) it even became a factor that favors the behavior of sybills: Operators who have a saturated pool can build more such pools because of their brand and awareness. So from the perspective of Sybil attacks, it might make sense to reduce mPC and then maybe even eliminate it altogether.

But I don’t think that today’s situation - where we are actually working on this parameter change - can be seen as a wrong decision from then, because the situation was different then.


I am not suggesting that the person who dreamed up the minPoolCost addition should be lynched. As I stated above, I think the motivation was well intended. Nevertheless this minPoolCost addition has been found to cause unintended side effects which result in bad outcomes, so by that definition it was wrong to add it. I guess that is what happens, when on the spur of the moment, someone adds something extra beyond what the extensive research determined sufficient.

The time to correct this error was yesterday.

1 Like

I find this a bit strange… First the importance of pledge is highlighted and then a decision was made to make it less less important because not everyone can afford it. Doing that is quite the same as saying it 's not that important after all…

1 Like

I agree and see this as one of the many trade-offs that had to be made and will continue to hit us in many governance decisions in the future. The most important thing is to understand the situations at different points in time, and also the relevance of the positive/negative (side) effects for different participants in such a diverse environment.

And because of this diverse environment, there will never be a situation in which everyone is happy and satisfied. At best, the writers of the complaints are then others.

What many aspiring pool operators also do not say or do not want to admit: if parameters are changed to make the way free for them to significantly filled pools, other pools must become smaller or give up for it. Unless of course the ambitious SPOs focus not on the stake delegations that are already in other pools, but on the stake that is currently unstaked or custodially staked.

So far, in the bootstrap phase, a few had to decide and then endure. Someone told me that will be a lot of fun then in Voltaire.

1 Like

I think you are overestimating/-stating the quality of the RSS research a bit.

1 Like

Totally. If we do get a fair playing ground then the OG multi-pool operators won’t be happy because their anti-competitive moat they obtained simply by being early, will be removed.

1 Like

Is it, though?

It is first and foremost proof of stake. And stake is not equal access to all by definition.


From my understanding they are keeping k=500 and minPoolCost = 170
But I think the most votes has option with k=1000 and minPoolCost = 170


this is a partial understanding.
I recommend to read the recommendation of the parameter committee and the reaction of the Cardano Foundation again carefully

A lot of text and pretty charts rehashing mostly things we already knew.

“So far, no one from the community grouped or ranked these opinions.”
I asked on the forum and SPO calls about whether these comments be studied and analyzed by Param committee and was told in both cases: ‘sure’.

“We can clearly expect a high competitive pressure for small pool operators (right half in the chart) to go to the new minimum, and so halve their operational budget. The larger pools are not so much affected by it.”
Not sure it’s that clear, will depend on the effectiveness of 170 fixedCost on various wallet rankings I presume (since while 170 improves projected ROS, when comparing to more than half-filled pools it’ll still be inferior I am guessing) - effect on larger pools will probably depend on the former too to some extent… also will be interesting to see what 2nd and later pools of MPOs that don’t have as much stake do, I am guessing not too much as the mostly have rarely moving delegators.

“is to replace minPoolCost with a minMargin. This is therefore not a simple change of one of the existing parameters but would only be feasible by means of a hardfork and the introduction of a new parameter, which shall not be part of this analysis.”
Yes we have been hearing about this for years now, any ideas a part of what analysis WILL min margin ever be?

“especially the smaller pools - which mainly demand a reduction of minPoolCost”
Eh, yes, what an amazing coincidence, the pools most disadvantaged by the minFixedCost are the main voices to have the floor lowered.

“Staged implementation is reasonable” - sooooo, when stage 1?


Waiting for the other governance key holders? Maybe even trying to put some pressure on them with this “We are ready to do it.” communication? (But just my personal speculation. I would be much more nasty towards IOG, but it’s clear that CF cannot be – even if they wanted which I do not know.)

1 Like

It’s good to hear that the PC might add a few new things. That is one of its tasks.

so you interpreted this sure as nobody else should or could do it meanwhile?

The assumption is based on the clear majority of answers in the survey. Why do so many choose this answer if they do not plan to use it?

there can be many such analysises. I did one in order to estimate which min margins would result in similar and not more operational costs per epoch. Turned out 3-5% without any fixed min Fee would result in slightly less up to same operational costs as we currently have with min Fee.

The more important analysis has to happen at ledger and security levels. Afaik this is a current workstream, where they already can say a halving and potentially complete removal of mPC is ok. I have no concrete information about the state of a min Margin. (reminder: the Parameter committee cares and focuses on existing parameters. it is not a parallel research and innovation entity)

As soon as a majority of genesis key holders agrees on the execution.
I don’t expect there is a problem on the recommended parameter value. It is probably more relatded to some intersecting reorgansiations

1 Like

I don’t know about you Marcus but when someone I know is inventing a wheel, I find something else to do…I interpreted the “sure” as “when the much awaited quarter of a year later write-up gets produced I hope there will be more than just a link to a json with regards to SPO voting comments”. You know, like a maybe a little grouping / tally of comments by category/option being suggested/etc. From memory things like pledge effectiveness, pool splitting disincentivizing need, etc were mentioned by voters but don’t get referenced in these postmortems (maybe for ‘too hard’ basket).

“As soon as a majority of genesis key holders agrees on the execution.” - it’s like answering with “when parameter change request gets finally submitted on-chain” - please don’t feel obliged to answer every point.

1 Like