Skip to main content

Applications for the autumn mentorship cohort are open until 30 September. Apply now

DSI
Worksheet

Protocol Parameter Change Review Worksheet

A structured review for proposed protocol parameter changes: what the value is now, what it becomes, who it affects, what the downside looks like, and how it would be reversed.

Type
Worksheet
Difficulty
Advanced
Time
45 min
Version
v1.0.0
Updated
8/9/2026
governance actionsprotocoltechnical

What this helps you do

Parameter changes are among the least discussed and most consequential governance actions. They rarely arrive with a narrative, they are easy to wave through, and their effects are distributed unevenly across stake pool operators, delegators, builders, and users.

This worksheet forces the questions a parameter change should have to answer. It compares current and proposed values, states the purpose in the proposer's terms and the expected effect in yours, identifies affected stakeholders, tests the supporting evidence and any historical comparison, records dependencies between parameters, and asks two questions that are often skipped: what does the downside look like, and how would this be reversed.

When to use this

  • A parameter change action is live and you need a consistent way to review it.
  • A proposal bundles several parameter changes and you need to separate their effects.
  • You are writing a rationale on a technical action and want the reasoning legible to non-technical readers.

When NOT to use this

  • The action is a treasury withdrawal with no parameter component.
  • You need authoritative current values for an operational purpose. Read them from chain.
  • You are looking for a recommended value. This worksheet deliberately produces analysis, not targets.

What you'll need

  • The current on-chain value of every parameter the action touches
  • The proposed value and the full action text
  • The parameter definition from the ledger specification
  • Any modelling, simulation, or historical data the proposer relies on

Estimated completion time

45 minutes

Working time for one governance action, assuming the inputs listed here are already to hand.

How to use it

  1. 1List every parameter the action changes. Bundled changes are reviewed individually and then together.
  2. 2Read the current value from chain or a governance explorer, and record where and when you read it.
  3. 3Record the parameter definition from the ledger specification in your own words, so the review does not depend on the proposer's framing.
  4. 4State the purpose as the proposer states it, then state the expected effect as you understand it. Note where these differ.
  5. 5Map affected stakeholders and, for each, whether the effect is direct or second order, and whether it is immediate or delayed.
  6. 6Assess the supporting evidence: modelling, simulation, testnet data, or comparable networks. Note the absence of evidence explicitly.
  7. 7Look for a historical comparison. If this parameter, or a similar one, has been changed before, what happened?
  8. 8Record dependencies: parameters that interact with this one, and guardrail bounds that constrain the value.
  9. 9Describe the downside case in concrete terms, not as a probability. What would people actually experience?
  10. 10Assess reversibility: can this be undone, by what mechanism, how quickly, and what damage would persist afterwards.
  11. 11Write the monitoring plan: what to watch after enactment, on what schedule, and what reading would trigger a correction.

The tool

Full worksheet - v1.0.0

The change

  • Parameter name as it appears in the ledger specification
  • Current value, with the date and source you read it from
  • Proposed value
  • Direction and size of the change, in absolute and percentage terms
  • Guardrail bounds that apply to this parameter
  • Whether the action bundles other parameter changes

Purpose and expected effect

  • Purpose in the proposer's own words
  • Expected effect as the proposer describes it
  • Expected effect as you understand it
  • Where those two differ, and why
  • Mechanism: how the value change produces the effect
  • Time to effect: immediate, one epoch, gradual

Who is affected

  • Stakeholder group
  • Direct or second-order effect
  • Direction of effect: benefit, cost, or neutral
  • Magnitude, with a stated basis
  • Whether the group was consulted
  • Groups the proposal does not mention

Evidence and history

  • Supporting evidence type: modelling, simulation, testnet, mainnet history, comparable network, none
  • Who produced the evidence and whether they are independent of the proposer
  • Assumptions the modelling depends on
  • Historical comparison: prior change to this or a related parameter
  • What happened after that prior change
  • Evidence you would want that does not exist

Risk, reversibility, monitoring

  • Dependencies on other parameters
  • Interaction effects if enacted alongside other live actions
  • Downside case described concretely
  • Who bears the downside
  • Reversibility: can it be reversed, by what mechanism, in what timeframe
  • Damage that would persist after reversal
  • Monitoring metrics, sources, and cadence
  • Reading that would trigger a corrective action
Fictional Example

Invented for illustration. It does not describe a real governance action, proposal, or organisation.

Fictional review: minimum pool cost reduction

  • Parameter: minimum pool cost. Current value read from a governance explorer on the day of review; proposed value is a reduction of roughly one third (fictional figures).
  • Purpose as stated: improve competitiveness for small pools. Expected effect as understood: modest redistribution of rewards, with the largest relative benefit to pools near the current floor.
  • Affected groups: small pool operators (direct benefit), delegators (small direct benefit), large operators (neutral to slight cost), and pool operators running at cost (direct cost, not mentioned in the proposal).
  • Evidence: one spreadsheet model produced by the proposer, no independent replication, and no testnet data. Assumption that operator behaviour is unchanged is doing most of the work in the model.
  • Historical comparison: a prior reduction to this parameter on a comparable network was followed by a rise in pool count and a fall in average pool margin.
  • Downside case: marginal operators exit rather than absorb a lower floor, reducing rather than increasing decentralisation.
  • Reversibility: reversible by a further parameter action within roughly one to two epochs; operator exits during that period would not reverse.
  • Monitoring: pool count, saturation distribution, and operator margin at 30, 90 and 180 days.

How to interpret the result

  • A proposal that cannot describe its own downside case concretely has not been stress-tested, whatever the modelling shows.
  • Where the proposer's expected effect and your understanding of the mechanism diverge, that gap is the finding worth publishing.
  • Reversible does not mean harmless. Record what survives the reversal.
  • Unmentioned stakeholder groups are usually the ones carrying the cost.

Limitations

  • Parameter values, guardrail bounds, and their meanings change. Read current values from chain rather than from any document, including this worksheet.
  • This structures review; it does not model outcomes. Quantitative effects require modelling this resource does not perform.
  • Historical comparisons across networks are indicative at best. Conditions differ in ways that are rarely captured.

Sources and methodology

Downloads

  • Markdown export: the complete tool, including metadata, instructions, the template, limitations, sources and version history.

No other file formats are published for this resource. We list a format only when the file exists.

Version and governance

Current version
v1.0.0
Published
Not recorded
Last updated
8/9/2026
Next scheduled review
2/9/2027
Licence
CC BY 4.0
Editorial status
Not yet externally reviewed

No named reviewer is shown because no external review has been completed. Attribution appears only once a verified reviewer has signed off.

Changelog

  • v1.0.0 (2026-08-09) - First published edition.
Use This Tool