Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: market params design_doc #1152

Merged
merged 8 commits into from
Jul 27, 2022
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
63 changes: 0 additions & 63 deletions docs/architecture/ADR-003-borrow-assets.md
Original file line number Diff line number Diff line change
Expand Up @@ -47,69 +47,6 @@ The calculated borrow limit, which weighs collateral uTokens against borrowed as

Note also that as a consequence of uToken interest, the asset value of uToken collateral increases over time, meaning a user who repays positions in full and redeems collateral uTokens will receive back more base assets than they deposited originally, reducing the effective interest.

### Collateral utilization
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why moving this definitions?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was not part of the original decision - since ADR-003 will be renamed to a design doc (and already functioned as one), this is an attempt to apply the rule "don't modify old design docs, but make a new one instead."

Since multiple parameters are being added in the same timeframe, it made sense to group the proposals.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know, but they are related to the borrowing as well.
Hence, if we are moving this then let's already organize it in a documentation, rather than scatter it around decision docs.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What specifically should I do to this PR before merging? As it stands, it is a completed design doc representing parameters which were added together on a single theme.

Moving the collateral utilization definition back to 003 violates "don't modify old design docs" rule. Removing this document altogether and putting it in the spec goes against our decision to use design doc PRs.

As I see it, this should either be merged unchanged, or moved to the design docs folder first then merged. Spec updates are a separate issue and do not happen during the initial design PR.


Definitions:

- `total_supply(tokenA)`: total amount of tokenA provided to the leverage protocol (including coins marked as a collateral).
- `available_supply(tokenA) = total_supply(tokenA) - reserve - total_borrow(tokenA)`: amount of tokenA available in the system for borrowing.
- `supply_utilization(tokenA) = total_borrow(tokenA) / (total_supply(tokenA) - reserve)`. It equals 0 if there is no borrow for tokenA. It equals 1 if all ledable tokenA are borrowed.
- `total_collateral(tokenA)`: total amount of tokenA used as a collateral.

We define a _token collateral utilization_:

```go
collateral_utilization(tokenA) = total_collateral(tokenA) / available_supply(tokenA)
```

Note: system must not allow to have available_supply to equal zero.

Intuition: we want collateral utilization to grow when there is less liquid tokenA available in the system to cover the liquidation.
Collateral utilization of tokenA is growing when suppliers withdraw their tokenA collateral or when borrowers take a new loan of tokenA.
If a `tokenA` is not used a collateral then it's _collateral utilization_ is zero.
It is bigger than 1 when available supply is lower than the amount of `tokenA` used as a collateral.
When it is `N`, it means that only `1/N` of the collateral is available for redemption (u/tokenA -> tokenA).

#### Examples

Let's say we have 1000A (token A) supplied to the system (for lending or collateral). Below let's consider a state with total amount of A borrowed (B) and total amount of B used as a collateral (C) and computed collateral utilization (CU):

1. B=0, C=0 → CU=0
1. B=0, C=500 → CU=0.5
1. B=0, C=1000 → CU=1
1. B=500, C=0 → CU=0
1. B=500, C=500 → CU=1
1. B=500, C=1000 → CU=2
1. B=999, C=0 → CU=0
1. B=999, C=500 → CU=500
1. B=999, C=100 → CU=1000

#### Motivation

High collateral utilization is dangerous for the system:

- When collateral utilization is above 1, liquidators may not be able to withdraw their the liquidated collateral.
- Liquidators, when liquidating a borrower, they get into position their _uToken_.
In case of bad market conditions and magnified liquidations, liquidators will like to redeem the _uToken_ for the principle (the underlying token).
However, when there are many `uToken` redeem operation, the collateral utilization is approaching to 1 and liquidators won't be able to get the principle and sell it to monetize their profits.
This will dramatically increase the risk of getting a profit by liquidators and could cause the system being insolvent.

Let's draw the following scenario to picture the liquidators risk:

1. Alice is providing \$1.2M USD supply.
2. Bob is providing \$1.5M in Luna as a collateral and borrows 1M USD from Alice.
3. Charlie provides \$2M in BTC as a collateral and borrows $1.4M in Luna from Bob.
4. Charlie predicts Luna collapse and sells the Luna.
5. Luna is sinking and Bob position has to be liquidated. However:
- Suppliers can liquidate Bob, but they can only redeem up to 6.6% of `u/Luna` because the rest is not available (Charlie borrowed it).
- Charlie will not pay off her borrow position - she will wait for the final collapse and buy Luna cheaply.
- Liquidators will not take the risk of obtaining and holding `u/Luna` when there is a risk of Luna sinking deep.
6. In case of the big crash, liquidators won't perform a liquidation, Bob will run away with 1M USD, system will end up with a bad debt and obligation to pay Alice.

