Project Genesis

A systematic quantitative research and execution infrastructure for cryptocurrency markets. The system was built to answer a single question rigorously for any candidate strategy: does this actually have an edge, or does it just look like it does?

Three strategies were run through it. All three received an honest negative verdict before any capital was deployed. That outcome is what the infrastructure was designed to produce — accurate evaluation, including when the answer is unwelcome.

The deliverable here is the apparatus, not a profitable strategy. What this project demonstrates is the discipline and tooling needed to evaluate quantitative strategies honestly: a backtest engine audited for the silent biases that flatter retail results, a methodology layer that catches selection bias and label leakage, a universe constructor that quantifies survivorship bias instead of hiding it, and a cross-sectional portfolio engine for strategies whose weights cannot be decomposed per-symbol. These pieces are the substance of the work.

---

The result the apparatus produced

Most algorithmic trading repositories present a backtest with a high Sharpe ratio and ask the reader to trust it. The single most common silent failure in retail quant work is methodology that flatters strategies into looking profitable when they are not — same-bar execution leaking the future, ignored selection bias from sweeping parameters, wrong annualization, label leakage in cross-validation, survivorship bias in coin universes. Each can inflate a reported Sharpe by 1-3x. In combination, they routinely turn a strategy that loses money live into one that looks excellent on paper.

Project Genesis was built specifically to not lie. Three candidate strategies were evaluated through the same apparatus:

Strategy	Apparatus verdict
1-minute and 1-hour EWMA momentum	No edge after fees. The original engine had reported Sharpe 1.545 with an 83% win rate; correction of same-bar look-ahead and a 5x annualization error revealed it had never been working.
Funding-rate arbitrage	180-day cost-sensitivity analysis: funding payments do not clear realistic taker fees often enough to be a primary strategy.
Volume-weighted time-series momentum (paper-faithful)	Lost outright to a volume-weighted crypto-beta benchmark over 400 days. Deflated Sharpe = 0.00 on excess returns. Survivorship adjustment would lower this further.

The negative results are not buried because they are the proof the methodology works. The first strategy in particular is informative: the same code, evaluated through the broken engine, looked excellent; evaluated through the corrected engine, it lost money. The gap is the size of the lie the unaudited infrastructure was telling.

---

What the apparatus consists of

Built in 12 phases of foundation, then 2 phases of correction and methodology, then a final phase of cross-sectional strategy evaluation.

Phases 1-12 - research foundation. Config and logging, data ingestion across REST and websocket clients, OHLCV and orderbook storage, validation, signal generators implementing a common BaseSignal interface (mean reversion, momentum, market making), higher-level strategy classes, feature engineering (technical, orderbook, funding-rate), risk management (position sizing, limit checking, manual-reset circuit breaker), an execution layer with a shared interface between paper and live (so strategies are tested against realistic execution, not just simulated returns), monitoring (health checks, Telegram alerter, Streamlit dashboard provider), and the initial backtest engine and reports. 1,099 unit tests, 20 integration tests, full pipeline verified end-to-end before any methodology work began.

Phase A - backtest engine correctness audit. The original engine had four real bugs that systematically inflated results. Each was identified, isolated, fixed, and re-verified:

• Same-bar-close execution let signals computed on bar i's close trade at that same close, effectively trading on information at the instant it was revealed. Fixed: signals at i execute at i+1's open. Verified by a "cheat" strategy that mints money under the bug but cannot under the fix.
• Fill prices were clamped to [bar.low, bar.high], itself a form of look-ahead since those extremes are not known at execution.
• Short positions were marked with abs(quantity * price), treating them as adding to equity rather than as liabilities.
• Annualization was hardcoded at 365, silently inflating hourly-bar Sharpe ratios by sqrt(24) ~= 4.9x.

The momentum re-evaluation after Phase A is the cleanest example of the audit's value: a strategy previously reporting Sharpe 1.545 correctly evaluated to no edge.

Phase B - methodology layer. Three new modules addressing the three most common silent biases in quantitative evaluation:

• src/math/deflated_sharpe.py - Deflated Sharpe Ratio (Bailey & Lopez de Prado). Takes an observed Sharpe, a trial count, and the return distribution's skew/kurtosis; returns the probability that the true Sharpe exceeds zero. Verified by collapsing identical return series from DSR 0.024 to 0.000 as the trial count rises from 1 to 1000 - the observed Sharpe does not change, only the honest correction for selection bias.
• src/validation/purged_cv.py - Purged K-Fold cross-validation with embargo. Removes training samples whose forward-looking label window overlaps the test fold, plus a buffer after each test fold for serial correlation. Verified by model-free overlap counting: naive k-fold leaves 250 train/test label overlaps; purged k-fold leaves exactly 0.
• src/labeling/triple_barrier.py - labels each candidate entry by which of three barriers (profit target, stop loss, time limit) is touched first. Produces variable-length exit_index spans that feed directly into the purged CV's label_spans parameter. The three tools interlock: 575 triple-barrier labels on a random walk fed into purged CV produce zero leakage overlaps.

Phase C - cross-sectional evaluation. Volume-Weighted Time-Series Momentum, the highest-priority candidate from the research catalogue. Built in four pieces because a cross-sectional strategy cannot be decomposed into per-symbol signals without destroying its mechanism:

• src/universe/construction.py - top-N liquidity ranking with tercile percentile gate, stablecoin / wrapped / leveraged exclusion, point-in-time-ready interface (a paid PIT data source could be substituted later without strategy changes), and an explicit SurvivorshipBiasReport that quantifies - does not fix
  • the bias from using survivors-only free data. Estimated +0.3 to +0.8 Sharpe inflation, independent of and additional to DSR.
• src/universe/data_layer.py - fetch-once cached daily OHLCV with ragged-history drop, timestamp intersection (no forward-filling invented prices), and a collapse guard that warns when a single delisted symbol could otherwise silently annihilate the panel.
• src/signals/vw_tsmom.py - faithful reproduction of the paper's construction: sign-only time-series momentum, dollar-volume weighting, long-short, exact gross normalization. Pure logic, 8-test verification suite.
• src/backtest/portfolio_engine.py - separate from the Phase A per-symbol engine because cross-sectional weights cannot be decomposed. Same Phase A discipline (next-bar-open execution, signed equity, real costs) plus explicit short-borrow charging and a volume-weighted crypto-beta benchmark so apparent edge can be separated from market exposure.

The honest evaluation driver (scripts/vw_tsmom_evaluate.py) wires all of this end-to-end: live symbol discovery, universe construction, ranking, signal formation, portfolio backtest, Deflated Sharpe on excess returns with an honest trial count, and survivorship disclosure. Output is a structured verdict, not a hopeful Sharpe number.

---

What this work demonstrates

Skills that are concrete and transferable:

• Quantitative methodology - selection bias correction, leakage- aware cross-validation, honest cost modeling, survivorship-bias quantification, look-ahead identification and correction, bar-interval-aware annualization
• Software engineering - ~12,000 lines of typed Python, ~1,100 unit tests, integration tests, dependency injection at network boundaries for testability, dataclass-driven configuration, consistent linting / formatting discipline
• Systems work - production-grade execution layer with shared paper/live interface, state-persistent paper trader with exponential-backoff reconnection, monitoring and alerting, git workflow with atomic commits documenting why changes were made
• Research discipline - the willingness to audit one's own backtest engine, fix the bugs it reveals about prior conclusions, and accept negative verdicts from the corrected machinery rather than tuning until results look acceptable

What this work explicitly does not demonstrate

• A profitable trading strategy. No strategy evaluated through the apparatus produced real alpha. The repository's value is the machinery that determined this, not the strategies themselves.
• Live capital deployment. The execution layer is production- capable, but the apparatus never graduated a strategy past paper trading because no strategy survived honest evaluation. This is consistent with the apparatus working as designed.
• HFT or microstructure edges. The infrastructure is not low-latency and was not intended to be. Decisions made at minutely or higher resolution, not microsecond.

This explicit scope statement is deliberate. The claim this project makes is not that it makes money - it is that it tells the truth about whether something makes money. Most quantitative work fails silently in the opposite direction; auditing rigorously enough to fail loudly, on purpose, is the differentiator.

---

Repository layout

src/
  backtest/        engine.py (Phase-A corrected), portfolio_engine.py, simulator.py, report.py
  data/            OHLCV models, REST + websocket clients, storage, validation
  execution/       paper trader, live client, execution engine, risk-gated routing
  features/        technical, orderbook, funding-rate feature engines
  labeling/        triple_barrier.py (Phase B3)
  math/            returns, statistics, volatility (GARCH), stationarity,
                   regime, deflated_sharpe.py (Phase B1)
  monitoring/      health checks, Telegram alerter, dashboard data provider
  risk/            position sizer, limit checker, circuit breaker, risk service
  signals/         base, momentum, mean reversion, market making, vw_tsmom.py
  strategies/      higher-level strategy classes
  universe/        construction.py (Phase C1), data_layer.py (Phase C2a)
  utils/           config, logging, time utilities, decorators
tests/
  unit/            1,099 tests covering every module
  integration/     20 end-to-end pipeline tests
scripts/
  vw_tsmom_evaluate.py   the C4 honest-evaluation driver
  funding_research.py    cost-sensitivity analysis for funding arb
  hourly_backtest.py     backtest runner on real Binance data
  paper_trading.py       state-persistent paper trading loop

---

Running it

Developed against Python 3.11+ on Ubuntu.

python -m venv venv && source venv/bin/activate
pip install -r requirements.txt
pytest tests/unit/ -q              # 1,099 tests, ~25 seconds
python scripts/vw_tsmom_evaluate.py --universe 25 --formation 7

Binance read-only API keys go in a .env file (gitignored; an .env.example template is included). Read-only is sufficient because all trades in paper mode are simulated locally; the keys are only used for market data ingestion.

The evaluation script prints a structured verdict with the honesty adjustments visible - that is the intended interface.

---

License

MIT.