Reduce minPoolCost to 75 ada and increase Plutus Memory Limits (Part 2)

System1mo ago7 posts
Participation76
Last activity23d ago
System1mo ago

On-chain governance action (Parameter Change).

Intersect's Parameter Committee proposes a single Parameter Update governance action bundling two independent, previously recommended protocol parameter changes:

  1. minPoolCost: decrease minPoolCost from 170,000,000 Lovelace (170 ada) to 75,000,000 Lovelace (75 ada), a decrease of approximately 55.9%.
  2. Plutus memory unit limits (Part 2 of 2): 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. No other protocol parameters or Plutus cost model settings are changed by this action.

  • Proposer return address: stake1uyvjdz9rxsfsmv44rtk75k2rqyqskrga96dgdfrqjvjjpwsefcjnp
  • Deposit: 100,000 ₳
  • Submitted: epoch 646
  • Expires: epoch 653

View in explorer

ADAtainmentDRepVoted YESRationale1mo ago

Frozen. On-chain rationale, submitted 1mo ago.

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.

TriangleForcesDRepVoted NORationale1mo ago

Frozen. On-chain rationale, submitted 1mo ago.

And again we've two unrelated things bundled together: one economic (minPoolCost reduction) and one technical parameter change (Plutus memory limits increase). All for governance convenience, or so we're told.

The minPoolCost reduction is designed to help smaller pools cope with lower rewards, which is crucial for keeping the system decentralized and ensuring pools can continue operating before any increase in k. The pitch leans on forecasts and incentives reports that themselves have shifted positions multiple times, which doesn’t show much confidence in my experience. The risk of encouraging Sybil attacks through stake fragmentation is acknowledged but downplayed, relying on a future proportional minPoolMargin fix that remains speculative. Frankly, another hack isn't what Cardano needs right now.

The empirical evidence since 2023 shows no market collapse at 170 ADA, which begs the question: is a further halving necessary now, or premature? Yet again in good Cardano fashion, the symptom (maintenance costs for running a SPO under declining rewards) is listed without addressing the cause head-on: Rewards are declining because reserve emissions are falling while transaction fee growth has not offset them! Reducing the minPoolCost is a mere tactical fix for declining rewards, not a structural answer, and I do see the risk that another floor reduction further delays the harder work of improving fees, transaction demand, and reward sustainability.

And talking of decentralization? Given that IO just gobbled up the majority of the 350M ADA NCL for "critical infrastructure maintenance", how "decentralized" is the Cardano blockchain anyways? Who are we fooling here?

On the technical side, completing the **25% increase in Plutus memory units is a low-risk, well-tested step **that directly benefits DApp developers by expanding execution headroom. This aligns with Cardano’s scaling roadmap and does not compromise security or performance based on recent node benchmarks.

I won't approve a minPoolCost reduction without clearer structural replacements and steps to address the underlying cause of the problem. This is a premature, tactical band-aid on a structural wound that demands a more comprehensive, evidence-backed solution.

The Plutus memory increase on the other hand is sensible and overdue but should stand alone to avoid conflating economic and technical governance decisions. It shouldn't be bundled with an economically sensitive parameter change.

CardanoLeoDRepVoted YESRationale1mo ago

Frozen. On-chain rationale, submitted 1mo ago.

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.

Mike Rogero (羅邁凱)DRepVoted YESRationale1mo ago

Frozen. On-chain rationale, submitted 1mo ago.

I believe that core parameter changes should be in the realm of critical decisions that must be in the hands of experts charged with fully modeling the impact and unintended consequences of such changes. The best body we currently have with this responsibility is Intersect, so as a DRep, I see voting yes as simply a ratification of supporting the governance structure we have in place and ratifying the opinion of the professionals given the responsibility and role to make proposals.

I do not see anything within the proposal that in my personal opinion causes concern, and thus without a significant against by Cardano Foundation or IOG, my position is to support the institution we have invested with the responsibility for these types of decisions.

Chris CataDRepVoted YESRationale28d ago

Frozen. On-chain rationale, submitted 28d ago.

Update Constitutional Committee 2026 — YES

I am voting YES on this update. I don't have any significant concerns with the proposed Constitutional Committee changes, and maintaining a fully functioning Constitutional Committee is important for governance continuity. This appears to be a reasonable operational update, and I support moving it forward.

Reduce minPoolCost to 75 ADA & Increase Plutus Memory Limits (Part 2) — YES

I am voting YES on these parameter updates. Lowering minPoolCost continues the effort to better align stake pool economics as rewards naturally decline, while increasing Plutus memory limits provides additional capacity for developers and smart contracts with low expected technical risk based on the testing and phased rollout that has preceded these changes.

That said, I do want to register one concern with the governance process itself. I do not believe unrelated parameter updates should be bundled into a single governance action. Each parameter change should stand on its own merits so DReps can evaluate and vote on each independently.

Martin LangDRepVoted No23d ago

I have voted NO on the "Reduce minPoolCost to 75 ada and increase Plutus Memory Limits (Part 2)" governance action as a DRep and as a SPO, because reducing minPoolCost even more makes no sense to me.

Thats not sustainable for an SPO on any level. And even this small value is a threshold that puts small pools in a disadvantage.

We need a minMargin parameter with a sustainable level first, before getting rid of minPoolCost at all. Evens the field for everybody, small and large pools.

I would have voted YES on the Plutus Memory Limits, but not in this combination.

Cite