CIP RobinHood - Tune parameters minPoolCost and K


The current parameters overvalue the disincentive (minPoolCost), which in turn devalues the incentive (pledge) to the end user. By tuning some parameters we can balance the two so they begin working together.


minPoolCost: The mandatory fixed fee imposed on all delegators currently set at 340 ADA/epoch/pool. It’s important to note ‘the [minPoolCost] parameter is not part of the original reward sharing scheme’ and has not been simulated. The last two years have been the test of its function and effectiveness. By comparing real world stake distribution with the simulated distribution from {ref.2} we can see its effects on the network.

baseline: The reward rate of a pool with 0 pledge, 0 margin, and 0 fixed fee. This is the best reward rate a sybille pool can offer without a minPoolCost. This is the reward rate of a private pool with just the owner’s stake - ex. BNP & AVENGERS pools. Shown in green {fig.1}.

tipping_point: This is the point on the plotted reward function where the slope of the tangent is equal to 2.5x10^-10. Tipping_point is the amount of stake required to make a pool begin to offer favorable rewards, and also represents the minimum pledge required to balance the incentive of pledge with the disincentive of minPoolCost. With current parameters this is equal to 10M ADA. Shown as the junction of red and black {fig.1}

danger_zone: The danger_zone is the part of the plotted reward function who’s tangent slope is less than 2.5x10^-10. Danger_zone represents the total pool stake the minPoolCost disincentivizes against by offering relatively low rewards. The danger_zone is shown in red and more favorable rewards are in black {fig.1}.

real set of pools: These are pools that actually exist on-chain. The real set of public pledge values are between 0 and 12M with no public pledge between 12M and saturation. Only 3 public pools’ pledge exceed the tipping_point.

sybille attack - an attacker with low stake tries to gain a majority of stake by creating lots of pools with low cost.


The minPoolCost apparently provides sybille protection by making a pool with low stake unattractive. A pool operator can make the pool more attractive by adding stake of their own as pledge to exceed the tipping_point; or, instead of pledging, the operator can campaign for stake delegation.

The tipping_point is currently out of reach of 99.9% of all public pools’ pledge, making campaigning the basis for stake distribution. This centralizes stake with operators that are effective at campaigning but do not necessarily have any stake in the system of their own. Coincidentally, the parameter meant to increase sybille protection can have the opposite effect if its value is set too high.

With the tipping_point too great, pools with relatively high pledge are left to compete with pledge-less pools to exceed the tipping_point. Pledge-less pools that have managed to saturate show historically much higher reward rates than pools with higher pledge who failed to gain popularity.

“Our game theoretic analysis has shown that if stakeholders try to maximize their rewards in a “short-sighted” (myopic) way (pool members joining the pool with the highest rewards at this moment[…]), chaotic behaviour will ensue.” {ref.1}

Delegators are more likely to stake with a pledge-less high total stake pool than a high pledged low stake pool despite the latter providing higher non-myopic rewards. This illustrates the imbalance of the incentive (pledge) and the disincentive (minPoolCost).

A sybille attacker should need stake in the system to compete for delegation, not a rigorous marketing campaign.

If few pools are able to buy-in past the tipping_point, it’s apparent we have set the tipping_point too high. Lowering the minPoolCost lowers the tipping_point. Reducing the minPoolCost dramatically will point the network toward its desired equilibrium outlined in the original RSS paper {ref.2}.

Pledge benefit incentivizes operators to consolidate their pledge to receive higher reward on their stake and also makes their pool more attractive; pledge benefit incentivizes delegators to lower operator leverage by hunting for the best rewarding pool. Pledge-less pools hit a reward ceiling and are unable to compete with higher pledged pools, making them less attractive.

Presently, pledge has a rather weak reputation, with many people believing that it’s not effective or noticeable enough. Currently, only 21 public pools can offset a meager 1% margin with their pledge. There is a large gap between public pledge and saturation, with the majority of pledge benefit noticed within that gap. Only a few private corporations, IOG included, are benefiting from high pledge rewards {fig.2}. We need to bring pledge benefit to within our real set of pools.