We propose to set a per token parameter: **max collateral utilization** stored in the `Token` registry (see ADR-004). The system will forbid to make any collateral related operation if the operation would move token _collateral utilization_ above _max collateral utilization_.

Stable assets will have high max collateral utilization (can go even to 50). Volatile assets should have significant smaller collateral utilization, and assets with high risk should have max collateral utilization close to 1.

## Detailed Design

For the purposes of borrowing and repaying assets, as well as marking uTokens as collateral, the `umee/x/leverage` module does not mint or burn tokens.
Expand Down
163 changes: 163 additions & 0 deletions docs/architecture/ADR-010-market-params.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,163 @@
# ADR 010: Market Parameters
toteki marked this conversation as resolved.
Show resolved Hide resolved

## Changelog

- Jul 4, 2022: Max collateral utilization added to ADR-003 (@robert-zaremba)
- Jul 18, 2022: Initial draft moved discussion to ADR-101 (@toteki)

## Status

Proposed

## Context

Umee manages the health of individual borrowers using borrow limits, collateral weights, and liquidation thresholds, but it currently lacks parameters that manages the health of token markets as a whole.

Several new parameters and alternatives are being proposed.

## Decision

Parameters we decide to use will be listed below in subsections:
- Max Collateral Share
- Max Supply Utilization
- Min Collateral Liquidity

Rejected or alternative implementations will appear in the alternatives section:
- Max Collateral Utilization

### Useful Definitions

The following terms may appear in multiple discussions below:

- `total_supply(token)` total amount of a base token which has been supplied to the system, including that which has been borrowed out, plus outstanding interest, minus reserves.
- `total_supply(utoken)` total amount of uTokens of a given type in existence. When exchanged for base tokens, this amount is worth exactly the total supply.
- `total_collateral(utoken)` total amount of a uToken marked as collateral.
- `total_collateral(token)` total amount of a uToken marked as collateral, multiplied by its uToken exchange rate to get the amount of base token collateral it represents.
- `total_borrowed(token)` the sum of all existing debt in a base token, including interest.
- `reserved(token)` the amount of tokens in the module balance which are reserved for paying off bad debt. These tokens are excluded from total supply.
- `available(token)` the amount of supplied tokens which have not been borrowed out or reserved.

These equations follow:

```go
available(token) = module_balance(token) - reserved(token)
total_supply(token) = total_borrowed(token) + available(token)
uToken_exchange_rate(token) = total_supply(token) / total_supply(utoken)
```

### Maximum Supply Utilization

One proposed parameter is `MaxSupplyUtilization`, to be defined per token.

```go
supply_utilization(token) = total_borrowed(token) / total_supply(token) // ranges 0 - 1
```

For example, if `1000 ATOM` are supplied and `200 ATOM` are borrowed, `supply_utilization` is `0.2`.

Implementing `MaxSupplyUtilization` would restrict `MsgBorrow` from increasing `total_borrowed` above a desired level.

It may or may not restrict `MsgWithdraw` from decreasing `total_supply(token)` below a desired level - adding this restriction might trap suppliers in a liquidity crisis in exchange for keeping more supply available for `MsgLiquidate`.

| Message Type | Current Decision |
| - | - |
| `MsgBorrow` | Restrict |
| `MsgWithdraw` | Allow |
| `MsgLiquidate` | Allow |

`MaxSupplyUtilization` could still be indirectly exceeded by borrow interest accruing.

Additionally, dynamic interest rates, which functioned as supply utilization ranged from `0` to `1`, would instead be adjusted expect values from `0` to `MaxSupplyUtilization`.

The motivation for restricting supply utilization is to reduce the likelihood of situations where suppliers cannot use `MsgWithdraw` due to borrowers borrowing all available supply.

This parameter overlaps in function with `MinCollateralLiquidity`. By lowering `MaxSupplyUtilization`, we create a buffer zone where `MsgBorrow` cannot reduce liquidity any further, but `MsgWithdraw` is still available. This helps protect suppliers and makes it more difficult to reach `MinCollateralLiquidity` overall.

### Maximum Collateral Share

Another proposed parameter is `MaxCollateralShare`, to be defined per token.

```go
total_collateral_value(token) = total_collateral(token) * oracle_price_usd(token)
collateral_share(token) = total_collateral_value(token) / Sum_All_Tokens(total_collateral_value) // ranges 0 - 1
```

