Implement XRP DEX order parsing -> EdgeTxAction's

[Jon-edge]

CHANGELOG

Does this branch warrant an entry to the CHANGELOG?

• Yes
• No

Dependencies

EdgeApp/edge-core-js#567

Description

Parse XRP DEX orders into EdgeTxActions. Supports OfferCreate and OfferCancel type order tx's

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1205412691849558

[paullinator]

Replace most of parseRippleDexTxAmount and processRippleDexTx with getBalances to determine src/dest amounts of order fulfillments.

[Jon-edge]

The way I had it done is more accurate and complete according to xrpscan.com.

The balances object is good for including mainnet fees in the xrp amount total, but for some reason underreports the actual amounts involved in the trades (regardless of fees - token amounts are underreported). Also there's no way to tell unfilled order amounts from the Balances obj either.

[Jon-edge]

Comparing against xrpscan.com shows alignment between my amounts and the summary amounts given by api queries to xrp explorers

[paullinator]

Should be an assert case if currency !== 'XRP' && issuer == null. Token check is just currency !== 'XRP'

[Jon-edge]

I'll add the assert, but we still need to keep the entire isTakerToken statement, or else makeTokenId right after complains

[paullinator]

This always get the amounts from the tx object. But in the case of a partial order fulfillment, the correct amounts are in the Nodes.

[Jon-edge]

We don't actually display the amounts from the GUI at this time.

This implementation is tracking 2 things consistently across all order states: the state of the order, and the posted order amount.

Fill amount is a completely separate thing and I think is a mistake to conflate into the source/destAsset amounts described here. We also don't differentiate full and partial fills in the GUI right now, either.

If we only track fill amount, we actually are mis-reporting later down the road when the order status changes. We won't have knowledge of that unless we go back and modify related transactions as we process newer transactions. Imo, fill amount should be a completely separate field.

At this point in time, the only thing we are certain of is the total amounts of the original offer. Even if we have a partial fill immediately upon posting, we don't know if a later tx from someone else further modified the fill amount.