I don’t want to sidetrack this discussion too much, but I have some observations I wanted to share based on
my experience
this is a throwaway account , but I’m an ex-employee from somewhere or other who was on the genesis council for both relay chains and many parachains, and left both Kusama and Polkadot councils at different points in time, largely due to the issues you are trying to avoid recreating. Me and some friends in the ecosystem also ran a small governance experiment with a very different model with largely successful outcomes - that ran out of money
.
in the rest of the ecosystem. Firstly, I want to commend the commitment you are making to truly decentralize your governance process - as you mentioned, many projects in the ecosystem remove sudo and claim decentralization, but simply operate a council+tech comittee model with their employees taking most of the seats/maintaining decision making power through informal influence - I think the model you are proposing could avoid some of that, but I have my concerns about how your first requirement/solution - giving more voice to builders with a gov token that is rewarded based on dapp staking ratings - would work in practice without careful consideration, and want to point out a pretty glaring issue that doesn’t seem to be addressed anywhere here, really.
The big issue with governance decentralization attempts in this space has always been complexity and cognitive burden - or, as @Jaski proposes:
Things are a little bit different with @hoonkim’s proposal of having a separate, non-transferrable, expiring governance token, but in the larger context as well, I have a different opinion regarding involving token holders only when needed. I believe this leads to outcomes like what we’re seening in OpenGov on Kusama currently - where professional governance delegates and perticipants who are supported by large ecosystem actors end up making all the decisions, and while that sounds like it meets your requirements, of builders and active participants having more influence, in practice it means “organizations and builders focused on engaging in governance, or who have the resources to have resources dedicated to engaging in governance, have a permanent advantage over organizations that focus on building and adding value”. That is obviously an undesired outcome.
An alternative I’ve long been proposing can basically be described as “doing as much onchain as possible, but making it as simple and unobtrusive and minimized as possible”, this is partially about changing the complexity of UX and interactions, but also largely around minimizing the true cost of making decisions and what is at stake when you do.
I assume we agree that:
- we want every legitimate participant of a governance process to willingly and consistently engage in it.
- we don’t want it to be possible for non-stakeholders to significantly manufacture consent/cause conflict/sway the decision making process.
The way I see that working is:
- the process for decision making in governance should be fast, cheap (cognitively and financially), and require little to no “coordination” - this means things like timing of responses within the expected window should have little or no effect on the outcome, this means that participants should be able to make a proposal, or make a decision on a proposal with exclusively information available onchain (identities, proposal metadata) and shouldn’t need to access or participate in, or be aware of offchain information or discussion other than what is linked to from the chain. I see the referenda and delegation pallets as used in opengov a pretty ideal candidate for this, since it’s all about hitting thresholds over time and doesn’t need participants to coordinate on timing or communicate much, but I don’t have a simple solution on how to employ them in a private context.
- a participant should be able to do everything they need to do regarding governance on the same page, submitting a single transaction, and requiring minimal followup. The way I can imagine this working would be using a single UI page (and/or governance wrapping pallet) that filters all available proposals to decide on that you have any influence over, presents all available metadata for that proposal, presents each action you are capable of taking on that proposal as a single button, after you have addressed all of those actions available to you if any, you are shown anything you can propose yourself, which you can optionally choose to do, before sending all of your decisions as a batched extrinsic.
In my experience of coordinating this kind of process, it has generally been an issue and large source of unneccesary friction to direct people to do something like “make a proposal on page A, post a message in chat B and forum C, which you need to monitor, and then talk to everyone in this pre-established group of influencers X to progress your proposal to stage D, where after you wait some indeterminate period of time for maybe getting approved you then need to manually withdraw half your payment onchain and then make a report in B and C and to everyone who is in X if you want the rest of your payment.” saying this kind of thing to anyone just makes the only people willing to stay around the “institutional governance manipulators” I described earlier, and scammers who don’t spend any time building and are fine playing governance games for a payout and then leaving.
The process, in my eyes, should ideally be, based on how I understand Hoon’s design:
- go to page A, make your proposal there, including a link containing all the requested context,
- you will know if it has been approved within X days
- you will begin getting paid in Y days
- after that - go back to page A every Z days you’re working on the project with a link to an update and to claim your payment - you will be asked your opinion on other projects and then you can provide your update to your project.
- If enough people/the council think it’s necessary to do so, your next payment will be your last, you will know this within X days, but you are still guaranteed that next payment, so you are expected to continue working within those X days.
In this scenario we abstract all governance decisions away to “projects opinions on other projects” in a queue of decisions they need to make every time they are claiming a bounty payout, guaranteeing a steady stream of governance participation by builders on other builders projects, all in the same place, and as part of a process they willingly want to participate in - think of it as the same kind of logic we see with validators and parachain teams being strongly encouraged to payout their nominators/contributors, even though they don’t technically have to, since it’s tied strongly to their own success and costs.
This works as well for company representatives on council, who I would assume are busy people with full time work other than engaging in blockchain gov - they would just need to visit the gov page once in a while, decide on their current queue of decisions, maybe poke one another for the occasional additional context - I won’t pretend this won’t happen, but it’s clear in this design the council isn’t making the micro-level funding decisions but rather operational ones and vetoing? Am I misunderstanding? It’s not clear from your description what their exact responsibilities are tbh.
tl;dr - Basically do gov fast and design for builders who value their time and aren’t playing politics and arguing on forums constantly.
longer tl;dr - you’re using a gov token for decisions, so we don’t need to worry about people being afraid to participate due to financial opp. cost. Just use referenda pallet and tracks for decisions, gate proposal making and payout claiming behind having votes for all proposals for gov token holders, and throw out the older UIs, make something card based with a queue of cards for each un-voted-on proposal, and submit all decisions and proposals at once as a batch. Make voting part of the proposing process and vice-versa, and make proposing something that is stupidly easy to do (cheap but not free), and stupidly easy to reject (because you aren’t killing someone by rejecting their proposals).