2Signals Presentation Brief

Status: start here for presentations, funding conversations and whitepaper prep.

This file is intentionally practical. It does not replace benchmark reports or raw artifacts. It tells you what to say, which numbers to show and which files to ignore unless someone asks for technical due diligence.

One-Sentence Thesis

2Signals is building a correctness-checked, cache-aware strategy computation engine for interactive exploration of large trading-strategy spaces.

The Simple Story

1. Strategy research is iterative: users do not run one backtest, they explore many nearby variants.
2. The hard problem is not only speed. The hard problem is speed with correctness: same dataset, same indicators, same masks, same trades and same P/L.
3. 2Signals now has controlled evidence that compares its results with Freqtrade and records timing boundaries.
4. The strongest current evidence has two parts:
   • a simple EMA side-by-side slice that compares correctness and timing;
   • a more complex futures slice that proves correctness on a larger, non-trivial dataset.
5. The next R&D step is to turn this into a canonical AST/IR and dependency invalidation engine, so strategy edits recompute only what changed.

The Numbers To Remember

Recommended 8-Slide Flow

If You Have Only 5 Minutes

Use this order:

1. "The product problem is interactive strategy exploration."
2. "The technical problem is correctness-preserving reuse."
3. "We now compare 2Signals with Freqtrade for both outputs and timing in controlled boundaries."
4. "The simple EMA slice gives clear side-by-side timing and correctness."
5. "The complex futures slice proves the approach on a non-trivial dataset."
6. "The next funding step is AST/IR plus dependency invalidation, so this works across a broader strategy corpus."

What To Open During Prep

Supporting Files

Open these only when someone asks for details:

Historical Or Low-Priority Files

These are not the first thing to show:

What Not To Claim

Avoid these formulations:

• "2Signals is universally faster than Freqtrade."
• "This is a pure engine-to-engine benchmark."
• "This proves parity for all strategies."
• "This is full authenticated /builder latency."
• "The ML/LLM layer already exists as a proprietary trading model."

Use these instead:

• "In controlled local boundaries, 2Signals and Freqtrade outputs match for the current EMA and complex futures slices."
• "The timing rows are explicitly labeled workflow boundaries."
• "The evidence supports an R&D thesis: correctness-checked reuse for interactive strategy exploration."

Likely Questions And Answers

What I Would Simplify Next

1. Treat this file, 2signals-engine-v0.4.md and 2signals-vs-freqtrade-main-v1.md as the only active entry points.
2. Keep older whitepaper drafts, but clearly label them historical.
3. Stop investing in generated whitepaper/deck automation until the evidence is frozen for a specific external deadline.
4. Improve one benchmark instead of adding five documents: the next useful benchmark is a larger non-EMA side-by-side slice with the same correctness discipline.

2Signals Engine - Current Benchmark Evidence

This is a short, manually maintained summary of the benchmark evidence that is currently useful for product, whitepaper and grant work.

The source of truth is not this document. The source of truth is the benchmark reports and raw JSON artifacts under docs/benchmarks/results/ and benchmarks/results/.

Use this document as the readable front door. A statistic is ready for whitepaper or grant material only when it has all of the following:

1. a named benchmark boundary,
2. a short explanation of what it measures,
3. a short explanation of why it is needed,
4. a correctness status or caveat,
5. a source report or raw artifact path.

What Matters

The current useful evidence is:

1. Main controlled 2Signals vs Freqtrade benchmark summary.
2. Controlled 2Signals EMA variant scaling.
3. Controlled production-like Builder render latency.
4. Controlled Freqtrade boundary references.
5. Complex futures correctness against a frozen Freqtrade reference.

This is enough to explain the current technical direction without turning the whitepaper into its own generated documentation system.

Start with docs/whitepaper/README.md when preparing for a presentation. It contains the talk track, slide flow, key numbers, Q&A and what not to claim.

Start with docs/benchmarks/results/2signals-vs-freqtrade-main-v1.md when the question is: "do we compare 2Signals and Freqtrade for both correctness and time?" It links the detailed source reports and keeps boundary caveats visible.

Current Results

Metric Definitions

Reproduction Commands

Use these when the evidence needs to be checked again:

pnpm bench:compare:ema:2signals-scale:correctness
pnpm bench:compare:ema:variant-scale:matrix
pnpm bench:compare:ema:freqtrade-persistent-variant-scale
pnpm bench:equivalence:complex:current-engine-export:controlled
pnpm bench:builder:production

Methodological Rules

• Do not claim a universal 2Signals vs Freqtrade ratio.
• Do not call workflow boundaries pure engine-to-engine comparisons.
• Do not claim strict linear scalability.
• Do not count the same dataset candles once per strategy variant.
• Keep correctness and timing boundaries separate.
• Keep complex futures evidence visible; it is more meaningful than another tiny EMA-only example.

What Not To Maintain

We do not need a daily-generated whitepaper pipeline right now.

Avoid maintaining:

• a generated whitepaper evidence manifest,
• a generated deck markdown file,
• a generated public evidence JSON file,
• a dedicated whitepaper validator,
• repeated markdown files that say the same thing.

The next useful work should improve benchmark quality, correctness scope and result visibility, not document generation.

2Signals Evidence Package v0.2

Status: working package for whitepaper publication and deep-tech funding preparation.

This document connects the whitepaper summaries, benchmark artifacts and the research roadmap. It is an index and claim guardrail, not another source of benchmark truth.

For presentation prep, start with docs/whitepaper/README.md. For day-to-day benchmark numbers, use docs/whitepaper/2signals-engine-v0.4.md. Use this file when you need to know which supporting documents exist and how to interpret them.

How To Read This Package

Current State

Statistic Glossary

Evidence baseline status: local evidence rows now span two measured baselines. The EMA scale and production-like Builder rerun were recorded on f771cf2ea946f9cac03392f2b1ea06b4d8185259; the complex frozen Freqtrade boundary and current-engine export were recorded on b261ffb7469f6a95c3c6611b9340800ea988caab. The freeze ledger records the raw artifact paths and hashes. External publication should still use a tagged evidence commit or exported artifact bundle.

