If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/QuantConnect/Lean shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 1d ago
• 13 active contributors
• Distributed ownership (top contributor 26% of recent commits)
• Apache-2.0 licensed
• CI configured
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live QuantConnect/Lean repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/QuantConnect/Lean.

What it runs against: a local clone of QuantConnect/Lean — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in QuantConnect/Lean | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of QuantConnect/Lean. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/QuantConnect/Lean.git
#   cd Lean
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of QuantConnect/Lean and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "QuantConnect/Lean(\\.git)?\\b" \\
  && ok "origin remote is QuantConnect/Lean" \\
  || miss "origin remote is not QuantConnect/Lean (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f ".github/workflows/gh-actions.yml" \\
  && ok ".github/workflows/gh-actions.yml" \\
  || miss "missing critical file: .github/workflows/gh-actions.yml"
test -f "Algorithm.CSharp/BasicTemplateAlgorithm.cs" \\
  && ok "Algorithm.CSharp/BasicTemplateAlgorithm.cs" \\
  || miss "missing critical file: Algorithm.CSharp/BasicTemplateAlgorithm.cs"
test -f ".devcontainer/Dockerfile" \\
  && ok ".devcontainer/Dockerfile" \\
  || miss "missing critical file: .devcontainer/Dockerfile"
test -f ".nuget/NuGet.config" \\
  && ok ".nuget/NuGet.config" \\
  || miss "missing critical file: .nuget/NuGet.config"
test -f ".editorconfig" \\
  && ok ".editorconfig" \\
  || miss "missing critical file: .editorconfig"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/QuantConnect/Lean"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

LEAN is an event-driven, professional-grade algorithmic trading platform written primarily in C# with Python support that enables backtesting and live trading across equities, futures, options, forex, and crypto. It provides market data ingestion, portfolio management, risk analysis, and execution simulation with support for alternative data sources and direct brokerage connections. Monolithic design with core engine in Lean.Lean/ (primary trading logic), Algorithm.CSharp/ containing 1000+ example/regression algorithms, Lean.Interfacing/ for broker connections, and Tests/ for validation. The .devcontainer/ and .github/workflows/ show containerized development setup. Multiple language support: C# for core, Python for research (via Jupyter notebooks under /Jupyter), and strategy writing in both.

Quantitative researchers, systematic traders, and algorithmic trading developers who need a production-ready backtesting and live trading engine with institutional-grade position management, multi-asset class support, and extensible alpha model architectures.

Highly mature and production-ready. The codebase shows 31M+ lines of C#, extensive regression test suites (visible in .github/workflows/regression-tests.yml, research-regression-tests.yml), and active CI/CD pipelines. QuantConnect maintains this as their core commercial platform with regular updates and strong community engagement via Discord and forums.

Low risk for established use cases; moderate risk for custom extensions. The monolithic architecture (all assets in root Algorithm.CSharp, Lean.Interfacing, etc.) can be difficult to navigate for new contributors. Dependency management relies on .nuget/NuGet.config, and the large surface area (60+ framework entry points) means breaking changes could impact custom strategies. Community-maintained forks may lag behind main releases.

Active regression testing and platform stability improvements evident from .github/workflows/ (api-tests.yml, benchmarks.yml, virtual-environments.yml). The presence of AddFutureOption*, AddOption*, and AddFuture regression algorithms suggests ongoing derivatives support expansion. Research integration tests and syntax validation indicate continued investment in Python integration.

git clone https://github.com/QuantConnect/Lean.git && cd Lean && dotnet restore && dotnet build Lean.sln. For Docker: docker build -f .devcontainer/Dockerfile . && docker run -it <image_id>. Python users can work with jupyter notebooks in Jupyter/ folder or write strategies in Algorithm.Python/.

Daily commands: For backtesting: compile in Visual Studio or via dotnet build then run Lean.Launcher as entry point. For live trading: configure QuantConnect API credentials in config.json (in root). For research: jupyter notebook in Jupyter/ folder. All workflows validate via gh-actions.yml which runs Build, Regression, API, and Syntax tests.

• .github/workflows/gh-actions.yml — Main CI/CD pipeline for build and test validation; all contributors must understand the automated testing requirements
• Algorithm.CSharp/BasicTemplateAlgorithm.cs — Reference implementation template showing the core algorithm structure that all trading strategies inherit from
• .devcontainer/Dockerfile — Development environment setup; defines dependencies and runtime requirements for the entire Lean engine
• .nuget/NuGet.config — Package management configuration critical for resolving C# dependencies across the engine
• .editorconfig — Code style and formatting standards enforced across Python and C# codebase for consistency
• .gitignore — Prevents accidental commits of build artifacts, binaries, and sensitive data to the repository
• .vscode/launch.json — Debugging configuration for VS Code; essential for local development and algorithm testing workflows

