Quant Research Framework

The Python reference is the framework anyone can install today and use to generate strategies, rule-based or ML, under a research-grade pipeline. You write a function that takes (df, lb) and returns int8 signals in {−1, 0, +1}; the framework owns optimisation, walk-forward orchestration, regime rotation, the 5-scenario robustness overlay suite, and metric computation. The numba JIT inner loop applies fees, slippage, funding (crypto-only), intrabar SL/TP, session windows, and forced-close logic over a typed trade ledger, so the simulated PnL is what a deployable execution layer would actually see.

Seven major subsystems ship in the box, data loader, indicator core, strategy contract, execution core, optimiser, walk-forward orchestrator, regime engine, plus the Monte Carlo and Deflated-Sharpe diagnostic blocks. The v0.4.0 release detangled Config from globals, which is what lets two backtests coexist in the same interpreter and is also what unblocked the cross-language parity protocol downstream.

• ▪Install: pip install quant-research-framework. DOI: 10.5281/zenodo.19798594. MIT licensed.
• ▪Strategy contract is deliberately minimal: (df, lb) → int8[] in {−1, 0, +1}. Same surface for hand-written rules and for ML models.
• ▪Bundled CSVs to make the first backtest a one-liner: SOLUSDT 1h (48,094 bars) and EURUSD 1h (53,160 bars).

The Rust port gives you the same engine, same WFO, same regime segmenter, same robustness suite, same strategy semantics, in a binary you can drop into a production deployment without a Python interpreter. It is a separate implementation of the same specification, not a transliteration: different memory layout, different rounding regime (LLVM-via-rustc vs LLVM-via-numba), different RNG. The point is to exercise the algorithmic spec with two engines whose only shared lineage is the spec itself.

Strategy contract mirrors Python exactly: fn(&[Bar], usize) → Vec<i8>. The flip-detection layer translates raw signal levels into entry/exit codes; this separation lets strategy authors specify desired state (long/short/flat) rather than transitions, which is much easier to keep no-look-ahead-correct.

• ▪DOI: 10.5281/zenodo.19798592. crates.io: cargo add quant-research-framework-rs.
• ▪Dependencies are deliberately tiny and pinned: rand =0.9 (exact), chrono 0.4, chrono-tz 0.10. The exact rand pin is documented because rand 0.10 makes random_range a trait method, breaking call sites.
• ▪Rust binary needs no warm-up; Python pays a one-time numba JIT cache cost before the first measured run.

Parity is the protocol that lets us claim Python and Rust are running the same backtester rather than two backtesters that happen to look alike. Three deterministic configuration surfaces are verified end-to-end on every PR: default config (56 metric points · candle-trigger WFO + smart-optimised lookback + auto-RRR), regime + WFO (98 metric points · per-regime LB optimisation + OOS LB rotation + 200-bar warmup + 4 WFO windows), and forex mode (56 metric points · pip-scaled position sizing + forex-mode PnL capping).

Tolerance is 10⁻³ relative; the worst observed deviation across all 210 metric points is 5×10⁻⁵, twenty times tighter than declared, which we take as evidence that algorithmic equivalence, not numerical accumulation, is binding. The 156-point paper-time replication matched bit-for-bit at \%.4f printed-rounding precision.

• ▪Re-running parity is one command per surface, total runtime ≈ 5–10 min on a recent laptop.
• ▪Disabled by design: Monte Carlo percentiles (different RNG implementations between engines). The previously-divergent INDICATOR_VARIANCE overlay was closed during paper preparation by adding IND_VARIANCE_SEED = 42 to both engines.
• ▪Honestly disclosed unverified scope: Windows MSVC. The four-way regime+WFO+forex+session combination is now byte-exact and gated in CI (Phase 08), and cross-architecture parity on aarch64 is CI-verified (Phase 06).

The point of the perf phase is that the Rust engine is operationally usable in a production deployment, not that the Python reference is slow. On the bundled bench the Rust port runs 25–60× faster end-to-end (replicated as 24–62× on the paper-time host) with ≈ 37× lower whole-process peak RSS, the engine-attributable memory delta is plausibly only 3–5× once Python's pandas/numpy/numba interpreter baseline is subtracted, and the paper reads the headline with that caveat.

The speedup comparison is meaningful precisely because parity holds: without parity, a faster re-implementation might just be doing less work; with parity, you are timing two implementations of the same algorithm.

• ▪Benchmarks run on bundled SOLUSDT 1h slices at 15k / 25k / 35k / 48k bars, three warm runs (with one warm-up discarded for numba JIT cache).
• ▪The full default pipeline runs end-to-end: IS/OOS baseline, smart-optimised lookback search with auto-RRR, candle-triggered walk-forward, Monte Carlo diagnostics, and the four v0.1.x robustness overlays.

The accompanying paper documents the architecture, the WFO + regime + robustness pipeline, the parity methodology, the performance comparison, and a reproducibility blueprint suitable for academic publication. It positions the framework against six widely used open-source backtesters and the relevant statistical literature; the contribution is the combination plus the parity protocol, not new statistical machinery.

Twelve internal review rounds took the paper from an average reviewer score of 7.0 to a final 8/8/9 trajectory. The paper repository ships requirements-paper.txt with pinned Python deps, a Makefile that runs make verify against pinned sibling-clone SHAs, and a generated parity_residuals.csv that backs every figure.

• ▪Full source: github.com/DaruFinance, paper repo + python repo + rust repo as siblings.
• ▪Both artefacts have separate Zenodo DOIs; the paper repository will receive its own DOI when archived to Zenodo at publication time.

The Rust port has been cross-compiled to aarch64-unknown-linux-gnu and run under QEMU user-mode emulation against the same inputs as the x86_64 binary. After seeding the previously-unseeded indicator-variance overlay (an oversight uncovered and fixed during paper preparation), every printed deterministic metric is byte-identical between the two architectures across all six bundled datasets, 1,176 metric lines, zero differences. Only the load and total wall-clock timings differ, both inflated by QEMU's emulation overhead.

The comparison is exact string equality of the printed metric block, strictly stronger than the relative-tolerance check used for cross-language parity, and it holds because the hot path uses only correctly-rounded IEEE-754 operations, with no fast-math or fused-multiply-add codegen. A native-ARM job on a free public ARM runner runs the same byte-identity assertion on real silicon alongside the QEMU job, so both architectures are checked on every change and the QEMU result stands as the reproducible backstop.

The execution core at the paper-pinned version operated on a single OHLC series at a time. The multi-asset substrate that lifts that limit shipped in v0.5.0 across both engines: a panel layer (cross-asset regime detection, long/short baskets, equal-risk-contribution sizing, beta / dollar / sigma neutralisations, portfolio constraints) plus pairs and carry primitives, over a redesigned per-leg trade ledger that carries a leg id, a trade-group id, and a full cost decomposition (fee, slippage, funding, gross and net) satisfying gross − costs = net to floating-point tolerance.

Every primitive is mirrored Python ↔ Rust and exercised by its own parity gate in CI, holding to the same discipline as the original surfaces, eight surfaces now agree within 1e-3 (trade counts exact). Single-asset metric outputs are byte-unchanged from the prior release. The proprietary strategy research that sits on top of this substrate stays private; the public release is the engine capability, not the strategies.

The published parity record covered three surfaces; the four-way combination, regime + WFO + forex + session, was the remaining one, and it is now closed. Root-causing the combo divergence found two causes. The dominant one was a harness mismatch, not an engine bug: the combo driver fed the two engines different selection knobs (minimum-trades and risk-to-reward optimisation are compile-time constants on the Rust side but were being overridden on the Python side), so the in-sample phase chose a different lookback.

The residual was three session-end-bar divergences in the Rust backtest core: on the last in-session bar of the day it let an opposite-flip signal open a position, never blocked a new entry, and ran the intrabar stop/target check, whereas the reference engine force-closes unconditionally and skips the stop/target check there. Aligning all three (fully guarded by the session flag, so the single-feature surfaces stay byte-unchanged) makes the combo byte-exact across every stage. It now runs as a fourth gated parity surface in CI, shrinking the honestly-disclosed unverified footprint to Windows MSVC.

The DSR utility (Bailey & López de Prado 2014) was Python-only because it depends on scipy's normal distribution and is invoked once per optimisation trajectory rather than per bar. It is now mirrored in Rust behind a lightweight feature flag, using the same parity discipline applied to its scalar output: a dedicated harness feeds identical (Sharpe, trial-Sharpes, returns) fixtures, including skewed, fat-tailed, and every degenerate-guard case, to both implementations and confirms agreement on the expected-maximum-Sharpe and the deflated Sharpe within the standard tolerance, and in fact below 1e-9 on all finite cases since both are closed form.

The normal CDF and its inverse come from a vetted statistics crate that matches scipy to roughly 1e-12; the coarse error-function approximation used elsewhere in the port is deliberately not reused, because its tail error would corrupt the expected-maximum-Sharpe term at the relevant quantile. The benefit is a Rust-only deployment that computes deflated-Sharpe diagnostics on its own optimiser trajectories without round-tripping through Python.