♾️2.2 Loans
A Loan is generated by a match between a borrower and a lender. The borrower owes some debt to the lender, who receives some credit or future cash flow to be claimed at the due date.
Debt must be repaid before the due date, otherwise, it is subject to liquidation, and credit can be sold to a third party or used to compensate for debt in a different loan.
This specification motivated us to break the Loan structure into two complementary primitives: DebtPositions and CreditPositions:
2.2.1 Accounting Primitives
2.2.1.1 DebtPosition
DebtPosition is an accounting entity that represents the debt taken by a borrower when a loan is created.
They are created as a result of:
a borrowing market order filling a lending limit order or
a lending limit order filling a borrowing market order
a partial repayment with a debt compensation mechanism
Its fields are
borrower
: BorrowerfutureValue
, the amount expected at the due datedueDate
: the due date (maturity)liquidityIndexAtRepayment
: the liquidity index of the Variable Pool during repayment
2.2.2.2 CreditPosition
CreditPositions are credit trackers. They are created either during the creation of a loan, at the same time a DebtPosition is created, or when a lender "sells" some of his credit in exchange for
cash (we call this informally "lender exiting to other lenders")
debt reduction (we call this "debt compensation")
Its fields are:
lender
: LenderforSale
: whether this credit position is for sale, by default set to truecredit
: the amount of credit or future cashflow the lender still havedebtPositionId
: a link to the DebtPosition
When a CreditPosition is sold, in part, a new CreditPosition is created. The exited amount is credited to the buyer and deducted from the seller so that the sum of credit remains constant. This means, in practice, that one loan can have a single debtor and multiple creditors.
2.2.2.2.1 Credit Transfer Eligibility Criteria
The criteria established for credit transfer are:
the credit has to be healthy i.e. the corresponding debt position must not be underwater
it means that a credit position whose corresponding debt position is underwater can't be sold and not used for compensations (cashless swap)
the reason is that at the moment we have no mechanism to allow pricing in the risk related to the CR since our yield curves allow pricing only for the time value of money i.e. the tenor
so the underlying assumption is all traded credit is non-fungible from the risk perspective, which practically means CR > CRL for us
also, the credit has not to be claimable
if a loan is repaid early either by standard repayment or liquidation, the related credit position can be claimed immediately, even before the loan due date, since the money is already in the protocol
however, considering a credit maturing at
T
if it is liquidated att < T
and therefore it is claimable att
then if the credit is also available for sale somebody can buy it at a discount depending onT-t
and claim it immediately, resulting in an arbitragefor this reason, claimable credit is non-transferable.
Side note for overdue credit
The easiest solution is to add an additional criteria to the list above, preventing the overdue credit transfer
A lender owning an overdue credit might be OK selling it at a discount because he needs the money then, while another lender might be OK buying that credit at a discount, and profiting from this discount because he is not in a rush and can wait for the liquidation to come. However, since there is no way to price that risk of overdue credit on the yield curve, we have decided to make overdue credit non-transferrable.
2.2.2 Loan Status
The lifecycle of a loan begins when it is created and is considered ACTIVE
, and ends when it is repaid (zero outstanding debt), either willingly by the borrower or forcibly through a liquidation, set to REPAID
. An ACTIVE
loan can become overdue if the current timestamp is greater than its due date. Overdue loans can also be REPAID
in the same way as active loans.
2.2.3 Position IDs
Because of this split of the Loan structure into two primitives, each is tracked separately on the Size storage contract in a mapping of DebtPosition and CreditPosition structs.
In order to access both structs with a unique identifier, the unsigned integer range was broken in half, so that debt position IDs start at 0
, and credit position IDs start at type(uint256).max / 2
.
This way, it is possible, for example, to fetch the loan status from both a credit position ID and a debt position ID, since the contract can determine at runtime which accounting primitive that identifier belongs to, and determine the remaining debt or maturity.
Last updated