OpenGov 2.0 looking for feedback

hello polkadotters,
I know that many of us are observing the unfolding drama on OpenGov, which has revealed numerous flaws in the current plutocratic government system. I would like to contribute some ideas to the discussion. I am very interested in everyone’s perspective on this, especially regarding possible flaws in these forms of governance models

Council-Based Governance model
Primary Actors:
Dot Holders: Represent the average users or stakeholders in the platform.

Council Composition and Structure

  • Council Size: Each council will consist of 12 members.
  • Term Length: Members will serve six-month terms.
  • Rotation System: Members will rotate responsibilities periodically to ensure fresh perspectives on each proposal.
  • Categories: Separate councils will be established for different operational categories, such as media/outreach, devops, etc.

Selection Process

  • Election Frequency: Elections will occur every six months to fill six of the twelve seats, ensuring overlapping terms for continuity.
  • Voting System: A ‘one dot, one vote’ system will be implemented, where each community member has a single vote (represented by a ‘dot’) per council category.
    Voting Limitation: Members can cast only one vote per dot, preventing vote concentration.
  • Rank Choice Voting: An optional rank choice voting mechanism may be considered to allow voters to rank preferences, enhancing decision-making quality.

Council Responsibilities
*Community Development: Councils will focus on fostering community growth within their respective categories.

  • Treasury Management: Each council will manage and allocate funds for their category from the treasury.

taking this a step further

balance Council-Based Governance model

Primary Actors:

  • Dot Holders: Represent the average users or stakeholders in the platform.
  • Parachain Builders: Represent the developers and entities directly building on the platform.

Same Selection Process for the counil

Selection Process for parachain builders

  • SelectionFrequency: Selection will occur every six months to fill six of the twelve seats, ensuring overlapping terms for continuity.
  • Members will be selected based on core time purchased or time spent on the chain, with a possible candle auction system, currently employed by Parachain auctions, being considered.

Treasury Allocation and Management System
Parachain Builders’ Role:

  • Allocation Decisions: Parachain builders are responsible for deciding how the treasury funds are distributed among the various council groups. Their technical insight ensures that funds are allocated to areas with the most potential for growth and development.
  • Oversight and Strategy: They may also set strategic priorities for funding, guiding the overall direction of platform development.

Council Groups’ Responsibilities:

  • Funding Management: Once the treasury funds are allocated to them, individual council groups decide on the specific use of those funds within their domain.
  • Autonomy: Council groups operate with autonomy in spending decisions, enabling them to address the unique needs of their respective categories.
  • Accountability: Councils are required to report back on their expenditures and the outcomes of funded initiatives.
1 Like

The reason for shifting away from the council defined in Gov1 was the lack of resilience + bottleneck of proposal volumes created due to the time constraints that a centralized body like the council suffers from.

I understand where you’re coming from, but going backwards isn’t a reasonable solution.

I agree with the idea of having different councils for different categories ( sub treasuries). For example, we can have a “wallet council”, where the council members are team members from popular Polkadot wallets like Nova, Talisman, etc. That way, if someone asks for funding to build a new wallet, the council can determine if they the proposal is reasonable. However, what would prevent the council from rejecting wallet applications simply because they don’t want more competition in the ecosystem? Perhaps the wallet council can have 40% of its members from wallet teams and the rest are other community members? That would make it more balanced.

I think there should be a “general” treasury category that doesn’t have a council. That way, we have a mix of sub treasuries with councils and a general treasury without a council.

1 Like

Should there be term limits on council members?

1 Like

Hey, thanks for the feedback, but I disagree that this would be a step backwards; it’s more like sideways, and maybe it’s just my lack of understanding, but how does a council vote vs. max vote change throughput? Proposals are still being made the same in both, just who decides.

I also think this model opens up for a more decentralized Treasury as it splits the treasury into multiple smaller treasuries, spreading the attack vector while at the same time keeping the voting power of the DOT the same, if not more, as a bad actor would need to take control of the majority of the seats per council election.

