Minimum Pool Fees (with a brief mention of K changes)

Minimum Pool Fees

This is background on proposed updates to two parameters: ‘K’ and the ‘minimum fixed fee’. Much of this was discussed at the discord call; this note doesn’t add new material. This note is primarily intended to summarize what was talked about and to facilitate a continued discussion.

Just to reiterate - these are changes up for consideration and I’d love to hear any constructive feedback.


Minimum pool fees are one component of the staking rewards formula. They are one of the more problematic pieces because the relative importance of these fees drift over time and need to be periodically reset to keep the same relative importance.

The primary goal of the minimum fees was to add an additional layer of protection against sybil attacks; an attempt to take over the network by creating large numbers of zero fee pools. The purpose of the minimum fees was to make it impossible for small pools starting out to economically compete with larger, established pools until they had reached a certain size (for example, by an SPO providing an amount of pledge.)

Over time, these minimum fees have changed from being a minor portion of the rewards formula to the single largest component. In 2020, pools could be much larger and were benefitting from a larger reserve (which acted to incentivize early adoption.)

Note: ‘Saturated’ in all the charts below means that a pool is optimally sized to maximize rewards. This size changes over time due to release of Ada from the reserves as well as another parameter, K, which controls how large a pool can be as a percentage of the released Ada.


In Dec 2020, we move K from 150 to 500. This is a parameter that controls how large a pool can be (and reduces that income that comes from the variable fee.) At the same time, the variable rates tended also tightened, with 1% being a very prominent number.


In March 2022, a saturated pool is 68 MM Ada. The effects of the minimum fixed fee are far more pronounced on smaller pools - like a pool with 10 MM delegation (a pool size that many people would consider “ not very small ”.)

The impact of this is troubling – we have moved from a distributed consensus, where a price is set based on a competitive market mechanism, to a price set by the minimum fee. A prominent viewpoint even being that the minimum fee should in fact represent a point where a pool can run profitably: eliminating any need for a price above the minimum allowed rate.

Implications for Security

The sybil protection aspect of the minimum fixed fee means that a pool needs to reach a certain size to be able to offer competitive economic rewards for delegators, which to me tends to mean within about 0.1%: meaning I am mostly indifferent between a pool that rewards 5.0% vs. 5.1%. (In my modeling, it means new delegators might choose to receive a 5.1% return, but existing delegators will not move for that.)

Originally, pool offering a 0% variable fee needed to reach several million Ada prior to being able to offer a competitive return with a saturated pool that took several percent return. In 2020, this would have represented an economic investment of 200K USD to clear that hurdle rate.


In the current economics, this has drifted even further – a pool with a 0% variable fee needs to start with over 10 MM USD in stake to offer a competitive return with a larger pool charging 1%. At current market prices, this is nearly 10 MM USD to clear that hurdle rate.

These has led to an unpassable hurdle rate for many pools – unless they can start at more than 10 MM Ada, they have no ability to organically grow. Not only with profit minded delegators not choose to delegate initially, but they are in fact strongly motivate to switch with larger pools: asking delegators to take a 3% return instead of a 5% return is a difficult sell.

The Change to K=750 (or K=1000)

K is the parameter that caps the maximum profits for a pool, such that attracting more delegators just splits the existing rewards between more people rather than add to the rewards. The other significant impact is that any pools over the new size cap will need to have delegators switch to a different pool. This will also be motivation for pools that are over the size cap to split into two smaller pools.

The impact of the minimum fee changes from being 38% of the total rewards to a bit more than 55% of the rewards. Whenever the fixed fee is more than half of the rewards, this means any pool that successfully splits into two is more profitable immediately, rather than the current situation where splitting requires additional delegation to become more profitable.


Obviously, running multiple stake pools is a contentious topic among the SPO community. As soon as the fixed fee represents more than half of the total rewards, the financial motivation changes from “spin up another pool as soon as all my existing ones are totally full” to “it makes sense to run two half-full pools indefinitely.”

What levels are appropriate for a fixed fee?

The necessity for the minimum fixed fee follows much of the same logic as a minimum wage vs living wage arguments; I am not going to reiterate those here.

There is a great write-up about alternative formulations for the minimum fees; if you are interested you should check that out. This would require a change to the ledger rules, not tweaking a parameter, so it is a much larger change than what I am discussing here.

