Strategy performance

How we publish performance — and what you should and shouldn't read into it. Last reviewed: 2026-09-02.

⚠️ Correction to the signed June 2026 snapshot — issued 2026-08-28

The published June 2026 snapshot reports a month total of −$6.03. Two of that month’s 137 closes were booked at prices the real market never printed — 54,852.76 and 58,891.15, against a real Binance BTCUSDT low of 58,115.01 across the whole of May and June 2026 — the result of a bad tick on our market-data feed. They account for −$8.27 of the reported loss. Corrected, June is +$2.25, not −$6.03. It was not a losing month.

The signed artifact is not being re-signed or replaced. The bytes published on 2026-07-02 are the bytes that were signed and the signature still verifies; nothing has been edited. That is the point of an append-only signed record — including when the correction would flatter us. A signature proves a record was not altered after publication. It does not prove the record was computed from sound data, and this is the first time that distinction has cost us something.

The underlying defect was fixed on 2026-06-16 and 2026-06-18 and both guards are deployed. July and August 2026 are unaffected: every fill in those months sits within 0.5% of the real market. Full method, figures and the limits of this correction are published in the repository as docs/performance-june-2026-correction-2026-08-28.md.

Second correction, 2026-09-02 — the sentence above, "It was not a losing month," is withdrawn. A measurement audit found that 102 of the same 137 June closes were booked gross: the 0.10% taker fee this page promises was never charged on them — $10.20 of fee the signed figure never paid (fee booking begins 2026-06-14; June mostly predates it). Restated on this page's own declared methodology, from the committed ledger pull: −$6.03 signed, +$8.27 bad-tick removal, −$10.10 unbooked fee net of the removed trips’ own — under the fee methodology this page declares, June 2026 restates to −$7.85: a losing month. To keep the three figures distinct: the signed artifact remains −$6.03 as published; the bad-tick-only, as-booked correction was +$2.25; the fee-consistent restatement is −$7.85 — and the page-declared methodology is the standard this project holds itself to. The first correction fixed the data defect and introduced a new overstatement in the same sentence; both now stand here, dated, because the record of being wrong is part of the record.

🎯 Public commitment

Monthly PAPER-portfolio snapshots per production strategy, signed with a dedicated Ed25519 key — verifiable the same flow as the build attestation on /security.

The runner bots are collecting data now. The first finalised month publishes here once it closes — no preview, no estimate.

Latest snapshot

Strategy	Return	Buy & hold	Edge	Sharpe	Max DD	P&L USD	Opens/Closes	Win rate	Profit fact

Real capital — founder's account REAL MONEY · NOT TRADING

The founder's own USDT sitting in Binance Simple Earn (flexible). This is deposit yield — carry, read live from the exchange with a read-only key. It is not a trading result and claims nothing about the strategies above. Shown because the honest baseline for any trading claim is what the same money earns doing nothing.

Asset	Amount	Effective APR	Base + tier	Rewards received	Redeemable

Owner-recorded entry cost, for honesty: the cash-in point charged a flat 7 % (63 ILS on 900 ILS, 2026-09-01) — roughly one year of this APR. Any return calculation on this capital starts at −7 %. That figure is attested by the owner from the point-of-sale receipts, not read from an API. Why this capital is parked and not traded — including by our own bots — is a published policy: /treasury. From 2026-10-01 the position is also frozen monthly into a signed, append-only Real Capital Statement (raw signed bytes + signature, verifiable with the same public key as the snapshots above).

Why this page exists

Selling discipline without showing data is asking for trust. This page commits, in public, to what we publish, when, and how to verify it.

What gets measured

The production strategies — EMA Cross, Breakout V1, TS Momentum V1, Quantor Adaptive Pro — each runs a PAPER portfolio on Binance market data. Correction, 2026-09-02: this sentence used to say "live market data". The worker's candles and paper fills actually come from the Binance spot testnet feed — the same market at retail scale (sampled deviation vs mainnet: worst fill 0.12%, most within 0.01%), but not the mainnet tape, and one June bad tick came from exactly this feed (see the June restatement below). A mainnet-data switch exists in the code and ships disabled; if it is ever enabled, the date will appear in the changelog below. (See the changelog for which runners are currently active):

