CIP-0046? | Prepay Min Fixed Fee

[shawnim]

Create a more fair marketplace for stakepools by paying the minimum fixed pool fee to qualifying pools before calculating pool and delegator rewards.

[SebastienGllmt]

Would this not make the optimal strategy to create a bunch of pools that only create 1 block per epoch to try and leech as much as possible from other pools?

[mark-stopka]

As I keep saying pledge influence relative to total delegated stake is the way to move forward.

[shawnim]

Would this not make the optimal strategy to create a bunch of pools that only create 1 block per epoch to try and leech as much as possible from other pools?

I don't see how this changes the incentives to create multipools at all.
Having multiple pools with your pledge and delegation spread out between them is no better rewards-wise than a single pool.

[capexeu]

Lets say that you have 1 Pool with 50M Stake and 1M pledge, and a 1% Flex fee, producing ~50 blocks per Epoch.
Now you were to split this into 10 pools of 5M Stake, 100kADA Pledge and still 1% flex fee, with ~5 blocks per Epoch.
In the current calculation method there would be a strong negative incentive to do this, since the delegates would have a very high relative fee in the 5M Stake Pools (~8%), while they have a very low relative fee in the 50M Stake Pool (~1.7%).
In the current calculation this will lead to a very unattractive situation for the delegates.
The SPO will receive 340 + 1% of ~50k = 840ADA in situation 1, but 10340 + 10(1% of 5k) = 3900ADA in situation 2.
This situation will probably not last long since all delegates would leave because of the high fees.

In the proposed calculation the 5M and 50M Stake situation will be equal for the delegates.
For the SPO the difference is still the same as in the current calculation (840ADA vs 3900ADA).
The SPO would take these 10*340 out of the total rewards pool and not from his own delegators, so there is no penalty for this behavior.
Is this a correct interpretation of the proposal? Or am I missing a step here?

[shawnim]

Lets say that you have 1 Pool with 50M Stake and 1M pledge, and a 1% Flex fee, producing ~50 blocks per Epoch. Now you were to split this into 10 pools of 5M Stake, 100kADA Pledge and still 1% flex fee, with ~5 blocks per Epoch. In the current calculation method there would be a strong negative incentive to do this, since the delegates would have a very high relative fee in the 5M Stake Pools (~8%), while they have a very low relative fee in the 50M Stake Pool (~1.7%). In the current calculation this will lead to a very unattractive situation for the delegates. The SPO will receive 340 + 1% of ~50k = 840ADA in situation 1, but 10_340 + 10_(1% of 5k) = 3900ADA in situation 2. This situation will probably not last long since all delegates would leave because of the high fees.

In the proposed calculation the 5M and 50M Stake situation will be equal for the delegates. For the SPO the difference is still the same as in the current calculation (840ADA vs 3900ADA). The SPO would take these 10*340 out of the total rewards pool and not from his own delegators, so there is no penalty for this behavior. Is this a correct interpretation of the proposal? Or am I missing a step here?

It is a good point. It's a fundamental problem of having a minimum fixed fee. Reducing (or eliminating) the min fixed fee would alleviate this problem. Forcing the delegators to smaller pools to pay substantially higher fees is an unfair way to disincentivize pool splitting and causes centralization in the network.
See also CIP-0023 Fair Min Fees.

[shawnim]

@KtorZ Any possibility of getting feedback on this proposal from IOG, especially in conjunction with CIP-0023 Fair Min Fees?

[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.

[rphair]

Regarding last CIP meeting discussion I'm ready to approve this if @shawnim can do something like what @KtorZ recommends in the last comment. Then at least the merged CIP would not face being stalled indefinitely, because there would be some basis for community pressure upon IOG for taking the next step(s).

[KtorZ]

Closing because inactive for a long time. Note that this PR also concerns the RSS which, as per the new process, has current no defined category. It would therefore be merged straight to Inactive for there's no implementors or reviewers designated for this area of the ecosystem.