Publication-Safe Claim Ladder

Strong claims

These can be used in the whitepaper with the stated boundary and rerun caveats:

Qualified claims

These are usable only with careful wording:

Not yet publication-ready

• Unqualified complex strategy parity across all product/export paths. The fresh controlled Freqtrade boundary and current-engine export pass locally, but the historical exported-fixture report remains a useful mismatch fixture and the result is still not full authenticated /builder flow evidence.
• Full production /builder authenticated user-flow latency.
• Cross-engine Freqtrade equivalence for 100/500/1000 variants.
• Production browser memory and IndexedDB footprint.
• Cache eviction behavior.
• Multi-timeframe and multi-asset correctness.
• Real-market large dataset scaling beyond the current frozen EMA fixture.

Deep-Tech Funding Thesis

The strongest funding thesis is not that 2Signals is merely a faster backtester. The stronger technical thesis is:

2Signals is developing a correctness-checked, cache-aware strategy computation system for interactive exploration of large strategy variant spaces.

This thesis is supported by current evidence and leaves credible R&D work:

• deterministic strategy representation;
• reusable computation over related strategy variants;
• correctness artifacts that separate dataset correctness from strategy correctness;
• boundary-aware comparison with Freqtrade workflows;
• production-like rendering evidence;
• planned canonical AST/IR and dependency invalidation graph.

Proposed R&D Work Packages

Evidence Rerun Status

The current evidence was rerun locally across the measured baselines listed in docs/whitepaper/evidence-freeze-v0.2.md. The raw benchmark directories are local artifacts under benchmarks/results and .benchmark-artifacts; if they are needed outside this workspace, export or archive them explicitly.

Completed in the rerun:

1. Static validation and benchmark contract tests passed.
2. 2Signals scale v2 correctness, timing and report regenerated.
3. 2Signals 10-variant boundary, Freqtrade separate-process CLI boundary and Freqtrade strategy-list boundary regenerated where applicable.
4. Side-by-side matrix regenerated with 10 shared EMA variants and 0 correctness mismatches.
5. Production-like Builder benchmark passed in production build with 70 measured samples and 0 failures.

Still pending before external publication:

1. Commit these refreshed reports and docs.
2. Decide whether raw ignored benchmark artifacts should be exported as a release bundle.
3. Tag the evidence baseline or create a signed publication package.
4. Regenerate benchmark-findings-v1.md if it should become the primary narrative report instead of the boundary-specific reports.

Command set used or completed during the local rerun:

pnpm exec tsc --noEmit
pnpm exec vitest run src/lib/benchmarks/report-script.test.ts src/lib/benchmarks/production-builder-benchmark-script.test.ts src/lib/benchmarks/controlled-variant-scale-comparison-script.test.ts --reporter=dot
pnpm bench:compare:ema:2signals-scale:correctness
pnpm bench:compare:ema:2signals-scale
pnpm bench:compare:ema:2signals-scale:report
pnpm bench:compare:ema:variant-scale
pnpm bench:compare:ema:variant-scale:report
pnpm bench:compare:ema:freqtrade-variant-scale
pnpm bench:compare:ema:freqtrade-variant-scale:report
pnpm bench:compare:ema:freqtrade-persistent-variant-scale
pnpm bench:compare:ema:freqtrade-persistent-variant-scale:report
pnpm bench:compare:ema:variant-scale:matrix
pnpm bench:builder:production
git diff --check

pnpm bench:builder:production required local server permissions in this sandboxed Codex environment because it starts next start on 127.0.0.1.

Next Publication Priority

Recommended next publication slice: produce an external review bundle from the evidence freeze.

Goal:

• tag or commit the benchmark evidence state;
• run pnpm whitepaper:review-bundle to export docs, reports, selected raw results and ignored .benchmark-artifacts into a review archive;
• verify exported artifact hashes with the generated SHA256SUMS;
• package the whitepaper, evidence package, freeze ledger, benchmark reports and raw artifacts through the review bundle;
• separate controlled evidence from product and marketing claims.

Minimum acceptance:

Funding Narrative Guardrails

Use:

• correctness-checked computation;
• reproducible benchmark artifacts;
• deterministic strategy representation;
• interactive strategy exploration;
• cache-aware reuse;
• boundary-aware external validation;
• research roadmap for AST, IR, invalidation and ML-assisted exploration.

Avoid:

• unqualified speed claims;
• algorithm-only claims from workflow benchmarks;
• claims of full Freqtrade equivalence at scale;
• claims that the LLM or ML layer trades autonomously;
• claims that a proprietary ML model already exists;
• claims that production /builder latency has been fully measured.

Immediate Open Items

2Signals Grant Evidence Summary v0.2

Status: short review brief for grant, funding and pitch conversations.

Evidence anchor: evidence/2signals-engine-v0.2-2026-07-27 at commit f4bf1db60d6dfc400fff818ef62ec22d5bf283a4.

External artifact bundle: /private/tmp/2signals-evidence-v0.2-2026-07-27.tgz, SHA-256 4b4842b1dc80963d7edba255ad8c4b5a35f4d590ad8ba4bb0189492e9c070ecd.

This summary is intentionally conservative. It is a grant/pitch bridge over the technical whitepaper and benchmark evidence, not a replacement for the raw artifacts.

One-Sentence Thesis

2Signals is developing a correctness-checked, cache-aware strategy computation system for interactive exploration of large trading-strategy variant spaces.

Why This Is Deep-Tech Work

Backtesting tools are often evaluated only by final trade output or total run time. 2Signals is pursuing a more structured engine model:

