How to Determine Which Order Books Are Affected in an XRPL Payment Transaction?

Question

Based on the reference docs, it seems like there are a few different ways that a Payment txn could be defined which would specify using a path through the Dex:

1. Different input currency and output currency, using default path:

• SendMax field is defined (input currency)
• Amount (or DeliverMax, depending on API version) field is defined (output currency)
• tfNoDirectRipple flag NOT SET This cross-currency payment will use the default path through the order book

2. Different input currency and output currency, using specified path:

• SendMax field is defined (input currency)
• Amount (or DeliverMax, depending on API version) field is defined (output currency)
• tfNoDirectRipple flag SET
• Paths field provided, indicating steps through the order book or AMM to take This cross-currency payment will use the path specified in Paths (will this tx fail if Paths is not provided?)

3. Same input currency and output currency, using specified path:

• SendMax field is defined (input currency)
• Amount (or DeliverMax, depending on API version) field is defined (output currency)
• tfNoDirectRipple flag SET
• Paths field provided, indicating steps through the order book or AMM to take This same-currency payment will use the path specified in Paths, which may or may not include steps through the order book or AMM

Confirmation of the above scenarios where a Payment txn may use a path through the Dex Order Book is the first part of my question. Are those valid scenarios? Am I missing other scenarios?

I've seen an example on Youtube where a trader is only filtering OfferCreate txns and txns with the Paths field defined, to track changes to order books in the Dex. But it seems like scenario #1 above will impact the Dex order book, and does not need to have the Paths field defined.

When I say 'defined' I mean a non-empty array.

The next part of my question is:

Is there an easy way (or just an established way) to determine which Order Books in the Dex that a Payment rippled (is that the right term?) through, by decoding the AffectedNodes in the tx meta?

Haven't tried anything yet. Just trying to understand the theory correctly, and then come up with a solution.

Answer 1

The documentation enumerates 6 possible categories of a Payment transaction. Source: https://xrpl.org/docs/concepts/tokens/fungible-tokens/paths#default-paths

Category-1 in your question could either flow through an OrderBook (or) AMM (or) through a direct trustline between the sender and the receiver. The above docs page does a great job of filling out all the possibilities.

The second part of your question is not related to the first half. Irrespective of whether you specify explicit paths for your Payment transaction (or) you set/unset the tfNoDirectRipple flag, the transaction meta-data should help you inspect the affected Offer objects.

Here is a python snippet (Uses the xrpl-py SDK) to inspect the modified Offer Objects:

"""Inspecting the Offers consumed in the blockchain"""

from xrpl.clients import JsonRpcClient
from xrpl.models import Ledger, Tx

# References
# - https://xrpl.org/look-up-transaction-results.html
# - https://xrpl.org/tx.html

# Note: This end-point might rate-limit users
client = JsonRpcClient("https://xrplcluster.com/")

# Create a Ledger request and have the client call it
ledger_request = Ledger(ledger_index="validated", transactions=True)
ledger_response = client.request(ledger_request)
print(ledger_response)

# Extract out transactions from the ledger response
transactions = ledger_response.result["ledger"]["transactions"]

# If you have a specific transaction hash, use it to fetch the relevant Transaction
# meta-data
for i in transactions:
    tx_response = client.request(Tx(transaction=i))
    # Important resource -- Format of transaction meta-data:
    # https://xrpl.org/docs/references/protocol/transactions/metadata
    for j in tx_response.result["meta"]["AffectedNodes"]:

        # Skip freshly-created Offers
        if "CreatedNode" in j:
            continue

        # partially-consumed offers
        if "ModifiedNode" in j and j["ModifiedNode"]["LedgerEntryType"] == "Offer":
            # TODO: further process the modified Offer object
            print(j["ModifiedNode"])

        # fully consumed offers
        if "DeletedNode" in j and j["DeletedNode"]["LedgerEntryType"] == "Offer":
            # TODO: further process the modified Offer object
            print(j["DeletedNode"])

This snippet will display all the transactions which consume any Offer object. Here are some of the affected Offer objects from the Ledger: 'ledger_hash': 'BC10B4C8C41918E27DFB9984BC417C67F5094364CCA7CF3B31E1B52674C21504', 'ledger_index': 90322232

{'FinalFields': {'Account': 'rD7YHBERNR5YzpmUpDv9xGCwQqPBmpYycn', 'BookDirectory': '28E42723CB1A79C4D79CCF5834F9F0F7E80E08D9B9C39D035908617F7C07B28E', 'BookNode': '0', 'Flags': 0, 'OwnerNode': '0', 'PreviousTxnID': 'AD6510A82DC9DE3A92E0BFD4965F0DB0F3BE2633244A1D5E7F81133342696959', 'PreviousTxnLgrSeq': 90322216, 'Sequence': 71359160, 'TakerGets': {'currency': '457175696C69627269756D000000000000000000', 'issuer': 'rpakCr61Q92abPXJnVboKENmpKssWyHpwu', 'value': '2331.496413278295'}, 'TakerPays': '55000000'}, 'LedgerEntryType': 'Offer', 'LedgerIndex': '5041B1CCC0DE66DBA1AF3147785117815BA5EF8803068826CF4B6F71202E4332'}
{'FinalFields': {'Account': 'rsTcD684mhKPBUNq9afrfTttjy9vjvSZHq', 'BookDirectory': '28E42723CB1A79C4D79CCF5834F9F0F7E80E08D9B9C39D035908248FD5D34000', 'BookNode': '0', 'Flags': 65536, 'OwnerNode': '1c', 'PreviousTxnID': 'B5F7F1237B0E67F77B7A13CD47158F7FC5BAAB2B54F20D76E46B51078BC4C177', 'PreviousTxnLgrSeq': 90322216, 'Sequence': 90098842, 'TakerGets': {'currency': '457175696C69627269756D000000000000000000', 'issuer': 'rpakCr61Q92abPXJnVboKENmpKssWyHpwu', 'value': '1836.3'}, 'TakerPays': '42087996'}, 'LedgerEntryType': 'Offer', 'LedgerIndex': 'B87D7A778E52EC9E9E52BB0DD058CF3E896DAB2B3E674D54BEB36DB26CA015AB'}
{'FinalFields': {'Account': 'rsTcD684mhKPBUNq9afrfTttjy9vjvSZHq', 'BookDirectory': '28E42723CB1A79C4D79CCF5834F9F0F7E80E08D9B9C39D0359080E01A153EA04', 'BookNode': '0', 'Flags': 65536, 'OwnerNode': '1c', 'PreviousTxnID': '1DC9B6A57B56E5DAC41448A2720F1A136F7A6C737383D7741250D9279D3EC495', 'PreviousTxnLgrSeq': 90322216, 'Sequence': 90098841, 'TakerGets': {'currency': '457175696C69627269756D000000000000000000', 'issuer': 'rpakCr61Q92abPXJnVboKENmpKssWyHpwu', 'value': '1824.2'}, 'TakerPays': '41358262'}, 'LedgerEntryType': 'Offer', 'LedgerIndex': '3DB55DA0E5AF9183B423880E30310D1BBD39E87A86F71561EC0E9A6FADDE5957'}

Furthermore, you can use the subscribe RPC command (https://xrpl.org/docs/references/http-websocket-apis/public-api-methods/subscription-methods/subscribe) to obtain real-time changes to Offer Ledger objects. It provides lower latency than JSON-RPC commands.