Kusama Treasury Follow-up Analysis: Continued Budgeting Incompetence

Ecosystem
,
21

I don’t feel you are being quite fair here.

Note that I did review, provided feedback, and found errors in your branch which started this thread.

I did not know you had made a PR, but that is great, it is a step in the right direction.

Note though that just because you made a PR, does not mean that anyone is liable for doing anything, it is just the correct first step. Similarly because you have a voice, people are not required to listen. Also, as you are seeing, the Runtimes which control polkadot have finally transitioned into a Fellowship repo, outside of Parity. So it might make sense why your PR in the wrong repo would not get the activity you might expect.

Rob makes a next step recommendation which I agree with:

  • Get OpenGov to ratify the RFC with system.remark (if rejected/ignored by Fellowship)

You mention in your PR:

These reconfigurations are what many believe is the first step in changing the paradigm of Treasury spending.

You can bring truth to that statement by showing “many” do agree with you with an on-chain signal of agreement.

You say that these are “trivial changes”, that it isn’t “rocket science”, and that this “barely changes anything” but indeed this somewhat shows an incomplete understanding of the sensitivity and importance of the runtime. Remember that simple misconfigurations have led to chains being bricked and exploited within our ecosystem. And I did catch errors in your PR.

Why wasn’t Gavin criticized when he didn’t code these parameters into storage to be determined by governance?

It seems you do not really respect the idea of the fellowship, and the time and expertise that individuals in the fellowship have spent to get into the fellowship.

But Gav is rightfully the highest level member in the fellowship, representing his over 7 years developing the network. You can note that he has among the highest code commits and reviews across all repos which power the Polkadot ecosystem, the obvious ones are:

Unlike many other founders in the Blockchain ecosystem, he is actually a builder, and every single one of his PRs get reviewed by peers. And his PR did go through a quite large code review, also digging into parameters, of which only a small fraction is captured here:

Note that PR above is only introducing the OpenGov system to Polkadot, but it had already had multiple other reviews for the creation of the pallets in FRAME, the deployment of the system into Kusama, and everything in between.

Furthermore, these parameters were discussed and reviewed with researchers at the Web3 foundation and other engineers at multiple in person working sessions. I believe there are paper trails of these things such as pictures of whiteboards i have seen attached to blog posts, and screenshots like this i have found in my history, which are more than a year old.

Is it possible the configurations are wrong? Of course. A lot of this is theoretical, and can only be tested in reality. However, these configurations DID go through a rigorous review and feedback process which you are trying to avoid.

I understand that you can be angry at the struggles of decentralization. It is a strictly harder process with more overhead, less certainty, and it is something which Polkadot is pioneering, and thus we are hitting every bump along the way for the first time. But the most important property is that this kind of process is resilient to malicious actors and other incumbent powers.

1 Like
22

Cannot agree more with what Shawn is saying here.

FWIW, I just opened an RFC for adding new collectives. Perhaps the Fellowship should adopt a similar RFC for proposing and approving runtime parameter changes, e.g.:

  • A parameters track with similar support/approval criteria to Root, but lower decision deposit and no hard power. As in, would only be used to make remarks that indicate the body’s instruction to the Fellowship to update some parameters.
  • A new Fellowship RFC for each parameter change. Should the Fellowship not pass it using its Fellows origin, an on-chain remark from Root would make clear the desire of Polkadot stakeholders.

Non-Fellows should have a path to signal the stakeholder body’s desire (via public referendum) for certain changes. The Fellowship should adopt/accept/implement those changes, as long as they are safe from a technical perspective. As part of their mandate, they should however refuse a change that is technically unsafe, which could lead to a non-Fellowship runtime proposal. As mentioned several times though, that should be a last resort and essentially a vote of no confidence in the Fellowship.

23

I want to take the time to thank everyone who has been part of the Treasury management discussion since it emerged during Q1 of this year. We have come a long way and a lot of ideas have been talked about and even tested on chain. My only regret is that we haven’t seen much systemic change, only change in the behavior of a few token-centralized entities. As such I just want to express my continued commitment to the ecosystem and to a sustainable and effective Treasury.

I also want to take a moment to apologize for some of my behavior. I understand that I have been hotheaded at times and may have offended a few key players in the ecosystem. Allowing my passion to enflame the discussion was not correct and moving forward I will attempt to dull my sharp edge when challenging ideas.

