Lite paper

Loanster is a permissionless peer to peer lending/borrowing platform built on Ethereum.

It is a loan marketplace where lenders lend ERC20 tokens to borrowers at a fixed rate and for a fixed duration.

Lenders

Lenders can publish a loan offer on allowed supply tokens by following these steps:

1. Keep tokens in wallet or deposit in Aave/Compound (to earn a variable rate waiting for a loan to be opened)

2. Approve loanster supply contract to spend their tokens

3. Sign a message that includes the lending terms:

   • Interest rate: yearly interest on supplied liquidity. It is paid at loan repayment.

   • Expiration date: the date after which no new loans can be initiated.

   • Min duration: the minimum length of a loan. Loans can be repaid before that time but the full interest on the min duration period must be paid.

   • Max duration: maximum lenth of a loan.

   • Min loan amount: the minimum amount of tokens to be borrowed in order to open a loan.

The signed message is sent to a backend that aggregates lending terms and signatures. Lending terms can be cancelled with a small on-chain transaction (that changes a nonce).

No tokens are moved unless the offer is accepted by a borrower. The gas fees are at the cost of the borrower.

Once a loan is repaid, the tokens and interest are held by the loanster supply contract and must be claimed by the lender.

The advantage of this approach compared to Aave/Compound is that up to 100% of the provided liquidity can be utilized at once. The only spread between lending and borrowing rates is the loanster commission (around 10%). In addition, lenders may be willing to pay higher interest rates for the peace of mind of a fixed rate or if they anticipate rate increases in the future.

Borrowers

Borrowers can deposit tokens as collateral and open loans as long as their health factor see (definition below) stays above 1. It is possible to deposit multiple collateral tokens and to borrow multiple multiple tokens from the same account.

Loans

Borrowers can open loans tokens against their deposited collateral. A loan is defined by the following parameters:

• Token borrowed

• Amount borrowed

• Interest rate (fixed)

• Loan term: date by which the loan must be repaid

• Min duration: loans can be repaid at any time, but if it is repaid before the min loan duration, the full interest on the min loan duration period must be paid.

Borrowers browse the loan offers through the front end and can open loans by sending an on-chain transaction with the lending terms and signature. The on-chain contracts verify the collateral requirements, that the loan and lending terms are valid, that they match the signatures and if so opens the loans by sending the supplier's tokens to the borrower.

The loan must be repaid before the loan term or the collateral can be liquidated.

Health Factor

The health factor is standard practice in lending protocols. It allows easily measure the liquidation risk associated with an account. The more collateralized, the higher the health factor. An Account with a health factor below 1 becomes eligible for liquidation.

Let us define, for a given account, for each token $t$, the ether value of the amount deposited as collateral $c_t$, the ether value of the amount borrowed $l_t$, its collateral factor $a_t$ and its borrow factor $b_t$. The adjusted value of the total collateral deposits $C_{adj}$ is defined as:

$$C_{adj} = \sum_{t} c_t a_t$$

The total value of the total liabilities (tokens borrowed) is defined as:

$$L_{adj} = \sum_{t} l_t b_t$$

The health factor is the ratio of adjusted total debt to liabilities:

$$HealthFactor = \frac{C_{adj}}{L_{adj}}$$

Borrowing capacity

Let us imagine a user wants to borrow a token $t$ in order to obtain a specific health factor $H$. His current total adjusted collateral is $C_{adj}$ and his current total liabilities is $L_{adj}$. We can compute how much he should borrow with the following equation:

$$H = \frac{C_{adj}}{L_{adj} + xb_t}$$

where $x$ is the ether value of the liability from borrowing token $t$ with borrow factor $b_t$. Solving for $x$, we get

$$x = \frac{C_{adj} - HL_{adj}}{H b_t}$$

To garantee that the borrower will repay the interest rate , we include the minimum interest owed in the liability. The value of the liability from borrowing tokens $t$ at a price $p_t$ (in eth) at interest rate $i$ for a minimum duration $s$ is given by:

$$x = amount\_to\_borrow *(1 + s* i) * p_t$$

Combining the above two equations, the amount to borrow is

$$amount\_to\_borrow = \frac{C_{adj} - HL_{adj}}{H b_t p_t (1 + i s)}$$

The borrowing capacity can be deduced from this formula by computing how much to borrow in order to get a health factor H of 1:

$$borrow\_capacity = \frac{C_{adj} - L_{adj}}{ b_t p_t (1 + i s)}$$

Decentralized price oracles

Collateral and loan prices are obtained using uniswap TWAP oracles, which compute the geometric mean price of assets over some interval of time. The longer the time interval, the smoother and harder it is to manipulate the price but the less up to date the price becomes.

