Hard Fork to Protocol Version 11 ('van Rossem' Hard Fork)
6 of 7 committee members voted
- Ace Alliance71aa5b3a…8f04YesActive · term ends epoch 726Rationale
Ace Alliance finds the proposed "Hard Fork to Protocol Version 11 ('van Rossem' Hard Fork)" Hard-Fork Initiation Governance Action Constitutional. Rationales are archived at https://github.com/ace-alliance/ace-voting/
A PDF version of this rationale is also made available.
"Hard Fork to Protocol Version 11 ('van Rossem' Hard Fork)" is a Hard Fork Initiation governance action proposing to upgrade Cardano mainnet from Protocol Version 10.0 to Protocol Version 11.0. The upgrade is intra-era: the ledger remains in the Conway era and the transaction format is unchanged. On-chain effects include activation of five sets of new Plutus primitives (CIP-0109, CIP-0132, CIP-0133, CIP-0138, CIP-0153), unification of built-in function availability across Plutus V1, V2, and V3, native
caseexpressions onBool,Integer, andDatain Untyped Plutus Core, and several ledger and node enhancements (VRF key hash uniqueness enforced at the ledger level; revised reference input rules for Plutus V1/V2; the Constitutional Committee voting restriction promoted from a mempool check to a ledger predicate; a rewritten non-matching withdrawals predicate; and improvedPPViewmismatch reporting). The governance action was recommended by Intersect's Hard Fork Working Group on 2026-06-15 and endorsed by Intersect's Technical Steering Committee on 2026-06-16. Intersect is an industry body closely associated with IOG, the entity historically most involved in Cardano's core protocol development; we note this connection once and apply identical constitutional scrutiny regardless of origin.Article II.6.1-2 (Governance Action Standards). The proposal anchors its justification to an immutable IPFS document (anchor hash
7f683eaf65629963cdc726e0cb7d3be295eb586fc5ba93985878f98e29cee897). The document provides a title, abstract, motivation, and a detailed rationale covering technical evaluation (functionality, security, performance, sustainability) and an explicit guardrail compliance analysis authored by the proposer. It names the Hard Fork Working Group's recommendation date (2026-06-15) and the TSC endorsement date (2026-06-16), links to published performance benchmark results for cardano-node 11.0.1, and references security audits for Plutus BLS primitives and execution costs across all new primitives. The proposal satisfies the format and rationale content standards of Article II.6.1 and II.6.2.Article II.6.3 (Technical Review Requirement). The Constitution requires "Hard Fork Initiation" actions to "undergo sufficient technical review and scrutiny as mandated by the Guardrails." The proposal documents a layered review chain: recommendation by Intersect's Hard Fork Working Group (2026-06-15), endorsement by Intersect's Technical Steering Committee (2026-06-16), security audits for Plutus BLS primitives and all new primitive execution costs, and publicly accessible performance results for cardano-node 11.0.1 showing no regressions in standard value, Plutus, and voting benchmarks. This constitutes sufficient technical review under Article II.6.3.
Appendix I.4 (HARDFORK Guardrails). Eight guardrails govern Hard Fork Initiation actions. We assess each in turn.
HARDFORK-01 requires the major protocol version to be the same as or one greater than the immediately prior version; if one greater, the minor version must be zero. The current protocol version is 10.0; this action proposes version 11.0. The major version increases by exactly one and the minor version is zero. HARDFORK-01 is satisfied.
HARDFORK-02a applies only when the major protocol version does not change. Because the major version changes from 10 to 11, HARDFORK-02a does not apply. The minor-version requirement in this case is governed by HARDFORK-01.
HARDFORK-03 requires at least one of the protocol versions (major or minor or both) to change. The major version changes from 10 to 11. HARDFORK-03 is satisfied.
HARDFORK-04a (non-automated, marked "x") requires that at least 85% of stake pools by active stake have upgraded to a node version capable of processing the new protocol rules before ratification. This guardrail cannot be checked by the automated guardrails script and must be assessed by the Constitutional Committee at the time of voting. As of 2026-06-30, Intersect's Hard Fork Working Group readiness reports confirm that the SPO block-signaling threshold for Protocol Version 11 readiness has been met, and that DApp and exchange ecosystem readiness thresholds have also been met. HARDFORK-04a is satisfied.
HARDFORK-05 (non-automated, marked "x") requires any new updatable protocol parameters introduced by the hard fork to be included in the Appendix with guardrails defined. The proposal states, and we find, that no new updatable protocol parameters are introduced. HARDFORK-05 is satisfied.
HARDFORK-06 (non-automated, marked "x") requires settings for any new protocol parameters to be included in the appropriate Genesis file. No new protocol parameters are introduced, so no Genesis file changes are required. HARDFORK-06 is satisfied.
HARDFORK-07 (non-automated, marked "x") requires deprecated protocol parameters to be indicated in the Appendix. The proposal states, and we find, that no protocol parameters are deprecated. HARDFORK-07 is satisfied.
HARDFORK-08 (semi-automated, marked "~") requires new Plutus versions to be supported by a version-specific Plutus cost model covering each available primitive. This hard fork introduces no new Plutus language version; new primitives are made available across the existing Plutus V1, V2, and V3 versions. Cost model entries for the new primitives are enacted by a companion Protocol Parameter Change governance action (
gov_action1eqhnsdyf3exhp5mqt7sdjtl7xy69wqg8tvg854psns2jt72cra3qqrcnr8r), which Ace Alliance has separately assessed as Constitutional. The new primitive entries activate only after enactment of the PV11 hard fork. HARDFORK-08 is satisfied.Ace Alliance finds the proposed "Hard Fork to Protocol Version 11 ('van Rossem' Hard Fork)" Hard-Fork Initiation Governance Action Constitutional.
- Cardano Curia84feba94…6bd5YesActive · term ends epoch 799Rationale
Cardano Curia finds the “Hard Fork to Protocol Version 11 (‘van Rossem’ Hard Fork)” governance action constitutional. The action is a focused intra-era hard fork that upgrades Cardano mainnet to protocol version 11.0 while remaining in the Conway era, improving Plutus capability, ledger consistency, and node-level security. Cardano Curia also recognizes the naming of this hard fork in remembrance of Max van Rossem and his contributions to Cardano governance and the wider community.
What is being proposed
This governance action proposes a Hard Fork Initiation to upgrade Cardano mainnet to Protocol Version 11.0, known as the “van Rossem” hard fork.
The expected effect is an intra-era protocol upgrade: Cardano remains in the Conway era, while Protocol Version 11 introduces focused improvements to Plutus capabilities, ledger consistency, and node-level security. The proposal includes new Plutus primitives and improved consistency of built-in functions across Plutus versions, supporting better developer experience and more capable smart-contract execution.
Constitutional and guardrails assessment
Cardano Curia classifies this governance action as a Hard Fork Initiation. It is therefore assessed under the Constitution’s general governance action standards and the hard-fork-related guardrails requiring sufficient technical review, scrutiny, ecosystem readiness, and protection of Cardano’s security, functionality, performance, and long-term sustainability.
The action is constitutionally aligned. It does not alter ada ownership rights, censor transactions, restrict access to the Cardano Blockchain, or interfere with governance participation. Instead, it proposes a technical protocol upgrade intended to improve the functionality, security, and developer capability of the network.
The proposal is narrow and technically bounded. It is an intra-era hard fork rather than a new ledger-era transition. This reduces ecosystem disruption because transaction shape and the broader era structure remain stable while the protocol gains targeted improvements.
The proposal also recognizes the relevant readiness condition that at least 85% of stake pools by active stake should have upgraded to a node version capable of supporting Protocol Version 11 before ratification. This condition is important because hard fork initiation requires broad infrastructure readiness and coordinated adoption across the network.
Governance quality assessment
The action has a clear scope: upgrade Cardano mainnet to protocol version 11.0. The intended outcome is measurable: the network either enacts the hard fork and reaches the new protocol version, or it does not.
The action is also supported by a coherent technical rationale. The proposed upgrade bundles focused improvements to Plutus performance and capability, ledger consistency, and node-level security. These are appropriate subjects for a hard fork where changes require protocol-level coordination.
The risk profile is acceptable because the action is not a broad redesign of Cardano’s governance or economics. It does not request treasury funds, change monetary policy, or alter voting rights. The main risks are ordinary hard-fork risks: insufficient node readiness, ecosystem coordination issues, or technical regressions. These risks are mitigated by readiness reporting, SPO participation, technical review, and the explicit upgrade-readiness condition.
Remembrance of Max van Rossem
Cardano Curia also acknowledges the significance of naming this hard fork in remembrance of Max van Rossem. Max contributed to Cardano as a community member, DRep, governance participant, and contributor to the constitutional governance process. Naming Protocol Version 11 the “van Rossem” hard fork appropriately records his contribution in Cardano’s public governance history.
This remembrance is not the constitutional basis for the vote; the constitutional basis is the technical validity, bounded scope, readiness expectations, and absence of conflict with the Constitution. However, the naming is consistent with Cardano’s practice of remembering contributors who helped shape the ecosystem.
Determination
Cardano Curia finds this Hard Fork Initiation constitutional. The action is clear, technically bounded, governance-legible, and aligned with the long-term functionality and sustainability of the Cardano Blockchain. It improves protocol capability while preserving continuity in the Conway era and respecting the constitutional role of SPOs, DReps, and the Constitutional Committee in hard fork governance.
Cardano Curia finds the “Hard Fork to Protocol Version 11 (‘van Rossem’ Hard Fork)” governance action constitutional.
The action is a focused intra-era protocol upgrade that supports Cardano’s functionality, security, developer capability, and long-term sustainability. It remains within the Conway era, minimizes ecosystem disruption, and includes an appropriate readiness expectation for stake pool adoption.
Cardano Curia also records its respect and remembrance for Max van Rossem, whose contributions to Cardano governance and community life are appropriately honored by the naming of this hard fork.
Cardano Curia therefore records 5 constitutional votes, 0 unconstitutional votes, 0 abstentions, 0 did-not-vote, and 0 against votes.
- Cardano Japan Council725d4d44…7b31YesExpired · term ends epoch 653Rationale
We consider this governance action to be constitutional.
This proposal is a Hard Fork Initiation Governance Action regarding the "Hard Fork to Protocol Version 11 ('van Rossem' Hard Fork)". The proposal text describes the upgrade of the Cardano mainnet to Protocol Version 11, the introduction of several new Plutus primitives, the unification of built-in functions across Plutus V1, V2, and V3, support for case expressions for built-in types, and improvements to ledger rules and node-level functionality. Regarding Article 2, Section 6, Paragraphs 1 and 2 of the Cardano Constitution, this proposal adopts an immutable off-chain reference using IPFS. Furthermore, the proposal text includes a summary, motivation, rationale, rollback plan, and references; we therefore determine that it presents sufficient information for evaluation as a Governance Action. Regarding Article 2, Section 6, Paragraph 3 of the Cardano Constitution, the body of this proposal includes recommendations from the Intersect Hard Fork Working Group and endorsement by the Technical Steering Committee, as well as test results, security audits, and performance evaluation results. Based on these, we determine that the sufficient technical review and scrutiny process required by the Cardano Constitution has been carried out. Furthermore, we have confirmed that this proposal meets the protocol version change requirements specified in HARDFORK-01, HARDFORK-02a, and HARDFORK-03. Additionally, no new protocol parameters or new Plutus versions will be introduced, and no clear conflicts with HARDFORK-05 through HARDFORK-08 were identified. HARDFORK-04a stipulates that at least 85% of stake pools, based on active stake, should have upgraded to nodes capable of supporting the new protocol version. Regarding the achievement of 85%, while we were unable to confirm that the active stake threshold had reached 85% or higher, this guardrail is a "should" provision and differs from a mandatory "must" requirement. Furthermore, multiple public metrics - including PoolTool, Cexplorer, and the Intersect Hard Fork Working Group's readiness tracker - indicated an upgrade rate of approximately 80-86%. After comprehensively considering these factors, we found no serious concerns sufficient to deem this proposal unconstitutional. Therefore, we determine that this proposal is constitutional.
For the reasons stated above, we determine that it is constitutional.
- KtorZ64f97568…3a49YesExpired · term ends epoch 653Rationale
Ok, but reckless in various aspects.
The proposal provides a clear technical rationale, demonstrates consistency with the applicable constitutional guardrails, and includes appropriate consideration of deployment readiness and rollback procedures. I therefore find the proposal constitutionally compliant.
I do, however, have significant reservations regarding two aspects of the proposal.
- The proposed Plutus changes: the proposal extends new semantics to existing Plutus language versions rather than introducing them through a new language version. Not only does this harm adoption (by breaking people's working code without them having done anything about it), it also changes the behaviour of already-deployed smart contracts and departs from Cardano's established approach of preserving language semantics across protocol upgrades. When confronted to the topic, the core team at IOG has admitted preferring this approach over introducing a new language version, and that "manual checks" had been performed to ensure this was safe. This is, however, a slippery slope and allowing ourselves to open this door is extremely dangerous.
For other reasons that cannot be stated publicly, I do not consider this sufficient to render the proposal unconstitutional, yet I believe such changes should be approached with extreme caution and only where there is a compelling justification (and here, there isn't).
- Once again, the retroactive modification of the Plutus cost models have a significant impact on dapps development. While the desire to level-set builtins across all Plutus versions may seem like a genuine good idea, it forces every single tool and application downstream into an upgrade that they could avoid. Opting to access new builtins should be a choice, not something forced onto developers. This makes Cardano extremely annoying to work with, especially when obtaining and manipulating the cost models is as annoying as it is (cf: PPViewHashesDontMatch). This is harming adoption.
Despite these points and given the overall benefits of the hard fork, I do not identify a constitutional violation. Nevertheless, I encourage future protocol upgrades to preserve backwards compatibility wherever possible by introducing semantic changes through new language versions rather than retroactively altering existing ones.
- Phil_uplc68bb0b42…8746YesActive · term ends epoch 799No rationale
- Tingvard646d1b3a…be43YesActive · term ends epoch 726Rationale
Tingvard judges the “Hard Fork to Protocol Version 11 (‘van Rossem’ Hard Fork)” governance action constitutional.
This governance action proposes to upgrade Cardano Mainnet to Protocol Version 11.0 through an intra-era hard fork, remaining within the Conway era.
The proposal explains that the hard fork introduces new Plutus primitives, makes built-in functions available consistently across Plutus V1, V2 and V3, supports case expressions for built-in types in Untyped Plutus Core, and introduces several ledger and node-level improvements.
The proposal provides technical rationale for the upgrade, including functionality, security, performance, and sustainability considerations. It states that the action was recommended by Intersect’s Hard Fork Working Group on 2026-06-15 and endorsed by Intersect’s Technical Steering Committee on 2026-06-16.
The proposal identifies the applicable hard fork guardrails:
HARDFORK-01
HARDFORK-02
HARDFORK-03
HARDFORK-04
HARDFORK-05
HARDFORK-06
HARDFORK-07
HARDFORK-08The proposed change from protocol version 10.0 to 11.0 satisfies HARDFORK-01, HARDFORK-02, and HARDFORK-03. The major version increases by one, the minor version remains 0, and at least one protocol version component changes.
The proposal states that HARDFORK-05, HARDFORK-06, and HARDFORK-07 are satisfied because no new protocol parameters are introduced and none are deprecated.
The proposal states that HARDFORK-08 is satisfied because no new Plutus version is introduced. The new Plutus primitives are made available across Plutus V1, V2 and V3, with the corresponding cost model entries provided through a separate protocol parameter update governance action.
HARDFORK-04 requires that at least 85% of stake pools by active stake should have upgraded to a Cardano node version capable of processing the new protocol version before ratification. The proposal acknowledges this requirement and states that readiness will need to be determined before ratification, supported by readiness reports from Intersect’s Hard Fork Working Group.
Tingvard therefore finds that the proposal satisfies the relevant constitutional requirements, provided that the HARDFORK-04 readiness condition is met before ratification.
Tingvard finds the “Hard Fork to Protocol Version 11 (‘van Rossem’ Hard Fork)” governance action constitutional.
The proposal identifies the protocol version change, explains the purpose and technical impact of the upgrade, addresses the relevant hard fork guardrails, provides supporting technical review, and includes a reversion discussion through the disaster recovery process.
Tingvard therefore judges this governance action constitutional, subject to confirmation that the stake pool readiness requirement under HARDFORK-04 is satisfied before ratification.
- Eastern Cardano Council4a822702…3d76Not votedActive · term ends epoch 726No rationale