Cardano’s van Rossem Hard Fork Is Live: What Changes for ADA DeFi Before Leios

Key takeaways

• Cardano mainnet is live on protocol version 11 following the July 18 van Rossem activation.
• The June 18 Plutus Cost Model update and the July 18 hard fork were separate governance actions.
• New capabilities include native arrays, improved multi-asset value handling, modular exponentiation, dropList, BLS12-381 multi-scalar multiplication and case expressions.
• Some existing Plutus primitive costs increased before the fork, so this was not a universal fee reduction.
• Existing smart contracts do not optimize themselves. Many benefits require recompilation, testing, auditing and redeployment.
• ADA did not split into a replacement asset, and Ouroboros Leios is not yet active on mainnet.

Cardano’s van Rossem hard fork activated on July 18

The van Rossem upgrade was an intra-era hard fork. Cardano changed its protocol and ledger rules without leaving the Conway era or adopting a new transaction format. Cardano’s Hard Fork Combinator coordinated the transition without creating a competing ADA asset.

The upgrade is named in memory of Max van Rossem, a contributor to Cardano’s governance and constitutional work. The official spelling is “van Rossem,” despite the “Van Rossum” spelling used in some secondary coverage.

The first distinction I would make is between the Cost Model update and the hard fork. The Cost Model action enacted on June 18. It changed the assigned costs of a small number of existing operations and supplied parameters for new primitives. Those new capabilities only became usable when protocol version 11 activated one month later.

Intersect’s official activation and voting record is available in its van Rossem hard-fork announcement.

What protocol version 11 actually changes

Protocol version 11 broadens the availability of supported built-in functions across Plutus V1, V2 and V3. This means an application may be able to access newer functionality without migrating to the newest Plutus language version solely to use a particular primitive.

That does not mean old contracts rewrite themselves. Compiler support, libraries, transaction builders and off-chain code must expose the new functionality correctly. An immutable validator already deployed on-chain will continue executing the code that was originally published until its protocol deliberately migrates to a replacement contract.

Version 11 also enables case expressions for Bool, Integer and Data. These can replace repetitive matching and branching logic with cleaner code, potentially reducing script size and computation in validators that repeatedly inspect encoded data.

The five new capabilities Cardano developers can use

CIP-138: native arrays

CIP-138 introduces a native Plutus array type with efficient indexed access. Developers previously had to represent many ordered collections as lists or encoded structures that required repeated traversal. Arrays can be useful for order books, batches, state collections and proof data where a validator needs one particular element.

A more efficient data structure is not the same thing as higher network throughput. It reduces work inside contracts that adopt it; it does not change Cardano’s block-production capacity by itself.

CIP-153: MaryEraValue

CIP-153 introduces native handling for Cardano’s multi-asset values. This is particularly relevant to decentralized exchanges, lending markets, NFT applications and transactions containing several native assets.

Under Cardano’s extended UTXO model, validators frequently inspect, compare, add or subtract token bundles. More efficient value handling may reduce script complexity and execution work, but it does not change ADA’s monetary policy or the supply rules of Cardano native assets.

CIP-109: modular exponentiation

Modular exponentiation is a fundamental component of several cryptographic verification systems. A native built-in can be more efficient than expressing the same operation through general Plutus code. Potential applications include signature verification, proofs and interoperability protocols.

CIP-132: dropList

dropList allows a script to discard a specified number of list elements without reproducing the operation through custom recursive logic. A small primitive-level improvement can become meaningful when it is repeated inside a complex validator or batched DeFi transaction.

CIP-133: BLS12-381 multi-scalar multiplication

Multi-scalar multiplication over BLS12-381 is relevant to advanced cryptography, proof aggregation and zero-knowledge systems. The built-in supplies a lower-cost building block, but it does not automatically create a consumer-facing privacy application, bridge or ZK protocol.

The complete technical scope is described in Intersect’s official van Rossem upgrade overview.

Did Cardano smart-contract costs really fall?

I would not describe van Rossem as a blanket fee cut.

The final amount paid for a Cardano smart-contract interaction can depend on several separate variables:

1. The minimum transaction-fee formula.
2. The serialized size of the transaction.
3. Plutus CPU steps.
4. Plutus memory units.
5. Cost-model coefficients.
6. The architecture of the validator.
7. The size of datums and redeemers.
8. The number and structure of inputs and outputs.
9. Fees separately charged by the application.
10. Market costs such as price impact and slippage.

Van Rossem directly changes only some of these variables. An ordinary ADA transfer does not become cheaper merely because new Plutus built-ins exist, especially when that transfer does not execute a Plutus validator.

