Great to see an update of this document.
A couple of things that stands out to me:
-
I still think we should redefine the “Receive input from at least 5 stewards”-requirement. A small edit to something like “Receive input from at least 5 stewards not connected to the proposal” would be a great start.
-
I feel like using the terminology “soft vote” and “hard vote” for Snapshot and Tally is quite misleading. If things haven’t changed from earlier version of this document governance is happening on Snaphot, exclusively. Anything that reaches Tally has already been discussed, proposed and ratified by the Stewards and should therefore always pass.
-
Is the concept of “soft quorum” no longer being used?
This document states that “Any change to the quorum requirements must be ratified by the community” which AFAIK hasn’t happened. -
MMM created this dashboard recently with information of our Gov Alpha set up. Part of it could be added to this document for (much needed) clarity regarding how on-chain proposals on Tally actually works. See excerpt below:
"GitcoinDAO Gov Alpha details*
GTC governance is a fork of the COMP/UNI governance systems. It uses Governor Alpha and Timelock.
Gitcoin: Governor Alpha contract address | Gitcoin: GTC Timelock contract address
Governor Alpha is the governance module of the protocol; it allows addresses with more than 1,000,000 GTC ( proposal threshold ) to propose changes to the protocol. Addresses that held voting weight, at the start of the proposal invoked through the getpriorvotes function, can submit their votes during a 40320 Ethereum blocks voting period . If a majority, and at least 2,500,000 votes ( quorum votes ) are cast for the proposal, it is queued in the Timelock, and can be implemented after 2 days.
Timelock extensions add a delay for governance decisions to be executed. The workflow is extended to require a queue step before execution. With these modules, proposals are executed by the external timelock contract, thus it is the timelock that has to hold the assets that are being governed.
Queue After a proposal has succeeded, any Ethereum address can call the queue method to move the proposal into the Timelock queue. A proposal can only be queued if it has succeeded. The waiting period begins when this function is called => 172800 seconds (2 days).
Execute After the Timelock delay period, any Ethereum address may invoke the execute method to apply the changes from the proposal to the target contracts. This will invoke each of the actions described in the proposal. The function is payable so the Timelock contract can invoke payable functions that were selected in the proposal.
The minimum time to vote, pass, and execute a proposal is 10 days and 8 hours approx.
