Comment on page
Credit Vault contract overview
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.
StructuredPortfoliois 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.
StructuredPortfoliohas 3 states:
The credit vault goes into
Livestate 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 algorithm.
Creating and funding loans is only possible in
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.
StructuredPortfolioFactoryis a factory contract that creates
StructuredPortfoliocontracts along with its
TrancheVaultcontracts and controllers.
TrancheVaultis the contract that allows users to deposit/withdraw funds and to manage the vault.
TrancheVaultcreates checkpoints on every action that changes total tranche value. This allows the vault to calculate linear growth since the last change in waterfall calculations.
TrancheVaulthandles paying fees to the manager and to the protocol. Fees are calculated continuously but are transferred on every checkpoint update.
TrancheVaultsupports ERC20, ERC165 and ERC4626 interfaces.
ProtocolConfigcontract holds parameters necessary for fee accruals.
These parameters are:
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.
DepositControllerchecks whether a lender is allowed to deposit and checks maximum deposit amounts for each lender. Managers can choose to enable or disable deposits.
WithdrawControllermanages 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
DepositControllerbut for withdrawals.
TransferControllerhas a single method
onTransferthat is called when a tranche's ERC20 transfer is made.
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).
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:
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.
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.
It is important to note that in
Closedstates, the vault consists only of idle funds. In
Closedstates, 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.