A DEX interaction could become cheaper if its developers replace repeated list traversal with a native array lookup, rewrite multi-asset calculations around MaryEraValue or simplify data matching with case expressions. The new validator might then consume fewer CPU steps, less memory or fewer bytes.

Users will only see those savings after the protocol updates its code and chooses to pass the reduction through in its user-facing pricing. A DApp could also retain part of the saving as protocol revenue.

Why some existing Plutus primitive costs increased

The preceding Cost Model action increased assigned CPU costs for selected existing operations, including equalsByteString across Plutus versions and the Plutus V3 integer operations divideInteger, modInteger, quotientInteger and remainderInteger.

The changes followed updated calibration intended to align the model more closely with measured execution work. Contracts operating near transaction limits had to update their execution estimates and retest.

This is why “all Plutus costs went down” is inaccurate. A contract that continues relying heavily on a recalibrated operation can become more expensive, while a redesigned contract using native arrays or improved value operations may become more efficient.

Where are the before-and-after benchmarks?

As of publication, I could not locate three production-representative benchmarks that disclosed all the information needed for a genuinely reproducible comparison: contract source, compiler version, Plutus version, protocol parameters, execution budgets, transaction size, test network, transaction hash and redeployment requirements.

The technical case for savings is strong for specific operations, but that is not enough to publish a universal cost-reduction percentage.

What matters now is whether Cardano applications publish version-locked comparisons showing the same transaction compiled and executed before and after adopting the new functionality. Until those results exist, the honest conclusion is that van Rossem makes lower-cost contract designs possible without proving that all production Cardano DeFi interactions are already cheaper.

Ledger and node changes beyond Plutus

Protocol version 11 also enforces uniqueness for stake-pool VRF-key hashes at the ledger level. VRF keys participate in Cardano’s leader-selection process, and two registered stake pools should not reuse the same hash. This reduces a potential class of operator and validation problems without suggesting that earlier Cardano blocks were insecure.

The upgrade additionally revises rules involving Plutus V1 and V2 reference inputs, moves a Constitutional Committee voting restriction from a mempool check into the ledger rules, improves handling of non-matching withdrawal structures and provides clearer diagnostics when protocol-parameter view hashes do not match.

Better diagnostics can reduce debugging time, but they do not directly lower network fees.

Cardano node 11.0.1 also introduced LSM-related storage capabilities. The release documentation lists different memory expectations for the in-memory and on-disk UTXO backends, while also disclosing early known issues for the LSM option. This is a node-software and operational change, not the same thing as a new consensus rule.

Node operators can review the cardano-node 11.0.1 release notes for dependencies, resource guidance and known issues.

What van Rossem means for Cardano DeFi

The most plausible DeFi benefits are smaller validators, lower execution-unit use for selected operations, improved multi-asset accounting, better batching and more efficient cryptographic checks.

Decentralized exchanges may use arrays and MaryEraValue in order routing or batch settlement. Lending protocols could simplify collateral-bundle accounting. NFT marketplaces may reduce work in token-heavy transactions. Bridges, partner chains and proof systems gain cryptographic operations that were previously more difficult to perform efficiently.

Wallets, compilers, SDKs, indexers and off-chain transaction builders are equally important. A protocol cannot safely expose a new validator when its fee estimator or serialization library still assumes the old execution environment.

Readers who are new to this area can review our beginner’s guide to DeFi applications.

At approximately 09:03 UTC on July 21, DefiLlama displayed about $70.08 million in Cardano DeFi TVL and approximately $62.88 million in stablecoin market capitalization. Those figures describe the ecosystem shortly after activation; they are not value created by the hard fork. Dollar-denominated TVL can also rise or fall because ADA and deposited assets change price.

The upgrade creates capacity for better applications. It does not create users, liquidity or sustainable demand by itself.

Which DApps must update or redeploy contracts?

Immutable validators cannot silently change. A protocol that wants its validator to use arrays, MaryEraValue, case expressions or new cryptographic built-ins will normally need some combination of:

• Updated compiler and library versions.
• Changes to off-chain transaction construction.
• Recompiled validators.
• A new security audit.
• Protocol governance or signer approval.
• Contract migration or redeployment.
• A user-interface transition to the new contract.

Some applications may obtain compatibility improvements without replacing their central validator. Others may conclude that the expected savings do not justify migration and audit risk.

Before activation, Intersect reported that DApp and exchange readiness had passed the coordinated thresholds and that version 11 nodes were producing the large majority of recent blocks. These were readiness indicators—not proof that the same share of applications had already redesigned their contracts around the new primitives.

ADA holders do not need to migrate their tokens

The ordinary ADA holder should notice almost nothing at the protocol boundary.

