This proposal is to enable a number of security improvements and bug fixes to currently deployed Gearbox V2 contracts. Rest assured, users wouldn’t need to perform any extra steps, all will be functioning as normal without interruption. Needless to say, any improvements were and will be audited with Chain Security. The core system parameters, such as asset LTs, fees, etc. will not be changed, but some new security parameters will be added (see below).
Note: the next sections are somewhat technical and require at least a high-level understanding of how Gearbox V2 contracts function. For a non-technical TLDR, skip to “Changes for users”.
Context & motivation
When Gearbox V2 was first deployed, there was still some ambiguity on the dev side on how users will interact with protocol - not in terms of PMF, but in terms of interfaces and UX. This led to some features and patterns from V1 being carried over, just in case users would require them for new use cases that V2 brought.
This is mainly relevant for three features:
- WalletConnect integration;
- adapters serving as direct interfaces for protocols (being able to call the UniswapV2 adapter to do a swap, in addition to using the Credit Facade multicalls);
- and fastCollateralCheck.
These features are challenging to support in regards to security - while they are solidly designed in themselves, they make the security analysis of the system, and especially new features, more complicated.
After tracking usage since the launch of Gearbox V2, we have decided that it’s worth discontinuing these features in V3. The usage of all is very limited - most users (even those that interact purely through contracts) use CreditFacade multicalls; while removing them allows us to implement code changes that would make the overall system more robust and help protect against some possible attack vectors. This will also help immensely in formal verification of the system.
After the Euler hack, we decided to revisit V2 and implement some of the new security additions in the already deployed contracts as well. Aside from that, there were a number of minor bug fixes and gas optimizations that were discovered during work on V3 and backported into V2.
List of 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. Adapters were optimized and streamlined, based on the fact that they can only be accessed during multicalls;
- Credit Account management functions (such as
enableToken, etc.) are no longer external functions in Credit Facade and are accessed through Multicall only;
CreditFacade.approve()was removed, since it was only needed for WalletConnect support;
fastCollateralCheckis removed from adapters (since fullCollateralCheck is performed after all multicalls);
- Improvements in CreditFacade:
- There are now circuit breakers that pause borrowing on loss, or even the entire system after too much loss is incurred. This will require setting Credit Facades as pause admins in the ACL contract;
- 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);
- 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 on liquidation - the borrower can use that contract to recover funds on another address;
- Emergency liquidations (i.e. liquidations while contracts are paused) now pay a premium like all liquidations.
- 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
controllerOnlyfor 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 new code can be found in:
- Core contracts in the
mainbranch of core-v2 starting from commit 710113f;
- Adapters in the legacy branch of integrations-v3 starting from commit e34cfbe;
Contracts to be replaced
- 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;
For new features outlined above, new parameters will be established:
Maximal cumulative loss before pausing a CM - equal to maxBorrowedAmount for each respective CM:
1.1) DAI - 1’000’000;
1.2) USDC - 1’000’000;
1.3) WETH - 600;
1.4) wstETH - 600;
1.5) WBTC - 50;
1.6) FRAX - 1’000’000;
Emergency liquidation premium - 4% for all CMs;
Total debt limit - corresponding pool’s expected liquidity at the time of deployment;
This update will also add two of the dev team bot addresses to the emergency liquidator set:
These addresses will be able to liquidate accounts while the system is paused due to emergency.
This is to prevent cases where a pause (required due to any emergency) results in otherwise safe Credit Accounts to go into below Health Factor < 1 state, and thus lead to bad debt.
Changes for end users
For UI users:
- WalletConnect support would be discontinued and the corresponding tab removed. Practically, it was always buggy and never got properly fixed, so nobody is factually being affected by this.
For smart contract users and integrators:
- All account management would be done through
CreditFacade.multicall()- this includes both adapters and CreditFacade functions for managing existing accounts, such as
increaseDebt. Account opening/closing is unaffected.
- 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;
The code changes are fully audited by Chainsecurity. Barring any critical issues, the new contracts will be deployed and connected to the protocol within 1-2 days after voting ends. That is to say, everything is ready, and is pending DAO vote & approval to let it all play out.