Given the turnaround for the two votes we had, why not something even higher (like 50%) ?
Stakers are incentivized to vote, hence there should be no issue with having quorum.
We thought about that but decided against it to make it easier for a dedicated group of smaller delegates and token holders to pass a proposal even without or against the larger delegates.
To avoid having this same discussion every other month, I would support a general rule for updating quorum to always require 3+ delegates.
For now that means 40%, but when there would be significant changes in delegated tokens, anyone would be able to propose a new vote to update it to be in-line with the 3+ delegate rule (max 1 vote per month or something like that).
I fully support the proposal to set the quorum to 40/50%, but I also want to highlight Frank’s comment.
Voting for quorum on a daily basis will be exhausting for everyone, so I wonder what other alternatives we have. @0xtucks I’d love to hear your opinion on the technical side on implementing something like a 3-delegate rule. Or what other alternatives we have.
IndexCoop had an interesting idea for a dynamic quorum.
Quorum is lower for proposals that are uncontentious, but as soon as the ratio of yes/no votes decreases it rises.
The rationale there being that a contentious vote needs more support to be ratified since the community isn’t unanimously in favor.
There’s a top and bottom boundary, which can be set to sensible values.
Imo this should be implementable in a smart contract, it’s simple math around parameters that are known anyhow.
Yeah I think 40% plus 10% seems the most inclusive. We’ll work to get this on-chain next week. We can update the quorum quarterly. I think that’s sufficient.
Given the calculations, I agree that the updated quorum threshold should be 140.91M / 975.13M = 14.45%. Since the quorum denominator is 100, the closest possible quorum numerator must be either 14 or 15??.
I believe to reflect the intended 14.45%, 15 would be the closest rounding since we usually have quite a lot of votes, effectively setting quorum at 15% instead of 14.45%. If we round down to 14, we’d technically be slightly below the target.
Would love to get final confirmation on which way we prefer to round, but either way, I’m aligned with the new quorum adjustment and the quarterly updates!
Please don’t be alarmed by the tenderly simulation failing.
The issue lies with the manner in which Tally simulation proposal execution.
The simulation is executed from the perspective of the timelock which for 90% of proposals is just fine.
However, when targeting the governor contract a crucial step is missed.
Assuming the proposal is successful. The execute method on the Governor contract will be called. In the body of this method, calldata is hashed and added to an array on the Governor contract.
if (_executor() != address(this)) {
for (uint256 i = 0; i < targets.length; ++i) {
if (targets[i] == address(this)) {
_governanceCall.pushBack(keccak256(calldatas[i]));
}
}
}
When the timelock then executes the queued proposal, and targets the Governor, calldata is retrieved from array and matched with the calldata being passed by the timelock.
if (_executor() != address(this)) {
bytes32 msgDataHash = keccak256(_msgData());
// loop until popping the expected operation - throw if deque is empty (operation not authorized)
while (_governanceCall.popFront() != msgDataHash) {}
}
It’s an additional layer of security when making updates to the SummerGovernor.
Secondly, it’s tricky for Tally to set this up as part of their tenderly simulations. It would require them to have specific handling for Governor targeted Timelock executed setups. Would require:
the use of testnets where the proposal is forced queued
and time jumped to when the proposal is eligible for execution
and the simulation would need call into the governor, and not the timelock, for the specific transaction