• deterministic strategy execution with explicit correctness artifacts;
• dataset correctness separated from strategy correctness;
• reusable computation across related strategy variants;
• boundary-aware comparison with Freqtrade workflows;
• production-like UI latency measurement for interactive strategy review;
• a roadmap toward a canonical strategy AST, normalized IR and dependency invalidation graph.

The technical risk is real and appropriate for R&D funding: the current product model works, but it is not yet the final canonical strategy representation; the current cache model is key-based, not a complete computation graph; and broader multi-timeframe, multi-asset and production-flow validation is still planned.

Current Evidence Snapshot

How To Interpret The Statistics

Publication-Safe Claims

Safe wording:

• 2Signals has a repeatable, correctness-gated benchmark evidence framework.
• 2Signals demonstrates reusable computation over related EMA strategy variants in the tested Node/service boundary.
• The current evidence includes controlled Freqtrade boundary references, but they are workflow references rather than pure engine-to-engine measurements.
• The complex futures slice now has a current controlled correctness reference against fresh Freqtrade output.
• Production-like Builder rendering has been measured in a controlled harness that uses production chart, metrics and trades components.

Avoid:

• unqualified claims that 2Signals is faster than Freqtrade;
• claims of full Freqtrade equivalence for all strategies;
• claims that the benchmark is full authenticated production /builder latency;
• claims that a proprietary ML model already exists;
• claims that cache reuse solves all incremental recomputation.

Proposed R&D Work Packages

Evidence References

Recommended Use

Use this document as a two-minute entry point for reviewers. For diligence, attach the evidence bundle and direct technical reviewers to the freeze ledger first, then to the whitepaper and benchmark reports.

2Signals Evidence Freeze v0.2

Status: prepared for publication/funding review.

Freeze label: evidence/2signals-engine-v0.2-2026-07-27.

This document is an evidence ledger for the technical whitepaper and funding materials. It freezes the paths, measured commits, raw artifacts, SHA-256 hashes and reproduction commands for the current controlled benchmark evidence. It is not a marketing summary and does not introduce new benchmark claims.

Scope

The measured evidence rows currently span two local baselines:

• f771cf2ea946f9cac03392f2b1ea06b4d8185259 for the controlled EMA scale and production-like Builder render rerun recorded earlier in the evidence package.
• b261ffb7469f6a95c3c6611b9340800ea988caab for the complex frozen Freqtrade boundary and current-engine Builder-equivalent export.

The freeze commit or tag should identify the final documentation state. Because raw benchmark directories are intentionally ignored by git, external review also needs an exported artifact bundle or access to the local artifact paths listed below.

Primary Complex Evidence

Report file hashes captured before this freeze document was added:

Per-candle artifact directories:

Correctness Summary

Dataset hashes:

Timing Boundaries

The timing rows below are boundary labels, not pure engine-to-engine claims.

Reproduction Commands

Use these commands from the repository root:

pnpm exec vitest run src/lib/benchmarks/complex-current-engine-export-report-script.test.ts src/lib/benchmarks/complexPerCandleArtifacts.test.ts src/lib/benchmarks/complex-freqtrade-boundary-report-script.test.ts src/lib/benchmarks/report-script.test.ts
pnpm exec tsc --noEmit --pretty false
pnpm exec eslint benchmarks/equivalence/builder-complex-current-engine-export.bench.ts benchmarks/equivalence/builder-complex-freqtrade-frozen-boundary.bench.ts scripts/benchmarks/report-complex-current-engine-export.mjs scripts/benchmarks/report-complex-freqtrade-frozen-boundary.mjs src/lib/benchmarks/complexPerCandleArtifacts.ts src/lib/benchmarks/complexPerCandleArtifacts.test.ts src/lib/benchmarks/complex-current-engine-export-report-script.test.ts src/lib/benchmarks/complex-freqtrade-boundary-report-script.test.ts
pnpm exec prettier --check benchmarks/equivalence/builder-complex-current-engine-export.bench.ts benchmarks/equivalence/builder-complex-freqtrade-frozen-boundary.bench.ts scripts/benchmarks/report-complex-current-engine-export.mjs scripts/benchmarks/report-complex-freqtrade-frozen-boundary.mjs src/lib/benchmarks/complexPerCandleArtifacts.ts src/lib/benchmarks/complexPerCandleArtifacts.test.ts src/lib/benchmarks/complex-current-engine-export-report-script.test.ts src/lib/benchmarks/complex-freqtrade-boundary-report-script.test.ts docs/benchmarks/results/controlled-complex-current-engine-export-v1.md docs/benchmarks/results/controlled-complex-freqtrade-frozen-boundary-v1.md docs/whitepaper/2signals-engine-v0.2.md docs/whitepaper/evidence-package-v0.2.md docs/whitepaper/evidence-freeze-v0.2.md
pnpm bench:equivalence:complex:freqtrade-frozen-boundary:controlled
pnpm bench:equivalence:complex:current-engine-export:controlled
pnpm bench:report
git diff --check

The Freqtrade boundary requires the local Freqtrade repository and local frozen Freqtrade data used by the runner. It does not fetch exchange data during the measured phase.

Archive Checklist

Before sharing outside the workspace:

1. Commit the code, reports and whitepaper docs.
2. Tag the commit with evidence/2signals-engine-v0.2-2026-07-27.
3. Export ignored raw artifacts from benchmarks/results and .benchmark-artifacts.
4. Verify the exported files with the SHA-256 hashes in this document.
5. Include this document, docs/whitepaper/evidence-package-v0.2.md, docs/whitepaper/2signals-engine-v0.2.md and the benchmark result reports.
6. Keep wording boundary-aware: controlled evidence, not broad performance or full production-flow claims.

Suggested local archive command:

pnpm whitepaper:review-bundle

The generated archive is written outside the repository by default under /private/tmp/2signals-review-bundles. It contains README.md, MANIFEST.json and SHA256SUMS files. To generate a smaller documentation-only review bundle without ignored raw artifact directories:

REVIEW_BUNDLE_INCLUDE_RAW=0 pnpm whitepaper:review-bundle

Methodology Guardrails

• Do not describe the complex current-engine export as a full authenticated /builder browser export.
• Do not compare the 2Signals service timing directly to the Freqtrade child process timing as a pure engine ratio.
• Do not include per-candle artifact export time in the backtest boundary.
• Do not use unqualified terms such as "10x faster" or "engine advantage".
• Do state that raw artifacts are ignored locally and must be archived explicitly for external review.
• Do state the exact dataset hashes, measured commits and boundary names next to each claim.

2Signals vs Freqtrade Main Benchmark v1

Status: current front-door report for controlled 2Signals/Freqtrade benchmark evidence.

This document exists to answer one practical question:

Do we have benchmark evidence that compares 2Signals and Freqtrade for both correctness and timing?

Answer: yes, in controlled local boundaries. The current evidence is strongest when read as two complementary slices:

1. a simple EMA variant side-by-side benchmark with detailed timing and correctness;
2. a more complex futures correctness benchmark with direct 2Signals and Freqtrade timing boundaries.

This is a manually maintained summary. The source of truth remains the source reports and raw artifacts listed below.

Source Reports

Main Snapshot

What The Statistics Mean

EMA Side-By-Side Evidence

Boundary: controlled local BTC/USDT 5m EMA crossover family.

Interpretation:

• This is the cleanest correctness-plus-timing side-by-side benchmark.
• It is deliberately small and simple, so it should not be presented as a universal strategy benchmark.
• It proves that the benchmark infrastructure can compare 2Signals and Freqtrade outputs while recording timing boundaries.

Complex Futures Evidence

Boundary: controlled local futures strategy over frozen OHLCV/funding artifacts.

Interpretation:

• This is the strongest current non-trivial correctness evidence.
• It compares fresh 2Signals output with fresh Freqtrade output on the same frozen data.
• The timing rows are boundary references, not a universal engine ratio.
• The current report does not include full authenticated /builder UI flow.

Neutral Boundary Ratios

These ratios are included only as boundary descriptors. They must not be used without the boundary labels.

What This Report Supports

Publication-safe wording:

• 2Signals has controlled benchmark evidence that compares correctness and timing against Freqtrade in named local boundaries.
• The EMA side-by-side slice passes correctness for 10 shared variants and records both 2Signals and Freqtrade workflow timing.
• The complex futures slice passes fresh 2Signals vs fresh Freqtrade correctness on 181,447 candles and 123 compared trades.
• Freqtrade boundary references are workflow measurements, not pure algorithm-only measurements.

Avoid:

• "2Signals is X times faster than Freqtrade" without boundary labels.
• "Pure engine-to-engine comparison" for the current Freqtrade workflow rows.
• "Full production /builder latency" for the controlled Builder-equivalent or BacktestService timings.
• Generalizing the EMA result to all strategies, all exchanges or all datasets.

What Seems Unnecessary Right Now

The useful evidence should stay focused on benchmark results, correctness and reproduction. The following are low-value unless there is a specific publication need:

Keep:

• raw benchmark JSON artifacts;
• correctness artifacts;
• matrix reports;
• the Freqtrade boundary audit;
• the complex futures reports;
• the production-like Builder UI latency report.

Recommended Next Step

Use this document as the main benchmark reference in the whitepaper and funding materials, then improve the benchmark itself rather than adding more document generation:

1. rerun the main EMA and complex slices on a clean tagged evidence commit;
2. export the raw artifacts listed by the source reports;
3. add one larger non-EMA side-by-side timing slice only when correctness can be enforced with the same discipline.

controlled-ema-2signals-variant-scale-btcusdt-5m-v2

Status: generated controlled 2Signals-only variant scale benchmark. This report is neutral and limited to the Node/service boundary described below.

Goal

Measure how the 2Signals Node/service engine path scales across related EMA strategy variants, including cache, memory and cleanup diagnostics.

Variant Space

• Version: ema-grid-v2.
• Fast EMA periods: 20 through 69.
• Slow EMA periods: 200, 180, 220, 160, 240, anchored around EMA(200).
• Operator combinations: crossed_above/crossed_below, crossed_above/crossed_above, crossed_below/crossed_above, crossed_below/crossed_below.
• Deterministic order: slow period, operator pair, fast period.
• The v2 space uses slow-period combinations because 1000 sensible unique variants cannot be produced from fast EMA periods alone on a 620-candle fixture.

Dataset

• Pair: BTC/USDT
• Timeframe: 5m
• Candle count: 620
• Start: 2023-12-31T07:20:00.000Z
• Backtest start: 2024-01-01T00:00:00.000Z
• End: 2024-01-02T10:55:00.000Z
• Dataset hash: 499155587500a60de08fe8edd922bcd432d5ce36e80b106814898955264ae5fe

Correctness Policy

• Correctness runs before timing and outside the measured benchmark phase.
• Dataset correctness is checked once per unique dataset hash and is not repeated for every strategy variant.
• Dataset correctness confirms dataset hash, pair, timeframe, timerange, candle count, first/last timestamp, OHLCV checksum and a dedicated fixture-to-adapter OHLCV comparison.
• Strategy correctness compares indicator series, entry/exit masks, signal timestamps, trades, fees, P/L and result hashes.
• 10 variants use full strategy correctness for every variant plus full result-hash validation.
• 100/500/1000 variants use full result-hash validation for every variant plus deterministic sampled strategy correctness.

Dataset Correctness

Strategy Correctness

Timing Boundary

• Boundary: 2signals-node-service-sequential-variant-scale-v2.
• Includes local frozen candles, indicator computation, cache lookup, rule/signal evaluation, trade simulation and result preparation.
• Excludes UI, chart rendering, IndexedDB, network, Freqtrade, visualization and artifact export.

Reuse Scenarios

