Gearbox Risk Foundation: Making security transparent
Gearbox has been on a development spree with multiple product upgrades in the pipeline. Curve V2 pools are approved for deployment, Gearbox V3 and Trading dApp is in Audits. But with all this about to be deployed, how do you trust that the audited code is the one being deployed, how can you in real time check risk and multi-sig updates and importantly, what do you do when there is risk? Let us bring you, GRF. Gearbox Risk foundation. Bringing the “Don’t trust, Verify” and Transparency ethos to the dev and multisig activities too.
You can find the vision behind what gearbox is building in the thread below. Meanwhile, back to GRF.
What is GRF?
GRF or Gearbox Risk Foundation is open documentation that brings transparency around risks related to anything Gearbox. The page is open to all on risk.gearbox.foundation, documenting all risk events, performing monitoring on the same and laying out actions to be followed in case an event occurs. It further lets you verify any tech multisig transaction that takes place. This is done by enabling anyone to compare the executable transaction with the audited code on Github or verifying if actions related to a GIP are followed. These efforts are made to make risk and tech actions transparent and verifiable. They act as an addition to our security practices.
This is for the risk and security side. The DAO’s efforts regarding operational transparency can be verified through our monthly updates.
Gearbox’s Security Efforts and V2.1
GRF is an additional open source monitoring mechanism in addition to Gearbox’s security practices. With the recent exploits in DeFi, Gearbox understands how important it is to have a robust security arsenal and below are the steps we have taken.
- Gearbox V2.1 Security Update: In July, Gearbox deployed it’s V2.1. The purpose of V2.1 was to bolster the security and to battle test the codebase used to build V3. The update cut out complexities from previous versions, removed any possible bugs the DAO or external devs could find and to reduce attack vectors. You can read the complete details in the article below.
- Audits: Gearbox has had 8 audits till date, check here. V3 is already lined up for 2 more.
- Bug Bounty: Gearbox, since being live, has had a bug bounty program live and code open. This incentivises white hacks to find bugs in the codebase and enable us to mitigate them.
- Third Eye Intelligence tool: Third eye intelligence is another monitoring and intelligence tools that queries data regarding Health checks, liquidations and more for Risk Contributors and helps them avoid any issues before they happen.
- Risk DAO Partnership: Risk DAO has now been working in conjunction with Gearbox for a year. Risk DAO has helped develop the frameworks and values for LTVs that help mitigate bad debt. RiskDAO creates monthly reports as well as helps real time evaluation of risk with the risk Dashboard.
- Insurance: Beyond these measures Insurace and Nexus Mutual also offer insurance to users.
While Gearbox has faced 0 exploits in 2 years of being live, no security measures can ensure 100% safety guarantee against all the risks. But what are the risks?
Risks covered by GRF
You can only prepare for the risks that you are aware of, the first of GRF thus is to outline all the possible risks. They are as listed below:
- Collateral Risks: The risk of loss arising from errors in the nature, quantity, pricing, or characteristics of collateral are called Collateral Risks. Examples being the collateral being blacklisted(ex USDC), malicious implementation of a proxy-based token etc.
- Market Risks: Risks that arise due to the change in the structure of markets for a token itself. Examples being reduction in liquidity on DEXes for a token, removal of liquidity from a token etc
- Front-End Risks: Risks involved with creating a user interface and user experience of the dApp cumulatively form the front end risks. Examples are unexpected DNS changes, phishing, approval to unknown address etc.
- Infrastructure Risks: Risks involved with the failure or misappropriation of the infrastructure that helps Gearbox functions. Examples are Liquidators not functioning, monitoring mechanisms not working etc
- Governance Risks: Risks that arise out of malicious management, implementation or executions arising through the technical multisig. Example being replacement of code with a malicious code, passing of malicious non-aligned transactions.
- Oracle Risks: Risks associated with the data providers and the logic implementation of the same for various assets constitute oracle risks. Examples are oracle deviations, oracle prices breaching bounds etc.
While these risks can seem scary, what matters is thorough management of the same in order to keep the system safe. This is enabled by comprehensive monitoring and an action plan for all possible risks.
GRF Monitoring: Risk Events and Protocol Updates
There are 2 kinds of monitoring required to ensure safety: Expected Updates Monitoring and External Events or Testing monitoring. GRF enables both through the following
1. Protocol Updates: Internal Updates Monitoring
These are the updates that happen through the actions of the devs and the multisig. Through GRF, you can monitor any transaction that goes to the multisig for signature and understand them in simpler terms as well.
You can monitor exactly what the tech multisig is about to execute through this page. You should first confirm if the transaction is an approved one through DAO votes or one required as an action towards certain risks. In case of any discrepancy, you should reach out on Discord for clarity.
2. Event Feed: Monitoring Risk Events
Risk events are occurrences associated with the risks defined above. They can either be unexpected or related to tests that we create in order to monitor the protocol.
The page monitors sources of risks and in case there does arise a risk event, it is flagged on the page and contributors are notified. For example, as seen in the image above, drop in liquidity for SNX by 55%. But this is an approach that is reactive in nature. Flagging after an issue arises could still lead to bad debt. So how do we turn this proactive?
Optimistic Liquidations: Proactive Risk Management
On the Risk Event page itself, you’ll come across a periodic notification. These are the Optimistic Liquidation notifications. Optimistic Liquidations periodically start a node with forked mainnet state. It then attempts to close all existing accounts on the forked state. This test ensures that in a critical moment all liquidations will execute correctly. Success on this test helps avoid bad debt.
If the liquidations take place as intended, the update comes in as a succesful execution. If it doesn’t, the issue is posted on the page and devs are notified to take action. This though might happen before any issue flags are raised as it’s continuous test of market and Gearbox’s interactions with it. Thus turning the process pro-active.
Now that we know the way pro-actively find any risk events, how do we manage them?
Actions: Dealing with Risk Events
To put it simply, “Actions” page on GRF is the playbook of dealing with a risk event that might occur. It highlights the steps needed to be taken in case of an event, for all the possible risk events that we could map out.
Just go to the actions page and click on the related action for an event and you’ll know exactly how the devs are likely to battle it. From this point you can ensure that the “Protocol Updates” that come in for an event follow what’s mentioned.
But that’s not enough, for complete security you should VERIFY that the transaction being pushed to the multisig is the one audited or mentioned in actions. How do you that?
Verification: Minimising deployment related trust
While the above explains how Forbid Token works, you accepting and believing multi-sig and contributors doing the right thing is based on trust. Which is what we want to change with GRF by enabling users to understand and verify at a contract level itself.
1. Go to the “Protocol Updates” page and check for the event related transaction. Within the update, you will see a link to the GitHub- Denoting auditted code submited by the auditor. And an etherscan code- the transaction sent to the multisig.
2. Head over to both the codes and open a diffchecker.com webpage as well
3. Paste the codes in diffchecker and compare if both the codes are the same
4. If they are the same, then the system works as intended. In case of a mismatch or confusions, you can ask all the questions in Discord.
And in this manner you can verify the deployment integrity.
Summary
That’s how Gearbox aims at removing the trust based nature of deployment and managing risk. But to do this, we need to ensure that the community knows that an Action is underway, understands if it’s the right one, finds out the way it is to be executed, confirms execution and the truthfulness of the code being deployed. If together the community and the contributors execute this, we can be assured of an even more robust Risk Framework.
With Curve V2, Gearbox V3 and a trading dApp coming up, there’ll be a lot of deployments incoming. Thus, having a system that makes it trustless is key in following the ethos of DeFi and safety of Gearbox.
Psst! Want to access the Curve V2 pools mentioned above? Drop in in our Discord or post your addy on the gov forum to gain access. And that’s all for the DAO update bosses. If you would like to join — just get involved on Discord. Discuss, research, lead and share. Call contributors out on their bullshit and collaborate on making things better. Here is how you can follow developments:
- Website: https://gearbox.fi/
- dApp: https://app.gearbox.fi/
- User Docs: https://docs.gearbox.finance/
- Developer Docs: https://dev.gearbox.fi/
- Forum: https://gov.gearbox.fi/t/start-here-forum-rules/
- Blog: https://medium.com/@gearboxprotocol
- Github: https://github.com/Gearbox-protocol
- Twitter: https://twitter.com/GearboxProtocol
- Snapshot page: https://snapshot.org/#/gearbox.eth
- And, of course, the DAO working docs:
