The Crypto Backtesting Platform That Deploys What It Tested
Research infrastructure for testing strategies on historical market data — including walk-forward and robustness analysis — and deploying them through the same APIs. Standalone backtesters end at a chart; this one ends at a running strategy.
Get API Access
Everything a Quant Team Builds Before It Can Test Anything
Data collection, a replay engine, out-of-sample machinery, sweep compute, versioning and a deployment path. Six things every research team ends up building. All six ship with the platform.
Historical market data
Trades, candles and order book snapshots per venue and instrument, alongside the reference data that determines what a fill actually costs.
Event-driven backtest engine
Strategies replay bar by bar or trade by trade, with taker fees, funding and modelled slippage charged on every simulated fill.
Walk-forward analysis
Parameters are fitted on one window and tested on the next window the strategy has never seen, rolling forward across the sample.
Robustness analysis
Parameter sweeps, cost and slippage stress, regime splits, trade-count sufficiency and a look-ahead audit.
Reproducible runs
Every run is pinned to a dataset version, a strategy version, a cost model and a seed. A result nobody can reproduce cannot be promoted to a deployment.
Strategy APIs and test environment
REST and WebSocket endpoints for data, backtests, sweeps, deployments and live fills, with scoped keys and an isolated test environment.
Data, Research, Testing, Deployment — One Stack
Most quant teams stitch these four layers together from separate vendors, then spend the year discovering where the seams leak. Here they are one system with one schema and one API surface.
Data
Trades, candles and order book snapshots recorded by the exchange stack itself, plus fee tiers, funding and instrument reference data. The live feed uses the same schema the backtest reads, so a strategy does not meet a different data shape on its first day in production.
How a Hypothesis Becomes a Running Strategy
Four layers, one data schema, one API surface, and a closed loop: what the strategy does in production becomes evidence for the next run.
Where the Work Actually Happens
Everything in the console is available through the API and the other way round. Teams that live in code never open it; teams that want a review surface get one for free.
Pin the dataset and the cost model
A backtest is an argument about the past, and an argument is only as good as its assumptions. Before a run starts, the console asks you to name every one: the venues and instruments in scope, the cost model and the data version.
- Venue and instrument universe, with book snapshots where the venue records them
- Fee tiers and funding drawn from reference data, not typed in by hand
- Fixed-spread, book-walk or impact-curve slippage — the run declares which it used
- The whole configuration is pinned as an immutable dataset and cost version
What Each Stage Asks, and What It Hands Back
No single test proves a strategy works. Each one attacks a different way a simulated result can flatter reality, and the report returns all of them together — including the ones that failed.
| # | Stage | The question it attacks | What the report returns |
|---|---|---|---|
| 1 | Backtest | Would these rules have made money after costs?fees, funding and modelled slippage on every fill | Simulated equity, drawdown, exposure, cost drag and the full trade list |
| 2 | Walk-forward | Does it hold on data it was never fitted to?rolling folds across the whole sample | Every fold's out-of-sample result beside its in-sample result, held or decayed |
| 3 | Parameter sweep | Is the setting a plateau or a lucky spike?every cell re-tested out of sample | A surface with in-sample and out-of-sample rank per cell, plus plateau detection |
| 4 | Cost and slippage stress | How much edge survives a worse execution environment?harsher fill and fee assumptions | The same run at each cost profile, and the profile at which the result breaks |
| 5 | Regime split | Did one market condition produce the whole result?volatility and trend regimes segmented | Per-regime behaviour, with regime concentration flagged as a finding |
| 6 | Look-ahead audit | Does any rule read data it could not have known?the quietest way a result flatters | The specific feature and the bar it reached into, raised as an open finding |
One Set of Endpoints, From First Query to Live Fills
The Coiny Strategy API is the product, not a wrapper around it. Everything the console does is an API call, which is why research, CI and production can all speak to the same system without an integration project in between.
Queue a run from code
Research That Ends Where Execution Begins
The expensive part of quant research is rarely the idea. It is the year spent collecting data, building a replay engine that charges realistic costs, wiring sweeps to compute, and then rewriting everything a second time so the strategy can actually trade. Coiny removes the second write entirely: research and production are one stack, so the thing you validated is the thing that runs.
- One data schema across history and the live feed — no reconciliation project on day one
- Costs modelled from the venue's own fee tiers, funding and recorded depth
- No rewrite between the tested strategy and the deployed strategy
- Every promotion carries the run that justified it, ready for an internal review
- Live fills return to the data layer, so drift from tested behaviour is measurable
The Questions a Research Lead Asks Before Moving Off Their Own Stack
- Do we have to abandon our own tooling?No. The strategy APIs are REST and WebSocket, so your existing notebooks, schedulers and CI keep working. Teams commonly start by pulling history through the data endpoints and leave everything else in place until the deployment path earns the move.
- How do we know the backtest is not lying to us?Because the platform argues with it. Walk-forward folds, parameter sweeps, cost stress, regime splits and a look-ahead audit run as standard, and failures are reported as open findings that travel with the strategy into the approval queue.
- Can a researcher accidentally trade real capital?No. Research and test-environment keys carry no scope that reaches a live venue, and no key at all can promote a strategy. Promotion is an approval in the console against a specific version, under the policy your operators define.
- What happens when a live strategy stops behaving like the tested one?Live fills are compared with the walk-forward envelope and alert on drift. Venue scope, position size and a daily loss limit are enforced by the engine, and the kill switch is one action away from the operator at any time.
- Can we reproduce a result from six months ago?Yes. Every run is pinned to a dataset version, strategy version, cost model and seed, and the pin is immutable. A run whose inputs cannot be reproduced is not eligible for promotion in the first place.
Where the Research Layer Plugs In
The research stack is one part of Coiny's quant infrastructure. These are the systems it feeds, the workflow that sits above it, and the API documentation a developer will want next.
Backtesting, Research & Strategy APIs — FAQ
You backtest a crypto trading strategy by replaying it against historical market data with realistic costs applied, then re-testing it on data it was never fitted to. On Coiny Exchange's backtesting platform that means four things: pin a dataset version and a cost model, run the strategy through an event-driven engine that charges taker fees, funding and modelled slippage on every simulated fill, repeat the run across rolling walk-forward folds, and read the robustness report rather than a single headline number.
A crypto backtesting platform is infrastructure that stores historical digital-asset market data, replays trading strategies against it under realistic cost and fill assumptions, and reports how the result holds up out of sample. Coiny Exchange's platform differs from standalone backtesters in one respect that matters to a quant team: it is wired to the venue. The data the research layer reads is recorded by the same exchange stack that will execute the strategy, and the API that queues a backtest is the API that runs it live.
Quant research infrastructure is the data, compute and tooling a trading team needs to go from a hypothesis to a tested strategy without building any of it themselves. Coiny Exchange provides it as a deployable layer: a historical market data store, a research environment for building features and signals, a backtest and sweep engine that scales with the run, versioning that makes every result reproducible, and the strategy APIs that carry an approved strategy into production.
A credible crypto backtest needs more than a price series. Coiny Exchange's data layer supplies trades, candles and order book snapshots per venue and instrument, plus the reference data that determines what a trade actually costs: tick sizes, fee tiers, funding rates and instrument definitions. Order book depth matters most, because a strategy filled at the touch price in simulation and against real depth in production will produce two different results.
An overfitted backtest is one whose result depends on being exactly right about the past. Coiny Exchange's robustness analysis tests that directly: parameter sweeps show whether the chosen settings sit on a plateau or a single spike, cost stress re-runs the strategy at harsher fill assumptions, regime splits check whether the result came from one market condition, and a look-ahead audit flags any rule reading data it could not have known at the time. Findings that fail are reported, not averaged away.
A trading strategy API is a programmable surface for defining, testing and running an automated trading strategy. The Coiny Strategy API covers all three over REST and WebSocket: query historical market data, queue a backtest or parameter sweep against a pinned dataset, read the resulting walk-forward and robustness report, then stream orders and fills for a strategy that has been approved for production. Keys are scoped, so a research key can run tests but cannot reach a live venue.
Yes. On Coiny Exchange the research and production paths share one data schema and one API surface, so a strategy is not rewritten to go live. What changes is governance rather than code: a named operator approves the exact strategy version, dataset version and open findings that were on the report, and the strategy then runs inside an operator-defined envelope of venues, position size and daily loss limits, monitored for drift from its tested behaviour.
Bring a Strategy. Leave With a Report You Can Argue With.
In a working session we point the research stack at your instruments, run one of your strategies through the backtest, walk-forward and robustness suite, and walk through the API surface and the deployment envelope that would carry it into production.
Get API Access