• A. Cold variant sweep: cache cleared before the sweep.
• B. Warm identical sweep: identical variant space run again against the existing cache.
• C. Partial reuse sweep: deterministic parameter changes preserve some indicator series and change others.
• D. Return to previous variants: deterministic sampled subset of previous variants is run again.
• E. Single-parameter invalidation: baseline, one dependent parameter change, and return to the baseline configuration.

Scale Curve

Scenario Timings

Cache Diagnostics

• Cache diagnostics in this table are aggregate totals across measured samples for each scale level, not a single-sweep value.
• Cold sweeps start with an empty cache, but related variants can still reuse cache entries created earlier in the same sweep.
• Warm 100% cache hit rate means measured cache reads hit; per-variant orchestration, rule/signal handling, simulation, metrics shaping and diagnostics still run.

Memory Methodology

• Memory uses Node process.memoryUsage() from this benchmark process.
• The benchmark invokes global.gc?.() around sweeps and cleanup when available; this run recorded gcAvailable=0 and gcRan=false, so GC was not forced.
• These numbers are useful for relative local process diagnostics, not total application memory.
• Observed sweep heap high-water mark is the max of heapUsed before and after each measured sweep; it is not a continuously sampled peak.
• Cleanup heap delta is heapUsed after cleanup - heapUsed before cleanup. The raw JSON field remains retainedHeapBytes for backward compatibility, but it should not be interpreted as retained heap from a stable process baseline.
• Cache size is a benchmark cache mock JSON serialization estimate from Buffer.byteLength(JSON.stringify(entries), "utf8"); it is not IndexedDB size or total process memory.

Scaling Growth

Invalidation And Cleanup

Frozen Freqtrade Boundary Reference

• Freqtrade --strategy-list, 10 variants: total workflow median 5.38 s.
• Freqtrade separate process per variant, 10 variants: total workflow median 35.27 s.
• These are frozen boundary references only; this report does not extrapolate Freqtrade to 100/500/1000 variants.

Limitations

• This is one local BTC/USDT 5m fixture with 620 candles.
• The v2 variant grid intentionally expands slow EMA periods around 200 to reach 1000 deterministic variants.
• The benchmark does not include browser rendering, auth, Apollo, IndexedDB, charting or Freqtrade execution.
• Cache eviction is not implemented in this benchmark cache mock.

Neutral Conclusions

All measured v2 samples and correctness gates passed. Timing values should be interpreted only for the explicitly named 2Signals Node/service boundary.

Artifacts

• Result JSON: benchmarks/results/controlled-ema-2signals-variant-scale-btcusdt-5m-v2/2026-07-26T22-21-05-858Z/2026-07-26T22-21-05-858Z.controlled-ema-2signals-variant-scale-btcusdt-5m-v2.json
• Correctness report: benchmarks/results/controlled-ema-2signals-variant-scale-btcusdt-5m-v2/2026-07-26T22-21-05-858Z/controlled-ema-2signals-variant-scale-btcusdt-5m-v2.correctness.json
• Dataset metadata: benchmarks/results/controlled-ema-2signals-variant-scale-btcusdt-5m-v2/2026-07-26T22-21-05-858Z/dataset.metadata.json
• Strategy metadata: benchmarks/results/controlled-ema-2signals-variant-scale-btcusdt-5m-v2/2026-07-26T22-21-05-858Z/strategy.metadata.json
• Docs report: docs/benchmarks/results/controlled-ema-2signals-variant-scale-btcusdt-5m-v2.md

controlled-ema-variant-scale-side-by-side-v1

Status: generated neutral side-by-side matrix for the controlled EMA variant scale benchmark. Final scale comparison status: passed.

These measurements describe different execution boundaries and must not be interpreted as a pure engine-to-engine speed comparison.

Generated at: 2026-07-26T22:36:04.392Z

Experiment validation

The report is generated only after timing metadata checks pass. Dataset correctness and strategy correctness can pass or fail independently; any failed dataset check or strategy variant sets the final scale comparison status to failed.

Correctness validation

Measurement boundaries

2Signals:

• in-process engine/service workflow;
• local frozen data;
• no UI;
• no network fetch;
• no separate process startup for each variant;
• includes indicator computation, signals, simulation and result preparation;
• uses the existing cache and reuse mechanisms.

Freqtrade:

• separate local Python/Freqtrade process for each variant;
• complete result cache disabled;
• local data;
• includes process startup, initialization, backtesting, export and parsing;
• freqtradeBacktestingMs is a marker reported around Freqtrade backtesting.start(), not a full isolated algorithm-only measurement.

Main Matrix

Correctness gate for the shared 10-variant level: passed.

2Signals in-process variant workflow

• Total workflow median: 20.25 ms.
• Per-variant median: 1.4 ms.
• Indicator cache hits/misses: 90 / 110.
• Indicator hit rate: 45%.
• Reused EMA(200) indicator series: 90.
• Recomputed fast EMA indicator series: 110.
• Correctness: passed.

Freqtrade process-based variant workflow

• Total workflow median: 35.52 s.
• Total child process median: 34.33 s.
• Reported backtesting median: 2.91 s.
• Per-variant process median: 3.39 s.
• Per-variant reported backtesting median: 287.39 ms.
• Correctness: passed.

Ratio Metrics

The following ratios are neutral descriptions of observed workflow timings. The numerator and denominator boundaries are intentionally different and are shown explicitly.

Correctness

Per-variant correctness

Future scaling matrix

Methodological limitations

• 2Signals is measured as an in-process workflow while Freqtrade is measured through child processes.
• There is no isolated Freqtrade algorithm-only boundary in this report.
• Python and Freqtrade initialization are part of the Freqtrade total process workflow.
• Filesystem and OS page cache can affect repeated local result reads.
• UI rendering is excluded from both scale slices.
• Both slices use local frozen fixtures.
• The strategy is a simple EMA crossover family.
• The side-by-side level covers one pair and one timeframe only.
• Freqtrade memory usage is not measured in this slice.
• There is no long-running Freqtrade worker/API benchmark in this report.

Neutral conclusions

• Final correctness status for the shared 10-variant EMA scale level: passed.
• 2Signals executed the variants inside one process and reused part of the indicator results.
• Freqtrade executed every variant as a separate local process.
• The observed timings reflect these different execution models.
• The next benchmark step should investigate larger variant counts, memory, and a closer Freqtrade execution boundary if it can be obtained without patching Freqtrade internals.

Source artifacts

controlled-ema-freqtrade-boundaries-v1

Status: neutral audit and boundary report for controlled Freqtrade EMA variant scale execution.

Audit Result

Decision: implement the nearest natural supported boundary through freqtrade backtesting --strategy-list, not a custom persistent server. The benchmark still uses a benchmark-only wrapper only to inject local fixture markets and record timings around existing Freqtrade functions.

Measurement Boundaries

• CLI separate-process boundary: one local Python/Freqtrade process per variant; existing reference remains unchanged.
• Persistent/single-process boundary: one local Python/Freqtrade process per sample; all 10 generated strategy classes run through one backtesting.start() call via --strategy-list.
• Both boundaries use the same frozen dataset, EMA fast 50..59, EMA slow 200, fee, stake and risk config.
• Both boundaries disable Freqtrade result cache with --cache none; OS page cache is still outside benchmark control.

Side-by-side Boundary Matrix

Phase Timings

Correctness

• Reused scale correctness report: benchmarks/results/controlled-ema-variant-scale-side-by-side-v1/2026-07-26T22-35-28-384Z/controlled-ema-variant-scale-side-by-side-v1.correctness.json.
• Persistent correctness status: passed.
• Persistent mismatch count: 0 in the first sample; all samples require the same gate.

Boundary Ratio Metrics

Artifacts

• 2Signals result JSON: benchmarks/results/controlled-ema-variant-scale-btcusdt-5m-v1/2026-07-26T22-27-15-168Z/2026-07-26T22-27-15-168Z.controlled-ema-variant-scale-btcusdt-5m-v1.json
• Persistent result JSON: benchmarks/results/controlled-ema-freqtrade-persistent-variant-scale-btcusdt-5m-v1/2026-07-26T22-22-44-618Z/2026-07-26T22-22-44-618Z.controlled-ema-freqtrade-persistent-variant-scale-btcusdt-5m-v1.json
• CLI result JSON: benchmarks/results/controlled-ema-freqtrade-variant-scale-btcusdt-5m-v1/2026-07-26T22-27-23-697Z/2026-07-26T22-27-23-697Z.controlled-ema-freqtrade-variant-scale-btcusdt-5m-v1.json
• Persistent docs report: docs/benchmarks/results/controlled-ema-freqtrade-persistent-variant-scale-btcusdt-5m-v1.md

Limitations

• Backtesting is an internal Freqtrade implementation class even though --strategy-list is a public CLI workflow.
• The benchmark wrapper patches Freqtrade functions only to record timings and fixture markets; it does not replace backtesting logic.
• backtesting.start() includes multiple internal Freqtrade phases and is not a pure engine timer.
• The controlled EMA fixture is small and synthetic.
• Results are not marketing claims and should not be generalized to hyperopt, live trading, or larger datasets without separate runs.

Neutral Conclusions

• Freqtrade does provide a natural single-process boundary for this comparison through public --strategy-list backtesting.
• The persistent boundary reduces repeated process and initialization work by construction, but remains a Freqtrade workflow boundary, not a pure algorithm-only engine benchmark.
• The separate-process CLI boundary remains useful as the user-facing invocation reference.

Controlled Complex Current-Engine Export v1

Status: passed. This report creates a fresh current-engine Builder-equivalent 2Signals export from frozen local data and compares it to the fresh Freqtrade frozen boundary reference.

This is a controlled engineering artifact, not a full authenticated /builder UI export. It exists to replace the historical browser-backtester-v18 target with current-engine 2Signals output checked against the fresh per-candle Freqtrade boundary.

Scope

Boundary

Trade Correctness

Per-Candle Correctness

Status: passed. Dataset correctness is checked once for the unique frozen dataset hash; strategy correctness compares indicators, masks, signal timestamps, trades and numeric trade metrics.

Per-Pair Artifact Summary

Timing Boundary

Artifacts

Limitations

• This step does not execute Freqtrade. It uses the latest fresh Freqtrade frozen boundary JSON as the reference.
• This is a Builder-equivalent current-engine export, not a full auth, route and browser UI export.
• Timing is reported only for the current 2Signals export workflow and should not be compared to Freqtrade process timings from this document alone.

Controlled Complex Freqtrade Frozen Boundary v1

Status: passed. This report reruns Freqtrade from the local frozen complex futures data and compares it to a fresh 2Signals run on the same market-data hash.

This is a controlled engineering artifact, not a marketing comparison. It separates the fresh Freqtrade boundary from the older exported Freqtrade target stored in the Builder diagnostics fixture.

Scope

Boundaries

Dataset

Correctness

Per-Candle Correctness

Status: passed. Dataset correctness is checked once for the unique frozen dataset hash; strategy correctness compares indicators, masks, signal timestamps, trades and numeric trade metrics.

Per-Pair Artifact Summary

Per-Candle Artifact Paths

Timing Boundary

Freqtrade Artifacts

Funding Diagnostics: Fresh 2Signals vs Fresh Freqtrade

No funding/profit mismatches were detected in the fresh comparison.

Funding Diagnostics: Fresh Freqtrade vs Exported Target

Limitations

• The Freqtrade boundary is still a local Python process with Freqtrade initialization, strategy loading and result serialization included in the reported child-process timing.
• The report uses local Freqtrade feather data; it does not fetch from Binance during measurement.
• The funding formula section is diagnostic only. Correctness status is based on the fresh trade comparison, not on replacing engine output with the diagnostic formula.

Benchmark Findings V1

Status: final methodological audit for controlled-ema-2signals-variant-scale-btcusdt-5m-v2.