Add a New Trading Algorithm Template

1. Create new C# file in Algorithm.CSharp/ directory following naming convention (e.g., BasicTemplateNewAssetTypeAlgorithm.cs) (Algorithm.CSharp/BasicTemplateAlgorithm.cs)
2. Inherit from QCAlgorithm and implement Initialize() to set cash, add security, and configure subscriptions (Algorithm.CSharp/BasicTemplateFuturesAlgorithm.cs)
3. Implement OnData() method to receive market data and execute trading logic with self.AddOrder() calls (Algorithm.CSharp/BasicTemplateCryptoAlgorithm.cs)
4. Register algorithm with regression test suite in appropriate .github/workflows/ file if it tests core engine functionality (.github/workflows/regression-tests.yml)
5. Document algorithm purpose, securities, and data types in file header comments matching existing template format (Algorithm.CSharp/BasicTemplateForexAlgorithm.cs)

Add a New Alpha Model (Quantitative Strategy)

1. Create new C# file in Algorithm.CSharp/Alphas/ following pattern (e.g., MyQuantStrategyAlpha.cs) (Algorithm.CSharp/Alphas/GreenblattMagicFormulaAlpha.cs)
2. Inherit from QCAlgorithm and implement universe selection (coarse filter for stock screening) (Algorithm.CSharp/Alphas/ShareClassMeanReversionAlpha.cs)
3. Implement factor calculation and portfolio rebalancing logic in OnData() using indicator libraries (Algorithm.CSharp/Alphas/MeanReversionLunchBreakAlpha.cs)
4. Add regression test entry in .github/workflows/regression-tests.yml pointing to algorithm for validation (.github/workflows/regression-tests.yml)

Add a New Market Data Type or Data Handler

1. Study existing data handler patterns in algorithm files using AddData() for custom data sources (Algorithm.CSharp/AuxiliaryDataHandlersRegressionAlgorithm.cs)
2. Create test algorithm in Algorithm.CSharp/ demonstrating new data handler subscription and usage (Algorithm.CSharp/BasicTemplateAlgorithm.cs)
3. Register new data type test in regression workflow to validate data pipeline integration (.github/workflows/regression-tests.yml)

Add a CI/CD Workflow for New Test Category

1. Create new YAML file in .github/workflows/ (e.g., my-tests.yml) with GitHub Actions job definition (.github/workflows/gh-actions.yml)
2. Define build matrix (OS, .NET version) and steps to checkout, build, and run test suite (.github/workflows/regression-tests.yml)
3. Configure artifacts/reports upload and notification settings matching existing workflow patterns (.github/workflows/benchmarks.yml)

• C# with .NET Framework — High-performance compiled language essential for low-latency algorithmic trading; integrates with Windows brokerages and APIs
• Python Support (Lean engine core) — Enables data science teams to prototype strategies using familiar libraries (pandas, numpy, scikit-learn); IronPython integration for cross-language support
• Docker containerization — Ensures reproducible backtesting environment across development, CI/CD, and cloud deployment; simplifies dependency management
• GitHub Actions CI/CD — Native integration with repository; enables automated regression testing, benchmarking, and validation on every commit
• NuGet package management — Standard .NET dependency resolution; enables modular engine architecture and community contributions

• Monolithic codebase with 600+ files vs. microservices architecture

  • Why: Tight coupling required for real-time trading performance; minimizes latency in order execution path
  • Consequence: Scalability challenges in distributed environments; requires careful refactoring for independent scaling of components

• C# and Python language dual-support in single engine

  • Why: Accommodates both production quants (C#) and data scientists (Python); broadens platform adoption
  • Consequence: Increased complexity in implementation; potential performance overhead in Python binding layer

• Comprehensive regression test suite (100+ algorithm templates)

  • Why: Ensures backward compatibility across engine updates; catches subtle behavioral changes in core systems
  • Consequence: Slow CI/CD pipeline execution; requires significant compute for full validation

• Template-based algorithm examples over abstract factory pattern

  • Why: Lower learning curve for new users; immediate runnable code examples
  • Consequence: High code duplication across templates; maintenance burden when core APIs change

• Real-time market data ingestion (relies on external data providers)
• Broker account management UI (console/API-driven workflows only)
• Machine learning model training (algorithms use pre-trained models or manual indicators)
• Linux kernel optimization or embedded systems trading
• Non-English language support in core engine or documentation

1. Algorithm.CSharp examples have strict dependencies on market data (minute/daily OHLCV); backtesting without proper data provider configured silently returns empty bars. 2) Python algorithms require PythonNet bridge and specific Python version matching .devcontainer/Dockerfile—version mismatch causes cryptic interop failures. 3) Portfolio cash currency must match security currency explicitly; mixed-currency positions need explicit forex conversions or they error silently. 4) Event ordering is critical: Universe.Select() runs before OnData(); modifying holdings in OnData() for universe-selected assets in same bar causes race conditions. 5) Regression tests in Tests/ must have bit-exact output matching; floating-point accumulation changes from compiler optimizations break builds.

• Event-Driven Backtesting — Lean's core design: market ticks trigger OnData() callbacks in strict chronological order, forcing realistic coding patterns (no look-ahead bias, proper state management)—understanding this prevents subtle strategy bugs
• Universe Selection / Dynamic Instrument Addition — Lean's Universe.Select() mechanism allows algorithms to trade dynamic asset lists (S&P 500 members, options chains) that change over time; misconfiguring this causes data mismatches and phantom fills
• Consolidators & Indicator Alignment — Market data arrives at multiple granularities (tick, minute, daily); Lean's Consolidator buffers events and triggers aligned indicator updates—getting consolidation timing wrong causes off-by-one errors in signals
• Slippage & Execution Fill Models — Orders don't execute at submitted price; Lean's configurable fill models (MarketOrderFillModel, etc.) simulate realistic slippage, partial fills, and rejections—missing this overestimates strategy PnL by 5-20%
• Warm-Up & Historical Data Initialization — Indicators need historical context (e.g., SMA-200 needs 200 bars); Lean's SetWarmUp() pre-loads data before live trading starts—forgetting warm-up causes NaN signals on day 1
• Options Greeks & Implied Volatility Chains — Lean auto-computes Greeks (delta, gamma, theta) and IV surfaces for options; understanding chain pricing conventions and greeks calculation prevents exotic arbitrage false-positives
• Continuous Futures Contracts & Contract Rolls — Lean abstracts physical contract expirations via continuous contracts (ESZ for ES Dec future); handling roll events and maintaining position continuity across expiries is non-obvious and errors cause gap losses

• QuantConnect/QCAlgorithm — Official Python API wrapper for Lean; users writing Python strategies import from this repo's modules
• zipline-live/zipline — Similar event-driven backtester in Python; architectural alternative if Python-native preferred over C#/Lean interop
• AlgoTrading101/algorithmic-trading-engine — Educational Python backtester; simpler than Lean for learning event-driven concepts without production complexity
• QuantConnect/Tutorials — Official walkthrough docs and notebooks; essential companion for understanding Lean API and live trading workflows
• QuantConnect/API-v2 — REST/WebSocket API to QuantConnect cloud; Lean can submit algorithms to this for cloud execution and live trading

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for Algorithm.CSharp regression algorithms

The repo contains 100+ C# algorithm files (Algorithm.CSharp/*.cs) but there's no visible test directory structure matching these algorithms. This is critical for a trading engine where algorithm correctness directly impacts financial outcomes. New contributors could create a test suite validating that regression algorithms produce expected outputs, catch regressions early, and serve as documentation for algorithm behavior.

• [ ] Create Tests/Algorithm.CSharp/ directory structure mirroring Algorithm.CSharp/
• [ ] Add unit tests for 5-10 high-value algorithms (e.g., AccumulativeInsightPortfolioRegressionAlgorithm, AddFutureContractWithContinuousRegressionAlgorithm) covering initialization, execution, and edge cases
• [ ] Integrate tests into .github/workflows/gh-actions.yml to run on PR submissions
• [ ] Document test patterns in a TESTING.md file for consistency across future contributions

Add GitHub Actions workflow for Python algorithm validation

The repo supports both C# and Python (.devcontainer/Dockerfile suggests Python support), but .github/workflows/ only shows C#-focused workflows (gh-actions.yml, syntax-tests.yml, api-tests.yml). There's no dedicated Python linting, type checking (mypy), or algorithm execution pipeline. This is a gap for the Python user base and violates the stated 'Python, C#' support claim.

• [ ] Create .github/workflows/python-validation.yml workflow
• [ ] Add steps for: black/pylint formatting checks, mypy type validation, pytest unit tests for Python algorithms
• [ ] Reference any existing Python test files (likely in Algorithm.Python/ if it exists) or create baseline
• [ ] Ensure workflow runs on PR creation and push to main branches

Create integration documentation for the Alphas subdirectory algorithms with parameter guidance

