Increase Transaction and Block Memory Units (Part 1 of 2)
395 SPOs voted · 15 with a rationale · 7 changed their vote · 2 re-voted unchanged
Open a row to read the rationale.
- YesRationale
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.
- YesNo rationale
- YesNo rationale
- YesNo rationale
- NoNo rationale
- NoNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- AbstainNo rationale
- AbstainNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesRationale
YES – Parameter Change
This governance action proposes an increase to Plutus execution memory limits (Part 1 of 2). Specifically, it increases the maximum Plutus script memory units per transaction by 25%, and the maximum Plutus script memory units per block by 25%. The proposal was submitted by Intersect’s Parameter Committee with the stated objective of improving flexibility and headroom for DApp developers building on Cardano.
As part of our governance responsibilities, we have followed the discussions on this parameter update since 2025-05-08, when it was formally introduced. In evaluating this action, we reviewed its potential impact across several dimensions: block propagation and network adoption, node performance and resource requirements, possible increases in stake pool operator overhead, and overall ecosystem readiness. We also considered community forum discussions, technical feedback, and guidance provided by the Technical Steering Committee.
It is important to note that discussion around adjusting these specific memory parameters predates December 2023. The proposal is supported by technical analysis, historical performance data, and sustained community engagement. In our assessment, this demonstrates both sufficient maturity of the idea and adequate transparency in its development.
From a governance perspective, parameter changes must balance innovation with network stability. In this case, we believe the 25% increase represents a measured and proportionate adjustment. It provides additional capacity for more complex smart contract use cases while remaining within operational tolerances for the majority of stake pool operators.
Based on the available evidence, the length and depth of prior discussion, and the documented technical rationale, we consider this proposal to be responsibly constructed and appropriately scoped. We therefore vote YES on Part 1 of 2, with the expectation that we will also support Part 2 of 2, subject to a final review of its detailed specifications and impact analysis.
We remain committed to reviewing all parameter changes with a focus on long-term sustainability, decentralization, and predictable network performance.
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale