Research → Production: Our Workflow for trading Crypto

A trading idea isn’t useful when it’s interesting. It’s useful when it can be turned into a system that behaves predictably under real constraints.

At NXFD, we treat research and production as a single loop. A hypothesis is not “done” when a backtest chart looks good – it’s done when we can deploy it with explicit assumptions, conservative execution, risk controls, and monitoring that tells us when it’s breaking.

This post outlines the workflow we use to go from observation to live operation in crypto spot and futures markets.

1) Observe: start with a measurable question

We start with questions that can be stated in plain language and tested without hand-waving:

“Does liquidity withdrawal predict short-horizon volatility expansion?”
“Do funding extremes correlate with asymmetric drawdowns?”
“Does a particular execution style reduce adverse selection in fast markets?”

The key is to anchor the question in something observable:

microstructure behavior
venue mechanics (fees, funding, rebates)
market regimes and constraints
operational realities (latency, uptime, API limits)

If the question can’t survive measurement, it won’t survive production.

Output of this stage: a clear hypothesis + what would falsify it.

2) Validate: test under constraints, not comfort

Validation isn’t “does it work in a backtest?” It’s:

does it work after costs?
does it work across regimes?
does it work under stress?
does it work with execution realism?

What we check (non-negotiables)

Costs and slippage: conservative assumptions; sensitivity analysis (e.g., 1×, 2×, 3× costs)
Robustness: multiple regimes, multiple sub-periods, multiple venues where applicable
Stress tests: worst-week scenarios, volatility spikes, liquidity gaps, price gaps
Failure modes: where it breaks and how it breaks (slow bleed vs cliff)
Overfitting pressure: simplify where possible; prefer fewer degrees of freedom

A result that only works under perfect fills is not a result. It’s a story.

Output of this stage: evidence that survives hostile assumptions + a written list of known limitations.

3) Engineer: make it reproducible

A research notebook isn’t a system.

Before anything is allowed near production, we require:

reproducible data inputs (with lineage)
deterministic computation where possible
versioned configs / parameters
clear definitions (signals, sampling, timestamps, venue-specific quirks)
explicit dependencies and fallbacks

This is also where we decide what must be monitored later:

feature health
data freshness
execution quality
drift / regime signals
risk utilization

Output of this stage: a buildable component with known interfaces, tests, and metrics.

4) Deploy: stage it, cap it, observe it

We deploy in stages because the goal isn’t to “turn it on.” The goal is to learn safely.

A typical staged rollout looks like:

Shadow / paper: generate decisions, don’t trade
Micro size: trade small, validate mechanics and monitoring
Capped scale: increase gradually under strict exposure and drawdown caps
Normal operation: only after the system proves it behaves as expected

At each stage we define:

position and exposure limits
drawdown rules
kill-switch triggers
expected ranges for key metrics

This isn’t bureaucracy. It’s how you prevent research mistakes from becoming irreversible losses.

Output of this stage: a live system with guardrails and clear go/no-go criteria.

5) Operate: measure the gap between expected and realized

Live trading is the final validation environment.

We constantly compare:

expected vs realized slippage
expected vs realized hit rate / payoff distribution
risk usage vs limits
behavior across volatility regimes
stability of signal inputs and data quality

When performance changes, the first question isn’t “what’s the new model?”

It’s:

did market conditions move outside our design envelope?
did execution degrade?
did data change?
did the strategy’s assumptions stop holding?

Output of this stage: a feedback loop – what to adjust, what to remove, what to keep.

6) Iterate: small changes, measured rollouts

Most systems die from uncontrolled iteration:

too many simultaneous changes
unclear causality
no baseline
no rollback plan

We keep iteration disciplined:

one change at a time where possible
explicit hypothesis for the change
staged rollout again
post-change review: did it do what it was supposed to do?

Iteration is not a sign of weakness. It’s the point. Markets change; systems must change – but safely.

What this workflow optimizes for

This workflow optimizes for:

robustness (not fragile precision)
risk containment (no single point of failure)
execution realism
operational clarity (we can explain what the system is doing and why)

In crypto spot and futures, the constraint isn’t idea generation. It’s turning ideas into systems that can survive reality.

That’s the work.