CIP-0173? | Net Change Limit Parameter

[Cerkoryn]

I think that this is an incredibly intuitive but much needed CIP that will substantially improve governance fatigue.

It is quite short and simple, but I am happy to take feedback and iterate on it until it satisfies community expectations.

(rendered)

[rphair]

@Cerkoryn the result of our last open debate on similar subjects is that the CIP process cannot be used to mandate characteristics of budget processes or other strictly human (non-technical) organisational processes:

• New Category: Governance #937

At this time we are only awaiting workload constraints — ongoing with CIP editors for a few months now — before drafting a proper Governance category CIP: so this category term can then be applied to technical procedures in the governance process. (Personally I have been waiting for some environmental factors, still pending resolution "after the holidays", before I have the time to prepare & submit a draft for this with other CIP editors).

Until a Governance CIP with such eligibility criteria is agreed upon by editors, reviewers & critics, and widely understood by governance actors, we can't begin reviewing any CIP like this. I would be happy recognising it as a Draft while that CIP is in the works: which is currently what we've had to do with all other CIP repo submissions which are ultimately about budget and human factors:

• CPS-???? | Social Governance #935
• CIP-???? | Social Governance - Budget Guardrails #936
• CIP-???? | Social Governance - Voluntary DRep Code of Conduct #939
• CIP-???? | Trust-Minimized Cardano Budget Process #940

Then we can start admitting any eligible Governance proposals once we have a framework to impartially establish that they are technical and not just creating more territory for the governance "dumpster fire" to spread into... or worse, creating opportunities for agents influential in the CIP process to to influence budget processes without the usual due process of voting.

@Cerkoryn I do think you may have found an acceptable technical governance process with this parameter, but the number of human factors listed in Path to Active to even consider such a parameter is daunting: and has "human", "organisation", and "money" written between every one of those lines.

Unless you can already make an indisputable case that your proposal and its implementation are about technical procedure and nothing else, you could mark this as a Draft until that can be established... or until we have at least an acceptable draft of a Governance CIP indicating broad support for such parameter additions & their feasibility.

I would not be alone in trusting your own good will & experience in this matter but — as you will see when reading the arguments presented in #937 — we would not want to reduce the entire community's "governance fatigue" by pushing that fatigue into the CIP process and its dramatically limited resources & personnel: let alone the opportunities for undue influence and vested interest that this could create.

[Ryun1]

I do feel that this problem could be probably be sufficiently solved via tooling

I'm not sure the benefits of asking node's to calculate this, over tooling

[Cerkoryn]

I agree that this could be solved with tooling relatively easily. This CIP doesn't ask the node to calculate anything, just hold the parameter values.

[Ryun1]

The parameters do not introduce any new ledger enforcement rules for treasury withdrawals or budgets; instead, they are used by the Constitutional Committee to assess constitutionality.

Do we have evidence that this is a problem that the Constitutional Committee have?

[Cerkoryn]

Not sure I understand the question. There is no problem here as I understand it. It's just saying that the CC will continue to do something that they already have to do, which is assess constitutionality of proposals according to the NCL.

The only difference is that this CIP would make the NCL a parameter instead of a governance action.

[Ryun1]

If we are already asking CC to compute outflows, I feel they can probably also calculate the NCL and treasury inflows

[Cerkoryn]

Yes, this CIP doesn't meaningfully change what the CC has to do with those calculations.

However, instead of the NCL being a fixed window, it is a rolling window defined by netChangePeriod.

[Ryun1]

Suggested change

	- `netChangeLimit`: **positive integer percentage** (e.g., 20 means 20%). May be greater than 100.
	- `netChangeLimitMultiplier`: **positive integer percentage** (e.g., 20 means 20%). May be greater than 100.

maybe a rename on this would be more straight forward
this is based on how I have seen the term NCL used

[Cerkoryn]

I was trying to keep it simple with the existing NCL (both name and acronym). Additionally, keeping the name the same happens to make it map cleanly to the existing NCL terminology in the Constitution.

However I realize that it is a percent instead of a flat number now, so maybe there is some room for discussion on this. Brainstorming some alternate ideas to keep the acronym consistent:

Net Change Level
Net Change Leverage
Normalized Change Limit
Normalized Change Level

Or if we want to drop the acronym we can call it Net Change Percent which seems simpler and more descriptive.

[Ryun1]

Suggested change

	- `netChangePeriod`: **positive integer** number of epochs used as the revenue lookback window (default **73** epochs, ~1 year).
	- `prevNetChangePeriod`: **positive integer** number of epochs used as the revenue lookback window (default **73** epochs, ~1 year).

netChangePeriod implied, to me, that it was referencing as established active Net Change Limit.
Rather than some previous time frame.

(perhaps the way I read it)

[Cerkoryn]

With this CIP the NCL would basically always be established as active, it would just be on a rolling timeframe.

For example if NCL is 73 epochs (1 year) and you submit a proposal today, I would then have to look back one year from today to see how much spending has been allocated during that window.

If you submit another proposal a month later, the window also shifts forward by a month.

In this sense there would never really be a a "previous" period because it would always be rolling.

[Cerkoryn]

@rphair I could've sworn I typed up a lengthy reply, but it seems to have disappeared somehow. I'll re-write what I was trying to say here.

@Cerkoryn the result of our last open debate on similar subjects is that the CIP process cannot be used to mandate characteristics of budget processes or other strictly human (non-technical) organisational processes:

This is maybe walking the line a bit, but technically this CIP doesn't change anything at all about the human processes, which are all defined in the Constitution and would not need any changes at all. The text of the Constitution states that "A net change limit for the Cardano treasury's balance per period of time must be agreed by the DReps via an on-chain governance action". But it does NOT specify that it must be an Info Action. Technically this CIP could check all those boxes by introducing the netChangeLimit parameter initialized to 0 and then having dReps approve a Parameter Change governance action. From there it would be enforced by the CC in the exact same way with no changes to the human process.

@Cerkoryn I do think you may have found an acceptable technical governance process with this parameter, but the number of human factors listed in Path to Active to even consider such a parameter is daunting: and has "human", "organisation", and "money" written between every one of those lines.

Unless you can already make an indisputable case that your proposal and its implementation are about technical procedure and nothing else, you could mark this as a Draft until that can be established... or until we have at least an acceptable draft of a Governance CIP indicating broad support for such parameter additions & their feasibility.

I concede that this still very much on the border of what may be acceptable for a CIP and will defer to the CIP editors to make that decision. Also, I would be happy to help contribute to that Governance CIP and I have some ideas for that, but was waiting on a finalized version of CIP-???? | On-Chain Surveys and Polls before building out a proof-of-concept for what I have in mind.

[rphair]

@Cerkoryn I think there you have the boundary of why a CIP could be considered both acceptable and not acceptable for this issue, and therefore a key consideration to address in a Governance category CIP:

• It should be acceptable if you reason that "that parameter is just a number" and all the CIP would practically do is indicate that the parameter comes from the chain... and therefore acceptable (i.e. a "technical" CIP).
• However, others would argue (and I personally would fear) that a CIP changing the context of how this parameter is derived (from parameter updates vs. whatever NCL processes, checks & balances exist today) is replacing one human convention with another — with potentially much human disagreement over influence lost or gained — and therefore not acceptable (i.e. an "organisational" CIP).

This is why also above in #1129 (comment) (where I haven't tagged anyone yet) and over in #1131 (comment) which also suggests parameter additions as if they are a purely "technical" thing (where I tagged @katomm @thenic95 as veterans of community parameter discussion) I've invited those with experience in parameter governance to indicate what it would take to establish a safe & generally acceptable best practice for CIP parameter additions.

Once we have that, we can apply it to the CIP process immediately and use the same reasoning to fill out the more difficult parts of the pending Governance category-defining CIP. I'm hoping to have more time to devote to this soon — once some constraints on my own workflow have been lifted — and then will look forward to getting that draft posted & open for community feedback including @Cerkoryn your in-progress ideas.

---

waiting on a finalized version of #1107 before building out a proof-of-concept

On the potential relationship to:

• CIP-???? | On-Chain Surveys and Polls #1107 (comment)

