Title
[GRFC] Sub-Proposal 1: Require GRO tokens to be locked to vote, and define off-chain governance processes
Author(s)/acknowledgements
- Raambo
- Graadient
- Jaypow
- KD
- Henrystats
- Beckley
Related discussion(s)
- One year in: Decentralising Gro
- https://www.notion.so/grodao/Gro-DAO-Structure-387b226c7a32409185b85b0154ebf511
- Get involved in Gro DAO’s new collaboration structure! - #26 by KD0x701137
- Open for application: People Pod facilitator role
Voting Options
Sub-proposal 1 proposes to:
- 1a) Allow only locked GRO tokens (i.e. vesting tokens that are still not vested) to vote
- 1b) Ratify what should be governed by who
- 1c) Ratify off-chain governance process
DAO members can either vote:
- FOR: approve the sub-proposal
- AGAINST: do not approve the sub-proposal
- ABSTAIN: no opinion on this proposal
Type (Proposed Changes)
- On-chain action: allow only locked GRO tokens (i.e. vesting tokens that are still not vested) to vote
- By setting the voting weight for liquid GRO on the vote aggregator contract to 0
- Off-chain action: Ratify what should be governed by who
- Define current and proposed distinctions of what should be governed by who, for;
- DAO votes resulting in on-chain actions
- DAO votes resulting in off-chain actions
- Pod/ Committee-Level Operations resulting in on-chain actions
- Pod/Committee-Level Operations resulting off-chain actions
- Emergency functions
- Define current and proposed distinctions of what should be governed by who, for;
- Off-chain action: Ratify off-chain governance process
Summary
Gro DAO governance should move on-chain, enabling votes to be held and executed by smart contracts autonomously. Accordingly, as part of a wider meta-governance update, the following three sub-proposals will be proposed, for the DAO to proceed:
- Require GRO tokens to be locked to vote, and define off-chain governance process
- Approve an Emergency multi-sig and define its powers
- Implement on-chain governance via a governor contract and define its powers, and define on-chain governance process
This post focuses on sub-proposal 1, which needs to be passed before sub-proposals 2 and 3 can be raised.
Rationale
1a) Allow only locked GRO tokens (i.e. vesting tokens that are still not vested) to vote
To further enhance the alignment of DAO members (GRO token-holders) with the long-term success of Gro DAO, a new governance model should be implemented. This model would allocate greater voting power to members who have longer commitments, as indicated by their vesting (locked) GRO tokens. Similar to how Gro DAO’s current vesting bonus mechanisms work, this incentivises longer-term commitments by giving members greater influence in exchange for them continuously re-vesting their liquid or already vested GRO tokens.
This governance model is inspired by Curve DAO’s popular veCRV model, which is widely recognised to align the long-term interests of the DAO with that of DAO members (token-holders), by basing DAO members’ influence on their vesting governance tokens. It requires participants to lock up (vest) governance tokens for a set period, while the vote aggregator contract only counts currently vesting tokens (tokens still locked in the vesting contract), towards votes. The proportion of tokens that are vested increases linearly from 0% on day 1 to 100% on the last day of the vesting period, so unless vested tokens are put back into vesting, a DAO member’s vote in governance decreases linearly from 100% of their vesting tokens on day 1 to 0% on the final day.
Gro DAO already has GRO token vesting contracts for community members, founding team members, advisors and seed investors, that reward those who lock up their GRO for a longer period (see more on Gro DAO’s 1 year community vesting period here).
Accordingly, to implement this change (if approved by the DAO), the voting weight for liquid and already vested GRO on the vote aggregator contract would be set to 0, so that only the DAO members, team members, advisors, and seed investors who are vesting their GRO tokens would have voting rights. This modification ensures that the interests of DAO members are better aligned with the long-term success of the DAO.
1b) Ratify what should be governed by who
It is important for the DAO to understand the proposed governance processes going forwards, including what requires DAO governance (especially if and when automatic on-chain governance execution is enabled).
To strike a balance between decentralisation and efficient execution, Gro DAO adopts a governance-minimised approach. This involves simplifying and hard-coding contracts to limit the need for governance, and relying on broad-based governance for convex decisions while handling concave decisions at the execution layer (the pod/committee level). By doing so, the DAO is able to maintain agility and speed while ensuring that critical decisions receive the appropriate level of oversight.
Table 1 (see here) illustrates what is currently governed and implemented by whom, and what should be governed and implemented by whom over time. It is worth noting that even if and when on-chain governance (sub-proposal 3) and an emergency multi-sig (sub-proposal 2) are configured, not all actions will be configured for automated execution immediately.
See TABLE 1 for a high-level breakdown of the actions that can be governed and executed by various DAO pods/committees, contracts and/or addresses.
1c) Ratify off-chain governance process
As seen in Lido and Yearn’s governance, there can be two parallel governance processes that can be taken, depending on whether the nature of proposed action is on-chain or off-chain (as seen in Table 1).
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 cannot be used to implement the resulting actions (either because on-chain governance is not approved by the DAO or because the respective proposal would not result in an on-chain action), the off-chain governance process result (though technically non-binding) is considered as the final vote:
- Discuss in Discord at #governance channel
- Write a Gro Request For Comments (GRFC) on [image]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 [15 members] participating in a passing signalling vote) that the proposal should be taken to vote, addresses with [175,000+ vesting or delegated vesting GRO tokens] (~0.5% of circulating GRO Supply), or whitelisted addresses; can initiate the proposal on Gro DAO’s Snapshot, using this Proposal Description Template
- The vote would be live for at least [5 days] for off-chain voting on Snapshot, and would need to meet a quorum of [350,000 vesting GRO] (~1% of circulating GRO Supply) and a passing rate of over [50%]
- A successful vote would have [3 days] of timelock for implementation (if applicable), allowing time for emergency multi-sig to act if there’s a malicious attack
See further details here for the definitions and logic behind proposed parameters and delegation.
When on-chain governance can be used to implement the resulting actions, the on-chain result can be considered as the final vote. However, this on-chain governance process will only be formally voted on during sub-proposal 3, because until then, Gro DAO would still be entirely governed through off-chain governance.
Implementation
1a) Allow only locked GRO tokens (i.e. vesting tokens that are still not vested) to vote
- The voting weight for liquid and already vested GRO on the vote aggregator contract would be set to 0
- This will require a low-effort single transaction to be executed (~20 minutes of prep), with negligible gas fees
1b) Ratify what should be governed by who
- Have agreed upon breakdown documented in Notion
1c) Ratify off-chain governance process
- Have agreed upon process documented in Notion
- Change Snapshot proposal threshold from 1,000,000 to 175,000 GRO
- Change Snapshot quorum from 50,000 to 350,000 GRO
- Add the with-delegation strategy to the Gro Snapshot space
Benefits (Pros)
1a) allow only locked GRO tokens (i.e. vesting tokens that are still not vested) to vote
- Ensures greater alignment between the DAO and its members
- Further incentivises longer-term commitments to the DAO
- Reduces risk of governance attack ahead of on-chain governance implementation becasue: as more direct power is held by DAO token holders, the more important it is to have a protected system. Currently, 1 locked/vesting GRO token, 1 unlocked/vested GRO token and 1 claimed/liquid GRO token all count as one vote. This leads to a potential attack scenario where a user buys a large amount of GRO, creates an unfavourable proposal, votes for the proposal, and then dumps their GRO tokens before negative consequences of the proposal can impact the value of the GRO token.
- Enables Gro DAO to lower proposal thresholds (from 1,000,000 to 175,000 GRO on Snapshot) which also increases and encourages greater voter participation
1b) Ratify what should be governed by who
- Greater clarity on current and future governance processes
- Further streamlining of DAO operations
- Understanding on Gro DAO’s progressive decentralisation journey
- Sets context for sub-proposal’s 2 and 3
1c) Ratify off-chain governance process
- Greater clarity on off-chain governance process
- Lower threshold to make proposal
- Enabling voter delegation makes it easier for DAO members to meet proposal thresholds, and for votes to meet quorum thresholds; and would give voters the chance to delegate to an informed and competent representative (where helpful), to increase total voter participation
Downsides (Cons)
- Greater operational overhead
- More complicated processes that need to be understood by DAO members
- Higher quorum thresholds need to be met for future proposals to be passed
Technical documentation
Submission date and next steps
- Date of Submission: 2023-05-12T23:00:00Z
- Move proposal to Snapshot if RFC feedback is implemented and there is sufficient support: 2023-05-21T23:00:00Z
Signalling Vote
Please indicate below whether you are FOR, AGAINST; or have no opinion (ABSTAIN); on this sub-proposal.
- FOR: approve the sub-proposal
- AGAINST: do not approve the sub-proposal
- ABSTAIN: no opinion on this proposal
0 voters
This RFC will be open for comments over the next [6 days]. If no substantial changes are required, it will then be open for voting for another [5 days].
