Gearbox V3: Evolving the Governance Model

It's been 2 years since Gearbox Protocol went live with a DAO first model. Focussing on handing over the protocol to the DAO and empowering the community to turn into DAO contributors. 2 years down the line and the DAO run protocol is about to launch its V3. But, as we move, it's necessary we evolve. And now we explore possibilities to evolve our governance too.

In this article, we delve into Gearbox Protocol Version 3, highlighting its transformative governance model. Addressing past limitations, the new version introduces permissionless execution of queued GIPs and a Controller role for enhanced operational efficiency. These changes signify Gearbox Protocols commitment to more adaptable, secure, and user-centric blockchain governance.

Current Limitations of Governance

All existing safe systems rely on time locks, leading to queued transactions being executed in a delayed manner. This process, while secure, introduces a two-fold limitation. Firstly, executing a single transaction requires gathering multisig twice – once for signing the queue and again for execution. Alternatively, adding two transactions simultaneously hinders the addition of an urgent queue transaction, reducing flexibility. This is a known issue among all governance implementations, be it via snapshot offchain or full onchain bravo.

Remember this Compound case, where a single letter bug in its code caused the contract to issue more COMP tokens than it should. This is a prime example of the limitation.

As a result, any changes, even urgent ones, currently require a minimum waiting period of 3-4 days (2 days for the time lock and 1-2 days for signing in Gearbox DAO case). This delay significantly hampers the responsiveness of protocol management. For example, the Compound case above could have been solved if there were more roles in place that could avoid such situations.

While governance experimentation continues with regard to non-plutocracy models and centralization (quadratic voting and whatnot), today’s piece is about practical implementations of these events. The best governance is the one that doesn’t exist, but before we get there, we need functional governance which is able to secure the system and make it decentralized, but not be a bottleneck either.

New Gearbox governance model

Gearbox requires protocol management for various aspects like risk assessment, oracle updates, and the addition of new assets, all of which necessitate decision-making. In developing Version 3, our objective was to refine the governance process to make it:

Convenient and cost-free: Retaining the voting mechanism on Snapshot ensures that community members can participate in governance without incurring any fees.
Cross-chain capable: Preparing for deployment across different networks is crucial, as it expands the protocol’s reach and versatility.
Rapid-response ready: Ensuring the ability to quickly adapt and implement changes is essential for staying relevant and effective in a fast-paced environment.
Enhanced Security: Achieved through fostering transparency and providing a suite of open-source tools. These tools are designed to make every change in the protocol understandable, even for those without a technical background. This approach ensures that all community members can stay informed and contribute to a secure and stable ecosystem.
Operationally efficient: Allowing for seamless operational tasks without overburdening the community with additional responsibilities.

The discussion on the new governance model and the way forward on how V3 will be deployed are now live on our Discord forum. You can click on the image below to check them out.

Snapshot vs Onchain governance

I previously held the belief that onchain governance was the superior method, largely due to its numerous benefits. However, I’ve come to recognize its significant drawbacks:

Voting costs: Each vote requires payment of gas fees, which restricts participation to those with substantial holdings, skewing representation. Hard centralization. Of course, security doesn’t come without costs, but this is not necessarily full-proof either.
Cross-chain governance complexity: This process heavily depends on bridges and messaging used, introducing additional risks and complications. As such, in case your governance becomes cross-chain, you are only adding risks compared to the snapshot model. Your full onchain governance with gas costs doesn’t considerably look much safer in that case. As one chain, it does, but with 1+ chains and gauges - not anymore.
Development and audit demands: Implementing a system where staked tokens can be used for voting requires considerable development resources and thorough auditing.

Suggested model combines the best of two approaches: voting is still happens on Snapshot as previously, however, token holders vote for concrete batch of transactions (like in Bravo), which would be automatically executed if voting was successful of desired chain. It's still costs zero for users, votes are protected by cryptographic signatures, and execution is automated. Additionally, this solution could be easily used across many chains.

Gearbox till date has had 78 snapshot votes or about 1 vote every 8 days. These are all available on our snapshot page below

This framework not only maintains safety and scalability across multiple chains but also ensures that voting remains free of charge, encouraging wider participation.

Updated governance flow

In the upgraded Version 3 of Gearbox Protocol, a new ‘Governor’ contract has been developed to enhance the flexibility of protocol management by changing the interaction format. New model involves three key roles in the decision-making process:

Queue Admin: This role is empowered to add transactions for execution. The new contract allows for multiple Queue Admins, enabling the integration of voting systems like oSnap and Snapshot X (to deliver voting results onchain), among others. This integration aims to automate the process of operational decision-making based on voting results.
Veto Admin: This role functions as a rapid-response (3/10 or 3/12) multisig, capable of flagging a transaction. It’s designed to provide a swift reaction in cases where an added transaction is identified as erroneous or malicious.
Executor: This role is responsible for executing transactions that have passed the time lock and have not been vetoed. In a significant shift from previous versions, any user can now assume this role, provided they cover the gas fees.

These roles collectively aim to streamline the governance process, making it more responsive and adaptable to the needs of the Gearbox Protocol community.

Controller role and operational automation

Another key enhancement in the governance system has been the introduction of a ‘Controller’ role in most contracts for parameter configuration, where voting might be superfluous. For instance, in fine-tuning Liquidation threshold (LT) ratios within a specific range, this role can save time that would otherwise be spent on voting and reduce the community’s burden. Moreover, it enables quicker responses to market changes and more efficient system adaptation.

However, the scope of changes that the Controller can make is deliberately limited. This ensures that even though these settings might be managed by committees within the DAO, they cannot significantly alter system parameters in a way that leads to major consequences.

This approach has effectively implemented a pattern where the DAO can delegate the task of setting or adjusting parameters within certain limits to responsible committees. This delegation reduces the workload on the broader community, streamlining the governance process.

Conclusion

The best code is the code that isn’t written. Similarly, the best governance is the one that’s unnecessary. Blockchain, by its nature, is deterministic, and currently, I don’t see the feasibility of implementing probabilistic models, which are generally more adept at risk assessment and similar tasks.

In the third version of our protocol, we’ve strived to make the process as scalable and transparent as possible. Alongside this, we’ve enhanced our deployment and protocol update system, a topic I will delve into in the next article.

This approach underscores our commitment to simplifying and refining our processes, ensuring that our protocol remains efficient and user-friendly.

Of course, like everything till now the implementation of above mentioned information is dependent on a DAO vote. And the GIPs

Come join the DAO if you would like to contribute or just vibe — just get involved on Discord or Telegram. Discuss, research, lead and share. Call contributors out on their bullshit and collaborate on making things better.

Website: https://gearbox.fi/
dApp: https://app.gearbox.fi/
User Docs: https://docs.gearbox.finance/
Developer Docs: https://dev.gearbox.fi/
Github: https://github.com/Gearbox-protocol
Telegram: https://t.me/GearboxProtocol
Twitter: https://twitter.com/GearboxProtocol
Snapshot page: https://snapshot.org/#/gearbox.eth
And, of course, Notion monthly DAO reports: