Oracle Engine

The Problem

Backtesting prediction market strategies requires realistic simulation of order execution, timing, and market impact. Most backtesting frameworks make assumptions that work for traditional markets but fail for prediction markets' unique characteristics: low liquidity, long settlement times, and binary outcomes.

Technical Approach

The system depends on Dome API for historical L2 order book snapshots on both Kalshi and Polymarket. Neither exchange exposes historical book data through their APIs - Dome provides this infrastructure.

I designed a clock abstraction that enables identical strategy code to run live or in backtest mode. The clock interface handles time progression, price updates, and order lifecycle uniformly regardless of execution context.

The system separates concerns cleanly:

• Exchange adapters normalize API responses from Kalshi, Polymarket, and future markets
• Dome client handles snapshot ingestion with rate limiting and pagination
• Strategy logic remains completely decoupled from execution mode

Interesting Challenges

The core challenge was designing a system where live and backtest share the same code path. The clock abstraction lets strategies subscribe to price updates and submit orders without knowing whether they're running against historical data or live markets. Flipping between modes is a config change, not a code change.

Getting the abstractions right took iteration. The exchange interface, the clock, the order lifecycle - each needed to be general enough to handle both contexts without leaking implementation details into strategy code.

What I'd Do Differently

The current architecture is synchronous. An event-driven approach with a message queue would better handle high-frequency updates from multiple exchanges simultaneously.