ggxchain / dex-ui

1 stars 0 forks source link

Formatting and rounding numbers #45

Open uchu opened 4 months ago

uchu commented 4 months ago

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.

AuroraLantean commented 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

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

uchu commented 4 months ago

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

AuroraLantean commented 4 months ago

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

AuroraLantean commented 4 months ago

@uchu @Warchant @akorchyn Regarding "harcoded map: token: price precision, amount precision":

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:

AuroraLantean commented 4 months ago

@uchu instructed to follow major cryptoexchange design patterns. According to Binance design:

AuroraLantean commented 4 months ago

Done: set Modal input max to 8 decimal precision in Wallet, Dex, BridgeBTC pages

AuroraLantean commented 4 months ago

@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

AuroraLantean commented 4 months ago

@uchu From the above observation, Price Representation Rules can be deduced:

AuroraLantean commented 4 months ago

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

akorchyn commented 4 months ago

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 ☺️

AuroraLantean commented 4 months ago

@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...

olenaboosty commented 4 months ago

@xcthulhu

AuroraLantean commented 4 months ago

PR: "fix input amount decimals, balance decimals, price representation #54" https://github.com/ggxchain/rfq-ui/pull/54 ? This PR includes all the following:

AuroraLantean commented 4 months ago

@uchu can I close this issue?

uchu commented 4 months ago

@AuroraLantean No, leave it to me please. I will review during the day. You can start with other tasks, that are some bugs. Thanks!

AuroraLantean commented 4 months ago

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

AuroraLantean commented 4 months ago

I think all the issues regarding this item have been resolved and all the above PRs have been merged.