Gearbox Pre-V3: Redefine Security
Not too long after a protocol is launched, the questions turn to “What next?”. And then come in, through user actions and strategy, newer versions. Some with more features, some with tokenomics, some with strategic needs. But, with every iteration, the code sees addition of new complexities and potential attack vectors. So how do you progress without putting the security at risk? The answer to this problem is to not look at security as another building block but as a part of the entire system design. And that’s exactly why, Gearbox Pre-V3 launches this week.
While security is the top most priority for the release, the upgrade will also expand the strategy offerings with MiM’s Curve and Convex pools as well as expansion of our LLSD cohort with cbETH.
This article is largely divided into two sections. First, on the security module. This section will answer why the security upgrade is being made and what security changes to expect, links to contracts and also help users know about the UX changes. The second part will focus more on the strategies to be added and what APYs to expect.
NOTE: The GIPs for the above additions have already passed. You can find the snapshot links of the governance proposals below.
- Security Module: Here
- cbETH: Here
- MiM Pools: Here
Part 1: V3 Security Module
The “Why?”: Proactive System Design Approach.
As a protocol that at peak reached a TVL of $130M, ensuring user funds remain safe has always been our top priority. The decision to launch the V3 security module significantly earlier is a proactive one to streamline and bolster all modules of the codebase. It was guided by 3 key reasons.
- Reducing Complexities: Over the last 18 months, Gearbox has released two versions, V1 and V2. With every new version we see some new features that often lead to older ones not being utilised as much. An example of this is how Multicall took away 70% of the transaction volume from “Wallet connect” as users didn’t need to manually connect to other apps. The older features add to the complexity for security analysis. Thus, dropping and altering features to enhance security across the Gearbox codebase was a key reason.
- Battle and time testing for V3: Audits are vital for any codebase to be used but nothing is as assuring as a battle and time tested codebase. While we can get more audits done, we can’t buy time. Thus, implementing the security in advance enables us to ensure that the more growth focused V3 is launched on a tested codebase.
NOTE: Gearbox V3 is going to be built atop Gearbox V2 in order to maximise the security utilisation. At the time of deployment, V2 would be almost a year old and thus will have a robust and reliable codebase. You can read about V3 in the article below.
3. General DeFi Environment: Over the course of the last year or so, we have seen a few significant DeFi exploits. While all exploits are terrible for users, protocol and innovation, they also serve as lessons for other DeFi protocols. This was a key factor in deciding to dive deeper into Gearbox’s security and make the system as robust as possible.
Now that you know why, let’s dive in to the “What” of the upgrade.
The “What”. Overview of the changes: User PoV
User sided changes are the ones that’ll be result of contract level changes that lead to a change in existing change. This is the simplified outcome of the overall contract level changes.
NOTE: The changes will not affect the operation of a CA or the protocol. You can use the protocol as you do.
The user changes are:
- UI Level: For the users who use the dApp, there’s one key change. WallectConnect will be removed from the dApp and the connect page you see after opening a position will be removed too. Post introduction of multicall, users are now able to open a position in a single click and thus this method of connecting natively has lost almost all usage. While the security of the function is strong, maintaining it through iterations increases complexities. As multicall today processes over 70% of the transactions, it makes having WalletConnect for integrations redundant.
2. Contract Interactions: There are two key changes in regards to contract interactions that you can expect.
- Changes in Account Management: All account management would be done through
CreditFacade.multicall()- this includes both adapters and CreditFacade functions for managing existing accounts, such asincreaseDebt. Account opening/closing is unaffected. - Reading States: Most view functions were removed from adapters, unless the function does not exist in the contract the adapter points to. The target contract needs to be called instead of the adapter.
NOTE: GIP-53 completely captures all the changes mentioned in the article. If you are more tech savvy, you can read the complete details in the link below.
Overview of the changes: Contract Level
At the contract level, we have significantly more changes coming up. Majority of these improve upon existing code without changing or disrupting the logic with which it was built. This reduces the number of UX changes for the users. The types of changes can be classified into 4 categories:
NOTE: The core system parameters, such as asset LTs, fees, etc. will not be changed, but some new security parameters will be added (see below). All changes are audited by Chainsecurity.
1. Multicall as sole route to Adapter: As mentioned above, Walletconnect feature will be discontinued going forward. This means Multicall will be the only way to connect to adapters such as Lido, Convex etc. This leads to 4 contract changes.
- Adapters no longer allow direct calls to them: and only accept calls from CreditFacade — this means that managing an account is always done through Multicalls, and is always followed by a full collateral check.
CreditFacade.approve():Function to be removed, since it was only needed for WalletConnect support;- Credit Account management: Functions such as
increaseDebt,enableToken, etc. are no longer external functions in Credit Facade and are accessed through Multicall only fastCollateralCheck:To be removed from adapters (since fullCollateralCheck is performed after all multicalls).
2. Improvements to Credit Facade: Credit Facade is the module that enables users to manage and open/close Credit accounts while also facilitating Multicalls. With multicalls becoming the sole access to adapters, Credit Facade will now have additional functionalities. The 3 key contract changes are:
- Limiting System Loss: There are now circuit breakers that pause borrowing on loss, or even the entire system after too much loss is incurred. More on this in the Parameters category below.
- Exposure Limit: A total limit for borrowing in a Credit Manager can now be imposed (this is supported on pool level in V3, but in V2 has to be done in Credit Facade). This limits the exposure the protocol has to a certain asset and thus sugnificantly reduces the risk of bad debt.
- Emergency liquidations: These are liquidations while contracts are paused. These will now pay a premium like all liquidations. The premium will be set to 4%, as normal liquidations. This is to ensure that bots have the incentive to liquidate positions.
3. Parameters for circuit breakers: The circuit breakers mentioned above help limit overall system losses or bad debt and are another safety measure for the worst case scenario. The parameters dictate the values at which the circuit breakers kick in, as shown below.
NOTE: Gearbox has an active approach towards safety as seen with our Risk DAO engagements. Gearbox has never had any bad debt, you can check the logic behind risk management to control bad debt in the article below.
4. Bug Fixes and others: These are the bugs discovered while re-evaluating the system which are now fixed.
- USDC Liquidation: A bug was fixed whereas a borrower that is blacklisted by USDC would not be liquidatable until there are no remaining user funds on the account (i.e., until all funds go to the pool and the liquidator and nothing remains for the user). There is now a special contract where user funds are sent post liquidation — the borrower can use that contract to recover funds on another address.
- A bug in CreditConfigurator was fixed that caused replaced adapters to still be usable to manage a Credit Account. Additionally, modified the constructor to allow deploying a Credit Configurator for an existing Credit Manager.
- Added the controller role and replaced
configuratorOnlywithcontrollerOnlyfor some configuration functions - the controller is by default equal to the root address (technical multisig), but can be changed to allow for more fine-grained access.
The above fixes and improvements is what you can expect to take place over the time of the upgrade. We must add, there is going to be no disruption to service due to the upgrade and using the dApp will happen as expected. You can view the timelock GIP here.
Contract Replacements and Links
To execute the above mentioned points, there are a few contracts that’d require being replaced. These largely are:
- CreditConfigurator for each underlying asset’s CM;
- CreditFacade for each underlying asset’s CM;
- All adapters
- All LP price feeds (as price per share / virtual price bounds are changed to be configurable by the controller role);
- A new BlacklistHelper contract will be added to the USDC credit contract suite
In order to view the changes and the new code:
1. You can view the core contracts from commit 710113f on the link below
2. For Adapters, refer to `legacy` branch of integrations-v3 starting from commit 267eb7d
And that’s it on the Security part of the article. Now, for our beloved degens, read on to know how you will be able to earn 40%+ in a single click.
Part 2: Strategies and LLSD
MiM: 40%+ on Curve and Convex
The first of the 2, MiM’s Curve and Convex pools come to Gearbox. MiM is Abracadabra’s stable coin that is backed by multiple interest bearing tokens as collateral. Since the launch of V2, the top most used strategy by our Ninjas has been one of LUSD, gUSD, sUSD pools. MiM furthers Gearbox’s foray into stablecoin farming.
NOTE: The protocol could be argued to still have potentially about 5.5% bad debt. Therefore, the max LTV for LP tokens is set up at 85. A 5x leverage should still be relatively safe for the MiM pools. For complete details, refer to the forum link below.
Pish Posh- How much will I make?
Ah ye, we know Degen. The below table outlines the possible APYs with an average borrow rate of 2.08% on USDC and 9.96% Curve Pool APY. Even a 5x leverage offers above 40% APY.
Excited and want to try it out? Submit your wallet address you’d want access on here or ping us on Discord.
LLSD Expansion: cbETH
Coinbase’s cbETH or Coinbase Wrapped Staked ETH Coinbase is an ERC20 based liquid representation of a customer’s staked-ETH. cbETH has grown over time to become the second biggest LSD service after LIDO and today has a TVL of $1.77B.
The yield on cbETH at the moment is 4.41%. While borrow rates for ETH on Gearbox are 3.68%. Which means a 7X leverage could generate an APY of 9.58% on your LLSD position.
This is all for the V2.1/Pre-V3 Upgrade, you should see the same deployed over the next couple of days. Meanwhile, you can read all about Gearbox’s $25M+ LLSD market below:
What Next?
Ahhh! Kind of like a Marvel post credits scene. But since you read the entire article completely, you deserve to know a little more. With security of the protocol now ensured, it only makes sense to shift the focus back on growth, V3 and our 2023 plans. Here are the 3 things you can expect to see over the next month:
1. Risk Committee proposing new higher APY pools
If you go down our DeBank activity, you’ll find some alpha. Or you could wait a week. But multiple pools with APYs comparable to MiM’s will be up for discussion soon.
2. Gearbox 2023 Overview coming to life
Hint: Point 6. “What for the rest of ‘23?” in our overview below.
3. This one is chiller :D Happy Pizza Day
Oh, and obviously, Pizza on VIBES if you are top 3 in this weeks poker night. (Well, not a 10,000 BTC pizza but $50 USDC each :D )
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:
