Temperature check - [Should we increase the votingDelay?]

Voting Delay is the period between when a proposal is made and when voting starts (and the delegation snapshot is taken).
The current delay is 1 block.
Should we increase it?

Link to snapshot: (https://snapshot.page/#/uniswap/proposal/QmZUeeJEoEp4Z1oLzMcXbWJyu4WNvHF9p8uHjz97T5nD3m)
Snapshot voting will start on Oct 30 and finish on Nov 1, 2020.

Links to additional reading:
(voting delay, preparation period)

8 Likes

No. The proposed action would require launching a new Governor contract. I consider this a dangerous concept, and I’m a little appalled that this would be cloaked in the cover of a minor modification of the delay mechanism.

Voting delay is not implemented as an ABI call, so I ill reiterate, this is replacing the Governor contract!

The Contract that is controlling Governance is at 0x5e4be8Bc9637f0EAA1A755019e06A68ce081D58F and launching a new Governor contract would be required to implement this suggested change.

The relevant line is:

/// @notice The delay before voting on a proposal may take place, once proposed
function votingDelay() public pure returns (uint) { return 1; } // 1 block

Are there any changes to the Uniswap governance that could be done without launching a new Governor contract?

Do I understand correctly your implication that everything that’s left for Uniswap governance to do is to send UNI from the governance treasury - and to activate the fee switch?

If that is correct, it makes sense to launch a discussion and do another temperature check - and see if there’s a consensus on it. It would save a lot of people a lot of time.

What’s your concern about replacing the governor contract, assuming that everyone understands the parameters of the change? It’s built to be replaceable by governance, and Compound (which Uniswap governance is forked from) has already done so once.

Personally I do think that if the governor contract is upgraded, it might as well be an upgrade that makes all these parameters upgradeable by governance rather than hard-coded so that future changes won’t require deploying a new governor contract.

4 Likes

Here’s the quote from the first proposal:

In order to achieve this reduction in thresholds, a new GovernorAlpha contract is required. To that end, we have deployed a new contract which contains the following changes:

There were a lot of discussions about this proposal, but none of them were about the appalling nature of launching a new Governor contract.

none of them were about the appalling nature of launching a new Governor contract.

Can you explain why you feel deploying a new governor contract is “appalling” when it was built with this type of upgradability in mind. See Dan’s comment

It’s built to be replaceable by governance, and Compound (which Uniswap governance is forked from) has already done so once.

Whoops, that was sarcasm, I should have used the quotes.
I don’t think deploying the new governor contract is appalling, quite the opposite in fact.

I was referring to this:

Thank you for the helpful info!

Yes please! Only makes sense as this keeps it all within the governance critical criteria

This would be a good proposal , especially if the delegates would signal how they would vote during the voting delay so that the people who disagree can undelegate in time

2 Likes