UNI holders should be able to delegate during the voting period with zero delay

Currently, if a UNI holder delegates during an open vote, they cannot begin voting until the next vote begins.

This delay could become a major point of voter suppression, as most users will likely delegate because of the current proposal being voted on. We have seen major voter apathy in other projects like Maker and Compound. Most UNI holders will not be proactive and delegate their vote just to be ready in case something they actually care about pops up. They’ll look to delegate and vote immediately when a triggering issue arises.

I would like to see a modification to the governance contract to allow UNI holders to delegate and immediately vote, rather than being delayed until the next proposal.

Before we run a poll, I thought it would make sense to understand the tech implications of how this could be accomplished and if there are any trade-offs that I’m not thinking of.

Please share thoughts on how the above could be accomplished with code, and what side-effects it may cause.


Counter-argument: This would allow open vote buying, and this previous proposal would have certainly passed for a cool 1.5 million USD worth of UNI with a potential profit for the proposers of much more.


That is already possible, just need to be self delegated before the proposal is started.


I think you misunderstand my point. This would allow the proposer to, at this early stage at least, purchase votes for itself on the open market to self delegate and vote for its own submitted proposal. This will be less possible down the line. This was obviously thought of and why things are the way they are. :partying_face:

How is this not possible now?

  1. Buy loads of UNI
  2. Self-delegate
  3. Propose
  4. Win vote
  5. Sell loads of UNI

What am I missing?

1 Like

Proposals can be canceled if the delegate that proposed them no longer has enough voting power, they need to hold the min required UNI to vote until the vote finishes.

1 Like

Chris, you have to change the votepage.tsx implementation

github page

The code is here to see. This modifies the user behaviour on the page.

// only count available votes as of the proposal start block
const availableVotes: TokenAmount | undefined = useUserVotesAsOfBlock(proposalData?.startBlock ?? undefined)

// only show voting if user has > 0 votes at proposal start block and proposal is active,
const showVotingButtons =
availableVotes &&
JSBI.greaterThan(availableVotes.raw, JSBI.BigInt(0)) &&
proposalData &&
proposalData.status === ‘active’

the logic continues in hooks.ts which checks to see if you have valid votes that were activated before the proposal datetime startblock

// fetch available votes as of block (usually proposal start block)
export function useUserVotesAsOfBlock(block: number | undefined): TokenAmount | undefined {
const { account, chainId } = useActiveWeb3React()
const uniContract = useUniContract()

// check for available votes
const uni = chainId ? UNI[chainId] : undefined
const votes = useSingleCallResult(uniContract, ‘getPriorVotes’, [account ?? undefined, block ?? undefined])
return votes && uni ? new TokenAmount(uni, votes) : undefined


however, you must consider that the greater the financial stake, the more this ‘actor’ will be incentivized to ‘improve’ the uniswap marketcap

practically, it’ll require 40M*3.20 = 128 Million USD to make it a cinch without the political ‘delegate to me’ campaign, and there isn’t enough liquidity on the order books to do this

the only possibility i can think of is

  1. wait for a drop in price
  2. all the steps you propose while fear is high
  3. launch some sort of campaign to temporarily pump price
  4. unload

that’s a pretty elaborate scheme that is difficult and risky to pull off. most whales i know calculate R:R like surgeons. that’s to say it is highly unlikely but possible.

1 token = 1 vote is very very problematic because it tips the balance in favour of those with short-term financial interests

Also I think the voting period should be extended a little longer as this last proposal I just noticed 1 day before it was finished counting down.

Because a heavy holder could go to market, buy enough UNI to push vote through, pass proposal, then sell on market, within 5 minutes. How is this not obvious? This only applies RIGHT NOW. Which I think is why it is being brought up RIGHT NOW.
I guess I’ll ask what is the rush to change such important rules so early?

Edit: And why are the same people that were so PRO the last proposal so PRO the seed of this one?
inb4 conspiracy

1 Like

I see what you’re saying. For instance, if there was 2m needed to reach quorum, someone could just go buy it, vote, then dump it.

Is there any actual precedent for this concern? Has it happened with MKR, COMP or any others?

The ability for people to vote on the current proposal is so important that it may outweigh this possibility.

One way to address this problem without making too deep technical changes (and potentially having other surprising effects) is to increase the votingDelay—the period between when a proposal is made and when voting starts (and the delegation snapshot is taken).

Personally I do like the idea of this being 24 or 48 hours rather than 1 block, to give people time to delegate in response to a proposal. What do you think of that?


This feels way better.

Delegating != blindly following.

Currently a surprise proposal could catch a user off guard and they have no time to respond — which appears to be the issue.

Creating a 48 hour window would save a lot of that stress.


I agree that the 48 hour window could help somewhat. However it doesn’t solve the root issue, which is that most people won’t pay attention to votes until they are very close and their vote could, potentially, tip the scales.

We should be enabling those people to make a difference - not actively blocking them from doing so.

1 Like

If you are able to delegate during the voting period without delay, it will be easier to buy a majority. It is still possible to buy a majority before the voting period if you delegate to yourself, it is just harder. In the first case you can adapt the amount of spending during the voting period and thus buying enough with a marginal victory. If you can’t delegate directly you will need to make an estimation to the amount of votes that are necessary, if you want to buy the vote

So, just to flesh out this conversation further:

Consider: say you delegate to one group before an initial proposal, but don’t agree with your delegate’s opinion and signalled intent to vote on a second proposal put forward after voting began but before it concluded for the first?

To preserve voter autonomy, we need to be able to delegate and undelegate if multiple issues are up for a vote at any given time.

If multiple issues can not be put up for a vote simultaneously, we should be considering the risks of miring ourselves into a somewhat plodding governance structure.

There’s a happy medium in here somewhere, I’m just throwing out some knock-on effects of both sides of this. I very much appreciate an eye towards mitigating governance attacks by unfaithful actors–however we move forward with this, that should be at the forefront.

1 Like

Do you have any concerns about drawing out the overall time it takes to pass and implement a given proposal? Are there scenarios where (in case of emergency–some sort of unforeseen black swan) we need the ability to cut those extra two days out in the future?

Curious to get an additional perspective.

What is the argument against 1 week or 1 month? Why is there a need to rush governance proposals through?


One thing that pops to mind is a rapid response to an attack on liquidity or governance itself. It seems like governance would want to keep its options open to move relatively quickly against an attack from either outside or within.

Obviously-- 1 minute, 1 day, 1 month, 1 year … etc trends to infinity. We have to strike a balance between: sufficient voter mobilization and discourse; and accomplishing any changes in a timely fashion. Catastrophic events requiring rapid changes with rapid governance approval process.

This is where I see the continuous approval voting process used by Maker being a nice set-up. Much like forking a distributed network, the changes only happen after a certain majority have weighed in.