Sahm Trader
I set out to build a strategy, and ended up building something else. What empties an account is not a run of losing trades — it is the one day everything collapses together. So I built the layer that stops it: a day the system had modelled as capped under 1% reached 13.84% — it now ends at 0.753%.
1 · The daily loss limit was lying to us
Everyone who builds a trading system focuses on one question: when do I enter. However well you answer it, the answer is not enough on its own — because what empties an account is not a run of losing trades. It is the one day the positions collapse together. So I turned the project around: not a system that enters trades — a system that stops the blow-up.
And the problem is sharper than "use a stop loss." Any serious system has a daily loss limit, and computes it from the stop. But that computation assumes price touches the stop. It does not always — it can gap straight past it, and you leave the trade far from where you had it priced. When that happens to two positions on the same day, a day the system had modelled as capped under 1% reached 13.84%.
And worse: lowering the per-trade risk does not fix it. At 0.01% per trade, the same day landed in the same place — because what governs the outcome is not your size, it is the distance the price jumps.
2 · What I built
A layer that sits between the strategy's intention and the broker, and asks one question before any order leaves:
If price gapped past the stop instead of touching it, would the day breach its limit?
If yes ⟹ refused — and the refusal is logged with its full arithmetic. You learn why it was refused, not just that it was.
| What it does, plainly | |
|---|---|
| UROS · the single sizing authority | One place in the system decides the size of any order, and there is no other route. The broker call order_send is reachable from exactly one file in the entire codebase — verified across the repository, not assumed |
| 12 gates | Twelve checks every order passes through. One gate saying no is enough |
| The governor | Owns the whole order path — reads the price, sizes, checks, sends or refuses — and records every decision with its reason |
| MEDRAR | The market-reading layer feeding the decision: data quality · volatility · microstructure · market state. When its resources run short, it stands itself down rather than degrading the system |
The result on that same day: 13.84% ⟶ 0.753%.
3 · A guard that cannot evaluate answers no
One principle runs through the whole layer: a guard that cannot evaluate answers no, not yes.
News calendar missing? No order leaves.
A position open that the system did not open? Every new entry refused.
The configuration itself unsafe? The system does not start at all.
4 · Why you can believe it
8,551 automated tests, and a regression test for every defect ever fixed.
Every one of those tests is proven to fail when its defect is put back — so a test that has quietly stopped testing cannot hide.
61 checks run before every commit.
The core of the layer runs with the broker's own module blocked entirely — against a substitute broker and a replay clock; breaking any guard stops the replay instead of printing its refusal.
And I published one of the measurements for public review: four engineers challenged it, and one named a defect our own audit had missed — I measured it, fixed it, and added the test.
What took the year was not the idea. Any engineer thinks of checking gap risk. What took the year was measuring it: 115.9 million market quotes.
And I built all of it myself: the engine in Python · the dashboard in Node · the app in Flutter — three runtimes, one system, nobody else on it.
Python · FastAPI · Node · Flutter · PostgreSQL · Redis · WebSocket · Docker · MetaTrader 5
Read the published measurement