Proposal: Reduce amount of UNIs required to submit governance proposal

Support this. Obviously need to decrease

Agreed. 10K seems like a happy medium, worth looking into creative governance systems too!

Keep it the way it is.
Most people here have no idea yet how any of this works. 10m is a very high amount, yet as stated above, the team has mechanism in place for this. lets give them the benefit of the doubt that they didn’t just randomly go for this number and see where it brings us.
besides, 10k is waaaaay too low. thats not even whale level holdings. really don’t feel like sifting through a ton of spam proposals for bigger airdrops while the real issues get ignored.


damn i was thinking i was good with 1k…

I support this very much. I don’t know if 10,000 is the right number, but I’m happy to adjust it upwards if it becomes chaotic at this level.

1 Like

I just posted this on another similar topic, so I’ll share my personal (again, I’m not a team member) opinion here:

‘‘Uniswap has always embraced the tenets of neutrality and trust minimization: it is crucial that governance is constrained to where it is strictly necessary. With this in mind, the Uniswap governance framework is limited to contributing to both protocol development and usage as well as development of the broader Uniswap ecosystem.’’ - from the blog post

That being said, I’m pretty sure the team has thought of this before implementing the minimum thresholds. There are very many suggestions/proposals that seem to not be approved by the majority of the community, as proven by the lack of support on certain suggestions.

That’s not an opinion or comment towards a specific proposal. It’s a fact based on what I’m seeing right now. I’m not necessarily sure that’s a bad thing, it’s an interesting situation.

I personally as a community member would vote no on a proposal to reduce this number. I strongly believe the most important proposals will find their support.


In my opinion the treshold of uni for submitting a proposal should be high, because there should be major support for the proposal and not a lack of interest to vote from the community. At the same time uniswap needs to keep innovating and therefore change with the support of the community. How high the treshold should be exactly is a point of discussion. We could introduce a rule that if none of the proposals have reached the minimum treshold of 10 mil UNI in a single month. The three proposals with the highest number of votes will be submitted as a governance proposal

Agree it is too high, but it is too low at 10k. You don’t want some troll spamming the governance since there isn’t a cost to posting a proposal. It is too excluding as high as it is however. If only a few people have the delegated votes what happens when they are creating two different proposals where you agree with one but not the other. You end up in a dilemma, more participation needed.

1 Like

Delegate to me and let us get that 1% of UNI voting power. I pledge to represent all constituents not just by holding town halls but using a voting mechanism to reach optimal consensus. Let us unite and bring forth what the community desires. If you are not familiar with how to delegate I have posted an instructional.

Andre Cronje has 10m uni delegated to him and is proposing this,

personally I thnk it’s not a bad system, stops the system being cluttered from hundreds of repeated and poorly thought out submissions.

Maybe a 2m UNI limit would be better, certainly no less that 1m.

I believe at this point in time, lowering the threshold to 10k would do much more harm than good .

Lowering the threshold this much would just have a spam effect .

Like, for example, we could get 200 proposals a la “Give UNI distributions towards MyBag/ETH pair!”

And we would probably have to vote against it , as we don’t know if people who offer it can reach the quorum at the last second.

This would effectively discourage participation in protocol governance, as it would cost a lot of money and time to the UNI community with no feasible benefit, just protecting the protocol against spam attacks over and over again.


For what it’s worth, you can make autonomous proposals with only 10k already . But this way, you wouldn’t make people waste their time, attention, and gas fees on voting against your proposal if it doesn’t reach 1%.

You need to reach 4% to get quorum anyways , so if you can’t get 1% of UNI to vote for your proposal, how do you intend to win?


I do think that there’s room to lower the threshold without compromising the governance of the protocol. But it would have to be of a different magnitude . Like 5 or 7.5 million UNI instead of 10 million to start with, definitely not 10k instead of 10 mils.


I very much agree, 2-5m Uni should be the very lowest requirement, otherwise the proposal area will be spammed with low quality proposals and people will get jaded.

The delegation systems exists for this reason.

1 Like

10K might be too little-- don’t forget the amount of users that are on uni-swap but cutting the 10M to 5M might work. if it only took 10K new proposals could get voted on way way too quickly

