Simulation vs. Reality

Every known way PredArena fills differ from real trading — what we model, what we approximate, and the data we record so you can measure the gap.

PredArena fills are not the same as real-money venue execution, and any model that hides that fact will quietly inflate your backtest. This page is the complete, honest list of divergences in PredArena's fill model. For each one: what really happens, what we model, the direction of the bias, and the data we record so you can quantify it on YOUR fills rather than trusting our word.

1. No market impact

Reality: your order consumes liquidity — after you lift 500 contracts off the asks, the next 500 cost more, and other participants react to your prints. PredArena: the book is untouched; two back-to-back orders both see the original depth. Bias: optimistic, growing with order size relative to book depth. Measure it: compare your intended size against the fills legs and book depth from GET /api/markets/orderbook; if your size routinely exceeds the top few levels, real impact would be material.

2. Fills assume the snapshot book

Reality: between deciding to trade and matching, the book moves; fast markets move it a lot. PredArena: we fetch the book and fill against that snapshot instantly — there is no in-flight requote, no race with other takers. Bias: optimistic in fast markets, neutral in quiet ones. Measure it: every order records mid_price_at_execution, slippage_per_contract, and slippage_cost; the analytics endpoint buckets slippage by order size. If you go live, compare your real fill slippage against the PredArena distribution.

3. Displayed depth only, all-or-nothing markets

Reality: real market orders can part-fill, and hidden liquidity (or liquidity that refreshes as you trade) can fill more than the displayed book suggests. PredArena: market orders fill only against displayed levels (Kalshi books are fetched at depth 20) and are rejected outright if displayed depth cannot absorb the full size. Bias: pessimistic on fillable size, optimistic on certainty (you never manage a part-filled market order). Mitigation: use limit orders with IOC for realistic partial-fill semantics.

4. Resting (maker) fills: no queue position

Reality: a resting limit order fills only after every order ahead of it at that price trades — queue position is often the whole game for maker strategies. PredArena: your resting order fills at YOUR limit price when the displayed opposite side crosses it, for the displayed crossed quantity. We cannot observe Kalshi's or Polymarket's queues, so we do not pretend to model them.

• Optimistic: you effectively hold front-of-queue priority — real maker fill rates are lower.
• Pessimistic: fills never price-improve past your limit, even when the book crosses through it.
• Time-quantized: the matching loop runs about once a minute, so a price that wicks through your limit between evaluations can fill you (or be missed) differently than a real-time book would.

Measure it: maker fills are flagged liquidity_role: maker with a resting_order_id link; if you go live, compare your real maker fill rate per (market, distance-from-mid) against the PredArena rate. Expect the PredArena rate to be higher.

5. Stop / take-profit triggers: polling, not ticks

Reality: venue-native or bot-managed stops react within seconds and still suffer gap risk past the trigger. PredArena: triggers are evaluated against displayed best bids on the same ~once-a-minute loop, then execute as taker market sells against the current book — so you get realistic gap-through-the-trigger fills, but with coarser timing than a live stop. Bias: both directions; worse for strategies that rely on tight stops in fast markets. The triggered execution records its slippage like any other order, so you can see exactly what each stop cost past its trigger price.

6. Fees: exact where the venue publishes, explicit where it does not

• Kalshi taker fees: exact formula with per-series/event multipliers, fee waivers, and ceil-to-cent rounding (sources on the Fees page).
• Kalshi maker fees: treated as $0. Kalshi charges makers only on designated series (0.0175 multiplier there) and does not reliably expose the designation via API — maker-heavy strategies on those series will pay more in reality. Each maker fill is labeled maker_default_zero so you cannot miss the assumption.
• Polymarket: verified category-based taker schedule via each market's own feeSchedule; makers free. The CLOB's misleading flat taker_base_fee field is deliberately not used as a rate.

7. Settlement timing and cash mechanics

Reality: settlement can lag market close (Kalshi expiration vs. settlement review; Polymarket UMA disputes can take days), and proceeds are not always instantly tradable. PredArena: a resolution loop observes venue settlement and credits $1 per winning contract when the venue's data reports a result; between checks, open positions are marked to the venue's last observed prices. Closing a position credits cash instantly. Bias: slightly optimistic on capital velocity.

8. Capital realism

• Resting buys hold worst-case cash (price + max taker fee) so a portfolio can never spend the same dollar twice — mirrors real buying-power holds.
• Resting limit sells hold contracts (reservedContracts); conditional stops/take-profits intentionally do not, matching common brokerage behavior.
• No margin, no borrowing, no portfolio haircuts — Kalshi and Polymarket are fully-collateralized venues, so this matches reality.
• Account balance caps are tier limits, not venue rules.

9. Polymarket-specific approximations

• Whole contracts only (the venue allows fractional shares).
• Neg-risk cross-market NO conversions are not modeled — multi-outcome arbitrage strategies will understate achievable P&L.
• 1 USDC is treated as exactly $1; on-chain gas/allowance mechanics of real Polymarket trading do not exist here.
• Marks between resolutions use the venue's last price rather than executable bids.

10. And versus Kalshi's official demo?

Kalshi's demo environment is the venue's own sandbox: perfect for integration-testing API code, but it is a SEPARATE environment with its own books — not production market data — and it provides no fee receipts, slippage capture, or analytics. PredArena inverts the trade-off: PredArena execution, real production orderbooks. Use the demo to test your plumbing; use PredArena to test your strategy. (And when you go live, start small: the gaps above are real.)

11. Latency transparency

Order placement latency is dominated by the round-trip to the venue's API for the live book. Every response carries Server-Timing and X-PredArena-Latency-Ms headers with a per-stage breakdown (auth, rate-limit, venue market fetch, venue orderbook fetch, fill model, persistence); append ?latency=1 to get the same data in the response body. Measure your own p50/p99 from your region — do not take our word for it.