Prevent exchanges to vote on Uniswap governance proposals

It is very simple.
Every exchange sees UNI as a competitor and they would like to see Uniswap fail.
We should prevent all centralized and decentralized exchanges from voting on any governance proposal or delegating votes to any other third party to vote for them.

Should we prevent exchanges to vote on UNI governance proposals?
  • Yes, exchanges shouldn’t have right to vote on UNI proposals.
  • No, exchanges shouldn have right to vote on UNI proposals.

0 voters


… And how exactly would you do this?


Giving governance to long term UNI holders can help with this!


All known addresses of exchanges should be muted and those votes ignored. Technically I don’t know how developer can code this, but doesn’t sound very complicated except that list of banned addresses should be updated from time to time.

That will not prevent attack from other exchanges!

If an exchange really wants to vote/create a proposal and circumvent a blacklisted address it would take all of 30 seconds to create a new one and delegate…

@mmoossttaaffaa’s proposal could help a bit to ensure that votes might have a more long term interest in Uniswap, but it’s hard to say.

I think a more concrete proposal would have to be made before consequences can really be analysed

I agree with you. In that case we need to give incentive UNI holders to not hold UNI tokens on exchanges. That way we will reduce token balance on exchanges. (Binance offers 0.44% interest on UNI without any lock)

Sounds like you would be in support of this proposal then:

Maybe continue the discussion there and close this thread :slight_smile:

This is a proposal to censor particular participants in the system. Good things will not come of going down this path long term.


Similar attacks have been proposed with MakerDAO, in fact using the Uniswap pool MKR-WETH, perhaps combined with a flash loan protocol to drain a pool, pass a proposal such as mass liquidation of vaults to itself, and then return the funds.

While I am against centralized exchanges exerting undue influence on Uniswap, I am against censorship or safelisting addresses by themselves. Some general principles that might guide thinking in this area:

  • UNI governance currently cannot do much besides control the inflation / deflation of UNI, as far as I can tell, and this is dependent on the Uniswap team’s willingness to listen to signals of UNI holders. A governance attack from a CEX would take the form of either inflation by voting to grant more UNI to itself (followed by mass selling) or (mass buying then) deflation by voting to burn (other) UNI. Similar to MakerDAO’s security delay feature, we can institute a delay before voted changes take effect, ideally through automated contract, which would probably require another version of the UNI contract. However, token contracts are simpler to upgrade than the Uniswap protocol contracts themselves. Such a delay, e.g. 24 hours, would rule out flash loan attacks and make other attacks much more expensive.

  • Similar to a voting execution delay, we could propose requiring addresses to have held / staked UNI for some amount of time (e.g. 1 month) before being able to vote. This will not rule out CEX’s, but will slow down sybil attacks or other attempts to create many new accounts that coordinate voting together while eluding identification.

  • Require locking up UNI for a delay after a vote, such as 6 months or 1 year, to incentivize votes that increase UNI value for everyone.

  • Uniswap is a successful protocol that will continue to earn fees. I encourage individuals looking for a sustainable return to provide liquidity, and I encourage Uniswap team to give UNI some intrinsic value and non-trivial ability, such as the ability to change fee percentages, to insure against either token in a trading pair crashing, similar to how YFI holders earn a share of fees from that protocol. Give CEX’s, as well as yield farmers, a reason to HODL and not make short term moves by giving them a better way to earn returns.

What if users delegate their UNI to CEXs they hold it on? :thinking:

It’s not the time to consider these issues.
Now the core team should have full rights to do things, and be transparent to listen to the opinions of the community, and then consider this issue when it is bigger, because it is difficult to avoid this issue now.