There are a wide range of minimum fees that could potentially work; the current levels are too high, but that doesn’t give a lot of guidance as to what the goal should be.

The proposal that best adheres the initial specification of the minimum fixed fee, in my opinion, is to move the fee from 340 Ada to 30 Ada. This would reset the relative sensitivity of the variable fees and fixed fees back to their original levels, and it also closely matches the original fiat values of the fee, which was originally set to around $5.25 / day. That will not fully compensate pools, the intent was that the variable fee would be useful in more situations than just when demand for staking far exceeded the available capacity of stake pools.

The other key outcome for moving the minimum fee to 30 Ada is that it brings the minimum viable size of a pool from over 10 MM Ada to slightly over 1 MM Ada, about the point where a pool becomes block producing. (By minimum viable I mean that the opportunity cost for staking to a small pool with a 0% coupon is no more than 0.1% annually, compared to staking with a nearly fully saturated pool with a 1% coupon.)


Small pools are still disadvantaged, the current specification with the sybil resistance requires that to an extent, but the playing field would be significantly more level. Pools that can get to 1 MM Ada are now reasonable alternatives rather than obviously bad choices (even with a 0% fee!)

Concerns about changes to the minimum fee

I am very aware that any changes to the minimum fee are very controversial. As it has increased in importance from being a small tweak to help sybil resistance to a primary mechanism to fully compensate pools, such that any variable fee is just an extra bonus, it is now huge part of the total rewards.

Concerns from existing profitable pools about a race to the bottom for pool fees is a major concern for us as well.

The very fact that the change is controversial underscores with how much it has gotten out of control – so much out of control that it is now an obstacle to making other changes (like the K change.)

Happy to try to answer additional questions here


The sooner the min. fee gets reduced, the better. Imho it should have been reduced a year ago.


I am not sure, and without long long explanation I would just paste a graf of the CIP23’s “solution”.
Who with familiar with math and graphs would understand what does it mean.
Check the local minimum of the blue line (op rewards) and the below purple (member rewards)

In simple words, there is an economic incentives to create pools with pledge left to the local minimum than do full pledge. Meaning economic incentives to split pledge and create smaller pools, that leads to non-single-pool operators (whales are different, they need to have multiple pools when their pledge > than ~68m atm). This applies to the original reward function, I just modified it to the Tobias’ Fair Min Fee . And it does not matter how anybody adjust the a, k, as the problem is with the reward distribution/split function and not in the reward function.


The proposal that best adheres the initial specification of the minimum fixed fee, in my opinion, is to move the fee from 340 Ada to 30 Ada.

I fully support this. I’d rather it was 0, but 30 is a huge step. I’m a small pool (WEN_K, formerly CODER :smile:) who has announced they are retiring specifically because the min fee makes it impossible to attract delegators (unlike some pools, I’m not one to claim that “small pools give the same rewards averaged out” to try and win delegators). If this change goes ahead/is given a date in the near future, I would absolutely keep the pool running.

I think k should go way further than 750. I set my pool up when it was supposed to be moving to 1,000 and that was almost a year ago. Forcing some stake to move around at the same time as making smaller pools more attractive would be a great way to hugely increase decentralisation. Yes, big pools will split, but the gap will be much smaller so the more ADA that’s forced to move, the more likely some will end up spread across a large number of operators.


I understand the whole reasoning, but I’m against such an abrupt change. A more gradual change would be better imho. E.g. first changing it to 250 (then it’s already below that half of the profits thing in your example) and a couple of months later to e.g. 150 and so on. Also, basing the new value on the current price of ADA is a bit dangerous because that price could quickly change dramatically (in both ways).

I also think the pledge formula should change at the same time, so that pledge differences in the lower regions (e.g. 100k vs 1M) matters more so that with a k increase, pool splitting is further disincentivized and higher pledged pools can more easily compensate a lower min fee with a higher margin while keeping expected ROA.


I completely agree with Dan’s opinion.

And to add some extra thoughts:

Relying on the minimum fixed fee for the stake pool’s income is wrong. The margin should not be 0. The margin should provide the stake pool’s income (take a look at other PoS blockchains, too). What is the incentive for the SPO to run a high quality service (doing his/her best to mint all blocks in each epoch), if minting one block will bring the same rewards for the stake pool as minting 10 other blocks in an epoch? Those extra blocks mean a lot for the delegators’ incomes, and they also mean something for the SPO if the margin is not 0%.

