# Turbo C4 Auditing Guide
**Codebase:** [Turbo](https://github.com/fei-protocol/fei-turbo/tree/main)

**Start Date:** Thursday, Feb 17, 2022

## Overview

This audit is primarily focused on Fei Turbo, a lending liquidity accelerator. It also includes the Solmate ERC-4626 Base implementation which is used in the solmate repo. For more information on ERC-4626 [see the live EIP](https://eips.ethereum.org/EIPS/eip-4626).

Turbo is a novel DeFi mechanism sitting one layer of abstraction above lending markets such as Fuse and synthetic credit facilities like MakerDAO. It uses FEI as the base asset which is *generated* through Turbo Safes, which are collateralized vaults similar to Maker Vaults. The key difference between Turbo and MakerDAO is that issuance and lending are segregated into their isolated components, with the lending portion managed by a distinct Fuse lending market.

The goals of Turbo are:
* Increased availability of FEI borrowable liquidity in Fuse
* Revenue sharing incentives for users
* No upfront cost for issuers
* Risk minimization for Tribe DAO
* Governance minimized, market determined usage

## Architecture

The Turbo architecture revolves around 3 key pieces (Turbo Master, Turbo Safe, Turbo Fuse Pool) as well as a series of modules (Booster, Clerk, Gibber) which can be swapped for logic upgrades.

### Turbo Master
The Turbo Master is a minimal factory, registry, and adapter to the various modules in the Turbo system.

It is the location where:
* users can permissionlessly create new Safes
* new boost actions are checked via the Booster, less is open access
* global state is maintained regarding active Safes/boosts
* Tribe DAO can claim fees

### Turbo Fuse Pool
The base Fuse pool which acts as an accounting/liquidation layer for Turbo Safes. It is permissioned such that only Safes created through the master can access the pool's liquidity. The FEI in the pool is borrowable with flat, 0% interest.

Tribe DAO governs the Turbo Fuse Pool parameters and listings. These are a layer where governance can restrict the types of Safes that can be created and introduce different supply and borrow caps.

### Turbo Safe
Turbo Safes wrap user positions in the Turbo Fuse Pool, and enforce that borrowed FEI is deposited into a whitelisted Vault under conditions checked by the Booster.

All underlying collateral is held directly inside the Turbo Fuse Pool and the safes hold fTokens and fees.

Fees are claimed automatically upon boost/less calls and can be manually claimed by the owner or governance.

Safes can be force-liquidated by the Gibber, discussed below.

### Booster Module
The Turbo Booster checks data regarding a given boost operation against different governance caps to make sure the boost is eligible, otherwise it reverts.

### Clerk Module

The clerk determines revenue split for yield earned by Safes. There is a global default with possible overrides per asset/Safe.

### Gibber
The Gibber is responsible for force liquidating positions. The reason for this is that a Safe position may become insolvent, but liquidation is only possible when the position becomes undercollateralized.

Positions should be force liquidated under conditions where the position is impossible to close and there is bad debt in the system. To protect users, the Gibber will function behind an immutable and lengthy timelock. Any gib() operation must have extended notice via this timelock.

## User Flows
Users can perform 6 actions in the system:
* Create Safe - create a new Turbo Safe
* Deposit (ERC-4626) - deposit new collateral into the Safe
* Withdraw/Redeem (ERC-4626) - withdraw collateral from the Safe
* Boost - generate new FEI into a ERC-4626 Vault to earn yield and provide liquidity
* Less - reclaim FEI from a boosted Vault and accrue fees
* Sweep - collect any reward tokens or revenue split on FEI yield for user

### Create Safe

Each Turbo Safe has 1 underlying collateral type and an uncapped number of FEI ERC-4626 Vault destinations. This architecture optimizes for having specific boost caps/revenue splits per collateral asset. Cross-margining complicates this significantly.

### Deposit

Deposit new collateral straight into the Turbo Fuse Pool. This enables new boost calls subject to collateral whitelisting, LTV thresholds and other caps.

### Withdraw

Withdraw collateral from the Turbo Fuse Pool. Subject to collateralization requirements.

### Boost

Atomically borrow FEI from the Turbo Fuse Pool and allocate it to a FEI Vault for yield generation. Subject to a Booster check which involves various caps and whitelists.

### Less

The inverse of a boost operation. There is no check, this can be done permissionlessly and cannot be paused.

### Sweep

Claim any ERC-20 in the Safe other than boosted vaults and fToken collateral. Used to claim FEI fees accrued in the Safe.

## Governance and Administration

Turbo has many layers of administration and configurability on 3 levels:
* Turbo Master + Modules
* Turbo Fuse Pool
* Turbo Safe

## Turbo Master + Module Administration

The Turbo Master has an [Authority](https://github.com/Rari-Capital/solmate/blob/main/src/auth/Auth.sol) which gates the following actions as follows:
* set booster - DAO governance
* set gibber - DAO governance + 3 week timelock (to allow other DAOs time to react)
* set clerk - DAO governance
* create safes - whitelist DAOs + large holders to start, fully permissionless within a short period from launch
* set default authority (for Safes) - DAO Governance
* claim fees - Public fee claimer contract

The TurboBooster [Authority](https://github.com/Rari-Capital/solmate/blob/main/src/auth/Auth.sol):
* setFreezeStatus - DAO governance or Pause Guardian
* setBoostCapForVault - DAO governance or Optimistic Approval
* setBoostCapForCollateral - DAO governance or Optimistic Approval

The TurboClerk [Authority](https://github.com/Rari-Capital/solmate/blob/main/src/auth/Auth.sol):
* setDefaultFeePercentage - DAO governance or Optimistic Approval
* setCustomFeePercentageForCollateral - DAO governance or Optimistic Approval
* setFeePercentageForSafe - DAO governance or Optimistic Approval

The TurboGibber [Authority](https://github.com/Rari-Capital/solmate/blob/main/src/auth/Auth.sol):
* impound/impoundAll - DAO governance or Optimistic Approval or Pause Guardian (all 3 behind 3 week timelock)

## Turbo Safe Administration
Administration is set by default to the authority stored in Master. Users can delegate Safe ownership to a contract via the authority.

The Turbo Safe [Authority](https://github.com/Rari-Capital/solmate/blob/main/src/auth/Auth.sol):
* boost
* less
* sweep
* ERC-4626 deposit/withdraw/redeem

## Turbo Pool Admin

The Turbo Pool is a normal Fuse pool which will use a FuseAdmin wrapper to control asset listings and parameters.