Proposed Intra-Era Hard Fork to Protocol Version 11

Cardano’s next protocol upgrade is now approaching community review. The proposal outlines an Intra-Era hard fork to Protocol Version 11, introducing targeted improvements across Plutus performance, ledger consistency, and node-level security without changing transaction shape or transitioning to a new ledger era.

These refinements represent the latest round of treasury-funded development nearing completion, and the ecosystem is now invited to assess, discuss, and contribute feedback as Intersect convenes the Hard Fork Working Group to coordinate readiness and ensure broad alignment.

Why now?

To implement several improvements to the Cardano Haskell node, a Cardano mainnet hardfork is required. This proposed upgrade of an Intra-Era hardfork to Protocol Version 11 introduces a small set of improvements across security, governance, and Plutus capability.

These updates represent the next tranche of treasury-funded development work nearing completion, and the community is now invited to review, discuss, and provide feedback.

Intersect has been informed of the brief proposal and will convene the Hard Fork Working Group (HFWG) to coordinate readiness, gather ecosystem input, and ensure governance actions reflect broad consensus. As with the Chang and Plomin hard forks, this group plays a key role in surfacing concerns, validating impact, and supporting smooth adoption across the ecosystem.

Things that will not change

With a regular hard fork, the ledger transitions into a new era. This can introduce significant architectural or model-level changes, such as new transaction types, new governance rules, or significant scripting capabilities. Requiring extensive upgrades across the ecosystem. An example of this was the Chang hard fork, adding many new types of governance-related transactions and ledger rules.

With an Intra-Era Hard Fork, by contrast, the ledger doesn't change era, keeping Cardano within the same ledger era (currently Conway). It introduces refinements, fixes, optimisations, and new features that do not require an era transition. It does require network-wide coordination, but usually with a much lower integration burden than during era transitions. Does not introduce a new transaction share or a significant breaking semantic change.

To summarize, the proposed upgrade will introduce improvements without changing transaction shape. This means the upgrade burden is much lower than for previous hardforks.

Areas of change

Plutus upgrades

All built-in functions are available across Plutus V1, V2, and V3:
Expanding the capabilities of Plutus V1 and V2 scripts and unifying the feature availability across versions.
case Expressions for built-in types:
Enables case expressions on Bool, Integer, and Data within UPLC. Provides significant performance improvements and cleaner script logic. Addresses one of the major performance bottlenecks in data matching.
New built-ins and native types:

CIP-138 | Array type – adding efficient, native on-chain array handling
CIP-153 | MaryEraValue type – optimised multi-asset value operations
CIP-109 | Modular exponentiation builtin – critical for advanced crypto
CIP-132 | dropList builtin – efficient list manipulation
CIP-133 | Multi-scalar multiplication over BLS12-381 – useful for advanced cryptographic operations, specifically with zero-knowledge proof systems

All of these new builtins will be introduced across all Plutus versions. Collectively, these changes increase script performance, reduce execution cost, and meaningfully extend what builders can accomplish in Plutus.

Ledger and Cardano Node enhancements

VRF Key uniqueness enforcement:

Ensures no two stake pools reuse the same VRF key
Strengthens pool security and mitigates possible attack vectors
This means that from the point of hardfork, VRK key hash uniqueness is enforced at the ledger level

Revised reference input rules for Plutus V1/V2:

Adjusts predicate checks that previously caused issues for scripts using reference inputs
This fixes a scenario where

Constitutional Committee voting restriction moved to a ledger rule:

Shifts a mempool-only check into a proper ledger predicate failure
Improves transparency and governance correctness

Non-matching withdrawals predicate:

Clearer error messaging and safer validation of withdrawal structures

Improved protocol parameter hash mismatch reporting:

Better diagnostics when PPView hashes differ
Helps operators identify and resolve configuration issues quickly

Caveats and timeline

As always, the proposal reflects the current proposed scope. As engineering work progresses and community feedback rolls in, details will evolve.

Intersect will continue using established communication pathways to share refinements, updated timelines, and structured readiness information.

If you have proposed changes that you’d like to see within this hard fork, please reach out to [email protected].

What happens next

The hard fork working group will form and meet, fortnightly initially, to discuss and coordinate matters related to the proposed hard fork.

This is an open Intersect working group, and anyone is welcome to join. A successful mainnet hard fork requires more than just Intersect members; it requires a whole ecosystem.

Where to find information

Follow the working group on X/Twitter, Discord, and via these Intersect news bulletins. We will be communicating updates after every working group session.

Do you feel passionately about a particular area of the community or a topic? Join the hard fork working group and represent your peers - we are always on the lookout for community champions to help define different parts of the ecosystem and provide unique perspectives.

Over the coming weeks, all hard fork-related information will be publicly available via the Intersect Knowledge Base here.

You can always reach the Intersect team at [email protected].