Increase Transaction and Block Memory Units (Part 1 of 2)
227 DReps voted · 76 with a rationale · 2 changed their vote · 3 re-voted unchanged
Open a row to read the rationale.
Changed votes: 2 to no, together voting with 162.3M ₳ of voting power.
- Yes20.3M ₳No rationale
- Yes18.3M ₳No rationale
- Yes17.2M ₳No rationale
- Yes16.3M ₳No rationale
- Yes15.3M ₳Rationale
Increase Transaction and Block Memory Units (Part 1 of 2)
- Yes14.2M ₳No rationale
- Yes12.1M ₳No rationale
- Yes12M ₳Rationale
本提案は、Plutusスクリプトのメモリユニット上限をガードレールで許容される範囲内で引き上げるものであり、十分な技術的検証、テストネットでの実証、ならびに性能およびセキュリティ評価を経ていることから、リスクは限定的であると判断します。DApp開発時の制約を緩和し、Cardanoエコシステムの持続的なスケーラビリティ向上に資する合理的な改善であるため、賛成します。\n\nI vote Yes, as this proposal increases Plutus memory unit limits within guardrail boundaries, is supported by thorough technical review and testnet validation, and presents limited risk while meaningfully improving DApp development flexibility and the long-term scalability of the Cardano ecosystem.
- Abstain11.9M ₳Rationale
Our preparation towards Cardano Africa Tech Summit 2026 which is scheduled for February 11th to 13th has been an all-hands-on-deck situation since the start of intensive preparations and as a committee who's been engaged heavily in organising a governance workshop at the summit, we have not had the space to carefully review this governance action.
That said, we trust that our colleague DReps would review and make accurate judgement on this governance action through their vote, hence to not be a blocker in any way, we are abstaining and we hope our delegators do bear with us in good faith.
See you in Nairobi!
- Yes11M ₳No rationale
- Yes10.9M ₳No rationale
- Yes10.3M ₳No rationale
- Yes9.5M ₳Rationale
Per the polls and community feedback out there seems to be enough support for this where the benefit outweighs any real risk to overall performance.
- Yes8.9M ₳Rationale
RCADA votes YES on Part 1 of this protocol parameter update.
This proposal reflects disciplined governance design: it is incremental, benchmark-supported, testnet-validated, and compliant with the Cardano Blockchain Ecosystem Constitution v2.4 and its Guardrails.
The increase to Plutus memory limits improves developer flexibility without modifying cost model parameters, monetary policy, or treasury funds. It remains within defined per-epoch adjustment bounds and preserves structural block composition.
I support measured scaling where evidence demonstrates sufficient performance headroom. At the same time, I recognize that parameter increases create forward path dependency once developers build against higher ceilings.
For that reason, this vote applies strictly to Part 1. It does not constitute pre-approval of Part 2. Any subsequent increase must be evaluated independently following observable mainnet performance data, including propagation metrics and real-world usage patterns.
Incremental scaling must remain evidence-driven and constitutionally grounded.
RCADA's full vote assessment can be found here:
"https://brolloks.github.io/rcada-drep-votes/" - Yes8.1M ₳No rationale
- Yes7.6M ₳Rationale
No specific security concerns are raised by this change. Performance results indicate that Praos timing guarantees will be maintained following this change.
This seems to be a relatively straightforward parameter change that has been carefully examined.
- Yes7.3M ₳No rationale
- Yes6.7M ₳No rationale
- Yes6.3M ₳No rationale
- Yes5.7M ₳No rationale
- Yes5.7M ₳No rationale
- Yes5.5M ₳Rationale
Given that two Intersect committees agree that this parameter change will benefit the Cardano ecosystem, particularly DApp development and since it has been thoroughly tested, I trust and support their decision to increase the memory limit.
- Yes5.5M ₳Rationale
Necessay addition.
- Yes5.3M ₳Rationale
STORM Partners votes YES on “Increase Transaction and Block Memory Units (Part 1 of 2)”.
This proposal is a conservative, guardrail-compliant increase to Plutus memory limits per transaction and per block, designed to reduce current bottlenecks for smart contract developers and improve real dApp usability without changing the cost model or requesting treasury funds. It aligns with our DRep objectives to enhance ecosystem efficiency and drive scalable adoption, by removing avoidable execution constraints that force inefficient workarounds and limit what can be done per block. The change follows a staged approach, with testnet deployment and benchmarking referenced, and it preserves network safety constraints while enabling more useful work to fit into a block. We support Part 1 as a measured scaling step. This YES vote does not pre-approve Part 2, which should be assessed after observing mainnet outcomes.
As a minor process note, we support making key technical references for governance actions more durable over time. Links and external websites can change or disappear, so preserving critical benchmarking and rationale artifacts in more immutable formats strengthens long-term auditability and credibility.
- Yes5.2M ₳No rationale
- Yes5.1M ₳No rationale
- Yes5.1M ₳Rationale
For transparency, I had to speak to some speak to community members to wrap my head around this technical proposal. Voting yes, as it stays within the constitutional guardrails, it's been validated on the testnet, low risk overall, and it gets us closer to stronger scalability for Cardano.
- Yes4.9M ₳No rationale
- Yes4.8M ₳No rationale
- Yes4.6M ₳No rationale
- Yes4.5M ₳No rationale
- Yes4.2M ₳Rationale
[Portuguese]
Optamos por votar "SIM" nesta ação de governança “Increase Transaction and Block Memory Units (Part 1 of 2)” (gov_action1cgd...0m5y83), pois a proposta visa aumentar os limites de unidades de memória dos scripts Plutus, tanto por transação quanto por bloco. Essa mudança amplia a escalabilidade e a capacidade funcional dos dApps na rede Cardano, permitindo aplicações mais complexas e eficientes. Além disso, os estudos apresentados indicam impacto mínimo na propagação de blocos e no desempenho dos nós, caracterizando a proposta como uma alteração de baixo risco e alto impacto positivo para o ecossistema.
[English]
We chose to vote "YES" on this governance action “Increase Transaction and Block Memory Units (Part 1 of 2)” (gov_action1cgd...0m5y83), because the proposal aims to increase the memory unit limits for Plutus scripts, both per transaction and per block. This change enhances the scalability and capabilities of dApps on the Cardano network, enabling more complex and efficient applications. Furthermore, the analysis provided indicates minimal impact on block propagation and node performance, making this a low-risk, high-impact improvement for the ecosystem. - Yes4.2M ₳No rationale
- Abstain4M ₳Rationale
I see the implications and follow-on impacts that this might have to be beyond my ability to independently assess. To make a sufficiently informed decision would take resources and modeling tools which I do not have, and thus while in principle I am supportive, I will abstain from this vote.
- Yes4M ₳No rationale
- Yes3.9M ₳No rationale
- Yes3.7M ₳No rationale
- Yes3.6M ₳No rationale
- Yes3.5M ₳Rationale
Makes sense
- Yes3.5M ₳No rationale
- Yes3.1M ₳No rationale
- Abstain3M ₳Rationale
As I have not had time yet to properly review this proposal, I am voting Abstain for now.
- Yes2.8M ₳No rationale
- Yes2.8M ₳No rationale
- Yes2.7M ₳No rationale
- Yes2.7M ₳No rationale
- Yes2.7M ₳Rationale
本提案は、Plutusスクリプトのトランザクション単位およびブロック単位のメモリ上限を段階的に引き上げるものです。IntersectのParameter CommitteeおよびTechnical Steering Committeeによる検証・承認を経ており、Node v10.2 に基づくベンチマーク結果も公開されています。
この変更は、将来的により柔軟で高度なDApp設計を検討するための基盤を整えるものであり、ネットワークの安全性や分散性を大きく損なうものではなく、技術的に確認された安全余地の範囲内での調整と考えられます。
開発者の負担軽減と、今後のスケーラブルなアプリケーション展開を支える現実的な改善であると判断し、本提案に賛成します。
This proposal gradually increases the Plutus script memory limits per transaction and per block.
It has been reviewed and approved by Intersect’s Parameter Committee and Technical Steering Committee, with benchmarking results published based on node v10.2.
I understand this change as a practical adjustment that broadens the design space for future DApp development, while remaining within verified technical safety margins.
It does not materially compromise network security or decentralization.
By easing unnecessary constraints for developers and supporting more scalable application design, I see this as a reasonable and forward-looking improvement, and I support the proposal. - Yes2.6M ₳No rationale
- Yes2.5M ₳No rationale
- Yes2.5M ₳Rationale
We have to tune the parameters. Keeping them stagnant helps no one. This particular parameter will enable more storage for more complex use cases. If you want Cardano to be competitive this is a no brainer.