From bb0a7893c36181ae5f68c56e6192e9a78e576065 Mon Sep 17 00:00:00 2001 From: Roman Akhtariev Date: Fri, 16 Jun 2023 20:04:41 +0000 Subject: [PATCH 1/8] docs: precision issues around price; short and long term solution --- x/concentrated-liquidity/README.md | 110 +++++++++++++++++++++++++++++ 1 file changed, 110 insertions(+) diff --git a/x/concentrated-liquidity/README.md b/x/concentrated-liquidity/README.md index c1755036d2e..9a180f4ab12 100644 --- a/x/concentrated-liquidity/README.md +++ b/x/concentrated-liquidity/README.md @@ -1582,6 +1582,116 @@ Note that for storing ticks, we use 9 bytes instead of directly using uint64, fi Note that the reason for having pool ID and min uptime index is so that we can retrieve all incentive records for a given pool ID and min uptime index by performing prefix iteration. +## Precision Issues With Price + +There are precision issues that we must be considerate of in our design. + +Consider the balancer pool between `uarb` and `uosmo`: + +``` +osmosisd q gamm pool 1011 +pool: + '@type': /osmosis.gamm.v1beta1.Pool + address: osmo1pv6ffw8whyle2nyxhh8re44k4mu4smqd7fd66cu2y8gftw3473csxft8y5 + future_pool_governor: 24h + id: "1011" + pool_assets: + - token: + amount: "101170077995723619690981" + denom: ibc/10E5E5B06D78FFBB61FD9F89209DEE5FD4446ED0550CBB8E3747DA79E10D9DC6 + weight: "536870912000000" + - token: + amount: "218023341414" + denom: uosmo + weight: "536870912000000" + pool_params: + exit_fee: "0.000000000000000000" + smooth_weight_change_params: null + swap_fee: "0.002000000000000000" + total_shares: + amount: "18282469846754434906194" + denom: gamm/pool/1011 + total_weight: "1073741824000000" +``` + +Let's say we want to migrate this into a CL pool where `uosmo` is the quote +asset and `uarb` is the base asset. + +Note that quote asset is denom1 and base asset is denom0. +We want quote asset to be `uosmo` so that limit oredrs on ticks +have tick spacing in terms of `uosmo` as the quote. + + +Note: +- OSMO has precision of 6. 1 OSMO = 10**6 `uosmo` +- ARB has precision of 18. 1 ARB = 10**18 `uarb` + +Therefore, the true price of the pool is: +``` +>>> (218023341414 / 10**6) / (101170077995723619690981 / 10**18) +2.1550180224553714 +``` + +However, in our core logic it is represented as: + +``` +218023341414 / 101170077995723619690981 +2.1550180224553714e-12 +``` + +or + +``` +osmosisd q gamm spot-price 1011 uosmo ibc/10E5E5B06D78FFBB61FD9F89209DEE5FD4446ED0550CBB8E3747DA79E10D9DC6 +spot_price: "0.000000000002155018" +``` + +As a protocol, need to accomodate prices that are very far apart. +As in the example above, the difference between `10**6 and 10**18` + +Most of the native precision is 10**6. However, most of the ETH +precision is 10**18. + +This starts to matter for assets such as `upepe`. That have +a precision of 18 and a very low price level relative to +the quote asset that has precision of 6 (e.g `uosmo` or `uusdc`). + +The true price of PEPE in USDC terms is `0.0000009749`. + +0.0000009749 * 10**6 / 10**18 = 9.749e-19 + +This below the minimum precision of `sdk.Dec`. + +Additionally, there is a problem with tick to sqrt price conversions +where at small price levels, two sqrt prices can map to the same +tick. + +As a workaround, we have decided to limit min spot price to 10^-12 +and min tick to `-108000000`. It has been shown at at price levels +below 10^-12, this issue is most apparent. See this issue for details: + + +Now, we have a problem that we cannot handle pairs where +the quote asset has a precision of 6 and the base asset has a +precision of 18. + +Note that this is not a problem for pairs where the quote asset +has a precision of 18 and the base asset has a precision of 6. +E.g. OSMO/DAI. + +### Solution + +At launch, pool creation is permissioned. Therefore, we can +ensure correctness. + +Long term, we will implement a wrapper contract around concentrated liquidity +that will handle the precision issues and scale the prices to be all in the +desired precision of 6. + +The contract will have to handle truncation and rounding to determine +how to handle dust during this process. The truncated amount can be significant. +That being said, this problem is out of scope for this document. + ## Terminology We will use the following terms throughout the document: From 32e037417be846843a5084b806fa60a4ab754812 Mon Sep 17 00:00:00 2001 From: Roman Akhtariev Date: Fri, 16 Jun 2023 20:09:14 +0000 Subject: [PATCH 2/8] updates --- x/concentrated-liquidity/README.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/x/concentrated-liquidity/README.md b/x/concentrated-liquidity/README.md index 9a180f4ab12..56e5a467c9c 100644 --- a/x/concentrated-liquidity/README.md +++ b/x/concentrated-liquidity/README.md @@ -1646,8 +1646,8 @@ osmosisd q gamm spot-price 1011 uosmo ibc/10E5E5B06D78FFBB61FD9F89209DEE5FD4446E spot_price: "0.000000000002155018" ``` -As a protocol, need to accomodate prices that are very far apart. -As in the example above, the difference between `10**6 and 10**18` +As a protocol, we need to accomodate prices that are very far apart. +In the example above, the difference between `10**6 and 10**18` Most of the native precision is 10**6. However, most of the ETH precision is 10**18. @@ -1658,9 +1658,10 @@ the quote asset that has precision of 6 (e.g `uosmo` or `uusdc`). The true price of PEPE in USDC terms is `0.0000009749`. -0.0000009749 * 10**6 / 10**18 = 9.749e-19 +In the "on-chain representaiton", this would be: +`0.0000009749 * 10**6 / 10**18 = 9.749e-19` -This below the minimum precision of `sdk.Dec`. +Noe that this is below the minimum precision of `sdk.Dec`. Additionally, there is a problem with tick to sqrt price conversions where at small price levels, two sqrt prices can map to the same @@ -1682,7 +1683,7 @@ E.g. OSMO/DAI. ### Solution At launch, pool creation is permissioned. Therefore, we can -ensure correctness. +ensure correctness for the initial set of pools. Long term, we will implement a wrapper contract around concentrated liquidity that will handle the precision issues and scale the prices to be all in the From 3bd17adfaa3715d26b46f978e722829443004040 Mon Sep 17 00:00:00 2001 From: Roman Akhtariev Date: Fri, 16 Jun 2023 20:13:07 +0000 Subject: [PATCH 3/8] lint --- x/concentrated-liquidity/README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/x/concentrated-liquidity/README.md b/x/concentrated-liquidity/README.md index 56e5a467c9c..e2b0532e9f6 100644 --- a/x/concentrated-liquidity/README.md +++ b/x/concentrated-liquidity/README.md @@ -1588,7 +1588,7 @@ There are precision issues that we must be considerate of in our design. Consider the balancer pool between `uarb` and `uosmo`: -``` +```bash osmosisd q gamm pool 1011 pool: '@type': /osmosis.gamm.v1beta1.Pool @@ -1627,21 +1627,21 @@ Note: - ARB has precision of 18. 1 ARB = 10**18 `uarb` Therefore, the true price of the pool is: -``` +```python >>> (218023341414 / 10**6) / (101170077995723619690981 / 10**18) 2.1550180224553714 ``` However, in our core logic it is represented as: -``` +```python 218023341414 / 101170077995723619690981 2.1550180224553714e-12 ``` or -``` +```python osmosisd q gamm spot-price 1011 uosmo ibc/10E5E5B06D78FFBB61FD9F89209DEE5FD4446ED0550CBB8E3747DA79E10D9DC6 spot_price: "0.000000000002155018" ``` From d58c64d0f604740f5b783fd1348403c44f00a1b3 Mon Sep 17 00:00:00 2001 From: Roman Date: Fri, 16 Jun 2023 16:24:12 -0400 Subject: [PATCH 4/8] Update x/concentrated-liquidity/README.md Co-authored-by: alpo <62043214+AlpinYukseloglu@users.noreply.github.com> --- x/concentrated-liquidity/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x/concentrated-liquidity/README.md b/x/concentrated-liquidity/README.md index e2b0532e9f6..d2b9b795781 100644 --- a/x/concentrated-liquidity/README.md +++ b/x/concentrated-liquidity/README.md @@ -1618,7 +1618,7 @@ Let's say we want to migrate this into a CL pool where `uosmo` is the quote asset and `uarb` is the base asset. Note that quote asset is denom1 and base asset is denom0. -We want quote asset to be `uosmo` so that limit oredrs on ticks +We want quote asset to be `uosmo` so that limit orders on ticks have tick spacing in terms of `uosmo` as the quote. From f77142fc345dcce8ba31b4eade34b96d43f9e698 Mon Sep 17 00:00:00 2001 From: Roman Date: Fri, 16 Jun 2023 16:52:51 -0400 Subject: [PATCH 5/8] Update x/concentrated-liquidity/README.md Co-authored-by: Sishir Giri --- x/concentrated-liquidity/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x/concentrated-liquidity/README.md b/x/concentrated-liquidity/README.md index d2b9b795781..a8601284ba1 100644 --- a/x/concentrated-liquidity/README.md +++ b/x/concentrated-liquidity/README.md @@ -1658,7 +1658,7 @@ the quote asset that has precision of 6 (e.g `uosmo` or `uusdc`). The true price of PEPE in USDC terms is `0.0000009749`. -In the "on-chain representaiton", this would be: +In the "on-chain representation", this would be: `0.0000009749 * 10**6 / 10**18 = 9.749e-19` Noe that this is below the minimum precision of `sdk.Dec`. From 462cf657076d0d008084ee20ab0f2e879cc0af45 Mon Sep 17 00:00:00 2001 From: Roman Date: Fri, 16 Jun 2023 16:53:06 -0400 Subject: [PATCH 6/8] Update x/concentrated-liquidity/README.md Co-authored-by: Sishir Giri --- x/concentrated-liquidity/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x/concentrated-liquidity/README.md b/x/concentrated-liquidity/README.md index a8601284ba1..0c6f3fb8d96 100644 --- a/x/concentrated-liquidity/README.md +++ b/x/concentrated-liquidity/README.md @@ -1661,7 +1661,7 @@ The true price of PEPE in USDC terms is `0.0000009749`. In the "on-chain representation", this would be: `0.0000009749 * 10**6 / 10**18 = 9.749e-19` -Noe that this is below the minimum precision of `sdk.Dec`. +Note that this is below the minimum precision of `sdk.Dec`. Additionally, there is a problem with tick to sqrt price conversions where at small price levels, two sqrt prices can map to the same From 3ab76f1b475222f90a0364af2d20a4baf0b3c188 Mon Sep 17 00:00:00 2001 From: Roman Date: Sat, 17 Jun 2023 10:30:24 -0400 Subject: [PATCH 7/8] remove uarb notation --- x/concentrated-liquidity/README.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/x/concentrated-liquidity/README.md b/x/concentrated-liquidity/README.md index 0c6f3fb8d96..7ca0c6bc6d2 100644 --- a/x/concentrated-liquidity/README.md +++ b/x/concentrated-liquidity/README.md @@ -1586,7 +1586,7 @@ all incentive records for a given pool ID and min uptime index by performing pre There are precision issues that we must be considerate of in our design. -Consider the balancer pool between `uarb` and `uosmo`: +Consider the balancer pool between `arb` base unit and `uosmo`: ```bash osmosisd q gamm pool 1011 @@ -1615,16 +1615,15 @@ pool: ``` Let's say we want to migrate this into a CL pool where `uosmo` is the quote -asset and `uarb` is the base asset. +asset and `arb` base unit is the base asset. Note that quote asset is denom1 and base asset is denom0. We want quote asset to be `uosmo` so that limit orders on ticks have tick spacing in terms of `uosmo` as the quote. - Note: - OSMO has precision of 6. 1 OSMO = 10**6 `uosmo` -- ARB has precision of 18. 1 ARB = 10**18 `uarb` +- ARB has precision of 18. 1 ARB = 10**18 `arb` base unit Therefore, the true price of the pool is: ```python From f862e8d5652e95f20cd9aaeae30cb8bd3453475c Mon Sep 17 00:00:00 2001 From: Dev Ojha Date: Mon, 19 Jun 2023 14:47:15 +0200 Subject: [PATCH 8/8] Update x/concentrated-liquidity/README.md --- x/concentrated-liquidity/README.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/x/concentrated-liquidity/README.md b/x/concentrated-liquidity/README.md index 7ca0c6bc6d2..668262a3c6e 100644 --- a/x/concentrated-liquidity/README.md +++ b/x/concentrated-liquidity/README.md @@ -1685,8 +1685,7 @@ At launch, pool creation is permissioned. Therefore, we can ensure correctness for the initial set of pools. Long term, we will implement a wrapper contract around concentrated liquidity -that will handle the precision issues and scale the prices to be all in the -desired precision of 6. +that will handle the precision issues and scale the prices to all have a precision of at most 12. The contract will have to handle truncation and rounding to determine how to handle dust during this process. The truncated amount can be significant.