This document freezes the publication-safe interpretation of the current benchmark artifacts. It does not add new benchmark data, does not change raw results, and does not change runner, scenario, cache or engine behavior.

Evidence Sources

• Scale v2 report: docs/benchmarks/results/controlled-ema-2signals-variant-scale-btcusdt-5m-v2.md
• Scale v2 raw result: benchmarks/results/controlled-ema-2signals-variant-scale-btcusdt-5m-v2/2026-07-26T11-09-07-054Z/2026-07-26T11-09-07-054Z.controlled-ema-2signals-variant-scale-btcusdt-5m-v2.json
• Scale v2 correctness report: benchmarks/results/controlled-ema-2signals-variant-scale-btcusdt-5m-v2/2026-07-26T11-09-07-054Z/controlled-ema-2signals-variant-scale-btcusdt-5m-v2.correctness.json
• Dataset metadata: benchmarks/results/controlled-ema-2signals-variant-scale-btcusdt-5m-v2/2026-07-26T11-09-07-054Z/dataset.metadata.json
• Strategy metadata: benchmarks/results/controlled-ema-2signals-variant-scale-btcusdt-5m-v2/2026-07-26T11-09-07-054Z/strategy.metadata.json
• Benchmark implementation and report renderer: benchmarks/comparison/controlled-ema-btcusdt.bench.ts
• Production render matrix: benchmarks/results/builder-production-like-production/2026-07-23T15-05-03-641Z/benchmark-matrix.md

Tested System Boundary

The scale v2 timing boundary is 2signals-node-service-sequential-variant-scale-v2.

It includes:

• local frozen candles already available in process;
• per-variant BacktestService.runBacktest;
• indicator computation and cache lookup through the benchmark cache mock;
• rule and signal evaluation;
• trade simulation;
• result preparation performed by the service path;
• benchmark sequence orchestration and diagnostics around the sequential sweep.

It excludes:

• browser UI, chart rendering and React rendering;
• IndexedDB and production browser cache layers;
• exchange, Supabase, Apollo and network requests;
• Freqtrade execution;
• correctness artifact generation and export;
• visualization and whitepaper/pitch-deck rendering.

totalDurationMs for a scale sweep starts immediately before the sequential variant loop and ends after every variant result is available. It includes per-variant wrapper overhead and diagnostics around the loop. The per-variant median comes from each internal runTwoSignalsEngine sample's totalDurationMs; that inner metric starts after variant-specific signal/config construction and ends after BacktestService.runBacktest.

Publication interpretation: this is a Node/service workflow benchmark, not a full product latency benchmark and not a pure mathematical indicator benchmark.

Dataset And Strategy Scope

Dataset:

Strategy variant space:

The v2 grid uses slow EMA combinations around EMA(200) because 1000 meaningful unique variants cannot be produced from fast EMA 20-69 alone on the 620-candle fixture.

Correctness Summary

Correctness is executed before timing and outside the measured benchmark phase.

Dataset correctness is now reported separately from strategy correctness. Dataset correctness is executed once for the unique dataset hash and confirms metadata, timestamp boundaries, an OHLCV checksum and a dedicated fixture-to-adapter OHLCV comparison.

Strategy correctness compares variant-dependent outputs only: EMA series, entry/exit masks, signal timestamps, trades, fees, P/L and result hashes. It does not recount the same OHLCV candles for every variant.

Aggregate correctness status: passed for 1 unique dataset, 1610 checked strategy variants, 86800 indicator values, 86800 mask values, 140 signal timestamps, 42 trade comparisons, 1610 result-metric comparisons and 0 mismatches.

Correctness confirms:

• deterministic internal equivalence between baseline and candidate 2Signals artifacts for the checked scope;
• dataset correctness for the unique dataset hash exactly once;
• full result-hash stability for every variant in 10/100/500/1000 levels;
• full strategy equality for the 10-variant level;
• sampled strategy equality for the 100/500/1000 levels.

Correctness does not confirm:

• full strategy-artifact validation for every 100/500/1000 variant;
• equivalence to Freqtrade for 100/500/1000 scale levels;
• browser rendering correctness;
• production IndexedDB/cache correctness;
• behavior on real exchange data beyond this frozen fixture.

Production Render Findings

The production render benchmark is separate from scale v2. Its latest production-like run is builder-production-like-render-v1, executed through the repeatable production script in:

benchmarks/results/builder-production-like-production/2026-07-23T15-05-03-641Z/benchmark-matrix.md

Boundary:

• production build via next build and next start;
• benchmark route enabled only with ENABLE_PRODUCTION_BENCHMARK_ROUTES=true;
• real BacktestDashboardChartComponent;
• real BacktestChartPrimary and SyncedChart;
• real BacktestResultsMetrics;
• real BacktestResultsTrades and BacktestResultsTradesTable;
• minimal provider shell and frozen fixtures;
• no full auth flow, Apollo subscriptions, exchange fetch or Supabase fetch.

Production-like measured results:

Publication interpretation: these are production-like fully-rendered UI latencies for the benchmark harness, not full authenticated /builder user-flow latencies.

2Signals Variant Scaling Findings

Scale v2 measured levels use different measured run counts:

• 10 variants: 3 warm-ups, 10 measured runs;
• 100 variants: 3 warm-ups, 10 measured runs;
• 500 variants: 3 warm-ups, 5 measured runs;
• 1000 variants: 3 warm-ups, 3 measured runs.

The cold full-sweep scale curve:

Growth factors:

Publication interpretation: the data supports "approximately linear in the tested range" for the stated Node/service cold full-sweep boundary. It does not support the broader phrase "linear scalability" without the tested-range and boundary qualifiers.

Cold Vs Warm Interpretation

Definitions:

