[GIP-53] Gearbox V2 Security Improvements

Proposals
1

Overview

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 increaseDebt, 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;
  • fastCollateralCheck is 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 configuratorOnly with controllerOnly for 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 main branch 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;

New parameters

For new features outlined above, new parameters will be established:

  1. 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;

  2. Emergency liquidation premium - 4% for all CMs;

  3. Total debt limit - corresponding pool’s expected liquidity at the time of deployment;

Emergency liquidators

This update will also add two of the dev team bot addresses to the emergency liquidator set:

  1. 0x16040e932b5Ac7A3aB23b88a2f230B4185727b0d
  2. 0x3c2E5548bCe88315D50eAB4f6b1Ffb2f1B8eBd7A

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;

Timeline

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.

2

Super cool. Love the attention to secuity.

When is timelock scheduled for then, just after or into V3?

3

Should actually be before V3, since we’ll ideally be ready to deploy next week. V3 will need some more time in the oven after that.