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.
- YesChanged480M ₳Rationale
Yoroi DRep votes YES on Reduce minPoolCost to 75 ada and increase Plutus Memory Limits (Part 2).
Change of Vote: Yoroi previously voted ABSTAIN on this proposal. Having considered the proposed changes further, we have decided to change our position to YES.
Why We Support It: Lowering minPoolCost to 75 ADA may help reduce the operating burden for stake pools, while increasing the Plutus memory limits gives developers and applications more room to operate within the network. These are practical adjustments that can support broader participation and continued growth across the Cardano ecosystem.
Yoroi supports moving these parameter changes forward and votes YES.
Earlier votes
Abstain15d agoSuperseded
Yoroi DRep votes ABSTAIN on Reduce minPoolCost to 75 ada and increase Plutus Memory Limits (Part 2). Yoroi recognises the importance of responsible governance during periods of ecosystem uncertainty.
- Ecosystem Situation: The trust our delegators place in Yoroi requires that we act only when we can do so with full confidence. In light of the current situation, Yoroi is choosing to withhold its vote on this proposal and will reassess our position once conditions allow for a considered decision.
- Yes395.6M ₳Rationale
I vote YES on "Reduce minPoolCost to 75 ada and increase Plutus Memory Limits (Part 2)".
Lowering minPoolCost from 170 to 75 ADA reduces the entry barrier for small pools and strengthens decentralization — a direction I have long advocated, and I agree with it. As a disclosure: since I am also an SPO, I considered whether this creates a conflict of interest. This change promotes fee competition by lowering the minimum fixed cost, and is if anything likely to work against my own pool income. I therefore judge that this YES vote is unlikely to serve my private interest, and does not constitute a conflict of interest.
The increase in Plutus memory limits is the second half of a phased increase (Part 2 of 2). No issues have been observed since Part 1 took effect, and weighing all information currently accessible to me, the benefit — more headroom for dApp execution — is clear, while I find no serious downside.
「Reduce minPoolCost to 75 ada and increase Plutus Memory Limits (Part 2)」にYESを投票します。
minPoolCostの170 ADA→75 ADAへの引き下げは、小規模プールの参入障壁を下げ分散性を高めるものとして、私が以前から主張してきた方向性であり、同意します。なお開示として：私自身もSPOであるため利益相反の可能性を検討しましたが、この変更は最低固定費の引き下げによって手数料競争を促すもので、既存SPOである私の収入にはむしろ減少方向に作用しうるものです。したがって、このYES投票が私的利益に資する可能性は低く、利益相反には当たらないと判断しています。
Plutusメモリ上限の引き上げは、段階的引き上げの後半（Part 2 of 2）です。先行して施行されたPart 1で問題は観測されておらず、現在アクセスできる情報を総合的に勘案する限り、dAppの実行余地拡大というメリットが明確である一方、深刻なデメリットは見当たりません。
- YesChanged305.5M ₳Rationale
EMURGO as a DRep previously voted ABSTAIN on Reduce minPoolCost to 75 ada and increase Plutus Memory Limits (Part 2). After taking another look at the proposal, we are changing our vote to YES.
The proposal makes two practical protocol updates: lowering minPoolCost to 75 ADA and increasing the memory limits available to Plutus transactions and blocks. Together, these changes can make it easier for stake pools to operate sustainably while giving developers more room to build and run applications on Cardano. We believe these are positive steps for the ecosystem and therefore support the proposal with a YES vote.
Earlier votes
Abstain15d agoSuperseded
EMURGO as a DRep votes ABSTAIN on Reduce minPoolCost to 75 ada and increase Plutus Memory Limits (Part 2), with rationale outlined below.
Given the ongoing situation in the ecosystem, responsible governance requires us to act with full clarity and confidence. Until the current situation reaches resolution, EMURGO prefers to withhold judgment rather than vote without the certainty our mandate demands. We will revisit this proposal once the situation is resolved.
- Yes271.8M ₳No rationale
- Yes219.9M ₳Rationale
Both changes are welcome.
- Yes181.1M ₳No rationale
- Yes156.5M ₳Rationale
The Cardano Foundation votes YES. The Plutus memory increase completes a two-step change we have already supported, and the reduction of
minPoolCostto 75 ada is a proportionate, evidence-based response to the declining share of block rewards.A PDF version of this rationale is also made available.
We commend Intersect's Parameter Committee and the author of PCP-006 for this action. Our decision is driven by three factors:
- Plutus Change Completion: This implements the second half of the 25 percent increase to `maxTxExecutionUnits[memory]` and `maxBlockExecutionUnits[memory]` approved on 1 October 2025. Following Preview testing in July 2026, node 10.2 and 10.3 benchmarks show adequate headroom, justifying our continued support.
- Proportionate `minPoolCost` Correction: With rewards near 300 ada per block, the 170 ada floor absorbs ~57 percent of a single-block pool's gross reward, raising the delegator penalty to ~52.8 percent and projecting 100 percent by epoch 758. Reducing the floor to 75 ada restores that share to ~25 percent, ensuring long-term economic predictability.
- Empirical Evidence: The 2023 reduction from 340 ada to 170 ada showed that a lower floor does not trigger a race to the bottom; 340 ada remained dominant. Operators can maintain higher fees if necessary, making a repeat concern unlikely.
The Cardano Foundation votes YES. Both changes are evidence-based, committee-reviewed, testnet-validated, and within constitutional guardrails.
NOTE on 'Internal Voting':
The fields constitutional and unconstitutional below reflect the CF governance teams' individual opinions whether they are for or against the proposal. Reason for this inconsistency is, that CIP-136 is at the moment only applicable to CC rationales, but we want to record the internal opinions of our DRep assessment transparently as well. - Yes93.3M ₳Rationale
As a DRep, I decided to vote YES for the proposal: Reduce minPoolCost to 75 ada and increase Plutus Memory Limits (Part 2).
My rationale:
I support reducing minPoolCost from 170 ada to 75 ada. As reserve-funded rewards decline, the fixed fee consumes an increasing proportion of the rewards earned by pools producing only one or a few blocks. This reduces returns for their delegators and makes smaller pools less competitive against established pools that can spread the fixed fee across many blocks.
The previous reduction did not cause a market-wide race to the minimum, and operators remain free to maintain a higher fixed fee if it reflects their costs and business model.
I also support completing the staged 25% increase in Plutus memory limits. The first step demonstrated demand for the additional capacity without reported network instability, while benchmarking indicates sufficient performance headroom for the proposed final values. Keeping the transaction and block limits proportionally aligned also preserves the number of maximum-sized transactions that can fit into a block.
However, these are two unrelated parameter changes, and bundling them is bad governance practice. It prevents DReps and SPOs from expressing an independent position on each change and can alter which governance bodies effectively decide an otherwise separate issue.
I tolerate the bundling in this exceptional case only because I support both changes independently. This vote should not be treated as support for bundling unrelated parameter changes in future actions. Future parameter changes should be submitted separately whenever possible.
I perceive the reduction of minPoolCost as a preparatory step towards further improvements to the staking incentives, including a possible increase of stakePoolTargetNum (k). I agree with that sequencing. Increasing k lowers the saturation point and can encourage stake to move towards a larger number of pools, but smaller pools must first be sufficiently competitive to receive that delegation. Otherwise, increasing k may mainly encourage established multi-pool and private operators to split their stake across additional pools.
I therefore expect an increase of k to be considered as the next concrete step. It should be proposed through a separate governance action, supported by updated modeling of stake redistribution, multi-pool splitting, saturation levels, and the likely effects on single-pool operators.
My support for this action does not pre-approve a particular value of k, but I do not want the reduction of minPoolCost to become an isolated adjustment without the follow-up reform used to justify it.
If you'd like to support my work, consider delegating to the MANDA pool and backing me as a DRep. Your support is the only way I can get time for governance.
MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8My DRep ID:
drep1y2m0g4r66...skqwqpBuy me a beer:
https://pay.cexplorer.io/pay/c0410d5b237b6ec0 - Yes92.5M ₳No rationale
- Yes89.4M ₳No rationale
- Yes87.9M ₳Rationale
Voting yes for a minPoolCost that may be less of an obstacle for smaller pools and the increase in Plutus Memory Limits to allow for forward progress.
- Abstain87.5M ₳No rationale
- Yes84.3M ₳Rationale
Reducing minPoolCost from 170 ADA to 75 ADA will lessen the impact of fixed fees on smaller pools and their delegators as block rewards decline, improving competitive conditions among stake pools.
A high fixed cost may disadvantage smaller pools while relatively benefiting larger operators capable of running multiple pools. I consider the reduction to 75 ADA a reasonable and gradual step toward structural reforms such as
minPoolMargin.The increase in Plutus memory limits is the second stage of the previously approved 25% increase. It has undergone testnet deployment and performance evaluation, remains within the guardrails, and will reduce constraints on DApp development while maintaining network safety.
As a minor consideration, the action combines changes of a different nature. Where practical, future changes should be submitted separately to allow independent evaluation. Nevertheless, I support both changes included in this action and therefore vote YES.
本提案によるminPoolCostの170 ADAから75 ADAへの引き下げは、ブロック報酬が減少する中、小規模プールとその委任者に対する固定費の影響を緩和し、ステークプール間の競争条件を改善するものです。
高い固定費は小規模プールを不利にする一方、複数プールを運営できる大規模事業者を相対的に有利にする可能性があります。75 ADAへの変更は、将来的な
minPoolMarginなどの構造的改革に向けた、段階的かつ妥当な措置だと判断しました。Plutusメモリ上限の引き上げも、承認済みの25％引き上げ計画の第2段階です。テストネットと性能評価を経てガードレールの範囲内に収まっており、ネットワークの安全性を維持しながらDApp開発上の制約を緩和する変更として支持します。
なお、性質の異なる変更が一つのアクションに含まれているため、今後は可能な限り個別に判断できる形での提出が望ましいと考えます。ただし、今回は双方の変更を支持できるため、YESとします。
- Yes82.9M ₳Rationale
SIPO DRep votes YES on the parameter update reducing minPoolCost to 75 ada and completing the increase to Plutus memory limits.
The action bundles two changes that Intersect's Parameter Committee had previously recommended separately. The first reduces minPoolCost from 170,000,000 lovelace to 75,000,000 lovelace, a decrease of about 56 percent. The second raises maxTxExecutionUnits[memory] from 16,500,000 to 17,500,000 units and maxBlockExecutionUnits[memory] from 72,000,000 to 77,500,000 units, completing a cumulative 25 percent increase that could not be made in one step because guardrails MTEU-M-04 and MBEU-M-03 cap how far either parameter may rise in a single action. The Technical Steering Committee ratified the minPoolCost reduction on 9 July 2026. No other parameters and no Plutus cost model settings are changed.
SIPO takes the Plutus limits to be uncontentious. They complete a target the Parameter Committee recommended and the Technical Steering Committee ratified, and the two-step path is a consequence of the guardrails working as designed rather than of any disagreement about the destination.
On minPoolCost, SIPO finds the evidence persuasive. The parameter was calibrated at Shelley launch against an ada price, an inflation schedule, and an estimate of operating costs that have all since moved. Gross rewards have fallen from roughly 1,800 ada per block to around 300 as the reserve depletes, so a fixed floor that was tolerable in 2020 now consumes a disproportionate share of what a small pool earns. At approximately 300 ada per block, the floor takes about 57 percent of a single-block pool's gross reward at 170 ada, and about 25 percent at 75. The delegator penalty on single-block pools, which the 2023 reduction from 340 ada brought down to roughly 28 percent, has climbed back to roughly 53 percent and is projected to reach 100 percent around epoch 758 if nothing changes. A floor that trends toward consuming the entire reward of a small pool is not a neutral setting. It is a gradual exclusion.
SIPO also weighs the reversal in IO Research's assessment. The original case for a high fixed-fee floor was that it deters Sybil-style stake fragmentation. IO Research now assesses that a high floor favours such fragmentation by large operators rather than deterring it, because an operator with scale can absorb a fixed cost across many pools while an independent operator cannot. When the evidence for a parameter's original justification reverses, the parameter should be revisited. That is what this action does.
SIPO states its own position plainly rather than leaving it to be inferred. SIPO operates stake pools, and every one of them declares a fixed cost of 340 ada, twice the current floor. SIPO is therefore not at the floor, and this reduction produces no mechanical change to SIPO's own revenue. SIPO is not making a sacrifice here and does not present this vote as one. SIPO supports the change because small-pool viability is a precondition for a distributed operator set, and a distributed operator set is what makes this network worth operating in.
SIPO records one reservation, directed at what follows rather than at this action. The proposal presents the reduction as a prerequisite step toward a future increase in stakePoolTargetNum, on the reasoning that smaller pools must be economically viable before raising k can be effective. SIPO accepts that reasoning as far as it goes. It does not follow that SIPO supports any particular value of k. Raising k lowers the saturation point proportionally, and a large increase would place pools that are presently well within saturation above it, redistributing delegation and affecting operators who have done nothing wrong. That is a separate question with its own evidence, and SIPO expects it to arrive as its own governance action accompanied by a published saturation analysis, rather than to be treated as settled by this vote. A Yes here is support for repairing small-pool economics. It is not a proxy vote on k.
This vote is SIPO DRep's recorded position.
SIPO DRep は、minPoolCost を 75 ADA に引き下げ、Plutus メモリ上限の引き上げを完了させるパラメータ更新に賛成（YES）を投じます。
本アクションは、Intersect の Parameter Committee がこれまで個別に推奨してきた 2 つの変更を束ねたものです。第一に、minPoolCost を 170,000,000 lovelace から 75,000,000 lovelace へ、約 56% 引き下げます。第二に、maxTxExecutionUnits[memory] を 16,500,000 から 17,500,000 ユニットへ、maxBlockExecutionUnits[memory] を 72,000,000 から 77,500,000 ユニットへ引き上げ、累積 25% の増加を完了させます。この増加を一度に行えなかったのは、ガードレール MTEU-M-04 および MBEU-M-03 が、単一のアクションで各パラメータを引き上げられる幅を制限しているためです。Technical Steering Committee は 2026 年 7 月 9 日に minPoolCost の引き下げを批准しました。他のパラメータおよび Plutus コストモデルの設定は変更されません。
SIPO は、Plutus 上限側を争点とは考えません。これは Parameter Committee が推奨し Technical Steering Committee が批准した目標値を完成させるものであり、2 段階になったのは目的地についての意見の相違ではなく、ガードレールが設計どおりに機能した結果です。
minPoolCost について、SIPO は提示された証拠に説得力を認めます。本パラメータは Shelley ローンチ時に、当時の ADA 価格、当時のインフレスケジュール、そして当時の運用コスト見積りに対して較正されました。その 3 つはいずれもその後変化しています。リザーブの枯渇に伴い、ブロックあたりの総報酬は約 1,800 ADA から約 300 ADA へ低下しました。したがって 2020 年には許容できた固定下限が、いまや小規模プールの稼得に対して不釣り合いな割合を占めています。ブロックあたり約 300 ADA の水準では、1 ブロックプールの総報酬に占める下限の割合は、170 ADA で約 57%、75 ADA で約 25% です。単一ブロックプールにおける委任者ペナルティは、2023 年の 340 ADA からの引き下げによって約 28% まで低下しましたが、その後 約 53% まで戻っており、何も手を打たなければエポック 758 前後で 100% に達すると予測されています。小規模プールの報酬を丸ごと飲み込む方向へ推移する下限は、中立的な設定ではありません。それは緩やかな排除です。
SIPO は、IO Research の評価が反転した点も重く見ます。高い固定費下限を設ける当初の論拠は、Sybil 型のステーク分割を抑止することにありました。IO Research は現在、高い下限はそうした分割を抑止するどころか、大規模事業者による分割をむしろ助長すると評価しています。規模を持つ事業者は固定費を多数のプールに分散して吸収できる一方、独立系の事業者にはそれができないからです。あるパラメータの当初の正当化根拠が、証拠によって覆されたのであれば、そのパラメータは見直されるべきです。本アクションはそれを行うものです。
SIPO は自らの立場を、推測に委ねるのではなく明確に述べます。SIPO はステークプールを運営しており、そのいずれもが固定費として 340 ADA を宣言しています。これは現行の下限の 2 倍です。したがって SIPO は下限に張り付いておらず、本引き下げは SIPO 自身の収益に機械的な変化をもたらしません。SIPO はここで犠牲を払っておらず、本投票をそのように装いません。 SIPO が本変更を支持するのは、小規模プールの成立可能性が分散した運営者層の前提条件であり、分散した運営者層こそがこのネットワークを運営するに値するものにしているからです。
SIPO は 1 点の留保を記録します。これは本アクションに対してではなく、その先に向けられたものです。本提案は、この引き下げを stakePoolTargetNum の将来的な引き上げに向けた前提条件と位置づけています。k を引き上げても、小規模プールが経済的に成立していなければ効果がない、という論理です。SIPO はその論理をその限りにおいて受け入れます。しかしそこから、SIPO が特定の k の値を支持するという帰結は導かれません。k の引き上げは飽和点を比例して引き下げます。大幅な引き上げは、現在は飽和に十分な余裕を持つプールを飽和の上側に置き、委任を再配分し、何ら落ち度のない運営者に影響を及ぼします。これはそれ自体の証拠を伴う別個の問題であり、SIPO は、それが本投票によって決着済みとして扱われるのではなく、公開された飽和分析を伴う独立したガバナンスアクションとして提出されることを期待します。ここでの賛成は、小規模プールの経済性を修復することへの支持です。k に対する代理投票ではありません。
本投票は SIPO DRep の記録上の立場表明です。
- No68.6M ₳Rationale
As a DRep and SPO, i have voted ❌NO on this proposal, because we need a minMargin parameter of at least 5% first before thinking about to lower minPoolCost even more. Does not make any sense to me, there is still a threshold which puts small pools in a disadvantage. Getting rid of minPoolCost while introduction minMargin is the way to go! I would have voted YES on the Plutus Memory Limits. But i am against any lowering of minPoolCost without introducing a minMargin parameter with a sustainable number parameter first.
- No56.2M ₳Rationale
NO ->> Reduce minPoolCost to 75 ada and increase Plutus Memory Limits (Part 2)
I am voting NO on this bundled Parameter Change reducing minPoolCost from 170 to 75 ADA and increasing Plutus memory execution limits by a cumulative 25%.
I fully agree with the network sustainability concerns this proposal identifies. Block rewards have fallen from approximately 1,800 ADA at Shelley launch to around 300 ADA today as the reserve depletes, while infrastructure costs have broadly risen. Against this backdrop, reducing minPoolCost may provide a stopgap with some effect for a limited period. However, given the long-term trajectory of continuously declining rewards, this is a measure that will need to be repeated — it is not a solution. The proposal itself signals that the long-term direction points toward zero, and I understand this to be a deferral rather than a resolution. The structural causes of declining rewards are the reduction in reward supply, the treasury distribution ratio, and reserve depletion. This proposal does not address any of these; it adds only a short-term stopgap. Regardless of how minPoolCost is set, block rewards will continue to fall. Small pool operators gain temporary competitive relief, but that relief will erode as rewards decline further. The underlying pressure is not resolved; it is inherited by the next parameter adjustment cycle. And above all, sustaining a pool at 75 ADA is extremely difficult given the current ADA price.
The Plutus memory limit increases may compound this problem asymmetrically. The proposal states that performance testing was conducted using current node version benchmarks, but those benchmarks reflect well-resourced infrastructure. The operators most affected by the reward reduction are smaller pools running at or near minimum viable hardware, and it is this same population for whom incremental increases in block execution load carry the greatest marginal cost. The proposal lowers their income floor and raises their operational ceiling in a single action, without verifying whether the operators absorbing the cost increase are the same population receiving the fee reduction benefit. The proposal further states that more recent node versions provide additional performance improvements. Those improvements might otherwise have translated into reduced hardware requirements for smaller operators — a concrete cost-side benefit for the pools this proposal claims to support. By consuming that headroom through increased execution limits, this action redirects the gains from node efficiency away from SPO cost relief and toward DApp execution capacity. The operators who stand to benefit least from expanded Plutus headroom may end up bearing the cost of providing it.
The performance evaluation cited covers node versions 10.2 and 10.3, conducted by IOE's Performance and Tracing team. However, the proposal does not specify the hardware profile, delegation volume, or transaction composition used in those benchmarks, nor does it provide data on how the full 25% cumulative increase performs across the range of real SPO environments currently active on mainnet. The claim that more recent node versions provide further improvements is stated without quantification. Where benchmark scope is undisclosed and headroom estimates are unquantified, the conclusion that the increase is safe cannot be fully separated from the judgment of the team that conducted the evaluation. That is not a reason to reject the change outright, but it is a reason to require a more transparent evidential basis before enacting an irreversible parameter increase bundled with an unrelated fee reduction.
This proposal also submits two independent changes simultaneously, which means an SPO who supports one and opposes the other cannot express that position. Submission efficiency and the interests of the network as a whole do not necessarily align. Each substantive change should be deliberated independently, with a vote that reflects the actual position of the stakeholders it affects.
Finally, before reducing the minimum fee floor further, the ecosystem should focus its energy on actively debating and answering why rewards continue to decline and whether that trajectory is acceptable. The question of how the reserve-to-circulation transition is managed over the coming epochs is the prior question. This proposal assumes the answer and optimises around it.
For these reasons, I vote NO.
[Japanese version follows]
「minPoolCostを170から75 ADAに引き下げ、Plutusのメモリ実行上限を累計25%引き上げる」パラメータ変更案に対し、反対票を投じます。本提案が指摘する問題であるネットワークの持続可能性の懸念については十分に同意できます。Shelleyローンチ時に約1,800 ADAあったブロック報酬は、リザーブ枯渇に伴い現在は約300 ADAにまで低下しており、一方でインフラコストは全般的に上昇しています。こうした背景のもと、minPoolCostの引き下げは明示的に「ストップギャップ（応急措置）」として一定期間の効果があると考えられます。しかしこれは、長期的に減少し続けるリワードを念頭に置くと、繰り返さざるを得ない応急措置であり、解決策ではありません。本提案自体が長期的な方向性として0への収束を示唆していることからも、これは問題の先送りにすぎないことを理解しています。報酬低下の構造的原因は、リワード供給の減少、トレジャリー分配比率、そしてリザーブの枯渇です。本提案はこれらに対処せず、短期的な応急措置を加えるに過ぎません。minPoolCostがどう設定されようと、ブロック報酬は引き続き下落します。小規模プールオペレーターは一時的な競争力改善を得ますが、それはさらなる報酬低下とともに失われます。根本的な圧力は解消されず、次のパラメータ調整サイクルに引き継がれるだけです。そして何より、75 ADAでプールを維持し続けることは現在のADA価格を考慮すると非常に難しいと言えます。
そしてPlutusメモリ上限の引き上げは、この問題を非対称的に悪化させる可能性があります。本提案では性能テストを現行ノードバージョンのベンチマークで実施したと述べていますが、それは潤沢なインフラを前提とした環境です。報酬削減の影響を最も大きく受けるのは、最低限のハードウェアで運用している小規模プールです。ブロック実行負荷の増加が限界コストとして最も重くのしかかるのも、この小規模プール層です。本提案は一つのアクションで彼らの収入下限を引き下げ、運用上限を引き上げていますが、コスト増を吸収するオペレーターと手数料削減の恩恵を受けるオペレーターが同一かどうかを検証してはいません。さらに本提案は、より新しいノードバージョンが追加的な性能改善をもたらすと述べています。本来であればその改善は、小規模オペレーターのハードウェア要件の引き下げ、すなわち本提案が支援の対象と位置づけるプールへの具体的なコスト削減として還元されるはずのものです。しかしメモリ上限の引き上げによってそのヘッドルームを即座に消費することで、本アクションはノード効率化による果実をSPOのコスト軽減からDAppの実行余裕へと転用しています。Plutusのヘッドルーム拡大から最も恩恵を受けない層が、その提供コストを負担することになる可能性があります。
引用された性能評価はnode 10.2および10.3を対象にIOEのPerformance & Tracingチームが実施したものです。しかし本提案では、当該ベンチマークで使用されたハードウェアプロファイル、委任量、トランザクション構成を明示していません。また累計25%の引き上げがメインネットで実際に稼働している多様なSPO環境全体においてどのように機能するかを示すデータも提供されていません。より新しいノードバージョンがさらなる改善をもたらすという主張も数値的な裏付けを伴っていません。ベンチマークの範囲が非公開でヘッドルームの推定が定量化されていない場合、「引き上げは安全である」という結論を、評価を実施したチームの判断から切り離すことはできません。これは変更を全面的に否定する理由ではありませんが、無関係な手数料削減とバンドルされた不可逆的なパラメータ引き上げを承認する前に、より透明性の高いエビデンス基盤を求める十分な理由となります。
また本提案は個別の２つの提案を同時に提出しており、一方の変更に賛成し、もう一方に反対するSPOは、その立場を表明できません。提出数を効率化することと、ネットワーク全体の利益は必ずしも一致しません。実質的な変更はそれぞれ独立して審議され、影響を受けるステークホルダーが実際の立場を反映した投票を行えるべきです。
さらに、最低手数料フロアをさらに引き下げる前に、なぜ報酬が低下し続けているのか、そのトレジェクトリーは許容できるのかを確認し、活発に議論し答えを出すことに注力すべきと考えます。今後のエポックにわたるリザーブから流通への移行をどう管理するかという問いが、先に答えられるべき問いです。本提案はその答えを所与のものとして、その周辺を最適化しています。
以上の理由から、私は本提案に対して反対票を投じます。 - Yes53.3M ₳No rationale
- Yes51M ₳Rationale
While there seem to be few concerns about the proposed changes to the Plutus limits, I've seen several SPOs raise concerns about reducing minPoolCost to 75 ADA, arguing that it could make running a pool unprofitable.
I don't share this concern, because minPoolCost does not require pool operators to set their PoolCost to the minimum allowed value. The current minPoolCost is 170 ADA, yet many pools already have a higher PoolCost — 200, 340, or even 500+ ADA.
Pool operators are free to choose whatever value they consider appropriate and that allows their pool to remain profitable.
Therefore, I'm voting Yes on both parameter changes.
- Yes44M ₳No rationale
- Yes43M ₳No rationale
- Yes42.1M ₳No rationale
- Yes41.9M ₳No rationale
- Yes35.1M ₳No rationale
- Yes32.3M ₳Rationale
I voted Yes because this parameter update strengthens Cardano’s long‑term stability and operational health. Lowering minPoolCost improves the economic viability of small pools and supports a more decentralized and competitive staking ecosystem, while the final step of the Plutus memory increase provides needed execution headroom for developers without compromising network performance or security. Both changes are evidence‑based, committee‑ratified, and consistent with constitutional guardrails. Supporting this action contributes directly to the sustainable functioning of the Cardano chain.
- Yes28.8M ₳No rationale
- Yes28M ₳Rationale
I am the author of the Parameter Change Proposal that requested minPoolCost be lowered to 75. Ultimately I think the parameter should be set to zero and removed entirely, however I do not think there is enough political will in the Cardano community to support doing that straight away unfortunately. I see this as an intermediate step to replacing it with minPoolMargin. Note that minPoolCost is just a global minimum fixed fee. Pools can still charge whatever fixed fee they want as long as it is above this global miniumum.
In regards to the Plutus Memory Limits, these changes are well-within our capabilities and I see no reason to vote against them.
- Yes26M ₳Rationale
Would have rather these been split into two separate proposals but it is what it is and will benefit spo's
- Yes23.6M ₳Rationale
Reducing the minimum pool cost towards 0 is good, especially with min pool margin on the horizon.
- Yes21.7M ₳No rationale
- Yes21.6M ₳Rationale
I vote YES on the Protocol Parameter Update action "Reduce minPoolCost to 75 ada and increase Plutus Memory Limits (Part 2)" (ab474223d40e2e...a306#0).
On bundling
It is unfortunate that these two parameter updates were bundled into the same action. It has been demonstrated on-chain that chaining governance actions of the same type can be coordinated successfully. This bundling denies governance actors the ability to assess each on their merits and muddies the waters about who is actually voting on what. minPoolCost, although a parameter that impacts SPO operations, is not actually voted on by SPOs. Bundling it with the Plutus memory units action that DOES require an SPO vote makes it appear as though SPOs have a say on minPoolCost, when they do not. It was also a risk as minPoolCost could be seen as a more contentious update than the Plutus memory units update which has already seen "Part 1" approved earlier this year. I would have preferred to have seen the Plutus memory limits proposal submitted first, with minPoolCost chained to it, and appropriate educational communications put forth as to the reasoning and sequencing of their submissions and potential ratifications.
Plutus memory units
I vote YES on the Plutus memory units increase as it is "Part 2" of the proposed increase from earlier this year. This was not possible to achieve in one step due to Constitutional guardrails limiting the size of the increase in one step. "Part 1" was approved, has been enacted and live for a number of months now with no ill side-effects. Therefore, I trust the benchmarking and analysis of the Technical Steering and Parameter Committees and vote YES.
minPoolCost reduction
I also vote YES on the reduction of minPoolCost. While Bitcoin has its widely acknowledged and often celebrated "halving" events, Cardano also experiences its own "halvings". The only difference is, Bitcoin reward halvings are step-changes, while Cardano rewards decline along a curve every epoch. As a result, it often goes unnoticed. Block rewards are now below 300 ada, in 2020 they were above 1000 ada. minPoolCost is the minimum fixed fee imposed by the network and is deducted from any block rewards earned in an epoch. If no blocks are produced, no fee is taken. As block rewards decline, this fixed fee negatively impacts smaller pools that make less blocks per epoch than larger pools. A pool only making one block per epoch is forced to take ~57% of the rewards in fees (if margin is set to 0%), reducing their ability to offer more competitive returns each epoch that they validate blocks. When minPoolCost was last reduced from 340 to 170 there were concerns about a "race to the bottom" which history has shown did not materialise and many pools still operate with a 340 ada fee today. This reduction lowers the minimum while still allowing operators the freedom to choose any number above that.
- Yes20.7M ₳No rationale
- No20.3M ₳No rationale
- No20.2M ₳Rationale
Yes to Increase Plutus Memory Limits (Part 2), no to Reduce minPoolCost to 75 ada. As this is bundled, I vote no. We should not reduce or eliminate minPoolCost before introducing minMargin with a sensible value for minimal sustainability, between 5 and 10%.
- Yes17.4M ₳No rationale
- Abstain16.6M ₳Rationale
As both a DRep and an SPO, we are directly affected by changes to minPoolCost and recognize the potential conflict of interest.
More importantly, this action bundles two unrelated parameter changes. We would support the proposed increase in Plutus memory limits, while the reduction of minPoolCost involves separate economic and decentralization trade-offs that deserve an independent vote.
Bundling the changes prevents governance participants from expressing a clear position on each proposal. We encourage their resubmission as separate governance actions.
- Yes16.3M ₳Rationale
Vote: YES
This Protocol Parameter Update (ab474223d40e2e3540555364be27e161a809c33651408f43d84acff10c0ba306), submitted by Intersect on August 3, 2026, makes two changes. It reduces minPoolCost from 170 ada to 75 ada, a 55.9% cut to the flat fee every stake pool deducts from block rewards before splitting with delegators. It also raises maxTxExecutionUnits[memory] from 16.5 million to 17.5 million units and maxBlockExecutionUnits[memory] from 72 million to 77.5 million units, completing the second half of a 25% cumulative increase from the original 14 million and 62 million limits, the first part of which was enacted on February 18, 2026. No ADA is requested and no treasury funds are involved. The action expires September 1, 2026 and requires 67% of active DRep stake and 51% of active SPO stake.
Dracula DAO votes YES. The Plutus half of this action is uncontroversial foundational work: it completes a capacity increase the ecosystem already approved in principle and enacted half of six months ago, it has been validated on testnet, and the 6.1% and 7.6% steps are deliberately conservative. The minPoolCost half addresses a problem that is real, quantified, and getting worse. The 170 ada floor was calibrated against a reward environment that no longer exists; as reserve-funded emissions decline, a fixed fee consumes a steadily rising share of a small pool's rewards, and Intersect's figures put the resulting delegator penalty at roughly 52.8% today and on a path to 100% by February 2028. A parameter that trends toward making an entire class of operator unviable is not a neutral default. The precedent also weighs in favour: the 2023 reduction from 340 ada produced none of the predicted race to the bottom, with larger pools largely holding at the prior level while smaller operators used the headroom. Lowering a floor grants flexibility; it does not compel any pool to charge less.
Two objections deserve to be recorded rather than waved away. The first is bundling. Combining an economic parameter with an unrelated execution-unit change forces DReps into a single package vote on questions that merit separate deliberation, and several DReps have objected to this on procedural grounds. Dracula DAO shares that objection. Governance quality depends on votes being answerable to one question at a time, and this action is worse for having been assembled the way it was. The second is that this is a symptomatic fix. As GAIA and TriangleForces have argued, the underlying cause is declining reserve emissions and the calibration of k and a0, and adjusting minPoolCost leaves that structure untouched. That criticism is correct. Dracula DAO also notes the Sybil concern — a lower floor reduces the cost of fragmenting stake across multiple pools — and regards it as real but modest at this magnitude, given that the 2023 precedent did not produce it.
Dracula DAO's philosophy is to take an ultra long-term view, and that view resolves this in favour. The viability of small independent stake pools is not a tactical concern; it is the substrate of Cardano's decentralisation, which is the property the entire security argument for this chain rests on. Allowing that base to erode on a known trajectory while awaiting a more complete redesign of the incentive structure would be the short-sighted choice, not the patient one. A stopgap that preserves optionality is preferable to a principled abstention that lets the problem compound for another two years. Dracula DAO supports this action while stating plainly that it is not a substitute for the structural work on k, a0, and the reward equation, and we expect that work to continue rather than be considered discharged by this vote.
Dracula DAO discloses that Vampyre Fund, the stake pool operator affiliated with this DREP, operates the VAMP pool and would benefit from a lower minPoolCost. We judge the change on its merits for the ecosystem and record the interest so delegators can weigh this rationale accordingly. This action falls in the Network group and therefore requires SPO ratification at 51%; as of the most recent tallies available, SPO support stood at 5.1% and DRep support at 37.7% against a 67% threshold, with the action expiring September 1. The VAMP pool has voted YES in the SPO track. Dracula DAO opposes the bundling of unrelated parameters and will say so again if the practice recurs, but will not withhold support for a beneficial change on procedural grounds alone.
- Yes15.5M ₳No rationale
- Yes13.2M ₳Rationale
RCADA votes YES on Reduce minPoolCost to 75 ada and increase Plutus Memory Limits (Part 2).
RCADA supports this parameter update because both changes are bounded, evidence-based, and aligned with the long-term health of the Cardano ecosystem.
RCADA supports the reduction of
minPoolCostfrom 170 ada to 75 ada. As block rewards continue to decline, the current fixed-fee floor creates a growing disadvantage for smaller pools, especially pools producing only one or a few blocks per epoch. This can make it harder for smaller independent SPOs to compete for delegation and can weaken the practical diversity of the stake pool ecosystem. The proposal notes that the delegator penalty for single-block pools has risen again since the 2023 reduction and may continue worsening if no further action is taken.RCADA has already indicated support for this direction during the earlier Intersect / Hydra voting stages relating to
minPoolCostreduction. This vote is consistent with that position. Lowering the floor to 75 ada does not force any operator to reduce fees, but it gives smaller pools more flexibility to compete and helps reduce a structural disadvantage in the delegation market.RCADA also supports the Plutus memory-limit increase. This action completes the second part of a previously recommended two-step increase, raising
maxTxExecutionUnits[memory]to 17,500,000 andmaxBlockExecutionUnits[memory]to 77,500,000, completing the cumulative 25% increase. The proposal states that this change was recommended by the Parameter Committee, ratified by the Technical Steering Committee, tested on Preview, and supported by performance analysis showing adequate timing headroom.RCADA recognises that the two changes are not directly related. Bundling unrelated parameter changes is not ideal because it can make voter choice less precise. However, in this case both changes are individually supportable, both have gone through relevant review processes, and the proposal is transparent about the bundling.
RCADA expects continued monitoring after enactment. For
minPoolCost, the ecosystem should watch for any unexpected effects on stake fragmentation, treasury inflows, and pool registration behaviour. For Plutus memory limits, the ecosystem should continue monitoring block performance, DApp usage, and whether the additional headroom improves developer experience without creating network stress.On balance, RCADA supports this action because it improves small-pool competitiveness, supports decentralisation, completes a staged and reviewed Plutus capacity increase, and reflects a measured approach to parameter governance.
RCADA’s full vote assessment can be found here:
https://brolloks.github.io/rcada-drep-votes/ - No10.9M ₳No rationale
- Yes10.9M ₳No rationale
- No10.4M ₳No rationale
- Yes9.5M ₳Rationale
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.
- No9.4M ₳No rationale
- Yes8.5M ₳Rationale
本提案に賛成します。minPoolCostの引き下げは、固定手数料を強制的に変更するものではなく、小規模ステークプールに対してより柔軟な手数料設定の選択肢を提供するものであり、委任者のRoS改善を通じて、小規模ステークプールの競争力向上が期待できます。また、Plutusメモリ上限の引き上げについても、段階的な導入に加え、テストネットでの検証および性能評価が実施されており、ネットワークの安全性と性能への配慮が十分に示されています。これらの変更は慎重かつ合理的なパラメータ調整であり、Cardanoエコシステムの継続的な改善につながると判断したため、本提案に賛成します。\n\nI vote Yes on this proposal. Reducing the minPoolCost does not force stake pool operators to lower their fixed fees. Instead, it provides smaller stake pools with greater flexibility in setting their fees, which is expected to improve delegator RoS and help smaller stake pools become more competitive. In addition, the proposed increase to the Plutus memory limits has been introduced in a phased manner and is supported by testnet validation and performance assessments, demonstrating appropriate consideration for network safety and performance. I believe these changes represent prudent and well-justified parameter updates that will contribute to the continued improvement of the Cardano ecosystem, and therefore I support this proposal.
- Yes7.5M ₳Rationale
Yes - and thanks to everyone who worked on this.
- Yes7.4M ₳No rationale
- Yes6.8M ₳No rationale
- Yes5.6M ₳Rationale
Trusting IOG's research team
- No5.5M ₳No rationale
- Yes5.1M ₳No rationale