Track record methodology

The Trading History page reads from three Postgres tables in our database:

• trade_cards — every signal Soar has ever published (asset, direction, entry zone, T1, T2, stop, conviction, timestamps).
• card_outcomes — per-card resolution rows (T1 hit, T2 hit, stop hit, expired) written by the resolution cron.
• sessions — the publishing session each signal belongs to.

The aggregation logic lives in src/app/api/recent-trades/route.ts; statistical formulas in src/lib/trackRecordStats.ts. Both are open in the repo.

Filters applied at query time:

• card_type = 'trade' — excludes watching/context cards.
• sort_order >= 0 — excludes hidden / quarantined cards.
• clerk_user_id IS NULL — excludes per-user on-demand reports (only site-wide pipeline cards).
• session_number > 0 — excludes ad-hoc user-research sessions.
• status = 'published' — only published sessions.

A signal's outcome is determined by which level price touches first, in this priority order:

1. target2_hit — price touched the second target. Counted as a WIN.
2. target1_hit — price touched the first target but not the second. Counted as a WIN.
3. stopped_after_t1 — price hit T1 then retraced through the stop. Counted as a WIN (T1 was reached and could have been monetized; we don't simulate selling, so the running-sum gain is the T1-level gain).
4. stop_hit — price hit the stop without ever touching T1. Counted as a LOSS.
5. expired — neither targets nor stop hit before the timeframe horizon elapsed. Counted as NEITHER (excluded from win/loss math, included in trade count).
6. open — still live. Excluded from this page entirely (only the dashboard shows live signals).

Per-signal gain is computed direction-aware:

gain_pct = ((exit_price − entry_mid) / entry_mid) × 100 × direction_sign

where direction_sign = +1 for long, −1 for short
      entry_mid = midpoint of the published entry_zone
      exit_price = T2 / T1 / stop level depending on outcome

Soar publishes a signal in a session, then carries it forward to subsequent sessions until it resolves or retires. Each session re-publish creates a new trade_cards row, but they share an outcome timestamp because the resolution cron stamps the entire lineage at once when price crosses a level.

To avoid double-counting carry-forward clones, we dedup on the lineage key:

lineage_key = (asset, direction, timeframe, resolved_at)

Cards with identical resolved_at collapse to a single trade for stats. A re-entry on the same asset after a stop-out has a different resolved_at and counts separately.

The full per-session list shown on the page (vs. the deduped stats) is intentional — admins can see every session appearance for audit purposes; stats use the deduped lineage.

Every metric on the page has a single canonical implementation in src/lib/trackRecordStats.ts. Formulas:

Hit rate + Wilson 95% CI

Hit rate = wins / (wins + losses). Confidence interval uses the Wilson score interval (Wilson 1927), the industry standard for small-sample binomial proportions:

p = wins / n
center = (p + z²/(2n)) / (1 + z²/n)
margin = (z × √(p(1−p)/n + z²/(4n²))) / (1 + z²/n)
CI95 = [center − margin, center + margin]
where z = 1.96 for 95% confidence

Wilson is asymmetric and stays inside [0,1] even at p≈0 or p≈1, where the naive Wald interval breaks.

Mean per signal + standard error

mean = Σ gain_pct / n
σ = √(Σ(gain_pct − mean)² / (n − 1))   ← Bessel correction for unbiased estimator
SEM = σ / √n   ← standard error of the mean

Profit factor

PF = Σ positive_returns / |Σ negative_returns|
PF > 1     → net profitable
PF > 1.5   → healthy
PF > 2     → strong
PF < 1     → losing

Expectancy per signal

Expectancy = (winRate × avgWin) − (lossRate × avgLoss)
Positive → system is +EV per signal even before sizing.

Sharpe ratio (annualized)

Per-signal Sharpe annualized at 1825 trades/year (≈ 5 closes/day × 365 days). Risk-free rate = 0% because Soar is a signal-only product with no capital deployed:

Sharpe = (mean / σ) × √(trades_per_year)
trades_per_year = 1825   ← Soar publishing cadence

Caveat: this is a per-signal Sharpe, not a portfolio-time-weighted Sharpe. Comparable to itself across windows; not directly comparable to fund Sharpe figures.

Sortino ratio (annualized)

Like Sharpe but uses downside-only deviation (penalizes losses, ignores upside vol). Better for the asymmetric distributions Soar's track record shows:

σ_downside = √(Σ negative_returns² / count_negative)
Sortino = (mean / σ_downside) × √(trades_per_year)

Max drawdown

Largest peak-to-trough decline of the running-sum cumulative index over the window. Captures the worst stretch.

Cumulative running-sum vs SPY

The headline cumulative number is a running sum, not a compounded portfolio return. We start at 100 and add each closed signal's gain_pct in resolution-time order:

index₀ = 100
indexᵢ = indexᵢ₋₁ + gain_pctᵢ

Why running sum and not compounding: Soar publishes signals; users decide capital deployment. Compounding would imply serial reinvestment into one rolling pot, which is not what the product is. Running sum is the honest "if every signal got 1 unit of capital, here's the per-signal additive total."

SPY benchmark is fetched from Yahoo Finance daily closes over the same window and indexed to 100 at the first signal close. Alpha = Soar cumulative − SPY cumulative.

Soar's engine has gone through significant versions. The default 14-day window reflects the current engine. The all-time view includes earlier versions whose behavior is not representative of today's engine. Per-version performance:

Why we show the older versions at all:hiding them would be cherry-picking. The all-time toggle exists for full transparency, but is labeled clearly so visitors don't mistake the all-time number for the current engine's expected output. The 14-day default is the right framing for "what does today's engine do."

Root cause: the trade-closure cron at src/app/api/cron/check-trades/route.ts:24-106 had an incomplete crypto-ticker map. DASH was missing, so the price lookup fell through to the Nasdaq stocks API, which returned DoorDash. The bug pattern is the same one that caused the v6.30.9.23 logo issue (DoorDash logo shown on Dash crypto card).

Fix: the two affected rows are quarantined (is_test=true) and excluded from the canonical engine_comparison_running_totals rollup. Phantom impact on Soar's all-time running sum: +$7,063.90 of fake gains removed. Adjusted all-time net P&L: +$10,231.80 → +$3,167.90 on the $25K reference balance (from +40.93% → +12.67%).

The Trading History page on this site reads from trade_cards.hit_price_t2 (the published target level), not from the corrupted exit-price feed, so the page's computed gain for those DASH rows was always the legitimate ~+15% T2 hit, not the +354% phantom. The phantom only affected the engine-comparison admin canonical rollup. Both surfaces now reconcile.

Disclosure rationale: showing the scar publicly is the credibility play. We found a bug, we're telling you about it, here's the fix and the impact.

• Live (open) signals — excluded from this page entirely. Only on the dashboard.
• On-demand user research — per-user signals from the report builder. Not site-wide pipeline output.
• Watching / context cards — not full trade signals, no entry/T1/T2/stop levels.
• Hidden / quarantined cards (sort_order < 0) — operator-flagged for data-quality review.
• Test rows (is_test = true) — synthetic data + the disclosed DASH incident rows.

Three layers of independent verification:

1. Raw CSV — every signal + outcome row is downloadable at /api/recent-trades/csv. Rerun any computation; we don't aggregate-and-hide.
2. Cryptographic anchor on Solana mainnet — every hour, the new signals + outcomes are hashed into a Merkle tree, signed (Ed25519), and the root is published on Solana mainnet via the official Memo Program (MemoSq4gqABAXKb96qnH8TysNcWxMyWCqXgDLGmfcHr). Once anchored, the root cannot be modified without leaving cryptographic evidence. Anyone can call /api/verify/:signal_id to get an inclusion proof and independently confirm a signal existed at a given time with given parameters.
3. Third-party audit (planned) — engagement of an independent quantitative consultant to validate methodology + sample data. Their report will be published in full, including any findings.