Intersect’s Technical Steering Committee has endorsed a series of parameter updates focused on improving smart contract capacity. Now entering Cardano’s testnets, these changes increase Plutus execution memory and update the Plutus V2 cost model, a key step in optimizing on-chain performance through safe, transparent governance.

On behalf of the Technical Steering Committee, Intersect will proceed in conjunction with the Parameters committee to iterate on and submit these governance actions over the coming months.

These changes aim to reduce friction for smart contract development, expanding the range of applications possible on Cardano, while demonstrating that community-led parameter changes can be applied safely, predictably, and transparently.

The first of these three actions is currently on the Preview testnet, for community review 

• see via CardanoScan
• see via Cexporer
• see via GovTool.

Background

The Plutus script memory unit limits define the total memory available to scripts within a transaction and a block, denoted by maxTxExecutionUnits[memory] & maxBlockExecutionUnits[memory]. Increasing these values enables smart contract developers to do more within transactions and blocks.

Community members have expressed strong support for increasing these limits, see Protocol Change Proposal 3 via Cardano Forum.

What is changing

Across three governance actions:

• A total 25% increase to Plutus script memory unit limits for transactions and blocks (To avoid violating Constitution guardrail MTEU-M-04, the 25% increase in memory units is required to be split between two separate governance actions.)
• Update the Plutus V2 Cost Model to include two primitives previously exclusive to Plutus V3:
  • integerToByteString
  • byteStringToInteger

No other protocol parameters or Plutus cost model settings will be changed.

Why?

Two key motivations underlie these governance actions:

1. Community demand: Developers and DApp builders have requested increased Plutus script memory unit limits (see PCP-003) to reduce the need for manual optimizations and ease contract deployment.
2. Technical alignment: Enabling additional primitives in Plutus V2 improves consistency between language versions, reducing friction for developers migrating or maintaining applications across V2 and V3.

Rationale

Intersect’s Parameter Committee proposes for the first governance action, increasing:

• maxTxExecutionUnits[memory] from 14,000,000 → 16,500,000 units (~ +17.9%)
• maxBlockExecutionUnits[memory] from 62,000,000 → 72,000,000 units (~ +16.1%)

Depending on the successful enactment of this first action, a second governance action will be used to increase the script memory units further.

The second governance action will aim to:

• maxTxExecutionUnits[memory] from 16,500,000 units → 17,500,000 units (+1,000,000 units)
• maxBlockExecutionUnits[memory] from 72,000,000 → 77,500,000 units (+5,500,000 units)

The third governance action will focus on the Plutus V2 cost model, adding costs for some Plutus V3 builtins into Plutus V2.

Technical Evaluation

Comprehensive benchmarking was conducted on Cardano node versions 10.2 and 10.3 by IOE’s Performance and Tracing team.

We can see from these results that:

• Per-transaction performance remains well within acceptable limits with the higher memory ceiling
• Per-block execution performance maintains block propagation time budgets with adequate headroom
• Praos timing guarantees are not impacted.

The cost model settings for the two new primitives have been derived from standard benchmarking on a reference machine and align with existing Plutus cost model procedures.

Raising maxTxExecutionUnits[memory] and maxBlockExecutionUnits[memory] could significantly improve Plutus script throughput with minimal impact on block propagation or node performance, making it a low-risk and high-impact change.

Rollout

Due to the criticality of these changes, the Parameters Committee has recommended that these changes be introduced to Preview and PreProd networks before Mainnet so that the changes can be enacted and tested on testnets before submission to Mainnet.

Note: due to maxBlockExecutionUnits[memory] inclusion within the Security group of protocol parameters, changes to it require approval from DReps, Constitutional Committee, and Stake Pool Operators. This is likely to be the first time that stake pool operators vote on a parameter update.

First Protocol Parameter Update

See the estimated timeline for the first governance action, aiming for ratification and enactment across testnets by November, to allow mainnet submission by early November. Look out for these actions across testnets in the second half of October.

 

The first of these three actions is currently on the Preview testnet, for community review:

• see via CardanoScan
• see via Cexporer
• see via GovTool.

The community is invited to review this action and provide feedback.

For each action on testnets, a confirmation test will be performed to test and ensure that the intended changes were successfully enacted. The following network’s action will not be submitted until the tests have been completed successfully.

Following actions

The second governance action will likely be planned for January to avoid changes during December’s holiday period. The third action to update the Plutus V2 Cost Model is expected early in 2026.

Stay Informed

To get one step ahead, you can follow the development of the first governance action’s metadata via: github.com/IntersectMBO/governance-actions.

Beyond that, look out for these actions on testnets as well as accompanying announcements.