Open uchu opened 4 months ago
@uchu @Warchant @akorchyn
After some research, for financial calculation it is recommended to use integers to do all calculation, then we round up to what we want at division: https://www.pullrequest.com/blog/precision-matters-why-using-cents-instead-of-floating-point-for-transaction-amounts-is-crucial/
Define "dp" as decimal precision... E.g. USD has 2 dp for example $ 2.37
Addition/Subtraction: a tokenA 2dp balance adds or subtracts a tokenB 3dp balance: Convert them into integers using the bigger dp E.g. 0.01+0.001 => (10 + 1)x1000 = 11 and dp of 3 => 0.011, and that is 3 dp Result dp = the max dp between them
Multiplication: a tokenA 2dp balance multiplies a tokenB 3dp balance: Convert them into integers using each of their dp E.g. 0.01*0.001 => (1x1)/(100 x1000) => 1 and dp of 5 => 0.00001 and that is 5 dp. The result dp = the sum of those dp
Division: a tokenA 3dp balance is divided by a tokenB 2dp balance: Convert them into integers using the bigger dp 3dp / 2dp => 2dp( top and bottom both are multiplied by the bigger of 10**dp => 0 dp / 0 dp => dp1-dp2 ) E.g. 0.001/0.10 => 1/10 => 0.1 The result dp = 3-2 = 1
2dp / 3dp => 2dp( top and bottom both are multiplied by the bigger of 10**dp => 0 dp / 0 dp => dp1-dp2 ) E.g. 0.01/0.001 => 10/1 = 10 The result dp = 0
E.g. 0.01/100.000 => 10/100000 = 0.0001 The result dp = ?? ... Division in math is always strange... I think we can decide how much dp we want after division
E.g. 0.01/100.000 => 10/100000 = 0.0001 Why it cannot be dp = 4 here?
Lets add max dp as a configurable variable. We can start with something like 6 max, and we can adjust it later in one place
Yes, 4dp... I was saying the dp from division is not predictable given input of dp1 and dp2
All practical calculations, we can all use BigNumber or similar libraries in JavaScript here and Rust in the GGXNode Those dp rounding are only for frontend users to view. Okay I will add a max dp
@uchu @Warchant @akorchyn Regarding "harcoded map: token: price precision, amount precision":
Amount precision has already be determined by each token/currency, except rare cases E.g. BTC: 8 dp, ETH: 18 dp, USDT on Ethereum network: 6 dp Exception. in Binance and Coinmarketpalce, USDT is quoted in 4 dp like 0.9996 USD, although USD itself has only 2 dp
Price precision is determined by the base token(like base currency in foreign exchange), and I suggest we round it up to ceiling in displayed view. Ceiling rounding means 0.051 is rounded to 0.06 in 2 dp
E.g. the price of BTC in USDT should be the same as USDT 6dp, because the customers have to pay in USDT, which is in 6dp 61158.69 USD per BTC /0.9996 USD per USDT = 61183.163265306 USDT/BTC ... We round it to ceiling 6dp: 61183.163266
E.g. the price of USDT in BTC should be the same as BTC 8dp 0.9996 USD per USDT/ 61158.69 USD per BTC = 0.9996/61158.69 BTC/USDT = 0.000016344 ... We round it to ceiling 8dp: 0.00001635
For actual exchange calculation when we calculate swap output token amount, we calculate all in integers and in BigNumbers. And we could:
@uchu instructed to follow major cryptoexchange design patterns. According to Binance design:
Done: set Modal input max to 8 decimal precision in Wallet, Dex, BridgeBTC pages
@uchu Regarding price and balance representation, after looking at Binance and Coinmarketcap, most tokens have 2 and 4 decimals, but the others have the following long decimals... However, they all have 4 significant figures(DOGE changes in price a lot so it changes between 4 and 5 significant figures). So 4 significant figures is more important, not fixed decimals. Please advise. Thanks Binance Price Display: https://www.binance.com/en/markets/overview DOGE $0.15273 ... 5 dp XME $0.03685 ... 5dp DGB $0.01275 ... 5dp XVG $0.005628 ... 6dp Coinmarketcap Price Display: https://coinmarketcap.com/ DOGE $0.1531 ... 4dp XEM $0.03696 ... 5 dp VeChain $0.04085 ... 5 dp Floki $0.0001425 ... 7 dp Shiba $0.00002278 ... 8 dp PEPE $0.000005191 ... 9 dp BONK $0.00001483 ... 8 dp
@uchu From the above observation, Price Representation Rules can be deduced:
I found another bug so cannot further progress on this item until this is fixed: DexPage Orderlist Prices show zeros#272 https://github.com/orgs/ggxchain/projects/6/views/1?pane=issue&itemId=60517298
DexPage SellAmount cannot handle some decimal inputs#268 https://github.com/orgs/ggxchain/projects/6/views/1?pane=issue&itemId=60312438
To be honest, this task seems related to this one. I don't think we need to create a new one and fix it as part of this one ☺️
@akorchyn the calculated price from amountConverter.divWithPrecision(requested, offered,)
is zero, so I will need to fix that whole calculation later on, and that is outside of formatting and rounding...
@xcthulhu
PR: "fix input amount decimals, balance decimals, price representation #54" https://github.com/ggxchain/rfq-ui/pull/54 ? This PR includes all the following:
formatting-numbersPart2
branch is moved to formatting-numbersPart3
@uchu can I close this issue?
@AuroraLantean No, leave it to me please. I will review during the day. You can start with other tasks, that are some bugs. Thanks!
DexPage Orderlist Prices show zeros#272 Fix Dex page orderlist prices #59 https://github.com/ggxchain/rfq-ui/pull/59/ is waiting for merging And DexPage SellAmount cannot handle some decimal inputs#268 https://github.com/ggxchain/rfq-ui/pull/58 ... has been merged
I think all the issues regarding this item have been resolved and all the above PRs have been merged.
We need to format all numbers in DEX, so it is more easy to read long numbers. For example: 1,000,000.00 (with 2 decimals precision by default)
We need to implement an ability to use custom decimal precision. In the simplest way it can be just a harcoded map: token: price precision, amount precision. In that way we can correctly display tokens that have typically low price or quantities.
Examples 0.0000012 BTC 30000.56 some token 150.50 USDT
While amounts can be like 1100.00 Usdt when displayed in the interface, the actual values can be like 1100.000091. we have to display the full exact amount on mouse hover (simple html tooltip is enough for now) and in any input fields of the forms. Also in the sections where we make transactions.
Let's discuss the parts of the UI where full or alternative formats can be needed, unless it is obvious.
DOD:
All numbers, prices and amounts should be rounded and formatted correctly.