Reduce minPoolCost to 75 ada and increase Plutus Memory Limits (Part 2)
Discussed in the Governance Review for epochs 650 to 652.
247 SPOs voted · 18 with a rationale · 1 changed their vote
Open a row to read the rationale.
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- NoNo rationale
- YesNo rationale
- YesNo rationale
- AbstainNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesRationale
YES - Reduce minPoolCost to 75 ada and increase Plutus Memory Limits (Part 2).
In regards to minPoolCost, this reduction has been discussed and debated by the community for years. Many believe this to be an important step in proving that liquid delegations are viable in the context of allowing smaller stake pools to attract delegators, others think it will force small stake pools out of operations via a race to the bottom. The reality of this param is that it is fundamentally useless to the network beyond bootstrapping and initial now less relevant ideas, and ultimately has caused a long term issue with the reward curve. The incentives this parameter provides are not healthy to the Cardano network, this and the lack of other parameters that provide pool incentives is exactly the main topic of discussion among SPOs. Firstly, there is little to no incentive to delegate to small stake pools. Any delegator with the knowledge of how the rewards work will understand they lose money if they stake with small pools, this is just the math of the situation we are in. For small SPOs to be able to compete we must be attractive to delegators. Secondly the race to the bottom is not predicated by this parameter, some likely feel this way because it is the only reliable income they have to gain from being a small stake pool, which includes us at Upstream with a current 250k stake. With this lens we cannot in good conscience support minPoolCost at all, and would vote for it to be ultimately replaced with a clearer poolCost (a cost reflective of what a Stake Pool thinks it's worth, delegators can decide, as it should be). Stake Pools can set any fee they like and we will likely keep ours to ensure operations for a short time, but at some point for small pools to be competitive we need to be able to say in earnest 'delegate to Upstream and earn the same as you would from any other pool' (or as close to that sentence as possible). Of course this is just a band-aid on the actual problem, which is the lack of params that actually drive liquid delegation to smaller pools, which of course can only be achieved if smaller pools are paid equal or more rewards to delegators, than that of larger pools. That is an honest and true incentive to achieve this goal, if indeed this is the collective Cardano goal. Until we have this, small pools will always bear the brunt of our network's incentive structures, and these discussions are only token gestures to cover the problems / intentional alternative incentives. If the aim is a secure network with thousands of productive pools then let's put our money where our mouth is and drive incentives back down the pyramid we have created.
As for Plutus Memory Limits, this continues on from the first step in the long planned updates (since 2024) and we approved the previous gov action and so we complete this here. The impact for these parameters is minor, only affecting those who must update direct implementations, if at all. Reviewing the technical communities' work, the proposal references and the provided benchmarks make it clear it's very low risk and impact for day to day chain activity.
- NoNo rationale
- NoNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesRationale
I vote yes on the change of memory limits and minPoolCost reduction.
I fully support the long-planned memory limit increase. I also support reducing minPoolCost, but bundling these otherwise unrelated changes sets an odd precedent, especially without a clear reason why they needed to be combined. It is almost phrased as a temperature check with SPOs on minPoolCost, but if that is the intent, I would have preferred that input to be gathered separately rather than making the memory limit change dependent on it. Why not a dedicated parameter change action?
I support the minPoolCost reduction as an interim step, but I am not convinced it will materially improve the viability of smaller pools. Even at around 3.5 million ADA delegation, sustainability remains a concern for us. When we polled our delegators in 2025 on fixed fees of 0, 170 and 340 ADA, the majority, albeit from a small sample, preferred 170 because they understood that it helps sustain the pool. We therefore do not plan to lower our own fixed fee.
I would also like to see a clearer path and target timeframe for introducing a minimum percentage based margin. I recognize that such a timeframe cannot be enforced through this action, but without it there is a risk that these incremental minPoolCost reductions remain the solution for longer than intended.
- YesNo rationale
- YesChangedHistory
Earlier votes
No16d agoSuperseded
- YesNo rationale
- NoNo rationale
- NoNo rationale
- NoNo rationale
- YesNo rationale
- YesNo rationale
- NoNo rationale
- NoNo rationale
- NoNo rationale
- NoNo rationale
- NoNo rationale
- NoNo rationale
- NoNo rationale
- NoNo rationale
- YesNo rationale
- NoNo rationale
- NoNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- NoNo rationale