Running a stake pool with minimum fees, but complaining when the minimum fee is decreased, is like saying to the delegators “I want to run the stake pool with the lowest possible fees, to maximize your rewards”, but in reality this is not true. I know this is not a popular opinion.

I personally don’t think adjusting the minimum fixed fee will start a race to the bottom for the pool fees. It will probably cause some adjustments, to make the fees more predictable, regardless of the total stake. Dropping the fees to the minimum without running a quality service and without providing some extra value in the community will not have success in attracting and keeping delegators, in my opinion. But I guess time will tell.

Edit: I support a minimum margin. It should probably be somewhere between 2% and 5%.

Edit 2: I agree with Tom, too, it should have been done gradually, but starting last year.


Unfortunately this change has been necessary for a long time, I don’t think this is something that should be delayed by a gradual decrease. This is especially important considering that k is also changing (hopefully to 1000). With all the stake that will be incentivized to move with the change to k, it’s important that smaller pools are able to offer competitive rewards with larger pools. I think it would be a huge mistake to change k to 1000 and the min fee to 250 and effectively force delegators to ignore small pools again because their rewards would be eaten up by the fixed fee.


This is such incredibly valuable and thoughtful feedback from the community. I see a common sentiment from the majority of the community and that is reflected here. A loud minority of SPOs are vehemently opposed, but these replies show how reasonable most find the proposed changes. I agree with Prometheus, Georgem, BrouwerQ, and DanTup in their additions. The minimum should be decreased and quite dramatically, it’s overdue and past the time for a gradual adjustment. Even as far as 0 fixed with a shift to minimum margin is a brilliant and makes for a much more level field for SPOs of all size. That’s also why I support the idea BrouwerQ mentions in incentivizing pledge differences in lower regions. And absolutely K to 1000 at the very least. Cardano community is strong, we will be here and we will weather any storm… together.


Yes, good proposal. Do it.


Race to the bottom concern is a bit over-rated imho, do we have some evidence of such a race taking place and having unwanted side-effects today elsewhere in crypto ecosystem? People that run pools with below minimum requirements specs take risks and sometimes pay the price for those risks, the network itself is a lot more resilient than even a moderate percentage of block producing nodes failing to create a block in a timely fashion. So similar to Dan, would prefer lower end of fixed fee removed entirely (we had this for 6 months of Incentivized Testnet on Rust before Shelley mainnet, I presume data from that network has been studied in detail? Do we have any published analysis from that related to ‘race to bottom’ etc?)

