Prediction markets trade like casinos, not exchanges.
Tens of billions in volume are moving through venues where stop-losses slip, cross-venue deltas sit unexploited, and APIs are treated as gospel instead of raw material.
APIs are treated as products instead of raw material.
Most tools sit on top of venue APIs and call it a platform. Historical data is shallow, schemas are inconsistent, and routing logic is bolted onto someone else's latency.
Treat ingest, schema, and routing as core infra.Stop-losses slip 20¢ and nobody can prove why.
Retail-size orders get treated like noise. Venue-side logic is opaque. You can see the prints, but you can't isolate where execution broke, or rerun the tape against a different routing policy.
Make slippage measurable and fixable.Cross-venue arb is visible but not executable.
You can see Kalshi vs. Polymarket deltas on a dashboard. You can't hit both legs atomically from one routing engine, with real risk controls instead of Discord bots and manual clicks.
Turn mispricing into fills, not screenshots.Architecture:
Kessel in four layers.
Early access focuses on Polymarket and Kalshi with live websocket ingest, a shared market schema, and server-side routing experiments.
Direct venue ingest
Persistent websocket connections to prediction venues. Idempotent event processing and replayable streams instead of polling brittle REST endpoints.
Own the firehose, not just the screenshots.Canonical market schema
Venue-specific chaos mapped into one clean model: price, liquidity, resolution rules, fee model, and depth structure stored in columnar formats.
One schema across venues, assets, and time.Server-side execution engine
Routing logic runs next to the data: true take-profit and stop-loss, portfolio-aware exits, and venue selection that can be benchmarked, not guessed.
Execution as code, not UI switches.Cross-venue engine
Detects mispricing between venues and executes both legs from a single call, with atomic semantics instead of best-effort bots.
One-click arb across markets.Latency + fill benchmarking
Benchmark against Telegram bots and native UIs. Measure where fills slip and where routing choices win so execution quality compounds over time.
Execution quality as a measurable edge.Infrastructure first, interfaces second
The terminal is intentionally thin. The real product is the normalized data and routing API you plug into your own terminals, bots, and research stack.
Build your own surfaces on top of the same engine.How Kessel compounds your execution edge.
Start with live ingest
Turn on 24/7 venue ingest with replayable streams and a published schema. Get to clean, queryable data before you worry about UI.
Measure execution quality
Route real size through the engine. Compare slippage against your existing bots and native UIs so you can quantify where Kessel helps.
Prove it with a minimal terminal
Use the thin terminal to inspect routes, fills, and failure modes. It exists to show what the infra can do, not to replace your front end.
Scale and monetize the primitive
Expose the engine to more flow with a clear API and fee-sharing on execution quality, so funds, traders, and terminals can plug in without rebuilding the stack.
Access designed for traders and builders, not SaaS seats.
Start with early access to live ingest and routing experiments. Scale into deeper integrations and fee share once Kessel is in your execution loop.
Early Access
For traders and teams who want to wire Kessel into their stack and start benchmarking execution quality.
- Direct websocket ingest for Polymarket and Kalshi
- Normalized markets and orderbooks exposed over one API
- Baseline cross-venue routing policies you can benchmark
- Access to latency and fill quality dashboards
- Discord or Telegram access to the core team during integration
Project-based engagement with clear technical scope.
Pricing based on venues, volume, and support.
Partners
For funds, desks, and terminals that want Kessel as a core execution primitive.
- Custom routing policies tuned to your strategies and risk
- Dedicated infrastructure for higher throughput and stricter SLAs
- Deeper venue coverage and faster integration of new markets
- Joint experiments on latency and execution quality improvements
- Revenue share on routed volume instead of seat-based pricing
Structured around routed volume, venue coverage, and the level of joint roadmap work.
Multi-year partnerships preferred.