Hard Fork to Protocol Version 11 ('van Rossem' Hard Fork)

Protocol Version 11 bundles a focused set of improvements to **Plutus performance**, **ledger consistency**, and **node-level security** into a single intra-era upgrade. Because it is an intra-era hard fork, transaction shape does not change and ecosystem upgrade effort is minimised. ### Plutus Performance and Capability Plutus is improved in three complementary ways. First, a number of new Plutus primitives, defined in CIP-0109, CIP-0132, CIP-0133, CIP-0138 and CIP-0153; provide an on-chain modular exponentiation primitive, an efficient `dropList` operation, multi-scalar multiplication over BLS12-381, a constant-time `Array` built-in type, and a native `Value` built-in type. Together, these additions address recognised throughput bottlenecks (constant-time indexing, fast list traversal, native `Value` handling), enabling more efficient pairing-based zero-knowledge cryptography (BLS12-381 multi-scalar multiplication), and remove the need to off-load operations such as modular inverses to off-chain processes. Second, the upgrade unifies the set of built-in functions across Plutus V1, V2 and V3. Historically each Plutus language version exposed its own subset of built-ins, so newer functionality was generally reachable only by recompiling contracts to use the latest Plutus version. Following the hard fork, the full set of built-ins (including the ones that have been introduced) will become available across all Plutus language versions, expanding the capabilities of existing Plutus V1 and V2 scripts. Third, `case` expressions over built-in types (`Bool`, `Integer` and `Data`) are added to the Untyped Plutus Language Core (UPLC), addressing performance bottlenecks in data matching, providing significant performance improvements, and yielding cleaner script logic. Collectively, these changes increase script performance, reduce execution cost, and meaningfully extend what builders can accomplish in Plutus. ### Ledger consistency Cardano’s ledger is strengthened by promoting several validation checks into proper ledger predicates and tightening existing rules. VRF key hash uniqueness is enforced at the ledger level, ensuring that no two stake pools can reuse the same VRF key. Reference input rules for Plutus V1/V2 are revised to address predicate checks that previously caused issues for scripts using reference inputs. The Constitutional Committee voting restriction is promoted from a mempool-only check into a proper ledger predicate failure, improving transparency and governance correctness. The non-matching withdrawals predicate is rewritten to provide clearer error messaging and safer validation of withdrawal structures. ### Node-level diagnostics and security Cardano-node is improved by reporting protocol parameter hash (`PPView`) mismatches with greater detail, helping operators identify and resolve configuration issues quickly, alongside the security benefits of VRF key uniqueness above. These changes can only be activated by a hard fork. They alter the rules under which blocks and transactions are validated, so they require coordinated activation across all nodes on the network.