And of course k = 1000 change would be a lot more welcome than k = 750, given we have over 1000 stake pools already making blocks per epoch (and hopefully there’ll be at least partial overspill after k change to increase that number even further - to 1500-2000 range.

I could say a few words about how long overdue all these things are but I think I’ve flogged that dead horse enough across various social media platforms over the past 12 months - so I’ll just say good to hear from you again, Colin! And hope these changes happen sooner rather than later, via whatever governance/decision making hurdles they need to jump over if any.


Many people arguing to reduce the minimum fee drastically and even to zero are not appreciating Colin’s point. The primary goal of the minimum fee was not to establish some minimum wage for a pool operator.

I am also in support of the minimum fee being reduced in line with what Colin has proposed but I do have some reservations.

A reason why we don’t want lots of tiny pools

I would point out that we don’t want to have more tiny pools generating 1 block per year. The problem with such pools is that they become relatively disconnected from the main core network producing blocks. This results in these pools having poorer block propagation. Making matters worse, there is a temptation for these pools to remain disconnected for extended periods whilst just running their leader logs. Only when they get awarded a block they connect up just in time to produce their block. The rest of the network has very poor connectivity with such a pool behaving this way.

If you only get awarded 1 block per year are you going to keep your server well connected and well maintained for the other 364 days of the year?

Also, the P2P mechanism tries to connect to other nodes that produce and receive blocks the quickest. Having lots of tiny pools producing very infrequent blocks is likely to work against this.

Note that having lots of tiny pools that get 1 block per year does extract a cost on the entire Cardano network. It causes propagation delays and more forks which is wasted resources.


Tiny pools don’t stand a chance with the current fees. I’ve been running my stake pool without minting any block for 8 months, until I received the IOG and then CF delegations. And this also has not brought my stake pool more than a couple new delegators.
Many tiny or small stake pools are paying back the delegators a part of the minimum fixed fee now, and this costs them extra transaction fees and other complications (like tax implications for some of them).
This new minimum fixed fee would give the tiny stake pools a chance to compete at fees and ROA with larger pools, until they grow enough to have more incomes than expenses.


I want to take this comment and point out something I think is really important - as an individual, not as a representative of IOG.

While I happen to personally support this idea, it represents a change in ledger rules and rewards formula. Those represent a change in direction and have a much higher barrier to get done.

On the other hand, there are things that, as good custodians, we need to periodically do in order stay in order to stay on course with the existing mandate. We need to make sure that changes these changes do get done in a timely manner for any governance to be meaningful.

Conceptually, keeping these separate will really help as we transition to Voltaire; to make sure the platform can evolve (but not too fast), but when a direction is chosen, we stay without so decisions get tacitly rolled back by inaction.

That was in fact the original plan, it got derailed in part because of the CIP process. The personal take-away for me from that was that even if a “change in direction” would solve the issue, you shouldn’t delay the other “stay on course” work because of it - they operate at different timescales.


Well said, Colin, and thank you to everyone for the insightful, reasonable conversation. And you’re right on the parallel paths of work they may be frustrating at times, but in the long-run you’ll be thankful to have kept options available and developed. That gives the ecosystem agility.

Can you explain this in more detail? I’m not sure I understand why having small pools producing infrequent blocks would become relatively disconnected or cause poor propogation. I also feel like poor propagation is something that can exist regardless of min fees/small pools and should be a self-correcting problem (eg. higher chance for your blocks not to be adopted, which looks bad for your pool and will lose you delegators). There should be motivations to run your pool well that do not stem from the min fee, because large pools need to also motivated to do this.

FWIW, I would also fully support a min variable fee. I understand that it would require more changes than just changing the current value and reducing the fixed fee should definitely not be help up on it, but my desire is that small pools are not penalised so harshly, and not particularly that pools are able to run with very low fees.

@Colin_Edwards I’m also curious about this:

The primary goal of the minimum fees was to add an additional layer of protection against sybil attacks

I thought pledge/a0 existed for this reason. If that’s not the case, it would be really useful to see a full list of all variables and exactly what their intentions are. If SPOs/ADA holders are expected to vote on things like this in future, it’s really important we fully understand the role of each parameter.


Guys why not relate the min pools fees to the price ada is trading. Almost like a difficultly factor we see in traditional proof of work networks. Why cant we learn from older networks, some things they did get right :wink:

There are a number of reasons why more pools is not always better:

  1. More pools requires more connections between pools in order to propagate blocks. The number of connections increase exponentially as number of pools increases. Obviously there is a trade off here with increasing decentralisation by increasing number of pools. The parameters used by IOG in the design seeks to push the system towards a certain number of pools which are more or less equal in stake distribution.
  2. There is less incentive to run small pools properly during epochs where they are not awarded a block. This should be pretty obvious. Humans are naturally lazy. Pool operators can run leader logs ahead of the epoch and check if they are awarded a block. If no block is awarded then what is the incentive for them to remain online and running well. Will they update their software. I mean, it doesn’t matter right? They can just check next epoch leader log and they still have time to update. Pools that behave like this are not reliable Cardano network citizens. After all, what is the real purpose of the nodes? They are there to do the job of being well connected, quickly transport blocks around, receive incoming connections from wallets about transactions.
  3. The node can only run fast with a limited number of connections to other nodes. This really is just point 1 restated. For your node to run most efficiently receiving / propagating blocks quickly, you need to choose which other nodes you connect to. Connecting to other nodes that receive blocks the quickest is beneficial for your node. Your node can’t connect to every other node.
  4. Building on 1 and 3 further. The P2P mechanism automates this process with the protocol seeking to connect preferentially with nodes receiving blocks quickest. Will this result in tiny pools being less connected? If a heap of tiny pools all fire up their P2P mechanism they will all try connecting to the fastest pools. Will this result in too many incoming connections to these bigger pools?
  5. Finally there is the problem whereby tiny pools that do get awarded a block actually have an advantage when their block conflicts with another block either when a slot battle occurs or when there is a single block fork resulting from propagation delay. See here for more information, but basically, the tiny pool has a lower VRF score so it wins these battles with its block being adopted even though its block was more delayed: Consensus should favor expected slot height to ward off delay attack · Issue #2913 · input-output-hk/ouroboros-network · GitHub
    Is it good for the system to reward the tiny pool because it delayed its block propogation? The pool I run is smallish but does produce a block or two almost every epoch, I lost one of my blocks because another tiny pool’s block was delayed by 30 seconds (THIRTY) which resulted in a 1 block fork, which was resolved by the protocol using the VRF score, which the tiny pool won. Forks like this are wasted resources. Why was the block delayed by 30 seconds before my pool received it? Probably because this tiny pool was not well connected to the rest of the network.

IOG has made a design decision which allows nodes to determine their awarded slots ahead of time.
Don’t get me wrong, I love this feature because I can time when I do updates and restart my node. But this design feature does have consequences.

There is a trade-off between more decentralisation and speed of the network. Ideally we want significant decentralisation but with relatively equally connected nodes.

We don’t want nodes at the fringe occasionally connecting to lob a block unseen by the rest of the network.

1 Like

To be clear, the design intentions was to have k number of nearly fully saturated pools and some tail of pools i.e. Nash-equilibrium.

This does not mean that other type of full (validator) nodes are restricted even it is preferred to have as many other type of full (validator) nodes (relays, edge nodes i.e. Daedalus, marchendises’ nodes, backend nodes etc.) as many we can. The P2P (its hot peers) and even the advise for static config prefer max. 20 active peer connections, due to the limitations of the resources (network, memory, CPU etc).
So, the network can be seen as some kind of 20-ary tree (from POV of any full node for block propagation)
Meaning, your assumption of exponential growing of connections is false. It just simple mean there will be nth level of the tree (hops with some delay) until nearly all of the nodes in the network are reached i.e. they receive a specified block. P2P should be significantly better than that manual or semi automatic settings.

The design does not want to discriminate any honest small (in pledge) pool, what it wants is to prevent creating a large number of pseudonymous identities and therefore to gain disproportionately large influence (proper definition of the Sybil attack). Like what we are heading now. Meaning, non-single-pool operators are growing (i.e. power are accumulating, the opposite we wanted, do not consider the affect of Sundaeswaps reverse-ISO now) and therefore nakamoto coefficient is shrinking. And when we make k for example to 1000 they will split their pledge and will double their pools (incentives to have at least similar profit, ofc decay influences their profit anyway).

And the prediction was that having the game theory specified in the RSS paper will converge to a Nash-equilibrium. But, it seems it has missed something, and I think that miss was that the pools have incentives to split their pledge for gaining higher profit, which makes sense, when operators can earn more when they split their pledge and attract delegators than do full pledge. How can it be solved, prevent them to split or punish their delegators hard (propotionally to their profit) to make them to redelegate to other pools.

So, I am not sure, 1st the principles, and meaning of things (i.e. what do we mean about small pool? Sybil resistance? etc.) should be well defined, meaning everybody has the same understanding of the context.


So, ideally we should see around k number of pools and some tail pools (the design principles of RSS) where:

  • whales would do full pledge with number of (private) pools proportional to their pledge
    • instead what we can see, they creates very small pledged pools and attract delegators by some kind of marketings.
  • all other entities would have only max. 1 pool
    • instead what we can see now, is multiple pools by SPOs gained popularity by fooling (by different ways) ppl.

If we cannot achieve this (Nash-equilibrium) then something is wrong in the RSS, but to have gut feeling, opinions, strong desires to be right what should be done instead of modelling and do proper math.


@_ilap I totally agree with your design arguments. Particularly your comments in the last post. Eventually I believe a better design will be found so that the goals you state are achieved. But this will be a complete redesign from what we currently have which Colin is arguing against in the near term.

But, I am not so sure about your views of the P2P mechanism:

I think your view here could be obtained if someone wise manually configured all the connection settings for every node. However, as I see the P2P mechanism working, each node will try to identify which nodes are most reliable at providing blocks the quickest and preferencing those nodes.