ADA remains the same native asset. Staked ADA remains delegated, and the hard fork did not create “ADA2.” Users do not need to exchange coins, send ADA to an upgrade address or claim a replacement token.

Wallet and exchange customers should keep their software updated and follow legitimate service notices. Readers reviewing their storage setup can use our guide to choosing a cryptocurrency wallet. Delegators can also revisit our complete cryptocurrency staking guide.

Security warning: No legitimate van Rossem process requires users to send ADA, reveal a seed phrase, connect to an unknown website or exchange existing ADA for a replacement token.

A Cardano hard fork coordinated through the Hard Fork Combinator should not be interpreted as the type of contentious chain split historically associated with some Bitcoin or Ethereum forks.

How Cardano’s on-chain governance approved the fork

The more consequential milestone may be the governance process rather than the immediate fee effect.

The percentages above are Intersect’s ratification snapshot from July 13. Cardanoscan’s later enacted-state page displayed slightly higher totals because additional or updated votes were reflected after the point at which the thresholds had already been crossed.

The SPO result was much tighter than the DRep result, clearing its threshold by approximately 1.7 percentage points in Intersect’s snapshot. That does not mean it was a simple one-pool-one-vote contest: the result was stake-weighted. It does show that infrastructure operators expressed a more cautious position than delegated representatives.

Stake pools face the direct operational burden of node upgrades, storage changes, resynchronization and downstream compatibility. A narrow SPO margin may therefore reflect different operational risk tolerances rather than opposition to the technical objective.

On-chain approval also did not eliminate off-chain coordination. Intersect’s Hard Fork Working Group coordinated releases, testing and readiness with contributors from Input Output, Cardano Foundation, EMURGO, Midnight and other ecosystem organizations.

I would not equate a passing vote with unanimous community consensus. Governance quality should be judged through participation, voting-power concentration, independent scrutiny and whether participants had a realistic opportunity to delay or reject the action.

For a broader explanation of validator-based consensus, see our comparison of proof of work and proof of stake.

van Rossem prepares for Leios—but does not activate it

I see van Rossem as a developer and governance upgrade, not Cardano’s finished scaling upgrade.

Van Rossem:

• Moves Cardano to protocol version 11.
• Expands Plutus functionality.
• Changes selected ledger-validation rules.
• Supports more efficient data handling and cryptographic operations.
• Demonstrates Cardano’s constitutional hard-fork process.

Van Rossem does not:

• Activate Ouroboros Leios.
• Immediately multiply Cardano mainnet throughput.
• Replace the existing block-production architecture.
• Guarantee faster confirmation during congestion.
• Introduce every planned Dijkstra-era feature.
• Guarantee that Leios will reach mainnet in 2026.

The current Linear Leios specification preserves Cardano’s Praos chain while introducing additional transaction capacity through endorser blocks. Standard Praos blocks become ranking blocks in the Leios terminology. Endorser blocks reference additional transactions and are validated by stake-based committees before certified data becomes part of the permanent ledger.

An important correction to older descriptions is that the simplified current specification does not use the separate input-block layer found in earlier Leios research. The design now focuses on ranking blocks, endorser blocks, votes and certificates.

The architecture is intended to use more of the bandwidth and processing capacity that Cardano nodes already possess, but every performance claim depends on block parameters, transaction sizes, network topology, node hardware and adversarial conditions.

The current primary specification is available in CIP-164: Ouroboros Linear Leios.

What Musashi Dojo is testing

The public Leios test environment, known as Musashi Dojo, went live on June 23, 2026. It allows independent operators, developers and tooling providers to run prototype Leios nodes and test the evolving Dijkstra-era architecture.

The testnet documentation explicitly warns that Musashi uses pre-release software, can be reset or redeployed and should be run on disposable infrastructure rather than equipment supporting real value. Early synchronization can also be slow because the network has relatively few relays and its catch-up path is not yet fully optimized.

A successful testnet is evidence of progress, not a guaranteed mainnet throughput result. Before Leios can reach production, Cardano still needs stable specifications, security analysis, realistic load testing, adversarial testing, operator readiness and future governance approval.

Developers and stake pool operators can follow the official Musashi Dojo installation guide.

What van Rossem meant for Midnight operators

Midnight operators had to prepare because a Midnight node depends on a local Cardano infrastructure stack containing cardano-node, cardano-db-sync and PostgreSQL. If the underlying Cardano node cannot validate post-fork blocks, downstream data stops advancing and Midnight block production can be affected.

Midnight recommended building a parallel Cardano stack using node 11 or later, cardano-db-sync 13.7.0.5 or later and PostgreSQL 17, then synchronizing and verifying it before cutting over. This was an operational-readiness requirement, not a new user-facing Midnight feature.

