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?
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.
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.
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