Now that the dust has settled, allow me to summarize my current opinions on the topics discussed so far:

  • Regarding the Fellowship, I now understand that it is a vitally important group of individuals who are acting in good faith across the board, afaik. At the onset of my setCode referendum, I felt frustrated that my tact was being criticized. At the time I thought a root track referendum was my only option for making any real change since I am not fluent in the Polkadot stack and I thought, from my past trivial PR experiences, the Fellowship would never listen to me. Little did I know there is a reasonable process for someone like me that only requires a little bit of initiative to push engagement from the Fellowship: RFC → PR → Merge & Release.

  • Regarding the Treasury, I still believe we should reconfigure the limited spending tracks as I suggested to effectively cap the spending rate. However, with Jonas’ proposal to adjust the inflation model to boost revenue to the Treasury and expose track params to openGov, I think we ought to wait until these features are implemented. A part of me is frustrated that we have to wait, especially when Kusama is supposed to be fast and loose, but I suppose patience and temperance are keys to success.

  • Regarding the process for change, I think there needs to be far better documentation laying out the proper avenues for people outside of the Fellowship to suggest changes in a meaningful manner. I don’t think the Fellowship or Parity ever made any earnest attempts to disseminate awareness of this process to the masses. I think people and organizations within the ecosystem should make publications about the proper way to make suggestions for runtime/ client changes. If anything was made clear through all of this it’s that almost no one outside of Parity/ the Fellowship knew there was a proper way.

Finally, I’d like to frame my behavior in some personal context. As some of you may know, Steeber Solutions was funded for Project Gweihir in January and we shipped all of our deliverables which were showcased on AAG #41. Building Gweihir gave our contractors, our business, and my family financial security for the better half of a year. In return we built scalable & decentralizable infrastructure that successfully relayed data from Kusama to Sepolia with a simple smart contract call on Sepolia. However, in response to HACNA and other NAY whales totally strong-arming spending referenda on Kusama, I decided not to pursue further funding from the Treasury to complete Gweihir’s ultimate vision of adapting all of Polkadot’s API to a Chainlink oracle on Ethereum. I didn’t want to do a song and dance just to be NAY’d and I also didn’t feel right asking for funds when the Treasury was bleeding out. So I shifted my focus to fixing the Treasury so that I could ask for funds with a good conscience and get back to building Gweihir. As a result, I’ve been in limbo not really knowing what to do or how to actually make meaningful change. Also frankly, I’m getting crushed financially with the expense of all the infrastructure I’m shouldering now; close to $1,200 per month. I really don’t want to spin down my validator, collator, or Gweihir but I’m running out of options. So the pressure within me to fix the Treasury builds day by day, monthly bill by monthly bill. But I suppose it’s out of my hands. Perhaps I should swallow my pride and throw my hat back into the Treasury for Gweihir’s continuance…

In any case, my next initiative is to comb through all of the discussions and contributions made about Treasury management throughout the last 6 months to discover tip-able individuals. As one of the people helping spearhead Treasury management, I feel personally responsible for making sure that everyone who provided value in this endeavor, who isn’t already on a payroll, is recognized and compensated for their time. I really hope the ecosystem will be willing to spend some of the Treasury to reward these individuals. So keep your eyes peeled on Polkassembly for a discussion (hopefully soon)!

Solemnly yours,

Adam

6 Likes
24

I think those headaches are desirable sometimes, it might be extra work for the fellows but some changes should not be part of the regular release schedule and it’s reasonable to “squeeze them in” so they can be evaluated in isolation. Could be that the fellowship is just missing an extra process to account for “controversial updates” that need to be released in isolation to let token holders decide if they want them or not? E.g. I still think that OpenGov in Polkadot should have been it’s own runtime upgrade instead of getting mixed with the usual bug/security fixing.

Another suggestion I have is to be less strict with Kusama and let the community (ab)use the runtime in whatever way the code allows, I don’t like this position of “you are with us or against us” and assume a that an external runtime upgrade already means the community doesn’t trust Parity/the thechnical fellowship, feels very defensive, we can leave that to Polkadot. Kusama is not Polkadot, a proposal like Adam’s is understandable to oppose it in Polkadot but it should pass just fine in Kusama(given a champion confirms it won’t brick the chain), instead of crushing an active community member’s spirit because he didn’t follow a non-existing process, we should embrace and encourage this kind of participation in the canary chain, active community members that live the problems of governance first hand are in great position to bring up points of improvement, it’s with this kind of proposals that the fellowship can identify important needs for the community and change parts of the code accordingly. e.g. At the time of implementation it probably made a lot of sense technically to have tracks configuration burned statically in the runtime for performance but it might be that it’s ok to incur in a performance penalty if that means making things more convenient for active token holders.

1 Like
25

The sooner people accept this the faster meaningful progress will be made.

2 Likes
26

Agree with you rich