• Cold sweep: cache is cleared before the sweep starts. This does not mean there is no reuse inside the sweep. Related variants can create cache entries that later variants reuse within the same cold sweep.
• Warm identical sweep: the identical variant space is run again after the cold sweep. Measured cache reads hit, but the workflow still executes per-variant orchestration, rule/signal work, trade simulation, metrics shaping, diagnostics and result object traversal.

Why warm is not faster for 500 and 1000:

Confirmed:

• warm reads hit the benchmark cache for the measured cache reads;
• rule/signal handling, simulation and result preparation still execute for every variant;
• cold sweeps have nonzero cache hit rates because reuse occurs inside the sweep;
• 500 and 1000 warm runs have higher total median than cold in this raw run.

Supported inference:

• the larger warm totals are consistent with measurement noise, JIT state, garbage collection behavior, memory pressure, larger cache object graphs and diagnostic overhead;
• 1000 warm has higher variance (187.12 ms stddev) than 1000 cold (75.54 ms stddev), so one should not infer that warm execution is inherently slower from this single local run.

Unknown:

• isolated diagnostics overhead;
• isolated memory-measurement overhead;
• isolated cleanup overhead per measured sweep;
• whether an --expose-gc run with a stable memory baseline would change the cold/warm ordering.

Frozen Freqtrade Boundary References

The current frozen Freqtrade references are 10-variant boundary references only:

Publication interpretation: these references must not be extrapolated to 100/500/1000 variants and must not be presented as equivalent to the 2Signals scale v2 Node/service boundary.

Memory And Cache Findings

Metric definitions:

GC interpretation:

• the code calls global.gc?.() around sweeps and cleanup when available;
• this run recorded gcAvailable=0 in samples and gcRan=false in cleanup diagnostics;
• therefore no publication claim should say that GC was forced in this run.

Baseline interpretation:

• raw samples contain local heapBeforeSweepBytes and heapAfterSweepBytes;
• there is no stable isolated process baseline before the whole benchmark;
• there is no continuously sampled peak;
• there is no memory-only run that separates module loading, JIT, correctness, report generation and timing execution.

Minimum future memory-only run:

1. launch a fresh Node process with --expose-gc;
2. initialize modules, TA-Lib and frozen fixture once;
3. force GC and record several idle baselines;
4. run cold and warm full sweeps without correctness artifact generation;
5. record before, after and after-cleanup snapshots;
6. report cache bytes as a share of heap delta.

Cache diagnostics:

The decreasing recomputed-series total at larger levels is not evidence that larger sweeps do less work overall. It is explained by two methodological facts:

• 500 and 1000 levels have fewer measured samples than 10 and 100;
• the finite EMA variant grid saturates reusable fast/slow indicator series, so additional variants increasingly reuse already computed series.

Eviction diagnostics are not available because the benchmark cache mock has no eviction policy. Cleanup diagnostics confirm that benchmark cache entries were cleared after each scale level in this run, with staleResultsAfterCleanup=0.

Methodological Limitations

• One local synthetic BTC/USDT 5m fixture with 620 candles.
• One local machine and Node/Vitest process.
• Different measured run counts across scale levels: 10/10/5/3.
• Scale v2 is Node/service only and excludes UI, IndexedDB and network.
• Memory metrics are local process diagnostics, not production memory usage.
• GC was not forced in the raw scale v2 run.
• Instrumentation overhead is not isolated as its own benchmark.
• Strategy correctness is sampled for 100/500/1000; dataset OHLCV correctness is checked once per unique dataset hash through the dataset adapter check.
• Freqtrade references are frozen 10-variant boundary references only.
• No claim is made about 500/1000 Freqtrade behavior.

Publication-Safe Claims

Supported

• In the tested Node/service boundary, 2Signals completed all measured v2 samples and correctness gates successfully.
• The tested dataset was BTC/USDT 5m with 620 frozen candles and the exact hash listed above.
• Correctness passed for 1 unique dataset and 1610 checked variants by full result-hash validation, with 0 mismatches across dataset correctness and full/sampled strategy checks.
• The cold full-sweep medians were 16.85 ms, 153.30 ms, 768.75 ms and 1582.08 ms for 10/100/500/1000 variants respectively.
• The production-like Builder benchmark separately measured fully-rendered latency using the real production chart, metrics and trades components inside a controlled provider shell.
• Benchmark cache cleanup removed entries after each scale level in this run.

Supported With Qualification

• 2Signals scale v2 is approximately linear in the tested range for the stated Node/service cold full-sweep boundary.
• Per-variant cost is stable in the tested range when interpreted inside the Node/service boundary and with different run counts disclosed.
• Warm cache reuse is effective for measured cache reads, but warm total duration is not guaranteed to be lower because non-cached per-variant work still runs.
• Memory and cache size grow with scale in the local benchmark process, but the current memory data is diagnostic and not a stable retained-memory claim.
• Freqtrade 10-variant references can be cited only as frozen boundary references with their exact workflow names.

Not Yet Supported

• "Linear scalability" without "approximately", "tested range" and explicit boundary qualifiers.
• Any "10x faster" style claim.
• Full production /builder user-flow latency.
• Full strategy-artifact correctness for every 100/500/1000 variant; only sampled strategy artifacts are checked at those levels.
• Cross-engine Freqtrade equivalence for 100/500/1000 variants.
• Extrapolated Freqtrade timings for 100/500/1000 variants.
• Total browser memory, IndexedDB storage size or production cache footprint.
• Cache eviction behavior.
• Claims that the raw scale v2 run used forced GC.

Remaining Research Questions

• What is the retained memory delta under a dedicated memory-only run with --expose-gc?
• How does the scale behavior change on larger real market datasets?
• How much of fully-rendered UI latency is chart drawing, marker rendering, metric rendering and trade table rendering at larger variant/result sizes?
• What is the comparable Freqtrade boundary for 100/500/1000 variants, if any, without changing Freqtrade semantics?
• How does production IndexedDB/cache behavior compare to the Node benchmark cache mock?
• Which diagnostics overheads become material at 1000 variants and above?