xrpl-labs / net-worth-xapp Goto Github PK

Users in environments with flaky internet reported this:

They don't understand this (and are scared), I think it's best to add an intro,

"An error occurred, this can be the case because of a flaky internet connection or unexpected results from an XRPL node.
\n
\n
Details: {the existing message}"

Here's an account with 19k EUR in IOU. The default currency selected in the wallet is EUR. Meaning we're looking at an IOU representation of the native asset selected in the wallet.

Now when the Account Worth xApp is opened:

1. It takes the IOU value
2. Takes the order book and checks what XRP value the IOU has
3. Taks the XRP value and turns it into fiat value

This then results in a lower EUR value, because there's slippage (lack of liquidity)

However, if my native asset is EUR, and the IOU is EUR, I won't end up with a lower amount of EUR when looking at net worth: it should stay unconverted.

Imo, there should be one addition to the current calculations:

• If IOU (XRPL asset code) equals user native asset code, then don't convert but use value as-is

The window.ReactNativeWebview object may not always be there, but it is referenced here:

Solution: rely on the Xumm Universal SDK (NPM: xumm) and check the environment for xApp.

We recently improvd a thing or two in XUMM (home screen) regarding TLs displayed: instead of showing them if present, we show them only if they claim a reserve. It happens that TLs are misconfigured by issuers, so the TLs are fully in default state on the end user side (in XUMM), but because the issuer isn't in default state the TL (ledger object) still exists. It doesn't claim reserve on the user side though.

The best way to determine if it's relevant for the end user is if it claims reserve. Then they opted in to have the TL. Reserve claimed or balance non zero, actually.

I discussed this with XRPscan, Bithomp, etc. and they agree and will change their explorers as well.

The XUMM home screen already respects this, Account Worth should as well :) If not, users see TLs they don't have on their side, and are not claiming reserve. Showing it anyway is only confusing.

This is a sample that uses account_objects and flags to check for the reserve claim, and mocks the output of account_lines.

https://gist.github.com/WietseWind/5df413334385367c548a148de3d8a713