CIP-0037? | Dynamic Saturation based on Pledge

[CyberCyclone]

This CIP is a proposal to correlate a SPOs total pledge to the pools saturation level. This takes the importance of the pledge and pool saturation away from the pool entity and places it on the SPO entity. This is to patch the loophole that single entity SPOs have exploited in running pool farms with significant amounts of stake.

The intention of the pool saturation was to limit how dominant a single entity could become, however they have bypassed this intention by creating secondary pools.

This proposal will mean that a SPO will have a saturation point across all their pools based on how much pledge they have across them.

[cffls]

We will need a mechanism to determine these pledge thresholds. For example, why does 500,000 ADA pledge, instead of 600,000 ADA, deserve 100% saturation point.

[mark-stopka]

It's not smart in general to limit saturation, dynamic impact of pledge, relative to total delegated stake would be much more beneficial, and provide a level playing field...

[CyberCyclone]

We will need a mechanism to determine these pledge thresholds. For example, why does 500,000 ADA pledge, instead of 600,000 ADA, deserve 100% saturation point.

The example I gave was based on the fact that the values would be adjustable in the same way all the other params were chosen and could be changed based on network consensus.

[CyberCyclone]

It's not smart in general to limit saturation, dynamic impact of pledge, relative to total delegated stake would be much more beneficial, and provide a level playing field...

For the purpose of the discussion, can you please explain why "it's not good to limit saturation"? Technically the k param already limits saturation, so I'm not sure what your point is.

The idea is to shift the saturation to the pledge instead of on the pool.

[cffls]

Here is my idea of formulating the thresholds as a function of k and two additional parameters, e (entry threshold) and l (leverage):

orig_sat = total_supply / k
new_sat = orig_sat * max(e, min(1 / k, pledge / orig_sat * l))

We can use function new_sat to calculate the saturation point for a pool given its pledge, so we don't need to define these thresholds manually in the protocol. The parameter e is to, like Casey mentioned, safe guard small SPOs so they can at least have a reasonable chance to generate a block in a certain period of time. A value of 0.01 could be a starting point. The parameter l (leverage) could be a value the community define, e.g. 20, which means the saturation point will be 20x the amount of pledge.

@mark-stopka Not limiting the saturation point means we will discard k completely, which will be a much bigger change than the scope of this proposal I think.

[santonode]

as a small pool, reaching saturation at 13m stake vs 64m seems more reasonable to me and targeting 50k pledge also seems like a realistic target this would encourage me to increase my pledge sooner to avoid declining rewards for my delegates - do I understand this correctly?

[cffls]

These numbers are just used for discussion purpose and nothing is finalized. In this context, increasing the pledge means increasing the saturation threshold for your pool. If your pool's pledge is at 50k, then the pool will be saturated at 13.49M ADA, meaning that any more delegation to the pool will result in decreasing reward. In this case, you are correct in a sense that you would need to increase the pledge above 50k in order to receive more delegations beyond 13.49M ADA without hurting the ROI of your pool.

[cffls]

@CyberCyclone Casey, if this formula looks good to you, would you mind including it in your proposal? I can also create a pull request to your clone, and then you can merge it from your clone and resubmit this pull request. I am fine with either way.

[CyberCyclone]

Thanks for the reminder @cffls Jerry. I'll try and look into adding it in the next few days. I'm working on another CIP so once that's ready I'll come back to this one.

[CyberCyclone]

@cffls I've finally gotten around to updating the CIP. I've attached the code to the bottom of the CIP.

[StakeWithPride]

The example uses these numbers: "500,000 ADA Pledged = Saturation point at 100% of K".

This is way too low. I'm pretty confident most of the OG pool group operators have enough ADA to cover this and not collapse pools.

[CyberCyclone]

The example uses these numbers: "500,000 ADA Pledged = Saturation point at 100% of K".

This is way too low. I'm pretty confident most of the OG pool group operators have enough ADA to cover this and not collapse pools.

I'm not sure who you're referring to @StakeWithPride or what OG means, but the idea is to make single entities the majority operators of the network and force large stake pool operators to put down a decent pledge. If a small number of entities have enough ADA to meet the pledge and want to operate multiple pools then that's not an exploitation.

[SmaugPool]

Just a comment to avoid the idea being lost: Tobias Fancee mentioned a possible variant by calculating the pledge benefit from the stake/pledge ratio:

"Pledge/pool stake ratio pledge benefit pretty much does the same thing and is way easier to implement. Also, you wouldn't need saturation at all because the more leverage a pool has the smaller their pledge benefit which gives smaller pools a chance to compete."

