[{"id":53,"proposal_number":12,"parent_id":null,"body":"Editor notes: \nThanks for getting this in, it's a serious piece of work and the overall structure is right. Every new parameter is defined, placed in its group, and given guardrails, which is exactly what HARDFORK-05 asks for, and it's cleanly additive so it's easy to see nothing existing is touched. A few things I'd want sorted while we are still in consultation.\n\n1. **[PENDING] values.** Just noting these are here. I know they're deliberate placeholders standing in for the real bounds, so no action beyond getting the final numbers in before this heads toward enactment.\n\n2. **minPoolMargin has no section.** It's named in the abstract and added to the economic parameter list, but unlike every other new parameter it has no description and no guardrails block. The Peras parameters get the full treatment even though Peras only activates at the later intra-era hard fork, so the same should apply here. Either add a definition and guardrails for minPoolMargin, or say why it's being deferred.\n\n3. **Peras parameter names don't match across the lists.** In the list added after govDeposit the Peras parameters carry a \"pp\" prefix (ppPerasMinCandidateBlockAge, ppPerasCertBoost, and the rest), while the definitions and the second list (after maxCollateralInputs) use the unprefixed names (perasMinCandidateBlockAge, etc.). These need to match the ledger's actual parameter keys, and match each other, or enforcement and cross-reference break. Please pick one set and use it everywhere.\n\n4. **Smaller consistency and formatting points.**\n\n   - Numbering: the Leios Quorum Stake Threshold jumps from LQST-03 to LQST-05, so LQST-04 is missing. Worth a pass over all the IDs to check none are skipped.\n   - Markdown: a few parameter bullets have unbalanced italics, for example \"maximum reference script size per Endorser Block (maxRefScriptSizePerEndorserBlock)\", and the Reference Script Cost Multiplier heading ends with a single asterisk instead of closing the bold. They render messily.\n   - Markers: most guardrails are (y), (x) or (x - \"should\"), but PBR-02 uses a \"~\" marker. If that's a distinct category, make sure it's defined against the legend used elsewhere in Appendix I.\n\n5. **Two layers of bounds.** Some parameters carry both a hard numeric bound and a [PENDING] one. maxPledgeLeverage is the clearest: MPL-01 and 02 pin it to 1 and 10,000, then MPL-03 and 04 are [PENDING]. If the fixed ones are the ledger's absolute encoding limits and the pending ones are the governance guardrails sitting inside them, that's fine, but say so once so reviewers know which is which.\n\n6. **References and exhibits are empty.** For a change this size it would help to cite the CIPs behind each group and the Dijkstra ledger spec, and ideally an exhibit mapping each parameter to its ledger group and its critical or non-critical status. That makes the technical review much faster.\n\nOn routing: the actual values, the security reasoning in the (x) guardrails, and the Guardrails Script changes need eyes from the TSC and the ledger team, so I'll forward it there for technical feedback, same as we did with CAP-10. From the editor side the structure is sound, and the points above are what I'd want addressed first.","author_stake_address":"stake1u8dknvrfz38gr8afd0c8vskmz7dkd79gn05gr8mh6ym3cjs7886dj","author_display_name":"Thomas","created_at":"2026-10-02T12:08:46.841518+00:00","updated_at":"2026-10-07T07:44:56.184378+00:00","moderation_status":"visible","about":null},{"id":54,"proposal_number":12,"parent_id":null,"body":"Hello,\n\nThank you for this amendment; HARDFORK-05 requires it, and the structure is clear. SIPO is a DRep and also operates three stake pools, with a direct interest in the pool-economics parameters. This comment is not a statement of how SIPO will vote on any future on-chain action.\n\nTwo points:\n\n1. minPoolMargin. As the editor notes, it is listed in the economic group with no definition or guardrails. Under PARAM-02a, the Guardrails Script would impose no constraints on it, short of the \"suitable guardrails\" HARDFORK-05 requires. One option is (y) bounds now, as the Peras parameters have. Otherwise, listing it in the amendment for the later hard fork at which the proposal says it activates seems safer than listing it unbounded; PARAM-01 keeps it at its genesis value meanwhile.\n\n2. maxPledgeLeverage. It starts unset, so the first Parameter Update applies the cap in one step, and stake above the cap earns no rewards for operators or delegators. poolPledgeInfluence has PPI-04 to limit the pace of change; MPL has no pace or notice guardrail. One option, modelled on PARAM-04a:\n\n\"MPL-06 (x - \"should\") A Parameter Update that first sets or lowers maxPledgeLeverage should be published off-chain at least 90 days before submission, together with an analysis of how much delegated stake would lose reward eligibility.\"\n\nFinally, CAP-10, also in consultation, names minimum pool margin and pledge leverage as examples of future parameters that may need SPO approval. It would help if both proposals stated how they relate.\n\n— SIPO DRep","author_stake_address":"stake1ux92yx3mk3wuj7q2t7m7hjt9l3nl9alqv9c56p976w4erkcd7x8kv","author_display_name":"SIPO","created_at":"2026-10-03T02:08:15.627665+00:00","updated_at":"2026-10-07T07:42:19.085356+00:00","moderation_status":"visible","about":"revisions[3]"},{"id":56,"proposal_number":12,"parent_id":null,"body":"My primary concern here is not with any of the new parameters to be added, but by an existing one that will be made obsolete with the addition of minPoolMargin:\n\n> MPC-03 (x - \"should\") minPoolCost should be set in line with the economic cost for operating a pool\n\nThe intent of CIP-23 and the new minPoolMargin parameter is to completely replace minPoolCost.  The expectation is that a parameter change governance action will set minPoolMargin to some initial value and set minPoolCost to zero at the same time.\n\nWithout removing MPC-03, the Constitutional Committee would likely interpret such a parameter change governance action to be unconstitutional.  This would completely undermine the purpose of including CIP-23 in the Dijkstra era and all the hard work that went into it.\n\nWithout a removal or change of MPC-03, I would find myself unable to vote in favor of this new Constitution text.","author_stake_address":"stake1uygyajn4dq8smt779tyaf7f8ha2x5veyuehmtd9lvy8kjjqwmde62","author_display_name":"Cerkoryn","created_at":"2026-10-04T13:41:29.376793+00:00","updated_at":"2026-10-07T07:47:46.049179+00:00","moderation_status":"visible","about":"revisions[5]"},{"id":57,"proposal_number":12,"parent_id":null,"body":"One other point regarding the new maxPledgeLeverage parameter:\n\n> MPL-05 (x - \"should\") *maxPledgeLeverage* should be set with regard to both protection against Sybil attack and the economic viability of operating a pool\n\nI'm not sure this is necessarily the right approach.  Protection against Sybil attacks is definitely a strong feature of this parameter, but hard to interpret what setting is needed for that.  \"Economic viability\" is even more dubious here, because it's unclear how maxPledgeLeverage effects that.  There are already pools with 0 pledge that are economically viable, and there could be pools that are fully-pledged that are not economically viable.\n\nOne of the ways I look at it is in conjunction with stakePoolTargetNum.  If we are targeting 500 pools but we have well over that amount (~1600 currently), maxPledgeLeverage could be used as a \"lever\" to guide the protocol toward the target number of stake pools.  In other words, we would set L to a lower value that would push us toward the 500 most well-pledged pools.  Similarly, if we target a higher number of stake pools such as 2000, we could set L to a higher value that eases the pledge requirements to encourage more pools.","author_stake_address":"stake1uygyajn4dq8smt779tyaf7f8ha2x5veyuehmtd9lvy8kjjqwmde62","author_display_name":"Cerkoryn","created_at":"2026-10-04T13:53:04.505500+00:00","updated_at":"2026-10-07T07:43:54.962692+00:00","moderation_status":"visible","about":"revisions[3]"},{"id":58,"proposal_number":12,"parent_id":null,"body":"On behalf of Intersect's Parameter Committee, sharing a technical review of what changes are needed to the constitution and guardrails to support the Dijkstra-era parameters.   The notes include some open questions that will need to be addressed.\n\nConcrete guardrail settings will need to be decided on the basis of benchmarking as well as simulation, once a fully integrated implementation is available.\n\nhttps://docs.google.com/document/d/1w1MoqOTADVfVfUuU_L5tp33-cBiuKzXHtGERBiQE9WI/edit?usp=sharing","author_stake_address":"stake1uy42cc65gdhryw93aezcag9j7k4pv9fxrdx982086yrxy2quecjvx","author_display_name":null,"created_at":"2026-10-05T16:37:16.721361+00:00","updated_at":"2026-10-05T16:37:16.721364+00:00","moderation_status":"visible","about":null},{"id":59,"proposal_number":12,"parent_id":null,"body":"Following on from the above comment.  Please also see the detailed notes provided via the Google Doc, which identify a number of additional guardrails that are required to enable Dijkstra, and questions that should be answered by the team...\n\nComment on CAP-12: Dijkstra era parameters\n\nThank you for this. The structure is sound, it's additive, and it does what HARDFORK-05 requires. I'm commenting as Chair of the TSC on behalf of the Parameter Committee. The points concern guardrails that protect users when parameters change, plus some classification fixes. The proposed wording follows the existing Appendix I style.\n\n1. Reducing maxRefScriptSizePerTx can lock funds.\nReference scripts on spent inputs count towards this limit. Reducing it below the size of an existing UTxO's reference script makes that UTxO unspendable. I suggest:\n\nMRST-07 (~ - no access to existing parameter values) maxRefScriptSizePerTx must not be reduced\n\n2. The largest transactions can be confined to Ranking Blocks.\nThree per-EB limits have no floor relative to the matching per-transaction limit. Without one, the largest transactions can only go into RBs and may wait indefinitely under load (Tenet 1). I suggest:\n\nMRSEB-05 (~ - no access to existing parameter values) maxRefScriptSizePerEndorserBlock must not be lower than maxRefScriptSizePerTx\nMEBTS-08 (~ - no access to existing parameter values) maxEndorserBlockTxsSize must not be lower than maxTxSize\nMEBEU-M-06 / MEBEU-S-06 (~ - no access to existing parameter values) maxEndorserBlockExecutionUnits[memory/steps] must not be lower than maxTxExecutionUnits[memory/steps]\n\nThe third follows the CIP's own reasoning: it deliberately left per-transaction limits unchanged so that an attack on certification can't starve high-budget transactions.\n\n3. leiosQuorumStakeThreshold has no upper bound.\nAs written, τ = 1 is permitted. That would stop certification whenever any seated pool fails to vote. I suggest:\n\nLQST-04 (y) leiosQuorumStakeThreshold must be lower than 1.0\nLQST-07 (x - \"should\") leiosQuorumStakeThreshold should not exceed 0.9\nLQST-08 (x - \"should\") leiosQuorumStakeThreshold should not be lower than 0.6\n\nThe CIP notes that a 26% stake attacker can block Leios throughput at a 75% threshold, which is relevant context for choosing the upper bound.\n\n4. Name an emergency off switch for Linear Leios.\nCAP-12 forbids zero for the EB sizes and the committee size, and leaves L_diff's maximum as [PENDING]. As a result, no parameter is clearly able to switch Linear Leios off. The HackMD specification reserves L_diff = 2^32−1 ms to mean \"certification off\". I suggest keeping that as the designated switch and stating its meaning:\n\nLDPL-02 (y) leiosDiffusionPeriodLength must not exceed 4,294,967,295 milliseconds. This value is reserved to mean that certification is disabled.\n\nThat meaning should also be stated in CIP-0164 itself, so that every implementation treats the value in the same way. Separately, L_hdr = 0 should stay forbidden, since it removes the equivocation-detection window. LAPL-01's [PENDING] minimum should be above zero.\n\n5. Add a pipeline bound.\nThe certification pipeline only works if it's short relative to the gaps between blocks. I suggest:\n\nLTP-01 (x - \"should\") 3 × leiosAnnouncementPeriodLength + leiosVotePeriodLength + leiosDiffusionPeriodLength should be well below the expected inter-block time\n\nThis bound is probabilistic. Inter-block times are exponential, so the share of EBs that can be certified falls roughly as e^(−T/20 s), where T is the pipeline length.\n\n6. Two points on the timing constraints.\n\nR3 is implied by R4 (Δreapply < Δapply) and R5 together, so it can be dropped or marked as derived.\nCIP-0164's own feasible values (1 s, 4 s, 7 s) satisfy R5 only if ΔEB_worstcase is below 16 s. The CIP's Table 1 gives 15–20 s. This should be raised on the CIP before the bounds are fixed.\n\n7. Reference-script DoS protection.\n\nThe amendment describes the tiered fee in words. I suggest defining it formally, since guardrails depend on it. The price per byte for the k-th stride is minFeeRefScriptCoinsPerByte × refScriptCostMultiplier^k, applied per transaction.\nBecause the tiering resets for each transaction, an attacker filling a block pays only the base rate. The per-block and per-EB DoS bounds therefore need to be stated against the base rate:\n\nMFRS-03 (x) minFeeRefScriptCoinsPerByte × maxRefScriptSizePerBlock must not be lower than the agreed per-block denial-of-service cost\nMFRS-04 (x) minFeeRefScriptCoinsPerByte × maxRefScriptSizePerEndorserBlock must not be lower than the agreed per-Endorser-Block denial-of-service cost\n\n8. minPoolMargin and MPC-03.\nI agree with the editor, SIPO and Cerkoryn. minPoolMargin needs its own section, and MPC-03 needs amending so that a combined action setting minPoolMargin and reducing minPoolCost to zero is constitutional. I suggest:\n\nMPM-01 (y) minPoolMargin must not be negative\nMPM-02 (y) minPoolMargin must not exceed [PENDING]\nMPM-03 (~ - checkable only if both are changed in the same proposal, \"should\") minPoolMargin and minPoolCost should not both be zero\nMPC-03a (x - \"should\") minPoolCost and minPoolMargin should together be set in line with the economic cost of operating a pool\n\n9. maxPledgeLeverage.\n\nI support SIPO's proposed notice guardrail.\nI'd add a limit on how fast it can change, in the spirit of PPI-04:\n\nMPL-07 (~ - no access to existing parameter values, \"should\") maxPledgeLeverage should not change by more than 25% in a single Parameter Update\n\nPlease also state whether the parameter can be returned to unset once a value has been set. One-way is simpler for the Guardrails Script and avoids encoding \"set to null\" in a Parameter Update.\nMPL-05 is hard to apply as written. Cerkoryn's suggestion to tie it to stakePoolTargetNum is a more concrete basis.\n\n10. Classification.\n\nMRST-05 and MRSB-05 relate two parameters, so the script can only check them when both are in the same proposal. They should be (~), not (y).\nLAPL-05, LVPL-05 and LDPL-05 (\"must be changed together\") can be (y). The script can reject any proposal that changes some, but not all three, of the timing parameters.\nIn answer to the editor's question, (~ - reason) is already a category defined in the ratified Appendix I. Several (x) guardrails here are really (~), including LCS-08, LQST-05 and PTCS-05.\n\n11. Peras grouping.\nThe Peras parameters are listed in the Network group. The HackMD specification expects TechnicalGroup plus SecurityGroup. Please confirm this against the ledger once the Peras parameters land.\n\nNote that we haven't yet reviewed the Peras guardrails.  These seem less urgent than those that are required for Protocol Version 12.\n\nWe're happy to work with the authors on the [PENDING] values, particularly for the Linear Leios timing and committee parameters.\n","author_stake_address":"stake1uy42cc65gdhryw93aezcag9j7k4pv9fxrdx982086yrxy2quecjvx","author_display_name":"Kevin Hammond","created_at":"2026-10-06T17:44:20.165535+00:00","updated_at":"2026-10-07T07:47:59.520097+00:00","moderation_status":"visible","about":"revisions[2]"},{"id":60,"proposal_number":12,"parent_id":null,"body":"@Kevin Hammond\n\n> MPL-04 (~ – no access to existing parameter values) must not change by more than 25% in a single update\n\nLimiting the change by size rather than by frequency is the wrong approach I think. This parameter is very similar to stakePoolTargetNum and should be treated similarly IMHO. I thought there was a guardrail for stakePoolTargetNum about how much time should pass between changes, but I am unable to find it.\n\nIn either case, I think maxPledgeLeverage should take that approach instead. I.e., \"Must not change more often than once every 73 epochs\" or something to that effect.\n\nSource from the IOG blog regarding stakePoolTargetNum (k) that I believe would also apply in this circumstance:\n\nhttps://www.iog.io/news/parameters-and-decentralization-the-way-ahead\n\n```\nIt is worth noting that the k-parameter is not amenable to small, gradual increases (unlike, for example, the d-parameter, which lends itself to a gradual reduction). Each increase in k requires pools and delegators to take action. For pool operators, this means a careful adjustment of their parameters and in particular their margin; for delegators, it means choosing new pools to delegate their ada to, especially if their current choice becomes oversaturated.\n\nTherefore, the best strategy for an upwards adjustment of k is to move in larger, less frequent increments – and to move it as far and as fast as practical network dynamics and economics will allow.\n```","author_stake_address":"stake1uygyajn4dq8smt779tyaf7f8ha2x5veyuehmtd9lvy8kjjqwmde62","author_display_name":"Cerkoryn","created_at":"2026-10-07T21:08:18.302886+00:00","updated_at":"2026-10-07T21:08:18.302893+00:00","moderation_status":"visible","about":null},{"id":61,"proposal_number":12,"parent_id":null,"body":"Following from the above comments, Cerkoryn makes a critical point that if CIP-0023 is intended to allow setting minPoolCost to zero once minPoolMargin is active, leaving MPC-03 unchanged creates an immediate constitutional roadblock for the Constitutional Committee.   \n\nI think the two issues that need addressing in the text before this can work: \nScope of the proposal's diff: The summary currently states that CAP-12 \"adds to the ratified text without changing or removing any existing provision.\" Modifying MPC-03 (or replacing it with MPC-03a, as Kevin Hammond suggests) means this proposal is no longer strictly additive. The author will need to update the diff to explicitly include the modification of MPC-03, rather than leaving it as it is.   \n\nTransition mechanics (MPM-03 and MPC-03a): Kevin Hammond’s suggestion of MPM-03 (minPoolMargin and minPoolCost should not both be zero) addresses the exact failure mode of a zero-fee race to the bottom. Because the Guardrails Script cannot read unchanged ledger parameters on-chain, could MPM-03 be formulated as an atomic requirement for the script? Specifically that the Guardrails Script rejects any Parameter Update that sets minPoolCost = 0 unless minPoolMargin is explicitly included in the same proposal and set to ≥[PENDING].   \nEnforcing this atomically prevents an accidental or malicious governance action from zeroing out minPoolCost before minPoolMargin is active, without requiring the Plutus script to query historical ledger state.  ","author_stake_address":"stake1ux2lyqmpvk6gtz42r569xj89gm8gr9439qqskd57nnw5dwcsz94s3","author_display_name":"Seun","created_at":"2026-10-08T18:48:18.360911+00:00","updated_at":"2026-10-08T18:48:18.360916+00:00","moderation_status":"visible","about":null},{"id":62,"proposal_number":12,"parent_id":null,"body":"In discussing the suggested 25% change cap (MPL-07) there is an edge case in the parameter's initial state that needs clarifying: The first activation cannot be a relative check, because maxPledgeLeverage is introduced unset at Dijkstra genesis, a guardrail restricting changes to a relative percentage (e.g., 25%) cannot evaluate the first update, as there is no prior numerical baseline. \n\nI think the guardrail text needs to distinguish between the initial activation, moving from unset to an initial integer value, which must satisfy absolute bounds (MPL-01 and MPL-02), and the subsequent updates, moving from one set value to another, where a rate-of-change cap or an epoch frequency restriction can apply. \n\nI agree that adjusting pledge leverage forces active responses from both SPOs and delegators. Capping leverage cuts off rewards for stake above L X Pledge. This makes SIPO's suggested MPL-06 (requiring a 90-day off-chain publication and impact analysis) essential, particularly for the first activation, so pools and delegators have sufficient epochs to rebalance stake before financial penalties bite.   \n\nAlso, can the parameter ever be returned to unset once a value is established, or is the transition strictly one-way? This should be clarified in the parameter description.","author_stake_address":"stake1ux2lyqmpvk6gtz42r569xj89gm8gr9439qqskd57nnw5dwcsz94s3","author_display_name":"Seun","created_at":"2026-10-08T18:57:03.870067+00:00","updated_at":"2026-10-08T18:57:03.870071+00:00","moderation_status":"visible","about":null},{"id":63,"proposal_number":12,"parent_id":null,"body":"I updated to the draft, mostly based on the parameters committee round of reviews  and some of the comments above that overlapped with the parameters feedback.\n\nThis draft still has several [PENDING] placeholders. We will incrementally  replace these with sensible values.\n\nHave not yet included changes and proposals from the rest of the comments. This will follow next week. Thank you all for your inputs and patience. \n \n@cerkoryn Please check the current draft MPL-01 and MPL-02  I think I captured the entire range allowed in the CIP.\n As implemented in Ledger, the param can be either null or a non-negative Integer,  with these guardrails it's bounded to null or 1-10,000. Also proposing to deprecate MPC-03 after you correctly noted that leaving it unchanged would effectively prevent it to be set to 0.  For this goal  im proposing an ammendment to \"MPC-03a: Deprecated.\" The constitution does not clearly states how the deprecation of guardrails should work. im guessing this should do the trick. There is a provision that says that a deprecated label is never re-used, so simply deleting MPC-03 would risk it to be reused again. \n\n\n\n","author_stake_address":"stake1uxh5vx8a9svkka2ef372hpytpffwrge4yf3c40nq0lfqa0sejrqru","author_display_name":"carlos lopez de lara","created_at":"2026-10-09T04:34:00.771832+00:00","updated_at":"2026-10-09T04:35:39.995230+00:00","moderation_status":"visible","about":null},{"id":64,"proposal_number":12,"parent_id":63,"body":"Editor notes on v2 and v3.\n\nThis is a strong revision. The Peras naming is consistent, minPoolMargin has its own section, MRST-05 and MRSB-05 are reclassified as (~), the per-EB floors and the LQST bounds from the TSC review are in, and the markdown issues are gone. The Leios section in particular reads far better than v1. The version diff shows what landed, so I'll skip the line by line and flag the handful of things the new draft introduced.\n\n1. **Typo in the Summary.** Your name has ended up in the middle of a word: \"reCarlos Lopez de Lara ference-script protection\". Easy fix.\n\n2. **The proposal now changes ratified text, and still says it doesn't.** The abstract and motivation both still say it \"adds to the ratified text without changing or removing any existing provision\". Since v2 that isn't true: eight of the fourteen revisions replace existing text. Grouped, that's four changes: the Block definition (your text is appended, but the last sentence narrows what \"Block\" means), the MPC-03 line, the minFeeRefScript rename (heading, MFRS-01 to 04 and the two list entries, plus a new MFRS-05), and PRME-02. Seun raised this too. The fix is to drop that claim and describe the modifications. Most of them trace straight to the TSC notes, so that's a short paragraph.\n\n3. **How to deprecate MPC-03.** You said the Constitution doesn't clearly state the convention. It does, under \"Amending, Adding or Deprecating Guardrails\" in Appendix I: \"If the text of a Guardrail is amended, the existing Guardrail will be deprecated and a new label will be used in this Appendix. Similarly, if a Guardrail is deprecated, its label will never be reused in the future.\" And the ratified text shows the practice: wherever a guardrail was amended (PARAM-02a, MBBS-03a, PCM-03a, GD-03a and so on) the new wording sits under the suffixed label and the old label simply disappears. Nowhere does a label carry \"Deprecated\" as its text. So your \"a\" label is right, but \"MPC-03a: Deprecated\" isn't a guardrail, and nothing in the CAP says MPC-03 is retired. Two clean options: put real wording under MPC-03a, for example Kevin's \"minPoolCost and minPoolMargin should together be set in line with the economic cost of operating a pool\", or remove the line and state in the analysis that MPC-03 is deprecated and its label retired. Either works.\n\n4. **The minFeeRefScript rename.** minFeeRefScriptCoinsPerByte becomes minFeeRefScriptCostPerByte across the heading, MFRS-01 to 04 and two list entries, keeping the old labels, and MFRS-05 is new. The Cost spelling is the ledger's actual name, so the correction is right, but it isn't explained anywhere in the CAP, and the TSC notes themselves say amended MFRS guardrails should get \"a\" labels. A sentence in the analysis plus the suffixed labels would do it.\n\n5. **PRME-02a.** This turns poolRetireMaxEpoch's guardrail from a \"should\" into an enforceable \"must\". I can see it comes from the TSC notes, which say the ledger already enforces it. Fine to keep, but since it's the one change here that isn't a Dijkstra parameter, the CAP should say so in a sentence.\n\n6. **perasBootstrapRound has no guardrails now.** v1 had PBR-01 to 03; v3 says \"No guardrail has been proposed yet\". Under PARAM-02a that means the Guardrails Script imposes no constraints on it at all, the same gap SIPO pointed out for minPoolMargin in v1. Restoring PBR-01 (\"when set, must not be negative\") would close it. Related: pinning perasMinCandidateBlockAge and perasCertBoost to single values makes them effectively non-updatable, the security-analysis and change-frequency guardrails for the Peras set were removed, and PQTSM-01 lost its lower bound. That may all be intentional, but it should be said. And Kevin's point about Peras sitting in the Network group rather than Technical plus Security is still open.\n\nOne small question: MEBTS-02 went from (y) \"must not be zero\" to (x) \"must not be lower than [PENDING], except 0 to deactivate\". Once the floor is known that looks checkable, so is (x) just temporary? On the same subject, v3 makes maxEndorserBlockTxsSize = 0 the Linear Leios off switch, where Kevin had proposed a reserved L_diff value. Worth getting the TSC to confirm the chosen switch, since MEBTS-02 and MEBTS-04 now both carry the \"except 0\" carve-out.\n\nEverything else I know is waiting on next week's pass, so I'll hold on those. Nice work on this one.","author_stake_address":"stake1u8dknvrfz38gr8afd0c8vskmz7dkd79gn05gr8mh6ym3cjs7886dj","author_display_name":"Thomas","created_at":"2026-10-09T11:43:50.039313+00:00","updated_at":"2026-10-09T11:43:50.039317+00:00","moderation_status":"visible","about":null},{"id":65,"proposal_number":12,"parent_id":null,"body":"As requested, differences between CAP12 and TSC review.  Further commentary to follow next week.\n\nhttps://hackmd.io/@mnt7hrc0S8OVvDS9XpzlDg/By_do_IjMe","author_stake_address":"stake1uy42cc65gdhryw93aezcag9j7k4pv9fxrdx982086yrxy2quecjvx","author_display_name":"Kevin Hammond","created_at":"2026-10-09T14:53:48.095136+00:00","updated_at":"2026-10-09T14:53:48.095139+00:00","moderation_status":"visible","about":null},{"id":66,"proposal_number":12,"parent_id":null,"body":"v3 designates `maxEndorserBlockTxsSize = 0` as the way to switch Linear Leios off, \"for example in an emergency.\" I think that's a sensible choice (CIP-0164 itself names no off mechanism, and the CAP rules out the alternatives, LCS-02 forbids a zero committee for instance). What I don't think the CAP has reckoned with is what pulling that switch involves under the Constitution it's amending.\n\nThe parameter sits on the Critical Protocol Parameters list. So turning Leios off is a Parameter Update that needs the Constitutional Committee, a DRep vote and an SPO vote with more than 50% of active block production stake (PARAM-03a), and it carries the 90-day notice expectation (PARAM-04a). PARAM-04a can be relaxed for a Severity 1 or 2 network issue, but only \"following careful technical discussion and evaluation,\" and even then the action has to be submitted, voted through by all three bodies, ratified at an epoch boundary and enacted the epoch after. Best case, once the votes are in, that's one to two epochs, call it a week to ten days (Plomin went from ratified to enacted in five days). Realistically a couple of weeks or more, because the first thing that happens in an incident is an argument about whether it's a Severity 1. The Parameter Committee's own notes say as much about a sibling parameter: \"may take several months to change if marked as a critical parameter.\"\n\nTo be fair, that's mostly fine, and the CAP should say why. In most Leios failure modes the chain falls back to Praos on its own: an Endorser Block that isn't certified in time is discarded and the next Block just carries transactions. Where it isn't fine, a node starving Praos of resources or a bug in validation, a parameter can't help anyway; that takes a node release. So the governance switch is really for the case where Leios keeps working and we want it stopped, uniformly and officially. That's an orderly deactivation path, which is valuable, and I'd rather the text described it as that than leaned on \"emergency.\"\n\nThree things I'd like to see:\n\n1. Say what the switch is and what sits underneath it. CIP-0164 makes Endorser Block production optional, makes voting a node-local decision, and leaves rewards untouched, so an operator can stop announcing EBs, stop voting, or decline to include certificates without any vote and without penalty. If committee pools holding roughly a quarter of active stake stop voting, certification halts network-wide. That operational path is the real emergency brake; the parameter change is what makes the stop official and uniform. What I can't find is whether cardano-node actually exposes any of this as a switch. The CAP should state the relationship between the two paths in a sentence or two.\n\n2. Pre-authorise the fast path in the text, so nobody has to litigate it mid-incident. The CAP already borrows the Severity language in LQST-09. Do the same here, using the Constitution's own phrase so it lines up with PARAM-04a: setting maxEndorserBlockTxsSize to 0 in response to a Severity 1 or Severity 2 network issue is exempt from the notice expectation in PARAM-04a. It can't be script-checked, same as LQST-09, but it removes a debate in the bad case and costs nothing in the normal one. (LQST-09 says \"security issue\"; worth aligning that to \"network issue\" too.)\n\n3. On the SPO vote: it isn't optional, every Leios parameter is in the ledger's security group so CIP-1694 requires it, and I wouldn't want it dropped even if it were. The committee that validates and votes on every Endorser Block is the top pools by stake, and as above they can already halt certification by withholding votes. The vote is what turns an operator stop into an official one, not what enables it. Speed should come from pre-agreed procedure, not from cutting them out.\n\nOne housekeeping item: the parameter spec linked under Links & Files (the Dijkstra parameters HackMD) returns 403 for anyone not logged in. It should be public before people are asked to assess bounds derived from it.\n\nNone of this changes a single numeric bound or (y) guardrail. It's about being honest in the text about what the off switch is, and making sure the fast path exists on paper before anyone needs it.","author_stake_address":"stake1u94hxeqaaxz8j0nhtdhz2eamu4ftglvjnv3uqqdqlev9gqgehtqzs","author_display_name":"Pepsi","created_at":"2026-10-14T11:34:39.962617+00:00","updated_at":"2026-10-14T11:34:39.962620+00:00","moderation_status":"visible","about":"revisions[7]"},{"id":67,"proposal_number":12,"parent_id":56,"body":"Good point, Cerkoryn.\n\nI agree that we need to clarify whether CIP-23 is included in Phase 1 or Phase 2 of the Dijkstra hard fork, as this has direct implications for the proposed removal of MPC-03.\n\nhttps://cardanoupgrades.docs.intersectmbo.org/dijkstra-era-upgrade/dijkstra-upgrade-overview\n\nMy understanding is that this is due to be revisited following the Hard Fork Working Group meeting on 13 October. The meeting minutes should help clarify the current position:\n\nhttps://cardanoupgrades.docs.intersectmbo.org/general/hard-fork-working-group-meeting-minutes/13th-october-2026#key-materials\n\nUntil the scope is confirmed, I think we should be careful not to finalize constitutional guardrails that could inadvertently prevent the intended transition from `minPoolCost` to `minPoolMargin`.\n","author_stake_address":"stake1u9dlmtu6y4tregfju8qsn5dx8e9gpzy7mmn9fa4q793z0ksg5lnaq","author_display_name":"Ken Erik Ølmheim (CIVICS)","created_at":"2026-10-15T07:26:34.124914+00:00","updated_at":"2026-10-15T07:26:34.124918+00:00","moderation_status":"visible","about":"revisions[5]"},{"id":68,"proposal_number":12,"parent_id":66,"body":"Thanks, Pepsi.  You have made some good points","author_stake_address":"stake1uy42cc65gdhryw93aezcag9j7k4pv9fxrdx982086yrxy2quecjvx","author_display_name":"Kevin Hammond","created_at":"2026-10-19T13:36:36.953371+00:00","updated_at":"2026-10-19T13:36:36.953375+00:00","moderation_status":"visible","about":"revisions[7]"},{"id":69,"proposal_number":12,"parent_id":null,"body":"Consistency with Existing Guardrails\n\nSome changes to make so the proposal is consistent with the existing guardrails.  See https://docs.google.com/document/d/1c_sEBi12s0F-eYrq7K4eumxgDQBF-0pNKCuC-5OmWeI/edit?usp=sharing\n\nCAP-12 v3 should follow five conventions of the ratified Appendix I more closely. None of these points changes a bound or a (y) check.\n\n1. Sign checks\nThe ratified text includes \"must not be negative\" for every numeric parameter, even where a positive lower bound already implies it (PPI-01 and PPI-03). Where zero is invalid, it adds a separate \"must not be zero\" (SPTN-03/04, CP-03/04). CAP-12 does this for MRST, MRSB, MRSEB, LCS and RSCS, but not here:\nParameter\nMissing guardrail\nleiosQuorumStakeThreshold\nNot negative (it has no sign check at all)\nmaxPledgeLeverage\nNot negative, when set\nAll Peras parameters\nNot negative; also not zero for perasTargetCommitteeSize\nleiosAnnouncementPeriodLength, leiosVotePeriodLength, leiosDiffusionPeriodLength\nNot zero\nmaxEndorserBlockReferencesSize\nNot zero\nmaxEndorserBlockExecutionUnits[memory/steps]\nNot zero\nrefScriptCostMultiplier\nNot zero\n\nminPoolMargin (zero is valid) and maxEndorserBlockTxsSize (zero is the off switch) are correctly excepted.\n\n\n2. Wording\nUse \"must not exceed\" for upper bounds. The Peras guardrails say \"must not be larger than\" (PMCBA-02, PHF-02, PCB-02, PTCS-02).\nKeep strict forms only where the boundary value itself is invalid, as in LQST-01 and LQST-02. Check whether PQTSM-01 \"must be lower than 0.25\" should be \"must not exceed\".\nGive units and equivalents as the ratified text does: \"1,000,000 Bytes (1MB)\", \"12,000,000 Bytes (12MB)\", \"5,000 milliseconds (5 s)\".\nMove the \"so that…\" rationale clauses into the descriptions or the rationale document. They appear in MRST-05, MRST-07, MRST-08, MRSB-05, MRSEB-05, MEBTS-04, MEBEU-M-04, MEBEU-S-04, RSCS-05, RSCM-02, MPM-05 and MFRS-05.\n\n\n3. Markers\nMark the benchmarking guardrails \"(x - unquantifiable)\" and use the ratified wording: \"The impact of any change to … must be confirmed by detailed benchmarking/simulation\" (MBBS-07, MBEU-M-04a).\nUse one form for rate-of-change guardrails: \"in any N-epoch period (approximately N months)\". The draft currently mixes \"single epoch\" (MEBRS-06), \"single governance action\" (MEBTS-07) and \"N-epoch period\".\nMPC-03a: give it real wording or retire the label, as Thomas notes.\n\n\n4. MPL-03\nMPL-03 is acceptable as a permissive (y) guardrail on the model of PARAM-02a. Phrase it as an instruction to the script:\nMPL-03 (y) maxPledgeLeverage may be set to null (unset); the Guardrails Script must accept a null value, and MPL-01 and MPL-02 apply only when a value is set.\nThe notice and frequency guardrails should also cover a change to null, since removing the cap changes rewards as much as setting it.\n\n\n5. Network-group guardrails\nThe Leios and reference-script parameters join the Network group, so the existing group-wide guardrails apply to them. NETWORK-01 allows at most one change to a network parameter per two epochs. NETWORK-02 allows one network parameter per epoch unless they are \"directly correlated\". CAP-12 should state two things:\nThe three Leios timing parameters count as directly correlated, so they can change in the same epoch.\nHow NETWORK-02 interacts with setting maxEndorserBlockTxsSize to 0, including on a Severity 1 or 2 fast path.\n\nKevin Hammond, Chair, Intersect Technical Steering Committee\n","author_stake_address":"stake1uy42cc65gdhryw93aezcag9j7k4pv9fxrdx982086yrxy2quecjvx","author_display_name":"Kevin Hammond","created_at":"2026-10-19T13:46:38.300481+00:00","updated_at":"2026-10-19T13:46:38.300484+00:00","moderation_status":"visible","about":null},{"id":70,"proposal_number":12,"parent_id":63,"body":"For MPC-03, specifically, the best option is probably to replace it with a guardrail such as:\n\nMPC-03a (x - “should”) minPoolCost should be set in conjunction with minPoolMargin. Until the protocol version that activates the minPoolMargin reward calculation, minPoolCost should be set in line with the economic cost of operating a pool.\n\nand\n\nMPM-04 (x - “should”) minPoolMargin should be set in conjunction with minPoolCost, considering both delegator rewards and the economic viability of operating a pool\n\n\nThis works regardless of whether minPoolMargin lands in PV12 or PV","author_stake_address":"stake1uy42cc65gdhryw93aezcag9j7k4pv9fxrdx982086yrxy2quecjvx","author_display_name":"Kevin Hammond","created_at":"2026-10-19T14:58:34.885717+00:00","updated_at":"2026-10-19T14:58:34.885720+00:00","moderation_status":"visible","about":null},{"id":71,"proposal_number":12,"parent_id":66,"body":"@Pepsi, thank you. This is a useful clarification, and I agree with the framing. Calling `maxEndorserBlockTxsSize` = 0 an orderly, official way to deactivate Linear Leios is more accurate than calling it an emergency switch. The CAP should say so, and should state how it relates to the operator-level options you describe.\n\nOn your three points:\n\n1. **Relationship to operator action.** Agreed. One refinement on the numbers: the stake needed to halt certification by withholding votes is the committee's coverage minus the threshold, σ(N_c) − τ. At τ = 0.75 that's roughly 20% of active stake at 95% coverage, rising to 25% only with full coverage. That's consistent with the CIP's 26% example. Whether cardano-node exposes stopping EB announcement or voting as an operator setting is a question for the node team, and the answer should be in the CAP.\n\n2. **Pre-authorised fast path.** I support it, with your wording: setting `maxEndorserBlockTxsSize` to 0 in response to a Severity 1 or Severity 2 network issue is exempt from the notice expectation in PARAM-04a. I agree LQST-09 should say \"network issue\" too. Two additions:\n   - The CAP should say how this interacts with NETWORK-02 (one network parameter per epoch unless directly correlated), so that a deactivation isn't held up by another network change in the same epoch.\n   - The fast path should apply only to switching Linear Leios off. Switching it back on should follow the normal process, including the benchmarking evidence required by MEBTS-05.\n\n3. **SPO vote.** Agreed. It's required anyway, because the parameter is security-relevant, and it's the right check. The note you quote from the TSC review, \"may take several months to change\", referred to the off-chain notice process for critical parameters, which is your point.\n\nOn access to the specification: I agree that the HackMD linked from CAP-12 needs to be publicly readable before reviewers are asked to assess bounds derived from it.  I'd assumed it was intended to be a public document.\n\nKevin Hammond, Chair, Intersect TSC\n","author_stake_address":"stake1uy42cc65gdhryw93aezcag9j7k4pv9fxrdx982086yrxy2quecjvx","author_display_name":"Kevin Hammond","created_at":"2026-10-19T15:14:01.786640+00:00","updated_at":"2026-10-19T15:14:01.786644+00:00","moderation_status":"visible","about":"revisions[7]"},{"id":72,"proposal_number":12,"parent_id":61,"body":"Hi @seun.  Yes, it's essential to make changes to existing guardrails in some cases, so this change can't be purely additive.  Others relate to existing rules on block sizes etc, which will be needed once we have Linear Leios (others might be needed for an eventul full Leios)","author_stake_address":"stake1uy42cc65gdhryw93aezcag9j7k4pv9fxrdx982086yrxy2quecjvx","author_display_name":"Kevin Hammond","created_at":"2026-10-19T15:24:05.092083+00:00","updated_at":"2026-10-19T15:24:05.092088+00:00","moderation_status":"visible","about":null},{"id":73,"proposal_number":12,"parent_id":null,"body":"Peras Parameters\n\nThe Parameter Committee discussed this on October 15.  The recommendation is to separate them into their own amendment.  This is for 4 main reasons:\n\n1. The PV12 changes are more immediate.  \n2. The amendments are quite substantial and merit proper attention.\n3. It allows them to be considered properly in their own forum\n4. Until there is experience with a merged implementation, it is possible that performance or other interactions could arise - having a specific amendment allows these to be ironed out if necessary after the PV12 amendment\n\nI'd expect the Peras guardrails to be relatively easy to define, since the implementation is now quite mature, even if it hasn't yet been deployed to Preview for example","author_stake_address":"stake1uy42cc65gdhryw93aezcag9j7k4pv9fxrdx982086yrxy2quecjvx","author_display_name":"Kevin Hammond","created_at":"2026-10-19T15:34:09.622800+00:00","updated_at":"2026-10-19T15:34:09.622803+00:00","moderation_status":"visible","about":null},{"id":74,"proposal_number":12,"parent_id":null,"body":"maxPledgeLeverage\n\nOn maxPledgeLeverage, I suggest consulting @Cerkoryn, as the CIP-0050 author, before these guardrails are finalised. The TSC review’s guardrails reflect our understanding of his position:\n\n1. a maximum of 500, not 10,000;\n2. a first non-null value of 500, then gradual tightening;\n3. joint bounds with poolPledgeInfluence: if poolPledgeInfluence > 0.5, maxPledgeLeverage must not be lower than 50; if poolPledgeInfluence = 0, maxPledgeLeverage must not exceed 100.\n\nCAP-12 v3 instead allows the full 1–10,000 range given in CIP-0050, places no constraint on the first value, and refers to poolPledgeInfluence only through the “should” in MPL-04. Ryan’s confirmation of the intended bounds, the starting value and the poolPledgeInfluence interaction would settle which set the Constitution should carry.","author_stake_address":"stake1uy42cc65gdhryw93aezcag9j7k4pv9fxrdx982086yrxy2quecjvx","author_display_name":"Kevin Hammond","created_at":"2026-10-19T15:54:47.439023+00:00","updated_at":"2026-10-19T15:54:47.439026+00:00","moderation_status":"visible","about":null},{"id":75,"proposal_number":12,"parent_id":62,"body":"Hi @seun, thanks. These are good points.\n\nFirst activation. Agreed: a percentage cap can’t apply when the parameter moves from unset to its first value. I’m withdrawing the 25% rule (MPL-07). In its place, changes to maxPledgeLeverage should be limited by frequency, to no more than one change in any 36-epoch period (36 is consistent with TC-05 and ME-05 which seems reasonable). The first setting, and any lowering, should be treated separately, with at least 18 epochs’ notice (MPL-05) so that pools and delegators have time to rebalance before rewards are affected.\n\nReturning to unset. CAP-12 v3 allows this. I think that’s acceptable, provided the same notice and frequency limits apply, and the parameter description should say so explicitly\n","author_stake_address":"stake1uy42cc65gdhryw93aezcag9j7k4pv9fxrdx982086yrxy2quecjvx","author_display_name":"Kevin Hammond","created_at":"2026-10-19T16:06:47.401276+00:00","updated_at":"2026-10-19T16:06:47.401279+00:00","moderation_status":"visible","about":null},{"id":76,"proposal_number":12,"parent_id":61,"body":"On your atomic check for MPM-05: the Guardrails Script can check both values **when they appear in the same action**. However, that doesn’t stop a near-zero value (for example minPoolCost = 1 lovelace), or a later action that changes only minPoolMargin, because the script can’t see the value of the other parameter. Before PV13, minPoolMargin also has no effect on rewards, so setting it doesn’t protect anything. MPM-05 therefore has to remain a “should”, backed by the pre-activation clause in MPC-03a.","author_stake_address":"stake1uy42cc65gdhryw93aezcag9j7k4pv9fxrdx982086yrxy2quecjvx","author_display_name":"Kevin Hammond","created_at":"2026-10-19T16:09:17.336423+00:00","updated_at":"2026-10-19T16:09:17.336427+00:00","moderation_status":"visible","about":null},{"id":77,"proposal_number":12,"parent_id":null,"body":"Also passed on to the Hard Fork Working Group\n\nGuardrails Script: versions and definition of done\n\nIt’s good that work on the guardrails script has started early. To avoid confusion while the CAP-12 text and values are still changing, I suggest that each script version state clearly what it is, and that we agree now what “done” means.\n\nEach script version should state:\n\n1. the CAP-12 revision and node version it implements;\n2. which (y) guardrails it enforces, and which use placeholder values for [PENDING] bounds;\n3. its tests, including null, 0 and boundary values (for example a null maxPledgeLeverage, and maxEndorserBlockTxsSize = 0 under MEBTS-02/04).\n\nProposed definition of done. The script is final when:\n\n1. CAP-12’s guardrail text is final, with no [PENDING] items;\n2. the values are confirmed by benchmarks on the production 12.x node, or on the final 11.x node promoted to 12x without any performance-impacting changes, as confirmed by the performance team;\n3. the script enforces exactly the (y) guardrails in the final text, each implemented and tested, with no additional checks and none missing;\n4. the script has passed security review and audit;\n5. its hash matches the one in the constitution governance action.\n\nUntil then, each version is a draft for review and testing, and nobody should read it as the agreed guardrails.\n\nTwo consequences of exact scope:\n\n1. If a (~) guardrail becomes checkable, for example one comparing two parameters changed in the same action, the constitution text must relabel it (y) before the script enforces it.\n2. The (y)/(x) markers in the final text then act as the script’s specification. MEBTS-02, for instance, is a numeric bound marked (x) and should be (y).","author_stake_address":"stake1uy42cc65gdhryw93aezcag9j7k4pv9fxrdx982086yrxy2quecjvx","author_display_name":"Kevin Hammond","created_at":"2026-10-19T17:03:30.279069+00:00","updated_at":"2026-10-19T17:03:30.279072+00:00","moderation_status":"visible","about":null},{"id":78,"proposal_number":12,"parent_id":null,"body":"**CAP-12 v4: what changed since v3**\n\nThank you all for the reviews. This summarises the changes in v4, grouped by topic, with the reviewers whose comments each group answers.\n\n**1. Peras moves to its own amendment** (Kevin, Parameter Committee)\n\nAll Peras definitions, list entries and guardrails are removed. The Peras points raised in review go to the separate amendment.\n\n**2. minPoolCost and minPoolMargin** (Cerkoryn, Ken, Seun, Thomas, Kevin)\n\n- MPC-03a now has real wording, the text Kevin suggested: \"*minPoolCost* should be set in conjunction with *minPoolMargin*. Until the protocol version that activates the *minPoolMargin* reward calculation, *minPoolCost* should be set in line with the economic cost of operating a pool.\"\n- *minPoolMargin* is fully implemented at the Dijkstra hard fork. It is introduced at 0, and a later Parameter Update sets its initial value.\n\n**3. maxPledgeLeverage** (SIPO, Cerkoryn, Seun, Kevin)\n\n- MPL-03 uses Kevin's wording: a null value is accepted, and the bounds apply only when a value is set.\n- MPL-04: \"should be set in conjunction with *stakePoolTargetNum* and the prevailing *poolPledgeInfluence*\".\n- MPL-05: a change that first sets, lowers or unsets the parameter needs 18 epochs' notice and an analysis of the delegated stake that would lose reward eligibility.\n- New MPL-06: at most one change in any 36-epoch period.\n\n**4. Switching Linear Leios off** (Pepsi, Kevin)\n\n- The \"emergency\" framing is removed from the *maxEndorserBlockTxsSize* description.\n- New MEBRS-07, a fast path: setting *maxEndorserBlockReferencesSize* to 0 in response to a Severity 1 or Severity 2 network issue is exempt from the PARAM-04a notice. Switching back on follows the normal process.\n- LQST-09 now says \"network issue\", matching PARAM-04a.\n\n**5. NETWORK-02 becomes NETWORK-02a** (Kevin)\n\nAll nine Leios parameters are in the network group, which allows only one change per epoch. NETWORK-02a adds that the Leios parameters are directly correlated and may change together in one epoch when detailed benchmarking/simulation confirms the combined change.\n\n**6. Reference scripts** (Thomas, Kevin)\n\n- After the rename to *minFeeRefScriptCostPerByte*, MFRS-01 to 04 become MFRS-01a to 04a, as Appendix I requires for amended text.\n- New MFRS-06 and MFRS-07 state the per-block and per-Endorser-Block denial-of-service cost against the base rate.\n\n**7. Consistency with the ratified Appendix I** (Kevin)\n\n- Sign checks are added (not negative, not zero) where the ratified convention calls for them.\n- Benchmarking guardrails are marked (x - \"unquantifiable\") and say \"detailed benchmarking/simulation\".\n- Units and rate-of-change limits use the ratified forms.\n- \"So that\" rationale clauses are moved from the guardrails into the parameter descriptions.\n\n**8. Precision and alignment with CIP-0164**\n\n- The undefined terms \"reference hardware\" and \"mainnet-representative topology\" are removed.\n- Endorser Block guardrails now use the CIP's voting window (3 × L_hdr + L_vote) by referring to LLS-01, instead of the voting period alone.\n- The Endorser Block reapplication constraint is stated in the CIP's own words.\n- \"Stage length\", a Full Leios term, is replaced.\n\n**9. Summary fields and exhibits** (Thomas, Seun, SIPO, Pepsi)\n\n- The \"purely additive\" claim is removed. The analysis lists the five existing provisions that change: the Block definition, MPC-03a, the MFRS rename, NETWORK-02a and PRME-02a.\n- The analysis now explains why ratifying before the hard fork enables a measured Leios rollout, and sets measurable success criteria.\n- The exhibit HackMD is public, and CIP and ledger links are added.\n- CAP-12 stays limited to the new Dijkstra parameters and the minimal changes they require, so its relation to CAP-10 is out of scope.\n\n**Still open**: the [PENDING] values, the *maxPledgeLeverage* range and first value (Cerkoryn), TSC confirmation of the off switch, and Guardrails Script versioning (Kevin).\n","author_stake_address":"stake1uxh5vx8a9svkka2ef372hpytpffwrge4yf3c40nq0lfqa0sejrqru","author_display_name":"carlos lopez de lara","created_at":"2026-10-21T09:35:11.408678+00:00","updated_at":"2026-10-21T09:41:48.166743+00:00","moderation_status":"visible","about":null},{"id":79,"proposal_number":12,"parent_id":78,"body":"Editor notes on v4.\n\nThe additive claim is gone and the analysis lists what actually changes, MPC-03a has real wording, the MFRS rename now follows the labelling convention, Peras is out pending its own amendment, the sign checks and ratified phrasing are in, LQST-09 matches PARAM-04a, the spec is public and the exhibits are properly sourced. Nearly everything from the two review rounds has been taken. Three things from my side.\n\n1. **The fast path is attached to the wrong parameter.** The off switch is maxEndorserBlockTxsSize = 0. Your own MEBTS description says so, MEBTS-02 and MEBTS-04 carve out zero for it, and the spec is explicit that maxEndorserBlockReferencesSize is not given that role and must stay positive. But the new fast-path guardrail is MEBRS-07, on maxEndorserBlockReferencesSize, and MEBRS-02 has picked up a matching zero carve-out. As written, the actual switch has no fast path, and a parameter that must stay positive has one. Looks like a MEBTS/MEBRS slip carried through, since the summary comment says the same. The fix is mechanical: move the guardrail to MEBTS (MEBTS-09), point the \"switching back on\" clause at MEBTS-05 instead of MEBRS-05, and take the zero carve-out back out of MEBRS-02.\n\n2. **The off switch still needs its description.** v4 removed \"for example in an emergency\", which is right, but didn't put anything in its place. Pepsi's first point, which Kevin agreed with, was to say what the switch is: an orderly, official way to deactivate Linear Leios, how it relates to what operators can do on their own (stop announcing Endorser Blocks, stop voting), and whether the node exposes any of that as a setting. A short paragraph under maxEndorserBlockTxsSize would close it.\n\n3. **Two small ones.** MEBTS-02 is a numeric bound marked (x); once the floor is set it should be (y), as Kevin noted. And MPC-03a says \"until the protocol version that activates the minPoolMargin reward calculation\" while the description now says it's fully implemented at Dijkstra. Kevin's wording works either way, so not wrong, but once the Phase 1 or 2 question is settled it's worth making the two read the same.\n\nEverything else looks settled from the editor side. The maxPledgeLeverage range and first value, and the [PENDING] numbers, are for the TSC and Cerkoryn to close. Nice work on this one.","author_stake_address":"stake1u8dknvrfz38gr8afd0c8vskmz7dkd79gn05gr8mh6ym3cjs7886dj","author_display_name":"Thomas","created_at":"2026-10-21T16:47:15.364020+00:00","updated_at":"2026-10-21T16:47:15.364026+00:00","moderation_status":"visible","about":null},{"id":81,"proposal_number":12,"parent_id":79,"body":"Thanks Thomas, agreed on all three, and two related points from my earlier consistency check that v4 hasn't yet picked up. I also have some more substantive comments, which I'll post as soon as possible (unfortunately I won't have access to this wallet for a few days, but there will be time to address them).\n\n1. You're right that the fast path is on the wrong parameter. The off switch is maxEndorserBlockTxsSize = 0. I suggest we move MEBRS-07 to MEBTS-09 unchanged apart from the parameter name, point the \"switching back on\" clause at MEBTS-05, and remove the zero carve-out from MEBRS-02. Carlos's v4 summary should be corrected to match.\n\n2. Suggested description under maxEndorserBlockTxsSize: \"Setting maxEndorserBlockTxsSize to 0 provides an orderly, on-chain way to deactivate Linear Leios endorsement without a hard fork. When set to 0, Endorser Blocks carry no transactions and ranking blocks continue to be produced as in Praos. This is the official deactivation path. It is distinct from, and does not depend on, individual operators choosing to stop announcing Endorser Blocks or voting.\" On whether the node exposes those operator actions as settings, I'd rather the Leios team confirm than we assert it in the text. Carlos, could you check with them?\n\n3. On MEBTS-02, I agree it should be (y). I'd also separate the off switch from the bound, so that it is a rule in its own right:\n\nMEBTS-02 (y) *maxEndorserBlockTxsSize*, when not 0, must not be lower than [PENDING] Bytes.\n\nMEBTS-10 (y) *maxEndorserBlockTxsSize* may be set to 0. A value of 0 deactivates Linear Leios endorsement (see MEBTS-09).\n\nMEBTS-04 would then read: \"*maxEndorserBlockTxsSize*, when not 0, must not be lower than *maxTxSize*\" (still ~). Each rule then does one thing, the script check is simply \"0, or at least the floor\", and the fast path in MEBTS-09 has a clear rule to refer to.\n\n4. Once the zero carve-out is removed from MEBRS-02, maxEndorserBlockReferencesSize needs the \"must not be zero\" sign check from Appendix I, in line with the other Leios size parameters: \"MEBRS-XX (y) *maxEndorserBlockReferencesSize* must not be zero.\"\n\n5. Nothing yet says how the off switch interacts with the network-group frequency limit or NETWORK-02a. If Linear Leios has to be switched off soon after another network-group change, the frequency limit could block exactly the change we most need. Suggested wording: \"NETWORK-XX (x) A change that sets *maxEndorserBlockTxsSize* to 0 under MEBTS-09 may be made in any epoch, notwithstanding [ratified frequency rule], and need not be accompanied by changes to other Linear Leios parameters. A change that sets it back to a non-zero value is subject to the normal network-group limits.\"\n\nOn MPC-03a: CIP-23 is now confirmed in full Dijkstra scope (HFWG, 20 Oct), so the \"until the protocol version that activates…\" clause in my earlier wording no longer reflects the plan. I suggest tying it to the value rather than the protocol version: \"minPoolCost should be set in conjunction with minPoolMargin. Until minPoolMargin is set to a non-zero value, minPoolCost should be set in line with the economic cost of operating a pool.\" That matches the description (introduced at 0, first real value set later) and still holds if the scope changes again.\n","author_stake_address":"stake1uy42cc65gdhryw93aezcag9j7k4pv9fxrdx982086yrxy2quecjvx","author_display_name":"Kevin Hammond","created_at":"2026-10-22T14:15:02.905508+00:00","updated_at":"2026-10-22T14:15:02.905512+00:00","moderation_status":"visible","about":null},{"id":82,"proposal_number":12,"parent_id":78,"body":"Thanks Carlos, v4 is a big step forward, and thanks for taking the Peras split on board.\n\n**Off switch:** I'll take the off switch to the TSC at our next meeting on 28 October and report back here.\n\n**Guardrails Script versioning:** I've sent a proposal to the Hard Fork Working Group and posted it here: version labels for the script tied to the CAP-12 revision they implement, a definition of done, and a rule for relabelling (~) guardrails once they become checkable. Two points for whoever writes the script: MPL-03 requires accepting null for maxPledgeLeverage, and MEBTS-02/MEBTS-10 need the \"0, or at least the floor\" check. Both should be tested explicitly as part of the same check.\n\n**Consistency with Appendix I:** I've checked v4 against my earlier consistency list. Most points are done, thank you. These remain:\n>\n1. maxEndorserBlockReferencesSize has no \"must not be zero\" rule (see point 4 of my reply to Thomas).\n\n2. Nothing covers how setting maxEndorserBlockTxsSize to 0 interacts with the network-group limits or NETWORK-02a (see point 5 of my reply to Thomas).\n\n3. LQST-01/02 (and LQST-05) use strict \"lower than\"/\"greater than\" forms. I'm not sure the Guardrails Script supports strict comparisons, as opposed to inclusive bounds and \"not equal\". Could you or the script team share a link to the current Guardrails Script source, so we can check how these would be implemented and whether they need rewording?\n\n4. Units are not yet in the ratified style everywhere. MEBRS-03 has \"1,000,000 bytes (1MB)\", which should be \"Bytes\". LAPL-02 has \"(5 seconds)\", which should be \"(5 s)\". MFRS-01a's \"1,000 (0.001 ada)\" has no unit word.\n\n5. Some \"so that\" clauses remain inside guardrails: MEBTS-08, MEBEU-M-06/08, MEBEU-S-06/08 and MPL-05. Please move them into the descriptions.\n\n6. Benchmarking wording: LCS-05 says \"must be shown by\". It should be \"must be confirmed by detailed benchmarking/simulation\". MFRS-04a has no benchmarking wording but should probably follow the same form.\n\n 7. Rate-of-change wording: when the [PENDING] periods are filled in (MEBRS-06, MEBTS-07, MRSEB-07, MEBEU-M-07, MEBEU-S-07, MRSB-07, MRST-10), please use the full \"in any N-epoch period (approximately N months)\" form.\n\n8. maxPledgeLeverage transitions to null: MPL-05's notice for unsetting is only a \"should\", and MPL-06 says \"changed\" without saying that unsetting counts. Suggest MPL-06 read \"must not be changed, including set to or from null, more than once in any 36-epoch period\".\n\n**maxPledgeLeverage:** the 1 to 10,000 range looks fine to me, but we still need a first value and Cerkoryn's view on how it interacts with poolPledgeInfluence, which I asked about earlier. @Cerkoryn, could you comment before Friday's call if possible?\n\n**[PENDING] values:** about 30 are still open, and benchmarking will drive most of them. As you resolve them, please send the proposed values to the Parameter Committee for review before they go into the proposal text, and please treat any values here as provisional. A rough timetable would also help us plan.\n","author_stake_address":"stake1uy42cc65gdhryw93aezcag9j7k4pv9fxrdx982086yrxy2quecjvx","author_display_name":"Kevin Hammond","created_at":"2026-10-22T14:29:27.666425+00:00","updated_at":"2026-10-22T14:29:27.666429+00:00","moderation_status":"visible","about":null},{"id":83,"proposal_number":12,"parent_id":null,"body":"Here are the more substantive comments that I promised. \n\nFollow-up on v4: TSC discussion and remaining substantive points\n\nOff switch: TSC discussion (28 October). The TSC discussed the Linear Leios off switch at its meeting on 28 October. The meeting was not quorate, so there is no formal TSC position. The discussion suggested that some form of off switch is needed or useful, but there was no agreement yet on what form it should take. I’ll report back once the TSC has reached a view. In the meantime, the editorial fixes already discussed (moving the fast path to MEBTS-09, and the MEBTS-02/MEBTS-10 split) still apply to whatever form is chosen.\n\n1. The off switch is caught by the benchmarking rule. MEBTS-05 requires any change to maxEndorserBlockTxsSize to be confirmed by detailed benchmarking/simulation, so setting it to 0 would need benchmarking first. Suggested wording: “Any change to maxEndorserBlockTxsSize, other than setting it to 0 under MEBTS-09, must be confirmed by detailed benchmarking/simulation demonstrating: …”\n\n2. minPoolMargin. CIP-0023 is now in full Dijkstra scope, so the first value of minPoolMargin, and any increase, changes delegator rewards immediately. Unlike maxPledgeLeverage, it has no notice or frequency guardrail. Suggested additions:\n\n- MPM-06 (x - “should”) A change that first sets or increases minPoolMargin should be announced at least 18 epochs (approximately 3 months) in advance, together with an analysis of the effect on pool and delegator rewards.\n\n- MPM-07 (~ - no access to change history) minPoolMargin must not be changed more than once in any 36-epoch period (approximately 6 months).\n\n- MPM-04 still has the earlier wording. As posted on 19 October, I suggest: “minPoolMargin should be set in conjunction with minPoolCost, considering both delegator rewards and the economic viability of operating a pool.”\n\n3. leiosCommitteeSize has no upper bound. It has non-negative, non-zero and lower-bound guardrails, but no maximum, so vote traffic is limited only by LCS-05, which is (x). Suggested addition: “LCS-09 (y) leiosCommitteeSize must not exceed [PENDING] (seats).” The TSC review suggested 1000.\n\n4. Quantities that (x) guardrails depend on need an owner. Several guardrails refer to figures that aren’t defined anywhere:\n\n- MFRS-06/07: the “agreed” per-block and per-Endorser-Block denial-of-service cost\n- LLS-01/02: the Endorser Block diffusion and transmission times\n- LQST-06: the adversarial stake the protocol tolerates\n- MRSB-06 and MRST-09: the “processing constraints of nodes”\n\nAs written, nobody can check these guardrails, because there is no figure to check against. I suggest a short paragraph saying that the Parameter Committee publishes the current figure for each, with its benchmarking/simulation basis, and that each Parameter Update cites the version it relied on. For reference scripts, this should include a time budget: the worst-case time to resolve and deserialise the maximum reference-script bytes for a Block (or Endorser Block) must fit within an agreed share of validation time.\nThe alternative would be to embed agreed values within the text of the constitution?\n\n5. The reference-script fee has no real floor. MFRS-05 says only “must not be zero”, so 1 lovelace per byte passes, which is the same near-zero gap as in MPM-05. A (y) minimum would give MFRS-06/07 an enforceable backstop: “MFRS-08 (y) minFeeRefScriptCostPerByte must not be lower than [PENDING].”\n\n6. Benchmarking and Reverting Changes (definitions in Appendix I, section 1). These need amending for Linear Leios:\n\n- Benchmarking is currently defined only by Block diffusion (95% of blocks within 5 s). The Linear Leios guardrails depend on further timing properties: Endorser Blocks validated within the voting window (LLS-01), certified Endorser Blocks reaching honest nodes in time (LLS-02), and Block diffusion not degraded by Endorser Block traffic. Suggested addition: “Where Ouroboros Linear Leios is active, Benchmarking must also show that Endorser Block diffusion and validation, and certified Endorser Block transmission, meet the timing requirements in LLS-01 and LLS-02, without degrading Block diffusion.”\n\n- Reverting Changes requires reverting a change “to its previous state if that is possible”. Several new guardrails could prevent that. Under MPL-06 (and the proposed MPM-07), a harmful first setting couldn’t be reverted for 36 epochs. NETWORK-02a could stop a Linear Leios parameter being reverted in the epoch it is needed. MPL-05’s notice period would also apply to a reversion. Suggested addition: “A Parameter Update that only reverts a parameter to its previous value under this provision is exempt from frequency and notice guardrails on that parameter, but must be accompanied by the performance monitoring evidence that requires it.” Where the previous state was null, the reversion should be able to return the parameter to null (see point 7).\n\n7. Null (unset) parameters. maxPledgeLeverage is the first protocol parameter that can be set to null by a “Parameter Update” action, and perasBootstrapRound will follow in the Peras amendment. The Constitution doesn’t yet recognise this. A general rule in section 2 would make the treatment explicit and consistent:\n\n- PARAM-XX (y) Where the ledger allows a protocol parameter to be set to null (unset), its guardrails must state whether a “Parameter Update” action may set it to null. If they don’t, the Guardrails Script must reject the action. Guardrails that bound the parameter’s value apply only when a value is set. Setting a parameter to null, or from null to a value, counts as a change for all notice and frequency guardrails.\nFor maxPledgeLeverage, MPL-03 already allows null, so the rule changes nothing there. It sets the default for any future nullable parameter.\n\nTwo related requests:\n\n- The CAP, or the Guardrails Script specification, should state how a null value is encoded in a Parameter Update as the script receives it, with a reference to the Dijkstra CDDL. The script should then check for null explicitly, and be tested on both an accepted null (MPL-03) and a rejected one.\n\n- The Definitions should include a short entry for “unset (null)“.\n\nOther points for a later amendment. The TSC review also raised Tenet 1 (whether transactions waiting for Endorser Blocks under sustained load are “slowed down”) and Tenet 8 and section 6.3 on long-term sustainability. These aren’t necessarily needed for CAP-12, but I’m noting them so they aren’t lost.\n\nAlso the Parameter Committee should see and discuss all [PENDING] values with evidence, and final parameters (and any restrictive guardrails that relate to performance) should be set based on the production node (to avoid having to recall the constitution if the guardrails are shown to be incorrect).","author_stake_address":"stake1uy42cc65gdhryw93aezcag9j7k4pv9fxrdx982086yrxy2quecjvx","author_display_name":"Kevin Hammond","created_at":"2026-10-29T17:58:04.844326+00:00","updated_at":"2026-10-29T17:58:04.844334+00:00","moderation_status":"visible","about":null},{"id":84,"proposal_number":12,"parent_id":null,"body":"On “so that” clauses. The reasons behind the guardrails matter, and the CC should have them. I’d put them in the parameter descriptions (and the Guardrails Rationale document), not in the guardrails themselves, in line with the ratified Appendix I. Inside a guardrail, a “so that” can read as a condition, which would make it unclear what is actually required. That matters most for (y) guardrails, whose text is effectively the script’s specification.\n\nFor example, MPL-05 would become: “A change that first sets, lowers or unsets maxPledgeLeverage should be announced at least 18 epochs (approximately 3 months) in advance, together with an analysis of the delegated stake that would lose reward eligibility.” The description would then say why: “so that pool operators and delegators can rebalance before rewards are affected.” The required analysis stays in the guardrail, and only the purpose moves to the description.","author_stake_address":"stake1uy42cc65gdhryw93aezcag9j7k4pv9fxrdx982086yrxy2quecjvx","author_display_name":"Kevin Hammond","created_at":"2026-10-29T17:59:49.400423+00:00","updated_at":"2026-10-29T17:59:49.400427+00:00","moderation_status":"visible","about":null},{"id":85,"proposal_number":12,"parent_id":null,"body":"**CAP-12 v5: what changed since v4**\n\nCAP-12 adds the protocol parameters that the Dijkstra hard fork makes governable (Leios, reference scripts, pool economics) to Appendix I of the Constitution, each with guardrails, and makes the few changes to existing provisions they require. v5 answers the reviews of v4. It settles the structure of the guardrails first; their numeric values go to the Parameter Committee for review and are filled in once validated. Until then, v5 shows [PENDING] wherever a value is still to be agreed.\n\nGuardrail labels combine a parameter abbreviation and a number (MEBTS-07 is the seventh guardrail on *maxEndorserBlockTxsSize*). The marker says how a guardrail is enforced: (y) by the Guardrails Script, (x) by the Constitutional Committee's judgement, (~) not checkable by the script. \"Block\" means a Praos block, also called a Ranking Block; an Endorser Block is the additional block the Leios protocol adds, certified by votes of a committee of Stake Pools (the Leios Committee).\n\n**1. Leios parameters cannot be set to zero** (Pepsi, Kevin, Thomas)\n\nMEBRS-07 and new MEBTS-09 (y) now say that *maxEndorserBlockReferencesSize* and *maxEndorserBlockTxsSize* must not be zero, as the other Leios parameters already did. The \"except when set to 0\" exceptions are removed from MEBRS-02, MEBTS-02 and MEBTS-04, and the *maxEndorserBlockTxsSize* description no longer describes a setting of 0.\n\nShould Leios ever need to be deactivated temporarily, a contingency plan in the spirit of the Disaster Recovery Plan for Cardano networks (CIP-0135) is the desirable route, outside the Constitution, rather than a parameter setting.\n\n**2. Values: reviewed by the Parameter Committee before they enter the text** (Kevin)\n\nSix guardrails had a value in v4 and now show [PENDING]:\n\n| Guardrail | v4 |\n|---|---|\n| MEBRS-03 | must not exceed 1,000,000 bytes (1MB) |\n| MEBTS-03 | must not exceed 12,000,000 bytes (12MB) |\n| LAPL-02 | must not exceed 5,000 milliseconds (5 seconds) |\n| LVPL-02 | must not exceed 20,000 milliseconds (20 seconds) |\n| LQST-03 | should not be lower than 0.6 (60%) |\n| LQST-04 | should not exceed 0.9 (90%) |\n\nThe other numeric bounds were already [PENDING] in v4 and go to the Committee in the same way.\n\nGuardrail bounds and initial settings need different evidence. The initial settings are what the network runs from the hard fork, so they must be fully benchmarked on the node release that carries it; under the rollout plan they sit well below the bounds. The bounds set the room that later Parameter Updates may use. They come from analysis of what the protocol can support, not from what one node release achieves: some values beyond today's measurements become reachable through software improvements alone, such as an optimisation in the networking stack. The evidence that a particular new value is safe is required when that value is proposed, since every increase must be confirmed by detailed benchmarking/simulation.\n\n**3. Endorser Block limits** (Kevin, Thomas)\n\n- *Floors.* An Endorser Block can always carry at least what a Block can. MEBTS-02, MEBEU-M-02, MEBEU-S-02 and MRSEB-04 now tie each Endorser Block limit to the matching Block limit (for example, *maxEndorserBlockTxsSize* must not be lower than *maxBlockBodySize*) instead of a [PENDING] number. NETWORK-02a lets a Leios limit and the Block limit that sets its floor change in the same epoch.\n- *Rate of change.* MEBRS-06, MEBTS-07, MRSEB-07, MEBEU-M-07 and MEBEU-S-07 now read \"should be changed by at most X per epoch (5 days)\", the form of the ratified MBBS-05 for *maxBlockBodySize*, instead of a percentage over a [PENDING] number of epochs. A fixed amount does not compound, and how often steps follow is left to NETWORK-01 and the governance process.\n- *Decreases.* New MEBRS-08, MEBTS-10, MRSEB-08, MEBEU-M-10 and MEBEU-S-10 copy the ratified MBBS-03a: no decrease \"other than in exceptional circumstances where there are potential problems with security, performance, functionality or long-term sustainability\".\n\n**4. Leios timing, committee and benchmarking** (Kevin)\n\n- LLS-03 is now a \"must\": 3 × *leiosAnnouncementPeriodLength* + *leiosVotePeriodLength* + *leiosDiffusionPeriodLength*, rounded up to whole slots, must be lower than the expected number of slots between Blocks (19 seconds at today's settings). The longer the total, the larger the share of Blocks produced before a certificate can be included.\n- New LCS-09 (y) gives *leiosCommitteeSize* an upper bound ([PENDING]). LCS-05 now reads \"The impact of any increase to *leiosCommitteeSize* must be confirmed by detailed benchmarking/simulation, to show that the resulting vote traffic per Endorser Block still diffuses within *leiosVotePeriodLength*\".\n- The Benchmarking definition now ends: \"Where the Leios protocol is active, Benchmarking must also show that Endorser Block diffusion and validation, and certified Endorser Block transmission, meet the timing requirements in LLS-01 and LLS-02, without degrading Block diffusion.\"\n\n**5. Reference scripts and their fee** (Kevin)\n\n- MRSB-07 now reads \"should be changed by at most [PENDING] bytes per epoch (5 days)\", like its Endorser Block counterpart. MRST-10 follows the ratified MTS-05 for *maxTxSize*: \"should not be increased by more than [PENDING] bytes in any epoch\".\n- New MFRS-08 (y): *minFeeRefScriptCostPerByte* must not be lower than [PENDING]. Once the reference-script size limits are governable, this base fee is what protects against denial-of-service attacks, and \"must not be zero\" (MFRS-05) still lets 1 lovelace per byte through.\n- MFRS-06 and MFRS-07 now compare against the denial-of-service cost \"established by detailed benchmarking/simulation\" instead of an \"agreed\" cost that nobody is charged with agreeing.\n\n**6. Pool economics** (Kevin, Thomas)\n\n- *minPoolMargin*: new MPM-06 asks for 18 epochs' notice and an analysis of the effect on rewards before any increase; new MPM-07 allows at most one change in any 36-epoch period, like *maxPledgeLeverage* and the ratified *treasuryCut* and *monetaryExpansion*. MPM-04 now says it \"should be set in conjunction with *minPoolCost*\", matching MPC-03a.\n- MPC-03a's second sentence now reads \"Until *minPoolMargin* is set above 0, *minPoolCost* should be set in line with the economic cost of operating a pool.\"\n- *maxPledgeLeverage*: MPL-06 now counts setting it from null as a change, so null cannot be used to get around its one-change-per-36-epochs limit.\n\n**7. Reverting Changes; unset (null) defined** (Kevin)\n\nThe new notice and frequency guardrails must not stop a harmful change being undone. One provision grants that exception, and the others refer to it:\n\n- *Reverting Changes* (definitions) now ends: \"A Parameter Update that only reverts a parameter to its previous value, including returning it to null where it was previously unset, is exempt from frequency and notice guardrails that apply to that parameter when the change being reverted has caused problems with security, performance, functionality or long-term sustainability. It must be accompanied by monitoring evidence or supporting analysis of those problems, and of why reverting the change is the better course.\" The four headings match the ratified section 2.6 on reverting parameter changes.\n- New PARAM-07 (y) sets the rule for parameters that can be unset (null), *maxPledgeLeverage* being the first: each parameter's guardrails must say whether null is allowed (if they don't, the Guardrails Script rejects it), value bounds apply only when a value is set, and setting to or from null counts as a change, \"except for a reversion under Reverting Changes (section 1)\".\n- The *Protocol Parameters* definition now adds: \"Some protocol parameters may be unset (null), meaning they have no value; what that means for a parameter is given in its description.\"\n\n**8. Drafting** (Kevin)\n\n- Guardrails state only the rule. \"So that\" clauses giving a guardrail's purpose are removed from MEBTS-08, MEBEU-M-06, MEBEU-M-08, MEBEU-S-06, MEBEU-S-08, MRST-06, RSCS-06 and MPL-05, and a \"since\" clause from LLS-01; the reasons are kept for the Guardrails Rationale.\n- Consistent naming: \"the Leios protocol\" for the protocol, \"Leios\" for its parameters and terms (the Leios Committee, a Leios Certificate).\n\n**Open questions**\n\n- The [PENDING] values, including those for reference scripts and *minPoolMargin*.\n- Whether *maxPledgeLeverage* needs joint bounds with *poolPledgeInfluence*, as the TSC review suggested (Cerkoryn). v5 relies on MPL-04; its first value is for a later Parameter Update.\n- Four guardrails could be dropped as redundant: MEBTS-04, MEBEU-M-04, MEBEU-S-04 and MRSEB-05 each require an Endorser Block limit to be at least a per-transaction limit, which already follows from the new floors in section 3 (no transaction can exceed a Block). v5 keeps them for now.\n","author_stake_address":"stake1uxh5vx8a9svkka2ef372hpytpffwrge4yf3c40nq0lfqa0sejrqru","author_display_name":"carlos lopez de lara","created_at":"2026-10-30T04:55:00.235362+00:00","updated_at":"2026-10-30T04:55:00.235365+00:00","moderation_status":"visible","about":null},{"id":86,"proposal_number":12,"parent_id":83,"body":"Thanks, Kevin. On the last parts of your comment: \n\nNull encoding and tests \nIn PV12 the only nullable parameter is maxPledgeLeverage. The Dijkstra CDDL encodes it as: \n\nmax_pledge_leverage = nonnegative_interval/ nil (update key 38), \n\nso a Parameter Update sets it to null by carrying nil for that key. MPL-03 allows null, and the ledger and the Guardrails Script both support it. The accepted-null test (MPL-03) stands.\n\nNo PV12 parameter can be set to null and then rejected by its guardrails, so there is no rejected-null case to test yet.\nPARAM-07 (CAP-v5) makes rejection the default for any future nullable parameter whose guardrails don’t allow null. \n\nDefinition of unset (null) \nRather than a separate entry, the Protocol Parameters definition now ends: “Some protocol parameters may be unset\n(null), meaning they have no value; what that means for a parameter is given in its description.” The meaning differs by\nparameter, so it stays in each description. \n\n[PENDING] values and the production node \n- Agreed that the Parameter Committee should see and discuss every [PENDING] value with its evidence.\n- The production node is the right input for the initial settings. They are what mainnet runs from the hard fork, so they are\nbenchmarked on that release, and under the rollout plan they sit well below the guardrail bounds.\n- The bounds, including those that relate to performance, need a different input. They set the room that later Parameter\nUpdates may use, and their evidence is analytical: what the protocol can support. Some values beyond what a given\nrelease achieves become reachable through software improvements alone, an optimisation in the networking stack for\nexample.\n- That is also the surest way to avoid a recall. A bound tied to one node release is the one most likely to be shown incorrect, because the next release can outgrow it. A bound set on the protocol’s limits stays valid, and each increase within it still has to be confirmed by detailed benchmarking/simulation when it is proposed.\n- For the same reason the Guardrails Script does not need to wait for the production node. It never checks the initial\nsettings, which are in the Dijkstra genesis file (HARDFORK-06), only later Parameter Updates against the bounds.","author_stake_address":"stake1uxh5vx8a9svkka2ef372hpytpffwrge4yf3c40nq0lfqa0sejrqru","author_display_name":"carlos lopez de lara","created_at":"2026-10-30T06:09:17.165833+00:00","updated_at":"2026-10-30T06:09:17.165837+00:00","moderation_status":"visible","about":null},{"id":87,"proposal_number":12,"parent_id":85,"body":"Editor notes on v5.\n\n1. **The off switch has been removed rather than moved, and the CAP, its exhibit and the TSC are now out of step.** The fix Kevin and I suggested for v4 was to move the fast path to MEBTS-09. v5 instead makes MEBTS-09 \"must not be zero\" (y), drops the deactivation sentence from the description, and says in the change note that deactivation belongs in a plan in the spirit of CIP-0135, outside the Constitution. Removing an unconfirmed mechanism from constitutional text is a defensible call: CIP-0164 describes no off switch, and the spec itself says the behaviour at 0 is still to be confirmed with the Leios team. Three things need sorting out regardless:\n   - The linked specification (v1.3, 7 October, checked today) still says in at least seven places that maxEndorserBlockTxsSize = 0 \"is the designated way to deactivate Linear Leios\". Either the spec or the CAP needs updating; readers will find both.\n   - As I read CIP-0135, it works through node releases and operator coordination and changes no protocol parameter. With MEBTS-09 marked (y), the script rejects the only on-chain route short of first amending the Guardrails Script or initiating a hard fork. If that is the intended position, the analysis should say so plainly, so the CC and DReps vote on it knowingly. The rule is in the analysis; the reasoning is only in the change note.\n   - Kevin's TSC report (28 October, not quorate, \"some form of off switch is needed or useful\", no agreed form) and v5 crossed in the post. I would hold the final form of the text until the TSC reports, and state the chosen position explicitly whichever way it goes. One small thing: the change note lists Kevin and me under this item; we asked for the switch to be moved, not removed.\n\n   Also for later readers: MEBRS-07 and MEBTS-10 now mean something different from what comments 79 to 83 refer to (the fast path and Kevin's proposed \"may be set to 0\" rule). A line in the next change note would save confusion.\n\n2. **The script-enforced floors on four Endorser Block limits are gone.** MEBEU-M-02, MEBEU-S-02 and MRSEB-04 were (y) numeric floors in v4, and MEBTS-02 was an (x) floor. In v5 all four are (~) relations to the matching Block limit, which the script cannot see, so the only (y) lower bound left on each is \"must not be zero\". That is the near-zero gap Kevin described for MFRS-05 and MPM-05: maxEndorserBlockTxsSize = 1 byte passes the script. The CAP already shows the fix twice: MEBRS-02 keeps a (y) [PENDING] floor next to MEBRS-07, and MRST-04 (y) sits next to MRST-05 (~). The other four Leios limits should follow the same pattern, a (y) numeric floor alongside the (~) relation.\n\n3. **PARAM-07.** Placement first: PARAM-01 and PARAM-02a are general rules at the top of section 2, while PARAM-03a to 06a sit under the two critical-parameter lists in 2.1. PARAM-07 is a general rule and belongs after PARAM-02a. On wording: where a nullable parameter is listed with no checkable guardrails, PARAM-02a (and the same sentence in section 1) says the script imposes no constraints, while PARAM-07 says it rejects null. The ratified overlap rule (\"the most restrictive set of Guardrails will apply\") already makes PARAM-07 prevail, but a \"notwithstanding PARAM-02a\" clause would save readers the inference and leaves PARAM-02a's text and label as ratified.\n\n4. **Reverting Changes: scope needs pinning down.** The appended sentence exempts a reversion from \"frequency and notice guardrails that apply to that parameter\". The analysis then claims the new rate guardrails are covered too, and they are not: the per-epoch caps (MEBTS-07 and its siblings) are the ones most likely to block a large reversion, so the text should name them if that is the intent. Three related points: the exemption sits in a definition and applies to every parameter in Appendix I, including ratified TC-05 and ME-05, which the analysis should say; it is unclear whether group-level NETWORK-01 and NETWORK-02a, and the 90-day PARAM-04a notice for critical parameters, count as guardrails \"that apply to that parameter\", which was Kevin's original concern; and the definition's first sentence is triggered by performance monitoring only, while the new sentence accepts four headings and \"supporting analysis\", so the two halves of one definition now have different triggers.\n\n5. **Smaller ones.**\n   - LLS-03 is now a \"must\" involving only the three timing parameters and two genesis constants. That is a parameter-only relation, so the marker should be (~ - no access to existing parameter values), as for MBBS-04 and MEBTS-02, not (x).\n   - MPM-05 and RSCS-05 are marked (~) but say \"should\". (~) means the script could enforce it after a ledger change; a \"should\" is never script-enforced. Either \"must not\" with (~), or (x - \"should\").\n   - The four descriptions (MEBTS, MRSEB, MEBEU-M, MEBEU-S) say \"never lower than\" the per-transaction limit, while the operative floor in each -02 / -04 rule is now the per-Block limit. If MEBTS-04, MEBEU-M-04, MEBEU-S-04 and MRSEB-05 are dropped as redundant, which is safe (they follow from the new floors plus ratified MBBS-04, MEU-M-01, MEU-S-01 and the new MRST-05, and MRSEB-05 duplicates MRST-07 anyway), the descriptions should be restated with the Block-level floor.\n   - MPL-06 says \"including set from null\"; PARAM-07 says \"to null, or from null\". Align MPL-06 or drop the clause and rely on PARAM-07.\n   - MPC-03a now reads \"until minPoolMargin is set above 0\"; the analysis still says \"until minPoolMargin is available\".\n   - On Kevin's strict-comparison question: VT-GEN-01 is a ratified (y) \"greater than 50%\", so LQST-01 and LQST-02 are in an established form. Separately, the Guardrails Script source link (with CIP-1694 and CIP-0120) dropped out of the exhibits in v5; it should come back, since item 3 of \"How we will know it worked\" depends on it.\n   - Kevin asked for the \"so that\" purposes to move into the descriptions. v5 deleted them and says they are kept for the Guardrails Rationale. The CC reads the Constitution, not the Rationale, so the descriptions are the right home. RSCM-04 still carries one (\"to preserve the intended denial-of-service protection\").\n   - The analysis says \"network and security groups\". Appendix I has no group by that name: the SPO vote comes from the section 2.1 \"critical to the operation\" list via PARAM-03a, and the DRep threshold from the section 9 network group. Suggest wording it that way. Also \"all reference-script parameters\" does not fit minFeeRefScriptCostPerByte, which is economic.\n   - maxRefScriptSizePerBlock is the one limit without an MBBS-03a-style decrease rule in v5 (MRSB-07 allows decreases by its \"changed by\" form). Deliberate?\n   - Disclosure: every Leios parameter is now on the critical list, so each \"measured step\" of the rollout carries PARAM-04a's 90-day notice unless Severity 1 or 2, and NETWORK-01's once-per-two-epochs limit. The analysis sells step-by-step increases and should say what each step costs in process.\n\nStill open from Kevin's list and not mentioned in the change note: the quantities LLS-01/02, LQST-06, MFRS-06/07, MRSB-06 and MRST-09 refer to (diffusion and transmission times, tolerated adversarial stake, \"processing constraints of nodes\") are still undefined in the text. Who publishes them is for the author and the Parameter Committee, but the text should at least say that a published figure exists and where.\n\nThe [PENDING] values, the maxPledgeLeverage question for Cerkoryn, and the TSC's view on the switch remain outside the editor's remit.","author_stake_address":"stake1u8dknvrfz38gr8afd0c8vskmz7dkd79gn05gr8mh6ym3cjs7886dj","author_display_name":"Thomas","created_at":"2026-11-02T16:59:01.757705+00:00","updated_at":"2026-11-02T17:02:24.214310+00:00","moderation_status":"visible","about":null},{"id":93,"proposal_number":12,"parent_id":null,"body":"Comments on the CAP-12 v5 reference-script guardrails\n\nAs requested by Carlos, I've reviewed the reference script guardrails. Some work is needed here (specifically benchmarking). These need to be treated carefully since there are security implications (including possible Denial-of-Service for Linear Leios). The review also shows a general gap in the constitution relating to the treatment of security concerns, which is sensibly plugged as a general case rather than specifically to these parameters. Some parameters should arguably be in the security group, requiring an SPO vote, but my understanding is that the ledger team has no capacity to make any changes at this point, so this may need to be held to Euler.\n\nFull public review, with worked figures and charts: https://docs.google.com/document/d/1DBL6UFbh28wjaH9yADRs4sjglIsI70rWsCbUEETosaM/edit\nThis has been passed on to the Parameter Committee yesterday for consideration.  A more detailed review has also been passed on to the Security Council who will need final sign-off.\n\n1. Response to comment 87\n- MRSEB-04: agree. Keep a (y) [PENDING] floor alongside the (~) rule, as MRST-04/05 do; the (~) rule is only checkable on-chain when both parameters are in the same proposal.\n- MRSB decreases: agree on the gap, but use MRSEB-08 wording (\"no decreases except in exceptional circumstances\") rather than an absolute ban. The per-block cap is the lever needed in an incident.\n- RSCM-04: agree. Keep the rule and move the purpose clause to the rationale.\n- Analysis, \"How governance changes\": agree the sentence is wrong for minFeeRefScriptCostPerByte, which remains in the economic group (and, in the Conway ledger, the security group, so the SPO vote still applies). Suggested wording: \"The Linear Leios parameters and the new reference-script parameters are in the network group; minFeeRefScriptCostPerByte remains in the economic group.\" Please check whether section 9 lists maxRefScriptSizePerEndorserBlock.\n- MRSEB-05 / MRST-07: disagree with removing the duplicate. Keep both pairs (and MRSB-05 / MRST-05) so each family lists every rule that limits it, as MBBS-04 and MTS-04 already do, and note the duplication in the rationale.\n\n2. Missing rules\n- Lock-up invariant: add MRST-11 (~), maxRefScriptSizePerTx must not be lower than maxTxSize, with a mirror rule in MTS. Otherwise UTxOs carrying existing reference scripts can become unspendable. This is the real rationale for MRST-08.\n- MFRS-06/07: state that \"fee\" means the base (tier-1) rate. Tiering is per transaction, so the multiplier does not affect block-level attack cost.\n- MFRS-08: derive the floor as the smallest base rate that satisfies MFRS-06/07 with MRSB and MRSEB at their upper bounds.\n- RSCS-05 is tagged (~) but worded \"should\"; make it \"must not exceed\".\n- RSCM-01/06 are implied by RSCM-02 but should stay, noted as potentially redundant, in line with TFPB, SPTN and CP.\n\n3. Base rate, stride, multiplier and per-tx cap must be bounded jointly\nThe fee is very sensitive to a smaller stride: at today's base rate and multiplier, halving the stride nearly triples the fee for 200 KiB, and below about 1.4 KiB that fee exceeds the entire ada supply. A multiplier below 1.0 makes large scripts cheaper per byte.\n\nThe 1,000 lovelace ceiling in the current MFRS-01 (carried into v5 as MFRS-01a) mirrors TFPB-02's ceiling for txFeePerByte, with no derivation given. It is too high: transactions remain payable, but at that rate referencing a single 10 KB validator would cost 10 ada, a 50 KiB DeFi transaction about 56 ada, and a 200 KiB transaction about 422 ada, which would be prohibitive. I suggest:\n- A relative ceiling: minFeeRefScriptCostPerByte should not exceed txFeePerByte. A referenced byte costs the node only deserialisation, which can be cached, while an inline byte also costs bandwidth and permanent storage. Above txFeePerByte, scripts that fit would be cheaper to inline, defeating the purpose of reference scripts (CIP-33).\n- A lower absolute (y) ceiling, derived from a guardrail bounding the worst-case fee, with RSCS-03, RSCM-03, MRST-04 and the MFRS ceiling set together.\n\n4. Additional stride guardrails\n- Stride not lower than maxTxSize, so a single script never pays the tier premium.\n- A bound on maxRefScriptSizePerTx / stride (the number of tiers).\n- A fee-impact analysis on existing mainnet usage before any decrease.\n- A rate-of-change limit, in line with MTS-05 and NETWORK-01.\n- A fee-computation cost analysis for any change to stride, multiplier or per-tx cap, including confirmation that off-chain fee calculators reproduce the ledger's exact result at the bound edges.\n\n5. Benchmarking and a Linear Leios time-cost model\nThe \"confirmed by benchmarking\" rules need defined quantities: per-byte validation cost, the time budget reference scripts may use, and a rule converting node time into required attacker spend. All should be measured on the final production node (node 12.0). Linear Leios needs the same for endorser blocks: validation cost within the voting window, endorser-block limits, the budget for adopting a ranking block that carries a certificate (bounding MRSB + MRSEB), and attack cost per endorser block.\n\nThese figures should feed a Linear Leios time-cost and impact model: per-resource cost functions mapped onto each protocol stage and deadline, the combined worst case, the impact of each overrun (lost throughput, late ranking blocks or slow adoption, latency, sync time) mapped to severity levels, and the attacker spend needed to cause each impact. Changes to Linear Leios and reference-script parameters should be confirmed against that model. Its method, budgets and pass-or-fail results should be public; adversarial inputs, precise breaking points and attack strategies should be held by the development teams and the Security Council, and released once fixed or superseded.\n\nI also propose a parity guardrail modelled on EIUP-GEN-01: filling a block via reference scripts should cost about the same, relative to node time, as filling it by size or execution units.\n\n6. Wider changes for CAP-12\n- Add executionUnitPrices, maxTxExecutionUnits and the new reference-script and Linear Leios parameters to the section 2.1 critical list. This needs matching security-group tagging in the ledger, or PARAM-03a cannot be enforced for them.\n- Add a general section 2.1 guardrail requiring a security assessment, with a published summary, before any change that weakens denial-of-service protection, plus a terminology entry next to \"Benchmarking\". The stride and multiplier are risky in both directions.\n- For maxRefScriptSizePerEndorserBlock: a ledger check per endorser block, separate timing budgets for ranking and endorser blocks, and a guardrail on the combined MRSB + MRSEB load when a certificate lands. Linear Leios timings are still [PENDING].\n\nKevin Hammond","author_stake_address":"stake1uy42cc65gdhryw93aezcag9j7k4pv9fxrdx982086yrxy2quecjvx","author_display_name":"Kevin Hammond","created_at":"2026-11-06T10:57:36.460429+00:00","updated_at":"2026-11-06T10:57:36.460432+00:00","moderation_status":"visible","about":null},{"id":94,"proposal_number":12,"parent_id":87,"body":"The TSC is considering the \"off-switch\".  It will review this at the next meeting (on Nov. 18 because of the node diversity workshop and a US holiday).  It seems sensible to have both a protocol-level switch controlled by governance in addition to the operational switch (controlled by ad-hoc SPO participation).\n\nProposed TSC position:\n\na. Off switch. Support maxEndorserBlockTxsSize = 0 as the official, network-wide deactivation path for Linear Leios, conditional on:\n\n1. written confirmation from the Linear Leios team that at 0 no EBs are announced, no votes are cast or diffused, no certificates appear in RBs, and node behaviour is equivalent to Praos;\n\n2. switch-off and switch-back-on exercised on Preview and Preprod, with block production measured against the Praos baseline (R31, R38);\n\n3. conformance tests for the 0 setting across all node implementations (consensus-critical);\n\n4. guardrail changes: fast path moved to MEBTS-09; MEBTS-02 split (floor applies when not 0); new MEBTS-10 (0 allowed).\n\nb. Fast path. Support waiving the PARAM-04a notice, limited to switch-off in response to a Severity 1 or 2 network issue. Switch-on follows the normal process. Note: this removes the notice period only; ratification and enactment still take at least one epoch boundary.\n\nc. Frequency limit. Support allowing a switch-off in any epoch (new NETWORK-XX guardrail), for the transition to 0 only; switch-on remains subject to the network-group frequency limit","author_stake_address":"stake1uy42cc65gdhryw93aezcag9j7k4pv9fxrdx982086yrxy2quecjvx","author_display_name":"Kevin Hammond","created_at":"2026-11-06T11:03:47.845102+00:00","updated_at":"2026-11-06T11:03:47.845105+00:00","moderation_status":"visible","about":null},{"id":95,"proposal_number":12,"parent_id":87,"body":"Thanks, Thomas.  You are making some good and careful points.  I will respond as I get time from other activities.  The overall direction here is positive, but there is still a lot of detail to sort out and some of it has security implications, so we need to get this right even if that takes a little more time.  Note that the Parameter Committee has not yet seen any [PENDING] values and it will take time and effort to review these properly.","author_stake_address":"stake1uy42cc65gdhryw93aezcag9j7k4pv9fxrdx982086yrxy2quecjvx","author_display_name":"Kevin Hammond","created_at":"2026-11-06T11:08:02.105712+00:00","updated_at":"2026-11-06T11:08:02.105715+00:00","moderation_status":"visible","about":null},{"id":99,"proposal_number":12,"parent_id":null,"body":"MPC-03a (x - \"should\") *minPoolCost* should be set in conjunction with *minPoolMargin*. Until *minPoolMargin* is set above 0, *minPoolCost* should be set in line with the economic cost of operating a pool.\n-> I think it doesn't make sense anymore to state that *minPoolCost* should be set in line with the economic cost of operating a pool. Also the 'until' clause is a bit strange, as nothing forbids to set *minPoolCost* again in the future; in this situatution this guardrail is a bit vague. I think the further formulation that *minPoolCost* and *minPoolMargin* might not both be 0 at the same time wil suffice.\n\nMPM-03 (y) *minPoolMargin* must not exceed [PENDING]\n-> I think the value for [PENDING] here should be 0.5 (50%) or higher to allow for enough room.\n\nMPM-04 (x - \"should\") *minPoolMargin* should be set in conjunction with *minPoolCost*, considering both delegator rewards and the economic viability of operating a pool.\n-> This is unnecessary imho.\n\nMPM-06 (x - \"should\") An increase to *minPoolMargin* should be announced at least 18 epochs (approximately 3 months) in advance, together with an analysis of the effect on pool and delegator rewards\n-> Why doesn't this requirement hold for any change (increase and decrease) and both *minPoolCost* and *minPoolMargin*?\n\n\nMPM-07 (~ - no access to change history) *minPoolMargin* must not be changed more than once in any 36-epoch period (approximately 6 months)\n-> Why doesn't this requirement hold for both *minPoolCost* and *minPoolMargin*?","author_stake_address":"stake1uxe9p8jl0j2v9z7l938ctza07s4cnl92zdy60yrp0c2r9rqu46jcf","author_display_name":"Tom [NIMUE]","created_at":"2026-11-06T16:44:56.667598+00:00","updated_at":"2026-11-06T16:44:56.667602+00:00","moderation_status":"visible","about":"revisions[7]"},{"id":100,"proposal_number":12,"parent_id":null,"body":"I think we should have a guardrail that states that the current total pledged ada should be taken into account when setting *maxPledgeLeverage*, so that, with enough margin, there's enough 'room' for all ada to be staked without losing rewards.\n\nE.g. The margin could be twice the max supply (90B ada). If the current total pledged ada is 2B ada, *maxPledgeLeverage* must be at least 45 then; pledge will need to more than half this way before there's not enough 'room' anymore (more than half and not half, because not all ada will be staked). Other values might work too and the required margin doesn't necessarily needs to be defined explicitly.","author_stake_address":"stake1uxe9p8jl0j2v9z7l938ctza07s4cnl92zdy60yrp0c2r9rqu46jcf","author_display_name":"Tom [NIMUE]","created_at":"2026-11-06T16:46:33.656945+00:00","updated_at":"2026-11-06T16:46:42.169519+00:00","moderation_status":"visible","about":"revisions[14]"},{"id":101,"proposal_number":12,"parent_id":93,"body":"Thanks Kevin. Two answers and three notes from the editor's side.\n\nSection 9: yes, v5 adds maxRefScriptSizePerEndorserBlock to the network group in the same insertion as the other Leios parameters, and keeps minFeeRefScriptCostPerByte in the economic group under its new name. Your replacement wording for the analysis sentence matches what the revisions actually do.\n\nMRSEB-08 wording for MRSB decreases, and keeping both halves of the MRST/MRSEB and MRST/MRSB pairs: agreed on both, with the duplication noted in the rationale so a later change updates both sides.\n\nThree things for Carlos as these go into v6:\n\n1. Every new rule needs a marker and a location. The stride and fee rules are straightforward. The Linear Leios time-cost model guardrail and the security-assessment guardrail refer to a model, a published summary and an assessing group that do not yet exist, so, as with the benchmarking quantities, the text should say where the published material lives and who publishes it.\n\n2. Adding executionUnitPrices and maxTxExecutionUnits to the section 2.1 list amends the ratified treatment of two existing parameters, and you note the ledger retagging may wait for Euler. If they go in, PARAM-03a would require an SPO vote the ledger cannot deliver until then, and the text should say what applies in between. Whether this belongs in CAP-12 or in a separate amendment is a scope call for the author. CAP-12 is titled as the Dijkstra parameters amendment and the CC and DReps will read it that way.\n\n3. The relative ceiling (minFeeRefScriptCostPerByte should not exceed txFeePerByte) is a parameter-only relation, so either (~ - no access to existing parameter values) with \"must not exceed\", or (x - \"should\"). Same marker point as RSCS-05 and MPM-05.\n\nThe (y) list is open again until Carlos says which of these go in, so the script work on the reference-script families should wait for that decision.","author_stake_address":"stake1u8dknvrfz38gr8afd0c8vskmz7dkd79gn05gr8mh6ym3cjs7886dj","author_display_name":"Thomas","created_at":"2026-11-09T10:42:15.731421+00:00","updated_at":"2026-11-09T10:42:15.731429+00:00","moderation_status":"visible","about":null},{"id":102,"proposal_number":12,"parent_id":94,"body":"Thanks, that answers the hold I asked for in item 1 of my v5 notes. If the TSC adopts this on 18 November, v6 reverses v5's removal. Consequences for the text:\n\n- a.4 is the shape we suggested for v4, so the guardrail form is settled: MEBTS-09 becomes the fast path, MEBTS-02 applies when the value is not 0, and a new rule permits 0. For the script, \"0 or not lower than the floor\" is only (y) if the floor is a number, and MEBTS-02 is now a (~) relation to maxBlockBodySize. So this ties to item 2 of my v5 notes: the (y) [PENDING] floor has to come back for the 0-or-floor check to be enforceable on-chain.\n\n- b is already in the ratified text. PARAM-04a says the 90 days \"may be relaxed in the event of a Severity 1 or Severity 2 network issue\". A switch-off rule should cite PARAM-04a rather than add a second exemption, and can narrow it to switch-off only if that is the intent.\n\n- c does need a new rule. NETWORK-01 is (x - \"should\"), once per two epochs for network parameters. A transition-to-0 exemption would be a new NETWORK guardrail, and the analysis should say, as you do, that ratification and enactment still take an epoch boundary.\n\n- The specification (v1.3) would then be right and v5's change note wrong about the designated deactivation path, so the note and the CIP-0135 paragraph in the analysis need updating together.\n\nMEBTS-09 and MEBTS-10 already exist in v5 with other meanings, so the v6 change note should map old labels to new ones.","author_stake_address":"stake1u8dknvrfz38gr8afd0c8vskmz7dkd79gn05gr8mh6ym3cjs7886dj","author_display_name":"Thomas","created_at":"2026-11-09T10:43:48.715230+00:00","updated_at":"2026-11-09T10:43:48.715235+00:00","moderation_status":"visible","about":null},{"id":103,"proposal_number":12,"parent_id":100,"body":"Thanks Tom. The MPM-03 value and whether the margin rules should also cover minPoolCost are for Carlos and the Parameter Committee rather than the editor. Three notes on form:\n\n- The rationale should say why MPM-06 and MPM-07 apply to minPoolMargin only. The ratified MPC family has no notice or frequency rule and v5 does not add one, so the asymmetry is a choice and should be stated as one.\n\n- On MPC-03a, the \"until\" sentence is one of the points in my v5 notes (the analysis still says \"available\"). Dropping it and relying on the not-both-zero rule would remove the mismatch. That rule is MPM-05, which is marked (~) but worded \"should\", so it needs to be \"must not\" if it is to carry that weight.\n\n- On the pledge-leverage idea in your second comment: anything that refers to the current total pledged ada is chain state, so it would be (x), next to MPL-04 and MPL-05. MPL-05 already asks for an analysis of the stake that would lose reward eligibility. Your headroom test could be phrased as part of that analysis rather than as a separate rule.","author_stake_address":"stake1u8dknvrfz38gr8afd0c8vskmz7dkd79gn05gr8mh6ym3cjs7886dj","author_display_name":"Thomas","created_at":"2026-11-09T10:44:32.823901+00:00","updated_at":"2026-11-09T10:44:32.823904+00:00","moderation_status":"visible","about":"revisions[14]"},{"id":104,"proposal_number":12,"parent_id":null,"body":"Proposed additional guardrails: increases to maxEndorserBlockTxsSize\n\nThe off switch (MEBTS-09/10) covers deactivation. It doesn't cover how capacity goes up, which is where the cost to SPOs and the irreversible effects lie: chain growth is permanent, and fixed operator costs start the day a step takes effect, whether or not demand arrives. I'd suggest the following, for discussion. The numbers are placeholders.  The straw man suggests that costs to SPOs could be up to ~$3M for a 10x-15x throughput increase, which is not sustainable from fee income.  A universal move to the LSM backend could reduce this, but the interaction with Linear Leios is not yet tested.\n\nMEBTS-11 (step size): a single change must not increase maxEndorserBlockTxsSize by more than twice the current maxBlockBodySize.\n\nMEBTS-12 (interval): maxEndorserBlockTxsSize must not be increased within 18 epochs of the previous increase.\n\nMEBTS-13 (utilisation): maxEndorserBlockTxsSize should not be increased unless average use over the previous 6 epochs is at least 60% of the current setting.\n\nMEBTS-14 (readiness): a governance action to increase maxEndorserBlockTxsSize must not be submitted unless pools holding at least 90% of active stake have registered BLS keys and declared that their hardware meets the published reference specification for the proposed setting.\n\nMEBTS-15 (benchmark): a governance action to increase maxEndorserBlockTxsSize must be supported by a published benchmark, run on a mainnet ledger snapshot, showing that endorser blocks at the proposed setting are validated within the voting window and certified at the expected rate. The reference specification in MEBTS-14 is derived from this benchmark.\n\nRationale for the readiness threshold: certification needs 75% of committee stake, so lagging stake, normal downtime and any adversary withholding votes must together stay under 25%. With 15% of stake lagging, an adversary with about 10% could block certification.\n\nI'd also ask for confirmation that maxEndorserBlockTxsSize sits in the security group, so SPOs, who bear the cost, vote on increases.\n\nBackground is in the TSC's provisional SPO cost-impact straw-man for the HFWG: https://docs.google.com/presentation/d/12EL4KWMUdv2wqHp_Cpxr-FfoyoT69nxK9uik9RYO5Io","author_stake_address":"stake1uy42cc65gdhryw93aezcag9j7k4pv9fxrdx982086yrxy2quecjvx","author_display_name":"Kevin Hammond","created_at":"2026-11-09T19:39:28.032773+00:00","updated_at":"2026-11-09T20:24:42.162734+00:00","moderation_status":"visible","about":null},{"id":105,"proposal_number":12,"parent_id":101,"body":"Thanks, Thomas.  Obviously it's important to get security right. Agreed that every new rule needs a marker and a location, and that the text must say where the published material lives and who publishes it, without naming any organisation. I'd suggest:\n\nPARAM-08 (x), in section 2.1 after PARAM-07: a change that weakens denial-of-service protection must be supported by a security assessment carried out or certified, and published, by a party not involved in preparing the proposed change. The proposer may commission the assessment but must not edit it. The governance action must reference the published assessment.\n\nLLS-04 (x), with the joint Leios timing guardrails: each change to a Linear Leios limit or timing parameter must be accompanied by the published Linear Leios time-cost model and the benchmark figures it uses, referenced from the governance action.\n\nBoth are (x) because they need the Constitutional Committee's judgement. Each also needs a terminology entry in section 1 next to Benchmarking: \"Security Assessment\", and \"Linear Leios time-cost model\" (per-resource costs mapped onto each protocol stage and deadline).\n\nDefining independence by role rather than by organisation means a proposer such as Intersect can still commission the work, while the findings stay outside the proposer's control. In practice I'd expect the Security Council normally to certify these assessments. That belongs in the rationale rather than the guardrail, so the Constitution doesn't depend on any one body.\n\nOn executionUnitPrices and maxTxExecutionUnits, I think CAP-12 needs to include them. The reference-script protections it introduces depend on them: the DoS cost of a block or endorser block is set by execution pricing and per-transaction limits as much as by the reference-script parameters. It would be inconsistent to require an SPO vote for the new reference-script and Leios parameters while leaving the two parameters they rely on outside the critical list. The text should then say what applies until the ledger can deliver the SPO vote, for example an SPO poll before any change.","author_stake_address":"stake1uy42cc65gdhryw93aezcag9j7k4pv9fxrdx982086yrxy2quecjvx","author_display_name":"Kevin Hammond","created_at":"2026-11-09T19:57:19.247480+00:00","updated_at":"2026-11-09T19:57:19.247483+00:00","moderation_status":"visible","about":null},{"id":106,"proposal_number":12,"parent_id":102,"body":"Thanks, Thomas. Agreed on each point, subject to the TSC's decision on 18 November.\n\n(a) A numeric (y) floor needs to come back so the script can check \"0 or not lower than the floor\". The Parameter Committee should propose it with the other [PENDING] values.\n\n(b) Agreed: cite PARAM-04a rather than add a second exemption, narrowed to switch-off only. Switching back on follows the normal process.\n\n(c) A new NETWORK rule for the transition to 0, with the analysis noting that even with the notice waived, ratification and enactment take at least two epoch boundaries, roughly 5 to 10 days. That is why operator-level controls in the node (stopping endorser-block announcements and voting) matter as a complement: they are the only way to act within hours rather than days.\n\nAnd yes, the v6 change note should map old labels to new, since MEBTS-09 and MEBTS-10 have changed meaning twice.","author_stake_address":"stake1uy42cc65gdhryw93aezcag9j7k4pv9fxrdx982086yrxy2quecjvx","author_display_name":"Kevin Hammond","created_at":"2026-11-09T20:05:08.260677+00:00","updated_at":"2026-11-09T20:05:08.260681+00:00","moderation_status":"visible","about":null},{"id":107,"proposal_number":12,"parent_id":99,"body":"Thanks, Tom. The MPM-03 value and the minPoolCost/minPoolMargin settings are for the Parameter Committee, which hasn't yet seen any of the [PENDING] values. I agree with Thomas that your pledge headroom test fits best inside the MPL-05 analysis.\n\nOn MPC-03a, I'd keep a link to the economic cost of running a pool in some form. Linear Leios will raise operator costs, and minPoolCost is the one existing parameter that reaches small pools. The TSC's provisional cost analysis is here: https://docs.google.com/presentation/d/12EL4KWMUdv2wqHp_Cpxr-FfoyoT69nxK9uik9RYO5Io","author_stake_address":"stake1uy42cc65gdhryw93aezcag9j7k4pv9fxrdx982086yrxy2quecjvx","author_display_name":"Kevin Hammond","created_at":"2026-11-09T20:06:53.911622+00:00","updated_at":"2026-11-09T20:06:53.911625+00:00","moderation_status":"visible","about":"revisions[7]"}]