Trading platform

Strategies that have to
prove themselves.

Prediction-market infrastructure for desks that want a number before they want a narrative. Nothing reaches your capital until it has been replayed against recorded order books and scored against a benchmark chosen in advance.

What the platform does

Six things, none of them optional.

A trading system is a chain of places to be wrong. Each of these closes one of them.

Compliance at the gate

Jurisdiction is checked before an order is signed, not after it fills. The venue's registration and the account's jurisdiction both have to pass, and a refusal is written to the same append-only ledger as a fill. You can show a regulator what the system declined and why.

Benchmarks, defined up front

A return means nothing on its own. Every strategy is scored against buy-and-hold on the underlying, the venue's own resolution rate, and a null policy run over identical windows. The comparison is chosen before the run, not after the result.

Positions you can actually read

Mark-to-bid unrealised P&L, settlement reconciled against on-chain redemptions, and expiries booked at the real verdict rather than at worst case. A console that reads green while the wallet drains is worse than one that is visibly broken.

Copy, then tweak

Start from a strategy we have already validated. Change the parameters and the platform re-runs the backtest against the same benchmarks before the tweak is allowed to trade. You cannot promote a change you have not measured.

Backtests that use real books

Replay runs against recorded order books — both sides, full depth, second by second — not against a reconstruction. Point-in-time is enforced by the platform, so a strategy cannot accidentally read the future.

Kill switches that have been used

Drawdown limits, pre-order balance gates, redemption caps and per-engine pause, resume and restart. These exist because each one was added the day after it was needed.

Why the backtests mean something

We kept the order books.

Live logs can never answer how a parameter affects performance — a bot only records the trades it took, so every rejection is invisible and the sample is far too small. So we archive the book instead, and replay the whole decision surface offline.

113
days of recorded books
31k
resolved windows per market
1 Hz
both sides, full depth
10⁴
windows replayed per config

Each tick carries best bid and ask with sizes, full depth on both sides, modelled slippage at trade size, and the largest fill available at the ask. A replayed strategy pays the spread it would actually have paid.

How we work with you

Four things, and you can take any of them.

Infrastructure

Order book recording, the replay corpus, execution hosts and the deployment around them. Run it in our account or your own.

Software

The console, the API, the replay harness and the strategy catalogue. Self-hosted or managed.

Consulting

Strategy design, parameter studies and the read on whether an edge is real or an artefact of the sample.

Support

Incident response for live engines, and the post-mortems that turn an expensive afternoon into a permanent gate.

Bring a strategy. We'll tell you if it's real.

The first thing we do on any engagement is replay what you already run. Sometimes the edge holds. Sometimes it was the sample. Either answer is worth having early.