Inspiration

Most algorithmic trading projects focus on one question:

Did the strategy make money in the backtest?

That is not enough.

A strategy can look excellent because it was optimized for one asset, one market regime, one unusually profitable trade, or one historical period that was repeatedly inspected during development. Once deployed, that apparent edge can disappear.

I built Freqtrade Autonomous Quant Research to answer a harder question:

Can an AI research agent discover one crypto strategy that remains profitable, stable, and generalizable across multiple assets and unseen market periods?

The project focuses on the OP/USDT, AVAX/USDT, and LINK/USDT perpetual markets, operating from a single shared wallet.

Instead of optimizing each asset independently, the system evaluates them together as one realistic portfolio with shared capital and a limited number of simultaneous positions.

The final goal is not simply to produce the highest backtest return. It is to identify one candidate that is strong enough to enter a one-month paper-trading evaluation without contaminating sealed validation data.

What it does

Freqtrade Autonomous Quant Research is a controlled, AI-assisted quantitative research workflow built around Freqtrade.

The research agent:

  1. Reviews the current best strategy and prior experiment history.
  2. Proposes a falsifiable improvement hypothesis.
  3. Registers the hypothesis, implementation scope, and evaluation rules before execution.
  4. Implements the approved strategy or portfolio-level change.
  5. Runs controlled backtests and stress tests.
  6. Evaluates profitability, drawdown, robustness, concentration, and asset-level consistency.
  7. Rejects weak, unstable, or overfit candidates.
  8. Advances only qualified candidates toward sealed out-of-sample validation and paper trading.

The system is designed to prevent the AI from repeatedly modifying a strategy after seeing protected results.

Development data, out-of-sample data, and protected holdout data are treated as separate research stages. Protected periods remain sealed until a candidate satisfies the previously registered eligibility gates.

Research objective

The project does not optimize for raw return alone.

A candidate must perform well across several dimensions:

  • Profitability: strong portfolio return after realistic costs
  • Stability: controlled maximum drawdown
  • Generality: positive contribution across OP, AVAX, and LINK
  • Robustness: resilience to fees, slippage, regime changes, and winner removal
  • Causality: no future information or lookahead leakage
  • Reproducibility: traceable code, data, configuration, and result lineage

A simplified research objective can be represented as:

$$ \mathrm{Score} = R - \lambda_1 \mathrm{MDD} - \lambda_2 C - \lambda_3 O $$

where:

  • (R) is portfolio return
  • (\mathrm{MDD}) is maximum drawdown
  • (C) represents concentration risk
  • (O) represents overfitting and instability penalties
  • (\lambda_1), (\lambda_2), and (\lambda_3) control the importance of each risk

The actual acceptance process does not rely on this score alone. Candidates must pass multiple hard gates independently.

How I built it

The project is built with Python, Freqtrade, Docker, Git, Codex, and GPT-5.6 using historical perpetual-futures data and a staged research process.

The strategy environment includes:

  • OP/USDT, AVAX/USDT, and LINK/USDT perpetual markets
  • One shared USDT wallet
  • A maximum of three simultaneous positions
  • Realistic trading-fee and slippage stress
  • Portfolio-level drawdown and capital-allocation checks
  • Walk-forward and out-of-sample evaluation
  • Protected holdout periods
  • Paper-trading qualification gates

Each research cycle is organized into four stages.

M1 - Hypothesis and preregistration

Before writing code, the agent records:

  • the proposed causal mechanism
  • the expected benefit
  • the files allowed to change
  • fixed evaluation metrics
  • rejection criteria
  • stop conditions
  • protected-data restrictions

M2 - Bounded implementation

The agent modifies only the approved files and implements the registered hypothesis.

Repository-wide rewrites, unrelated cleanup, uncontrolled parameter searches, and unregistered scope expansion are prohibited.

M3 - Controlled execution

The project runs only the predefined experiments.

Outputs are stored as new artifacts rather than overwriting previous results. Important files and configurations are tracked with SHA-256 hashes so that every result can be linked to the exact strategy, configuration, and input data that produced it.

M4 - Evaluation and decision

The agent determines whether the hypothesis:

  • improved the strategy
  • failed its registered gates
  • revealed a structural problem
  • or justified a new research direction

Failed experiments remain part of the permanent research history so that the system does not unknowingly repeat them.

How Codex and GPT-5.6 were used

Codex served as the primary research and software-engineering agent.

