book_offers pagination does not return marker, making full order book traversal unreliable (Version: 2.2.x / 2.3.x)

[Platonenkov]

Summary

The book_offers method does not always return a marker, which makes it impossible to reliably iterate through the full order book using pagination.

Most XRPL methods support consistent pagination via the marker field, allowing clients to fetch all objects in multiple requests.

However, book_offers behaves differently and may return exactly limit objects without providing a marker, which prevents the client from continuing traversal.

Sample with 70 unfunded offers:

Motivation

DEX clients, wallets, trading bots, and analytics tools need to reliably load the full order book.

With the current behavior of book_offers, clients are forced to use large limits to avoid missing liquidity.

This becomes problematic because:

• The order book may contain many unfunded offers (owner_funds == 0 || taker_gets_funded == 0 )
• With a small limit, the client may receive only unfunded offers
• Without a marker, there is no reliable way to continue traversal
• This can result in incorrect liquidity display

In practice, this means a client may believe that liquidity is very low,
while actual funded offers exist deeper in the book.

This can also be abused by placing many unfunded offers at the top of the book,
causing UI clients to show incorrect liquidity unless they use very large limits.

Solution

Make book_offers pagination consistent with other XRPL methods.

Possible options:

1. Always return marker when the number of available offers is greater than the number returned
2. Guarantee that pagination can traverse the entire order book
3. Document the exact pagination behavior of book_offers if the current behavior is intentional

The goal is to allow clients to reliably iterate through the order book without needing very large limits.

Paths Not Taken

Possible workarounds include:

• Using very large limits
• Running a private node with increased limits
• Filtering unfunded offers client-side

However, these do not solve the core issue:

Pagination should allow reliable traversal of the order book regardless of server limits,
and clients should not need to depend on large limits to get correct results.