VODF-172 - Add Batch transaction integration considerations

Update AI config on site

docs/concepts/transactions/batch-transactions.md

@@ -168,3 +168,40 @@ If Alice just signs her part of the Batch transaction, Bob can modify his transa
 An inner batch transaction is a special case. It doesn't include a signature or a fee (since those are both included in the outer transaction). Therefore, they must be handled carefully to ensure that someone can't somehow directly submit an inner `Batch` transaction without it being included in an outer transaction.
 
 Inner transactions cannot be broadcast (and won't be accepted if they happen to be broadcast, for example, from a malicious node). They must be generated from the `Batch` outer transaction instead. Inner transactions cannot be directly submitted via the submit RPC.
+
+## Integration Considerations
+
+`Batch` transactions have some unique integration considerations:
+
+- Since the outer transaction returns `tesSUCCESS` even when inner transactions fail (see [Metadata](#metadata)), you must check each inner transaction's metadata and result codes to determine its actual outcome.
+- If inner transactions are validated, they are included in the same ledger as the outer transaction. If an inner transaction appears in a different ledger, it is likely a fraud attempt.
+- Systems that don't specifically handle `Batch` transactions should be able to support them without any changes, since each inner transaction is a valid transaction on its own. All inner transactions that have a `tes` (success) or `tec` result code are accessible via standard transaction-fetching mechanisms such as [`tx`](/docs/references/http-websocket-apis/public-api-methods/transaction-methods/tx.md) and [`account_tx`](/docs/references/http-websocket-apis/public-api-methods/account-methods/account_tx.md).
+- In a multi-account `Batch` transaction, only the inner transactions and batch mode flags are signed by all parties. This means the submitter of the outer transaction can adjust the sequence number and fee of the outer transaction as needed, without coordinating with the other parties.
+
+The following sections cover additional recommendations for specific types of integrations.
+
+### Client Libraries
+
+Client libraries that implement `Batch` transaction support should:
+
+- Provide a helper method to calculate the fee for a `Batch` transaction, since the fee includes the sum of all inner transaction fees. See [XRPL Batch Transaction Fees](#xrpl-batch-transaction-fees).
+- Provide a helper method to construct and sign multi-account `Batch` transactions, where one party signs the outer transaction and the other parties sign the inner transactions.
+- Provide an auto-fill method that sets each inner transaction's `Fee` to `"0"` and the `SigningPubKey` to an empty string (`""`), while omitting the `TxnSignature` field.
+
+### Wallets
+
+Wallets that display or sign `Batch` transactions should:
+
+- Clearly display all inner transactions to users before requesting a signature, so users understand the full scope of what they are approving.
+- For multi-account `Batch` transactions, provide a workflow for users to review and sign their portion of the batch, then export it for other parties to sign.
+- Warn users if they are signing a `Batch` transaction that includes inner transactions from other accounts, since they are approving the entire batch.
+- Display the batch mode (`ALLORNOTHING`, `ONLYONE`, `UNTILFAILURE`, `INDEPENDENT`) and explain its implications.
+- Avoid auto-incrementing sequence numbers after successes or failures, since the number of validated transactions depends on the batch mode and which inner transactions succeed.
+
+### Explorers and Indexers
+
+Explorers and indexers that display `Batch` transactions should:
+
+- Display the relationship between outer `Batch` transactions and their inner transactions using the `ParentBatchID` field in the inner transaction metadata.
+- Show inner transactions in context with their parent `Batch` transaction, rather than as standalone transactions.
+- Consider grouping inner transactions with their outer transaction in transaction lists for clarity.

redocly.yaml

@@ -28,10 +28,18 @@ responseHeaders:
       value: noindex
 search:
   engine: typesense
-  ai:
-    hide: true
   filters:
     hide: true
+aiAssistant:
+  hide: false
+mcp:
+  hide: false
+  docs:
+    hide: false
+    name: "xrpl.org MCP server"
+    ignore:
+      - ja/**
+      - es-es/**
 metadataGlobs:
   'docs/**':
     redocly_category: Documentation