Trading platform
Strategies that have to
prove themselves.
Prediction-market infrastructure for desks that want a number before they want a narrative. We run LEAN underneath and model the part LEAN does not: contracts that resolve. Nothing reaches your capital until it has been replayed against recorded order books and scored against a benchmark chosen in advance.
LEAN runtime · Polymarket + Kalshi · 113 days of recorded books · every refusal on the record
Architecture
The engine is settled.
The layer above it is the product.
LEAN is a good engine, and we run it. It brings an API that quants already know, parameter optimisation as a real screen, and point-in-time history — for instruments that trade. It has no model for a contract that resolves to 0 or 1. That part is ours, and it is where the money is won or lost.
LEAN is Apache-2.0 and runs on your own hardware. Nothing in the layers above it is locked to a vendor, and the venue trait means a second exchange is an adapter, not a rewrite.
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. A refusal is written to the same append-only ledger as a fill, so you can show a regulator what the system declined and why.
Benchmarks, fixed 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 over identical windows. The comparison is chosen before the run, not after the result.
Positions you can 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 scored. Change the parameters and the platform re-runs the sweep against the same benchmarks before the tweak is allowed to trade. You cannot promote a change you have not measured.
Backtests on 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 read the future by accident.
Kill switches that have been used
Drawdown limits, pre-order balance gates, redemption caps, and per-engine pause, resume and restart. Each one exists because it 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 records only the trades it took, so every rejection is invisible and the sample is far too small. We archive the book instead, and replay the whole decision surface offline.
Five markets — BTC, ETH, SOL, XRP and BNB — about 4 GB. Every tick carries what the book actually showed, so a replayed strategy pays the spread it would actually have paid.
Benchmarks
A return means nothing on its own.
Every strategy is scored against three references, and the comparison is registered before the run. You cannot pick the flattering one afterwards.
Buy and hold the underlying
Same windows, same capital, no trading. The floor any signal has to clear.
The venue's own resolution rate
What the market already told you. Beating the book is the only edge that pays.
A null policy
The same gates with the edge switched off. Separates the strategy from the plumbing.
Sweeps report paired confidence intervals across identical windows. A number without an interval is a story.
Catalogue
Copy a strategy. Then make it yours.
- 01
Take a strategy from the catalogue, with the scorecard it earned.
- 02
Fork it and change the parameters that matter to you.
- 03
The platform re-runs the sweep on the corpus. No promotion without a scorecard.
- 04
It goes live with attribution in the signed order, so the author earns from every copy at the venue.
Before every entry the server re-quotes the book. A price that drifted or a book that collapsed is refused, and the refusal is recorded next to the fills. Skips are first-class here — they are how the latency reality stays visible.
Compliance
Jurisdiction is a gate, not a footnote.
Polymarket US now operates as a CFTC-regulated designated contract market, and roughly eleven states restrict it. That is a routing problem, and routing is something a platform can do properly: know the customer's jurisdiction, know the venue's registration, refuse at the gate, and write the refusal to the ledger next to the fills.
We will not help you route around a restriction. The gate exists to hold.
Shape of a real entry. Refusals and fills share one record.
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.
Engagement tiers
The corpus and the replay harness. One seat.
Live engines, catalogue, benchmarks. Managed.
Multi-venue, your gates, your ledger.
Your hardware, your keys, our support.
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.