EPIC: Intelligently choose how many DP to display

[JonRay15]

Intelligently choose how many DP to display in positions, orders, fills, collateral on Console...

Tasks

• [x] Quantum formatting for collateral table vegaprotocol/frontend-monorepo#2340
• [x] Quantum formatting for liquidity provision table vegaprotocol/frontend-monorepo#2341
• [x] Quantum formatting for deal ticket vegaprotocol/frontend-monorepo#3952
• [ ] Quantum formatting for Ledger entries (transfer amount)
• [x] https://github.com/vegaprotocol/frontend-monorepo/issues/4301
• [ ] Quantum formatting for LP Dashboard vegaprotocol/vega.xyz#707
• [x] Quantum formatting for min Withdrawal amount vegaprotocol/frontend-monorepo#3915

Additional information

Can we start trying to intelligently decide how many DP to show anywhere in Console that we are using asset dp. Everywhere else I think we're using positionDecimals or decimals so the values are sensible, but these are set by market by a user so are generally sensible values. Where asset DP is often long (18) and can be meaningful to different levels depending on the asset (eg BTC vs USDT)

We could use quantum in order to work out how many DP is sensible. I'd argue less that 0.001USD is meaningless.

Based on discussion with @TomMcL we think mirroring other exchanges is best and propose to add a tick box for "Show Dust" or "Show Small Balances". This box would be somewhere on Collateral section, in the footer or similar.

If user selects "Show Small Balances" then we should simply remove all trailing zeroes on all numbers, but show however many non-zero DP we have for that asset, regardless of materiality.

If user selects "Hide Small Balances" then we should apply the below logic.

The values we'd want would be the below, so you could just code the ranges.

Or expressed as a formula if easier:

Number DP = MAX(0, LOG10(100/Quantum))

NB. Ideally the 100 in the above would be configurable in the component, because we will probably use this in LP Dashboard too and in that we probably dont care about 1c .... we would only care about 1 USD min so having that configurable gives us flexibility.

When in "Hide Small Balances" mode it is possible that the user's balance for a given asset may be so small that the asset should be hidden altogether.

Full Review based on Barney & Madalina comment

Market Level In the analysis below: md = in line with decimals value from market pd = in line with positionDecimals value from market config ad = in line with decimals on the asset

Positions Notional Size = md = correct Open Volume = pd = correct Mark price = md = correct Entry price = md = correct Liquidation price = md = correct Leverage = shown to 1, think thats hard coded and is fine Margin = ad = correct > apply enhancement Realised / Unrealised PNL = md = correct

Orders Size = pd = correct Filled = pd = correct

Fills Size = pd = correct Value = md = correct Filled value = md = correct Fee = ad = correct > apply enhancement**

Collateral Total = correct > apply enhancement Margin breakdown = correct > apply enhancement

Liquidity Provision Table Commitment = doesnt match any of ad / pd / md .... what is it? Should be ad with enhancement imo Proposed Fee = dont know what this is either? It probably has to be whatever anyone sets? Market valuation at entry = ad = correct > apply enhancement Obligation = dont know, think it should be ad and apply enhancement Supplied = dont know, think it should be ad and apply enhancement

Portfolio Level Positions, Orders, and Fills all behave as above so same conclusions.

Ledger Entries MTM done using md which is fine. Transfers = should use ad with enhancement

Deposits Once you select an asset: Maximum total deposit amount needs this treatment Remaining needs this treatment If you click "view asset details" the infrastricture fee account balance needs this treatment

Withdrawals The Amount should use this treatment

I can then think of two ways to address Barney's desire for full precision to be available if needed. Either

1. We introduce the "Show / Hide Small Balances" button on the Collateral tab and the setting applied there is applied EVERYWHERE in the app that asset decimals are used (effectively we assume if you love detail you love it everywhere)
2. We apply the enhancement by default everywhere and show full detail on hover everywhere
3. We introduce the button, but even with it applied you can hover over for full details

I think it depends a bit on the pain involved with having a hover over everywhere. And also on whether we think that it is right to have a button on the collateral tab control your experience everywhere in the app.

[barnabee]

Proposal looks good cocneptually for financial amounts.

I'd probably tend towards one more place than the example. Though it depends on context, if the smallest useful amount is one cent I'd generally like an extra dp of precision so that I can see how the amount I'm interested in move. Sometimes though the smallest useful amount is thousands or millions and I'm sure some people would love that to be configurable by asset too.

Ideally the precision would be configurable.

Note also that we can't apply this to prices on orders, trades, etc. because:

1. They aren't guaranteed to have asset units, and we have no way to know if they coincidentally match an asset, so quantum is undefined.
2. Even when they do the dps would often be different. For instance GBPUSD is often quoted with 1 or 2 more dps than people would normally use.

[barnabee]

If we ever truncate in a way that loses data, we should show the full data somewhere.

So for instance, if you have a value:

123.457000000002300000

We might decide to show 123.46 or 123.457 but we need to make it possible to see 123.4570000000023 (we could drop the trailing zeros after '23' in the hover as they don't add any data). 

Ways to show this data might be:

• In a hover tooltip
• In an expandable details area
• via a clickable ellipsis (123.46[…]) that shows the full data in place when clicked
• by linking from the value to another view (which could be on a different site like block explorer) that shows the full data
• etc…

This is necessary because our primary "product" is the software for a blockchain and all of our dapps need to work well as views over that chain and can't [only] be considered products in their own right.

For example, Console will be used by many people who never place a trade through Console, including probably every serious profresional trading firm. They will use it as a way to view data. If they end up doing calculations in spreadsheets or on their own systems and pasting data from Console, we need those calcs to match what they see elsewhere and in APIs and what the specs and code say, so we need to make sure people know if we've truncated or hidden data.

[JonRay15]

Other places to potentially apply this ... review and update ticket:

balances (collateral, margin, positions - P&L, deposits/withdrawals, ledger entries, ...) ledger entry amounts fees rewards transfers deposits withdrawals LP stake (individual and total supplied, target) staked balance (VEGA tokens) total staked/delegated for validators delegations total votes for/against a proposal thresholds for proposals (if expressed as a num of tokens) deposit limit for asset

[JonRay15]

Reviewed all the Console cases Barney outlined above and provided info / recommendations in the main ticket.

Many of the other cases he described are not in Console so will raise other tickets for these.

[mattrussell36]

@MadalinaRaicu @barnabee @JonRay15 I've created the following two tickets off the back of this (will probably need some further refinement)

• https://github.com/vegaprotocol/frontend-monorepo/issues/2341
• https://github.com/vegaprotocol/frontend-monorepo/issues/2340

Looks like these two provide the most value.

What I propose is that we tackle this on a table by table basis, starting with collateral. This will allow us to figure out the best implementation without having to also implement some global settings.

We should be able to do this in way which leverages the tool AgGrid provide. For example we could add a checkbox/toggle control to header columns (in a dropdown similar to column filtering) which can toggle the value formatter for that column between the raw value and a formatted value using asset.quantum. What do you think?

That said, to me this feels like a lower value task right now. Reasons being:

• We still have some problems with data integrity, adding in another layer of data manipulation potentially increases the surface area for bugs here. If we can get away with just showing the raw values (perhaps just trimming trailing zeroes), perhaps we should.
• Adding toggles/settings quickly increases number of test cases. Given we are behind on test coverage, this is another reason to only show the raw value and ensure that it is well tested first

[barnabee]

Although I mentioned expandable/hoverable ability to get full precision, and still would like this, some areas like the deal ticket could definitely live without that, and if a first iteration didn't have that, I'd be ok with it.

[JonRay15]

We've done this everywhere we needed to