Van Rossem did not launch Midnight or create a new NIGHT token event. Midnight’s technical preparation is explained in its operator migration guide.

ADA’s price reaction was not a clean referendum

CoinGecko’s UTC daily data showed ADA near $0.157 on July 13 and around $0.167 on July 18. The move coincided with ratification and activation, but broader cryptocurrency-market conditions also contributed.

There is not enough evidence to isolate van Rossem as the cause of the price move. Protocol improvements do not guarantee token appreciation, and this article makes no ADA price prediction.

The metrics that will show whether van Rossem worked

Activation is binary; practical value is not. The post-fork indicators I would monitor include:

• The share of Cardano DApps using version 11 capabilities.
• The number of upgraded or redeployed validators.
• Median Plutus CPU and memory use by transaction type.
• Median fees for comparable smart-contract interactions.
• Transaction and validator sizes.
• Script-validation failure rates.
• Compiler, SDK, wallet and indexer support.
• Node memory, disk and synchronization performance.
• DEX volume, active DeFi users and stablecoin liquidity.
• TVL measured in both US dollars and native assets.
• Musashi Dojo participation, stability and adversarial-test results.

For me, the strongest post-fork metric is an execution-unit reduction in a production contract performing the same user action. Dollar TVL can rise because ADA rises, while dollar-denominated fees can fall because ADA falls. A reliable assessment should compare equivalent transactions and separate code improvements from market-price effects.

My conclusion: judge van Rossem by adoption, not the activation headline

Cardano’s van Rossem hard fork delivered what it was supposed to deliver at the protocol boundary. Mainnet moved to version 11, the ledger accepted new Plutus capabilities and the network completed a governance-led hard-fork process.

What it did not deliver was an instant universal reduction in transaction fees or the activation of Ouroboros Leios.

The technical opportunity is credible. Native arrays, improved multi-asset handling, case expressions and cryptographic built-ins give developers routes to smaller or less computationally expensive scripts. At the same time, the preceding Cost Model update made some existing operations more expensive, so the real effect is application-specific.

The next proof will come from open-source code, reproducible execution budgets, audited contract migrations and production deployments—not from the activation headline alone.

Frequently asked questions

What is the Cardano van Rossem hard fork?

The van Rossem hard fork is Cardano’s intra-era upgrade to protocol version 11. It adds Plutus capabilities, changes several ledger rules and keeps Cardano in the Conway ledger era.

When did van Rossem activate?

Van Rossem activated on July 18, 2026, at 21:44:51 UTC. The activation occurred at mainnet slot 192,844,800.

What is Cardano protocol version 11?

Protocol version 11 is the active set of Cardano protocol and ledger rules introduced by van Rossem. It enables new built-ins, case expressions and validation changes without beginning a new ledger era.

Did van Rossem reduce Cardano transaction fees?

Van Rossem did not automatically reduce every Cardano transaction fee. It enables more efficient smart-contract implementations, while ordinary ADA transfers and contracts that do not adopt the new functionality receive no automatic saving.

Are Cardano DeFi interactions now cheaper?

Some interactions may become cheaper after applications optimize and redeploy their contracts. The result depends on CPU use, memory, script size, transaction structure and the application’s own fees.

Do ADA holders need to migrate their tokens?

ADA holders do not need to migrate, swap or claim their tokens. Staked ADA also remains staked.

Does the hard fork create a new ADA coin?

The hard fork does not create a new ADA coin. Cardano’s Hard Fork Combinator transitions the existing network without requiring a replacement asset.

What new Plutus features did van Rossem introduce?

The upgrade enables native arrays, MaryEraValue operations, modular exponentiation, dropList, BLS12-381 multi-scalar multiplication and case expressions for Bool, Integer and Data.

Must developers redeploy their smart contracts?

Developers will generally need to redeploy immutable validators when they want the validator itself to use the new features. Tooling-only or off-chain compatibility changes may not always require a new on-chain script.

Is Ouroboros Leios live?

Ouroboros Leios is not live on Cardano mainnet. It is being tested through Musashi Dojo and is expected to require a later Dijkstra-era governance and hard-fork process.

Why was van Rossem important for Cardano governance?

The action required on-chain approval from DReps, stake pool operators and the Constitutional Committee. It demonstrated that Cardano’s governance system can ratify a network upgrade while still relying on substantial technical coordination.

Why is the upgrade called van Rossem?

The upgrade is named in memory of Max van Rossem, who contributed to Cardano governance and constitutional work.

Research snapshot: July 21, 2026, approximately 09:03 UTC. Blockchain, market and DeFi figures can change after publication.

Editorial disclosure: This article is for informational purposes only and does not constitute investment advice. Cryptocurrency and DeFi applications carry technical, liquidity and market risks.