Raising a0 will make pledge benefit more noticeable, but this would mostly benefit the small handful of corporations that have pledged to saturation and would only barely effect the majority. It would not change the gap between the founders and everybody else. We need a change that will benefit the most people.

The solutions in this CIP will solve all of the above mentioned problems. It will exponentially benefit more people/entities than in will detriment.


Change the minPoolCost from 340 ADA/epoch to 10 ADA/epoch and raise K from 500 to 2000.


“minPoolCost”: 10000000
“stakePoolTargetNum”: 2000


With minPoolCost set at 340 ADA/epoch the tipping_point is 10M ADA. By lowering it to 10 ADA/epoch the tipping_point drops to 1.75M {fig.4}. Now any pool with ≥ 1.75M pledge will no longer be competing with a sybille attacker for their first delegators. This tipping_point was chosen because it represents an upper-middle level of pledge within the real set of pools. An entrepreneur is far more likely to find 1.75M ADA investor over a 10M ADA investor.

Earlier proposed changes of K to 750 or 1000 are far too small. We would still have a tremendous gap between real public pledge and saturation (between the rich founders and everybody else). Raising K by four times its present value will make pledge four times more noticeable and bridge the mentioned gap {fig.3}. Pledge only being somewhat more noticeable won’t be enough to change pledge’s tarnished reputation. ‘Pledge is now 4x more effective’ in an article headline and YouTube title will grab the layperson’s attention. It will change the narrative from ‘pledge has no value’ to ‘pledge is preferred’. This will all be done while decreasing the rewards paid to saturated pools.

Making pledge more effective could also help solve the problem of exchanges, despite having no stake of their own, making >20% of the blocks. BNP is simply being greedy with their stake. It is more profitable to run their own pledge-less pools than to pay a fee to an SPO. Only a few public pools currently offer greater than baseline rewards, thanks to the imbalance mentioned above. If more pools could offer greater than baseline rewards, exchanges like Binance and Coinbase could choose to make more ADA by delegating to community pools.

At all times we need to incentivize decentralization!

Raising K will force a shakeup of the current stake distribution, which is quite centralized at the moment. Many delegators will be forced to revaluate their pool choice, hopefully for the better.

Scheduling the shakeup in conjunction with pledge becoming more effective opens a great opportunity to reeducate the population of delegators on how the reward function works and what effects parameters have on their reward rates.

This is not so much a change as a tuning of the originally applied incentive/disincentive scheme. The simulations from the original RSS paper show there is no danger of lowering the minPoolCost too low, so long as pledge is ‘meaningful’ within our real set of pools.


These changes will lower the reward rate of the pledge saturated pools while increasing rewards for all delegators. Pool operators will be able to set their own prices more in line with their actual cost of running the pool. Saturation point will be reduced from ~69M to ~17M. Pledge will become four times more effective at incentivizing decentralized stake delegation.

Backwards Compatibility:

This proposed change is fully backwards compatible and will not require a hard-fork. Adjusting parameters is ‘easy’ and will require no code rewrites. This change can be implemented immediately.


All graphs were generated using data through epoch 353.

{fig.1} Definitions

{fig.2} Currently unfair pledge gap & poor effectiveness

{fig.3} Proposed

{fig.4} Compare Danger Zones


{ref.1} - Design Specification for Delegation and Incentives in Cardano, Philipp Kant, Lars Brünjes, Duncan Coutts,

{ref.2} - Reward Sharing Schemes for Stake Pools, Lars Brünjes, Aggelos Kiayias, Elias Koutsoupias, Aikaterini-Panagiota Stouka,

Hash: SHA256

No stake pool will claim credit for this CIP



@ADARobinHood the lead designer of the original stake pool incentive scheme and/or reward formula is going to be on this upcoming discord call (from July SPO Digest):

Your invitation to the August SPO call is here! In this month’s call we’ll have Professor Aggelos Kiayis, IOG’s Chief Scientist, join us to share more on his latest research, which compares alternative reward sharing schemes for Cardano. … Thursday, August 4th at 3 p.m. UTC in Discord.

The discussion around the pending CIP-0050 has been adamant about increasing K not having any effect, mostly due to the behaviour of multi-pool operators, while all changes under consideration involve reducing or eliminating the minimum fixed fee.

You could tune in to these discussion threads, ongoing since April, to see how your proposal might fit into the deliberation so far (I believe your suggestions have already been under consideration here):


First, welcome @ADARobinHood ! I love seeing that your charts are so similar to mine and we share similar thought processes on the reward equation. As I spend more time looking at Cardano I become more convinced that an enforcement is necessary instead of an incentive with a zero or negative slope as stake increases. Long-term in an era of governance both the current minimum fee and a0 can be weaponized by the large against the small, crushing the robinhood spirit. k-parameter almost becomes irrelevant if a cardano-node modification allows for a single node instance to manage any number of block producing key sets.

I’m about to revise all the charts in CIP-50 but this is a sneak peek:

I like log(stake) linear(yield) scales with a few helpful vertical and horizontal label lines.

Welcome to the CIP-50 hivemind??


“Long-term in an era of governance both the current minimum fee and a0 can be weaponized by the large against the small, crushing the robinhood spirit.” Can completely removing a minimum fee prevent this weaponization? It shouldn’t have been there to begin with, and as your chart shows in CIP-50, no minimum fee already gives small pools the same expected returns at equal pledge, while letting the current a0 value have a slightly more meaningful impact than currently

Yes please, and I would add that there needs to be some decentralized mechanism for the community to agree on these changes. It shouldn’t be a case of trying to convince IOG to do it - it should be a case of trying to convince the community to do it, and then IOG implementing the democratically selected change.
I know Voltaire is coming, but I think we need this immediately. In the mean time can’t we use ? :smiley:

1 Like

I’ve found out recently that the Discord invite links expire after 7 days by default: so therefore has the one above. I generated this link after removing the expiry time: (invite)

1 Like

Pity that it is not possible to see the content without a verified Discord account. Which in turn requires a verified mobile number. Which in turn requires verified registration with a Govt issued ID. Which then enables easy tracking by Big tech and Govt and easy linking of everything for analysis by the AI algorithms of the future.

Is it possible to copy the content from Discord somehow?

1 Like

I’m working on exporting this now: if & when successful I’ll ask the other CIP editors & the founding contributors to the CIP-0050 thread if they agree to post this export publicly somewhere.

Threads about developing issues tend to be only as useful as the most recent messages, but I think this is an exception because a lot of the development has already taken place, with discussion going back to May of this year.

I don’t believe it will be possible to automate an export of this or any other Discord channel:

  1. The most recommended Github project that offers this depends upon the .NET framework being installed even on Linux (an intolerable security breach as I see it) and leans into a political issue in a way that suggests unreliability.
  2. I’m trying to use a Chrome extension to do it, which unfortunately relies on the token for one’s own user account which means it can’t be properly automated.
  3. Discord itself has refused many, many requests over the last 4 years for a “chat export” feature: just another one of the many things I hate about Discord.

BTW I’ve been “exporting” as per method #2 for 20 minutes without any progress indicator, so I don’t know if this will fail or succeed. If I can get it to work I’ll post here and in the Discord thread.

1 Like

p.s. this method did not work (nor did I attempt to solve the problem) but already on the Discord there’s a suggestion we bridge with Matrix which I think at the very least would make the CIP discussions accessible in real time without KYC for readers (and probably some kind of proxy posting as well).

To avoid further off-topic messages I’ll post another forum thread whenever we might get that to work. :nerd_face:


Note from the editorial point of view; we now have a CIP submission for this:

… although I’m not sure how it relates to, or whether it replaces, @ADARobinHood’s earlier merged proposal: