Proposal 1: Feedback/Discussion for going forward

Now that proposal 1 has come and gone I have set up this forum post as a place for us all to be able to come together and discuss/provide feedback on the proposal, any potential issues faced and any changes that could be made going forward to help better align the community for any future proposals going forward.

Please try and keep conversation polite and on topic

3 Likes

It seemed like there were several reasons why this didn’t pass, I’ll try and list a few reasons why but this won’t be exhaustive. I’ll attempt to write this as neutrally as possible.

  1. Lack of Uni voters delegating, the good new is this proposal has raised awareness that delegation was required before you can vote.

  2. The rider concern, some Uni voters were unhappy with the fact that two different proposals were combined into 1.

  3. The reduction in Quorum was a concern that some users saw as centralisation risk.

6 Likes

Completely agree I think if there were a way in the future to be able to get the message out to Uni holders far and wide this would prove beneficial to the community and allow everyone to feel involved in the decisions made.

To add onto this I think there is an issue with the current delegation lock that gets put in place, that if a user doesn’t delegate before a certain block it makes the “ineligible to vote” I think this should be re thought out and re approached to allow for a more inclusive process in my opinion.

Thanks for providing feedback :slight_smile:

1 Like

Delegation lock according to the governance doc is in place until

Votes are delegated from the current block and onward, until the sender delegates again, or transfers their COMP.

This means that it’s a diminishing problem, not a recurring one.

Interesting… the contract has a ‘Cancel’ funcion

Cancel

Cancel a proposal that has not yet been executed. The Guardian is the only one who may execute this unless the proposer does not maintain the delegates required to create a proposal. If the proposer does not have more delegates than the proposal threshold, anyone can cancel the proposal.

Governor Alpha

function cancel(uint proposalId)
  • proposalId: ID of a proposal to cancel. The proposal cannot have already been executed.
  • RETURN: No return, reverts on error.
1 Like

We need to prevent governance attacks. Im going to remain highly suspicious of any attempts to change governance rules. Furthermore, we need alerts for when votes come up. Perhaps I may be wrong but IMO any good proposals should have overwhelming support. To have overwhelming support and remain decentralized we need people to be aware when votes are taking place and also to have their votes be counted ( I had no idea I had to self delegate, so my votes did not count on the last proposal). Any governance changes I would support would be raising minimum for quorum to 5% and also a 2/3rds majority for a proposal to pass. I saw the last proposal as an clear attack on UNI and governance and as Ive stated in posts well before the proposal was made we as a community need to prevent that from happening no matter who its from.

7 Likes

I agree completely with the rider problem. Proposals should be simple changes that are clearly understood and either agreed with or not agreed with, not two or more separate proposals packed into one. Its not like we can line item veto here.

4 Likes

Maybe I’m just particularly pessimistic in this way but I think the thresholds for quorum and proposals need to come way down. Like, way down. Looking at even real life examples, there will always be a significant chunk of people who won’t delegate and who aren’t interested in voting or are in different time zones or are holding these for investment and doesn’t even know the community exists or whatever. The key is that it’s pretty much unavoidable that if you use a high quorum to enforce decentralization , you’re likely to get stagnation. In real life examples, American voter turnout has always been low, because many don’t feel that their opinions were represented, or they don’t care about the issues, or that they didn’t know, etc. And in a sphere like this you can’t force people to delegate without people randomly delegating as a popularity context for “for the lulz”. This of course benefits centralization because if you can just use attention to get votes from people who don’t care, well, there it is.

I think that there should possibly be a few different categories of proposals in addition to the “pork problem” (riders that gets added on for the benefit for a few), in terms to what degree they affect policies writ large how much potential impact, insfoar as they can be calculated, and adjust the requirements accordingly. How many counts for a quorum, how many needs to just to get the proposal on the table, etc, doesn’t need to be fixed forever but be done on a sliding scale. Now, of course the law of unintended consequences tends to throw wrenches down the line, but that just requires some sort of way to figure out how quickly these can change via voting. It may tale some time to work out a reasonable system here on testnet or something before this can be put in.

