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.
- YesNo rationale
- YesNo rationale
- YesRevotedHistory
Earlier votes
Yes7mo agoSuperseded
- YesRevotedHistory
Earlier votes
Yes7mo agoSuperseded
- 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
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.
- YesRationale
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.
- YesRationale
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.
- YesRationale
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.
- YesRationale
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.
- YesRationale
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.
- YesRationale
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.
- 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