It was used to:

  • inspect the existing Freqtrade repository
  • review previous experiment results
  • propose falsifiable hypotheses
  • draft preregistration and rejection rules
  • implement bounded strategy changes
  • create validation and causal-safety tests
  • analyze failures and unexpected results
  • maintain research handoff documents
  • preserve reproducible experiment lineage

GPT-5.6 Luna Max was used through Codex during the current build phase for long-running repository analysis, implementation, testing, validation review, and documentation.

The agent operates under strict controls:

  • one active research hypothesis at a time
  • one writer at a time
  • no access to protected data before eligibility
  • no overwriting previous experiment artifacts
  • no opportunistic reruns after inspecting results
  • explicit file, command, and scope restrictions
  • predefined completion and rejection conditions

What was built during OpenAI Build Week

The underlying quantitative research project began before OpenAI Build Week.

During the hackathon period, Codex with GPT-5.6 was used to create and document:

  • a runnable candidate-validation demonstration
  • preregistered hard-gate evaluation logic
  • a fail-closed protected-data access controller
  • shared-wallet validation documentation
  • judge testing instructions
  • and a compact hackathon submission repository

The submitted demonstration and documentation are represented by the repository commit history and the submitted Codex Session ID.

Preventing lookahead bias

One of the hardest engineering problems was ensuring that every portfolio decision uses only information that was available at that exact moment.

Portfolio-risk calculations may depend on previously closed trades and currently open positions. The implementation must ensure that:

  • only trades closed strictly before the decision timestamp are visible
  • positions opened at the same timestamp share the same prior state
  • same-time events are processed atomically
  • future or out-of-order records cause the process to fail safely

A strategy that accidentally uses future information may produce excellent historical results while being impossible to reproduce in live or paper trading.

For this project, causal correctness is a mandatory requirement rather than an optional quality check.

Challenges

Avoiding overfitting

The largest challenge was resisting the temptation to keep adjusting a strategy until the historical results looked good.

To reduce this risk, every research hypothesis is registered before execution, protected datasets remain sealed, and results are evaluated against multiple independent robustness gates.

Shared-wallet realism

Testing each pair independently can hide capital conflicts.

A strategy may appear profitable on three assets even though all three tests assume access to the same funds at the same time.

The project therefore evaluates the assets together under one wallet with limited simultaneous positions.

Distinguishing real improvement from one lucky winner

A portfolio can be dominated by one asset or one unusually profitable trade.

The system checks whether performance survives after removing the strongest contributor and whether each asset remains useful after realistic costs.

Managing autonomous research safely

Allowing an AI agent to direct research creates a new control problem.

The agent must be prevented from:

  • widening the research scope without approval
  • accessing protected data too early
  • rerunning failed experiments opportunistically
  • modifying previous evidence
  • selecting only favorable outcomes

The solution was to build explicit research stages, immutable artifacts, single-writer rules, scoped file permissions, and documented stop conditions.

Balancing return and stability

The strategy with the highest historical return is not necessarily the best candidate for paper trading.

A slightly lower-return strategy with smaller drawdowns, broader asset contribution, stronger cost resilience, and better out-of-sample behavior may be much more valuable.

What I learned

This project changed how I think about quantitative trading and AI-assisted software development.

I learned that:

  • A backtest result is only as trustworthy as the process that produced it.
  • Preventing data leakage is often harder than designing an entry signal.
  • Portfolio-level behavior can differ greatly from isolated pair results.
  • Failed experiments are valuable when they are preserved and classified.
  • AI agents perform better when research freedom is paired with strict procedural controls.
  • Reproducibility, lineage, and falsification are as important as model creativity.
  • The best strategy is not necessarily the one with the largest historical return.
  • A stronger candidate is one that is more likely to survive contact with unseen data.

Current status

The system currently maintains a best-known shared-wallet strategy and continues controlled research to identify one stronger candidate.

The next milestone is to qualify one strategy through:

  1. preregistered development testing
  2. walk-forward validation
  3. sealed out-of-sample evaluation
  4. protected holdout validation
  5. a one-month paper-trading trial

The project does not execute real-money trades as part of the hackathon submission.

What's next

Future work includes:

  • automated experiment dashboards
  • interactive lineage visualization
  • portfolio-level risk attribution
  • live paper-trading monitoring
  • regime-change detection
  • automated drift alerts
  • human-readable research reports for every accepted or rejected candidate

The long-term vision is an AI research system that does not merely generate trading strategies, but produces auditable evidence explaining why a strategy should or should not be trusted.

Built With

Share this project:

Updates