$10,000 baseline (same constant the production DailyLossSentinel uses).
Documented default params — no manual tuning per month. Default changes are dated; the old default runs in parallel ≥ 90 days for comparison.
Fixed allowlist: BTC/USDT (and SOL/USDT historically) — runner slate now all H1, corrected from M1/M5 across 2026-06-09 and 2026-06-18 (see the changelog below).
Taker fees — Binance spot 0.10%, booked into realized PnL on every fill since 2026-06-14. Correction, 2026-09-02: this line used to say "tracked in the snapshot" without qualification. Two things were wrong with that: trades before 2026-06-14 were booked gross — 102 of the 137 June closes carry no fee at all, $10.20 of taker fee that the signed June figure never paid (see the June restatement below) — and the snapshot carries fee-inclusive PnL rather than any separate fee field.

What's in a snapshot

Single signed JSON, one row per strategy:

monthly return % + cumulative return %
Sharpe (annualised, 365-day, zero rf) — same formula as MeEquityCurveController.annualizedSharpe. Correction, 2026-08-26: until this date the signed figure did not match that reference. It sampled only the days that contained a closed trade and then annualised as if every calendar day were represented, and it used the population rather than the sample standard deviation. The effect was to overstate Sharpe, roughly two-fold on a sparse month. The formula now matches the reference and a regression test fails the build if the two ever diverge again — but months signed before 2026-08-26 still carry the old, overstated figure. Signed rows are immutable by design, so they are left as they were rather than quietly restated. Every other metric on this page is unaffected.
max drawdown % — peak-to-trough, positive number
win rate, profit factor, opens / closes
buy & hold benchmark — passive HODL of the same symbol over the same period, so the strategy's edge over "do nothing" is visible. Correction, 2026-09-02: "over the same period" was not true for any month signed before this date. The benchmark request treated the exchange's endTime as exclusive when it is inclusive, so the window silently included the next month's first bar — and because signing runs at 02:15 UTC on the 1st, that bar was still open and its "close" was simply the spot price at the minute the cron fired, making the signed benchmark unreproducible. Measured against the exchange's own daily candles, the signed buyAndHoldReturnPct errors are: 2026-06 BTC +1.90 pp, 2026-06 SOL +4.60 pp, 2026-07 BTC +0.26 pp, 2026-07 SOL +0.26 pp, 2026-08 BTC −0.44 pp — and edgePct shifts by the same amount on every row (in June the error flattered the strategies). The signed artifacts are not re-signed, per the policy above. As of this date the code requests an exclusive month end and refuses to benchmark any response carrying a bar that opens at or after the period end — and the next signed artifact will be checked against the exchange's own candles after publication, because a fix is a claim until a signed month confirms it.

Snapshot JSON includes the period start/end ISO timestamps and the strategy rows listed above, and each snapshot is Ed25519-signed. Correction, 2026-09-02: this paragraph previously claimed the snapshot also contains the SHA-256 of the strategy source file and the build commit SHA. Neither field exists in the artifact, and the claim is withdrawn — what the signature proves is that the published bytes were not altered after signing, nothing more. Nothing in a snapshot is editable after publication — overwriting a past month breaks the signature and is visible on inspection.

Schedule

Monthly

1st of each month: signed JSON for the previous calendar month.

Quarterly

Jan / Apr / Jul / Oct: 90-day roll-up with regime breakdown (CALM / VOLATILE / DANGEROUS).

Annual

Once per year: written commentary on what worked + what didn't, signed alongside the data.

Methodology changelog

Every change to how the runner bots are configured is dated here — a mid-track change is never silent. The signed snapshots are dated and tamper-evident, so you can always check what ran when.

2026-09-14 — a sentence inside the signed snapshot said the wrong source; corrected going forward

Snapshots carry an openPositions disclosure with two counts and a note explaining them. The note said “Counts derive from the trade_events ledger” and covered both. That was true of openTradeGroups and false of dustParked, which is read from the bot decision log — an operational table pruned after 30 days. So a signed artifact attributed one of its numbers to the permanent ledger when it actually came from a log that gets deleted, which made the claim wrong and, after a month, impossible to check either way.

Nothing about the money moved. Every realized-PnL figure in every snapshot has always come from the trade_events ledger, whose rows are individually signed and never pruned. The error was in a sentence describing a disclosure counter, not in a number.

From today the note names each count's own source and states plainly that dustParked is a point-in-time observation which a later recomputation will not reproduce. Past months are not rewritten. Their bytes and their signatures stand as published, with the inaccurate sentence in them — which is what an immutable record means. This entry is the correction.

2026-06-18 — Adaptive Pro (BTC) retired; TS Momentum (SOL) M5 paused