And some of this is spitballing but I’ve been intrigued with the notion of decision-making in a certain sense by lottery. Now, an ordinary lottery wouldn’t work if a centralized actor holds a ton of power already, but it may also be possible to essentially delegate specific proposals addressing more particular areas of reform out to smaller groups of randomly selected voters who are put their hats i nthe ring so to speak, to work out, and then depending on impact either then put it in as a general proposal or if it’s something truly minor, enact it with obvious knowledge ahead of time. I need to flesh this out, certainly. There are no perfect systems and the goal needs to balance between functional and fairness and that’s kind of a problem that has existed for centuries.

I’m personally less concerned about “governance attacks” per se but more the way it is done. We’ve seen both relatively easily systems go to waste (the 1933 March German Elections, even though their safeguards meant that Hitler failed to even get a majority but were able to get dictatorial power anyway) with overwhelming support with threats of violence and bribery) and in the current US congress where pretty much nothing ever gets passed because even though they’re only a few votes short, that gives immense power nonetheless to the party with even 1 extra vote to dictate literally everything. I personally think that the way you prevent hostile takeovers is to not create a system where power can truly be concentrated in a way such as that. I know this is all lofty but pie-in-the-sky right now but at least that’s the sort of safeguards we need to have in mind. I’ll gladly do some research in the next few (I’m quarantined right now so at least I have time) because governance is of course hard but it doesn’t mean it’s bound to fail.

2 Likes

Just tweeted my summary as well: https://twitter.com/TMod_Marco/status/1318095598105612289?s=20.

This has been an interesting ride and actually, @Danpi314’s opinion summarizes this proposal pretty well. These are thoughts I read on the forum.

I think this was a successful first proposal.

  • It has indeed resulted in awareness for Uniswap governance.
  • I’ve seen amazing discussions on this forum. And, even though it was necessary to (unfortunately) address certain issues (e.g. false flagging), these discussions resulted in new ideas as well as users being able to find enough information to form their own opinion.
  • Personally agree with the rider comment.

Regardless, I’m hoping this proposal will lead towards continuous discussions and new proposals on Uniswap. I had some comments on Twitter / Telegram that this clearly demonstrates governance ‘doesn’t work’. However, I agree to disagree the first proposal getting rejected does not mean governance doesn’t work. Great things were learned, let’s move forward and apply these learnings!

2 Likes

In my opinion this 1st proposal shows that the current governance has some strong points, this was a contentious proposal, it makes sense that quorum hasn’t reached (even more if we account for only 45m delegated votes)

I want to summarise my concerns with it:

  1. The proposal had a rider, lowering the threshold to vote and lowering the quorum, I have very different opinions about those two changes.

  2. Lowering the quorum makes the governance more agile, but at the expense of passing more contentious proposals. In my opinion our governance is too young, and we should try to move slow until we settle in some good processes for it.

  3. Autonomous proposals have been talked multiple times as an alternative to make governance more liquid, while preserving the robustness of a high quorum. This possibility should be explored in more depth.

  4. One of the reasons this proposal was made is to improve the chances of passing the “second airdrop” proposal, although I don’t think this is the context to give my opinion on that one, I think we should vote on it using the original governance parameters, lowering the quorum only to pass a contentious proposal has a good chance of fracturing the community.

8 Likes

From literature on DAOs. There are 4 cited issues with this typology.

1. Procedural Nature
Lack of voter participation, or in our case, delegation to enter the timelock, self or otherwise. This particular issue has a long-standing history in democracies and we are better served not attempting to solve it.

Strategies to mitigate:

  • Lower the threshold for quorum
  • Make quorum a factor of the currently delegated amount, and keep the % required proportional to ‘interest’
  • Implement a ‘liquid democratic vote’ found here, which calculates the ‘configurable’ percentage required between the difference in Yes and No votes over the total
  • Allow tokens to achieve ‘tenure’ like in LTSE For example, holding tokens for 1 year may give you 1.5x voting size. This balances the needs of long-term holders and short-term investors that may otherwise overwhelm governance.

What not to do:

  • Remain stuck on the Compound governance fork with the initial constructor configuration of 1% and 4%. These percentages are over the Total tokens in circulation, NOT delegated. The human function of progress and innovation is to ‘copy’ and ‘improve’. So far, all we have done is ‘copy’.

2. Legal Indeterminacy
Not much to be said here, but we are an illegal organizational structure, and when the SEC can be bothered, they will come after us. If we issue governance tokens, we become a target. Are we prepared to extend ‘unlimited liability’ to our customers? If not, we have no right pursuing a cryptoanarchist agenda.

Strategies to mitigate:

  • Keep evolving with the space and whenever there is an opportunity to legitimize our group, we have to have the flexibility to do so. This is precisely why i think the crypto-anarchist decentralized agenda will ultima hurt Uniswap. Their ideology is more important than the financial integrity of the services they offer.
  • A financial stake normally solves this problem because it ensures that you have ‘skin in the game’. To pursue this fully we would have to experiment with the idea of a non-delegated vote. In this voting regime, idealogues’ votes would be muted, especially those with little to no substantial stake in the success of Uniswap.
  • If the SEC does get involved, they will go after who they can - in this case it would be ‘Delegates’ with public identities

3. The DAO is code
The essential construction of the DAO is held in turing complete Solidity contracts. This makes it extremely difficult to alter once in operation. Even a trivial bug fix has to undergo a vote. (have we been audited?) This creates a dichotomy. Although the code is highly transparent, it is difficult to repair or modify.

Strategies to mitigate:

  • Create an emergency ‘governor’ like function that will allow us to implement bug fixes quickly. Any proposed changes will have to go through an emergency audit to maintain integrity and accountability. The auditor must remain an objective 3rd party.

4. Voter Manipulation
It is possible, however difficult to prove, for groups of voters to scheme against the DAO machine. Horizontal accountability is required to preserve the democratic nature of this group. We saw plenty of this drama play out on the forums. Most of it was unsubstantiated fear mongering about elaborate schemes to overthrow Uniswap, like this was a chapter in Lord of the Rings. However, if the possibility is there to manipulate the vote, system actors will eventually attempt to exploit it. Welcome to human nature.

Strategies to mitigate:

  • Implement the ‘tenure voting’ mechanism mentioned above
  • Make the vote ‘HIDDEN’. This is already a fairly well studied voting procedure, and it will curtail all the scheming that occurs during the 7 day active vote. Instead of focusing on and gaming the voting results, delegates should instead respond in faith to the proposal being put to a vote. This also reduces the ‘abstain’ vote, because in this scenario it is not clear that ‘abstain’ counts effectively as a ‘no’ vote. Abstain should be reserved for those who take issue with the proposal, and remain uncomfortable with either a ‘yes’ or ‘no’ vote.
  • Open a formal proposal topic in the forums for a 6 day discussion. Once closed voting takes place over a tighter 24 hour period. This allows discussion to take place and limits the ‘politicking’ to a 24 period of time. If we implement the quorum strategies above, we can safely pass good proposals with the currently ‘engaged’ delegates, and not worry about having a time window artificially stretched to ‘gather’ in sleepy voters.

What not to do:

  • Don’t make the voting progress visible. Humans are prone to story-telling with little to no evidence, and any legitimate attempt to push through a good proposal will always be subject to ‘manipulation’, political machinations, and coercion.
1 Like

we should move this thread to meta-governance and change the title to ‘Post Vote-1 Governance feedback’? or create a new thread

seems too specific and important to be in ‘uncategorized’ :slight_smile:

I want to politely disagree. My full-time job is to help large enterprise organizations go ‘digital’. The strategies we implement are ‘complexity science’ based, and are proving to be far more effective than traditional MBA-like approaches, which feature deadly conservatism. I think @Agusx1211 what you are articulating is a concern to not allow governance to become so easy to change, that it degenerates into chaos at the hands of evil actors in the system. This is a good concern, and one i share. However, life is not a polarity, and i caught you saying ‘spectrum’ several times already, so i know that you get it. Going to the opposite extreme and maintaining a highly immobile governance structure, under the auspice of ‘slow is best’, is also not conducive to survival. Systems have to find that point of criticality in the middle where change is aggressive enough to represent ‘positive adaptation’. Today, for large organizations, ‘slow’ is bankruptcy - it’s just a matter of time. In the words of a well known ‘systems behaviour’ scholar Ackoff, we want to be ‘interactive’, which is to say… We want to aggressively interact with our ecosystem, our token holders, our governance rules, to find out what works. It’s a race against time, because the next UNI-killer is just around the corner. We operate within this highly mercurial space and we know this to be true.

Dharma has nothing to gain financially from this, except indirectly through the good-will of their users. Additionally, only 4000 or so Dharma users were impacted, so we aren’t talking about a massive horde of tokens. I agree with you however, because Nadav admitted it openly under the claim of 'broken governance to give it added legitimacy. Also, i fail to see how Dharma users getting UNI would fracture the community. Most of them don’t even know this is happening and are blissfully unaware that they may one day see a ‘claim’ call-to-action on their mobile client. Who are we defending against? Dharma and/or it’s users? We should be focused on growing the ecosystem, not fighting proposals that are intended to expand wealth and good will. Let’s test out this theory. Ask yourselves this “does interaction with uniswap, either to swap tokens or provide liquidity, automatically entitle you to care about Uniswap’s long-term viability?” It’s very likely that many UNI holders today don’t care, and yet, they have governance entitlement to vote. Now you have a community like ‘dharma’ that cares, at least that’s what they are signalling, and what are we doing? We are spending time characterizing them as vile tryants attempting to overthrow governance. The hypocrisy is too funny not to call out tbh. Leaders in this community should be building bridges, not stoking fires.

Sorry but your comments are almost impossible to follow, can you try to keep a more concise message?

I never commented on that, I explicitly said “I don’t think this is the context to give my opinion on that one”, what I am saying is: If the airdrop is something the community wants, then it should be voted and approved with the original quorum.

If the quorum has to be lowered in order to pass the “second airdrop” proposal, then the proposal is too contentious, if the governance is changed anyway and the proposal passes that could split the community.

2 Likes

I will try to simplify my feedback where i can. Sorry about that. I sometimes use the language of academia too liberally. We cannot TLDR important matters of governance however, so finding a balance is key. Learning along the way is essential.

Your latests two paragraphs weren’t very academic

It was more of a straw man, responding to a lot of things that I never said… and closing the impossible to follow argument with:

If you don’t have a response to my initial point (being: “lowering the quorum to pass a contentious proposal is bad”), then don’t deflect by shifting the conversation to accusations I never made.

1 Like

I’m glad personally this proposal failed. I agree to his point the major point to the proposal was basically greed. (Airdropping more UNI to those unhappy about not getting the first airdrop). Secondly, I think governance decisions should hold more worth and only be done with the utmost urgency to fill a need that is important to the UNI-verse at large. Lowering the quorum also risks damaging the governance by allowing much more contentious and self-interested parties to pass governance that may hurt the system at large by allowing them to take a quick profit at the expense of the many. And finally if anything I think they need a system on the front-end page like the scrolling numbers at the bottom for votes to make the users, aka. uni-holders aware there are actually votes going on.

Is this saying that if a delegation has the required votes, makes a proposal, and then a bunch of delegates transfer their UNI elsewhere (falling below the required delegate count) that anyone can quash the proposal? Seems pretty straightforward.

I think there should be a clear guide front and centre on the uniswap website on how the voting process works, and how to participate.