btcRegimeScaler — Status & roadmap

Where this strategy is today

BLOCKED — the code is correct, uniform and shippable. That is a statement about engineering, not about profitability; the performance verdict is separate and sits below it.

Dimension	State
Correctness	failing
Console output	4 tagged calls, 0 off-format
Side panel	13 rows, padded to the 3-column grid
Chart marks	reference-levels
Palette	8 / 8 canonical
GUI settings	12 exposed · 0 read at runtime · 0 untunable · 0 inert
Deployed to a live install	Not yet — audited and staged, not yet shipped

Performance verdict. Over three years on 7 markets it returns a median -78.2% against buy-and-hold's 49.6% — an edge of -127.8% — and is profitable on 0 of 7. On this window it is not a replacement for simply holding the asset, and nothing in these reports claims it is.

What it actually does

btcRegimeScaler trades one pair but reads the weather off another. Every cycle it pushes the current BTC price into a rolling 100-cycle history, takes the standard deviation of the log returns, and calls that number the market's regime:

BTC hourly realised vol	regime	order size
< 0.5%	CALM	120%
0.5-1.0%	NORMAL	100%
1.0-2.0%	ELEVATED	50%
> 2.0%	PANIC	20%
fewer than 20 samples	UNKNOWN	70%

The regime does two things. It scales the order size through effectiveTL: TRADING_LIMIT × regimeSize, and it gates entry outright: the strategy only buys in CALM or NORMAL, and only when the traded pair's own RSI is at or below 40. So it is a dip-buyer that refuses to buy dips while the wider market is disorderly.

Exits are a four-way ladder, first match wins: a hard stop at −10% from break-even, tightened to −7% in ELEVATED and −4% in PANIC; a take-profit at +2.5%; a TTL at 50 cycles; and a regime: == 'PANIC' && gain > 0 rule that takes any profit at all once the market turns violent.

Above all of that sit two risk latches, checked before anything else runs:

The code behind this is in the engineering record, which this site does not publish.

Both are meant to be cleared once a day. Neither ever was — that is the first defect this audit found, and it had been supplying the strategy's entire measured performance.

Read from the shipped strategy source, not from its documentation.

The measured constraint

Time in market is 33.5%, over 5937 round trips across all 7 markets and three years. Everything in the performance report rests on that fraction of the bars.

Settings, measured

This strategy does not use the engine config surface.

What to build next

Ordered by expected effect on the result, not by effort.

1. Nothing here is a tuning problem yet — the strategy loses 69% and the benchmark returned 39%

Highest priority

With both defects repaired the median return over three years and seven markets is −68.9% against a buy-and-hold of +39.2%, with a median drawdown of 74.4% and not one profitable market. The earlier +7.4% was the strategy being switched off.

So the question is not which threshold to move. It is whether the central idea — gate a per-pair RSI dip-buy on BTC's realised volatility — survives contact with the data at all. Three ways to find out, cheapest first:

1. Does the regime label predict anything? Bucket every bar by regime and compare the forward return distribution over the next 1, 4, 12 and 48 bars against the unconditional one. If CALM bars do not have better forward returns than PANIC bars, the whole scaling apparatus is decoration.
2. Does the gate help or hurt? Run the same RSI dip-buy with the regime gate removed. If the ungated version does better, the gate is filtering out the trades that pay.
3. Is the exit the problem? A −10% stop against a +2.5% target needs a 4:1 win rate to break even. Measure the realised exit mix before assuming either number is right.

Until one of those comes back positive there is nothing here worth tuning.

2. Both risk latches now clear once a day — check that a day is the right period

High priority

The circuit breaker and the daily loss limit are both cleared by a calendar-day rollover, and with the clock fixed that rollover finally happens. Measured across all seven markets after the fix, the circuit breaker now fires on zero of 176,120 decision cycles: at roughly one trade every four to ten days, three losses almost never land inside the same calendar day.

That is the opposite failure to the one just repaired. Before, the breaker was permanent; now it is unreachable. Neither is a working risk control, and the reason is the same in both directions — a calendar day is the wrong unit for a strategy whose trades are spaced in days.

The fix worth measuring is a rolling window rather than a wall-clock boundary: three losses in the last N trades, or in the last N hours of market time. That is reachable at this trade frequency and it does not depend on what a clock says. The same choice applies to the 51 other strategies in the pack with a wall-clock daily reset.

3. The drawdown-tracking fields are written and never read

Worth testing

The code behind this is in the engineering record, which this site does not publish.

Both are maintained every cycle and neither is ever read — not by a gate, not by the side panel, not by the log line. MAX_DD_PCT is a per-position stop measured from break-even, so it is unrelated to this account-level figure.

With a measured median drawdown of 74.4%, an account-level drawdown limit is exactly the control this strategy is missing, and two thirds of one is already sitting in the file. Wiring maxDD to a configurable ceiling that halts new entries is a small change with an obvious test: it should cap the 74.4% at whatever the ceiling is set to.

4. The strategy's own PnL accounting disagrees with the engine's

Worth testing

Every exit books its result with

The code behind this is in the engineering record, which this site does not publish.

That charges one side's fee at BR_FEE (0.1%) against a breakEven that already includes the entry fee — the same arithmetic the mm-dca audit had to reason through — and it uses bid rather than the price the order actually filled at. It ignores slippage entirely.

This number is not cosmetic. It drives wins versus losses, which drives consecutiveLosses, which arms the circuit breaker. A trade the engine records as a small loss can be booked here as a small win, and the breaker then does not arm when it should. Worth reconciling totalPnL against the engine's realised P&L market by market; any gap is the size of the error the risk control is being steered by.

5. CAPITAL_ALLOC defaults to 9,090 and sets the daily loss limit in absolute quote

Read before acting on the others

CAPITAL_ALLOC (default 9090) does two jobs: it caps effectiveBase and it sets the daily loss limit at 2% of itself, i.e. 181.80 quote. That threshold is absolute, so on the calibrated 157-quote account the limit would require losing more than the whole account in a day and can never trigger, while on a 90,000-quote account it fires after a 0.2% day.

The limit should be a fraction of the account actually in play — effectiveBase, or equity — not of a setting the operator may never have touched. Left as a note rather than fixed here because it is unreachable at the tested capital and so cannot be measured from this run; it needs its own test at a capital where it bites.

6. The same clock defect sits in 51 other strategies and two more share the buy gate

Read before acting on the others

The wall-clock reset was fixed across all 76 files that read the clock, and the six strategies already published were re-measured against their published records: every measured value is identical, so nothing already reported needs restating. They were lucky rather than correct — their latch is dailyLossLimit, which needs a 2%-of-CAPITAL_ALLOC daily loss to arm, and none of them ever had one. The 23 other strategies gated on consecutiveLosses are the ones exposed to what happened here, and each will be measured as it comes up.

The full-size buy gate is narrower: apexEngine and cashFlowEngine are the only other files that carry it. Both recorded against each strategy and deliberately left unfixed, because a change to live behaviour belongs in the audit that measures it. apexEngine carries the identical half-order contradiction; cashFlowEngine has the full-size gate without the half-order allowance, so what it should do instead is a judgement its own audit has to make.