https://twitter.com/TobiasFancee/status/1466437270651686922

PS: It looks like the same idea as the one mentioned in this comment: #163 (comment)

[leo42]

This CIP is a proposal to correlate a SPOs total pledge to the pools saturation level. This takes the importance of the pledge and pool saturation away from the pool entity and places it on the SPO entity. This is to patch the loophole that single entity SPOs have exploited in running pool farms with significant amounts of stake.

The intention of the pool saturation was to limit how dominant a single entity could become, however they have bypassed this intention by creating secondary pools.

This proposal will mean that a SPO will have a saturation point across all their pools based on how much pledge they have across them.

Why define it as a concreate number and not a Leverage cap ?

For example at a leverage cap of 10 you can have 10X the stake given your pledge.

this way it is also easy to translate into K changes etc.

[leo42]

A good way to calculate a starting value for the max leverage(dynamic saturation is to find the total leverage of the network at present and use that) this way theoretically all stake should go to the pools to saturate base on pledge.

Operators will naturally increase pledge as much as they can making the system more fluid and competitive again.

Based on data from (https://adapools.org/press) this suggested starting values would be:
12.58

This would mean that for a full saturation of 64M an operator would need ~ 5M Pledge.

This is the extreme end of values that we can support but we can support it and I would make things like new pledge changes and K increases less relevant and necessary

[cffls]

This CIP is a proposal to correlate a SPOs total pledge to the pools saturation level. This takes the importance of the pledge and pool saturation away from the pool entity and places it on the SPO entity. This is to patch the loophole that single entity SPOs have exploited in running pool farms with significant amounts of stake.
The intention of the pool saturation was to limit how dominant a single entity could become, however they have bypassed this intention by creating secondary pools.
This proposal will mean that a SPO will have a saturation point across all their pools based on how much pledge they have across them.

Why define it as a concreate number and not a Leverage cap ?

For example at a leverage cap of 10 you can have 10X the stake given your pledge.

this way it is also easy to translate into K changes etc.

I proposed a formula which introduced in a new parameter l (leverage) for exactly the same reason. Please take a look at the review above.

[cffls]

A good way to calculate a starting value for the max leverage(dynamic saturation is to find the total leverage of the network at present and use that) this way theoretically all stake should go to the pools to saturate base on pledge.

Operators will naturally increase pledge as much as they can making the system more fluid and competitive again.

Based on data from (https://adapools.org/press) this suggested starting values would be: 12.58

This would mean that for a full saturation of 64M an operator would need ~ 5M Pledge.

This is the extreme end of values that we can support but we can support it and I would make things like new pledge changes and K increases less relevant and necessary

Top 19 pools are IOG and anonymous pools with full pledge (64M). We should exclude these pools since they are outliers.

If those 19 pools are excluded, we will end up with leverage of 31.09, which means full saturation of 64M will require ~2M pledge, which sounds a bit better.

Calculation:

total_delegation = 23930M
total_pledge = total_delegation / 12.294 = 1946.48M
total_pledge_curated = total_pledge - 64M*19 = 730.48M
leverage_curated = (total_delegation - 64M*19) / total_pledge_curated = (23930 - 64*19) / 730.48 = 31.09

[KtorZ]

Moving forward, we would like to:

• Mark and merge this CIP as proposed
• Add a "Path to active" section which clearly indicates that the next step is at the moment upon IOG to provide feedback on the feasibility and soundness of the approach; as well as (if applicable) possible timelines or priorities when it comes to implement the proposition.

[CyberCyclone]

Moving forward, we would like to:

• Mark and merge this CIP as proposed
• Add a "Path to active" section which clearly indicates that the next step is at the moment upon IOG to provide feedback on the feasibility and soundness of the approach; as well as (if applicable) possible timelines or priorities when it comes to implement the proposition.

@KtorZ The CIP has been updated for IOG review. Thank you!

[rphair]

@CyberCyclone thanks for adding Path To Active although the Status: in the header is not the place to suggest that this is waiting for review...

[rphair]

thanks for making that last change but my apologies (for duplication of effort) we also missed this one 😖

[CyberCyclone]

No problem @rphair. Let me know if there's anything else needed.

[CyberCyclone]

@rphair just pinging this in case it's been forgotten about 👍

[rphair]

@CyberCyclone I've requested reviews from other editors already, plus I've also just now requested that we add this to the upcoming CIP meeting agenda... so it's sure to progress somehow from there 😎 here's the Discord where that meeting will take place: https://discord.com/channels/971785110770831360 ... you'll see the upcoming meeting details & agenda on the Events tab.