Wow thats a really high price for a PROPOSAL

Hash: SHA256


In order to analyze this proposal a bit more seriously, we need a security framework for reasoning about quorum sizes. We propose the following de minimus threat model which aims to reason about quorum sizes as a function of the quantity of UNI needed for a set of negative actors to perform actions harmful to UNI holders and LPs. While there isn’t an purely objective definition for what the set of negative actors looks like, I will focus on actors that I believe are generally agreed upon to be negative participants should they unilaterally form a cartel to pass proposals through governance. Gauntlet would very much appreciate feedback on whether you think this definition is too aggressive, however.

Threat Model

In order to quantify optimal quorum sizes, we first have to define a threat model that prescribes how much UNI colluding adversarial actors would need to accrete to perform a deleterious action. In the remainder of this post, we consider a deleterious action to be one that:

  • Reduces the amount of decentralization inherent to the protocol
  • Reduces the potential future cash flows that UNI holders could (not will) receive from the transaction fees allocated by the protocol
  • Interferes with the ability for liquidity provider and traders to achieve execution as defined in the smart contract (e.g. via a change that increases gas costs without a very strong reason for doing so)

Given that these are qualitative objectives, we will need to introduce simplifying assumptions to create a data-driven model.


We first make the following assumption about an adversary that necessarily satisfies the above criteria:

A0. The set of deleterious adversaries is non-empty and at least includes the following three actors

a. On-Chain Lending Pools (Compound [0], Aave [1], PowerPool)
b. Competitive Automated Market Makers with Governance (e.g. SushiSwap)
c. Centralized Exchanges

The first category is nascent and quite small, so we will focus on analyzing the threat posed by exchanges. According to Nansen, we have the following top UNI holding exchanges:

From these balances, it is quite clear that the main exchanges that we need to consider as threats to governance are Binance and Huobi. Even if every non-Uniswap UNI exchange colluded to try to achieve quorum, they would barely be able to do so. The high cost of coordination amongst competing adversaries behooves us to make the next model assumption:

A1. Only exchanges with balances higher than Uniswap are likely to collude to reach quorum

Now that we have restricted ourselves to analyzing exchanges with higher balances than Uniswap, it is natural to ask about quorum size relative to their total balance. Given that the two exchanges that meet this criteria are fiduciaries and strident competitors, we believe that it is reasonable to assume that they will not collude.

A2. Competing centralized exchanges will not collude to take over Uniswap

This assumption, which is the strongest one that we make within this threat model, is likely to be controversial as the cryptocurrency space has historically had collusion of this form (e.g. Bitcoin’s New York Agreement). However, we believe that competing exchanges forming an anti-UNI holder cartel (to drive liquidity and volume back to centralized venues) will inevitably be an unstable alliance as the form of UNI manipulation chosen will likely only benefit the largest member of the cartel. In particular, we do not believe that they will be able to make progress on omnibus proposals that require multiple governance votes without running to a point where their cartel spontaneously breaks apart.

Given these assumptions, we can define the safe quorum threshold to be the least upper bound on the most capitalized deleterious actor’s UNI balance. This captures the minimum amount of UNI that a deleterious actor that satisfies assumptions A0-A2 would need to perform a governance action unilaterally.


How do we estimate the safe quorum threshold? Given that exchange balances fluctuate daily, one simple upper bounded heuristic for the safe quorum threshold is the estimator (written inefficiently as a quadratic algorithm, but with an eye towards clarity using Python notation)

safe_quorum_threshold_ub = max([max_balance[t] + abs(max_delta[tp]) 
                                for t in range(start_date, end_date)
                                for tp in range(start_date, end_date)])


  • balance[exchange, t] is an array of the balances at exchange exchange indexed by a date t
  • max_balance[t] = max(balance[exchange, t] for exchange in exchanges)
  • delta[exchange, t] = max_balance[exchange, t] - max_balance[exchange, t-1]
  • max_delta[t] = max(delta[e, t] for e in exchanges).

