Analyse my MSTR probability strategy

Hi All,

I'm working on an automated probability bot for MSTR. I need people to analyse what I have done so far.

Overall conclusion

The strongest conclusion is this:

The MSTR/BTC volatility-expansion idea has evidence as a volatility-detection framework, but it is not yet proven as a live-money trading strategy.

That distinction is absolutely central. The PDF shows that the research found real MSTR volatility behaviour, especially around the US open, but the tested long, short and event-aware execution routes did not yet convert that volatility signal into a sufficiently robust after-cost trading edge.

1. What the PDF proves well

The strongest empirical finding is that MSTR was not simply following BTC. In the 27 April to 1 May 2026 one-minute audit, BTC had 7,201 rows, MSTR had 4,800 rows, the matched dataset had 4,800 rows, and the RTH-only set had 1,950 rows. The RTH comparison showed MSTR realised volatility of 9.43% versus BTC at 3.82%, meaning MSTR was roughly 2.47x more volatile during RTH. Across the full matched week, MSTR realised volatility was 9.47% versus BTC at 3.56%, around 2.66x BTC.

That is useful because it kills the weak assumption that “BTC direction alone tells us MSTR direction”. BTC was relevant, but not sufficient. The PDF correctly reframed MSTR as a leveraged Bitcoin-treasury equity affected by BTC, dilution/share issuance concerns, event risk, premium/discount repricing, earnings positioning and opening-flow behaviour.

The opening period finding is also strong. The PDF shows that roughly 24% to 32% of the whole RTH day’s MSTR variance happened in the first 30 minutes, and roughly 40% to 49% happened in the first hour. That supports the later strategy shift away from simple mean reversion and towards pre-empting volatility expansion.

2. The strategic pivot was correct

The PDF’s best strategic move was abandoning the idea that an extreme MSTR/BTC Z-score should automatically be faded. The better interpretation became:

An extreme spread may mean MSTR is entering a volatility-expansion or repricing regime.

That is a much more realistic framework. The proposed structure was sensible: first detect whether a large MSTR swing is likely, then only trade after direction is confirmed through an opening-range break, VWAP position, volume and BTC confirmation.

The recommended feature set was also appropriate: pre-market MSTR volatility, pre-market BTC volatility, MSTR/BTC volatility ratio, opening 15/30/60-minute range, opening volume, gap, VWAP, BTC confirmation, event-risk flags and spread/Z-score as a risk signal rather than a direct reversal trigger.

3. The two-year dataset was a genuine improvement

The PDF confirms that a proper 5-minute research dataset was created. It covered 2024-05-03 to 2026-05-03 and contained 94,734 matched MSTR/BTC rows, 39,000 RTH rows, 55,734 outside-RTH rows and 500 daily feature rows. It also notes that rolling threshold columns were shifted by one day to reduce look-ahead bias.

That matters because this moved the work from “one interesting week” into a much more defensible research base. The output files were also the right ones: matched all-session data, RTH-only data, outside-RTH data, daily volatility summary, volatility-expansion day features and a gap audit.

4. The long strategy found a signal, but not a tradable edge yet

The best long route was:

VolScore ≥ 3 and broke the opening-30 high, using an opening-breakout-long route.

That condition had a 42.9% +5% hit rate with p-value effectively zero, which means it was not random noise as a volatility/upside-day detector. But the costed trading route had only 62 trades, a 54.8% win rate, average net return of +0.091%, profit factor 1.09 and a negative bootstrap lower bound of -0.425%. Therefore it failed the live-money threshold.

This is the most important analytical point in the PDF:

The bot can identify stronger MSTR volatility conditions, but the tested entry/exit logic did not yet convert that into robust profit.

So the next research problem is not “add more prediction features”. It is “fix and validate execution”.

5. The short/fall route failed

The PDF tested short/fall logic separately, which was the right thing to do. It did not assume that long and short behaviour would be symmetrical. The short-side validation found that some conditions increased the chance of downside volatility, but the actual short trade simulations lost money after costs. One example route had 57 trades, a 35.1% win rate, average net return of -0.467% and profit factor 0.56. The conclusion was clear: no tested short/fall condition passed and live short trading should not be enabled.

That means short-side signals should currently be treated as risk warnings only, not trade-entry signals.

6. The event-aware layer did not solve the problem

The event-aware long validation also failed to produce a live-ready route. One example, EVENT_ge4_broke_high with opening-breakout-long execution, had 94 days, a 35.1% +5% hit rate, p-value effectively zero, 92 trades, 51.1% win rate, average net return of +0.029%, profit factor 1.03 and bootstrap lower bound of -0.404%. The report concluded that no event-aware long route passed the full live-money threshold after costs.

Again, that shows the same pattern: the signal has informational value, but execution remains too weak.

7. The biggest operational weakness was version chaos

The PDF shows a serious operational control problem. Five different bot folders wrote logs on the same day. The longest/latest running version was MSTR_LIVE_BOT_CURRENT_FIXED, which logged 1,574 rows from 15:42 to 20:23 and recorded NO_TRADE every time. The final row showed MSTR +3.05%, BTC confirmation YES, VolScore 0, Market Event 2, News Event 2, P(+5%) 68.95%, P(-5%) 38.94%, statistical label NOT_STATISTICALLY_VALID and trade gate NO_TRADE. The blocker was “vol_score 0 below threshold”.

That means the live test was not clean. It was not possible to confidently judge the strategy because different versions, folders and rule sets were active. Even if a trade had occurred, attribution would have been messy.

The PDF later identifies the intended current/latest bot as MSTR_LIVE_BOT_CURRENT_DECISION_V3 and explicitly says not to run the older CURRENT, CURRENT_FIXED, probability dashboard, patched dashboard or strict gate versions.

8. My judgement on the PDF

This is the honest judgement:

The research direction is now much better than the earlier mean-reversion idea.

The data build is useful.

The volatility-expansion concept is plausible and partially evidenced.

The opening-range framework is sensible.

The existing execution strategy is not yet live-ready.

Shorts should remain disabled.

Long trades should remain paper-only.

The current priority should be execution optimisation, not adding more features.

The operational process needs tightening before any live-money use.

9. What I would do next

The next step should not be another new bot. The next step should be a controlled validation cycle using one master folder and one strategy version.

The immediate plan should be:

1. Freeze one bot only: MSTR_LIVE_BOT_CURRENT_DECISION_V3.
2. Archive every older bot folder.
3. Keep the bot in paper/log-only mode.
4. Run a clean forward test for 30 to 60 trading days.
5. Record every signal, non-signal, missed move, spread, entry condition, exit condition and decision reason.
6. Separately optimise execution: entry timing, stop placement, trailing logic, time exit, profit target and cost assumptions.
7. Only reconsider live trading if the strategy achieves a costed profit factor above your required threshold, ideally 1.3+, with positive bootstrap lower bound and stable walk-forward behaviour.

The key sentence from the whole PDF is this:

The work has found a volatility signal, not yet a proven trading edge.

That is not a failure. It is actually valuable, because it stops the dangerous mistake of turning a visually impressive MSTR move into an unvalidated live bot.