Private Stake Pool by Cardano Foundation
Badges (1)
Forum activity (0)
No forum posts yet.
Governance record
- Yes2 (100%)
- No0 (0%)
- Abstain0 (0%)
No vote changes
Voting history (2)
YesHard Fork to Protocol Version 11 ('van Rossem' Hard Fork)Decided epoch 644View rationaleEnacted2mo ago
Cardano Foundation votes YES on this Hardfork Governance Action to fork into "van Rossem". We have been actively involved in the Hardfork Working Group, where we monitored readiness along many different verticals (Exchange readiness, Technical readiness and SPO readiness, et al).
A PDF version of this rationale is also made available.
Cardano Foundation votes YES on this Hardfork Governance Action to fork into "van Rossem".
NOTE on 'Internal Voting':
The fields constitutional and unconstitutional below reflect the CF governance teams' individual opinions whether they are for or against the proposal. Reason for this inconsistency is, that CIP-136 is at the moment only applicable to CC rationales, but we want to record the internal opinions of our DRep assessment transparently as well.
YesIncrease Transaction and Block Memory Units (Part 1 of 2)Decided epoch 614View rationaleEnacted7mo ago
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.