# Credit Vault contract overview

[***Credit Vaults***](https://docs.brila.finance/brila-protocol/credit-vaults) are multi-tranche vaults allowing lenders to deposit into one or more specific buckets of funds ("tranches") managed by the portfolio manager. Credit Vaults can have up to 3 tranches, enabling each tranche to deliver unique risk-return profiles.

Below is an overview of Credit Vault contracts.

## Contracts

### StructuredPortfolio&#x20;

`StructuredPortfolio` is a contract responsible for loan management and Tranche value calculations. It might hold any number of tranches (limited by gas) but at launch, credit vaults are intended to contain 1, 2, or 3 tranches.&#x20;

`StructuredPortfolio` extends [`LoansManager`](#loansmanager) contract.&#x20;

`StructuredPortfolio` has 3 states: `CapitalFormation`, `Live` and `Closed`.&#x20;

The credit vault goes into `Live` state when the `start()` method is called. It transfers all funds from tranches to the credit vault and enables the ability to create and fund loans. Each tranche value is now calculated using the [debt waterfall](#waterfall) algorithm.

Creating and funding loans is only possible in `Live` state.&#x20;

When the vault's end date passes, anyone can close the vault. Manager can close a vault prematurely if there are no ongoing loans. This will transfer funds back to tranches according to the waterfall algorithm.&#x20;

### StructuredPortfolioFactory&#x20;

`StructuredPortfolioFactory` is a factory contract that creates `StructuredPortfolio` contracts along with its `TrancheVault` contracts and controllers.

### TrancheVault&#x20;

`TrancheVault` is the contract that allows users to deposit/withdraw funds and to manage the vault. `TrancheVault` creates checkpoints on every action that changes total tranche value. This allows the vault to calculate linear growth since the last change in waterfall calculations.&#x20;

`TrancheVault` handles paying fees to the manager and to the protocol. Fees are calculated continuously but are transferred on every checkpoint update.&#x20;

`TrancheVault` also manages `DepositController`, `WithdrawController` and `TransferController`. `TrancheVault` supports ERC20, ERC165 and ERC4626 interfaces.&#x20;

### ProtocolConfig&#x20;

The `ProtocolConfig` contract holds parameters necessary for fee accruals.&#x20;

These parameters are:&#x20;

* `defaultProtocolFeeRate`: the protocol fee (in basis points) that will be charged on each vault
* `protocolAdmin`: the address of the protocol owner
* `protocolTreasury`: the address where all fees are transferred
* `pauserAddress`: address of developer multisig for emergency pausing the protocol
* `customFeeRates`: custom fee model that can be defined by the manager

All of these parameters are settable by the protocol admin.&#x20;

### LoansManager&#x20;

`LoansManager` is an abstract contract that is an adapter to [`FixedInterestOnlyLoans`](https://docs.brila.finance/brila-protocol/other-concepts/instruments/fixedinterestonlyloan) that allows to add/fund/cancel/repay them.&#x20;

## Controllers

[controllers](https://docs.brila.finance/brila-protocol/other-concepts/controllers "mention") regulate different aspects of how TrueFi products work.

### DepositController&#x20;

`DepositController` checks whether a lender is allowed to deposit and checks maximum deposit amounts for each lender. Managers can choose to enable or disable deposits.&#x20;

### WithdrawController&#x20;

`WithdrawController` manages whether a lender can withdraw and checks maximum withdrawal amounts for each lender. Managers can choose to enable or disable withdrawals prior to the vault's maturity date. This controller is similar to `DepositController` but for withdrawals.

### TransferController&#x20;

`TransferController` has a single method `onTransfer` that is called when a tranche's ERC20 transfer is made.&#x20;

The basic implementation of this controller always returns true (all transfers enabled). This could be swapped for a different controller to add custom functionality (e.g. only transfers between specific addresses allowed, no transfers allowed, etc).

## Debt Waterfall

In credit vaults, the senior tranches are entitled to receive principal plus accrued interest (fixed rate *target interest*) in higher priority over the more junior tranches.

Thus in a three-tranche credit vault, the waterfall of repayments works as follows:&#x20;

First, Tranche A receives principal plus target interest, then Tranche B receives principal plus target interest, and then Tranche C receives the remainder of the funds in the vault.&#x20;

In summary, juniormost tranches absorb performance-based volatility within the vault, while more senior tranches feel losses only if losses exceed the size of subordinated junior tranches.&#x20;

It is important to note that in `CapitalFormation` and `Closed` states, the vault consists only of idle funds. In `CapitalFormation` and `Closed` states, there are no assumptions about the future performance of deployed capital and thus the vault is only calculating how to split idle funds between different lenders.