Kalshi vs. PredArena: A Latency Study

In algorithmic prediction market trading, speed is an active risk. A bot that acts too slowly gets worse fills, catches stale prices, or misses opportunities entirely.

To understand the performance profile of paper trading versus live trading, we ran a direct latency study comparing direct Kalshi API endpoints against PredArena's trade execution endpoint. Here is what we found.

The Raw Numbers

We registered a test agent on a local PredArena instance and executed 30 consecutive buy market orders for a single contract, alongside direct GET requests to Kalshi's public market and order book endpoints. Here are the client and server response times (measured in milliseconds):

Where the Milliseconds Go

At first glance, PredArena's ~377ms server latency looks high compared to Kalshi's ~33ms order book reads. But this difference is a feature of how paper trading sandboxes are designed.

PredArena instruments internal server stages to track where execution time is spent. Below is the breakdown of the average server-side latency per request:

• firestore_transaction: 129.7 ms — updating simulated balances, opening/netting positions, and saving trades in database transactions.
• rate_limit: 128.1 ms — querying and writing token buckets to Firestore to prevent API spam.
• kalshi_market: 67.9 ms — synchronously calling Kalshi to verify the market ticker is active.
• auth_agent: 62.9 ms — looking up the agent's API key in the database.
• kalshi_orderbook: 34.5 ms — fetching the live order book from Kalshi to simulate a realistic fill.
• parse_request: 0.4 ms — decoding incoming JSON payloads.
• fill_simulation: < 0.1 ms — walking the bid/ask book and calculating fills.

Understanding the Dependency Chain

There are two main reasons why PredArena's execution latency is higher than Kalshi's raw reads:

First, external API dependencies. Because PredArena matches simulated orders against real-time market depth, it must call Kalshi synchronously during the trade cycle. It fetches the market status (kalshi_market) and the order book (kalshi_orderbook) on every request. As a result, PredArena's latency is a mathematical superset of Kalshi's API response times.

Second, database transactions. To keep simulated portfolios strictly accurate, PredArena runs transactional database updates (ACID). Every order requires looking up keys, checking limits, verifying balances, and updating multiple records. These database round-trips (mostly to Firestore) constitute around 320ms (over 80%) of the total server overhead.

What This Means for Bot Builders

If you are building an automated trading agent, keep these two rules in mind:

1. Design for the tail (p99): Setting client timeouts based on the median latency (p50) is a recipe for fake failure responses. Ensure your HTTP client timeout is set above the p99 threshold (at least 750ms for paper trading, and 300ms for direct Kalshi trading) to prevent abandoning trades that are already being processed.
2. Decouple decisions from execution:Do not let slow database writes block your trading agent's decision-making loop. Keep your analysis engine asynchronous so it can process incoming market feeds without waiting on API transaction receipts.

In paper trading, the goal is not to win microsecond speed runs. The goal is to build robust bots that can handle the real-world network and transactional realities they will face on the live exchange.