Prediction markets are a weirdly clean sandbox for trading. Every contract is a yes/no question that pays $1 or $0, so a price of 37¢ is just the crowd saying "37% likely". If you think you know the probability better than the crowd, you have a trade. That framing pulled me in, and it's been my main side project for most of 2026.
v0: looking for free money
I started with a small backtester on Polymarket data and the most naive strategy possible: if the best YES ask plus the best NO ask is under $1, buy both and lock in the difference.
It never showed up. At the top of the book the market was efficient enough that this kind of arb basically didn't exist. Useful lesson early: there's no free money, so any edge has to come from actually modelling something better than the market does.
v1: an event-driven engine
I moved to Kalshi and rebuilt from scratch as three small services that talk through Redis:
exchange websocket
|
v
[ market data ] --> live order books in Redis
|
"book changed"
v
[ signals ] --> order requests
|
v
[ order mgmt ] --> risk checks --> exchange
- Market data holds an async websocket open to the exchange, keeps every order book live in Redis, and emits an event whenever a book changes.
- Signals is a pool of workers that only wake up for books that actually changed, run the strategies against them, and send order requests.
- Order management is the only thing allowed to touch real money. It runs risk checks, places orders, keeps a ledger, and reconciles against the exchange.
Today it tracks ~670 live markets with around 200ms average signal-processing latency, and I've benchmarked my models against market-implied probabilities on 1.3M historical trades.
Design rules that saved me
- Strategies are untrusted. They can ask for anything; the order manager decides what actually happens. Limits live in one place.
- Paper and live share one code path. Promoting a strategy means flipping a flag, not rewriting it, so what I tested is what runs.
- Fail safe, not fail open. Stale data means no trade. A broken dependency means conservative limits. There's a master kill switch.
- Keep it cheap. The whole thing runs on small hosted instances and a shared Redis. Hobby budgets force simple designs.
What I've learned so far
- The strategy is maybe 10% of the code. The other 90% is plumbing: reconnects, out-of-order updates, partial fills, and making sure my idea of my positions matches the exchange's.
- Markets are mostly well calibrated. Most ideas die quietly in the backtest, which is exactly where you want them to die.
- Writing a design doc for a side project felt like overkill until the third time it saved me from a bad change.
I'm keeping the actual strategies to myself for now, but happy to nerd out about the architecture. Reach out!