Thanks @Coinballers for posting this.
Right now the current state of the art of the voting journey is:
- Off-chain discussions and polls;
- On-chain proposals.
What can we improve here? How can we speed up this process?
On-chain Voting Phase
The current approach requires 5 days (3 days for voting and 2 days as timelock) for an on-chain proposal to pass through the voting phase. This is an industry-standard already adopted by protocols like Compound and changing this can impact the security of the protocol.
The timelock might seem useless, but it allows people to exit the protocol if they don’t agree with the approved proposal. While some proposals are only related to Governance Ecosystem funds or minor fixes, others might affect users’ interests (eg changes in governance tokens distribution or protocol’s fees). This grace period gives members who voted No or didn’t vote the opportunity to redeem their assets before the execution of the proposal if they’re willing to do so.
It would be quite interesting to set up a framework to classify proposals’ impact on the protocol (simply, high/low impact). In this way, minor changes might have a faster consensus approach (e.g. 2 days for voting and 1 day as timelock) and the most important ones would continue with the current approach. This differentiation can even be applied to the minimum threshold and quorum for proposals.
What do you think? Any additional input on this would definitely help further discussions.
Off-chain Discussion and Consensus Formation
The governance process we’ve set up takes into account that a proposal often comes without any “ready-to-prod” code attached. If we look at the Smart Treasury, it took 6 Temperature Checks (Snapshot votes) to define community consensus on the proposal, pools’ weights, trading fees, grant applications, security review, and final Consensus Check (in approximately 2 months, considering holiday season and other development that were coming along at the same time). This is mainly due to the fact that this initiative’s parameters needed to be discussed with the community and it came without any code, so we had to go through the grant selection process, building phase, and security review.
As first improvement to this process, we have recently proposed to bypass the Consensus Check if the proposal has been widely discussed and accepted.
Furthermore, I think that the Pilot League (treasury committee) would be an initial way to speed up this process. As @idal said, multiple IIPs can be processed at the same time and having a PM that organizes discussions/grants/applications should quicken the implementation of a new proposal.
This Leagues structure can be improved further down the line with more departments that take care of a specific area of expertise (eg Development League, Treasury League, Communications League, …) effectively creating a more agile process that allows faster innovation and adequate due diligence process. We recognize that the majority of $IDLE participants might tend towards passivity over time and the Idle Governance architecture should allow for such reality as protocol improvements should be directed by a sufficiently decentralized community of competent professionals, but not necessarily all participants.
That said, DeFi governance space is still highly experimental, and the approach we’re taking is iterative. I think this discussion helps us to nail down where the bottlenecks are, and your feedback is definitely useful!
Where do you specifically see slowdowns in the “Off-chain Discussion and Consensus Formation” phase? Where do you guys feel it is unnecessarily bureaucratic (other than the final Consensus Check)?