Kalshi Backtester

A research and execution framework for systematic strategies on Kalshi event contracts: rules-based signals run across a universe of recurring markets, evaluated statistically, combined into a portfolio, and executed with realistic costs. It is built correctness first, because the failure that matters in a backtester isn't a crash. It's a number that looks right and isn't.

Architecture

Order book & fill modeling

For resting orders, the engine replays each taker order's prints through the recorded book plus our own orders, in price order. Volume that printed at a level was resting before us, so it fills first. Our order fills only if the taker clearly went through it. Step through it:

There are two execution paths. A bar engine models latency in bars, caps size at a fraction of each bar's volume, and fills limit orders only on trade-through. The L2 tape replay above is queue-aware and pessimistic. Both share one fee model, charged per fill and rounded up to the cent, with maker fees looked up per series. A parity test holds the live engine's replay to the research backtest: the same order intents, and P&L within 1%.

Not fooling yourself

• Lookahead tests: settlement and future bars are unreachable from signal code, and future external data can't change past outputs.
• Synthetic recovery: on data with a known generating process, the engine books exactly the P&L that process implies.
• Walk-forward evaluation, candidates registered before they are run, and a holdout spent once with its pass rule fixed in advance.

Known limitations

• No adverse-selection model: a passive order fills whenever price trades through it, which flatters passive strategies. Maker fees are charged in full partly for that reason.
• In the bar engine, queue position is a blunt proxy (a strict trade-through), not a model.
• Public prints include block and crossed volume that a small order could not have taken.

Status

A small set of alphas is in paper trading on the live feed. Strategy details aren't public.