Methodology · v1.2

Every number we publish is reproducible from the same ledger you trade against.

Most "trading tools" show you back-tests with survivorship bias and round-number slippage. We don't. Here is exactly how DyadScalp verifies a playbook before it's allowed in the terminal, and how every fill is accounted for after.

Pillar

1 · Walk-forward verification

A playbook is fit on a rolling 90-day window and tested out-of-sample on the next 14 days. We repeat across 24 months. Only playbooks with positive median out-of-sample R across all windows are admitted.

Pillar

2 · Tick-level slippage model

Fills are simulated against L1 best-bid/best-ask at the exact millisecond. We charge full STT, exchange fees, GST, SEBI, and stamp duty per leg — not a flat 'commission' assumption.

Pillar

3 · Append-only audit ledger

Every signal emitted, every fill received, every risk-gate trigger is written to an append-only ledger with a per-row hash chained to the previous row. Tampering is detectable.

Pillar

4 · Public methodology versioning

Changes to the verification pipeline are versioned (currently v1.2). Each Honesty and Track Record page shows which methodology version produced its numbers.

What we explicitly do NOT do

· In-sample back-tests presented as forward results.
· "Average win" cherry-picked from green months only.
· Slippage modeled as a fixed bps figure (real markets aren't symmetric).
· Hiding losing trades behind "alerts only" disclaimers.
· Editing or deleting historical signals after the fact.

Verifiable, not "trust us"

Each weekly cohort on the Track Record page ships with a ledger hash. Once a quarter we publish the raw ledger CSV for independent reconstruction. If our published Win% ever disagrees with the ledger, the ledger wins and we issue a correction.

See verified track record