Each assed is mapped to a specific WETH pool in uniswap. The pool tier is decided by governance for each asset.

Note: WETH therefore has a collateral factor of 1

Liquidations

The liquidation mechanics are designed in a way to be the least punitive possible towards collateral violators. This is done through a dutch auction mechanism where the liquidator's profit is 0 at the liquidation threshold and becomes larger as the account becomes increasingly undercollateralized.

If the health factor becomes < 1, the account becomes eligible for liquidation. This allows any liquidator to repay the undercollateralized account's debt in exchange for collateral at a discount rate. The discount rate $r$ is defined as:

$$r = Min(1 - HealthFactor,\ MaxDiscountRate)$$

The amount of collateral eligible for liquidation is limited by the $TargetHealthFactor$ (for instance 1.25), which is the maximum health factor of an account after liquidation.

The maximum value of the liquidated collateral can be computed by solving the following equation:

$$TargetHealthFactor = \frac{C_{adj} - x a_{t_c}}{L_{adj} - yb_{t_l}}$$

Where $y$ is the ether value of the repaid liability token $t_l$ and x is the ether value of the liquidated collateral token $t_c$. The liquidated and repaid token values are linked by the discount rate with the following formula: $y = \frac{x}{(1 + r)}$. Replacing y in the formula above and solving for x, we obtain the maximum value of the liquidated collateral:

$$x = \frac{C_{adj} - L_{adj}*TargetHealthFactor}{a_{t_c} - \frac{b_{t_l}}{1 + r}*TargetHealthFactor}$$

Secondary market

Each supply deposit and each trove is represented by an NFT which is transferrable. If a supplier wants liquidity that is currently locked in a loan, he can sell the promise of payback on a secondary market. If a borrower has locked in an advantageous borrowing rate but needs to unlock his collateral, he can sell his loan and swap his collateral for someone else's.

Protocol fees

Possible fees are

• Commission on interest payments (i.e. 10%). This would go to the protocol's governance.

• A matching fee could be given to the front-end that matches a buyer and a seller.

• Liquidation fees could be implemented for to the protocol's governance.

Upgradability

The smart contracts will be be non-upgradable to limit risks for users as well as legal implications of being able to modify the contracts to take ownership of assets.

New features can be developped by releasing a new set of smart contracts and a v2 interface.

Governance / DAO

Governance rights

The governance of the protocol has the following powers:

• Add/remove supply tokens.

• Add/remove collateral tokens.

• Set the TWAP pool for tokens.

• Set Collateral factors and Supply factors for tokens.

• Set limits on maximum amount of collateral deposited per token type.

• Set protocol fees. Protocol fees are set when a loan is opened and can not be changed for an ongoing loan.

While a first version of the protocol can have a multisig-controlled governance and no token, a decentralized governance system with token can be implemented later on and ownership transferred. Since none of these parameters need to be changed frequently, the DAO token holders can do on-chain voting to control them. A curve-like ve-model should be used to align long-term interest of governance holders to voting power.

Governance attack risks

If a malicious actor were to be in control of governance (for instance if the governance is a DAO and a single entity controls > 51% of tokens), he could put the protocol in danger in the ways listed below. These attacks can however be mitigated to protect currently open loans if that were to happen.

Governance right	associated risk	risk level	mitigation
Add/remove collateral tokens.	Add an illiquid collateral token and take loans (attacker must also have access to signatures)	affects open offers but not open loans.	Collateral tokens are only elegible for lending offers that were made after the time they were added.
Set the TWAP pool for tokens.	Set twap to a more illiquid pool which easier to manipulate.	medium	force a delay to modify parameter or fix oracle for each loan.
Set Collateral factors and Supply factors for tokens.	Lower factors to enable liquidations, reimburse loan and steal collateral	high	force a delay to modify parameter or fix factors for each loan.
Set limits on maximum amount of collateral deposited per token type.	If a large amount of a token's liquidity is locked as collateral in the protocol, it could cause cascading liquidations if the price of the token were to suddenly drop.	low	force a delay to modify parameter
Set protocol fees.	set fees very high	high	interest rate fee is hardcoded for each loan and cannot be modified on an open loan.

Open questions

Should a lender be able to specify the types of collateral he accepts? This could be implemented using collateral tiers.

Can the front-end and back-end be decentralized? The smart contracts could be coded in a way that the person who matches a borrower to a lender takes a fee. However the front-ends would not share the supply offers. A different design would be to post the lending terms on-chain, which would make it possible for front-ends to share the supply offers and more safely revoke them. However, it would cost gas to lenders to publish or modify offers.

When a loan is repaid it requires the lender to make a transaction to claim the tokens. There could be a way to lend out tokens again gasslessly and/or deposit the repaid token in variable rate lending protocols.