Percent Dominance Staking as a Pipeline for Proposals

Consensus Check
1

I think there’s a more organic way to get quality ideas turned into proposals, I would like to outline it for you and get any feedback, as I am currently working on a UI to showcase as a demo. This is something that I have been thinking about a LOT regarding how voting takes place, particularly since I first saw the “UniPig” page…

First off, we don’t want to turn this system into the one we’re trying to step away from. That means that every UNI holder should have a say from start to finish, even if they’re putting 100 UNI against 100,000 UNI. I think a high bar for quorum helps ensure that voters put in due diligence to form ad-hoc coalitions to get a proposal passed. That is after all what we’re ultimately working towards with decentralized governance systems. I do however, think there is a more elegant way that we can vote that is more natural and ensures that large stakeholders do not form monopolies on proposals.

I think a more robust UI to initiate proposals would:

  • Churn out more, and decide on proposal ideas quickly
  • Give voting users an opportunity to find like-minded users to form representative voting parties that can come together with to pass a proposal through, and then go on their ways until they meet again.

I’m picturing a “Delegation Portal UI”. Any stakeholder should be able to post a “position”, it’s a step below a proposal and represents a rough idea that through discussion gets fleshed out. You can allow filtering of “positions” based on topic, and the posting user’s UNI holdings to better choose delegates. This would allow for proposals to grow organically.
The current model is pretty binary. You can make a proposal if you have a huge amount of UNI. THEN users get to delegate. Proposals should be “grown” based on community demand instead of put forward by large stakeholders only.

Remember this? https://unipig.exchange/
If you didn’t see it when it came out, take a look at it just to get an idea of part of what I’ll be discussing throughout this when it comes to percent (%) dominance and pools.

Here’s the outline, this does not involve staking your UNI, the process of “position” voting is separate from proposals, think of it like Y Combinator for proposal ideas using abstract tokens that represent either a yes/no vote.

  1. A time is set for “positions” to be laid out, it lasts for X number of days. You can log in, and see a grid view of all the different positions, post your own idea, etc.
  2. At the same start time, all users are airdropped a set amount of UNI-YES tokens, and an equal amount of UNI-NO tokens.

This is where unipig comes into play…

  1. To add a position to the portal, you must delegate all of your UNI-YES tokens to your position, starting it off at 100% YES.

Each position has a discussion board so ideas can be expanded upon.

  1. After a brief period of time, open quadratic voting begins. This is now a friendly competition of staking YES/NO positions. Those who placed positions can still vote NO on others, but they cannot support other positions as they staked all allocated UNI-YES tokens in theirs.
  2. Once this is set in motion, the YES:NO ratio will change more organically based on how people are voting and how discussion takes place.

Just like liquidity pools, you can move your stake (perhaps with a time-lock of 24 hours).
However, unlike liquidity pools you are only staking in one side of the pool, either YES or NO, with the intention of having staking dominance by the end of the voting period.

  1. If at any time between the start of the voting period and the end of the voting period a “position” drops below a certain % YES stake for some amount of time T, it is removed from the cohort (this is the reason for the delayed start in step 4.)

This frees up the positions that weren’t going to pass and lets users focus on the ones people are competing back and forth on.

You can move your votes around to different position pools, but if a pool is closed because the % dominance of NO was > 50% for too long, all abstract tokens in the position are burnt. This intrinsically removes the incentive to “pull out” at the end and keep your votes instead of having them burnt, because otherwise you would lose % dominance at the last minute.

  1. At the end of the voting period, the positions still standing have made it. They will (in some form) go on to the proposal phase. During this time, the community goes through and decides whether or not there are redundant positions or if certain positions should be combined into meta-proposals based on similarity, or if together they create a more robust proposal, etc.
  2. After this the proposals get set. How everyone staked their abstract vote tokens during the competitive phase is revealed to the community.

This allows participants a chance to find others that agree with them on ideas, and a potential for ad-hoc communities to form.

The competition based position phase using non-value abstract voting tokens is important for organic growth, and to keep large stakeholders from controlling the pipeline to proposals. It also turns the voting process into a staking process that we are familiar with, and is unlike any voting that I can think of.

I knew when I first saw the UniPig site that it had huge potential for something and I think the principle behind it could make for a fair and organic growth of ideas and a system of voting that provides the same opportunity of entry to every single user through the “position” phase and the UNI-YES/NO staking tokens, which are of course only usable within this single UI.

Again, you’re not staking actual UNI during the position process, it uses valueless tokens for a gamified version of voting by staking

5 Likes
2

No thanks, don’t want to stake uni on votes if I understand your proposal correctly.

1 Like
3

You don’t understand it correctly.

This is not an alteration to the way voting is done on proposals and uses valueless tokens that are just an abstraction of approval or disapproval.

The intermediary process uses a separate token used specifically within a system that works more-or-less like a filter for ideas, using a “gamified” version of staking in which the YES side and NO side try to gain a majority staking dominance. You’re not adding collateral, each user is just adding to one side of the “pool”, not both.

The fact that there is a limited time to stake on all of the ideas, which cycle like cohorts, lasting for a set amount of time. The fact that voting power is diminished the more you add to one idea promotes interaction outside of your top one or two ideas of the cohort.

1 Like
4

I’ve simplified parts of the body of the original post as well as the title to reflect your feedback.

5

Thank you for your explanation. I think I understand more. Is it kind of like a temperature check but instead we vote to see what the people think of future proposals? Sounds good.

6

I’m sure it’s more nuanced then what i’ve mentioned in terms the process of it

7

Kind of. I really want to get a demo UI up and running as I think a visual is necessary to really explain it.

At it’s core, it is intended to be a more effective method than forum posts to turn ideas into proposals; a way for anyone to submit an idea no matter how broad or narrow it is and basically, as you said, get a temperature check on it. These don’t have to be full proposals.

Other participants would then use valueless tokens who’s only purpose is to stake a YES or NO vote on that idea. Once the “temperature check” voting period is up, the community then has a sorted list of what ideas were most liked.

I thought about the way legislation is developed in governments now. One piece of legislation (proposal) may include multiple ideas within it. At it’s core, that’s a great way to get rid of bloat in the number of proposals, but the problem with the way governments do it is The People have no idea what bits and pieces go into a complex proposal.

I’d like this develop in a way where we can put together more complex and nuanced proposals based on ideas that have already been vetted by the community.

Once we have the ideas that passed this stage, we can get together, look at the list (sorted by YES:NO ratio) and have discourse like the following:

Person1: “Idea3 and Idea12 are very similar, let’s refine those and combine them into one.”
Person2: “Yes, but look at Idea6, it only had 56% favorability on it’s own, but I think together they complement each other. Maybe we combine those two into one proposal?”
Person3: “If we implement Idea6 into the proposal with Idea12, there’s really no need to have Idea3 in there.”

I hope that was helpful. I know it’s a pretty abstract idea so I hope to have a demo ready this week.

1 Like
8

I agree with you that the governance does need some structured way to make coalitions as you mentioned.
A demo would be nice.
Good initiative!