# CIP ? - Set minPoolCost to 0

**URL:** https://forum.cardano.org/t/cip-set-minpoolcost-to-0/109309
**Category:** CIPs
**Created:** [20 October 2022 12:31 UTC](https://forum.cardano.org/t/cip-set-minpoolcost-to-0/109309 "2022-10-20T12:31:22Z")
**Posts on this page:** 5
**Page:** 3

<div class="post-metadata">

### Author: ![Jaromir](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/jaromir/32/14207_2.png) [@Jaromir](https://forum.cardano.org/u/Jaromir)
#### Post date: [25 October 2022 07:26 UTC](https://forum.cardano.org/t/cip-set-minpoolcost-to-0/109309/41 "2022-10-25T07:26:38Z")

</div>

In the first place, we should not change key parameters without research and simulation of participant behaviour for the case when it will be possible to set fixedCost and Margin parameters to 0. We should have the simulation results and debate over them. Only then does it make sense to consider a possible change. It is likely that the IOG already has some results from the simulations.

As for a change, we should not allow a situation where delegates force pool operators to reduce rewards. Running a pool must remain a profitable business. Our priority is network security, not rewards. Race to the bottom is a real risk to the network and the minimum reward per epoch is a defence.

We can consider reducing the minimum from 340 to say 100 ADA for fixedCost. But we should introduce a minMargin parameter and set it reasonably to say 2%. But this has its drawbacks as well.

More on our blog:

> **[Is it smart to change the incentive model of Cardano? | cexplorer.io](https://cexplorer.io/article/is-it-smart-to-change-the-incentive-model-of-the-cardano)**
>
> CIP-69 proposes to reduce the minPoolCost parameter to 0. You can find enough good arguments for and against. Let's see what a possible reduction of this parameter to 0 would mean and what it should b

---

<div class="post-metadata">

### Author: ![COSDpool](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/cosdpool/32/21482_2.png) [@COSDpool](https://forum.cardano.org/u/COSDpool)
#### Post date: [25 October 2022 08:56 UTC](https://forum.cardano.org/t/cip-set-minpoolcost-to-0/109309/42 "2022-10-25T08:56:24Z")

</div>

A naming collision with this previously written candidate CIP has come up at our Editors’ meeting taking place now:

> <https://github.com/cardano-foundation/CIPs/pull/321>
>
> The aim of the CIP is to allow more secure designs, streamline the developer exp…erience and increase the design space of Cardano validators. 
> 
> All three purposes are achieved by removing the \`Datum\` out of a spending script's signature, to be the exact same as every other type of script. Datum is made available in \`ScriptPurpose\` instead. 
> 
> This change lets us use one script as both a spending and a minting validator, meaning that we resolve a well known protocol design problem of 'mutually dependent' validators, where a minting validator needs as parameter a spending validator, and the spending validator needs as parameter the minting one. 
> With this CIP, they can be merged into a single script, enabling us to enable the two-way (or more) dependency where necessary. 
> 
> \---
> 
> \[see rendered Markdown\](https://github.com/zygomeb/CIPs/blob/master/CIP-0069/README.md)

so could @ADARobinHood or a moderator please remove the **69** reference from the title & further communications? 🙏

---

<div class="post-metadata">

### Author: ![HeptaSean](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/heptasean/32/82306_2.png) [@HeptaSean](https://forum.cardano.org/u/HeptaSean)
#### Post date: [25 October 2022 09:08 UTC](https://forum.cardano.org/t/cip-set-minpoolcost-to-0/109309/43 "2022-10-25T09:08:06Z")

</div>

> [@COSDpool](#):
>
> so could @ADARobinHood or a moderator please remove the **69** reference from the title & further communications?

I have done that, but hesitating. It has been very widely discussed under that number in a _lot_ of channels. I don’t know if we get that genie back into the bottle.

---

<div class="post-metadata">

### Author: ![COSDpool](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/cosdpool/32/21482_2.png) [@COSDpool](https://forum.cardano.org/u/COSDpool)
#### Post date: [25 October 2022 10:29 UTC](https://forum.cardano.org/t/cip-set-minpoolcost-to-0/109309/44 "2022-10-25T10:29:58Z")

</div>

> [@HeptaSean](#):
>
> hesitating… I don’t know if we get that genie back into the bottle.

thanks… in this case we have to do our best. The author of the _real_ CIP 69 pointed out today (humbly, but legitimately) that use of the other number has confused the consideration of his own proposal. The fact that the poached number is being used by a much more popular proposal (the one above, by contrast, is technically narrow-fielded) makes it even more important.

The original version of the CIP documentation was never clear enough on what’s simply been stated but not enforced… that CIP authors aren’t supposed to choose numbers. This is one of those cases where logic and consistency have to take precedence over popular demand. Until CIPs are placed as candidates & given a reserved number (as will be documented in the forthcoming version of CIP-0001), both authors & advocates should be calling them by what they _are_ or what they _do_ rather than the number. 🕶

---

<div class="post-metadata">

### Author: ![girljoseph](https://avatars.discourse-cdn.com/v4/letter/g/b5a626/32.png) [@girljoseph](https://forum.cardano.org/u/girljoseph)
#### Post date: [26 October 2022 02:09 UTC](https://forum.cardano.org/t/cip-set-minpoolcost-to-0/109309/45 "2022-10-26T02:09:39Z")

</div>

It’s important to recognize what problem is ailing the network. Once we find the problem we can find the solution, then develop a path toward it.

Problem: Stake is centralizing with few operators resulting in a low MAV and a network trending toward centralization. The network is highly leveraged. Operators with very little stake in the system are making disproportionately many blocks. Pools with low pledge are able to offer better rewards than pools with relatively high pledge.

![1](https://us1.discourse-cdn.com/flex023/uploads/cardano/original/3X/a/3/a3a7601fd63b0851e85aee3b549e4476ab9db5da.png)

Solution: Reduce leverage over the network. We need operators with much stake in the system making many blocks and operators with little stake in the system making few blocks. This is the sign of a secure decentralized system.

Path toward solution: Cardano doesn’t force behavior, it tries to influence it with incentives. We need to incentivize the right behavior from SPOs and delegators alike. Pool operators need to be incentivized to consolidate and grow their pledge, and delegators need to be incentivized to stake with pools consolidating and growing pledge. Modify the network’s parameters so that stake trends toward decentralization, so that pools with pledge can offer better rewards than pools without.

Below are some examples showing how the incentive model works WITHOUT a minPoolCost. This is the incentive model in Cardano’s design, not it’s current implementation. We’re going to reference ‘low fee pools’ in a lot in these examples. A low fee pool is one with 0 fees and 0 pledge. They offer their delegators 0.05244% /epoch rewards. Higher desirability is higher reward rate for delegators.

* * *

> ex1.

Pool A - Saturated, 10MM pledge, 50 cost, 3% margin, delegators making 0.05298% /epoch, higher desirability than low fee pool.  
The SPO is making 5486 ADA/epoch on their stake + 1028 ADA from pool fees - total 6497 ADA/epoch

SPO decides they want more stake than a single saturated pool in hopes to make more ADA. So they split their pledge in half and make 2 pools. They lower margin on the first pool to keep relatively same desirability as before at saturation. The threat of 0 fee pool desirability defines a minimum desirability for all pools. In order to attract stake in Pool B they put it ‘on sale’ charging no fees at all until it becomes saturated, then they match fees with Pool A.

Pool A - Saturated, 5MM pledge, 50 cost, 1% margin, delegators making 0.05296% /epoch  
Pool B - Saturated, 5MM pledge, 50 cost, 1% margin, delegators making 0.05296% /epoch  
SPO is making (2678 x 2) = 5356 ADA/epoch on their stake + (395 x 2) = 790 ADA from pool fees - Total 6146 ADA/epoch.

To maintain the same desirability while doubling leverage the operator is getting less ADA/epoch, this isn’t even including the lost rewards from the time the pool spent ‘on sale’.

By this example you can see an incentive for the SPO to keep their pledge consolidated otherwise risk losing their own rewards. If the operator wants more rewards they need to grow their pledge.

* * *

> ex2.

A person has 75K ADA and they’re considering opening a pool. They run the numbers and see that they can only charge 0 cost and 0.015% margin to maintain higher desirability than a low fee pool. At saturation it’s only 5.5 ADA in pool fees per epoch. This isn’t enough to break even, so they decide to delegate instead.

This is a good thing for the network because a saturated pool with only 75K pledge is said to be highly leveraged and we want to keep leverage low. This person has incentive to go and find more pledge either by buying it themselves or partnering with somebody who has a lot of stake in order to make their potential pool more desirable and profitable.

By this example you can see a lack of incentive for potentially high leverage pools to ever start in the first place.  
There is no way to distinguish a single low stake person from a high stake person acting like many low stake people. For this reason we should treat all highly leveraged pools as a potential attacker.

* * *

> ex3.

Somebody has 210MM ADA.  
If they start 3 fully pledged private pools they’ll make (47,783 x 3) = 143,259 ADA/epoch

If they half pledge 6 pools and charge 13% margin, to maintain higher desirability than low fee pool, they make (23,882 x 6) = 142,932 ADA/epoch.

This is what keeps ultra whales from competing in the public stake pool market. They make more ADA by pledging privately.

* * *

> ex.4

Two separate persons that know each other have a decent level of trust and have 2MM ADA each.  
They each start their own pool and manage to saturate it.  
Saturated, 2MM pledge, 30 cost, 0.75% margin, delegators making 0.05245%/epoch  
SPO makes 1057 on stake, 299 from fees - 1356 total ADA/epoch each.

They decide to become co-owners to a single pool.  
Saturated, 4MM pledge, 30 cost, 1.59% margin, delegators making 0.05245%/epoch (same desirability as before)  
Each person now makes 1066 on stake, 294 on fees - 1360 ADA/epoch each.  
Real cost is halved and not expressed here.  
By consolidating into 1 pool everybody makes more ADA.

You can see, by this example, an incentive for people with decent levels of trust to consolidate multiple pools into one to receive higher rewards on their stake.

This also works for large groups of individuals who trust each other but do not individually have enough stake to pledge a desirable pool.

‘’’

These examples show that under many diverse conditions the network still incentives operators to run as few pools each as possible. This is essential if we want the network to trend toward k desirable pools. As operators in the upper pledge spectrum consolidate to remain desirable it will open up opportunity for lower pledged operators to gather stake.

Popular operators can still exceed saturation by opening many pools. They can also make more ADA with many pools if their popularity is worth a loss of rewards for their delegators. This principal also allows operators in low income areas or operators supporting a worthy cause to run a profitable pool by finding delegators willing to accept lower rewards (delegate to a less desirable pool).

Exceeding thresholds and evading protocol incentives using popularity always results in lower rewards for delegators. We can’t completely remove popularity influence on delegators, but we shouldn’t pair it with better rewards as you’ll see below.

I used 0 fee 0 pledge pools as the desirability threshold. This was mostly to show how absurd the ‘race to the bottom’ argument is. That argument must completely discredit pledge to make sense. In reality the desirability threshold will be determined by the k-500th pool. Desirability is relative to other pools and its lower bound will be 0 fee 0 pledge. If an operator must lower their fee to 0 to try and remain desirable, then they should not have started the pool to begin with.

‘’’

* * *

> ex.5

Person has 5MM ADA and is deciding whether to start a pool or delegate. They see there are no pools with \> 5MM pledge and room for their stake. If they delegate to a pool with less than 5MM pledge they miss out on pledge benefit while paying whatever fee the operator is charging. If those two losses are greater than their real cost to run a pool, then they should decide to run a pool. Even if that pool stays private they’re making more ADA than they would by delegating. They decide to start a pool.

They set their fees to 0 to attract stake by becoming temporarily highly desirable. Remember, they’re already making more ADA by running the pool without delegated stake.  
Pledge 5MM, 0 cost, 0% margin. The first and all following delegators to the pool are making 0.05356%/epoch  
Operator is still making 2678 ADA/epoch on their stake, 0 ADA on fees.  
Once the pool saturates the operator can add cost and margin while still maintaining competitive desirability.

This example represents the network’s ability to correct toward higher decentralization, by incentivizing stake to move from less desirable (lower pledged pools) into one with higher pledge. It gives pools the option to modulate their desirability to attract stake.

All pools have the option to raise pledge and/or lower fees to modify their desirability with or without delegated stake in their pool (popularity).

* * *

minPoolCost makes desirability dependent on pool size first and foremost, by making LOW STAKE pools offer bad rewards. This also causes pool with relatively high pledge and LOW STAKE to offer bad rewards. It doesn’t discriminate. Pledge can only work with a minPoolCost if delegators are non-myopic, which they’re not. Delegators want high rewards now. Nobody wants to be the first delegator to move to a new, high pledge low stake pool and accept bad rewards while hoping others move with them. Myopic delegation makes Cardano unable to recover from an attack using pledge desirability. ex5 from above cannot happen with a minPoolCost.

minPoolCost causes stake to lock-in to pools even if that pool would otherwise be less desirable than others. ‘If they are popular’ determines everything about a pool’s rewards, and this is the crux of the current reward model. Popularity should be an add-on, not everything. It should cost something. Popularity is far too valuable in the system, far far more valuable than actual stake in the system. Popularity defines how much ADA an operator can extract from the network.

minPoolCost does not ad sybille defense, it pegs sybille defense to popularity instead of stake in the system (pledge). It removes sybille defense and makes Cardano something other than proof of stake.

The level of minPoolCost sets the level that popularity can become more powerful than pledge in determining desirability. Currently, popularity is more powerful than 19MM pledge. This is WAY too high. If the community decides to lower minPoolCost to some value higher than 0, we first have to decide what level of pledge we want people to believe doesn’t work. This was a subject in CIP RobinHood, which set the minPoolCost to 10. At minPoolCost of 10, pledge under 4MM will be believed to not work because a minfee pool with no pledge can offer better rewards than a new 4MM pledged pool. The network can only correct for misappropriated stake with pools \> 4MM pledge. This is still unacceptably high.

We have 2 years of history showing many pools with no pledge offering better rewards than pools with relatively high pledge. 3 of the top 5 highest lifetime rewarding pools (excluding luck) have only 50k pledge. As long as an operator can gain popularity, they do not need pledge at all to offer great rewards. They can create as many pools as their popularity allows, with each of them more desirable than unpopular pools with pledge.

* * *

Let’s look at some examples showing the disproportionate power of popularity over pledge caused by minPoolCost.

```auto
Pool A - 15MM pledge, 15.1 MM total stake, 340 cost, 0% margin. Provides its delegators 0.05093% /epoch
Pool B - 3MM pledge, 20 MM total stake, 340 cost, 0% margin. Provides its delegators 0.05134% /epoch
Pool C - 0 pledge, 70 MM total stake, 340 cost, 1% margin. Provides its delegators 0.05144% /epoch

```

Pool C has a large marketing advantage. They can say, ‘look, my pool gives high rewards. If you also want high rewards delegate to my other pool’ ‘Pledge doesn’t work, look pools with pledge are giving low rewards’

As you can see by these examples, if an operator can make their pool popular and gain stake, they can lower pledge, raise margin, and still remain more desirable than pools with relatively large pledge that are less popular. The network is incentivizing this behavior by giving these pools better rewards.

Pools with pledge will remain unpopular as they continue to give lesser rewards. This is BACKWARDS. If a pool with 0 pledge saturates, we want EVERY inventive working toward moving that stake into pools with pledge.

There is no way to completely eliminate a social aspect from a delegated POS system without forcing people to delegate a certain way. If all we have to work with are incentives then we need to incentivize the right things.

[Previous page](https://forum.cardano.org/t/cip-set-minpoolcost-to-0/109309.md?page=2)
