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

I believe in the post you are referencing the mention of “higher pool saturation” refers to how much stake is in the pool, not to how high the saturation point is, because how much of your pledge benefit that you realize does indeed increase with total stake in your pool. What I am referring to is the saturation point that is determined by k, if this saturation point is lower while a pool’s pledge remains constant then they realize greater pledge benefit.

I agree that changing k alone is not driving decentralization where we want, this is after all only a single knob. Turning this knob up over time however has also increased the relative importance of the a0 knob which we have been reluctant to turn at all, I think it would be a mistake to reduce k without first trying to tune from the a0 perspective as well. We are also turning the min fixed fee knob, and while I don’t think this will drive stake away from where it is currently it should at least make people more open to a wider array of pools.

1 Like


You have pointed out something that I hadn’t completely appreciated:

If K is increased then this makes it viable for more whales to earn increased yield through running private pools 100% pledged. With K=500 you have to be a mega-whale with 68M pledge to fully saturate your pool and get that extra yield. With K=5000 then now you only need 6.8M pledge to get this extra yield.

Also checkout the fantastic calculate created by @dstratio

The more we increase K within the current framework, the more whales will enter the range that can benefit from the far greater returns for 100% pledge.

If you think this doesn’t matter much then here is how I would game the system if I was a multi-pool operator with plenty of pledge:

Let’s say I had 17M Ada and K was increased to 2000. Now I can run a fully saturated pool with 17M pledge to earn extra yield. I would do that and also continue as a multi-pool operator with almost no pledge in my mult-pools for the community because these are still additionally profitable.

Hence, I think we need to be careful about increasing K within the current framework. And, I can definitely see reasons for reducing K within the current framework.

Agreed. Let’s both start making charts of the entire problem space at various values of the parameters just like @brouwerQ did. I’m working on that now. You should also!

Only the biggest most elite whales earning the best rewards (boost after >90% pledge >90% saturation) isn’t exactly ideal philosophically. That does not align with my concept of ‘fair’. I need to replicate the charts and work on some variations of the parameters (a0, k) generating the gradient field ( 0 to 100 pledge, 0 to 100 saturation ) for each.

1 Like

I think it will be a mistake to increase K.

Yep. Not fair.

Plugging some values into @dstratio calculator (leaving a0 unchanged at 0.3) and changing fixed fee to 30Ada.

K=1000, fixed fee 30Ada

  • K=1000, poolsize=34M, pledge=100K => Yield=4.28%
  • K=1000, poolsize=34M, pledge=1M => Yield =4.32%
  • K=1000, poolsize=34M, pledge=34M => Yield=5.55%

K=2000, fixed fee 30Ada

  • K=2000, poolsize=17M, pledge=100K => Yield=4.29%
  • K=2000, poolsize=17M, pledge=1M => Yield=4.36%
  • K=2000, poolsize=17M, pledge=17M => Yield=5.55%

The more we increase K the more whales can benefit from this increased yield by spinning up fully saturated private pools. Currently, with K=500 you need to be a mega-whale with 68M, so probably only IOHK OGs will have this and since they are building the system, I can live with it. However, if K was increased to 2000 or even 1000, there are many more whales large enough to exploit this.

Ada has a fixed cap supply so extra yield earned by some is at the expense of the rest of the community.

I support the fixed fee being reduced to 30. However, I do not support K being increased to 1000 or 750 within the current framework and incentive structure. In fact, I support K being reduced.

I keep on harping on about it, but the real threat is staking via smart contracts. These defi lending platforms are going to control literally massive amounts of Ada. They might start to make Binance look small.


The change in K will have no effect on fully saturated pools, but it could actually decrease a whale’s rewards. If somebody could only self-saturate 1 pool with ~68 million then after K change they can fully saturate 1 pool then half another, their total rewards will be less because ~20 million of their stake is now in a not saturated pool.

The reduction in fixed fee is absolutely essential. It needed to have been done a year ago. It’s been horribly damaging to the ecosystem, particularly by making pledge appear to not work. The ‘hurdle rate’ Colin wrote about also becomes the minimum accepted pledge value. Any pools with pledge below the hurdle rate are faced with the exact same challenge as a sybille attacker’s pool. They have to convince delegates to accept poor returns by promising better returns later. As pledged pools fail this challenge they leave an anecdotal record of poor returns that anybody can search and use as examples of pledge not working. A bad-actor in the system will always have an easier time attracting stake if put on a level playing field as others because they have no moral bottom and are willing to lie and cheat. The fixed fee was meant to deter a sybille attack, but ended up just forcing bad education onto delegates who are now more than happy accepting poor returns and thinking they are helping the network by doing so. The hurdle rate needs to always be set within the actual set of public pool pledge, which is about a million or less. So a change to 30 fixed OR LESS is a must.

Delegates have been seasoned to accept really poor returns because of the fixed fee. Besides changing parameters, there needs to be a huge push by IOG and the community to educated delegates on how parameters work and how each effects their rewards. Delegates say they want good returns, but don’t know how to get them.

When delegates try to get the best return on their stake they accidentally force pools to consolidate their pledge to compete with other high return pools. Unfortunately, the min fee has been too high, so even when pools consolidate their pledge they are below the hurdle rate.

Changing K will hopefully stimulate delegates to research new pools and begin staking rationally.

Sitting on the fixed fee change waiting for feedback is foolish. It needs to be changed today…


Do any of the concepts from these CIP have a place in the conversation?


This comparison is wrong.The 1.1M stake pool will also have some epochs with zero blocks and some epochs with two (or more) blocks which will result in earning more than 340 ADA per epoch on average. You can’t ignore this at this scale.

OK @brouwerQ, say I have 1M Ada to stake. Please advise me what return I could expect from staking my 1M Ada to a pool with 100K total stake currently.

Correct. Lowering k will result in a certain pledge amount in ADA being a smaller percentage of the saturation point and lower the pledge benefit. However, increasing a0 won’t make much difference either, because almost all public pools have a pledge of less than 10% of the saturation point. Increasing k to e.g. 1000 will change this 10% into 20%, but this is still small with the current pledge formula.

Correct, this will give them 30% more rewards, but nobody is talking about k being 5000 at the moment. We’re talking about 750 or 1000, so you’ll still need 45M or 34M (and this increases with time when the reserve depletes).

If on average you’re producing 1 block per epoch, you have the following chances of producing x blocks in a certain epoch:

  • 0 blocks: 37%
  • 1 block: 37%
  • 2 blocks: 18%
  • 3 blocks: 6%
  • 4 or more blocks: 2%

So if you take 680 ADA as a constant block reward (as you do in your example, the current one is already lower and decreasing instead of staying constant) and zero margin:

  • 37% of epochs will give 0 ADA to pool and 0 ADA to delegators
  • 37% of epochs will give 340 ADA to pool and 340 ADA to delegators
  • 18% of epochs will give 340 ADA to pool and 1020 ADA to delegators
  • 6% of epochs will give 340 ADA to pool and 1700 ADA to delegators
  • 2% of epochs will give 340 ADA to pool and at least 2380 ADA to delegators

So on average the pool get about 215 ADA per epoch and delegators get about 465 ADA per epoch instead of each 340 ADA… You should use those numbers for the small pool in your example.

1 Like

So what average yield is that for the small pool with current 100K total stake (and using current 636 Ada block reward)?

By comparison, I can get 4.32% yield currently if I stake to a large pool with 60M total stake.

Couldn’t you both just agree that it is still – just looking at the numbers – significantly less profitable to delegate to a pool in the 1 million range than in the 10 million range, although it is (due to the relevance of oscillations in number of blocks) not as bad as a calculation with 1 block per epoch would imply.


Sorry. Need to stay calm while delineating economic reality.

It is economically non-viable to delegate to a pool with less than 10M total stake if the min fixed fee remains at 340. If the min fixed fee is dropped to 30 then it becomes economically non-viable to delegate to pools with less than about 1M total stake. If your pool is small then this is the reality for any delegator that is interested in earning rewards.


The times when you get 2 or 3 blocks instead of 1 do indeed help your returns, but nowhere near enough to offset the huge gap created by the minimum fee. Your rewards for delegating to a small pool (1 MM) are about 1% less on an annualized basis. That is, 3% instead of 4% or you are giving up a quarter of your rewards.


The chance of block production is a binomial distribution, in the current environment it’s pretty close to this for a 1MM pool (I have a 5% block loss in there, which is why it’s not 21600 blocks). In the periods where you generate a 2 blocks, you get paid double, but the fixed fee only is paid once.

Another way to think about that is that the fixed fee is actually 42.8% lower than the listed value for the pools - so 1 MM pools “effectively” have a minimum fee around 195 Ada/epoch. (so… yeah, you can make a joke about a minimum wage only for the rich and for the express purpose of keeping the poor down here.)



Anyway, if the minimum fixed fee was set to 30 Ada, a delegator (motivated only by the staking reward) would be indifferent to staking with a “nearly saturated 3%” pool and a “1MM sized 0% pool”… assuming both had a minimum fixed fee.


(it may be difficult for a delegator choosing a stake pool to actually know that though - the headline variable rate does seem to be weighed too heavily by delegators - pool size and fixed fee tend to be overlooked.)



As promised here are charts. This is the current reward level as a function of pool saturation at various pledge fractions from 0% to 100%. a0=0.3 and minFee=340.

Clearly being a whale and pledging to a private pool is what the reward formula was designed to favor.
Most operators have far less than 20% pledge so multipools have become favored for operators.

What happens if we drop minFee to 30?

Whales which pledge into private pools still earn higher rewards.
It is far easier for small pools to provide competitive yields exceeding 4% (on average).

What happens if we keep minFee=30 and increase a0 to 0.5?

Yields would drop for most people and only a couple dozen ultra-whales would retain yield.
Increasing a0 clearly only benefits ultra-whales pledging to private pools.

What happens if we keep minFee=30 and drop a0 to 0.1?

Yields increase (4.2% to 5.1% for most people) and the ultra-whale advantage decreases to a half percent.

Decreasing a0 to 0.0 removes the ultra-whale advantage entirely and most of the reward equation.

For now, let’s discuss and debate the principles of the Cardano reward equation.

  • Do we want ultra-whale pledge to have a yield advantage? 0.0% 0.5% 1.0%?
  • How harsh of an on-ramp do we want?
  • What should diminishing rewards based on stake look like? (currently based on k)
  • What should diminishing rewards based on pledge look like? (Nothing yet)
  • Should a0 be transformed from the ultra-whale boost parameter to a complement of k but for pledge? (would require a new equation and hard-fork, however no new parameters)

Other Open Items:

  • Rename k-effective for @Colin_Edwards ?
  • I will be happy to lead creating an equation and CIP based on our principles with diminishing rewards for stake (based on k) and diminishing rewards for inadequate pledge (a refactored a0).

I couldn’t wait…

Yes! I’ve read both and have taken inspiration from both.

  • It doesn’t feel ‘fair’ for an ultra-whale pledge have a reward advantage OR disadvantage.
  • A slight and adjustable on-ramp is not a bad idea. With a parameter change it can be dropped to 0.
  • In principle k should govern only maximum pool size and diminishing rewards. k should be set higher than the current network decentralization of block production, but not too high. We don’t need single groups like Binance collectively using more CPU’s, NIC’s, and RAM than a Solana node. That’s dumb.
  • In principle a0 should govern the influence of pledge. The more you pledge the larger your pool could become. The way I would use a0 would be very similar to @TobiasFancee implementation in his CIP. I give him credit and have borrowed his idea of a maximum pledge leverage ratio for pool size. This parameter should start out high (a0 = 50-100), and be reduced slowly over time with care. By requiring pledge dividing pools will not be favored.
  • I don’t think any new parameters are necessary unlike @TobiasFancee and Casey Gibson. Also, I just don’t like the way the a0 parameter is currently used for the benefit of ultra-whales. I’m not going to use the R/(1+a0) term.
  • The equation should be computationally simple and elegant.

This is what I have so far for the rewards function F :
R = ((reserve * rho) + fees) * (1 - tau)
F( pool_stake, pool_pledge ) = R * min( a0 * pool_pledge , min( pool_stake / total_stake, 1/k ) )

So, what does this look like?

  • minFee = 30

  • k = 500

  • a0 = 10 (a >10% pledge pool could reach the pool size saturation based on k)

  • One important characteristic is that the maximum yield gets very flat and very fair. This is intentional and by design.


I just want to interrupt this with a note about model risk. The platform will need to adapt and evolve over time, so change is both something we anticipate and also will require. Sidechains and other scalability solutions will require changes, and the growth of the platform is even now largely moving in directions that we not entirely foreseeable when the platform was being developed. At the same time, we need to have those changes to be stable and predictable as possible; we don’t want the fundamental rules arbitrarily changing underneath people’s feet.

It’s helpful to think of updates as one of 3 things:

1 - Ledger Changes
Ledger changes need to be raised as CIPs and the time frame for implementation is much longer than for parameter updates. The the CIP forums have some of the discussion and their is a biweekly call to discuss issues. I highly encourage you to engage with that process.

Cardano Improvement Proposals

CIP Bi-Weekly Meetings

2 - Parameter Changes that represent a change in direction

Some parameter changes represent a conceptual change in direction. While these certainly have a lower barrier to change than CIPs, these will need to have overwhelming popular approval or go through some form of governance.

