Cardano protocol parameters reference guide

Protocol parameters on Cardano are the various settings that define the blockchain's behavior. Some protocol parameters are stable and non-updatable while others can be adjusted to adapt to changing conditions over time.

Examples of important Cardano protocol parameters include the maximum block size, the transaction fee structure, the block production schedule, and the minimum ada balance required for staking (read more in the following sections). Parameter choices can have a significant impact on the network's performance, security, and usability, and their alteration must be carefully considered.

The Voltaire governance system for Cardano aims to provide a flexible and adaptable framework that can evolve over time. This includes monitoring and changing the various protocol parameters. The collaboration of founding entities (Input Output Global, the Cardano Foundation, and EMURGO) with the community allows for a decentralized approach to governance and decision making. Cardano can then respond to changing conditions and optimize its performance and functionality to meet the needs of its users.

Additionally, the use of protocol parameters allows for agility and innovation within the network, as new ideas and proposals can be tested and implemented without requiring a hard fork or other disruptive changes to the network's architecture. This enables Cardano to remain at the forefront of blockchain technology and provide a robust and sustainable infrastructure for decentralized applications (DApps) and services.

Types of protocol parameters on Cardano

Cardano protocol parameters are classified as follows:

  • Network parameters – affect Cardano’s connectivity properties and performance. Examples include the maximum number of connections allowed per node, peer discovery algorithm, the network propagation speed, block body and header size, transaction size, etc.
  • Economic parameters – affect the economic aspects of blockchain operations. Examples include parameters such as the transaction fee structure, the minimum ada balance required for staking or transacting, stake pool fees, treasury settings, etc.
  • Technical parameters – affect technical protocol properties like the consensus algorithm or cost models, for example. These include the stake pool pledge influence, a target number of stake pools, collateral percentage, and others.
  • Governance parameters – as Voltaire is rolled out, a new class of parameters will be introduced to define the governance process.

Protocol parameters are either updatable or non-updatable:

  • Updatable parameters can be adjusted through governance processes. These parameters can be used to change the operation of the block-producing protocol, vary transaction fees, define the influence of pledge, etc.
  • Non-updatable parameters affect the fundamentals of the Cardano protocol and are stable, which means that they cannot be changed except via a hard fork. Non-updatable parameters include those defining the genesis block or basic security properties, for example. Some non-updatable parameters may be embedded in the source code or implemented as software. Each major protocol version defines its own set of updatable and non-updatable parameters.

Updatable parameters are designed to be flexible and adaptable, allowing the network to evolve over time in response to changing conditions and community needs. Non-updatable parameters, on the other hand, are typically set at the launch of the network or when introducing major changes to the protocol and are intended to provide a stable and secure foundation for the network's operations.

A list of updatable protocol parameters

maxBlockBodySizeNetworkMaximum size of a block body. Limits blockchain storage size and communication costs.
maxTxSizeNetworkMaximum size of a transaction. While several transactions may be included in a block, the maximum transaction size must be strictly less than the maximum block size.
txFeePerByte aka minFeeAEconomicAdditional transaction fee per byte of data (in lovelace).
lovelacePerUTxOWord aka utxoCostPerWordEconomicThe deposit charged per word of UTXO storage. This parameter sets the cost for storing UTXOs and protects against low-cost denial of service attacks.
stakePoolDeposit aka poolDepositEconomicPool deposit (in lovelace).
treasuryCut aka tauEconomicTreasury rate (0.2 = 20%). The proportion of total rewards allocated to treasury each epoch before the remaining rewards are distributed to pools.
minPoolCostEconomicMinimum pool cost per epoch (in lovelace), which enables the pledge effect.
txFeeFixed aka minFeeBEconomicBase transaction fee (in lovelace).
stakeAddressDeposit aka keyDepositEconomicDeposit charged for stake keys (in Lovelace), which ensures that unused keys are returned thus freeing resources.
monetaryExpansion aka rhoEconomicMonetary expansion rate per epoch, which governs the rewards that are returned from reserves to the ecosystem (treasury, stake pools, and delegators).
executionUnitPrices aka executionPricesEconomicExecution prices are specified in fractions of lovelace per Plutus CPU execution step or memory unit. These have been set to be consistent with the cost for a full transaction that contains no Plutus scripts.
poolRetireMaxEpoch aka eMaxTechnicalMaximum number of epochs within which a pool can be announced to retire starting from the next epoch.
collateralPercentageTechnicalPercentage of fee that is used as collateral for a failed transaction.
stakePoolTargetNum (k parameter) aka nOptTechnicalThe target number of stake pools, also known as k, impacts the saturation threshold and encourages the growth of stake pools.
maxCollateralInputsTechnicalMaximum number of collateral inputs in a transaction.
maxValueSizeTechnicalThe limit on the serialized size of the value in each output.
costModelsTechnicalPlutus cost models.
maxBlockExecutionUnits/exUnitsMemNetwork/TechnicalMaximum number of Plutus execution steps that can be used in a single block.
maxBlockHeaderSizeNetwork/ TechnicalMaximum size of the block header, which should be significantly less than the maximum block size.
maxTxExecutionUnits/ exUnitsMemNetwork/ TechnicalMaximum number of Plutus memory units that can be used in a single transaction.
maxTxExecutionUnits/ exUnitsStepsNetwork/TechnicalMaximum number of Plutus execution steps that can be used in a single transaction.
protocolVersionTechnical/ Requires a hard forkProtocol version. Major versions are “hard forks” such as Byron (1), Shelley (2), Allegra (3), etc.
poolPledgeInfluence aka a0Economic/ TechnicalThe ‘influence factor’ that governs how much impact the pledge has on rewards.

You can find a list of non-updatable protocol parameters here.

CIP-09, CIP-28, and CIP-55 provide an overview of protocol parameters in the Shelley, Alonzo, and Babbage eras.