Reduce minPoolCost to 75 ada and increase Plutus Memory Limits (Part 2)
164 DReps voted · 59 with a rationale · 6 changed their vote
Open a row to read the rationale.
- Yes737.6K ₳No rationale
- Abstain627.2K ₳Rationale
Vote is Abstain. Plutus memory increase is a clear public good for the Leios/Peras roadmap, but the bundled minPoolCost reduction to 75 ada carries unresolved SPO sustainability concerns. Since I cannot vote for one without the other, I abstain
A PDF version of this rationale is also made available.
I vote Abstain on this parameter-update bundle.
The Plutus memory increase is straightforward and needed. It completes a planned 25% cumulative expansion of maxTxExecutionUnits[memory] and maxBlockExecutionUnits[memory], giving dApp developers headroom that will be required once Leios parallel block production finally arrives. Without the execution-layer capacity, the consensus-layer throughput is just an empty pipe. I'd vote Yes on this part alone.The minPoolCost reduction to 75 ada is not as clear to me. I have run infrastructure, but I'm not an SPO. The proposal itself calls this a "stopgap" pending minPoolMargin (CIP-0023). Some active SPO have stated directly that 75 ada is not operationally sustainable, especially if ADA falls below about $.20 USD, compounded with reality that reserve-funded block rewards continue declining. The post-2023 drop to 170 ada did not produce a race to the bottom, but we have also seen many pools both with hight and low stake close down over the last two years. Making sure SPOs can safely maintain modern hardware should be compensated for. Furthermore SPOs are required to vote today as part of CIP-1694 governance this work should be compensated for in addition to legacy SPO responsibilities.
MPC-03 says minPoolCost "should" reflect pool operating costs. I recognize this is a SHOULD guardrail, not a MUST, and that the Constitution doesn't mandate a specific cost floor. But "should" still carries intent. The Parameter Committee is asking the network to approve a number that even its own rationale admits is incomplete. I'm not comfortable approving any unnecessary risks to operator sustainability.
The deeper problem is bundling. These two changes are unrelated: one is execution-layer capacity, the other is stake-pool economics, "bundled here for submission efficiency", efficiency for the proposer shouldn't force an all-or-nothing vote on the voter. Votes on bundled parameters, means accepting a minPoolCost level I believe is premature.
My abstention is not support for this action, and it is not rejection of Plutus memory expansion on the merits. It's an acknowledgment that I cannot make a reliable Yes/No judgment on the whole when the parts pull in different directions.
If these were split into separate votes, I'd vote Yes on Plutus memory and Abstain on minPoolCost until minPoolMargin is in place.
- Yes623.3K ₳No rationale
- Yes590.1K ₳No rationale
- Abstain564.7K ₳No rationale
- Yes545K ₳Rationale
I support the proposal **Reduce minPoolCost to 75 ADA and increase Plutus Memory Limits (Part 2) **.
In this vote, I believe the two adjustments need to be considered separately.
First, the 25% increase in Plutus memory limits has already been validated on the testnet. It directly eases the execution-space constraints currently faced by DApp developers, carries relatively manageable risk, and aligns with Cardano’s ongoing effort to strengthen on-chain application capacity. I regard this as a reasonable and necessary technical improvement.
Regarding the reduction of minPoolCost from 170 ADA to 75 ADA, my view is more measured.
I do not consider lowering the fixed-cost floor to be an ideal long-term solution in itself. However, under the present conditions of declining block rewards and increasing operational pressure on smaller stake pools, this is a staged adjustment that has become difficult to avoid.
If no change is made now, the marginalisation of smaller pools is likely only to accelerate. Therefore, until more complete structural solutions—such as a proportional minPoolMargin—are in place, I am willing to support this reduction as a means of giving smaller pools some breathing room in the near term.
At the same time, I wish to keep one important observation:
75 ADA addresses the immediate pressure; it does not resolve the underlying economics of running a stake pool.
Over the longer term, what continues to concern me most is whether fee revenue can grow, whether the reward structure can improve, and whether Cardano’s overall economic model can move toward a healthier and more sustainable path.
For these reasons, I am casting a Yes vote.
I support the necessary near-term relief, while remaining mindful of the longer-term issues that still need to be addressed. - Yes501.3K ₳Rationale
- Yes448.9K ₳No rationale
- Yes436.1K ₳Rationale
MinPoolCost always was a bad idea. It gives small pools a relevant competitive disadvantage because it gives an overproportional share of the rewards to the pool operator when the pool only produces one or two blocks in an epoch leaving a very suboptimal return on stake for the delegators. This parameter should go down asap. A replacement by MinMargin in one of the upcoming protocol upgrades would be good, but letting MinPoolCost go down further is a good step independent of that.
For the increase of memory limits, I trust the judgement of the committee.
- No432.6K ₳No rationale
- Yes409.2K ₳No rationale
- Abstain347.7K ₳No rationale
- Abstain341.1K ₳Rationale
Abstaining from voting as a DRep due to my role as a member of the Tingvard constitutional consortium, ensuring structural independence and avoiding conflicts of interest between governance delegation and constitutional interpretation.
Thank you for reading my rationale. You can follow my governance journey on X as user @kenerik
- Yes318.8K ₳No rationale
- Yes315.5K ₳No rationale
- Yes287.5K ₳No rationale
- Abstain282.6K ₳No rationale
- Yes272.2K ₳No rationale
- Yes268.8K ₳No rationale
- Yes252.5K ₳No rationale
- No246K ₳Rationale
75 Ada ($17.17 today after a recent Ada price pump) per epoch is NOT sustainable for any pool, and especially not for small single pools which make up all of Cardano's real distribution and allow it to be decentralized. Lowering minPoolCost with no other method of fair operator rewards in place would be wildly irresponsible. "It's just a minimum" is a tone-deaf misunderstanding of the reality of operating a stake pool. Small single pools must always stick to the minimums to stay competitive and retain delegators, and lowering the minimums pushes them away due to the costs associated with running and maintaining a stake pool. Without these small pool operators the chain would soon be captured by massive multi-pools and centralized exchange pools using user funds to profit and vote - these lower the minimum attack vector significantly and create a massive risk for the network.
Including Plutus Memory Limits in this proposal is a strange choice, though thankfully it does mean that actual stake pool operators get to vote on this (not just dReps) to block the minPoolCost change and save the network from a downturn in decentralization. - Yes237.9K ₳No rationale
- Yes233.1K ₳Rationale
I am voting YES on this governance action because I believe both proposed parameter changes are reasonable, evidence-based, and supportive of Cardano’s long-term decentralization, scalability, and ecosystem growth.
The first component of this proposal reduces minPoolCost from 170 ADA to 75 ADA. I support this change because the current fixed minimum cost can place a disproportionate burden on smaller and independent stake pool operators, particularly those that produce relatively few blocks per epoch.
As staking rewards gradually decline over time, a fixed minimum pool cost represents an increasingly large portion of the rewards generated by smaller pools. This can make those pools less attractive to delegators, even when they are technically well operated and contribute positively to Cardano’s decentralization.
Lowering minPoolCost does not force stake pool operators to charge only 75 ADA. It simply lowers the protocol-defined minimum. Operators remain free to set a higher fixed cost if that better reflects their operating expenses, infrastructure requirements, or business model.
I believe this added flexibility is important. Cardano should avoid creating economic conditions that unintentionally favor only large pools or large multi-pool operations. Smaller independent operators are an important part of a healthy and geographically distributed staking ecosystem, and protocol parameters should not create unnecessary structural disadvantages for them.
I also recognize the concern that lowering the minimum could create competitive pressure for operators to reduce fees below sustainable levels. That concern is valid and should continue to be monitored. However, because the parameter establishes a minimum rather than a mandatory fee, I believe operators and delegators should have greater freedom to determine what fee structures are appropriate.
The second component of this proposal increases Plutus memory limits. I strongly support this change.
The proposal increases transaction memory from 16.5 million units to 17.5 million units and block memory from 72 million units to 77.5 million units. These increases provide additional execution capacity for more sophisticated Plutus scripts and applications.
Cardano’s application ecosystem continues to evolve. DeFi protocols, aggregators, lending platforms, DEXs, complex multi-script transactions, and other applications increasingly require greater computational resources. Providing developers with additional memory capacity gives them more room to build sophisticated applications without unnecessarily constraining functionality at the protocol level.
What I particularly support is the measured way this increase has been approached.
The previous memory increase was implemented first, observed under real network conditions, and then evaluated before proceeding with the next stage. That is exactly how protocol parameter changes should be handled.
Rather than making aggressive changes based only on theoretical demand, Cardano has the ability to increase capacity incrementally, observe network behavior, evaluate utilization, and proceed based on evidence.
The fact that transactions have already made use of the additional memory provided by the previous increase demonstrates that this is not simply an arbitrary increase in theoretical limits. There is real demand for additional execution capacity.
At the same time, the proposed increases remain within Cardano’s constitutional parameter guardrails. Those guardrails exist to protect network performance, block propagation, validation times, and node accessibility. Expanding capacity while respecting those limits represents a responsible balance between scalability and network safety.
This proposal also illustrates one of the strengths of Cardano’s governance and development philosophy: protocol parameters can evolve gradually as network usage changes, rather than requiring disruptive redesigns or reactive decisions.
I do have one reservation regarding the structure of this governance action. The minPoolCost reduction and Plutus memory increases address two largely unrelated areas of the protocol—stake pool economics and smart contract execution capacity.
As a general governance principle, I would prefer unrelated parameter changes to be submitted as separate governance actions whenever practical. Separate actions provide clearer voting signals and allow DReps and SPOs to evaluate each issue independently.
However, in this case, I find both individual changes sufficiently justified on their own merits, so the bundling does not prevent me from supporting the action.
Reducing minPoolCost provides greater economic flexibility for stake pool operators and may help smaller pools remain competitive, supporting Cardano’s decentralization.
Increasing Plutus memory limits expands the capabilities available to developers and applications while following a cautious, incremental, and evidence-based approach.
Both changes reflect responsible protocol stewardship rather than unnecessary experimentation.
For these reasons, I vote YES on the governance action to reduce minPoolCost to 75 ADA and increase Plutus memory limits.
- Yes196.7K ₳No rationale
- Yes189.6K ₳No rationale
- Yes184.3K ₳No rationale
- Yes182.6K ₳No rationale
- Yes166.5K ₳Rationale
I am voting Yes on this proposal.
I believe reducing minPoolCost from 170 ADA to 75 ADA is a reasonable and necessary stopgap while Cardano works toward a better long-term solution based on a proportional or variable minimum pool cost.
The economics that originally justified a relatively high fixed minPoolCost have changed significantly. Block rewards have continued to decline, and a fixed 170 ADA cost now represents a disproportionately large percentage of the rewards earned by small pools that may only produce one or two blocks in an epoch. That directly reduces the return available to their delegators and makes it more difficult for smaller independent pools to compete with large, consistently producing operators.
I also think the experience since the previous reduction from 340 ADA to 170 ADA is important. We did not see the ecosystem collapse into a universal race to the minimum fee. Pool operators continued to price their services differently, while the lower floor gave smaller pools additional flexibility when they needed it. Reducing the minimum to 75 ADA likewise does not require any operator to charge 75 ADA; it simply gives them the ability to do so.
I am also persuaded by the updated incentive analysis suggesting that a large fixed minimum cost is not necessarily an effective Sybil deterrent and may actually benefit large operators capable of splitting stake among multiple pools and collecting the fixed fee repeatedly.
Ultimately, however, I do not believe that repeatedly choosing a new fixed ADA value is the ideal long-term solution. A proportional minPoolMargin, or another mechanism that allows the minimum cost to scale with pool rewards and network economics, makes substantially more sense to me than attempting to periodically recalibrate a static number. I therefore view 75 ADA as an appropriate intermediate step while that more complete solution is developed and implemented.
I also support completing the previously evaluated increase to the Plutus memory limits included in this action. This is the second step of the planned 25% increase, has already undergone technical review and testnet evaluation, and provides additional execution headroom for Plutus applications without changing the fundamental capacity relationship between transaction and block limits.
For those reasons, I support the proposal as a practical improvement to the current reward structure and network capacity while Cardano continues working toward a more durable solution for stake pool economics.
- Yes149.7K ₳Rationale
I support this action primarily because lowering minPoolCost to 75 ADA gives small pools a better chance to remain competitive and viable as rewards continue to decline. While I’m not a fan of bundling two separate changes, I see no material downside to the package as proposed.
- Abstain138.3K ₳No rationale
- Yes126.4K ₳No rationale
- Yes125.1K ₳No rationale
- Yes115.6K ₳No rationale
- Yes107.4K ₳No rationale
- Yes93.7K ₳No rationale
- Yes92K ₳Rationale
I voted yes because the proposal supports smaller stake pools by lowering the minimum pool cost and gives DApps more capacity by increasing Plutus memory limits. I believe both changes help improve Cardano’s decentralization, usability, and overall network efficiency. As a stake pool opperator Parad i see fist hand how hard it is top get pledge when small and small stake pools are good for the ecosystem.
- YesChanged86.8K ₳History
Earlier votes
Abstain25d agoSuperseded
- Yes85.7K ₳No rationale
- Yes85.6K ₳Rationale
EN — iFly (SWADA) votes YES on reducing minPoolCost from 170 to 75 ada and raising the Plutus memory limits.
DECLARED INTEREST: I operate the SWADA stake pool, which sits at the minPoolCost floor. This change directly lowers my own pool's fixed cost. I disclose that rather than leave it unstated, and readers should weigh my vote accordingly.
On the merits: as reserve-funded rewards decline, a 170 ada fixed fee consumes a punishing share of a small pool's rewards — the single-block-pool delegator penalty is already around 53% and is projected toward 100% by roughly epoch 758. IO Research has reversed its earlier position and now holds that a high floor helps large operators fragment stake into Sybil pools rather than deterring them. A healthy long tail of small, independent pools is one of my stated priorities as a DRep, and this change supports it.
Reservations: the proposal bundles two unrelated changes into a single yes/no vote, and a lower floor should arguably be paired with a minPoolMargin and an increase in k to prevent a fee race to the bottom. I would support those as follow-ups. I vote YES.
SV — iFly (SWADA) röstar JA på att sänka minPoolCost från 170 till 75 ada och höja Plutus-minnesgränserna.
REDOVISAT INTRESSE: Jag driver stakepoolen SWADA, som ligger på minPoolCost-golvet. Ändringen sänker direkt min egen pools fasta kostnad. Jag redovisar detta i stället för att lämna det osagt, och läsare bör väga min röst därefter.
I sak: när de reservfinansierade belöningarna minskar tar en fast avgift på 170 ada en orimligt stor andel av en liten pools belöningar — straffet för delegerare i en pool som gör ett block är redan runt 53% och beräknas nå 100% omkring epok 758. IO Research har ändrat sin tidigare hållning och menar nu att ett högt golv hjälper stora operatörer att splittra stake i Sybil-pooler snarare än att avskräcka dem. En sund lång svans av små, oberoende pooler är en av mina uttalade prioriteringar som DRep, och denna ändring stödjer den.
Invändningar: förslaget paketerar två orelaterade ändringar i en enda ja/nej-röst, och ett lägre golv borde rimligen kombineras med en minPoolMargin och en höjning av k för att förhindra en priskrig nedåt. Jag skulle stödja detta som uppföljning. Jag röstar JA. - Yes73.8K ₳No rationale
- Yes62.6K ₳Rationale
Reducing minPoolCost to 75 ada eases a fixed fee that disproportionately penalises small pools, helping them stay competitive. Plutus memory increases are modest, incremental steps that give dApp developers more headroom.
- Yes56K ₳No rationale
- Yes53.1K ₳Rationale
Anything that lowers the barrier to entry in a blockchain ecosystem should ultimately help drive adoption, right? I'm in favor of the minPoolCost decrease from 170 ada to 75 ada.
- Yes51.8K ₳Rationale
I vote Yes for this proposal intended to Adjust the minpool Cost and PLUTUS memory limits. ~Lourde Ouroborus Imperator Aeternalis ~
- Yes50.6K ₳No rationale
- Yes45.3K ₳No rationale
- Abstain35.1K ₳No rationale
- Yes31.8K ₳No rationale
- Yes19.7K ₳Rationale
I'm genuinely in favor of what this does — it helps small pool operators stay viable and gives developers more room to actually build things on-chain. Both of those matter to me.
I wanted to hear directly from the people this affects most before voting on their economics, so I went and read what pool operators are actually saying to each other about it. It's a real debate — some want the flexibility to price lower and compete, others worry about a race to the bottom on quality. Nobody's ignoring this, they're just split, which is different from what I was worried about.
What settles it for me: this doesn't force anyone's hand. It just lowers the floor — pools that want to keep charging what they charge today can keep doing exactly that. And the problem it's solving is real and getting worse on a clock, not hypothetical. This went through the proper process too, not a side deal.
Voting yes.
- Yes18.9K ₳No rationale