Increase Transaction and Block Memory Units (Part 1 of 2)
227 DReps voted · 74 with a rationale · 5 changed their vote
Open a row to read the rationale.
- Yes584.2M ₳Rationale
Summary
Yoroi DRep votes YES on the proposal to increase Plutus memory unit limits for transactions and blocks. The adjustment improves smart contract flexibility and user experience without introducing material risk to network stability.
Rationale
• Developer constraint relief with low risk
Increasing memory limits allows Plutus scripts to perform more meaningful work within a single transaction, reducing forced transaction splitting and improving developer and user experience without reflecting capacity pressure on the network.• Well tested and performance safe
Benchmarking by IOE’s Performance and Tracing team, along with validation on Preview and PreProd testnets, confirms that the proposed increases preserve Praos timing guarantees and maintain sufficient performance headroom.• Governance compliant and incrementally staged
The proposal is recommended by Intersect’s Parameter Committee, ratified by the Technical Steering Committee, and fully aligned with Constitutional guardrails. As the first step of a staged approach, it does not pre-commit the ecosystem to future increases, which must be evaluated independently.Conclusion
Yoroi supports this proposal as a safe, well tested parameter update that improves usability while maintaining Cardano’s reliability and operational stability. - Yes435.8M ₳Rationale
I will vote YES on “Increase Transaction and Block Memory Units (Part 1 of 2)”.
The potential benefits of this proposal are already well described in the metadata and accompanying documentation. With regard to potential downsides, I have made efforts to understand the risks by reviewing forum discussions, Intersect committee meeting minutes, and available analyses. Based on this review, I have not identified any indications of critical or fatal drawbacks at this time.
That said, surveys indicate that there is a non-negligible number of developers who believe that this change should not be implemented. For this reason, I intend to continue gathering information and monitoring further analysis related to possible downsides. I will also continue to pay close attention to the arguments and perspectives of those who believe a NO vote would be more appropriate.「Increase Transaction and Block Memory Units (Part 1 of 2)」にYESを投票します。
この提案書のメリットはメタデータ等に記載される通りです。デメリットについて、フォーラムの議論やINTERSECTの委員会の議事録、分析結果等を通して把握しようと努めましたが、致命的なデメリットに関する兆候は把握されませんでした。
しかし世論調査によると変更すべきではないと考えている開発者も一定数確認できるため、ダウンサイドに関する分析について引き続き情報収集をしたいと考えています。NOを投票すべきと考える方々の意見を引き続き注視します。
- Yes332.2M ₳No rationale
- Yes293M ₳Rationale
Summary
EMURGO as a DRep votes YES on the governance action titled “Increase Transaction and Block Memory Units (Part 1 of 2)”, based on the rationale outlined below.
Rationale
This proposal removes a practical bottleneck for Plutus development by relaxing per-transaction constraints, allowing more meaningful work to be executed in a single transaction without being driven by network congestion considerations. The change reduces unnecessary script fragmentation and improves developer and user experience without modifying the cost model or introducing new protocol complexity.
From a governance perspective, the update is responsibly designed and well substantiated. It remains within Constitutional guardrails, has undergone extensive technical review, and has been validated on multiple testnets.
The proposal also reflects a disciplined Conway era governance process, with clear staging and correlation of parameters. For these reasons, EMURGO votes yes.
- Yes222.9M ₳Rationale
TL;DR: EDC voted YES on gov_action1cgdsp7g0rr7wgqp7maptpvx525fxuqwfgm5qe3f5r20ew5x2772sq0m5y83;
The metadata goes into full detail, two committees signed off on this proposal and monitoring will be in place. Easy decision.
- Yes174.6M ₳No rationale
- Yes165.7M ₳No rationale
- Yes120.2M ₳Rationale
Cardano Foundation votes YES on this governance action. We support this parameter change to improve developer flexibility and network scalability. Benchmarks confirm that the network has sufficient headroom to accommodate these increases without compromising block propagation or security guarantees.
A PDF version of this rationale is also made available.
Our support for this proposal is driven by the following factors:
Developer Experience & Scalability: Increasing the per-transaction memory limit by ~17.9% and the per-block limit by ~16.1% addresses immediate pain points for developers. It allows for more complex Plutus scripts to run without requiring inefficient workarounds, while maintaining the capacity to fit four maximum-sized transactions per block.
Technical Validation: We rely on the data provided by the IOE Performance and Tracing team. Detailed benchmarking (on node versions 10.2 and 10.3) indicates that despite the increased memory budget, critical system resources (Kernel RSS, CPU usage) remain stable, and block diffusion remains well within the target of 95% propagation within 5 seconds.
Process & Guardrail Compliance: This proposal is the result of over a year of analysis by the Intersect Parameter Committee. We specifically point to the "Part 1 of 2" implementation strategy in this instance because it is required by the Constitutional Guardrails (specifically MTEU-M-04), which limit the maximum increase per epoch. In general, we advocate for bundling parameter changes to minimize the frequency of governance actions requiring Stake Pool Operator (SPO) votes, thereby reducing their operational burden.
The Cardano Foundation votes YES. This update represents a technically sound, data-backed optimization of the network's parameters. It unlocks necessary capacity for the ecosystem while adhering to established safety guardrails.
- Yes92.2M ₳No rationale
- Yes91.5M ₳Rationale
As a DRep, I decided to vote YES for the proposal: Increase Transaction and Block Memory Units (Part 1 of 2)
Increasing the Plutus script memory unit limits for both transactions and blocks can, in some cases, facilitate dApp development and have a positive impact on the user experience.
The proposed changes do not have a dramatic impact on performance, which has been tested.
The change is recommended by the Parameter Committee and ratified by Intersect's Technical Steering Committee. I trust that they can devote enough time and have the expertise to best assess all the technical aspects of the change.
The parameters were set conservatively at the beginning. It is reasonable to push the limits. Especially if the builders request it.
In case of problems, the changes can be reverted. As stated in the proposal, it will probably not be necessary. I agree.
- Yes88.6M ₳No rationale
- Yes86M ₳Rationale
Vote: YES (Conditional Approval)
DRep: SIPOAs SIPO DRep, we vote YES on this governance action (Increase Transaction and Block Memory Units – Part 1 of 2).
This proposal represents a well-scoped, carefully validated protocol parameter adjustment that meaningfully improves the developer experience and scalability of Plutus-based applications, while preserving Cardano’s core guarantees around security, decentralization, and network stability.
Why we support this proposal
First, this change is technically conservative and evidence-based.
The proposed increases to maxTxExecutionUnits[memory] and maxBlockExecutionUnits[memory] remain fully within the Constitutional guardrails and represent the maximum safe increment allowed per epoch. The change is backed by extensive benchmarking, has been reviewed and recommended by the Intersect Technical Steering Committee, and has already been validated on Preview and PreProd testnets. From a DRep perspective, this is exactly the kind of change that should move forward.Second, the impact is practical and immediately useful.
Memory limits have been one of the most common friction points for Plutus developers, often forcing unnecessary transaction splitting, over-optimization, or degraded user experience. This adjustment allows more meaningful work to be done per transaction and per block without changing the cost model or introducing new complexity. Importantly, existing applications can benefit without redesign, while SPOs and network operators are not burdened with additional operational risk.Third, this proposal demonstrates healthy Conway-era governance in action.
The process followed here—long-running public discussion (PCP-003), off-chain notice in line with PARAM-04a, testnet validation, and a clearly scoped on-chain action—sets a strong precedent for how critical protocol parameters should evolve. Supporting this proposal is also a vote of confidence in that process.Conditional support and forward-looking view
Our support is explicitly limited to Part 1 of the proposed two-step increase.
While we agree that additional headroom may be possible in the future, any subsequent increase (Part 2) should be evaluated independently, based on real mainnet data after this change is enacted. Approval of this proposal should not be interpreted as automatic approval of future increases.
This is not about competing in headline TPS metrics or aggressively pushing L1 limits. From SIPO’s perspective, this change is best understood as removing unnecessary friction and enabling sustainable, high-quality scaling—consistent with Cardano’s long-term design philosophy.
Closing
In summary, SIPO supports this governance action because it is:
• Technically justified and well-benchmarked
• Governance-compliant and carefully staged
• Directly beneficial to developers and users
• Low-risk for network operation and decentralizationFor these reasons, we cast a YES vote, with the clear expectation that future steps will be assessed with the same level of rigor and transparency.
投票：YES（条件付き賛成）
DRep：SIPOSIPO DRepとして、本ガバナンスアクション
「Increase Transaction and Block Memory Units（Part 1 of 2）」に 賛成（YES） します。本提案は、Cardanoの安全性・分散性・ネットワーク安定性という中核的な前提を一切損なうことなく、PlutusベースのDApp開発とスケーラビリティを現実的に改善する、適切にスコープされたプロトコル・パラメータ変更だと評価しています。
賛成する理由
第一に、技術的にきわめて慎重かつ検証済みである点です。
今回の maxTxExecutionUnits[memory] および maxBlockExecutionUnits[memory] の引き上げは、憲章のガードレールに完全に準拠し、1エポックあたりで許容される最大増分の範囲内に収まっています。
詳細なベンチマークに基づき、Intersect Technical Steering Committee による承認も得られており、さらに Preview / PreProd テストネットでの実証も完了しています。DRepとして、こうした変更こそ前に進めるべきだと考えます。第二に、開発者・ユーザーにとって実務的な効果が明確である点です。
Plutusのメモリ制約は、これまで多くの開発者にとって慢性的な摩擦となっており、不自然なトランザクション分割や過剰な最適化、UXの低下を招いてきました。
本変更により、1トランザクション・1ブロックあたりで実行できる意味のある処理量が増え、設計の自由度が向上します。コストモデルの変更や新たな複雑性を伴わず、既存DAppも恩恵を受けられる点は大きな利点です。また、SPOやネットワーク運用者への新たな負担が発生しない点も重要です。第三に、Conway期ガバナンスが健全に機能していることを示す好例である点です。
長期にわたる公開議論（PCP-003）、事前のオフチェーン告知、テストネット検証、そして明確に切り分けられたオンチェーン提案という流れは、Cardanoが目指してきたガバナンスの姿そのものです。本提案に賛成することは、そのプロセスを肯定する意思表示でもあります。条件付き賛成としての立場
SIPOの賛成は、本提案（Part 1）に限定したものです。
本提案は2段階構成であり、後続の増加（Part 2）については、今回の変更がメインネットで実際にどのような影響を与えるかを確認したうえで、改めて独立に評価されるべきだと考えます。
今回の賛成が、将来の追加増加を自動的に承認するものではありません。また、この変更はTPS競争やL1の肥大化を目的としたものではなく、あくまで 不要な摩擦を取り除き、持続的で質の高いスケーリングを可能にするための調整 だと位置づけています。
まとめ
SIPO DRepとして、本提案は以下の点で妥当だと判断しました。
• 技術的根拠と十分な検証があること
• ガバナンスおよび憲章ガードレールに完全に整合していること
• 開発者・ユーザーにとって実利が明確であること
• ネットワーク運用や分散性に対するリスクが低いこと以上の理由から、SIPOは本ガバナンスアクションに YES（条件付き賛成） を投じます。
今後のステップについても、同じ水準の慎重さと透明性で評価されることを期待しています。 - Yes84.3M ₳Rationale
In this vote, I am relying on the expertise and unanimous vote of the Technical Steering Committee as evidenced in the minutes linked in the proposal. (See https://committees.docs.intersectmbo.org/intersect-technical-steering-committee/meeting-minutes/2025-tsc-meeting-minutes/meeting-minutes-october-01-2025).
- Yes77.7M ₳No rationale
- NoChanged76.8M ₳Rationale
This proposal should have passed two years ago. As it stands now the increase is far too conservative, and meaningless, instead we should focus on reducing the ex-unit (mem and CPU) cost of CEK operations to account for the massive amount of optimization work that has been done over the years.
A PDF version of this rationale is also made available.
This proposal should have passed two years ago. As it stands now the increase is far too conservative, and meaningless, instead we should focus on reducing the ex-unit (mem and CPU) cost of CEK operations to account for the massive amount of optimization work that has been done over the years. The memory cost of the term AST node is 100 which is a hundred times higher than it should be (it should be 1).
Instead of increasing the budget, we should reduce ex-memory costs of cek ops to accurately reflect the memory that the ops consume.
Earlier votes
Yes5mo agoSuperseded
The proposed increase in memory units is too small and too conservative. It should have been implemented two years ago. As it stands now, we need to fundamentally re-evaluate the ex-memory and ex-cpu costing of builtins to account for the years of optimizations.
A PDF version of this rationale is also made available.
The proposed increase in memory units is too small and too conservative. It should have been implemented two years ago. As it stands now, we need to fundamentally re-evaluate the ex-memory and ex-cpu costing of builtins to account for the years of optimizations which have significantly improved the CEK machine to an extent far beyond the increase in this proposal. Mem cost is pretty much completely arbitrary magic, as demonstrated by the fact a simple term AST node has a memory cost of 100 which is a hundred times higher than what the cost should be (it should be 1).
- Yes75.2M ₳No rationale
- Yes74.5M ₳Rationale
I vote YES on this parameter update.
This proposal increases Plutus memory limits in a measured and well-tested way, with a clear safety margin. The change has been benchmarked, validated on testnets, and reviewed by the relevant technical bodies, indicating that performance and security guarantees are maintained.
I especially support the decision to implement this as a first step in a staged increase. Raising the limits gradually allows the ecosystem to benefit from improved developer flexibility while preserving the ability to observe real-world effects before further adjustments.
Overall, this is a low-risk, high-impact improvement that meaningfully reduces friction for DApp developers without compromising network stability.
本パラメータ更新にはYESを投票します。
本提案は、十分な検証とベンチマークに基づき、安全マージンを確保した上でPlutusのメモリ上限を引き上げるものです。テストネットでの実証や技術委員会によるレビューを経ており、パフォーマンスやセキュリティ保証が維持されることが確認されています。
特に、今回の変更を段階的な引き上げの第一段階としている点を評価しています。一度に大きく変更するのではなく、実運用での影響を観測しながら進めることで、開発者体験の改善とネットワークの安定性を両立できます。
全体として、本提案はリスクが低く、DApp開発の摩擦を減らす効果が高い、妥当な改善だと考えます。
- Yes73.1M ₳Rationale
I vote YES. This is a zero-cost upgrade to utility. Increasing Plutus memory limits allows further DApp functionality and improves developer experience. Verified deployments on Preview/PreProd and IOE benchmarking confirm this fits within safe propagation limits.
A PDF version of this rationale is also made available.
I am voting YES on this Protocol Parameter update. This proposal represents a pragmatic, zero-cost upgrade to the network's utility that enhances the developer experience and potential DApp throughput.
I explicitly credit Intersect's Parameter Committee for their diligence in pushing this forward. From a strategic perspective, increasing
maxTxExecutionUnits(+17.9%) andmaxBlockExecutionUnits(+16.1%) leverages existing headroom to improve performance. The proposal demonstrates responsible governance through verified deployments on Preview and PreProd testnets and benchmarking by IOE's Performance & Tracing team, confirming that propagation times remain safe. This is exactly the kind of "smart growth" I support. - Yes69.4M ₳No rationale
- Yes66M ₳Rationale
Makes sense
- Yes62.7M ₳No rationale
- Yes53.8M ₳No rationale
- Yes50.5M ₳No rationale
- Yes50.4M ₳No rationale
- Yes50M ₳Rationale
As a DRep and an SPO, I believe these protocol parameter changes will be beneficial for the network. They are an important step toward improving stability and long-term sustainability, so I'm voting Yes.
- Yes49.5M ₳No rationale
- Yes48.6M ₳No rationale
- Yes47.6M ₳No rationale
- Yes42.9M ₳No rationale
- Yes40.1M ₳Rationale
This proposal delivers a low-risk, well-benchmarked increase to Plutus memory limits that eases DApp development and improves on-chain throughput without changing cost models, security, or consensus guarantees. It stays fully within constitutional guardrails, has been validated on testnets, and represents a prudent, incremental step toward better scalability for Cardano.
- Yes38.1M ₳Rationale
low-risk technical improvement, well tested … why not?
- Yes37.8M ₳No rationale
- Yes34.6M ₳No rationale
- Yes34.3M ₳Rationale
Socious votes YES on the proposal to increase Plutus Script Memory Units. We support this update as a low-risk, high-impact measure that significantly improves the developer experience by allowing for more complex script logic without requiring manual optimization. Extensive benchmarking by the IOE Performance and Tracing team confirms that this increase fits comfortably within the network's capacity, ensuring that critical Praos timing guarantees and block propagation standards are maintained. Furthermore, we recognize this governance action as the necessary first step of a two-part strategy to sustainably enhance Cardano's scalability and block utilization while adhering to constitutional guardrails.
Sociousは、Plutusスクリプトのメモリユニット増量（パート1）の提案に賛成（YES）を投じます。この変更は、開発者が手動で最適化を行う負担を減らし、より複雑なロジックの実装を可能にすることで開発者体験を大幅に向上させる、低リスクかつ効果の高い施策です。IOEパフォーマンスチームによる広範なベンチマーク調査により、この増量はネットワークの許容範囲内に収まっており、重要なPraosのタイミング保証やブロック伝播の基準が維持されることが確認されています。さらに、私たちはこのガバナンスアクションを、憲法上のガードレール（安全策）を遵守しつつ、Cardanoのスケーラビリティとブロック利用効率を持続的に高めるための2段階戦略の不可欠な第一歩として認識しています。
- Yes33.5M ₳Rationale
- Yes31.4M ₳Rationale
I am voting Yes for the following reasons:
• Developer feedback collected through PCP‑003 indicates clear support for increasing Plutus memory limits.
• The change reduces unnecessary complexity in dApp development and improves the overall developer experience.
• Benchmarking and technical evaluations show that the associated risks to network performance are minimal. - Yes31.1M ₳No rationale
- Yes30.7M ₳No rationale
- Yes27.9M ₳Rationale
This parameter change has been in the works for over two years since it was originally proposed in December of 2023. Given the clear benefits and the minimal-to-no tradeoffs, I see no reason to vote against this proposal as it seems to be an obvious benefit to the Cardano community.
- Yes27.9M ₳No rationale
- Yes27.5M ₳No rationale
- NoChanged26.3M ₳Rationale
I will vote against this proposal because insufficient testing has been conducted on the proposed parameter changes, and the process appears rushed.
Modifications of this magnitude should be thoroughly tested — ideally validated multiple times by independent groups of developers or experts.
The Intersect team should clearly present and document the testing that has been performed before proceeding.This is the best practice I would like to see being implemented by Intersect.
Earlier votes
Yes5mo agoSuperseded
- Yes26.1M ₳Rationale
◇ Voted YES on increasing Plutus transaction and block memory limits because it reduces friction for teams building real products on Cardano and improves the commercial viability of the ecosystem. To be clear this is a very well vetted proposal reviewed by the technical steering committee and it has fail safes in place to insure that it can be rolled back
◇ Builder productivity and cost efficiency
◇ Higher memory headroom lowers the engineering tax of squeezing contracts into conservative limits, reducing refactor cycles, audit churn, and time to ship.◇ Improved user experience and conversion
◇ More capacity enables richer transaction flows and fewer split transactions, which typically means fewer failures, less user drop off, and lower support burden for dApps and wallets.◇ Scalability headroom for growth
◇ Increasing these limits raises the ceiling for Plutus throughput as activity increases, helping builders scale without immediately hitting protocol constraints that force product compromises.◇ Ecosystem competitiveness and partner readiness
◇ Smoother execution budgets make it easier for teams to commit to performance expectations with liquidity partners, integrators, and enterprise pilots, strengthening Cardano’s ability to attract and retain serious builders.◇ Risk managed and reversible
◇ The change is staged and can be reverted via governance if network health metrics regress, making this a controlled upgrade rather than a permanent bet - Yes25.3M ₳Rationale
I am voting YES to Increase Transaction and Block Memory Units (Part 1 of 2). Y'all know the drill.
- Yes23.5M ₳No rationale
- Yes22M ₳Rationale
I am voting YES to this parameter update. This proposal is a well-researched, data-driven, and necessary step to enhance the capabilities of the Cardano network.
Increasing the Plutus script memory limits directly addresses a significant pain point for dApp developers, enabling them to build more sophisticated applications and improve the scalability of existing ones. This is not a speculative change but a direct response to clear feedback from the builder community.
Crucially, the proposal is backed by comprehensive benchmarking from IOG's performance team and has been successfully tested on public testnets. This evidence provides strong assurance that the change can be implemented safely without compromising the network's stability or the security guarantees of the Praos consensus protocol.
The meticulous adherence to constitutional guardrails and the cautious, two-part approach further demonstrate the professionalism and diligence of the Parameter Committee. This is exactly the kind of incremental, evidence-based improvement that will ensure Cardano's long-term, sustainable growth. - Yes21.5M ₳No rationale
- Yes21.5M ₳Rationale
I vote YES on the proposed protocol parameter update proposal to “Increase Transaction and Block Memory Units”. This is the first proposal of a two-step process to increase the parameter value as the desired value is currently a larger increase than the current Guardrail script will allow in one step.
This is a well written proposal and uses the correct parameter names as found both within the Constitution text and output from the on-chain query
cardano-cli query protocol-parameters –mainnet. I raise this point as I have previously stated that I would vote NO to any parameter change proposal that does not adhere to the correct naming scheme as found in these two searches. The proposal also provides sufficient evidence of the historical discussions regarding the parameter change including, Cardano Forum posts of the Parameter Change Proposal PCP-003, public survey results, benchmarking results and outputs from both the Parameter Committee and Technical Sterring Committee. There has also been a progressive and phased rollout of the proposed update across both Preview and Prerpod testnets.The proposal also contains a reversion plan, as mandated by the Constitution, and so I am comfortable voting YES knowing that if any unforeseen circumstances arise as a result of this change that it should not create too much of an issue with regards to reverting to the current values.
There has also been a progressive and phased rollout of the proposed update across both Preview and Prerpod testnets.
- Yes21.4M ₳Rationale
As a DRep, I vote YES on this Protocol Parameter Change.
This proposal introduces a conservative, well-benchmarked increase to Plutus memory limits that directly reduces friction for dApp developers while maintaining Cardano’s security and performance guarantees. The change has been validated on testnets, and is recommended by both the Parameter Committee and the Technical Steering Committee.
- No21.1M ₳No rationale