♾️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 : Borrower

• futureValue, the amount expected at the due date

• dueDate : 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: Lender

• forSale: whether this credit position is for sale, by default set to true

• credit: the amount of credit or future cashflow the lender still have

• debtPositionId: 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.

This $1:N$ $borrower:lenders$ dynamic implies that when the loan is repaid, each lender must be able to claim their owed credit amount after the due date. In order to make the repayment a $O(1)$ operation, the borrower transfers the loan's futureValue to the Size contract, which deposits it on the Variable Pool, and waits for each lender to claim it after the due date, with variable-rate interest. This flow is explained in more detail in the Repayment section of the documentation.

2.2.2.2.1 Credit Transfer Eligibility Criteria

The criteria established for credit transfer are:

1. 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

2. 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 at t < T and therefore it is claimable at t then if the credit is also available for sale somebody can buy it at a discount depending on T-t and claim it immediately, resulting in an arbitrage

• for this reason, claimable credit is non-transferable.

3. 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 ACTIVEloan 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.