I don’t have an ETA for the governance - I am not strongly tied into that process; it’s complicated. Some parameters are fairly opaque in function and have significant public misconceptions about what they do. Having a straight up public vote about parameters every 36 hours may sound like an easy solution - but even on these there needs to be a long-term direction and consistency. There are trade-offs as well: decentralization, performance and security are a famous example from Vitalik Buterin … but even things like the staking rewards creating a barrier for people engaging in other forms of economic activity need to be considered.

3 - Parameter Changes that represent staying on course

Some parameters need to be periodically adjusted as the price of Ada changes and to respond to changes in the ecosystem (like rewards being release from the ecosystem.) These are about the only things that, as a custodian of the platform trying to keep it on course, we can really change right now.

For economic parameters: the minimum pool fee, the fixed transaction cost, the portion of transaction cost based on byte size are the main ones that need to be updated as the price moves and as the reserve get drawn down. (The changes to K were previously discussed as a several step change, so this is again trying to deliver on that commitment - not as a change of direction, but staying on a course that was previously set.)

For non-economic parameters: the block height, the size of scripts, the timing of blocks could all be changed.

The whole point of that is: these are great ideas - but they I don’t want to tie up the “stay on course” discussions with the “change the ledger rules” types of changes. They are both important - but they operate on different time scales.

1 Like

I’d like to reference portions of your blog post from 1 year ago:
Not long till ‘d’ (=0) day

This did not create an opportunity for more [groups] to create blocks. The actual distribution of block production by groups is equivalent to a k of only approximately 41 on average. It’s not even close to the intended 500.

The last year is proof of you were correct with this statement. Real decentralization hit a ceiling.

You didn’t mention that was designed to allow groups like IOHK to earn 1.0% more staking yield than everybody else. If that economic benefit did not exist for IOHK you would have the economic motivation to delegate to small pools for the same reward and improve real decentralization, k-effective. This is why I removed the current R/(1+a0) term, decided to totally re-factor how the a0 factor was used, and use a reward curve that is intentionally flat until pledge/k diminishing limitations.

I agree!
As you can see, I’ve accurately modeled the reality of the rewards formula and network decentralization (k versus k-effective)*. With 1 more year of observations after your blog post it’s obvious decentralization has not materially improved. I believe that delivering on the decentralization promise will deliver more economic benefit to the Cardano ecosystem than allowing a dozen ultra-whales to earn 1.0% more staking yield than everybody else.

I’m going join the bi-weekly meetings when I can and do my best to help IOHK researchers and analysts deliver a CIP Ledger Change for modifying the rewards formula.

*I still need to include the ‘shadow’ no-ticker saturated whale pools into k-effective :frowning:


I’d like to reference portions of your blog post from 1 year ago:

(1) I pride myself on being an empiricist, which means I get to change my mind as soon as evidence comes along that shows something different. My understanding a year ago is not the same as my understanding now. I don’t feel bad about that at all.

(2) The blogs represent a certain degree of talking the company line, in that a lot of the more technical descriptions get watered down to make them more accessible. There is a degree of nuance that is lost when that happens - and to be honest - I think we erred too much on the side of making it seem more simple than it really was - as if we were just turning a knob from “more centralized” to “more decentralized”.

This did not create an opportunity for more [groups] to create blocks. The actual distribution of block production by groups is equivalent to a k of only approximately 41 on average. It’s not even close to the intended 500.

Just want to mention that K doesn’t represent a target number of pools; K sets the maximum size of the pool. (If all pools were fully saturated, K=500 represents ~350 pools.) So a K of 41 would only represent 30 pools, not 41.

The main value of K is to get more pools closer to the “saturated” size, even if it involves pools splitting. Being nearer to the saturated point tends to advantage you in terms of economics, where smaller pools running at a loss can’t offer a better return. (There is a secondary benefit, in that it tends to force a redelegation event for the largest pools, but that is not the direct intent.)

You didn’t mention that was designed to allow groups like IOHK to earn 1.0% more staking yield than everybody else.

It’s designed to make it such that a large player is not financially motivated to split fully saturated pools into numerous smaller pools. The best returns are to have a very low pledge relative to delegation, and benefit from that. While fully pledged pools are more profitable - you are forgoing all the public delegation you aren’t getting “for free”.

In general, using private, fully pledged pools does give better returns compared to staking to community pools - but it is certainly a lot of foregone revenue relative to running a large number of public pools.

This is set at a level to keep the economics about equal for a fully saturated pool vs. splitting into two 50% saturated pools - and earning returns from those.