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

Proposal Discussion
#7

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])
?.result?.[0]
return votes && uni ? new TokenAmount(uni, votes) : undefined
}

#8

nothing

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

#9

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.

#10

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
#11

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.

#12

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?

14 Likes
Temperature check - [Should we increase the votingDelay?]
[proposal] giving Uniswap governance to long term UNI holders
#13

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.

3 Likes
#14

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
#15

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

#16

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
#17

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.

#18

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

3 Likes
#19

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.

#20

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.

#21

Exactly what I thought when I read @danrobinson’s post

I’m uncomfortable with the thought of people being able to rush through proposals without the communities best critical thinkers having time to think through both the short term & long term ramifications as a result of the proposal being passed

1 Like
#22

That’s fair but in that case should there not be two types of proposals?

  1. Urgent proposal - Should be a rare occurrence (:crossed_fingers:) to handle emergency situations with a shorter period of time to both vote on & delegate votes for

  2. Normal proposal - Longer period of time to vote on & delegate votes for

1 Like
#23

Flip side: we do critically think about a proposal, think it’s good, implement it. However, there’s an unforeseen critical exploit introduced, and funds are at risk as a result.

Quite frankly, I don’t even know if this is possible, but–if it is, you’d then have to wait that same period before you could revert.

#24

What is the attack vector against governance that governance itself could stop?

1 Like
#25

very good question :slight_smile: tricky. my answer is that they are too numerous to count in a purely decentralized model.

a decentralized governance group has little recourse should this happen - it’s simply too slow

we all know of the 51% attack concept - here the bar is lower and there is nothing preventing someone from pulling off a 4% attack anonymously

however, there are several critical steps in governance that could mitigate the concern. each relies on some form of centralization.

  1. Delegates have the ability to move a proposal to a formal vote. The community can recommend proposals, but it’s no longer an autonomous function. Just make the trigger multi-sig. Here’s the trade-off.
    Pros
    -No single person can shove a deleterious proposal through on volume of UNI alone
    Cons
    -No longer a decentralized function either.- Prone to internal politics, and can easily be utilized to stall efforts to progress the platform

  2. Do none of the above, but let’s continue with the idea of an ‘approved delegate’. Here is the post-hoc solution. If an attack is imminent, then give them a multi-sig ability to ‘cancel’ a vote.
    Pros
    -No single person can pull off an attack
    Cons
    -not decentralized when you give a small group ‘veto’ power
    -may also expose a critical weakness of multi-sig, because it assumes all delegates are paying attention and ‘able’ to vote

  3. Extend the power of a governor. This ‘governor’ address (presumably uniswap employee) already has the override power to ‘cancel’ a vote. A classic fail-safe mechanism that is built into the code, unless i’m reading it incorrectly. There should be an ‘appeal’ process that allows us to ask the Governor to ‘cancel’ a vote.
    Pros
    -Nothing in the code needs changing
    -No single bad agent can get away with an attack
    Cons
    -can be misused in a trustless system

this is a matter for a different post altogether, but we are at the stage where the foundational assumptions behind ‘decentralized social groups’ should be challenged.

  • there is no historical precedence for this social entity working effectively.
  • social anthropology says ‘no’ - do not try to equate this to hunter/gatherers - different scale - different problem
  • behavioural economics says ‘no’ - human social progress is not a formative, rational, or ethical system - it is darwinian - it doesn’t give a gnats’ ass about which form of social organization we take. besides, modern capitalism is on the verge of collapse. there are many reasons for this, but my favourite is the critical assumption that Adam Smith got wrong in ‘wealth of nations’. he assumed, incorrectly, that given an economic choice, every human being would make a choice that improved the state of the social group. kahneman eloquently dismantled that argument on his way towards getting a nobel prize.

so, maybe a ‘hybrid’ model that mixes decentralized with centralized structures. the purists will cry foul because they prefer to see the universe as a convenient, non-quantum, arrangement of 1s and 0s. fair enough, the clockmakers among us may be right in the end, but i have my doubts. the point of innovation is to ‘temporarily suspend your disbelief’, because it’s the only way to trigger the novelty center of the brain. if we remain stuck in our beliefs, and hold them as sacrosanct pillars, we may as well let go of any claim to critical thought.

otherwise, a purist approach to decentralization will succeed, or not, on the assumption that humans can align on matters of mutual benefit. find precedence and i may be convinced. this is why satoshi was brilliant - he turned it into an economic challenge, and deferred the question of ‘trust’ to one of economic viability. here’s the irony. in order for a truly ‘decentralized’ system to work, we would have to abandon selfish needs and privilege the group over the self. in that system we no longer rely on PoW or PoS to achieve consensus on anything. :slight_smile: i fear we are mixing decentralized wealth, identity, ownership of data (SELF) with decentralized governance (SOCIAL). the fact that it works so well with one, does not automagically confer the same outcome for the other.

#26

Can you give an example of one? Specifically, I’m interested in attacks where there is a time delay on governance proposals between creation and delegation snapshot, and someone executes a governance attack that can then be mitigated by governance, but only if the delay is short.