{"id":24,"number":12,"title":"Dijkstra era parameters","body":null,"structured":{"type":"CAP","category":"Technical","abstract":"The Dijkstra hard fork introduces new updatable protocol parameters for reCarlos Lopez de Lara ference-script protection, Ouroboros Leios, Ouroboros Peras and pool economics (CIP-0023 minimum pool margin, CIP-0050 maximum pledge leverage). Under the Constitution, a parameter that is not listed in Appendix I cannot be changed by a Parameter Update (PARAM-01). HARDFORK-05 requires every new updatable parameter introduced by a hard fork to be added to the Appendix with suitable guardrails. This amendment does exactly that: it names each new parameter, places it in the parameter group and on the critical-parameter list where the ledger implementation puts it, and defines its guardrails, with an updated Guardrails Script to enforce the checkable ones. It adds to the ratified text without changing or removing any existing provision.","motivation":" The Dijkstra hard fork makes new protocol parameters updatable. Under the current Constitution, none of them can be changed. PARAM-01 says that any protocol parameter not explicitly named in Appendix I must not be changed by a Parameter Update action, and the Guardrails Script enforces this on-chain. Until the Constitution names them, every new parameter stays fixed at the value it was given in Dijkstra genesis, and the community has no way to adjust it.\n\nThat has practical consequences:\n\n- Reference-script protection. The limits and fee curve that protect the network against the denial-of-service attack of June 2024 have so far been fixed values in the ledger. Dijkstra makes them protocol parameters so they can be tuned, but they stay frozen until the Constitution lists them.\n- Ouroboros Leios. The parameters that set Endorser Block capacity, timing and the voting committee could not respond to measured network behaviour or growing demand.\n- Maximum pledge leverage (CIP-0050). It is introduced unset, so the feature does nothing at all until a governance action sets a first value. That action is only possible once the parameter is listed.\n- Peras and minimum pool margin (CIP-0023). These become active at a later intra-era hard fork, and would face the same block when that happens.\n\nWhy the Constitution should change\n\nThe Constitution itself requires this amendment. HARDFORK-05 requires every new updatable parameter introduced by a hard fork to be included in Appendix I with suitable guardrails. NEW-CONSTITUTION-01a requires a New Constitution or Guardrails Script action to define them.\n\nUnlocking a parameter without bounds would be unsafe, because several of these parameters are critical to Cardano's security, throughput and denial-of-service resistance. The amendment therefore does three things for each new parameter:\n\n1. defines what it controls;\n2. places it in the parameter group the ledger assigns it, so that the correct DRep threshold applies and, for security-critical parameters, an SPO vote is required;\n3. sets guardrails, enforced by an updated Guardrails Script wherever they can be checked automatically.\n\nThe change adds to the ratified Constitution and does not alter any existing provision.","analysis":"Once enacted, every parameter the Dijkstra hard fork makes updatable can be changed by a Parameter Update action, within the bounds the amendment sets. The community gains the ability to tune Leios capacity and timing as network measurements accumulate, to adjust the reference-script denial-of-service protections, and to activate maximum pledge leverage by setting its first value. Peras and the minimum pool margin become governable in the same way, ready for when they are activated at a later intra-era hard fork.","impact":"","exhibits":"https://hackmd.io/@eJKr9l7wQ6aU2PgNdrfgZg/Dijktstra-parameters\n","revisions":[{"original":"Block. A container of data produced by a Stake Pool that includes, at minimum, a header. Block production and block forging are used interchangeably.","proposed":"Block. A container of data produced by a Stake Pool that includes, at minimum, a header. Block production and block forging are used interchangeably. Under Ouroboros Leios, a Block is also referred to as a Ranking Block (RB), to distinguish it from an Endorser Block. Blocks form the chain exactly as before; under Leios a Block may additionally announce an Endorser Block and may include a Leios Certificate for a previously announced one. Unless expressly stated otherwise, the term Block refers to a Ranking Block and not to an Endorser Block.\n\nEndorser Block (EB). Under Ouroboros Leios, a supplementary block, produced by the same Stake Pool that produced the Ranking Block announcing it, which carries references to additional transactions (rather than the transactions themselves) in order to increase transaction throughput beyond what a Ranking Block can include directly. An Endorser Block is validated and voted on by the Leios Committee; its referenced transactions become part of the Cardano Blockchain only if it gathers sufficient votes to be certified and the resulting Leios Certificate is included in a subsequent Ranking Block. An Endorser Block that is not certified in time is discarded, and its transactions remain eligible for inclusion in later blocks.\n\nLeios Committee. The set of Stake Pools eligible to vote on Endorser Blocks during an epoch: the Stake Pools with the most active stake, up to the number set by *leiosCommitteeSize*, determined once per epoch.\n\nLeios Certificate. An aggregated cryptographic proof, composed of Leios Committee votes, that attests that votes representing at least *leiosQuorumStakeThreshold* of total active stake were cast for the same Endorser Block.\n\nPeras Certificate. An aggregated cryptographic proof, composed of Peras Committee votes, that attests that a quorum of votes for the same block were cast during a round.\n\nPeras vote. A cryptographic proof attesting that a member of the Peras voting committee has voted for a specific block to be one boosted in a Peras election.\n\nPeras voting committee. The set of Stake Pools eligible to vote for blocks under the Ouroboros Peras protocol. Committee membership is determined by a predetermined stake-based selection mechanism.","section":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 1. Introduction","context":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 1. Introduction › Terminology and Guidance"},{"original":"- *maximum script execution/memory units in a single block* (*maxBlockExecutionUnits[steps/memory]*)\n\n- *minimum fee coefficient* (*txFeePerByte*)\n\n- *minimum fee constant* (*txFeeFixed*)\n\n- *minimum fee per byte for reference scripts* (*minFeeRefScriptCoinsPerByte*)","proposed":"- *maximum script execution/memory units in a single block* (*maxBlockExecutionUnits[steps/memory]*)\n\n- *minimum fee coefficient* (*txFeePerByte*)\n\n- *minimum fee constant* (*txFeeFixed*)\n\n- *minimum fee per byte for reference scripts* (*minFeeRefScriptCostPerByte*)","section":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 2.1. Critical Protocol Parameters","context":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 2.1. Critical Protocol Parameters › Parameters that are Critical to the Operation of the Blockchain"},{"type":"addition","insert_after":"- *minimum lovelace deposit per byte of serialized UTxO* (*utxoCostPerByte*)\n\n- *governance action deposit* (*govDeposit*)","proposed":"- *maximum Endorser Block size* (*maxEndorserBlockReferencesSize*)\n\n- *maximum total transaction size per Endorser Block* (*maxEndorserBlockTxsSize*)\n\n- *maximum reference script size per Endorser Block* (*maxRefScriptSizePerEndorserBlock*)\n\n- *maximum Plutus memory and steps per Endorser Block* (*maxEndorserBlockExecutionUnits[memory/steps]*)\n\n- *Leios header diffusion period length* (*leiosAnnouncementPeriodLength*)\n\n- *Leios voting period length* (*leiosVotePeriodLength*)\n\n- *Leios diffusion period length* (*leiosDiffusionPeriodLength*)\n\n- *Leios committee size* (*leiosCommitteeSize*)\n\n- *Leios quorum stake threshold* (*leiosQuorumStakeThreshold*)\n\n- *Peras minimum candidate block age* (*perasMinCandidateBlockAge*)\n\n- *Peras healing factor* (*perasHealingFactor*)\n\n- *Peras certificate boost* (*perasCertBoost*)\n\n- *Peras target committee size* (*perasTargetCommitteeSize*)\n\n- *Peras bootstrap round* (*perasBootstrapRound*)\n\n- *Peras quorum threshold safety margin* (*perasQuorumThresholdSafetyMargin*)\n\n- *maximum reference script size per transaction* (*maxRefScriptSizePerTx*)\n\n- *maximum reference script size per block* (*maxRefScriptSizePerBlock*)\n\n- *reference script cost stride* (*refScriptCostStride*)\n\n- *reference script cost multiplier* (*refScriptCostMultiplier*)","section":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 2.1. Critical Protocol Parameters","context":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 2.1. Critical Protocol Parameters › Parameters that are Critical to the Operation of the Blockchain"},{"original":"MPC-03 (x - \"should\") *minPoolCost* should be set in line with the economic cost for operating a pool","proposed":"MPC-03a: Deprecated\n\n#### Minimum Pool Margin (minPoolMargin)\n\nPart of the rewards mechanism. Defines the lower bound for the pool margin (variable fee), that is, the minimum allowable percentage of rewards a pool can take. Introduced by CIP-0023, it complements *minPoolCost*, the fixed-fee floor. It is a fraction between 0 and 1.\n\nPool registration and update certificates with a lower margin remain valid: if a pool's registered margin is less than *minPoolMargin*, then *minPoolMargin* overrides the pool's registered margin during the reward calculation. The parameter is introduced with the Dijkstra hard fork at a value of 0, and has no effect until the reward calculation that uses it is activated at the intra-era hard fork to protocol version 13.\n\n##### GUARDRAILS\n\nMPM-01 (y) *minPoolMargin* must not be negative\n\nMPM-02 (y) *minPoolMargin* must not exceed 1.0 (100%)\n\nMPM-03 (y) *minPoolMargin* must not exceed [PENDING]\n\nMPM-04 (x - \"should\") *minPoolMargin* should be set with regard to both delegator rewards and the economic viability of operating a pool\n\nMPM-05 (~ - no access to existing parameter values) *minPoolMargin* and *minPoolCost* should not both be zero, so that pool fees always have a floor","section":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 2.2. Economic Parameters","context":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 2.2. Economic Parameters › Minimum Pool Cost (minPoolCost) › GUARDRAILS"},{"original":"#### Transaction fee per byte for a reference script (minFeeRefScriptCoinsPerByte)","proposed":"#### Transaction fee per byte for a reference script (minFeeRefScriptCostPerByte)","section":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 2.2. Economic Parameters","context":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 2.2. Economic Parameters › Transaction fee per byte for a reference script (minFeeRefScriptCoinsPerByte)"},{"original":"MFRS-01 (y) *minFeeRefScriptCoinsPerByte* must not exceed 1,000 (0.001 ada)","proposed":"MFRS-01 (y) *minFeeRefScriptCostPerByte* must not exceed 1,000 (0.001 ada)","section":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 2.2. Economic Parameters","context":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 2.2. Economic Parameters › Transaction fee per byte for a reference script (minFeeRefScriptCoinsPerByte) › GUARDRAILS"},{"original":"MFRS-02 (y) *minFeeRefScriptCoinsPerByte* must not be negative\n\nMFRS-03 (x - \"should\") To maintain a consistent level of protection against denial-of-service attacks, *minFeeRefScriptCoinsPerByte* should be adjusted whenever Plutus Execution prices are adjusted (*executionUnitPrices[steps/memory]*) and whenever *txFeeFixed* is adjusted\n\nMFRS-04 (x - \"unquantifiable\") Any changes to *minFeeRefScriptCoinsPerByte* must consider the implications of reducing the cost of a denial-of-service attack or increasing the maximum transaction fee","proposed":"MFRS-02 (y) *minFeeRefScriptCostPerByte* must not be negative\n\nMFRS-03 (x - \"should\") To maintain a consistent level of protection against denial-of-service attacks, *minFeeRefScriptCostPerByte* should be adjusted whenever Plutus Execution prices are adjusted (*executionUnitPrices[steps/memory]*) and whenever *txFeeFixed* is adjusted\n\nMFRS-04 (x - \"unquantifiable\") Any changes to *minFeeRefScriptCostPerByte* must consider the implications of reducing the cost of a denial-of-service attack or increasing the maximum transaction fee\n\nMFRS-05 (y) *minFeeRefScriptCostPerByte* must not be zero, since a zero base rate makes the whole reference-script tiered fee zero and removes its denial-of-service protection","section":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 2.2. Economic Parameters","context":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 2.2. Economic Parameters › Transaction fee per byte for a reference script (minFeeRefScriptCoinsPerByte) › GUARDRAILS"},{"type":"addition","insert_after":"MBHS-05 (x - \"should\") *maxBlockHeaderSize* should be within TCP's initial congestion window (3 or 10 MTUs)","proposed":"#### Maximum Endorser Block Size (maxEndorserBlockReferencesSize)\n\nThe maximum size, in bytes, of an Endorser Block itself: the list of transaction references it carries, not the transactions those references point to. It limits Endorser Block size to ensure timely diffusion, and prevents issues with many small transactions. CIP-0164 calls this the maximum endorser block size; the parameter is named after what it bounds, the list of transaction references.\n\n##### GUARDRAILS\n\nMEBRS-01 (y) *maxEndorserBlockReferencesSize* must not be negative\n\nMEBRS-02 (y) *maxEndorserBlockReferencesSize* must not be lower than [PENDING] bytes\n\nMEBRS-03 (y) *maxEndorserBlockReferencesSize* must not exceed 1,000,000 bytes\n\nMEBRS-04 (x - \"should\") *maxEndorserBlockReferencesSize* should be large enough to reference transactions filling *maxEndorserBlockTxsSize*, given the expected transaction sizes\n\nMEBRS-05 (x) Any increase to *maxEndorserBlockReferencesSize* must be confirmed by benchmarking and simulation showing that Endorser Blocks can diffuse network-wide within the voting period (*leiosVotePeriodLength*)\n\nMEBRS-06 (x - \"should\") *maxEndorserBlockReferencesSize* should not be increased by more than [PENDING]% in any single epoch\n\n#### Maximum Total Transaction Size per Endorser Block (maxEndorserBlockTxsSize)\n\nThe maximum total size, in bytes, of the transactions that can be endorsed by a single Endorser Block. It limits the total transaction payload to ensure timely diffusion within the stage length. It does not change the maximum size of individual transactions: *maxTxSize* remains unchanged and continues to limit individual transaction sizes.\n\nSetting *maxEndorserBlockTxsSize* to 0 deactivates Linear Leios: Endorser Blocks then endorse no transactions, and all transactions are carried in Blocks. It is the designated way to switch Linear Leios off, for example in an emergency.\n\n##### GUARDRAILS\n\nMEBTS-01 (y) *maxEndorserBlockTxsSize* must not be negative\n\nMEBTS-02 (x) *maxEndorserBlockTxsSize* must not be lower than [PENDING] bytes, except when set to 0 to deactivate Linear Leios\n\nMEBTS-03 (y) *maxEndorserBlockTxsSize* must not exceed 12,000,000 bytes\n\nMEBTS-04 (~ - no access to existing parameter values) *maxEndorserBlockTxsSize* must not be lower than *maxTxSize*, so that any valid transaction can be endorsed by an Endorser Block, except when set to 0 to deactivate Linear Leios\n\nMEBTS-05 (x) Any change to *maxEndorserBlockTxsSize* must be confirmed by benchmarking and simulation demonstrating:\n\n1. That nodes with the expected reference hardware configuration can validate all endorsed transactions within the Endorser Block reapplication time constraint\n\n2. That the resulting network bandwidth requirements remain within the capabilities of the Stake Pool Operator community\n\nMEBTS-06 (x) *maxEndorserBlockTxsSize* does not affect individual transaction size limits; changes to this parameter must not be used as a substitute for adjusting *maxTxSize*\n\nMEBTS-07 (x - \"should\") *maxEndorserBlockTxsSize* should not be increased by more than [PENDING]% in any single governance action\n\nMEBTS-08 (x - \"should\") *maxEndorserBlockTxsSize* should be set well above *maxBlockBodySize*, so that Endorser Blocks add meaningful throughput over Blocks alone\n\n#### Endorser Block Reference Script Size (maxRefScriptSizePerEndorserBlock)\n\nThe maximum total size, in bytes, of reference scripts used by the transactions endorsed by a single Endorser Block. It is the Endorser Block analogue of *maxRefScriptSizePerBlock*: it bounds the script bytes that must be loaded from the UTxO and evaluated per Endorser Block, which the Endorser Block's own size does not account for.\n\n##### GUARDRAILS\n\nMRSEB-01 (y) *maxRefScriptSizePerEndorserBlock* must not be negative\n\nMRSEB-02 (y) *maxRefScriptSizePerEndorserBlock* must not be zero\n\nMRSEB-03 (y) *maxRefScriptSizePerEndorserBlock* must not exceed [PENDING] bytes\n\nMRSEB-04 (y) *maxRefScriptSizePerEndorserBlock* must not be lower than [PENDING] bytes\n\nMRSEB-05 (~ - no access to existing parameter values) *maxRefScriptSizePerEndorserBlock* must not be lower than *maxRefScriptSizePerTx*, so that any valid transaction can be included in an Endorser Block\n\nMRSEB-06 (x) Any increase to *maxRefScriptSizePerEndorserBlock* must be confirmed by benchmarking and simulation demonstrating that the reference-script validation cost of a maximally-filled Endorser Block allows Leios Committee members to validate it within *leiosVotePeriodLength* on the expected reference hardware\n\nMRSEB-07 (x - \"should\") *maxRefScriptSizePerEndorserBlock* should not be changed by more than [PENDING]% in any [PENDING]-epoch period\n\n#### Endorser Block Memory Unit Limits (maxEndorserBlockExecutionUnits[memory])\n\nThe maximum memory allowed for Plutus scripts in a single Endorser Block. It limits memory resources per Endorser Block to ensure timely validation. It is a per-Endorser-Block limit, distinct from the per-block limit (*maxBlockExecutionUnits[memory]*) and the per-transaction limit (*maxTxExecutionUnits[memory]*), which are unchanged. The memory and steps limits are carried together as a single parameter, so an update to either carries both.\n\n##### GUARDRAILS\n\nMEBEU-M-01 (y) *maxEndorserBlockExecutionUnits[memory]* must not be negative\n\nMEBEU-M-02 (y) *maxEndorserBlockExecutionUnits[memory]* must not be lower than [PENDING] units\n\nMEBEU-M-03 (y) *maxEndorserBlockExecutionUnits[memory]* must not exceed [PENDING] units\n\nMEBEU-M-04 (~ - no access to existing parameter values) *maxEndorserBlockExecutionUnits[memory]* must not be lower than *maxTxExecutionUnits[memory]*, so that any valid transaction can be endorsed by an Endorser Block\n\nMEBEU-M-05 (x) Any change to *maxEndorserBlockExecutionUnits[memory]* must be confirmed by benchmarking and simulation on reference hardware demonstrating that an Endorser Block using the full limit can be validated by Leios Committee members within *leiosVotePeriodLength*, and reapplied within the Endorser Block reapplication constraint\n\nMEBEU-M-06 (x - \"should\") *maxEndorserBlockExecutionUnits[memory]* should be set consistent with *maxEndorserBlockExecutionUnits[steps]* so that the combined resource cost of a fully utilized Endorser Block remains within acceptable node resource constraints\n\nMEBEU-M-07 (x - \"should\") *maxEndorserBlockExecutionUnits[memory]* should not be changed by more than [PENDING]% in any [PENDING]-epoch period\n\nMEBEU-M-08 (x - \"should\") *maxEndorserBlockExecutionUnits[memory]* should be set well above *maxBlockExecutionUnits[memory]*, so that Endorser Blocks add meaningful script capacity over Blocks alone\n\n#### Endorser Block CPU Unit Limits (maxEndorserBlockExecutionUnits[steps])\n\nThe maximum computational steps allowed for Plutus scripts in a single Endorser Block. It limits computational resources per Endorser Block to ensure timely validation. It is a per-Endorser-Block limit, distinct from the per-block limit (*maxBlockExecutionUnits[steps]*) and the per-transaction limit (*maxTxExecutionUnits[steps]*), which are unchanged.\n\n##### GUARDRAILS\n\nMEBEU-S-01 (y) *maxEndorserBlockExecutionUnits[steps]* must not be negative\n\nMEBEU-S-02 (y) *maxEndorserBlockExecutionUnits[steps]* must not be lower than [PENDING] units\n\nMEBEU-S-03 (y) *maxEndorserBlockExecutionUnits[steps]* must not exceed [PENDING] units\n\nMEBEU-S-04 (~ - no access to existing parameter values) *maxEndorserBlockExecutionUnits[steps]* must not be lower than *maxTxExecutionUnits[steps]*, so that any valid transaction can be endorsed by an Endorser Block\n\nMEBEU-S-05 (x) Any change to *maxEndorserBlockExecutionUnits[steps]* must be confirmed by benchmarking and simulation on reference hardware demonstrating that an Endorser Block using the full limit can be validated by Leios Committee members within *leiosVotePeriodLength*, and reapplied within the Endorser Block reapplication constraint\n\nMEBEU-S-06 (x - \"should\") *maxEndorserBlockExecutionUnits[steps]* should be set consistent with *maxEndorserBlockExecutionUnits[memory]* so that the combined resource cost of a fully utilized Endorser Block remains within acceptable node resource constraints\n\nMEBEU-S-07 (x - \"should\") *maxEndorserBlockExecutionUnits[steps]* should not be changed by more than [PENDING]% in any [PENDING]-epoch period\n\nMEBEU-S-08 (x - \"should\") *maxEndorserBlockExecutionUnits[steps]* should be set well above *maxBlockExecutionUnits[steps]*, so that Endorser Blocks add meaningful script capacity over Blocks alone\n\n#### Leios Timing Parameters\n\nThe three Leios timing parameters below, the header diffusion period length (L_hdr, *leiosAnnouncementPeriodLength*), the voting period length (L_vote, *leiosVotePeriodLength*) and the diffusion period length (L_diff, *leiosDiffusionPeriodLength*), are expressed in milliseconds. Voting on an Endorser Block starts 3 × L_hdr after the Block announcing it and lasts L_vote. A Leios Certificate for that Endorser Block can be included in a Block no earlier than 3 × L_hdr + L_vote + L_diff after it was announced; that total is converted to a whole number of slots by dividing it by the slot length and rounding up.\n\nThe parameters are tightly coupled through the guardrails below, so a change to any one of them must be evaluated against the values of the other two. They may nevertheless be changed individually or together: the guardrails are conditions on the values that result from a change, not a requirement to change all three.\n\nThe guardrails refer to the following measured characteristics of the network and the ledger. They are not protocol parameters: each is established by benchmarking and simulation on a mainnet-representative topology, and may change as the network evolves.\n\n- *Endorser Block diffusion time*: the time for an Endorser Block to be transmitted and validated network-wide under favourable network conditions, as defined through testnet validation\n\n- *certified Endorser Block transmission time*: the worst-case time for a certified Endorser Block to reach all honest nodes, starting from the stake that voted for it\n\n- *Block diffusion time*: the time for a Block to propagate and be adopted network-wide\n\n- *transaction validation time*: the time to validate the transactions of a Block by standard Praos processing\n\n##### GUARDRAILS\n\nLLS-01 (x) 3 × *leiosAnnouncementPeriodLength* + *leiosVotePeriodLength* must exceed the Endorser Block diffusion time, so that Leios Committee members can receive and validate an Endorser Block before voting on it ends. This must continue to hold after any change to the timing parameters or to *maxEndorserBlockReferencesSize*, *maxEndorserBlockTxsSize* or *maxEndorserBlockExecutionUnits*, since larger Endorser Blocks take longer to diffuse\n\nLLS-02 (x) 3 × *leiosAnnouncementPeriodLength* + *leiosVotePeriodLength* + *leiosDiffusionPeriodLength* + (Block diffusion time − transaction validation time) must exceed the certified Endorser Block transmission time, so that every honest node receives a certified Endorser Block in time to process a Block that includes its certificate within the Block diffusion time\n\nLLS-03 (x - \"should\") 3 × *leiosAnnouncementPeriodLength* + *leiosVotePeriodLength* + *leiosDiffusionPeriodLength* should be well below the expected interval between Blocks (20 seconds at the current active slot coefficient of 0.05 and slot length of one second). Intervals between Blocks are random, so the longer this total, the larger the share of Blocks produced before a certificate can be included: at 14 seconds, about half of all Blocks\n\n#### Leios Header Diffusion Period Length (leiosAnnouncementPeriodLength)\n\nThe duration, in milliseconds, for Block headers to propagate network-wide (L_hdr). It must accommodate header propagation for equivocation detection: voting starts three header diffusion periods after a Block announces an Endorser Block, one for each of initial header propagation, conflicting header propagation and equivocation evidence propagation.\n\n##### GUARDRAILS\n\nLAPL-01 (y) *leiosAnnouncementPeriodLength* must not be lower than [PENDING] milliseconds\n\nLAPL-02 (y) *leiosAnnouncementPeriodLength* must not exceed 5,000 milliseconds\n\nLAPL-03 (y) *leiosAnnouncementPeriodLength* must not be negative\n\nLAPL-04 (x) *leiosAnnouncementPeriodLength* must exceed the time it takes a Block header to propagate network-wide, with headroom for adverse network conditions, as measured by benchmarking and simulation on a mainnet-representative topology\n\nLAPL-05 (x) Any change to *leiosAnnouncementPeriodLength* must be evaluated together with the values of *leiosVotePeriodLength* and *leiosDiffusionPeriodLength* that will apply alongside it, and validated via simulation against LLS-01 to LLS-03. The three parameters may be changed individually or together\n\n#### Leios Voting Period Length (leiosVotePeriodLength)\n\nThe duration, in milliseconds, during which Leios Committee members can vote on Endorser Blocks (L_vote). It must accommodate Endorser Block propagation and validation time, and is set to the minimum value that ensures honest parties can participate in voting.\n\n##### GUARDRAILS\n\nLVPL-01 (y) *leiosVotePeriodLength* must not be lower than [PENDING] milliseconds\n\nLVPL-02 (y) *leiosVotePeriodLength* must not exceed 20,000 milliseconds\n\nLVPL-03 (y) *leiosVotePeriodLength* must not be negative\n\nLVPL-04 (x) *leiosVotePeriodLength* must be long enough for Leios Committee members to receive and validate an Endorser Block and for their votes to diffuse to Block producers, as shown by benchmarking and simulation on a mainnet-representative topology\n\nLVPL-05 (x) Any change to *leiosVotePeriodLength* must be evaluated together with the values of *leiosAnnouncementPeriodLength* and *leiosDiffusionPeriodLength* that will apply alongside it, and validated via simulation against LLS-01 to LLS-03. The three parameters may be changed individually or together\n\n#### Leios Diffusion Period Length (leiosDiffusionPeriodLength)\n\nThe additional duration, in milliseconds, after voting that ensures network-wide availability of a certified Endorser Block (L_diff). It is derived from the fundamental safety constraint, and relies on the network assumption that data known to more than 25% of nodes propagates fully within this time.\n\n##### GUARDRAILS\n\nLDPL-01 (y) *leiosDiffusionPeriodLength* must not be lower than [PENDING] milliseconds\n\nLDPL-02 (y) *leiosDiffusionPeriodLength* must not exceed [PENDING] milliseconds\n\nLDPL-03 (y) *leiosDiffusionPeriodLength* must not be negative\n\nLDPL-04 (x) *leiosDiffusionPeriodLength* must be long enough for a certified Endorser Block to reach all honest nodes before a Block that includes its certificate needs to be processed, as shown by benchmarking and simulation on a mainnet-representative topology\n\nLDPL-05 (x) Any change to *leiosDiffusionPeriodLength* must be evaluated together with the values of *leiosAnnouncementPeriodLength* and *leiosVotePeriodLength* that will apply alongside it, and validated via simulation against LLS-01 to LLS-03. The three parameters may be changed individually or together\n\n#### Leios Committee Size (leiosCommitteeSize)\n\nThe number of top-stake Stake Pools seated on each epoch's Leios Committee (N_c). The value is a whole number of seats (e.g., 900), not a stake fraction. It directly bounds the number of votes per Endorser Block and the size of a Leios Certificate.\n\nIt is governed from the stake distribution, so that the cumulative active stake of the seated Stake Pools (the committee's stake coverage) exceeds *leiosQuorumStakeThreshold* with headroom. Coverage above the threshold is a hard floor rather than an operating point: at exactly the threshold every seated Stake Pool must vote and be reachable within the voting period, so a practical choice leaves budget for seated Stake Pools that are offline, have no registered voting key, or are slow.\n\n##### GUARDRAILS\n\nLCS-01 (y) *leiosCommitteeSize* must not be negative\n\nLCS-02 (y) *leiosCommitteeSize* must not be zero\n\nLCS-03 (y) *leiosCommitteeSize* must not be lower than [PENDING] (seats)\n\nLCS-04 (x) *leiosCommitteeSize* must be set such that, under the prevailing stake distribution, the active stake held by the seated Stake Pools exceeds *leiosQuorumStakeThreshold*, with sufficient headroom for seated Stake Pools that do not vote\n\nLCS-05 (x) Any increase to *leiosCommitteeSize* must be shown by benchmarking and simulation to leave the resulting vote traffic per Endorser Block diffusing within *leiosVotePeriodLength*\n\nLCS-06 (x) Any change to *leiosCommitteeSize* must be supported by an analysis of the prevailing stake distribution showing that LCS-04 continues to hold\n\nLCS-07 (x) *leiosCommitteeSize* and *leiosQuorumStakeThreshold* must be evaluated jointly; any change to either must be accompanied by an analysis confirming that *leiosQuorumStakeThreshold* remains strictly lower than the stake coverage of the seated Stake Pools\n\nLCS-08 (x - \"should\") *leiosCommitteeSize* should be reviewed whenever *stakePoolTargetNum*, *maxPledgeLeverage* or the stake distribution change materially\n\n#### Leios Quorum Stake Threshold (leiosQuorumStakeThreshold)\n\nThe minimum fraction of total active stake that must be represented by votes in a Leios Certificate (τ). The threshold is a fraction between 0 and 1 of total active stake, not of committee votes (e.g., 0.75 represents 75% of total active stake).\n\nIt is safety-critical. It must be greater than 0.5 and lower than the stake coverage of the seated Leios Committee. Below 0.5, two disjoint sets of voters could each reach a quorum and certify conflicting Endorser Blocks. It must also exceed the adversarial stake that the protocol tolerates by a sizable margin, because the honest stake above that margin is what guarantees that a certified Endorser Block is held widely enough to reach all honest nodes by the end of the diffusion period.\n\n##### GUARDRAILS\n\nLQST-01 (y) *leiosQuorumStakeThreshold* must be greater than 0.5 (50%)\n\nLQST-02 (y) *leiosQuorumStakeThreshold* must be lower than 1.0 (100%)\n\nLQST-03 (x - \"should\") *leiosQuorumStakeThreshold* should not be lower than 0.6 (60%)\n\nLQST-04 (x - \"should\") *leiosQuorumStakeThreshold* should not exceed 0.9 (90%)\n\nLQST-05 (x) *leiosQuorumStakeThreshold* must be strictly lower than the share of active stake held by the Stake Pools seated under *leiosCommitteeSize*, under the prevailing stake distribution\n\nLQST-06 (x) Any decrease to *leiosQuorumStakeThreshold* must be accompanied by a formal security analysis demonstrating that the resulting threshold still ensures the fraction of honest nodes guaranteed to know a certified Endorser Block exceeds the minimum required for safe diffusion within *leiosDiffusionPeriodLength*, under the assumed adversarial stake bound\n\nLQST-07 (x) *leiosQuorumStakeThreshold* and *leiosCommitteeSize* must be evaluated jointly; any change to either must be accompanied by a combined security analysis demonstrating that the joint settings satisfy the Leios protocol safety and liveness requirements\n\nLQST-08 (x) Any change to *leiosQuorumStakeThreshold* must be confirmed by benchmarking and simulation\n\nLQST-09 (x - \"should\") *leiosQuorumStakeThreshold* should not be changed more than once in any 18-epoch period (approximately 3 months) except in response to a Severity 1 or Severity 2 security issue\n\n#### Reference Script Protection Parameters\n\nThe following four parameters govern the reference-script denial-of-service protections that were introduced as a security update during the Conway era. In the Conway ledger their values are fixed constants that no governance action can change. From the Dijkstra hard fork they become updatable protocol parameters, and the guardrails below constrain how governance may set them. They operate alongside *minFeeRefScriptCostPerByte* (defined above), which sets the base per-byte price to which the tiered reference-script fee is applied.\n\n#### Maximum Reference Script Size Per Transaction (maxRefScriptSizePerTx)\n\nThe maximum total size, in bytes, of all reference scripts a single transaction may use. Each reference is counted separately, even when the same script is referenced more than once. A transaction whose combined reference-script size exceeds this limit is invalid. In the Conway ledger this value is fixed at 204,800 bytes (200 KiB); from the Dijkstra hard fork it becomes governable. It works together with the reference-script tiered fee (see *minFeeRefScriptCostPerByte*, *refScriptCostStride*, and *refScriptCostMultiplier*) and with the per-block limit (*maxRefScriptSizePerBlock*). The ledger represents it as an unsigned 32-bit integer (0 to 4,294,967,295 bytes).\n\n##### GUARDRAILS\n\nMRST-01 (y) *maxRefScriptSizePerTx* must not be negative\n\nMRST-02 (y) *maxRefScriptSizePerTx* must not be zero\n\nMRST-03 (y) *maxRefScriptSizePerTx* must not exceed [PENDING] bytes\n\nMRST-04 (y) *maxRefScriptSizePerTx* must not be lower than [PENDING] bytes\n\nMRST-05 (~ - no access to existing parameter values) *maxRefScriptSizePerTx* must not exceed *maxRefScriptSizePerBlock*, so that a transaction is never permitted more reference-script data than an entire Block\n\nMRST-06 (x - \"should\") Any increase to *maxRefScriptSizePerTx* should be reviewed together with the reference-script tiered fee parameters (*minFeeRefScriptCostPerByte*, *refScriptCostStride*, *refScriptCostMultiplier*) so that denial-of-service protection is preserved\n\nMRST-07 (~ - no access to existing parameter values) *maxRefScriptSizePerTx* must not exceed *maxRefScriptSizePerEndorserBlock*, so that any valid transaction can be included in an Endorser Block\n\nMRST-08 (~ - no access to existing parameter values) *maxRefScriptSizePerTx* must not be decreased, so that funds locked by scripts that must be supplied as reference scripts remain spendable\n\nMRST-09 (x) Any increase to *maxRefScriptSizePerTx* must be confirmed by benchmarking and simulation demonstrating that the validation cost of a transaction using the maximum permitted reference-script size remains within the processing constraints of nodes on the expected reference hardware\n\nMRST-10 (x - \"should\") *maxRefScriptSizePerTx* should not be changed by more than [PENDING]% in any [PENDING]-epoch period\n\n#### Maximum Reference Script Size Per Block (maxRefScriptSizePerBlock)\n\nThe maximum total size, in bytes, of all reference scripts referenced by all transactions in a single block, counted with multiplicity. A block whose combined reference-script size exceeds this limit is invalid. This parameter bounds the reference-script validation work that a single block can impose on nodes. In the Conway ledger this value is fixed at 1,048,576 bytes (1 MiB); from the Dijkstra hard fork it becomes governable. The ledger represents it as an unsigned 32-bit integer (0 to 4,294,967,295 bytes).\n\n##### GUARDRAILS\n\nMRSB-01 (y) *maxRefScriptSizePerBlock* must not be negative\n\nMRSB-02 (y) *maxRefScriptSizePerBlock* must not be zero\n\nMRSB-03 (y) *maxRefScriptSizePerBlock* must not exceed [PENDING] bytes\n\nMRSB-04 (y) *maxRefScriptSizePerBlock* must not be lower than [PENDING] bytes\n\nMRSB-05 (~ - no access to existing parameter values) *maxRefScriptSizePerBlock* must not be lower than *maxRefScriptSizePerTx*, so that any valid transaction can be included in a Block\n\nMRSB-06 (x) Any increase to *maxRefScriptSizePerBlock* must be confirmed by benchmarking and simulation demonstrating that the reference-script validation cost of a maximally-filled Block remains within the processing constraints of nodes on the expected reference hardware\n\nMRSB-07 (x - \"should\") *maxRefScriptSizePerBlock* should not be changed by more than [PENDING]% in any [PENDING]-epoch period\n\n#### Reference Script Cost Stride (refScriptCostStride)\n\nThe increment size, in bytes, over which the per-byte price of reference scripts grows. Reference-script fees follow a tiered, stepwise- exponential schedule: the first *refScriptCostStride* bytes of a transaction's reference scripts are priced at the base rate (*minFeeRefScriptCostPerByte*), and each subsequent stride of *refScriptCostStride* bytes is priced at the previous tier's rate multiplied by *refScriptCostMultiplier*. A smaller stride makes fees escalate more steeply with reference-script size; a larger stride approaches a flat per-byte fee. In the Conway ledger this value is fixed at 25,600 bytes (25 KiB); from the Dijkstra hard fork it becomes governable. The ledger represents it as a non-zero unsigned 32-bit integer (1 to 4,294,967,295 bytes); a stride of zero is rejected by the ledger encoding before any guardrail is consulted.\n\n##### GUARDRAILS\n\nRSCS-01 (y) *refScriptCostStride* must not be zero\n\nRSCS-02 (y) *refScriptCostStride* must not be negative\n\nRSCS-03 (y) *refScriptCostStride* must not exceed [PENDING] bytes\n\nRSCS-04 (y) *refScriptCostStride* must not be lower than [PENDING] bytes\n\nRSCS-05 (~ - no access to existing parameter values) *refScriptCostStride* should be lower than *maxRefScriptSizePerTx*, so that transactions using large reference scripts reach the higher pricing steps of the fee curve\n\nRSCS-06 (x - \"should\") *refScriptCostStride* should be set together with *refScriptCostMultiplier* and *minFeeRefScriptCostPerByte* so that the reference-script tiered fee continues to make large reference-script transactions progressively more expensive, preserving denial-of-service protection\n\nRSCS-07 (x) Any change to *refScriptCostStride* must be confirmed by benchmarking and simulation demonstrating that the reference-script denial-of-service protection is preserved\n\n#### Reference Script Cost Multiplier (refScriptCostMultiplier)\n\nThe growth factor applied to the per-byte reference-script price at each successive stride (*refScriptCostStride*). It is the base of the tiered fee's exponential growth: the per-byte price for the k-th stride is the base rate (*minFeeRefScriptCostPerByte*) multiplied by *refScriptCostMultiplier* raised to the power k. A value of 1.0 yields a flat per-byte fee; values above 1.0 make each additional stride of reference-script data progressively more expensive. In the Conway ledger this value is fixed at 1.2; from the Dijkstra hard fork it becomes governable. The ledger represents it as a positive rational number (strictly greater than zero); a multiplier of zero is rejected by the ledger encoding before any guardrail is consulted.\n\n##### GUARDRAILS\n\nRSCM-01 (y) *refScriptCostMultiplier* must not be negative\n\nRSCM-02 (y) *refScriptCostMultiplier* must not be lower than 1.0, so that the per-byte reference-script price is non-decreasing across tiers and denial-of-service protection is not weakened\n\nRSCM-03 (y) *refScriptCostMultiplier* must not exceed [PENDING]\n\nRSCM-04 (x - \"should\") *refScriptCostMultiplier* should be set together with *refScriptCostStride* and *minFeeRefScriptCostPerByte* to preserve the intended denial-of-service protection of the reference-script tiered fee\n\nRSCM-05 (x) Any change to *refScriptCostMultiplier* must be confirmed by benchmarking and simulation demonstrating that the reference-script denial-of-service protection is preserved\n\n#### Peras Parameters\n\nThe following parameters govern Ouroboros Peras, as specified in CIP-0140. They are introduced with the Dijkstra hard fork and have no effect until Peras is activated at the intra-era hard fork to protocol version 13.\n\n##### GUARDRAILS\n\nPE-01 (x) The epoch length must be divisible by the Peras round length (U = 90 slots)\n\n#### Peras Minimum Candidate Block Age (perasMinCandidateBlockAge)\n\nThe minimum age, in slots, of a candidate block for being voted upon (L in CIP-0140).\n\nIts value is fixed at 30 slots, the value proposed in CIP-0140.\n\n##### GUARDRAILS\n\nPMCBA-01 (y) *perasMinCandidateBlockAge* must not be lower than 30 slots\n\nPMCBA-02 (y) *perasMinCandidateBlockAge* must not be larger than 30 slots\n\n#### Peras Healing Factor (perasHealingFactor)\n\nThe healing factor (h), the healing time coefficient used to derive the length of a Peras cooldown period (T_heal). It is a positive fraction.\n\n##### GUARDRAILS\n\nPHF-01 (y) *perasHealingFactor* must not be lower than 1\n\nPHF-02 (y) *perasHealingFactor* must not be larger than 3\n\n#### Peras Certificate Boost (perasCertBoost)\n\nThe extra chain weight that a Peras Certificate gives to a block (B in CIP-0140).\n\nIts value is fixed at 15, the value proposed in CIP-0140.\n\n##### GUARDRAILS\n\nPCB-01 (y) *perasCertBoost* must not be lower than 15\n\nPCB-02 (y) *perasCertBoost* must not be larger than 15\n\n#### Peras Target Committee Size (perasTargetCommitteeSize)\n\nThe number of members on the Peras voting committee (n in CIP-0140).\n\n##### GUARDRAILS\n\nPTCS-01 (y) *perasTargetCommitteeSize* must not be lower than 500\n\nPTCS-02 (y) *perasTargetCommitteeSize* must not be larger than 1000\n\n#### Peras Bootstrap Round (perasBootstrapRound)\n\nThe Peras round number used to manually bootstrap Peras voting for the first time, and to resynchronize voting after unexpected failures. Under the Peras voting rules, voting cannot start if there are no Peras votes on the chain; this parameter provides the way to start Peras voting, and to unblock it in an unforeseen situation. It may be unset, and is unset when introduced.\n\n##### GUARDRAILS\n\n[PENDING] No guardrail has been proposed for *perasBootstrapRound* yet.\n\n#### Peras Quorum Threshold Safety Margin (perasQuorumThresholdSafetyMargin)\n\nThe extra safety margin (τ_margin) added on top of the Peras quorum threshold, which is fixed at a baseline of 75% and is not itself a protocol parameter. It is required to mitigate the security risk from votes possibly being transferred to malicious nodes. It is a fraction between 0 and 1.\n\n##### GUARDRAILS\n\nPQTSM-01 (y) *perasQuorumThresholdSafetyMargin* must be lower than 0.25","section":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 2.3. Network Parameters","context":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 2.3. Network Parameters › Block Header Size (maxBlockHeaderSize) › GUARDRAILS"},{"type":"addition","insert_after":"PPI-04 (x - \"should\") *poolPledgeInfluence* should not vary by more than +/- 10% in any 18-epoch period (approximately 3 months)","proposed":"#### Maximum Pledge Leverage (maxPledgeLeverage)\n\nPart of the rewards mechanism; provides protection against Sybil attack. Caps a pool's reward-eligible stake at the lower of the saturation point (1 / *stakePoolTargetNum*) and *maxPledgeLeverage* times the pool's pledge, so a pool reaches full rewards only when its pledge is proportionate to its stake. Stake above *maxPledgeLeverage* times the pool's pledge earns no rewards, for the operator or its delegators. Introduced by CIP-0050.\n\nIt is one of two protocol parameters that may be unset (null), together with *perasBootstrapRound*. It is introduced unset at the Dijkstra hard fork, which leaves the rewards calculation as it was in earlier eras, and the cap takes effect only once a \"Parameter Update\" action sets a value. When set, it is a ratio between 1 and 10,000, the range given in CIP-0050. A \"Parameter Update\" action may also return it to unset, which removes the cap again.\n\n##### GUARDRAILS\n\nMPL-01 (y) *maxPledgeLeverage*, when set, must not be lower than 1\n\nMPL-02 (y) *maxPledgeLeverage*, when set, must not exceed 10,000\n\nMPL-03 (y) *maxPledgeLeverage* may be set to null (unset), which removes the leverage cap and restores the reward calculation used before the Dijkstra era; MPL-01 and MPL-02 apply only when it is set to a value\n\nMPL-04 (x - \"should\") *maxPledgeLeverage* should be set with regard to protection against Sybil attack, the economic viability of operating a pool, and the prevailing *poolPledgeInfluence*\n\nMPL-05 (x - \"should\") Changes to *maxPledgeLeverage* should be announced at least [PENDING] epochs in advance, so that pool operators can adjust their pledge","section":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 2.4. Technical/Security Parameters","context":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 2.4. Technical/Security Parameters › Pledge Influence Factor (poolPledgeInfluence) › GUARDRAILS"},{"original":"PRME-02 (x - \"should\") *poolRetireMaxEpoch* should not be lower than 1","proposed":"PRME-02a (y) *poolRetireMaxEpoch* must not be lower than 1","section":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 2.4. Technical/Security Parameters","context":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 2.4. Technical/Security Parameters › Pool Retirement Window (poolRetireMaxEpoch) › GUARDRAILS"},{"type":"addition","insert_after":"*maximum number of collateral inputs* (*maxCollateralInputs*)","proposed":"- *maximum Endorser Block size* (*maxEndorserBlockReferencesSize*)\n\n- *maximum total transaction size per Endorser Block* (*maxEndorserBlockTxsSize*)\n\n- *maximum reference script size per Endorser Block* (*maxRefScriptSizePerEndorserBlock*)\n\n- *maximum Plutus memory and steps per Endorser Block* (*maxEndorserBlockExecutionUnits[memory/steps]*)\n\n- *Leios header diffusion period length* (*leiosAnnouncementPeriodLength*)\n\n- *Leios voting period length* (*leiosVotePeriodLength*)\n\n- *Leios diffusion period length* (*leiosDiffusionPeriodLength*)\n\n- *Leios committee size* (*leiosCommitteeSize*)\n\n- *Leios quorum stake threshold* (*leiosQuorumStakeThreshold*)\n\n- *maximum reference script size per transaction* (*maxRefScriptSizePerTx*)\n\n- *maximum reference script size per block* (*maxRefScriptSizePerBlock*)\n\n- *reference script cost stride* (*refScriptCostStride*)\n\n- *reference script cost multiplier* (*refScriptCostMultiplier*)\n\n- *Peras minimum candidate block age* (*perasMinCandidateBlockAge*)\n\n- *Peras healing factor* (*perasHealingFactor*)\n\n- *Peras certificate boost* (*perasCertBoost*)\n\n- *Peras target committee size* (*perasTargetCommitteeSize*)\n\n- *Peras bootstrap round* (*perasBootstrapRound*)\n\n- *Peras quorum threshold safety margin* (*perasQuorumThresholdSafetyMargin*)","section":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 9. List of Protocol Parameter Groups","context":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 9. List of Protocol Parameter Groups"},{"original":"The economic parameter group consists of:\n\n- *minimum fee coefficient* (*txFeePerByte*)\n\n- *minimum fee constant* (*txFeeFixed*)\n\n- *minimum fee per byte for reference scripts* (*minFeeRefScriptCoinsPerByte*)","proposed":"The economic parameter group consists of:\n\n- *minimum fee coefficient* (*txFeePerByte*)\n\n- *minimum fee constant* (*txFeeFixed*)\n\n- *minimum fee per byte for reference scripts* (*minFeeRefScriptCostPerByte*)","section":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 9. List of Protocol Parameter Groups","context":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 9. List of Protocol Parameter Groups"},{"type":"addition","insert_after":"- *treasury expansion* (*treasuryCut*)\n\n- *minimum fixed rewards cut for pools* (*minPoolCost*)","proposed":"- *minimum pool margin* (*minPoolMargin*)","section":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 9. List of Protocol Parameter Groups","context":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 9. List of Protocol Parameter Groups"},{"type":"addition","insert_after":"*pool pledge influence* (*poolPledgeInfluence*)","proposed":"- *maximum pledge leverage* (*maxPledgeLeverage*)","section":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 9. List of Protocol Parameter Groups","context":"APPENDIX I. CARDANO BLOCKCHAIN GUARDRAILS › 9. List of Protocol Parameter Groups"}],"co_authors":[]},"type":"CAP","state":"open","author_stake_address":"stake1uxh5vx8a9svkka2ef372hpytpffwrge4yf3c40nq0lfqa0sejrqru","author_display_name":"carlos lopez de lara","labels":[{"name":"consultation"},{"name":"CAP"},{"name":"Technical"},{"name":"author-ready"}],"comments":14,"moderation_status":"visible","withdrawal_requested_by":null,"withdrawal_requested_by_name":null,"created_at":"2026-10-01T16:04:56.781410+00:00","updated_at":"2026-10-09T04:24:39.105144+00:00","co_authors":[]}