max_block_ex_steps

Cardano Network Parameters Part 23

The Cardano Blockchain has over 40 parameters that lets you tune the system to work on a wide range of applications. In this installment of our series to explore these parameters, we will be covering the max_block_ex_steps network parameter.

In a previous article we covered the max_block_ex_mem, the other peas in the typical pod when it comes to rating a the power of a computer system. If you ever purchased a computer chances are two things that came up in the conversion are processing power and memory. If max_block_ex_mem is about how much RAM (memory) a block can consume, then max_block_ex_steps is about how much CPU power that block can demand.

What is max_block_ex_steps?

At its core, max_block_ex_steps defines the upper limit on the number of Plutus script execution steps allowed in a single block. These “steps” are not exactly your typical second or milliseconds, but rather units of computation as measured in Cardano’s abstract execution cost model. The cost model is designed to make smart contract resource usage predictable and fair across the decentralized network. You can think of these execution steps as the number of operations the blockchain is willing to process in a block, where each operation represents a unit of Cardano specific work.

When a transaction uses a smart contract, that contract runs code. The code is run in a special interpreter on-chain. As it processes the logic, the interpreter keeps track of how many computational “steps” it takes. Too many steps? The transaction fails. If a block tries to include too many steps in total? The block is invalid.

Why does this matter?

Just like in real life, resources are finite. Validators (block producers) must be able to verify blocks quickly and efficiently to keep the chain healthy. max_block_ex_steps puts a ceiling on how much thinking (computation) a single block can demand. This ensures that no block stalls the network with excessive on-chain logic. It also plays a key role in smart contract throughput. A higher max_block_ex_steps means more complex or more numerous scripts can run per block, improving dApp scalability. But increasing it comes at a cost: heavier computation burden on block producers, which might strain less powerful nodes.

How many steps is too many?

As of this writing, the mainnet limit for max_block_ex_steps is set at 20 Billion steps per block. To give a sense of scale: a single Plutus smart contract interaction (like voting in governance, or claiming a reward from a staking pool) might use tens of thousands of steps. This means that, depending on complexity, a block might carry dozens of such interactions before hitting the ceiling.

But it also means developers must carefully budget their scripts. The more efficient the code, the more transactions fit into a block. Tools like Plutus cost estimators and benchmark data help teams measure and optimize their logic against these constraints.

What’s next for this parameter?

Cardano was set up from the beginning to be continuously optimized and improved. As the network evolves, and as node software becomes more performant, parameters like max_block_ex_steps are regularly reviewed by technical bodies within the ecosystem. With Cardano on-chain governance live on mainnet, anyone can raise a request to update this and other updatable parameters. Upgrades like input endorsers and pipelining aim to decouple transaction validation from block production, potentially making higher max_block_ex_steps limits more feasible without compromising decentralization.

TL;DR

  • max_block_ex_steps limits the total computation per block in abstract “steps”.
  • It’s like a CPU cap for the blockchain.
  • Prevents overly complex blocks that would bog down the system.
  • Helps ensure consistent performance and decentralization.
  • Developers must stay under this cap or risk failed transactions.
  • Future upgrades may allow increasing this limit to enable more dApp activity.

Get more articles like this in your inbox

Was the article useful?

Or leave comment

No comments yet…

close

Playlist

  • EP2: epoch_length

    Authored by: Darlington Kofa

    3m 24s
    Darlington Kofa
  • EP1: 'd' parameter

    Authored by: Darlington Kofa

    4m 3s
    Darlington Kofa
  • EP3: key_deposit

    Authored by: Darlington Kofa

    3m 48s
    Darlington Kofa
  • EP4: epoch_no

    Authored by: Darlington Kofa

    2m 16s
    Darlington Kofa
  • EP5: max_block_size

    Authored by: Darlington Kofa

    3m 14s
    Darlington Kofa
  • EP6: pool_deposit

    Authored by: Darlington Kofa

    3m 19s
    Darlington Kofa
  • EP7: max_tx_size

    Authored by: Darlington Kofa

    4m 59s
    Darlington Kofa
0:00
/
~0:00