Algorithm.CSharp/Alphas/ contains 11 specialized alpha algorithms (GreenblattMagicFormulaAlpha, VixDualThrustAlpha, etc.) but there's no documentation explaining their purpose, required parameters, market conditions they target, or how to adapt them. New contributors often don't understand when/how to use these templates. This blocks adoption and creates support burden.

• [ ] Create docs/Alphas-Guide.md documenting each algorithm in Alphas/ subdirectory (purpose, market applicability, parameters, historical performance context if available)
• [ ] Add inline code comments to 3-5 complex alpha algorithms explaining key logic (e.g., GreenblattMagicFormulaAlpha sorting/rebalancing strategy)
• [ ] Add a table in README.md linking to Alphas documentation and categorizing them (mean reversion, arbitrage, volatility, etc.)
• [ ] Include a 'Getting Started' section with a simple worked example of modifying one alpha for a new symbol

• Write unit tests for Lean.Lean/Portfolio/CashManager.cs to validate multi-currency conversion edge cases (bid-ask spreads, stale rates, missing pairs)—currently no dedicated test file visible: Portfolio cash handling is security-critical yet tests are sparse; high impact bug prevention
• Add regression algorithm AddFutureOptionsWithMultipleUnderlying.cs that chains options on multiple future contracts simultaneously, validating symbol mapping consistency across contract rolls: Existing tests cover single-underlying; multi-underlying options expose chain subscription bugs caught late in production
• Document and test the data file format/schema for alternative data sources (visible as AddAlphaModel-style algorithms); create Algorithm.CSharp/AlternativeDataLoaderTemplate.cs with step-by-step custom data ingestion walkthrough: Alternative data is a marquee feature but no canonical example; many users struggle with custom data format mapping

The QuantConnect Lean repository shows a moderate security posture with some areas of concern. Critical limitations in this analysis include: (1) No dependency manifests were provided, preventing vulnerability scanning; (2) Dockerfile content unavailable for container security assessment; (3) GitHub Actions workflows present potential automation security risks if improperly configured; (4) Development configurations may leak sensitive data. The large codebase with numerous algorithm files requires careful input validation to prevent injection attacks. Recommendations include implementing dependency scanning, Docker image scanning, reviewing workflow configurations, and establishing a security disclosure policy. The actual security score would improve significantly with dependency analysis and the ability to review complete configuration files.

• Medium · Missing Dependency Manifest Analysis — Repository root - missing dependency manifests. No package dependency files (package.json, requirements.txt, .csproj, packages.config) were provided for analysis. This prevents identification of known vulnerable dependencies, outdated libraries, or supply chain risks. Fix: Provide and regularly scan package manifests using tools like OWASP Dependency-Check, Snyk, or NuGet audit to identify vulnerable dependencies.
• Medium · Docker Image Build Security — .devcontainer/Dockerfile. The .devcontainer/Dockerfile exists but content was not provided. Docker images commonly have security risks including: base image vulnerabilities, missing security scanning, running containers as root, and exposed sensitive environment variables. Fix: Implement Docker security best practices: scan images with Trivy/Grype, use specific base image versions, run as non-root user, minimize layers, and use multi-stage builds.
• Low · GitHub Actions Workflow Security — .github/workflows/. Multiple GitHub Actions workflows are present (.github/workflows/*.yml). These workflows may be vulnerable to token exposure, unsafe script execution, or insecure artifact handling if not properly configured. Fix: Review all workflow files for: proper secret handling, use of GITHUB_TOKEN with minimal permissions, avoidance of untrusted actions, and validation of script inputs.
• Low · Development Configuration Exposure — .vscode/ directory. VsCode and development configuration files (.vscode/settings.json, .vscode/launch.json) are committed. These may contain sensitive information like API endpoints, debug credentials, or internal tool paths. Fix: Move sensitive configurations to local .gitignore'd files or use environment variables. Review current files for exposed credentials or internal URLs.
• Low · Missing SECURITY.md Policy — Repository root. No SECURITY.md file was referenced in the repository structure. This is crucial for responsible vulnerability disclosure and security reporting. Fix: Create a SECURITY.md file with clear instructions for reporting security vulnerabilities responsibly and outline the disclosure timeline.
• Low · Potential Code Injection in Algorithm Files — Algorithm.CSharp/ directory. The repository contains numerous algorithm files (Algorithm.CSharp/) that may accept user-supplied trading parameters or configurations. Without validation, these could be vulnerable to injection attacks. Fix: Implement strict input validation and sanitization for all user-supplied algorithm parameters. Use allowlists for configuration values where possible.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.