You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
-[1029](https://github.com/umee-network/umee/pull/1029) Removed MsgSetCollateral(addr,denom,bool), and replaced with MsgAddCollateral(addr,coin) and MsgRemoveCollateral(addr,coin)
52
52
-[1023](https://github.com/umee-network/umee/pull/1023) Restrict MsgWithdraw to only uToken input (no base token auto-convert)
53
+
-[1106](https://github.com/umee-network/umee/pull/1106) Rename Lend to Supply, including MsgLendAsset, Token EnableLend, docs, and internal functions. Also QueryLoaned similar queries to QuerySupplied.
Copy file name to clipboardExpand all lines: docs/architecture/ADR-001-interest-stream.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -52,11 +52,11 @@ As an alternative, transfer of uTokens via IBC could be forbidden or unsupported
52
52
53
53
- Requirement: Umee chain stores uAsset <-> Asset exchange rate for each asset (not 1:1)
54
54
55
-
In this implementation, for each whitelisted Cosmos asset type, the Umee chain stores an "exchange rate" between the base asset and its associated uToken. The exchange rate starts equal to 1, and increases whenever interest would have been applied to uToken balances in the original implementation. Whenever a lender deposits or withdraws base assets for uToken, this exchange rate is used.
55
+
In this implementation, for each whitelisted Cosmos asset type, the Umee chain stores an "exchange rate" between the base asset and its associated uToken. The exchange rate starts equal to 1, and increases whenever interest would have been applied to uToken balances in the original implementation. Whenever a user supplies or withdraws base assets for uToken, this exchange rate is used.
56
56
57
57
Example scenario:
58
58
59
-
> Two lenders Alice and Bob provide Atoms to the asset facility at different times and earn interest. Assume that for the duration of this scenario, the interest on deposited uAtoms is 0.1 percent per week (or 1 atom per week per 1000 deposited).
59
+
> Two users Alice and Bob supply Atoms to the asset facility at different times and earn interest. Assume that for the duration of this scenario, the interest on deposited uAtoms is 0.1 percent per week (or 1 atom per week per 1000 deposited).
60
60
>
61
61
> The asset facility starts with 0 atoms in custody and 0 uAtoms in circulation. The exchange rate of Atom:uAtom starts at 1.
Copy file name to clipboardExpand all lines: docs/architecture/ADR-002-deposit-assets.md
+12-12Lines changed: 12 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,11 +13,11 @@ Accepted
13
13
14
14
One of the base functions of the Umee universal capital facility is to allow liquidity providers to deposit assets, and earn interest on their deposits.
15
15
16
-
The associated feature “Lender deposits asset for uToken & redeems uToken for a single Cosmos asset type" was initially discussed as follows:
16
+
The associated feature “User supplies asset for uToken & redeems uToken for a single Cosmos asset type" was initially discussed as follows:
17
17
18
-
-Lender deposits (locks) a Cosmos asset (like Atoms or Umee) into asset facilities.
18
+
-User supplies (locks) a Cosmos asset (like Atoms or Umee) into asset facilities.
19
19
- Facility mints and sends u-Assets in response (u-Atom, u-umee).
20
-
-Lender redeems u-Assets for the original assets.
20
+
-User redeems u-Assets for the original assets.
21
21
- Asset facility knows its current balances of all asset types.
22
22
- Asset facility knows the amount of all u-Asset types in circulation.
23
23
@@ -71,41 +71,41 @@ The `sdk.Coins` type is a slice (ordered list) of `sdk.Coin` which contains a de
71
71
Asset Facility deposit functionality is provided by the two following message types:
72
72
73
73
```go
74
-
//MsgLendAsset - a lender wishes to deposit assets and receive uAssets
This resembles the built-in MsgSend, but either ToAddress or FromAddress is removed because the module's address should be used automatically. The remaining address is that of the lender.
88
+
This resembles the built-in MsgSend, but either ToAddress or FromAddress is removed because the module's address should be used automatically. The remaining address is that of the supplier.
89
89
90
90
MsgDepositAsset must use only allow-listed, non-uToken denominations. MsgWithdrawAsset must use only uToken denominations.
91
91
92
92
These messages should trigger the appropriate reaction (disbursement of uTokens after deposit, return of assets on withdrawal). The exchange rate defined in ADR-001 must be used.
93
93
94
94
_Note: The `Coin` type seen in the `Amount` fields contains a single token denomination and amount._
95
95
96
-
It is necessary that `MsgLendAsset` and `MsgWithdrawAsset` be signed by the lender's account. According to the [Transactions Page](https://docs.cosmos.network/master/core/transactions.html)
96
+
It is necessary that `MsgSupply` and `MsgWithdrawAsset` be signed by the supplier's account. According to the [Transactions Page](https://docs.cosmos.network/master/core/transactions.html)
97
97
98
98
> Every message in a transaction must be signed by the addresses specified by its GetSigners.
99
99
100
-
Thus `MsgLendAsset.GetSigners` and `MsgWithdrawAsset.GetSigners` should return the `Lender` address.
100
+
Thus `MsgSupply.GetSigners` and `MsgWithdrawAsset.GetSigners` should return the `Supplier` address.
101
101
102
102
### API
103
103
104
104
Both CLI and gRPC must be supported when sending the above message types, and all necessary handlers must be created in order to process and validate them as transactions. As part of this initial feature, an exact list of such steps required when adding message types will be created and added to future issues.
105
105
106
106
### Testing
107
107
108
-
Assuming a placeholder token allow-list of one element (e.g. `umee`), and a uToken existing (e.g. `u-umee`), an end-to-end test can be created in which one user account sends a `MsgLendAsset` and a `MsgWithdrawAsset` of the appropriate token types.
108
+
Assuming a placeholder token allow-list of one element (e.g. `umee`), and a uToken existing (e.g. `u-umee`), an end-to-end test can be created in which one user account sends a `MsgSupply` and a `MsgWithdrawAsset` of the appropriate token types.
Note: system must not allow to have available_supply to equal zero.
66
66
67
67
Intuition: we want collateral utilization to grow when there is less liquid tokenA available in the system to cover the liquidation.
68
-
Collateral utilization of tokenA is growing when lenders withdraw their tokenA collateral or when borrowers take a new loan of tokenA.
68
+
Collateral utilization of tokenA is growing when suppliers withdraw their tokenA collateral or when borrowers take a new loan of tokenA.
69
69
If a `tokenA` is not used a collateral then it's _collateral utilization_ is zero.
70
70
It is bigger than 1 when available supply is lower than the amount of `tokenA` used as a collateral.
71
71
When it is `N`, it means that only `1/N` of the collateral is available for redemption (u/tokenA -> tokenA).
72
72
73
73
#### Examples
74
74
75
-
Let's say we have 1000A (token A) provided to a system for lending. 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):
75
+
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):
76
76
77
77
1. B=0, C=0 → CU=0
78
78
1. B=0, C=500 → CU=0.5
@@ -88,20 +88,20 @@ Let's say we have 1000A (token A) provided to a system for lending. Below let's
88
88
89
89
High collateral utilization is dangerous for the system:
90
90
91
-
- When collateral utilization is above 1, lenders may not be able to withdraw their the liquidated collateral.
91
+
- When collateral utilization is above 1, liquidators may not be able to withdraw their the liquidated collateral.
92
92
- Liquidators, when liquidating a borrower, they get into position their _uToken_.
93
93
In case of bad market conditions and magnified liquidations, liquidators will like to redeem the _uToken_ for the principle (the underlying token).
94
94
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.
95
95
This will dramatically increase the risk of getting a profit by liquidators and could cause the system being insolvent.
96
96
97
97
Let's draw the following scenario to picture the liquidators risk:
98
98
99
-
1. Alice is providing \$1.2M USD for lending.
99
+
1. Alice is providing \$1.2M USD supply.
100
100
2. Bob is providing \$1.5M in Luna as a collateral and borrows 1M USD from Alice.
101
101
3. Charlie provides \$2M in BTC as a collateral and borrows $1.4M in Luna from Bob.
102
102
4. Charlie predicts Luna collapse and sells the Luna.
103
103
5. Luna is sinking and Bob position has to be liquidated. However:
104
-
-Lenders can liquidate Bob, but they can only redeem up to 6.6% of `u/Luna` because the rest is not available (Charlie borrowed it).
104
+
-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).
105
105
- Charlie will not pay off her borrow position - she will wait for the final collapse and buy Luna cheaply.
106
106
- Liquidators will not take the risk of obtaining and holding `u/Luna` when there is a risk of Luna sinking deep.
107
107
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.
@@ -184,7 +184,7 @@ In contrast, if we had put tokenDenom before borrower address, it would favor op
184
184
185
185
### Positive
186
186
187
-
- uTokens used as a collateral increase in base asset value in the same way that lends positions do. This counteracts borrow position interest.
187
+
- uTokens used as a collateral increase in base asset value in the same way that supply positions do. This counteracts borrow position interest.
188
188
- UX of enabling/disabling token types as collateral is simpler than depositing specific amounts
189
189
-`lengthPrefixed(borrowerAddress) | tokenDenom` key pattern facilitates getting open borrow and collateral positions by account address.
Copy file name to clipboardExpand all lines: docs/architecture/ADR-004-interest-and-reserves.md
+8-8Lines changed: 8 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,9 +13,9 @@ Accepted
13
13
## Context
14
14
15
15
Borrow positions on Umee accrue interest over time.
16
-
When interest accrues, the sum of all assets owed by all users increases for each borrowed token denomination. The amount of that increase serves to benefit lenders (by increasing the token:uToken exchange rate), and also to increase the amount of base assets the Umee system holds in reserve.
16
+
When interest accrues, the sum of all assets owed by all users increases for each borrowed token denomination. The amount of that increase serves to benefit suppliers (by increasing the token:uToken exchange rate), and also to increase the amount of base assets the Umee system holds in reserve.
17
17
18
-
The mechanism by which interest is calculated, and then split between incentivizing lenders as per [ADR-001](./ADR-001-interest-stream.md) and reserves as defined in this ADR, will follow.
18
+
The mechanism by which interest is calculated, and then split between incentivizing suppliers as per [ADR-001](./ADR-001-interest-stream.md) and reserves as defined in this ADR, will follow.
19
19
20
20
## Decision
21
21
@@ -70,7 +70,7 @@ We modify the Compound formula to use collateral utilization rather than supply
70
70
71
71
The `x/leverage` module keeper will contain a function which accrues interest on all open borrow positions at once, which is called when `EndBlock` detects that has elapsed.
72
72
73
-
The accrued interest is split between protocol reserves and lender profits as explained in the following sections.
73
+
The accrued interest is split between protocol reserves and supplier profits as explained in the following sections.
@@ -131,13 +131,13 @@ for _, coin := range newReserves {
131
131
132
132
The token:uToken exchange rate, which would have previously been calculated by `(total tokens borrowed + module account balance) / uTokens in circulation` for a given token and associated uToken, must now be computed as `(total tokens borrowed + module account balance - reserved amount) / uTokens in circulation`.
133
133
134
-
Also, because Lend, Withdraw, Borrow, and Repay transactions don't affect the token:uToken exchange rate, it's enough to update the exchange rate during the EndBlocker `AccrueAllInterest`.
134
+
Also, because Supply, Withdraw, Borrow, and Repay transactions don't affect the token:uToken exchange rate, it's enough to update the exchange rate during the EndBlocker `AccrueAllInterest`.
135
135
136
136
### Modifications to Withdraw and Borrow
137
137
138
138
Existing functionality will be modified:
139
139
140
-
- Asset withdrawal (by lenders) will not permit withdrawals that would reduce the module account's balance of a token to below the reserved amount of that token.
140
+
- Asset withdrawal (by suppliers) will not permit withdrawals that would reduce the module account's balance of a token to below the reserved amount of that token.
141
141
- Asset borrowing (by borrowers) will not permit borrows that would do the same.
142
142
143
143
### Example Scenarios
@@ -160,18 +160,18 @@ Note that the module "reserved amount" has increased, but not the actual balance
160
160
Here is an additional example scenario, to illustrate that the module account balance of a given token _can_ become less than the reserved amount, when a token type is at or near 100% supply utilization:
161
161
162
162
> Lending pool and reserve amount of `atom` both start at zero.
163
-
> Bob, lends 1000 `atom` to the lending pool.
163
+
> Bob, supplies 1000 `atom` to the lending pool.
164
164
> Alice immediately borrows all 1000 `atom`.
165
165
>
166
166
> During the next `EndBlock`. Alice now owes 1000.001 `atom`. The amount of `uatom` the module is required to reserve increases from 0 to 50 (assuming the `ReserveFactor` parameter is 0.05 like in the previous example).
167
167
>
168
168
> The module account (lending pool + reserves) still contains 0 `uatom` due to the first two steps. Its `uatom` balance is therefore less than the required 50 `uatom` reserves.
169
169
170
-
The scenario above is not fatal to our model - Bob (lender) continues to gain value as the token:uToken exchange rate increases, and we are not storing any negative numbers in place of balances - but the next 50 `uatom`lent by a lender or repaid by a borrower will be blocked for the reserve requirements rather than being immediately available for borrowing or withdrawal.
170
+
The scenario above is not fatal to our model - Bob (supplier) continues to gain value as the token:uToken exchange rate increases, and we are not storing any negative numbers in place of balances - but the next 50 `uatom`supplied by a supplier or repaid by a borrower will be blocked for the reserve requirements rather than being immediately available for borrowing or withdrawal.
171
171
172
172
The edge case above can only occur when the available lending pool (i.e. module account balance minus reserve requirements) for a specific token denomination, is less than `ReserveFactor` times the interest accrued on all open loans for that token in a single block. In practical terms, that means ~100% supply utilization.
173
173
174
-
This is not a threatening scenario, as it resolves as soon as either a sufficient `RepayAsset` or a `LendAsset` is made in the relevant asset type, both of which are **highly** incentivized by the extreme dynamic interest rates found near 100% utilization.
174
+
This is not a threatening scenario, as it resolves as soon as either a sufficient `RepayAsset` or a `MsgSupply` is made in the relevant asset type, both of which are **highly** incentivized by the extreme dynamic interest rates found near 100% utilization.
Copy file name to clipboardExpand all lines: docs/architecture/ADR-008-borrow-tracking.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -35,7 +35,7 @@ This change in borrow storage will be opaque to other parts of the leverage modu
35
35
36
36
As a result of efficiency gains, the parameter `InterestEpoch` will be removed, with periodic functions taking place every block.
37
37
38
-
Additionally, the values `BorrowAPY`, `LendAPY`, and `uTokenExchangeRate` will be removed from state, instead being efficiently calculated when needed.
38
+
Additionally, the values `BorrowAPY`, `SupplyAPY`, and `uTokenExchangeRate` will be removed from state, instead being efficiently calculated when needed.
39
39
40
40
## Detailed Design
41
41
@@ -48,11 +48,11 @@ This decision mainly updates existing features, rather than adding new ones. The
48
48
**State:**
49
49
50
50
- Add `InterestScalar` and `TotalAdjustedBorrows` to state, and add `Get/Set` functions
51
-
- Remove `BorrowAPY`, `LendAPY`, and `uTokenExchangeRate` from state, and remove `Set` functions
51
+
- Remove `BorrowAPY`, `SupplyAPY`, and `uTokenExchangeRate` from state, and remove `Set` functions
52
52
53
53
**Getters:**
54
54
55
-
- Modify `Get` functions for `BorrowAPY`, `LendAPY`, and `uTokenExchangeRate` to calculate values in real time.
55
+
- Modify `Get` functions for `BorrowAPY`, `SupplyAPY`, and `uTokenExchangeRate` to calculate values in real time.
56
56
- Modify `GetBorrow(addr,denom)`, `GetBorrowerBorrows(addr)`, and `GetAllBorrows()` to use `InterestScalar` and `AdjustedBorrow`
57
57
- Modify `GetTotalBorrows(denom)` to use `InterestScalar` and `TotalAdjustedBorrows`
58
58
@@ -104,7 +104,7 @@ This design change should address our lingering tradeoff between performance and
104
104
105
105
- Total borrows and supply utilization can be calculated in O(1) time instead of O(N) as N is the total number of borrow positions across all users
106
106
- Periodic functions can now take place every block instead of every `InterestEpoch` blocks
107
-
- Quantities like uToken exchange rates and lend APYs now update instantly to new borrow and lend activity, even between multiple transactions within the same block.
107
+
- Quantities like uToken exchange rates and supply APYs now update instantly to new borrow and supply activity, even between multiple transactions within the same block.
0 commit comments