Codebase: Turbo
Start Date: Thursday, Feb 17, 2022
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.
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:
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.
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
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 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.
The Turbo Booster checks data regarding a given boost operation against different governance caps to make sure the boost is eligible, otherwise it reverts.
The clerk determines revenue split for yield earned by Safes. There is a global default with possible overrides per asset/Safe.
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.
Users can perform 6 actions in the system:
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 new collateral straight into the Turbo Fuse Pool. This enables new boost calls subject to collateral whitelisting, LTV thresholds and other caps.
Withdraw collateral from the Turbo Fuse Pool. Subject to collateralization requirements.
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.
The inverse of a boost operation. There is no check, this can be done permissionlessly and cannot be paused.
Claim any ERC-20 in the Safe other than boosted vaults and fToken collateral. Used to claim FEI fees accrued in the Safe.
Turbo has many layers of administration and configurability on 3 levels:
The Turbo Master has an Authority which gates the following actions as follows:
The TurboBooster Authority:
The TurboClerk Authority:
The TurboGibber Authority:
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:
The Turbo Pool is a normal Fuse pool which will use a FuseAdmin wrapper to control asset listings and parameters.