Lender First Pool
In this model one lender creates a pool with lend funds and the lender dictated terms and then one or more people can borrow from it.
In this model one lender creates a pool with lend funds and the lender dictated terms and then one or more people can borrow from it.
Parameter | Details |
---|---|
For pairs with on-chain oracles we can pause borrowing if the price of collateral is less than the amount of lend tokens being given out. We can further customize this with maximum LTV parameter to trigger the pause earlier or in contrary allow an under-collateralized loans.
If we set the maxLTV to 100% which we can encode as 100000 as a contract parameter then the borrowing will pause exactly as soon as we lend the value equal to the value of collateral, for example:
If wETH price is $1200 and USDC price is $1. When lending in the pool with 1000 lend ratio we would be giving 1000USDC for 1 wETH. If the maxLTV is 100% then borrowing will pause when the wETH price is 1000 or less. It will be enabled automatically again if the LTV decreases again. It would also pause if USDC would cost 1.2$.
If we were to set the maxLTV to 95% we would disable borrowing even earlier and if we were to set the LTV to 105% then we would pause later.
By setting the maxLTV to type(uint48).max
you can skip the oracle price check completely.
NOTE: For any asset without an oracle, maxLTV must be set to type(uint48).max or otherwise all borrow transactions will revert due to an oracle check.
Many lenders do not want to have borrowing be enabled after some point, but they do not want to go and manually pause the pool. For that reason they can set the pauseTime
parameter to a epoch timestamp in seconds after which the borrowing will pause. Lenders can also pause the borrowing immediately by setting this variable to current timestamp. To unpause, lenders just need to set the variable to a later timestamp or even expiry date of the pool.
This is a list of addresses that can initiate the loan. Essentially the lending pool will check the msg.sender
against the whitelisted addresses. It is important to note that the borrower
address in the borrowOnBehalfOf(...)
is not checked in this case. You also can not turn a public pool into a private pool after deployment.
All the fees in this pool are paid up-front. The best way to understand this is with an example:
Imagine Pool: wETH<>USDC with Lend Ratio of 1000 and fixed 10% term fee. Let's assume Vendor also charges 1% of borrowed funds (number picked for simplicity, Vendor charges much much less).
If Alice would like to borrow from this pool and she has 1 wETH then in her borrow transaction the following steps will take place:
Pool will give her a 1000USDC as per lend ratio. That is her debt.
Pool will then use those funds to pay the lender fee up front or 100USDC.
Pool will then use those funds to pay the Vendor fee up front or 10USDC.
Alice will receive 890 USDC and she has a debt of 1000 USDC to unlock collateral.
Lenders can create rollover pools that borrowers can transfer their debt into. A rollover pool must satisfy a few conditions:
It must have same lend token.
It must have the same collateral token.
It must have longer expiry.
It must have the same owner.
It must be whitelisted by the owner of the origin pool (pool borrower is rolling out of).
When doing a rollover borrower will trigger the function called rollInFrom(address)
on the new pool that they want to roll into and will pass an address of the pool in which borrower has current debt. This is done this way because this makes it easier to charge the fees for the new pool and keep them in the new pool right away. Otherwise additional transfers of fees from old pool to the new one are required and are not gas efficient.
When rolling over into a pool with a different lend ration than the original pool additional math needs to be done. Let's go over the simplest case where borrower is rolling over into a pool with the same lend ratio. For all examples consider an origin pool to be the wETH <> USDC pool with 1000 lend ratio and 10% fixed term rate. The borrower would have a debt of 1000USDC and 1 wETH deposited as collateral.
Same Lend Ratio
Consider the borrower is rolling over into a destination pool with the following parameters: wETH <> USDC pools with 1000 lend ratio and 10% fixed term rate. Same as origin pool but longer expiry. In this case borrower would simply need to pay all the fees in the new pool in his rollover transaction. That is 100USDC to lender plus any Vendor fee. After that borrower would still have 1000USDC debt and 1 wETH collateral but in a destination pool now.
Larger Lend Ratio
Now consider the same example as above but new lend ratio is 2000. In this case borrower would only need 0.5wETH to back the same debt of 1000USDC. So lender would need to pay all the fees like in case with same lend ration and will also get half of wETH back to him. Here is the formula we can use for computing the reimbursed collateral when the new lend ratio is larger that the old one:
Smaller Lend Ratio
In this case we need more collateral to maintain the same debt. Since we can not expect borrower to have more collateral token on hand it is easier to ask them to return a fraction of borrowed funds using formula:
This formula basically computes how much over the new mint ratio you were lent given you collateral deposit. Borrower would also need to pay the lender and Vendor fees of the new pool. All of the obtained lend token in all three cases are sent directly to a new pool. With exception of Vendor fees, those are sent directly to treasury.
expiry
Expiry of the pool. Epoch timestamp in seconds.
colToken
Collateral token address
lendToken
Lend token address
maxLTV
A maximum LTV ration after which the borrowing will be paused. Set in % where 1% is 10000. See more here: Max LTV
puaseTime
A timestamp at which the borrowing will be paused automatically. Epoch timestamp in seconds.
mintRatio
Amount of lend tokens lent per unit of collateral. Always in 18 decimals.
borrowers[]
Array of addresses that can initiate a borrow transaction
feeRatesAndType
Configuration for the fee behavior. See more here: Fees Manager