Upstream

YES - Reduce minPoolCost to 75 ada and increase Plutus Memory Limits (Part 2).

In regards to minPoolCost, this reduction has been discussed and debated by the community for years. Many believe this to be an important step in proving that liquid delegations are viable in the context of allowing smaller stake pools to attract delegators, others think it will force small stake pools out of operations via a race to the bottom. The reality of this param is that it is fundamentally useless to the network beyond bootstrapping and initial now less relevant ideas, and ultimately has caused a long term issue with the reward curve. The incentives this parameter provides are not healthy to the Cardano network, this and the lack of other parameters that provide pool incentives is exactly the main topic of discussion among SPOs. Firstly, there is little to no incentive to delegate to small stake pools. Any delegator with the knowledge of how the rewards work will understand they lose money if they stake with small pools, this is just the math of the situation we are in. For small SPOs to be able to compete we must be attractive to delegators. Secondly the race to the bottom is not predicated by this parameter, some likely feel this way because it is the only reliable income they have to gain from being a small stake pool, which includes us at Upstream with a current 250k stake. With this lens we cannot in good conscience support minPoolCost at all, and would vote for it to be ultimately replaced with a clearer poolCost (a cost reflective of what a Stake Pool thinks it's worth, delegators can decide, as it should be). Stake Pools can set any fee they like and we will likely keep ours to ensure operations for a short time, but at some point for small pools to be competitive we need to be able to say in earnest 'delegate to Upstream and earn the same as you would from any other pool' (or as close to that sentence as possible). Of course this is just a band-aid on the actual problem, which is the lack of params that actually drive liquid delegation to smaller pools, which of course can only be achieved if smaller pools are paid equal or more rewards to delegators, than that of larger pools. That is an honest and true incentive to achieve this goal, if indeed this is the collective Cardano goal. Until we have this, small pools will always bear the brunt of our network's incentive structures, and these discussions are only token gestures to cover the problems / intentional alternative incentives. If the aim is a secure network with thousands of productive pools then let's put our money where our mouth is and drive incentives back down the pyramid we have created.

As for Plutus Memory Limits, this continues on from the first step in the long planned updates (since 2024) and we approved the previous gov action and so we complete this here. The impact for these parameters is minor, only affecting those who must update direct implementations, if at all. Reviewing the technical communities' work, the proposal references and the provided benchmarks make it clear it's very low risk and impact for day to day chain activity.

YES - Update Constitutional Committee 2026.

We vote yes to update the constitutional committee for a few reasons. Firstly the 4 committee seats that are expiring need to be filled so governance continues as planned, this rotation is fundamental to the continued operation of the CC, staggering the seat rotations, and builds on the work done by community workshops for the last 2 years. Secondly these candidates were elected in the 2026 Constitutional Committee election by means of a community votes and we support their work and respect the election outcomes, albeit the continued low turnouts from the community for these elections, this is still by far the most inclusive path we have in Cardano for updating the constitutional committee.

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.

YES - Update Committee Action.

This action adds an eighth members to the Constitutional Committee, thus strengthening the Committees ability to make decisions.

The current min committee size parameter is set to seven, with seven serving members. We see some of these members currently missing votes, or submitting abstain with poor reasoning, raising concerns that some members are not fulfilling their elected duty. Adding this new member will help mitigate situations like no vote or poor abstain reasoning, and more importantly give us a member count one above the minimum threshold, preventing another potential retirement and snap election scenario.

The applicant Cristina is a commited Cardano community member, and has a proven track record of public discourse with the community on governance subjects and the Cardano ecosystem in general.

From a technical review of the governance action, it is submitted with the correct 'previous action reference'.

For these reasons we support this new committee action. We would have preferred the applicant to reach out to others and build a Consortium, which we believe is a more appropriate structure for member seats.

YES - Update Committee Action.

With the retirement of the Cardano Atlantic Council bringing us below quorum, we are in urgent need of a replacement committee member so we can continue with a functioning system and allow us to address other open governance actions.

Along with the urgency, the potential committee member Cardano Curia consists of a consortium who are representative of the Cardano Community, active im the public spaces and openly discuss governance topics with knowledge necessary to take on this role.

We understand Intersects mandate for supporting and funding this governance action, and respect the outcome of the off-chain voting process held on the Ekklesia platform. Although a preferred outcome would be to see an update committee action including 2-3 new members, addressing the real problem at hand of our committee only being at the minimum quorum (protocol parameter: committeeMinSize is currently 7, this new member puts us back to 7).