Lending Module: Prime
Prime: Rumi’s Lending Module
One of the key components of our Defi stack is Prime. Prime functions as Rumi's undercollateralised lending module and it is composed of Single Asset Vaults.
Rumi uses this module for two objectives: first, to be able to create leveraged strategies and thus increasing the overall returns. Prime offers undercollateralized leveraged positions, which enable investors who deposit into our strategies to maximize their returns by borrowing funds from the module. These investors typically have a higher risk tolerance and are focused on yield maximization. Second, Rumi uses leverage (debt) in some cases to create hedging machanisms. Specifically, we are able to create impermanent loss hedging for our Pseudo Delta Neutral and Directional Delta 1x strategies.
For Yield Strategy investors
For borrowers, Prime provides access to undercollateralized leverage, allowing them to increase their potential returns while minimizing their capital requirements, and also access our risk hedging mechanisms.. This is particularly beneficial for strategy investors who are looking to maximize their yield. Prime's undercollateralized leverage feature enables borrowers to enter into leveraged positions with only a fraction of the collateral required by traditional lending platforms.
Note: It is important to note that Rumi leveraged startegies are completely managed by the Rumi Keepers. This means that only the Rumi Team can select the level of leverage on its strategies. This is important to know as because of our automated leverage management system, there are no liquidations on our platform
For Prime Lenders
Prime is designed to provide a secure and stable single asset lending environment for lenders. With Prime, lenders can earn a steady return on their investment while minimizing their risk exposure.
Rumi has analyzed several undercollateralised lending protocol and designed its lending module taking into account the common shortcomings seen in the industry, especially related to liquidity utilization. Two main changes we implemented that distant our module from others:
Instant liquidity: in most lending modules, when utilization reaches maximum levels, lenders are not able to withdraw their funds. Protocols don't often warn this on their docs, and lenders find themselves surprised when this happens. Rumi offers instant liquidity to all lenders, no matter the utilization level
Smoother interest rate curve: resorting to extreme interest rates to make existent borrowers to close positions and deter new borrowers to borrow is a bad customer experience in our opinion. Our interest rate model is smoother, even at high utilization levels as we manage liquidity and utilization using our automated deleveraging mechanisms on our strategies
Finally, Lenders of Prime can access additional Rumi Token rewards as part of our liquidity mining programmes. Pre TGE, we are distributing non transferable Rumi tokens to Lenders who support us on our early days. Post TGE, the full liquidity mining programme will be launched on our Prime Lending vaults.
Overall, Prime is a unique lending module that aligns the incentives of both lenders and borrowers. With its focus on security, stability, and flexibility, Prime offers a profitable and secure lending market for all parties involved.
Lending Module Architecture
Our system is inspired by successful DeFi protocols like Aave, but we have enhanced it to provide undercollateralized loans. Our interest rate model follows a similar design to Aave's triple slope model, which is based on Utilization Rate. This means that the availability of capital will determine the rate that will be offered on our platform. Furthermore, we have introduced a few technology innovations on our utilization rate mechanics so we can offer instant liquidity to the single asset lenders at all times.
All of this is programmed into our smart contracts, ensuring that the process is transparent, secure, and automated. By utilizing smart contracts, we eliminate the need for intermediaries and enable users to interact with the platform in a trustless manner.
SYSTEM COMPONENTS
EOA Accounts: External accounts that provide liquidity to the Lending Vault. By providing liquidity they get in exchange an ibToken, this token accrues interest on the loan. Only external accounts are allowed to provide liquidity, for security reasons we are denying contract to contract interaction for now.
IbToken: Interest bearing tokens that represent a share of the lent asset and the accrual of interests.
Lending Vault: ERC1155 MultiToken Vault, this is the main component of the module, it receives lender's funds, mints ibTokens, provides borrowing capacity (credit limits), manages the interest rate model for each ibToken, provides position health management for potential liquidations and connects to the reserve contract.
Reserve Contract: The reserve contract is used as a buffer to provide instant liquidity to lenders in case there are withdrawals but also as a Treasury for Rumi Finance's governance. More on this below.
Leverage Controller: The leverage controller is an orchestrator between the reserve, the lending vault and the leveraged borrowers, this contract controls the amount of leverage that each strategy-borrower should have in order to provide instant liquidity and an optimal utilization rate.
INTEREST RATE MODEL
The interest rate model is taken from Aave's triple slope model
Interest rate of token t, R_t follows the following model
* - if U_t<=Uo_t: R_t = R0_t + R_s1*(U_t/Uo_t)
* - if U_t>Uo_t: R_t = R0_t + R_s1 + R_s2*(U_t - Uo_t)/(1 - Uo_t)
* - Where U_t is utilization of token t,
* - Uo_t is optimal utilization rate of token t,
* - R0_t is the base borrow rate of token t
* - R_s1 is slope1 for token t
* - R_s2 is slope2 for token t
Supply Rate
S_t = R_t
The same concept applies to Prime:
When utilization is low it attracts investors (Lower Interest rate)
When utilization is high it attracts lenders (Higher interest rate)
The supply rate is the interest paid to the Lenders for providing liquidity, this is equal to the Interest Rate paid by borrowers. One of our key differences with Aave's model is that we build up our reserve from the yield generated by the strategy investors who have a higher risk-reward profile.
Utilization Rate
Utilization rate for a token is calculated as follows
* - U_t = B_t/D_t
* - where B_t is the total amount borrowed for the token and
* - D_t is the total amount deposited for the token
The utilization rate is the ratio between the total amount borrowed of a token and the total amount of deposits for that token. The utilization rate influences the interest rate, the maximum utilization rate and the credit limits are controlled by Governance in order to maintain an optimal setpoint for interest rates.
Reserve
The reserve has three main purposes:
Act as a buffer to provide instant liquidity to lenders.
Create a governance treasury fund.
Provide insurance against potential security breaches and other events.
The reserve is funded from the borrowing side, on each repayment of debt a premium from the leveraged position is called for by the reserve.
Reserve Model
* - LP_Position = collateral_provided + borrowed_amount + yield_generated
* - if yield_generated > 0: R_fee = Rf*yield_generated
* - Where R_fee is the amount of fees charged by the reserve
* - Rf is the reserve factor
* - yield_generated is the amount of yield that the strategy has generated
Yield Generated Modeling
* - Yield_generated = Pnl_t1 - Pnl_t0
* - Pnl_t0 - Profit or loss at time 0 (initial repayment event)
* - Pnl_t1 - Profit or loss at time 1 (final repayment event)
The premium paid by the borrowers comes directly from the yield generated by their position, it is a haircut taken from their profits whenever there's a repayment event. Our strategy contracts track the PnL between every repayment event (Pnl_t0 and Pnl_t1), on every repayment event the lending vault will receive the assets borrowed plus interest plus the reserve fee (Rf*yield_generated), burn the shares held by the borrower and mint ibTokens for the Reserve corresponding to the amount of reserve fee (R_fee). This way the reserve will hold ibTokens and will be generating yield as well all while providing liquidity for the lending vault.
The reserve is funded by repayments of debt, during each repayment event part of the currency tokens are sent to the reserve contract per the reserve model above, the currency tokens will be accumulating in the reserve and will be available for instant liquidity, governance fees and insurance The reserve contract has a special accounting for the different uses of the reserve, specifically for providing instant liquidity the reserve has an accounting with the Lending contract that will have the Lending contract have a debt issued to it so that it will replenish the Reserve contract back after providing liquidity for withdrawal.This replenishment or repayment will come from future lenders.
Withdrawal Mechanism - Instant Liquidity
In order to provide instant liquidity we've set a few rules and interactions between our smart contracts as follows.
Scenario 1- Lending Vault holds enough liquidity for withdrawal
Lender requests a withdrawal
Lending vault burns ibToken
User gets instant liquidity
Scenario 2 - Lending Vault holds partial funds for withdrawal and has to request a loan-funds from the reserve
Lender requests a withdrawal
Lending vault burns ibToken
Lending vault requests missing funds from the reserve
The reserve keeps a debt-record to the Lending Vault
Funds are transferred to the lending vault
User gets instant liquidity
Scenario 3 - Lending Vault holds does not hold any funds for withdrawal and has to request a loan-funds from the reserve
Lender requests a withdrawal
Lending vault burns ibTokens
Lending vault requests all funds from the reserve
The reserve keeps a debt-record to the Lending Vault
Funds are transferred to the lending vault
User gets instant liquidity
Scenario 4 - Lending Vault holds does not hold any funds for withdrawal and has to request a loan-funds from the reserve which only has partial funds and has to ask for deleveraging
Lender request a withdrawal
Lending vault burns ibTokens
Lending vault requests all funds from the reserve
The reserve keeps a debt-record to the Lending Vault
Funds are transferred to the lending vault
Reserve asks the leverage controller to deleverage the strategy with the most funds
A fee is charged to the user withdrawing to accrue funds for gas that will also allow the strategy to be further re-optimized
The strategy sends funds to the Lending Module
User gets instant liquidity
The keeper at a later point in time comes in and re-optimizes and rebalances the strategy to bring back to the leverage setpoint whenever there's enough funds available.
Scenario 5 - Lending Vault holds does not hold any funds for withdrawal and has to request a loan-funds from the reserve which has no funds and has to ask for deleverage
Lender request a withdrawal
Lending vault burns ibTokens
Lending vault requests all funds from the reserve
Reserve asks the leverage controller to deleverage the strategy with the most funds
A fee is charged to the user withdrawing to accrue funds for gas that will also allow the strategy to be further re-optimized
The strategy sends funds to the Lending Module
User gets instant liquidity
The keeper at a later point in time comes in and re-optimizes and rebalances the strategy to bring back to the leverage setpoint whenever there's enough funds available.
As shown by the interaction above the priority will always be given to the lender fulfilling their need for instant liquidity and lowering their lock-up risk. The reserve also acts like a buffer that builds up funds for the leveraged positions to take.
The withdrawal penalty charged in the case that funds are called to the Leverage Controller will be for the maintenance of the keeper bot that aims to maintain an optimal leverage setpoint and utilization rate of the whole system. These funds will be managed by Governance so that they can replenish the gas used by the keepers.
Borrowing Mechanism
A borrowing occurs between the whitelisted strategy contracts and the lending vault, the borrower can only borrow up to a certain amount of credit (creditLimit), the credit limit is used by the protocol to control utilization rates. When the strategy requests funds to borrow the following conditions should be met:
The borrower is inside its allowed credit limit
The new borrowing amount will not raise the utilization rate above the maximum allowed limit
Health of the Positions
To provide under collateralized loans to borrowers but at the same time guarantee to lenders that their deposits are safe the health of positions has to be tracked. At any given time the protocol has to have the proper amount of collateral plus debt in order to cover withdrawals with zero or minimal loss.
Health can be calculated as:
* health = PRECISION*(totalETHValue-debtETHValue)/debtETHValue
* - If a borrower can pay back nothing, health will be -PRECISION
* - If a borrower can pay back exactly the debt and have nothing left, health will be 0
* - If a borrower is healthy the ratio will be positive
At the time of measuring a position everything is taken to ETH value as common denominator for the equation, this way assets in a liquidity position can be equivalent to the underlying debt.
A health factor is applied into the system so that positions have to be above the health factor to be considered healthy otherwise they will be prone to killing them (liquidation) or to deleveraging them (forced partial repayment).
Kill event
Whenever a position is unhealthy the Lending Vault Contract provides a function that is permissionless that can be called by anyone that will kill unhealthy positions, if the health is below the threshold it will allow to unwind the leveraged position and strive to repay the available debt and leave in the strategy the funds after repayment that correspond to the collateral plus yield generated by it. Collateral and yield will be used in order to repay debt thus protecting and prioritizing the lenders.
Last updated
