Reduce minPoolCost to 75 ada and increase Plutus Memory Limits (Part 2)
Discussed in the Governance Review for epochs 650 to 652.
195 DReps voted · 71 with a rationale · 6 changed their vote · 1 re-voted unchanged
Open a row to read the rationale.
Changed votes: 5 to yes, 1 to no, together voting with 875.7M ₳ of voting power.
Voting concentration
7 of 195 DReps cast half of the voted power.
Largest voter 12.6%, top 5 combined 43.9% of 3.8B ₳ voted.
The 33 largest voters together held as much voting power as the 67.0% threshold required in yes votes.
- Yes1M ₳Rationale
This action makes two independent changes. First, it lets stake pools set their fixed fee as low as 75 ADA instead of 170 ADA. Pools are not forced to lower their fee, but smaller pools can use the lower floor to improve the return offered to delegators. The strongest evidence separate from PCP-006 is the Input Output Research incentives report: after the earlier 340→170 ADA reduction, 340 remained the dominant fee and 170 became a challenger tier rather than causing a market-wide race to the bottom. The same report identifies 873 of 1,614 active pools below the delegation level associated with consistent block production and argues that the fixed fee can favour multi-pool fragmentation by well-capitalised operators. This supports lowering the floor, although it does not independently prove that 75 ADA is the correct calibration.
Second, it completes a staged 25% increase from the original Plutus memory limits. Part 1 is already enacted. Part 2 adds only 1M transaction-memory units and 5.5M block-memory units, remaining within the Constitution's numerical guardrails. Official node 10.3 benchmarks tested much larger 1.5× and 2× budgets under an intentionally saturated workload and found predictable costs without an absolute network-performance risk, while still recommending conservative staging because deployed scripts can become dependent on higher limits.
Delivery is unusually feasible because there is no vendor, budget or long implementation chain: if ratified, the ledger changes the parameters. The strongest objection is governance quality. The action bundles unrelated economic and technical choices. Its claim that the minPoolCost change was ratified by the TSC on 9 July is not supported by the accessible minutes: the bundle was still being drafted on 8 July, and a 5–1 vote on 15 July approved concurrent Pre-Prod/Mainnet submission. The proposal also supplies no current pool-operating-cost study, numeric reversion thresholds or independently reviewed post-Part-1 mainnet telemetry.
Those shortcomings justify Medium rather than High confidence and require explicit feedback, but they do not outweigh the source-supported direction, low implementation burden and substantial safety headroom. The risk-adjusted recommendation is therefore YES.
- No984.8K ₳No rationale
- Yes966.3K ₳No rationale
- Yes929.9K ₳Rationale
We vote YES on this parameter update.
We support the reduction of minPoolCost from 170 ADA to 75 ADA because it helps improve the economic position of smaller stake pools. As block rewards continue to decline, a high fixed-fee floor creates a growing disadvantage for smaller pools and their delegators. Lowering the floor does not force any operator to reduce their fee, but it gives smaller pools more flexibility and can support a healthier, more competitive stake pool ecosystem.
We also support the second part of the Plutus memory limit increase. Completing the cumulative 25% increase gives DApp developers more execution headroom and can reduce current constraints for more complex applications. The proposal indicates that the change has been tested, remains within guardrail limits, and does not raise significant security or performance concerns.
While the two parameter changes are not directly related and bundling unrelated changes is not ideal, both changes are individually reasonable and aligned with Cardano’s long-term goals: better decentralization, stronger developer experience, and more capable on-chain applications.
For these reasons, we support this proposal.
- Yes927.7K ₳No rationale
- Yes926K ₳No rationale
- Yes924.3K ₳No rationale
- Yes920.9K ₳No rationale
- No877.5K ₳No rationale
- Yes870.3K ₳No rationale
- Yes866.3K ₳No rationale
- Yes829.9K ₳Rationale
Supporting arguments from TSC seem solid.
- No796.1K ₳Rationale
Bundling these two items together is omnibus BS. They should be evaluated independently. And lowering min pool fee without any fix to pledge and/or minimum margin fixes nothing.
- Yes792.3K ₳No rationale
- Yes742.7K ₳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. - Yes737.8K ₳No rationale
- Yes622K ₳No rationale
- Abstain604.7K ₳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.
- Yes579.1K ₳No rationale
- Abstain564.6K ₳No rationale
- No550.1K ₳Rationale
De locos!!! imposible mantener la infraestructura con estos precios!
- Yes501.3K ₳Rationale
- Yes479.2K ₳No rationale
- Yes438.6K ₳No rationale
- No433.2K ₳No rationale
- Yes388.8K ₳No rationale
- Yes379.5K ₳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.
- Yes379.3K ₳No rationale
- No356.1K ₳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. - Abstain342.8K ₳No rationale
- Yes330.6K ₳No rationale
- Yes318.6K ₳No rationale
- Abstain318.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
- Yes313.8K ₳No rationale
- No297K ₳Rationale
Summary
The following points were taken directly from the actions metadata
- From Intersect's Parameter Committee
- decrease minPoolCost from 170,000,000 Lovelace (170 ada) to 75,000,000 Lovelace (75 ada), a decrease of approximately 55.9%
- increase maxTxExecutionUnits[memory] from 16,500,000 to 17,500,000 units (+6.1%) and maxBlockExecutionUnits[memory] from 72,000,000 to 77,500,000 units (+7.6%), completing the two-step, cumulative 25% increase to both parameters begun in the linked Part 1 action.
- These two changes are otherwise unrelated: one lowers the stake pool fixed-fee floor, the other increases Plutus script execution headroom. The changes are bundled here for submission efficiency and to allow SPOs to give input on minPoolCost.
Considerations
- I do want to increase memory available to Plutus scripts. In my quantum-secure smart contract experiments this would have been useful.
- I'm not convinced we should decrease the minPoolCost as it could make it harder for smaller SPOs to be competitive while remaining profitable.
- I really appreciate the proposer being honest about why these proposals are bundled.
Conclusion
Seeing that the proposer has made it clear that these two changes need not be bundled, and that I want to support the maxTxExecutionUnits and maxBlockExecutionUnits changes but not the minPoolCost change, I find it most appropriate to reject this proposal as it exists and request that the proposer resubmit an action only to increase these two memory parameters.
Signed,
William DoyleYour friendly neighbourhood dRep!
$computerman
drep1yfpgzfymq...pzw3nt
@william00000010 on 𝕏
contact@williamdoyle.ca - Yes288.1K ₳No rationale
- Abstain285.2K ₳No rationale
- No275.2K ₳Rationale
I support completing the proposed Plutus memory-limit increase as a separate technical parameter action. The increase from 16.5M to 17.5M transaction memory units and from 72M to 77.5M block memory units completes the second stage of the previously planned 25% adjustment, follows the earlier approved Part 1 change.
However, I do not support this combined governance action. The Plutus memory-limit increase and the reduction of minPoolCost are unrelated changes that should have been submitted separately. Bundling them prevents DReps and SPOs from expressing an independent position on each parameter and forces a vote on a contested economic change as a condition of approving an otherwise supportable technical update.
minPoolCost is the protocol-enforced minimum fixed fee a stake pool may deduct from its own earned epoch rewards before the remainder is distributed. Reducing the floor from 170 ADA to 75 ADA does not lower the actual cost of operating secure, reliable infrastructure; create new rewards; attract sufficient delegation; or address the deeper causes of small-pool fragility. It may allow some operators to offer a more competitive reward profile by voluntarily reducing their declared fee, but it is a tactical reward-distribution adjustment rather than a complete decentralization or sustainability solution.
The proposal relies on the prospect of a future proportional minPoolMargin mechanism as an intended structural counterbalance. That mechanism is not part of this governance action and is neither implemented nor guaranteed to be proposed, ratified, or adequately designed. I cannot responsibly support an immediate reduction in an existing economic boundary based on the expectation that a separate future action may later supply the necessary safeguards.
Lowering the fixed-fee floor without an enacted and tested replacement framework also risks increasing dependence on external subsidy or sponsorship for operators unable to cover the genuine costs of reliable pool operation. That dynamic can create additional conflicts of interest and undermine the independent infrastructure incentives decentralization is intended to protect.
For these reasons, I would vote Yes on the Plutus memory-limit increase if presented independently, but I vote No on this bundled action in its current form.
- Yes272.2K ₳No rationale
- Yes268.9K ₳No rationale
- Yes260.8K ₳Rationale
Voting YES. Fully endorse reducing minPoolCost to 75 ADA to relieve single-block SPOs and finalizing the scheduled 25% Plutus memory limit increase to boost smart contract throughput.
- Yes258.2K ₳Rationale
minPoolCost should be 0 - give small stake pools a fair chance.
- Yes252.7K ₳No rationale
- Yes238K ₳No rationale
- Yes236.8K ₳No rationale
- Yes210.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.
- No201.5K ₳No rationale
- Yes196.9K ₳No rationale
- Yes189.8K ₳No rationale
- Yes185K ₳No rationale