... I've tagged the author again to indicate we're only waiting on his fixing of the metadata table entry before promoting this to candidate (pending other editors' agreement) and continuing review.

[rphair]

@Ryun1 @perturbing (cc @Cerkoryn) I don't want any uncertainty over how to involve other governance groups / processes / stakeholders to delay the review requested in this PR... and in fact discussion at a well-attended meeting might even help overcome any obstacles we face in getting the right review for the governance aspects of the problem.

So even though we can't be sure this is an admissible CIP yet, I think it should still be marked for Triage to bring those questions into the next meeting (as time permits, and perhaps without yet being able to grant a CIP number / candidate status): https://hackmd.io/@cip-editors/127

[rphair]

This has been confirmed at the CIP meeting today by the quorum of 2 editors present (cc @Ryun1) based on the reasoning supplied in #937 (comment) ... I've recorded those reasons there to ensure they can become part of the Governance proposal draft somehow since this proposal, as expected, has provided a good litmus test for acceptability as technical governance.

Though there would be a "can of worms" over which human influences might be changed along with the "seat" of the Net Change Limit, these would be common in inclusion of any CIP in any hard fork. But since we don't want to interrupt any discussion of Protocol Parameters in general, @Cerkoryn through the PC has agreed to:

• ask the Parameter Committee if there are any objections to this proposal: especially in considering whether or not it would be a purely "technical" change to adopt this CIP;
• also ask if any of the PC members would please consider reviewing the CIP itself (I've attempted to tag some above but we could try again now more emphatically).

Thanks again @Cerkoryn and please rename the CIP directory to CIP-0173 and update the link in your original posting. 🎉

[rphair]

Suggested change

	Category: Ledger
	Category: Governance

Not much to change in Ledger to make this a reality: so most of the discussion around this will be in the Governance category & so that category will remain applicable as long as it continues to be clear this is only a technical change to the data structure used in Cardano governance.

[Cerkoryn]

Based on Parameter Committee feedback, I am contemplating the idea of changing this CIP to let the NCL be enforced by the ledger instead of the Constitutional Committee. I think in that case it would still belong in the Ledger category if I am not mistaken? More info here.

[rphair]

yes @Cerkoryn I think it would indeed revert to Ledger in that case: since we always try to target the CIP category to a product of 1) who needs to do the most work to achieve that improvement * 2) who most needs to provide review to establish feasibility of a CIP or completeness of a CPS. (cc @Ryun1 @perturbing to concur)

A confirmed plan to enforce an NCL parameter in the Ledger would indicate the Ledger category just as much as for CIP-1694 itself (which I believe should still remain outside the scope of the new Governance category by the same reasoning). — cc @lehins

In the meantime I'll decategorise this now (i.e. the GitHub label), to force us to re-assign the category after that decision is made.

[rphair]

@Cerkoryn, as noted from the meeting, we also need to classify which Parameter group this is in since it would have an effect on the boundaries of how the parameters can be changed... I recall something like the choices being "economic" vs. "technical"? Please give us more details about that when you're ready & got all the necessary background information.

[Cerkoryn]

Seems like the parameter committee thinks the governance parameter category would suit this CIP the best in its current form. I posted more info about it here.

[ptrdsh]

Thanks for this initiative. NCL is a thorn in Governance in general and this would alleviate some of this.
However, I believe itd not be required as CIP, or as new parameter, because the constitution doesnt forbid the (current) NCL to be a formula, which means this concept can already be "enabled" through an info action that defines the NCL as [NCL=someFormula], indefinitely.
This would also allow us to keep the lane more open for alternatives to NCL altogether, as the whole concept is quite "questionable" anyway.

Assuming we would nevertheless introduce these parameters, I have a question on the formula. I might not understand it at the moment..
The cap formula is defined as: somePercentage * TreasuryInflowsInLastPeriod, whereby somePercentage could be >100.
This would be a fine approach if TreasuryInflows would be closer to where the chain needs them to be, and not expected to change drastically. It also doesnt reflect the need for more Treasury Funding early for "investments", and less Treasury Funding later for "maintenance" - as was/is the idea behind the staking reward (subsidy) formula.
Defining the cap as its defined now, would result in basically the same problem as today where we need to revisit the NCL every year, because today's chain revenue (treasury inflows) is very low and the NCLpercentage would need to be set at thousands of % to be equivalent to todays wishes.
If the spend of the treasury results in what we want - namely more chainRevenue - the percentage would need to be adapted very frequently.

