Rate limits shape what any P2P tool can tell you

We refresh rail tables for twenty fiat markets. The obvious optimisation is to fetch them in parallel — the work is almost entirely waiting on the network, so four at a time should be roughly four times faster.

We tried it. Within about five seconds, 19 of the 20 markets came back rate-limited. One survived.

Going back to one market at a time, all twenty succeeded, and the whole pass took roughly 110 seconds.

The constraint is real and it is not negotiable

Each market requires paging through its board, which is already a sequence of requests. Fetching four markets concurrently multiplies the request rate against a limit we were evidently already close to. There is no clever batching around it: the ceiling is requests per unit time, and every market needs a lot of requests to read completely.

So a tool covering many markets picks one of three positions:

1. **Refresh everything, slowly.** Complete, but each market is as stale as the length of the full cycle. 2. **Refresh a few markets often.** Fresh where it matters, absent everywhere else. 3. **Read each board shallowly.** Fast and broad, but a capped read discards the quiet rails first — the ones with the widest spreads.

Every multi-market P2P page has picked one of these. Most do not say which.

Why option three is the trap

Shallow reads are the tempting compromise because they look complete: every market present, everything current. But a board scan capped at a few pages returns the most competitive ads across all rails combined, and silently drops the rest. The rails it drops are disproportionately the thin ones — which is precisely where an uncontested spread would be.

A page built that way will show you a tight, crowded, accurate-looking market and never reveal that it stopped reading before the interesting part.

What we picked, and what it costs

We read boards fully, sequentially, and refresh on a fixed cycle rather than continuously. The cost is honest and worth stating: a rail table is as old as its timestamp, which we print on the page.

The live order book on each market page is a separate path — a direct connection from your browser, so it is genuinely current while you have the page open. Two different mechanisms, two different freshness guarantees, both labelled.

What to take from it

• Ask any P2P data source when it last read the market. If the answer is not on the page, assume it is older than you would like.
• "Real-time" across dozens of markets simultaneously is a claim worth doubting. The rate limits make it expensive, and something is usually being traded away to make it look true.
• Complete and current are in tension here. A tool that appears to give you both is probably reading shallowly, and a shallow read removes exactly the rails a maker is hunting for.