On-Chain Governance Process

The following steps illustrate the requirements to raise and vote on a proposal in the scenario where only vesting GRO counts towards votes. When on-chain governance can be used to implement the resulting actions, the on-chain result can be considered as the final vote:

Discuss in Discord at #governance channel
Write a Gro Request For Comments (GRFC) on Gro DAO Forum, following these guidelines on writing GRFCs, and use the poll feature to conduct an informal signalling vote
After at least [6 days]* of GRFC, if feedback has been implemented and there is a general consensus (as determined by GRFC feedback and by at least [30 members] participating in a passing signalling vote) that the proposal should be taken to vote, addresses with [350,000+ vesting or delegated* GRO tokens]** (~1% of current*** GRO Supply), or whitelisted**** addresses; can initiate the respective on-chain proposal, following this Proposal Description Template
This proposal has [2 days]* (in line with Compound) for view before it goes live for voting so that the payload can be updated, any resulting on-chain actions can be simulated, token holders can delegate their voting power or buy more votes before the vote starts, and the DAO can double-check for any potential threats before the vote goes live.
The vote would be live for [5 days]* for on-chain voting, and would need to meet a quorum of [1,500,000 vesting GRO]* (~4% of current *** GRO Supply) and a passing rate of over [50%*]
A successful vote can be queued for [3 days]* of timelock for implementation, allowing time for emergency multi-sig to act if there’s a malicious attack

Screenshot 2023-05-11 at 15.12.49.png

CAVEATS:

*Parameters:

Proposal threshold, quorum, timelock, voting period, and voting delay:
- Are aligned with those set by similar-sized DAOs (e.g. Inverse DAO, Origin DAO, Idle DAO, Angle, Lido, Aave) and protocols (as defined by market cap, treasury size, TVL) that use a vesting-governance model
- Take into consideration current voter participation rates within Gro DAO and distribution of GRO tokens
- Have been proposed to balance safety and security, with greater autonomy
- Follow Tally’s guidance on parameters for balancing between ease of passing proposals and security against malicious proposals

Parameter	Definition	Tally Recommendation
Proposal Threshold	the amount of voting power that an account needs to make a proposal.	• 0-2% of circulating token supply
• at least 5-10 delegates should have enough voting power to make a proposal
Quorum	the amount of `For` votes – sometimes also including the amount of `Abstain` votes – for a proposal	• 1-10% of circulating token supply
Voting Period	how long voting lasts on each proposal	• 3-7 days
Voting Delay	time between when a proposal is submitted and when it goes up for voting	• 1 day
Timelock	minimum amount of time between when a proposal posses and when it can be executed	• 3-7 days for if the Timelock has someone with an emergency veto/cancel role and if the governor manages a DeFi protocol

As more GRO tokens get distributed and the current supply of GRO increases, the absolute parameter values will need to be updated over time.
The parameters for off-chain votes are lower than those for on-chain votes, as by definition, these cannot be used to conduct a significant governance attack.

**Delegation:

It is proposed that voters can delegate their votes to others in order to more easily meet the aforementioned parameters. By aggregating GRO tokens together through delegation contracts, it becomes more feasible, for example, that someone else other than core team members can initiate a proposal. Additionally, it would give voters the chance to delegate to an informed and competent representative (where helpful), to increase total voter participation and allow voters to avoid paying gas fees (by sending signatures to a delegate who then executes the aggregated on-chain vote, if applicable). Guidance on how to delegate governance tokens to an address, can be found here.

***Current Supply of GRO Tokens