### Technical Evaluation The submission of this governance action has been recommended by Intersect's Hard Fork Working Group on **2026-06-15** and further endorsed by Intersect's Technical Steering Committee on **2026-06-16**. #### Functionality The upgrade enables: 1. **Plutus upgrades:** new primitives (CIP-0109, CIP-0132, CIP-0133, CIP-0138, CIP-0153); unified built-in availability across V1/V2/V3; and `case` expressions on `Bool`, `Integer` and `Data` in UPLC. 2. **Ledger and Cardano Node enhancements:** VRF key hash uniqueness enforced at the ledger level; revised reference input rules for V1/V2; the Constitutional Committee voting restriction promoted from mempool to ledger predicate; a clearer non-matching withdrawals predicate; and improved `PPView` mismatch reporting. All other Protocol Version 10 functionality is preserved, and the transaction shape is unchanged. Testing reports demonstrate no behavioral regressions, show complete conformance between specification and implementation for the new ledger rules, and confirm the correct operation of the new Plutus primitives and `case` expressions across all of Plutus V1, V2 and V3. #### Security Security audits have been undertaken for Plutus BLS primitives and on execution costs for all Plutus primitives. #### Performance [Performance results for Cardano Node version 11.0.1](https://updates.cardano.intersectmbo.org/reports/2026-05-performance-11.0.1) show no regressions from previous versions of the Cardano node for the standard value, Plutus and voting benchmarks, and acceptable baseline performance for the new Plutus primitives and `case` expressions. #### Sustainability The upgrade provides new Plutus functionality that addresses long-standing performance bottlenecks for DApps (constant-time array indexing, fast list traversal, native `Value` handling, native `case`-expressions on `Data`), expands Plutus's cryptographic capabilities (BLS12-381 multi-scalar multiplication, modular exponentiation), unifies built-in availability across Plutus V1, V2 and V3, and tightens ledger rules. ### Plutus Upgrades #### Unified Built-ins for Plutus V1, V2 and V3 Each Plutus language version has historically exposed its own subset of built-ins, so newer functionality was reachable only by recompiling contracts to the latest version. Following the van Rossem hard fork, all built-in functions, including those newly introduced by CIP-0109, CIP-0132, CIP-0133, CIP-0138 and CIP-0153, will be available for all of Plutus V1, V2 and V3. #### Case Expressions for Built-in Types Untyped Plutus Core gains `case`-expressions over the built-in types `Bool`, `Integer` and `Data`. Prior to this upgrade, branching on `Data` structure (or on integer or boolean values) relies on chained `if`/`equalsInteger`/`unConstrData` patterns that are expensive at runtime and verbose at the source level, data matching is one of the major performance bottlenecks in current scripts. Native `case` expressions let the interpreter dispatch on the relevant tag or value directly, yielding significant performance gains and cleaner script logic. #### New Plutus Primitives The new Plutus primitives are defined in five CIPs: [CIP-0109](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0109), [CIP-0132](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0132), [CIP-0133](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0133), [CIP-0138](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0138) and [CIP-0153](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0153). A complementary protocol parameter update governance action (`gov_action1eqhnsdyf3exhp5mqt7sdjtl7xy69wqg8tvg854psns2jt72cra3qqrcnr8r`) provides the corresponding cost model entries that will enable the primitives following the hard fork. ##### **CIP-0109 | Modular Exponentiation Built-in for Plutus Core** Modular exponentiation is used in many cryptographic protocols, including elliptic-curve and pairing-based cryptography. Without a native built-in, Plutus contracts have offloaded operations such as multiplicative inverses to off-chain processes, inflating transaction size and cost. CIP-0109 adds an efficient on-chain modular exponentiation primitive (with inverse support). `expModInteger` ##### **CIP-0132 | New Plutus Builtin dropList** `elemAt` and `drop` operations on lists are a throughput bottleneck for many DApps; today they require the fixed-point combinator, which is expensive on-chain and limits common optimisations such as redeemer-indexing. CIP-0132 introduces a `dropList` built-in that drops a given number of list elements directly, drastically improving `elemAt` and unlocking redeemer-indexing's full potential. `dropList` ##### **CIP-0133 | Plutus support for Multi-Scalar Multiplication over BLS12-381** Multi-scalar multiplication (MSM) over BLS12-381 is central to modern SNARK protocols (e.g. PLONK). Optimised MSM cannot be implemented practically in Plutus directly. CIP-0133 exposes optimised MSM functions from the `blst` library, enabling efficient on-chain verification of pairing-based zero-knowledge proofs. `bls12_381_G1_multiScalarMul, bls12_381_G2_multiScalarMul` ##### **CIP-0138 | Plutus Core Builtin Type - Array** Plutus Core's built-in list is singly-linked, with `Θ(n)` indexing, there is currently no built-in collection with constant-time lookup. CIP-0138 introduces a polymorphic `Array` built-in type with constant-time indexing, unlocking a broad class of classical algorithms and data structures for on-chain code. `indexArray, lengthOfArray, listToArray` ##### **CIP-0153 | Plutus Core Builtin Type - MaryEraValue** `Value` (the multi-asset map of ada and native tokens) is one of the most-used types in Plutus contracts, but is currently manipulated via generic `Map`/`Data` operations, a source of script-execution overhead. CIP-0153 introduces a built-in `Value` type (modelled on the Mary-era multi-asset value) and built-in functions over it, enabling efficient native handling of multi-asset values. `valueData, unValueData, insertCoin, lookupCoin, unionValue, scaleValue` ### Ledger and Cardano Node Enhancements The hard fork promotes several validation checks into proper ledger predicates and tightens existing rules, improving ledger consistency, governance correctness, operator diagnostics, and node-level security. #### VRF Key Hash Uniqueness From the point of the hard fork, VRF key hash uniqueness is enforced at the ledger level: no two stake pools can register or operate with the same VRF key. Promoting this from a non-ledger check to a ledger predicate strengthens stake pool security and mitigates attack vectors that rely on VRF key reuse. #### Revised Reference Input Rules for Plutus V1/V2 Reference input rules for Plutus V1 and V2 scripts are revised, adjusting predicate checks that previously caused incorrect script failures, while preserving V3 semantics. #### Constitutional Committee Voting Restriction Promoted to a Ledger Rule The restriction governing which Constitutional Committee votes are permitted is promoted from a mempool-only check to a ledger predicate failure. Where previously an offending vote could only be rejected at the mempool layer, it now causes a deterministic on-chain ledger failure, improving transparency and ensuring all participants observe the same outcome regardless of submission path. #### Non-matching Withdrawals Predicate The predicate validating reward withdrawals is rewritten for clearer error messaging and safer validation, easing diagnosis for tooling and reducing the surface area for incorrect withdrawal handling. #### Improved Protocol Parameter Hash Mismatch Reporting Errors from a mismatch between a transaction's protocol parameter view (`PPView`) hash and the expected hash for the current ledger state are now reported in greater detail, helping operators identify and resolve configuration issues quickly. ### Consistency with Guardrails The relevant guardrails in the Cardano Constitution are: * **HARDFORK-01:** "The major protocol version must be the same as or one greater than the major version that will be enacted immediately prior to this change. If the major protocol version is one greater, then the minor protocol version must be zero." * **HARDFORK-02:** "The minor protocol version must be no less than the minor version that will be enacted immediately prior to this change." * **HARDFORK-03:** "At least one of the protocol versions (major or minor or both) must change." * **HARDFORK-04:** "At least 85% of stake pools by active stake should have upgraded to a Cardano node version that is capable of processing the rules associated with the new protocol version." * **HARDFORK-05:** "Any new updatable protocol parameters that are introduced with a hard fork must be included in this Appendix and suitable guardrails defined for those parameters." * **HARDFORK-06:** "Settings for any new protocol parameters that are introduced with a hard fork must be included in the appropriate Genesis file." * **HARDFORK-07:** "Any deprecated protocol parameters must be indicated in this Appendix." * **HARDFORK-08:** "New Plutus versions must be supported by a version-specific Plutus cost model that covers each primitive that is available in the new Plutus version." This governance action is consistent with all eight guardrails, provided attention is paid to HARDFORK-04, as described below. None of these guardrails can be checked by the automated guardrails script. #### Consistency with HARDFORK-01 The protocol version will be changed from major version 10 (minor version 0) to major version 11 (minor version 0). #### Consistency with HARDFORK-02 The minor protocol version will be unchanged (0 in both cases). #### Consistency with HARDFORK-03 The major protocol version will change from 10 to 11. #### Consistency with HARDFORK-04 The stake pool upgrade status will need to be determined prior to ratification of the governance action. If insufficient stake pools by stake have been upgraded, the action should not be ratified. #### Consistency with HARDFORK-05, HARDFORK-06 and HARDFORK-07 No new protocol parameters are introduced and none are deprecated, so no guardrail updates or Genesis file changes are required. #### Consistency with HARDFORK-08 No new Plutus version is introduced. The new Plutus primitives are made available across Plutus V1, V2 and V3, with version-specific cost model entries, covering each affected primitive in each Plutus language version, enacted by a separate, previously-enacted protocol parameter update governance action. ## Reversion Plan The hard fork represents a permanent change to the on-chain ledger rules, including new Plutus capabilities. Reversion is only possible in extreme circumstances, using the disaster recovery process that is described in [CIP-0135 | Disaster Recovery Plan for Cardano networks](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0135/README.md). The new Plutus primitives are enabled by a companion governance action that will introduce new cost model settings. If issues are discovered with the Plutus primitives, these settings could be changed so that the primitives could not be used. ### In Memory of Max van Rossem The Cardano community has lost one of its most dedicated builders. Max van Rossem passed away in October 2025, leaving behind a legacy woven into the foundations of Cardano's governance, its community, and the generations of builders who will follow. Max believed in planting digital trees in whose shade he would never sit, and he lived that belief. From the earliest days of AmsterdamNode, running the AMS stake pool with friends, organising the Cardano Summit in the Netherlands four years running (2021 through 2024), and enabling Amsterdam's first bar to accept ada, Max helped turn the Dutch Cardano community into one of Europe's most active hubs. Max shaped the constitutional bedrock of on-chain governance. He served as a member and co-lead of the Constitutional Committee Election Working Group at Intersect, which delivered the first fully elected Constitutional Committee. He represented the Dutch community as a DRep and as a delegate to the Constitutional Convention in Buenos Aires, Argentina, and was a driving force behind the inclusion of Article VIII in the Cardano Constitution. He was a core contributor to the framework of the *Beyond MVG "State of Governance"* report, helping the community to see itself clearly and to visualise what comes next. Max was also a Cardano builder. Through AdaMoments and, finally, Moments, he pursued a singular vision: that individuals should own their digital signal, their identity, and their story. *"User data = User's data"* was not a slogan for him; it was a principle he defended in code, in governance, and in every conversation. Beyond blockchain, he co-founded Stichting Oekraïne Express, personally helping drive humanitarian supplies to the Polish–Ukrainian border and bring refugees to safety. Those who worked with Max remember him as sharp-minded, direct, deep, caring, and unwaveringly committed. He asked hard questions. He built. He showed up. On 11 January 2026, after Max's passing, his son Max Louis Hans van Rossem was born. He will grow up in a world where the blockchain his father helped shape carries his family name, a hard fork named not for a product or a protocol milestone, but for a human being who gave his time, his mind, and his heart to a decentralised future he believed in. The van Rossem hard fork, Cardano's Protocol Version 11, is the community's way of saying: *we remember. The trees you planted are growing. Your signal endures.*