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.
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.
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.
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])
?.result?.[0]
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
wait for a drop in price
all the steps you propose while fear is high
launch some sort of campaign to temporarily pump price
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
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
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?
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.
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
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.
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?
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.