A fresh out-of-sample walk-forward review (6 strategies × 11 major pairs × 2 timeframes × 2 cost levels = 264 walk-forwards, after fees + slippage) found no strategy with a credible edge over buy-and-hold — and Quantor Adaptive Pro was the worst live performer. We paused the Adaptive Pro (BTC) runner rather than keep paying its noise-loss. Its prior signed decisions stay in the dated snapshots — nothing is deleted or back-edited.

We also paused TS Momentum (SOL) on M5: at the minute timeframe it over-trades into the ~0.3% round-trip cost floor — death by a thousand cuts. The runner slate going forward is EMA Cross (BTC, H1) and Breakout V1 (BTC, H1).

Why we're telling you this: quietly retiring a loser to flatter a track record is exactly the cherry-picking this page exists to prevent. So it's dated here, the history is retained, and the snapshots stay tamper-evident. We don't promise profit; we prove what happened.

2026-06-09 — Timeframe corrections: EMA Cross & Adaptive Pro (M1 → H1), Breakout V1 (M5 → H1)

Two of the four runner strategies (EMA Cross, Quantor Adaptive Pro) were running on the 1-minute timeframe. On M1, round-trip fees + slippage (~0.3%) dominate the signal, and these strategies' default parameters — tuned for 1h/4h — bleed against minute-bar noise. We moved both to their designed H1 timeframe on 2026-06-09.

In the same pass we also moved Breakout V1 (BTC) from M5 to H1. On M5 it was over-trading — roughly 28 round trips a day, chasing false breakouts on BTC's intraday chop and paying the spread each time (it was, frankly, the worst performer of the four). H1 makes it a fair test of real breakouts instead of noise. Only TS Momentum (SOL) stays on M5.

These were misconfiguration corrections, not parameter re-tunes, so the old timeframes were switched off rather than run in parallel — keeping a known-misconfigured bot live would only pile up more avoidable noise-loss.

Effect on the signed snapshots: the June 2026 month therefore spans both periods — M1 (Jun 1–9) and H1 (Jun 9 onward) — so read June as a transition month, not a clean baseline. July 2026 is the first clean full-month H1 snapshot. We'd rather show you the messy honest month with this note than quietly restart the track on a convenient date.

⏳ What you'll see here until the first snapshot publishes

No backtest charts, no cherry-picked windows. Until the first calendar month finishes, the only honest answer is «data is being collected — check back when it closes». When the first snapshot lands, the JSON URL + verify command appear above.

How to verify the signed snapshot

curl -sS https://quantorsaas.app/api/v1/public/performance/latest.json > snap.json
curl -sS https://quantorsaas.app/api/v1/public/performance/latest.sig  > snap.sig.b64
curl -sS https://quantorsaas.app/.well-known/quantor-perf-pubkey       > key.pem
base64 -d snap.sig.b64 > snap.sig 2>/dev/null || base64 -D snap.sig.b64 > snap.sig   # (-D on macOS)
openssl pkeyutl -verify -pubin -inkey key.pem -rawin -in snap.json -sigfile snap.sig
# Expected: "Signature Verified Successfully"
# Check you got the real key — its SHA-256 fingerprint (never changes):
openssl pkey -pubin -in key.pem -outform DER | openssl dgst -sha256
# → 3ea917ace8401383af503f27bed9205195b56f21df89af21bd44a94aec5a25e5
# A specific finalized month: swap latest.json / latest.sig for
#   snapshots/YYYY-MM.json  and  snapshots/YYYY-MM.sig

Public-key SHA-256 fingerprint 3ea917ac…5a25e5 (full value in the recipe above and on /security) never changes during the project's lifetime; any rotation is announced ≥30 days in advance with cross-over verification. The ed25519-perf:… string shown with each snapshot is our internal signing-key id — an operational label, not something you can recompute from the public key; the fingerprint above is the one you verify.

What this page does NOT promise

Forward returns. Past PAPER ≠ prediction. Regimes change.
That LIVE matches PAPER. Slippage, partial fills, exchange downtime, your specific notional all shift the result.
«Guaranteed yield». If you see «+X% guaranteed» anywhere on this site, it's a bug — please report to bugs@quantorsaas.app.

Quantor is built on discipline, transparency, and risk controls — not the idea that we beat the market. If a strategy loses money over a year, the snapshot shows it losing money. Surprised customers cancel.

Open beta — free

Quantor is in open beta. Create a free account and run a PAPER bot on exchange market data today — real-money LIVE trading isn't enabled yet (we'll tell you well before it opens). No application, no waitlist.

All strategies are free during the open beta. No data resale, no mailing list.

Start free → Watch it trade live →

Replies read personally. Questions → bugs@quantorsaas.app.