This finds the max balance plus the maximum [in,out]flow that an exchange has in a single day. By using the maximum flow (regardless of direction) and the maximum balance, we’re constructing a best unbiased estimate of how large the largest exchange could get if it a) had the maximum known exchange balance and b) the largest inflow day possible.


Using the Nansen, we can first see that Binance has always been the maximum balance exchange, hovering around 25M UNI.

Therefore, we center our analysis around Binance. In this Google Sheet, we use daily balance data from Nansen to compute a number of quantities related to the safe_quorum_threshold. If we exclude max_delta from the first day of UNI issuance (which is an outlier, as illustrated in the spreadsheet), we see that:

  1. max(max_delta[t] for t in range(start_date, end_date)) = 1'212'017.65
  2. max(max_balance[t] for t in range(start_date, end_date)) = 28'904'174.60

However, we note that Uniswap’s market share in terms of UNI markets has increased over time, whereas Binance and Huobi have been decreasing in UNI holdings. As such, we think a weaker but still acceptable estimator for safe_quorum_threshold is:

safe_quorum_threshold_ub2[exchange] = max([avg_balance[exchange] + abs(max_delta[t]) 
                                          for t in range(start_date, end_date)])

Why do we think this is reasonable?

  1. The first few days post UNI launch had exceptional volumes and they should be considered outliers
  2. The increase in Uniswap market share is extremely promising as the number of UNI held in Uniswap pools more than doubled from the minimum (3.4M) to the maximum (8M) whereas Binance and Huobi had far more anemic growth

Using this bound gives us a final number that we believe could be in a proposal:

safe_quorum_threshold_ub2["binance"] = 26'930'326.78

Thus, we believe that a quorum amount of roughly 27M UNI should suffice to prevent a unilateral deleterious act.


[0] Compound has borrow caps enabled as of Compound governance proposal 22, which mitigates the size of borrow that an adversary can

[1] Aave has a community sentiment poll for adding Uniswap to the protocol



Thanks for this in depth analysis! One question regarding:

The increase in Uniswap market share is extremely promising as the number of UNI held in Uniswap pools more than doubled from the minimum (3.4M) to the maximum (8M) whereas Binance and Huobi had far more anemic growth

I don’t have Nansen access, but does Binance announcing lending support (or some other feature) reverse this trend for other tokens on the platform?

Hash: SHA256

That’s a good question! I do think you’re right that they’d probably do best at aggregating more balances via some incentive-like this. One thing I don’t think they can do is compete on a UNI basis with UNI’s incentives (e.g. deciding which pools get UNI, % of UNI inflation) — so they’ll need to convince UNI lenders looking for yield to either

  1. Accept BNB as a form of yield payment
  2. Provide some % of UNI/X trading fees to lenders

The former works, but is likely to cause a lot of friction as BNB is a standalone Tendermint chain (so the UX is not, well, farmer friendly) and the latter is likely to make market makers move away from Binance. So it might (but is not impossible!) be hard for them to incentivize users in an easy manner.

That being said, having a cross-chain DEX like Serum does make the second choice more palatable and FTX in the future might be able to pull this off more easily.

One other thing I wanted to add: In A1, we use UNI balances to rank exchanges and not volumes. Why?

Ansatz: If a user generally uses exchange G and puts UNI on it, then they were willing to move liquidity from G to Uniswap, farm it, then bring it back to G

Thesis: These ‘flight risk to UNI’ users are the ones who CEXs want to ensure don’t leave, so exchanges with higher balances UNI balances will be more afraid of Uniswap’s market share growth as they have more users who aren’t sticky


1 Like

I agree with you here. Thanks for the swift follow up!

This analysis is great, @tarun — thanks for sharing.

One additional consideration that needs to be taken into account is that cUNI currently has ~4.4M UNI available for borrowing… If a large UNI holder like Binance were to borrow this UNI just before submitting a proposal (potentially even via flash loan) and pay it back right after proposing, they would be able to exceed the proposed safe quorum threshold. (It does seem likely that this UNI would quickly be eaten up by borrowers or pulled by suppliers if the available amount became too large.)

How about padding your proposed quorum threshold a bit to account for this possibility? Say, 3M to propose and 30M for quorum?


Voting is live on this proposal:

1 Like