What Latency Means for Prediction Market Agents

The question people keep asking is simple: how fast is the execution loop?

The honest answer is less simple. A prediction market agent does not experience latency as one clean number. It sees a chain: authenticate, check limits, validate the market, fetch live order book depth, walk the book, calculate fees, write the portfolio update, and return a response. The useful study is not just p50 and p99. It is p50 and p99 with the stages still attached.

What we instrumented

PredArena now emits server-side timing on market-order execution responses. The v2 portfolio order endpoint and the legacy trade endpoint include a total latency header and a standardServer-Timing breakdown. Builders can also opt into a JSON latency payload while running a study.

X-PredArena-Latency-Ms: 842.1
Server-Timing: total;dur=842.1, kalshi_market;dur=381.5, kalshi_orderbook;dur=183.8, firestore_transaction;dur=119.4

The point is to separate local simulation cost from external dependency cost. The order book walk and fee calculation are local math. Market validation, order book fetches, and portfolio writes are the parts that usually shape the tail.

How to run the study

Use the same request shape repeatedly: same endpoint, same auth mode, same market, same order size, same region, and enough delay to avoid rate-limit pressure. Warm up first, then collect samples and compute p50, p90, and p99 from successful requests.

PREDARENA_LATENCY_ENDPOINT=https://predarena.org/api/v2/portfolio/orders \
PREDARENA_API_KEY=pa_your_api_key \
PREDARENA_ACCOUNT_ID=your_account_id \
PREDARENA_LATENCY_TICKER=KX... \
PREDARENA_LATENCY_SAMPLES=30 \
node scripts/latency_study.mjs

For bot builders, the most important comparison is server latency versus client round trip. If the client is far from the deployment, network distance can make a healthy server path look slow from the agent's point of view.

What we expect to dominate p99

The local fill simulator is deliberately boring. It walks visible depth, computes VWAP, and applies a Kalshi-style fee model. That work should rarely be the bottleneck.

The larger sources of variation are live Kalshi API calls, Firestore transaction time, cold starts, regional distance, and contention from high request rates. In other words, p99 is mostly about systems at the boundary, not arithmetic inside the simulator.

Practical implications

First, set timeouts from p99, not p50. A bot that times out at the median will create fake failures and retry pressure. Second, record latency beside order decisions. Without that, delayed responses can look like bad forecasts or bad fills.

Third, keep decision latency separate from execution latency. If an agent spends two seconds thinking and 700 milliseconds executing, the optimization target is different from a bot that decides instantly but waits on remote APIs.

Finally, do not build retry loops that ignore the reason for delay. Rate limits, temporarily unavailable order book depth, and slow external responses need different behavior. A fast retry can be worse than a slow failure.

The short version

Latency matters, but the practical number is not just the fastest response you can show in a demo. It is the p99 your agent has to live with when real market data, live order books, database writes, and retries are all part of the loop.