Exernal
Describe the feature you'd like
Automatic deduction of the minimum fixed cost, FC_epoch, even if the fixed cost set at pool registration time, FC_reg, is below the minimum fixed cost.
FC := max(FC_reg, FC_epoch)
Rationale
With the varying price of ADA a repeated reregistration of the pool with an appropriate mimumum fixed cost is tedious and error-prone. A pool with a fixed cost set to zero at registration time would always follow the minimum fixed cost set per epoch, according to the formula above.
Not a fan of the concept then it goes into a constant battle of re-registration and updates for fees to maintain the lowest. This fee was not included to be the new minimum absolute cost to be used as a marketing tool it was set to keep the network above absolute 0 to maintain the growth of the network. If I am not mistaken the re-registration and fee updates were to have a effect on performance "rank" in a wallet to stop the re-registration / update "Game" where pools lower the fee to onboard stake then quickly raise the fee again shortly after.
I do agree there needs to be something to maintain the fee to adjust it in the future and in my opinion that minimum fee would be included in the genesis and updated or maintained by CIP if people are just going to set it to the bare minimum and never use it as intended.
Not a fan of the concept then it goes into a constant battle of re-registration and updates for fees to maintain the lowest. This fee was not included to be the new minimum absolute cost to be used as a marketing tool it was set to keep the network above absolute 0 to maintain the growth of the network. If I am not mistaken the re-registration and fee updates were to have a effect on performance "rank" in a wallet to stop the re-registration / update "Game" where pools lower the fee to onboard stake then quickly raise the fee again shortly after.
The outlined formula does not prevent you to set the fixed cost higher than the minimum fixed cost. It is more like an automatic mechanism that adjusts your fixed cost to reflect the current minimum fixed cost of the network in case you drop below. I assume the minimum fixed cost to go up and down so it is tedious to follow and adjust.
The above statement was not about the "cap" of the fee more so of the re-adjustments needing to be maintained by other pools (pre registered) to adapt to later (NEW) and future pool registrations at reduced costs or raised costs in the future. Meaning there should be something in place that moderates the minimum floor for all past present and future not just time of registration/update. If pools used this Minimum cost as intended to charge the actual average costs / maintenance as a business not a side gig or as a marketing this would be a non topic and there would not be a need to have these set costs constantly adjusted. The formula is great for a at time of registration but not to maintain the fee long term thus the proposal of a set cost via genesis and update via "CIP" as a solution not needing the formula at all.
Strongly disagree, we should not shove the opinion of fixed cost being reflective of min costs down to every pool operator.
It might work for a section of pool operators and they'd want it to be adaptive based on min Costs, other section of crowd would want their profits to be adaptive and want more (or less) accordingly.
It isnt a rocket science for a basic pool operator to just update pool costs depending on update (take 10 seconds to execute) - I feel having such automation at protocol/node level would rather be unfair by making a decision on the behalf of pool operators.
If required, you can raise this via CIP perhaps.
We have already been discussing this, since it is clear to us that it could impact pool operation. This would need a small change in the ledger implementation, which we would prefer to postpone at this stage. We do not expect to change the minimum cost value frequently, and we will aim not to make any changes in the value before we have this change integrated. We think operators should be encouraged to choose their actual cost level. If this is below the minimum then the minimum cost would apply for ranking and rewards calculations.
@kevinhammond From your comments I read that there are no penalties planned (like no rewards for the epoch) when the configured fixed cost of the pool drops below the minimum fixed cost other than in the ranking?
@rdlrt My original thoughts were more along the lines how to avoid penalties when the pool fixed cost drops below the minimum fixed cost. With the suggested formula one could even avoid the question of a penality, because the fixed cost is always enforced by the protocol. So it simplifies things and still keeps the minimum fixed cost idea alive.
I am not a big fan of the minimum fixed cost becuase it limits the possible return on stake (ROS) a pool can achieve. Especially for pools with a small stake the fixed cost will not allow a competitive ROS compared to larger pools. So it puts the smaller pools at a disadvantage from the get go. Putting actually a cap on the pool margin would create a level playing field, but no guaranteed minimum return. So it is aways a kind of trade off.
@onyxstakepool - Not sure where/if I saw any mention of penalties.
About your last statement, its the same anxiety/concern of pool operators who could not attract enough delegation - that lead to centralisation on ITN (by using various workarounds). The minimum fixed cost for pool is added for a reason, and it applies to everyone equally. The point is to not have centralised 20 out of 1000, but closer to equally distributed nOpt pools , while others have a chance to compete
We think operators should be encouraged to choose their actual cost level. If this is below the minimum then the minimum cost would apply for ranking and rewards calculations.
I second this, and this essentially (to me atleast) emphasizes the need for pool operators to freely decide how they want to handle their fee/profits. Your suggestions forces them to follow down a path, that suites for a subset of ecosystem.
@onyxstakepool - Not sure where/if I saw any mention of penalties.
@rdlrt I have raised the question elsewhere what would happen if a pool's configured fixed cost is below the minimum fixed cost. If there are no penalties on operating below minimum fixed cost then the whole concept of setting a minimum cost level is void. So logically this case (operating below minimum fixed cost) has to be handled somehow.
AFAIk - The concept of minimum pool cost is only while registering or modifying the pool , to ensure fixed cost of pool is not below this variable - nothing more - to prevent the anxious pools lowering their costs to a point where its not sustainable for honest operators to maintain their pool.
what would happen if a pool's configured fixed cost is below the minimum fixed cost.
Afaik you can't register a pool with fixed cost declared below the defined minimum.
Afaik you can't register a pool with fixed cost declared below the defined minimum.
@gufmar Over time the minimum fixed cost could rise and thus leave pools that registered at the previous minimum fixed cost level end up below the current minimum fixed cost level.
Please file a CIP here: https://github.com/cardano-foundation/CIPs/issues/new - This is a major change to the ledger rules.
Most helpful comment
We have already been discussing this, since it is clear to us that it could impact pool operation. This would need a small change in the ledger implementation, which we would prefer to postpone at this stage. We do not expect to change the minimum cost value frequently, and we will aim not to make any changes in the value before we have this change integrated. We think operators should be encouraged to choose their actual cost level. If this is below the minimum then the minimum cost would apply for ranking and rewards calculations.