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.
- Yes2.3M ₳No rationale
- Yes2.3M ₳No rationale
- Yes2.3M ₳No rationale
- Yes2.3M ₳No rationale
- Yes2.1M ₳No rationale
- Yes2.1M ₳No rationale
- Yes2.1M ₳No rationale
- Yes2.1M ₳Rationale
YES — This proposal delivers a measured, constitution-aligned increase to Plutus memory limits, improving developer flexibility and user experience without compromising network safety. The staged (Part 1 of 2) approach respects governance guardrails, allows real-world observation, and avoids reckless parameter jumps. Supporting this change helps Cardano scale practically today while preserving long-term decentralisation and robustness.
- Yes2.1M ₳No rationale
- Yes2M ₳No rationale
- Yes1.9M ₳No rationale
- Yes1.8M ₳Rationale
I am voting YES on this governance action because increasing transaction and block memory units is a practical, low-risk improvement that directly enhances Cardano’s smart contract capacity and developer experience. This change supports more expressive and efficient Plutus applications, reduces current technical constraints faced by builders, and helps the ecosystem scale in line with growing usage. The proposal is grounded in benchmarking and careful parameter adjustment, making it a sensible incremental upgrade rather than a disruptive shift. Approving this step signals that governance can respond constructively to technical needs and supports Cardano’s competitiveness by enabling faster progress for applications already being built today.
- Yes1.7M ₳No rationale
- Yes1.7M ₳No rationale
- Yes1.6M ₳No rationale
- Yes1.6M ₳No rationale
- Yes1.6M ₳No rationale
- Yes1.5M ₳No rationale
- Yes1.4M ₳No rationale
- Yes1.4M ₳No rationale
- Yes1.4M ₳Rationale
I support this first-stage increase to
maxTxExecutionUnits[memory](14M → 16.5M) andmaxBlockExecutionUnits[memory](62M → 72M).This is a disciplined, guardrail-compliant adjustment that reduces developer friction while preserving network safety. The increases sit exactly at the per-epoch limits allowed under MTEU-M-04 and MBEU-M-03, reflecting incremental rather than aggressive tuning. The change has been benchmarked, ratified through the appropriate committees, deployed on testnets, and satisfies the procedural requirements for critical parameter updates.
This is measured parameter stewardship: evidence-based, staged, and ecosystem-aligned.
I will vote YES.
- Yes1.4M ₳No rationale
- Yes1.3M ₳No rationale
- Yes1.3M ₳No rationale
- Yes1.2M ₳Rationale
I'm voting YES, lets reduce propagation delays, use more plutus v2, I normally don't like to increase block size, but if slot duration is not increased too much we stay within safety limits. let's change and monitor.
- Yes1.1M ₳Rationale
Infrastructure is only as valuable as the utility it can reliably support. Personally, I view the Cardano network not merely as a cryptographic experiment, but as a business-critical platform where stability and scalability are paramount.
**While the proposal pushes strictly to the edge of what is permissible, I believe it remains technically compliant (please do correct me, if I'm wrong). The question I'm not sure about at this point is whether the increase is necessary "greasing of the gears" or reckless acceleration. The motivation cited — alleviating developer pain points and enhancing scalability — is a compelling business argument. If we stifle the capacity of our smart contracts, we stifle the innovation required to make Cardano commercially viable. **However, putting on my strategist helmet, I am slightly wary of changes that max out parameters without a commensurate, visible improvement in utility. The proposal leans heavily on benchmarking results, asserting that block propagation times will remain safe. What worries me, is that we are trusting that these simulations accurately reflect the chaotic reality of the mainnet. Ultimately though, I think this is a low-risk, high-reward lever to pull. Most importantly: It requires no treasury withdrawal, thereby protecting our financial resources, yet can (theoretically and hopefully) unlock greater throughput for DApps. By allowing more memory consumption per transaction and per block, we are essentially widening the lanes of our digital highway, which is a requisite step if we intend to scale. While I generally view "maximum allowed" requests with skepticism… I think we can and should push this lever to 11.
- Yes1M ₳No rationale
- Yes971.5K ₳Rationale
We vote YES on this protocol parameter update.
Increasing the Plutus memory unit limits per transaction and per block is a measured and technically justified step to improve Cardano’s smart contract capacity. The proposed adjustments remain within all constitutional guardrails, have undergone benchmarking and testnet validation, and preserve Praos timing and propagation guarantees.
From a governance perspective, this change addresses a well-documented developer pain point. By modestly increasing execution memory limits, DApp builders gain greater flexibility without requiring structural protocol changes or introducing new systemic risk. This supports sustainable ecosystem growth while maintaining decentralization and network stability.
We also acknowledge that this is the first part of a controlled, two-step adjustment, respecting guardrail limits on parameter increases per epoch. The phased approach reflects responsible parameter governance rather than aggressive scaling.
Given the available performance headroom and the demonstrated technical review by the Parameter Committee and Technical Steering Committee, we consider this a low-risk, high-impact improvement that strengthens Cardano’s application layer and long-term competitiveness.
For these reasons, we support this proposal.
- Yes964.1K ₳No rationale
- Yes931.8K ₳No rationale
- Yes929.9K ₳No rationale
- Yes891.3K ₳No rationale
- Yes861.5K ₳No rationale
- Yes825.2K ₳Rationale
Proposed parameter changes have a clear advantage for Dapp devs while now representing any risks for the protocol. We suggest waiting more than the mimimum epochs required by the guardrails before submiting the second proposal to insure adecuate obesrvation prior to aditional changes.
- Yes820.1K ₳No rationale
- Yes798.6K ₳No rationale
- Yes798.4K ₳No rationale
- Yes794.5K ₳Rationale
I trust the recommendations of the Parameter and Technical Steering committees with respect to benefits of proposed parameter changes and assessment of any potential drawbacks.
- Yes763.4K ₳No rationale
- Yes759K ₳No rationale
- Yes717.5K ₳No rationale
- Yes705.1K ₳Rationale
I am voting yes for this proposal because it helps our DApp builders from having to manually optimize due to insufficient Plutus script memory unit limits per transaction. This allows teams to focus on innovation rather than workarounds. This would also allow for more sophisticated smart contract logic, the kind that cannot exist with our 14 million memory unit ceiling. This will unlock new capabilities and use cases for our ecosystem! By allowing more plutus scripts to execute per block, we are greatly enhancing our scalability! This upgrade has been tested as being safe, as it has run on testnet and has passed all the proper safety checks. Let's get it passed!
- Yes625.9K ₳Rationale
I'm voting yes on this parameter update because it delivers meaningful, zero-cost utility improvements to Cardano's developer ecosystem with rigorous technical validation backing every number. Increasing maxTxExecutionUnits[memory] by ~17.9% and maxBlockExecutionUnits[memory] by ~16.1% isn't speculative optimization, it's measured, benchmarked headroom that already exists in the network, now being unlocked for DApp developers who've been working around artificial constraints.
The practical impact is straightforward: Plutus scripts can do more meaningful work within a single transaction, eliminating the forced complexity of splitting logic across multiple transactions to stay within memory limits. This reduces developer friction, simplifies smart contract architecture, and opens the door to more sophisticated DeFi, governance, and utility applications, all without touching fees, tokenomics, or security parameters.
The technical validation process here is exactly what responsible governance looks like. IOE's Performance and Tracing team benchmarked node versions 10.2 and 10.3, confirming that critical timing metrics, like Kernel RSS, CPU usage, and block diffusion, all remain stable and well within the 95% propagation target within 5 seconds. Equivalent changes were successfully deployed and tested on Preview testnet and PreProd testnet before this mainnet submission. Intersect's Parameter Committee recommended this change, ratified by the Technical Steering Committee, and with the off-chain proposal published July 2025 satisfying the mandatory three-month notice period required by PARAM-04a. Every Constitutional guardrail is met.
This is part one of a staged two-step increase totaling 25%, structured this way specifically because guardrail MTEU-M-04 limits increases to 2,500,000 units per epoch. That constraint is being respected, not circumvented. The staged approach is the right governance posture, and it doesn't pre-commit the ecosystem to the second increase, which must be independently evaluated and ratified.
I'll be honest about the limits of my own analysis here. The benefits are well-documented and the technical case is compelling. I've reviewed Parameter Committee meeting records, forum discussions, and available benchmarking data, and found no indications of critical drawbacks. There is a non-negligible developer/SPO minority expressing concern about the change that I want to recognize. The primary acknowledged risk, of irreversibility, is real. Once DApp developers build against higher memory limits, lowering them would break dependent smart contracts. But current limits are demonstrably conservative relative to actual network capacity, and the benchmarks prove it. Accepting measured, validated expansion of proven headroom is smart growth, not recklessness.
Intersect's Parameter Committee earned credit here for over a year of analysis, transparent process, and methodical compliance with every guardrail. This is how technical governance should work. - Yes605.7K ₳Rationale
📌 Voting is live to increase Plutus memory limits in Cardano — and I'm voting YES as a DRep
🧠 What it’s about:
The proposal increases memory unit limits for Plutus scripts:maxTxExecutionUnits[memory]: 14M → 16.5MmaxBlockExecutionUnits[memory]: 62M → 72M
This gives developers more flexibility to build scalable and powerful smart contracts, while maintaining block performance.
🔧 Why I’m voting YES:
✅ Enables more advanced DApps with fewer limitations
✅ Already tested on Preview & PreProd testnets
✅ No security or performance risks confirmed by benchmarks
✅ Supported by Intersect’s Parameter and Technical Committees
✅ Fully compliant with all governance guardrails
📊 This is how Cardano scales smartly — with real governance, real testing, and community control.
More complex logic, smoother UX, better developer experience.🖤 My DRep ID:
➡️ drep1y269ehxj30k4vfzfc2z84v0xykd3amuy2xn0kv9zf8rhcec2fg2jr
Details: https://t.me/PROCENT666/338
🚀 COURSE: “LEDGER COLD WALLET” | METAMASK
https://edgarbagdasarian.justclick.ru/order/LEDGERMETAMASK
🔥 VIP PRIVATE CHAT (PAID ACCESS)
https://t.me/MREDGARCROSS_BOT
🌐 ALL COURSES & LINKS
https://mredgarcross.com/#Cardano #DRep #Plutus #Governance #ADA #DeFi #SmartContracts #ProtocolUpgrade #мыслЯотэдгара #dRepVotesYES
- Yes598.3K ₳No rationale
- Yes589.7K ₳No rationale
- Yes587.6K ₳Rationale
Rationale ID: RID24920185fi39ik2039fdhe4t2wdvs
Generated At: 2026-02-05T03:55:00+03:30
Generated By: govcircle.spaceAction Information
Action Title: Increase Transaction and Block Memory Units (Part 1 of 2)
Action ID: gov_action1cgdsp7g0rr7wgqp7maptpvx525fxuqwfgm5qe3f5r20ew5x2772s2z23ttFollow DRep's Rationale: YUTA
Vote: YES
Executive Summary
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.Audit
Digest: 84ad0c7a781bdad8761ada4cf0fe175920247cf0292b6e995380bf8d6263ff40
Digest Algorithm: SHA-256 - Yes559.2K ₳No rationale
- Yes545.4K ₳No rationale
- Yes535.2K ₳Rationale
lgtm