For example, if `10 ATOM` collateral exists at a price of `$20` alongside `100 OSMO` collateral at a price of `$1`, then `collateral_share(ATOM)` is `10 * $20 / $300 = 0.66` and `collateral_share(OSMO)` is `$100 / $300 = 0.33`.

Implementing `MaxCollateralShare` would restrict `MsgCollateralize` from increasing `total_collateral` above a desired level.

`MaxCollateralShare` could still be indirectly exceeded by fluctuating oracle prices, `MsgDecollateralize` or `MsgLiquidate` of other tokens, or interest accruing in one denom faster than another.

### Minimum Collateral Liquidity

Another proposed parameter is `MinCollateralLiquidity`, to be defined per token.

It is the reciprocal of `MaxCollateralUtilization`, functionally equivalent in which messages it would restrict.

```go
collateral_liquidity(token) = available(token) / total_collateral(token) // ranges 0 - ∞
toteki marked this conversation as resolved.
Show resolved Hide resolved
```

For example if `200 ATOM` of collateral exists and the `x/leverage` module only has `40 ATOM` available (with the rest of supply being borrowed out), then `collateral_liquidity(ATOM) = 0.2`.

Stable assets can have low `MinCollateralLiquidity` (as low as `0.02`, but more likely around `0.15`). Volatile assets should have significantly safer values, for example `0.5` or `1`.

Implementing `MinCollateralLiquidity` would restrict `MsgBorrow` and `MsgWithdraw` from decreasing `available_supply`, or `MsgCollateralize` from increasing `total_collateral` in certain market conditions.

It may or may not allow `MsgLiquidate` to decrease `available_supply` under the same conditions, to prevent crises.

| Message Type | Current Decision |
| - | - |
| `MsgBorrow` | Restrict |
| `MsgWithdraw` | Restrict |
| `MsgLiquidate` | Allow |

`MinCollateralLiquidity` could still be indirectly exceeded by supply interest accruing on a collateral denom's uToken exchange rate.

It has also been proposed separately to factor `collateral_liquidity` (or `collateral_utilization`) into dynamic interest rates, to enhance the current model which uses `supply_utilization` (see ADR-004).

## Alternatives

### Collateral Utilization

One proposed parameter is `MaxCollateralUtilization`, to be defined per token.

It is the reciprocal of `MinCollateralLiquidity`, so the motivation and tradeoffs will be the same.

```go
collateral_utilization(token) = total_collateral(token) / available(token) // ranges 0 - ∞
```

For example if `200 ATOM` of collateral exists and the `x/leverage` module only has `40 ATOM` available (with the rest of supply being borrowed out), then `collateral_utilization(ATOM) = 5`.

This quantity has the property of increasing rapidly (as 1/N -> 0) when available supply is under stress.

Stable assets will have high max collateral utilization (can go even to 50). Volatile assets should have significantly smaller collateral utilization, and assets with high risk should have max collateral utilization close to 1.

#### Motivation

High collateral utilization is dangerous for the system: When collateral utilization is above 1, liquidators may not be able to withdraw their the liquidated collateral.

Let's draw the following scenario to picture the liquidators risk:

> | User | Supply | Collateral | Borrowed |
> | - | - | - | - |
> | Alice| $1.2M BTC | - | - |
> | Bob | - | $1.5M LUNA | $1M BTC |
> | Charlie | - | $2M BTC | $1.4M LUNA |
>
> - Charlie predicts Luna collapse and sells the Luna.
> - Luna is sinking and Bob's position has to be liquidated. However:
> - Liquidators can liquidate Bob, but they can only redeem up to 6.6% of `u/Luna` because the rest is not available (Charlie borrowed it).
> - Charlie will not pay off her borrow position - she will wait for the final collapse and buy Luna cheaply.
> - Liquidators will not take the risk of obtaining and holding `u/Luna` when there is a risk of Luna sinking deep.
> - In case of the big crash, knowledgeable liquidators won't liquidate Bob, Bob will run away with $1M of BTC, and the system will end up with a bad debt and obligation to pay Alice.

## Consequences

### Positive
- Multiple ways of preserving market health
- Per-token parameters allow fine grained control

### Negative
- Users may find restrictions unfair, e.g. "why can't I borrow just because other people's collateral is too high?"
3 changes: 2 additions & 1 deletion docs/architecture/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -39,4 +39,5 @@ Note the context/background should be written in the present tense.

### Accepted

- [ADR-009: Liquidity Mining](./ADR-009-liquidity-mining.md)
- [ADR-009: Liquidity Mining](./ADR-009-liquidity-mining.md)
- [ADR-010: Market health parameters](./ADR-009-market-params.md)