MarketEdge
Prediction-market divergence engine
Stack
- Python
- FastAPI
- PostgreSQL
- Prefect
- httpx
- Docker
01
The problem
Kalshi and traditional sportsbooks price the same real-world events through completely different mechanisms. Kalshi is an exchange where traders set the price; a sportsbook sets a line and manages its own exposure. When those two prices disagree, the disagreement is information.
Nearly every tool in this space is built to tell you what to bet. That framing is convenient, because a tool that only makes claims never has to be right — no prediction is ever checked against what actually happened.
02
The approach
MarketEdge is deliberately not a pick-winners bot. It is an independent auditor: it observes both sides, reports where they diverge, and then holds itself accountable for whether its own confidence was justified.
The honesty-first part is the calibration grading. When the engine says an event is 70% likely, roughly 70% of those calls should come in. Tracking that over time turns the tool from something that makes assertions into something with a measurable track record — including a measurably bad one, if that is what the data shows.
This inverts the usual incentive. Most systems are optimized to look confident; this one is optimized to be checkable.
03
Architecture
- Prefect for scheduled collection
- Odds and market prices are only meaningful as a time series, so ingestion has to run on a reliable schedule with retries and visible failures. A cron job that silently dies leaves gaps that corrupt every downstream calibration number.
- httpx against two very different sources
- An exchange API and sportsbook odds have different shapes, rate limits, and failure modes. Both get normalized into one internal representation before anything is compared.
- PostgreSQL as an append-only history
- Calibration scoring depends on knowing what was believed at the time, not just the current state. Prices are appended rather than overwritten, so past claims stay auditable after the outcome is known.
- FastAPI read layer
- Serves current divergences and historical calibration, keeping the query surface separate from the ingestion pipeline.
- Docker
- Pins the pipeline, scheduler, and database together so a scheduled run behaves identically in development and deployment.