# V2 Open Questions

## Debt token price

For both models we use the following formula for the debt token price:

The only difference is how we calculate CURRENT_POOL_VALUE, more specifically when the interest from open loans is taken into account.

For a pessimistic price, we add interest only from the repaid loans. For "optimistic", we add accrued interest to the CURRENT_POOL_VALUE every second.

### Pessimistic price PROS 

* Already implemented and known to stakeholders
* Matches with the real token value in case of defaults

### Pessimistic price CONS 

* Can be easily manipulated. An attacker can sniff price-changing transactions and enjoy from the same APY as someone who is deposited in the pool for a long time effectively stealing the liquidity.
    * Example: 

- User1 deposit 1000 USDC, get 1000 rUSDC1
- User2 borrows 1000 USDC
- rUSDC1 price is 1 USDC
- 1-month pass
- User2 repays 1010 USDC
- Attacker sniffed this transaction
- Attacker deposit 1000 USDC before this transaction for 1000 rUSDC1
- rUSDC1 price is 1.01 USDC
- Attacker withdraws 1000 rUSDC1
- Attacker gets 1005 USDC
- Pool has 1005 USDC
- User1 has 50% interest to withdraw

### Optimistic price PROS 

* Resilient against price manipulation and front-runs
* In line with standard Defi debt token implementation 

### Optimistic price CONS 

* Will diverge from the real pool liquidity in case of low repayments
* Requires better protection from bunk run in case of low repayments

## Bank run prevention 

In case of large defaults, lenders can observe protocol poor performance and start to withdraw. 

In this case pool liquidity won't be enough to make lenders whole. 

For this case, we might need a mechanism to prevent the immediate withdrawal of all lenders in the given pool. 

Possible ideas:

- Various queue implementations
- Reserve rate curve, which will always keep some liquidity in the pool
- Temporary lock-ups 

## Liquidation

Suggested collateral management and liquidation mechanics for V2:

When the loan is created, contract locks required collateral in the "freezer" structure. E.g. for the loan of 1500 USDC contracts locks 1ETH in "the freezer". 

Users cannot claim from the "frozen" collateral or add to it.

Even when the loan is repaid partially, the user still cannot claim frozen collateral 

We liquidate only "frozen" collateral, not global collateral.

When the loan is repaid in full, frozen collateral for this loan is unfrozen and available again for the user. 

Now there are 2 different liquidation tactics we can choose for V2, "greedy" and "gambler".

### Plain

On liquidation, we seize only part of the collateral which matches the loan's LTV. If frozen collateral does not cover that, we seize part from its "global" collateral. If frozen collateral costs more than LTV, we send it back to "global" storage.

PROS
- Easier to explain to customers
- More predictable results in a stable market

CONS
- Complex math and code logic, code less secure, more tests needed

### Gambler

On liquidation, 100% of frozen collateral is always seized by the liquidator.

PROS
- Straightforward logic allows for more secure code and better development speed
- Good on the bull market, as liquidators grab more collateral in USD than LTV 

CONS
- Users can be very unhappy re losing collateral amount which is larger than the agreed LTV
- Bad on a bear market, as the liquidator gets less collateral in USD than LTV

## APR and maturity date per loan

For V2 we want to allow maximum flexibility for setting loan params, specifically LTV, APR and maturity date. However, to implement that properly, we need to list several possible scenarios. 

Example: 
- User can choose from combinations [APR, maturity date], e.g. 7 days + 10% APR or 14 days 9% APR. 
- APR for all loans in the given pool is defined as a function of pool utilization or some external market variables 
- Different LTV for the different collateral types (Maker DAO style) 

## Specific interest accrual implementation

- Compounding? 
- TBD

## Limits

- Per pool
- Per NFCS