Again, maybe I am misguided; my brain does tend to think differently than most; that’s why I do highly value your feedback. If you can help me understand how you see it, It would be much appreciated.

Yes, that would be great, but I don’t know how you would implement it, as someone could just create a new identity every time their term limit hits. We run into the same issue as the one account, one vote.

For you issue on council corruption , it hard to say for sure but I still believe In the one vote per dot. so seeing this I would expect a backlash from the community and the whale :whale2: in the next election cycle plus that the benefit of rotating council voting blocks I may not have made this as clear as would have like but in a council of 12 only 6 would vote for each proposal and the council members who vote would be picked randomly so you would need the majority of that council seats to be corrupted

Can you please elaborate on the lack of resilience + bottlenecks?

1 Like

For me it would be sad to see a system as expressive as blockchain governance revert back to an older form of governance like the republic.

The overall goal of a governance system is to accurately approximate the aggregate will of its constituents, and a delegated democracy does this with a lot more granularity than any council ever could.

Delegated democracy is new, and what we’re experiencing now are the types of healthy growing pains that lead to super structures laid on top of it. Things like voting blocks, coalitions, powerful delegates. All this will happen in time. We’re still VERY early stage.

That being said… I’m not against us establishing collectives to kickstart this type of thing. For instance, the fellowship is a great example. It’s a group of individuals who are committed to improving the network. Are they the only ones who can? No. Are they the only ones who decide things? No. Will there be separate powerful groups that pull in different directions in the future? Yes. It’s healthy.

I would suggest we do create other collectives, but as technical report entities. They write technical reports, release them, signal their intention on voting, then vote. If they do well, people will delegate. If they don’t, other more naturally occurring groups will emerge.

1 Like

Good point. Should council members be doxed? That would solve the problem.

how does a council vote vs. max vote change throughput?

A 12-person council has limited bandwidth and would be expected to review every proposal.

It works on majority approval with the need for at least 51% to vote - where if the council members for any reason fail to vote, the proposal fails by default.

OpenGov where any DOT holder can vote - allows for proposals to pass more often, even if certain holders are unavailable for any reason, other (potentially smaller) DOT holders can continue voting on proposals to reject/accept them.

this model opens up for a more decentralized Treasury as it splits the treasury into multiple smaller treasuries

I had missed this part, apologies.

Yes, this is inline with the idea for having several focused on-chain collectives and is probably the direction in which things are headed.

The key differences are the larger size and the hierarchical structure of a collective, which I believe is better suited to carry out these functions than a flat council that’s purely elected.

Can you please elaborate on the lack of resilience + bottlenecks?

It’s a lot easier to convince or force 12 people to collude to disrupt operations v/s a decentralized community of DOT holders.

For bottlenecks, it’s the same reason explained in the first part.

That said I do believe that having focused, merit-based collectives (instead of a council) similar to the fellowship would be better than expecting OpenGov to make good decisions in all domains.

Would you say your ideas are similar to the ones outlined here?

1 Like

Thanks for all the reply they mean a lot,

Polka.dom and batman I get the desire to move forward but I don’t think this is the way current system which maybe new for Blockchain but is a very old governance model in history is a move forward

Polka.dom I don’t think this is growing pains but a flaw in the system. But we will see my fear is all this drama create hopelessness among smaller holders and the core community

Batman as for the bandwidth problem I think the rotating council who vote solves that plus the 12 was just and example it could be 100 council members with still x council members voting per proposal but I get what you are saying about moving fast and breaking things which is this model

I like the collective model I’ve just have not read anything about how these these collective members would be selected but it would be a good middle ground :blush:

Chris, yea I don’t think we should be doxing people in any scenario but more so when it comes to giving out assets as we may not have evil intentions that doesn’t mean others would not try to put pressure on individual council members

Thanks again everyone I am really enjoying this debate :blush: