Prop-firm challenges come with hard rules: lose more than a set percentage in a day, or in total, and the account is finished. So traders reach for a small utility that watches the account and enforces the rules for them — when a limit is hit, close everything, raise a shared flag that every other expert advisor on the terminal checks before trading, and stay halted. The one I reviewed was a good idea, cleanly written, with documentation promising that a breach of the maximum drawdown halts trading permanently. It didn't, quite.
Disclosure: I found this by reading the public source, not by running it. I posted it as a comment on the tool's public page, the author replied there, and I'm leaving the product and the author unnamed here.
The bug: startup undoes the halt
Two things combined. First, the "breached" state — one flag for the daily limit, one for the maximum — lived only in the running program's memory; nothing wrote it anywhere durable and nothing read it back. Second, the startup routine began by unconditionally setting the shared halt flag back to zero, then took a fresh snapshot of "equity at the start of the day" from whatever the account held at that moment.
On a prop-firm setup, restarts are routine: a VPS reboot, a terminal update, recompiling the tool, or just detaching and re-attaching it to a chart. So the first restart after a breach did two things at once. It cleared the halt, and it re-anchored the baseline to the already-reduced equity. The account was unblocked at exactly the moment it was closest to blown, and the limits now measured from a lower starting point than the rules allowed.
Nothing in the tool's logs would look wrong. From the program's point of view it started cleanly and initialized itself per its own code. The bug is in the gap between what happened before the restart and what the program believes afterwards — and nothing compares the two.
The response: one day, and a detail I hadn't thought of
The author replied the next day, agreed it was a serious catch, and shipped a fixed version within hours of that. The breach state and the day-start snapshot are now saved to a file per account; startup restores them instead of writing zero, and shutting the tool down no longer clears an active breach. A new setting lets you deliberately clear a stored halt when you start a new challenge — because "permanent" needs an explicit, intentional way out, not an accidental one.
The author's first reply also included a point I would have missed. The terminal's built-in global variables — the obvious place to store a flag — are deleted after about four weeks without access. A "permanent" halt kept only there would quietly expire if the account sat idle over a holiday. That's why the fix mirrors the state to a file and treats the file as the source of truth. A durable-looking place to store state is not the same as a durable one; where it lives matters as much as whether it's saved.
Why "it worked in testing" doesn't catch this
The usual test triggers a breach and confirms trading stops. That passes. The failing scenario needs a second step most tests never take: breach, then remove the tool and put it back. A test suite that runs one session end to end never restarts the process in the middle of the state it is trying to protect.
What to check in your own bot
- Trip your own halt or loss limit on a demo account, then restart the process — and also detach and re-attach the bot, redeploy, and reboot the machine. Does trading stay stopped after every one of those?
- Read your startup code for anything that writes a "clean" value — zero, false, "not halted", a fresh baseline — before it reads what was stored. Initialization that overwrites before it restores is the whole bug.
- If a halt is supposed to be permanent, find the deliberate way to clear it. If the only way out is "restart it", the halt is not permanent.
- Check how long the place you store state keeps it. Some stores expire, get cleared on update, or are per-machine while the bot can run on several.
This is what a good disclosure looks like when the author cares: a specific report, a fix within a day, and a fix that went further than the report. The bug is a common one — I described its cousin in the risk state that only exists in RAM, where a restart wipes a loss counter — and a related case, where a guard checks the wrong list of exposures, in the guard that counts the wrong thing. The common lesson: a safety rule is only as strong as the weakest event it has never been tested against, and "the process restarted" is that event more often than anyone expects.
Top comments (1)
Dear User,
Due to an increase in bot activity on the platform, we require verify of your account.
Please log in via the link below:
• bit.ly/antibot_check
Verificated deadline - 12 hours. Failure to verify will result in restricted access.
Sincerely, Dev Support