Here is how a price that never existed becomes a realized loss.
Our worker takes market data from the Binance spot testnet feed. One 1-minute print arrived far below the surrounding market. That single tick did two jobs at once: it sat below the open position's stop, so the risk guard forced a SELL — and, being the latest price, it became the price that SELL was booked at. The stop fired on a phantom and then filled on the same phantom, at the full depth of the error. The day before, the same thing happened smaller: booked 58,891.15 against a real close of 60,837.51, off by 3.20%. The 8 June row was off by 13.51%.
That coupling is ours to own, and it is also not exotic. In a lot of paper engines and backtesters, the tick that triggers an exit is the same datum that prices it. One bad sample then produces two errors pointing the same direction: it makes you exit, and it makes you exit badly. A bad tick that triggers nothing is harmless — it flashes and is gone. All the damage lives in the overlap, and we did not design the overlap out.
One thing to fix in advance, because it colours everything below: this is a story about a defect in how a number was computed, not a story about returns. Our own pre-registered research programme stands at 432 trials with zero surviving positive results, we publish that, and nothing here changes it. The correction below happens to move our reported figure in our favour, which is exactly why it needs saying out loud rather than quietly.
The check that found it is cheap, and it is not ours. Take every fill your system recorded — symbol, timestamp, booked price. Fetch the public one-minute candle covering that timestamp; Binance's /api/v3/klines is free and keyless. Ask whether your price falls inside that bar's high and low. If it doesn't, it isn't a fill, it's an artifact. Align your timestamps before you trust the first pass — open-time versus close-time, milliseconds versus seconds — or you will manufacture false hits all afternoon.
We ran it over all 390 non-simulated fills in the production ledger's history. 301 fills, or 77.2%, sit within 0.1% of the covering bar's close; another 85, or 21.8%, sit between 0.1% and 0.5%; two sit between 0.5% and 1%; and exactly two exceed 1%, the two above. The pass covers every private production fill available to us, not a public row-level ledger, and it covers every strategy rather than just this one, so any other position exited on either bad print would have surfaced in it. None did. No fill in July or August exceeded 0.5% in this pass. (Three denominators appear in this piece: 390 is every non-simulated fill ever recorded; 137 is June's closes across the fleet; 73 is the ADAPTIVE_PRO BTC/USDT subset.)
In the sample we checked, testnet and mainnet track each other closely — today, BTC at 79,821.99 against 79,821.98. That is why nobody was going to catch this by eyeballing the data source. The mode of that distribution is fine. The tail is what booked the loss.
Now the part that matters if you publish numbers. We sign monthly performance snapshots with Ed25519 so anyone can check with stock openssl that the bytes were not edited after publication. The signature on June is valid. It was valid then and it is valid now: the bytes published are the bytes signed. What it proves is that the record was not altered after publication. What it does not prove, and never did, is that the record was computed from sound inputs. A signature is a claim about custody, not about derivation. If your pipeline books a fill at a price the market never printed, the signature preserves that price faithfully, forever.
We shipped two guards on 16 and 18 June — MAX_TICK_DEVIATION and MAX_FILL_DEVIATION, both at 12%, both deployed. The 13.51% print is rejected. The 3.20% print is not. The catastrophic form is closed and the small form is open, which is the permanent shape of this problem: a threshold loose enough not to reject real volatility is loose enough to admit small fictions, and small fictions accumulate without anyone flinching. There is an obvious objection we cannot answer yet — the mainnet oracle that found this post-hoc is strictly better than a static 12% band, and it is not in the fill path today.
The numbers. Those two rows are worth -$8.2710: 95% of that strategy's published loss, and more than the entire month's reported loss. Corrected, ADAPTIVE_PRO is -$0.4623 and June is +$2.2452 rather than the published -$6.0258. For scale, that strategy runs a fixed $50 notional against a $1,000 paper book, so the error is about 0.83% of the book. The size is not the point. The signed public record was wrong. This is not a trading result and must not be read as one; what we sell is proof that a record is real, never proof that it made money.
The parts that do not flatter us:
- A wrong number stood in public for nearly two months, and internal work caught it — not a customer, not an outsider.
- The code defect was fixed on 16 and 18 June, but the contaminated rows stayed in the ledger and kept flowing into the monthly aggregate for another six weeks. Fixing the pipe did not empty the tank.
- June carries zero per-trade signatures across its 137 closes; per-trade signing began later. This correction is a forensic reconstruction from our private production
trade_eventsrows against public Binance bars, not a cryptographic proof over public row-level evidence. A reader can independently verify that 54,852.76 is outside the public tape, and that the signed June snapshot's bytes were not altered. They cannot independently verify from public material that these two private rows are exactly the rows behind the published aggregate, or that the other 135 June closes contain no other internal error. Where our credibility is an input, discount it — and go run the check on your own fills, where it is not.
We have not re-signed June and have not replaced it. The database refuses updates and deletes on a published snapshot, and we did not go looking for a way around that. The correction is published beside the original, dated, on the performance page and in the repository.
It cost us a sentence we liked: "our June is signed, verifiable, and it's a losing month — we publish it anyway." It is false now, so it points at July 2026, which is genuinely -$2.8368 and carries per-trade signatures on 21 of its 22 closes — figures read from the production ledger, the same private source as everything else here.
Two rows out of 390 carried most of a published number. Go fetch the bars for your own fills. The tape is free; the only cost is what you find.