In my views, a better formula would be:
chainRevenue + somePercentage * Treasury
This scales smoothly with the inflows while ensuring a transition (a smooth decay) from early subsidies to maintenance.

[Cerkoryn]

Assuming we would nevertheless introduce these parameters, I have a question on the formula. I might not understand it at the moment.. The cap formula is defined as: somePercentage * TreasuryInflowsInLastPeriod, whereby somePercentage could be >100. This would be a fine approach if TreasuryInflows would be closer to where the chain needs them to be, and not expected to change drastically. It also doesnt reflect the need for more Treasury Funding early for "investments", and less Treasury Funding later for "maintenance" - as was/is the idea behind the staking reward (subsidy) formula. Defining the cap as its defined now, would result in basically the same problem as today where we need to revisit the NCL every year, because today's chain revenue (treasury inflows) is very low and the NCLpercentage would need to be set at thousands of % to be equivalent to todays wishes. If the spend of the treasury results in what we want - namely more chainRevenue - the percentage would need to be adapted very frequently.

In my views, a better formula would be: chainRevenue + somePercentage * Treasury This scales smoothly with the inflows while ensuring a transition (a smooth decay) from early subsidies to maintenance.

@ptrdsh perhaps I should clarify better in the CIP, but "revenue" is defined as fees + reserve emissions, not just fees alone. So as emissions dwindle, revenue dwindles, and the ability to spend more also dwindles. Similarly, increasing fees via more usage would allow for greater spending (if we wanted it) which incentivizes exactly the right behavior for driving usage to the chain.

For reference I built a flowchart on Cexplorer that calculated the 2025 revenue the way I described it available here.

You can see via mouseover that the treasury revenue (inflows) for 2025 was approximately 283M ADA. If we were to set the NCL at 100% then this would be the spending limit which is right in the ballpark of where the spending limit is being proposed anyways.

[Cerkoryn]

@rphair comments from the Parameters committee are generally that this CIP is a "Good approach for tomorrow, but not a good approach for the day-after-tomorrow."

It was recommended that perhaps this CIP be re-worked to allow the ledger to enforce the withdrawal limit, rather than having to rely solely on the CC as an enforcement mechanism. This would be a bit of extra implementation work, but would alleviate some pressure on the CC and allow us to lean into the "code is law" ethos of Cardano.

It was also recommended that if these parameters are introduced they would best fit in the governance category with a 75% threshold requirement for dReps to change it.

In any case, I am happy to entertain alternative versions of this CIP depending on feedback.

@ptrdsh @kevinhammond Please feel free to add if I missed anything, thank you.

[ptrdsh]

@Cerkoryn

"revenue" is defined as fees + reserve emissions

aahhh.. yeah that explains a lot. was confused that noone else flagged this before me. Then indeed its similar to my formula and decays sustainably. Yours piggybacks on the SPO incentives plus it self-references YoY, which I have to wrap my head around first. I think I like it, but my gut says caution.. should I muster up some smart thoughts, Ill let you know.

I havent seen the Sankey Diagram on cexplorer yet - holy shit its nice! 🤯 👏

---

Going a few sentences deeper into

"Good approach for tomorrow, but not a good approach for the day-after-tomorrow."

than just the "save CC some time" argument:
I want to express concerns about the long term value of this CIP, given that the NCL concept as a whole assumes an (annual or timebased) budgeting process, which is a corporate construct that doesnt reflect the needs of a decentralized, fast evolving system very well. It may be the best treasury control model we have right now, but its actually terrible. I, and noone I believe, has a better solution atm, so my argument is kinda void from the start, but Im afraid of locking us into the NCL "target spending" concept too deeply, should we come up with a better treasury control model at some point.

[rphair]

Governance category removed pending discussion about whether this will be done in Ledger as per #1129 (comment) & #1129 (comment).