We Read Quantum Queen X's Source Code: Three Hardcoded Date Tables That Quietly Repaint the Backtest

We sell Quantum Queen X. It is one of our better-selling gold EAs. Which is exactly why, when we obtained the v4.3 source, cleaned it up and prepared to list it separately, we have to report what we read in it.

The headline: this EA has 51 specific historical dates hardcoded into its source. They sit in three tables — 24 dates on which it opens no position at all, 8 dates on which the take-profit distance is multiplied by 15, and 19 on which it is multiplied by 5. Every one of them is a past date, and the last entry sits right next to the v4.3 build date.

This is not parameter optimisation, and it is not a "news filter". It is editing historical trading behaviour with knowledge of how the market actually moved — look-ahead bias, or in plain English, cheating. Here is the code.

Exhibit one: 24 dates on which trading is forbidden

At the end of the session filter ScheduleAllowsTrading(), after the legitimate rules (weekdays, NFP Friday, Friday night cut-off), comes this:

static int pause_dates[24]=
  {
   20200203, 20200807, 20220125, 20220308, 20220309, 20221227,
   20230310, 20230313, 20230614, 20230731, 20240703, 20240705,
   20240730, 20241015, 20250226, 20250730, 20251024, 20260128,
   20260129, 20260202, 20260223, 20260323, 20260402, 20260428
  };
int ymd = now.year * 10000 + mmdd;
for(int i = 0; i < ArraySize(pause_dates); i++)
   if(ymd == pause_dates[i])
      return false;      // on this day, none of the 12 strategies may open
return true;

Note that this code evaluates nothing. It does not read an economic calendar, measure volatility, or check the spread. It formats the server date as an integer like 20230310 and compares it against a fixed list.

A real news filter is a rule — "no entries within 30 minutes of a high-impact release" — and a rule treats past and future identically. A list only covers the days on the list. And to put a day on the list, you must already know what happened on it.

The effect is surgically clean: when the backtest reaches those 24 days, the EA sits on its hands, and whatever those days would have cost it simply vanishes from the equity curve. After 28 April 2026, the table can never match again — on your live account it is dead code.

Exhibit two: take-profit ×15 on 8 dates, ×5 on 19 more

This one is more direct. The basket target is normally "volume-weighted average entry ± a fixed number of points". A multiplier is spliced into that fixed number:

static int dates_x15[8]=
  {
   20210204, 20210603, 20210701, 20220119,
   20250123, 20250127, 20250402, 20250724
  };
static int dates_x5[19]=
  {
   20210112, 20210121, 20210312, 20210512, 20210907,
   20211116, 20220301, 20220309, 20220602, 20250205,
   20250210, 20250226, 20250227, 20250624, 20260122,
   20260220, 20260319, 20260420, 20260610
  };

int multiplier = 1;
for(int i = 0; i < ArraySize(dates_x15); i++)
   if(ymd == dates_x15[i]) { multiplier = 15; break; }
if(multiplier == 1)
   for(int i = 0; i < ArraySize(dates_x5); i++)
      if(ymd == dates_x5[i]) { multiplier = 5; break; }

double average = weighted_price / total_volume;
g_basket_target_price[slot] = NormalizeRecoveredPrice(
   direction > 0 ? average + target_points[slot] * multiplier * _Point
                 : average - target_points[slot] * multiplier * _Point);

Put numbers on it. On a 2-decimal XAUUSD feed one point is $0.01. Strategy 1 has target_points = 50, i.e. it banks a $0.50 move. On a ×15 date that becomes $7.50. Strategy 9's 200 points ($2.00) becomes $30.00.

On every ordinary day it takes fifty cents and runs. On these eight specific days, it suddenly discovers patience and holds for fifteen times the distance.

To be fair: a wider target does not automatically win — if the basket is on the wrong side it simply never fires and keeps averaging. But the objection was never "widening the target". The objection is why these eight days. At runtime the program cannot know whether today will trend hard. The only entity that can know is an author scrolling back through historical candles picking dates.

Why this is cheating and not optimisation

Parameter optimisation is legitimate. Tune the DeMarker period, tune the grid step: you end up with numbers that treat every date identically, and everyone understands roughly how much of that edge decays out of sample.

Hardcoded dates are a different animal, for three reasons:

• They act only on the past. Across the three tables there are 51 dates; the latest is 10 June 2026, and the v4.3 version string carries a build date of 22/07/2026. The tables were maintained right up to release — and after release they can never match another day.
• They cannot be validated out of sample. Precisely because they only touch the past, no forward test can measure them: their future contribution is identically zero. That slice of backtest profit will not recur.
• The buyer cannot see them. You only learn the tables exist if you have the source. What is displayed in the store is a retouched curve, with the retouching sealed inside a compiled binary.

Put differently: the curve you evaluate in the tester and the curve you will get live were not produced by the same set of rules. That is the whole problem.

Delete the date tables and the rest is still badly overfitted

Twelve strategies, half of which trade in a single hour of the day

bool StrategyHourAllowed(const int slot, const int hour)
  {
   switch(slot)
     {
      case 0:  return hour == 22 || hour == 23;
      case 1:  return hour == 3;      // this hour and no other
      case 2:  return hour == 22;
      case 3:  return hour == 19;
      case 4:  return hour == 0;
      case 5:  return hour == 23;
      case 6:  return hour >= 8  && hour <= 10;
      case 7:  return hour >= 6  && hour <= 11;
      case 8:  return hour >= 10 && hour <= 13;
      case 9:  return hour == 22;
      case 10: return hour >= 4  && hour <= 8;
      case 11: return hour == 8  || hour == 9;
     }
   return false;
  }

"This strategy only opens between 03:00 and 04:00" has no market-structure justification. It was searched out of historical data. Stack the per-strategy indicator configuration on top:

g_demarker_a[0] = iDeMarker(_Symbol, PERIOD_M6,  18);
g_demarker_b[0] = iDeMarker(_Symbol, PERIOD_M15, 16);
g_demarker_a[1] = iDeMarker(_Symbol, PERIOD_M15, 14);
g_demarker_b[1] = iDeMarker(_Symbol, PERIOD_M20, 20);
// ... 24 handles in total

static double upper_a[12]={0.7,0.7,0.7,0.7,0.7,0.7,0.9,0.5,0.9,0.7,0.7,0.7};
static double lower_a[12]={0.3,0.3,0.3,0.3,0.3,0.3,0.3,0.3,0.3,0.3,0.3,0.1};

Look at M6, M10, M12 and M20 — non-standard periods that do not even exist on a default MT5 chart. There is no trading rationale for a 6-minute or 20-minute bar; there is only one reason to pick them, which is that they scored better in a parameter sweep. Same story with the thresholds: nearly all are 0.7/0.3, except strategy 7 at 0.9, strategy 8 at 0.5 and strategy 12's lower band at 0.1. Isolated exceptions like that are the fingerprint of "nudge this cell until the curve smooths out".

Count the degrees of freedom: each strategy carries an entry timeframe, two sets of (indicator timeframe + period + upper + lower), a session window, a grid step and a target distance — roughly 13 tunable numbers. Times twelve, that is about 150 free parameters fitted to a single symbol.

Eight of twelve strategies are long-only, and nothing carries a stop loss

int StrategyDirection(const int slot)
  {
   ...
   if(slot == 4 || slot == 5 || slot == 10 || slot == 11)
      return -1;
   return 1;         // the other eight are long only
  }

// order entry: parameters 4 and 5 are SL and TP — both passed as 0
g_trade.Buy(volume, _Symbol, 0.0, 0.0, 0.0, SafeComment(slot));

Eight of the twelve strategies are long only. Combine that with an unstopped grid that averages down up to 100 times per strategy, then run it over 2020–2026, a stretch in which gold went from 1,500 to over 3,000. That combination can barely lose money in a backtest. What is being measured is the market regime, not the strategy. We wrote about this structure separately: how dangerous are grid and Martingale EAs.

Worth noting: the only brake, InpDDMode (drawdown control), ships disabled by default.

Change broker, change which strategies are enabled

if(InpSets == QQ_PRESET_ICVT_HIGH)
   return slot==0 || slot==1 || slot==2 || slot==4 || slot==5 ||
          slot==7 || slot==8 || slot==9 || slot==11;
if(InpSets == QQ_PRESET_ICVT_MEDIUM)
   return slot==0 || slot==2 || slot==7 || slot==8 || slot==11;
if(InpSets == QQ_PRESET_ROBO_ECN)
   return slot==0 || slot==2 || slot==3 || slot==4 || slot==5 ||
          slot==7 || slot==8 || slot==9 || slot==11;

The marketed "broker-specific set files" reduce to a different subset of enabled strategy numbers per broker. What genuinely differs between brokers is spread, commission and execution quality — those belong in cost parameters, not in "enable strategy 6 at broker A and disable it at broker B". This reads as a separate optimisation sweep run against each broker's historical feed.

About the source we publish

For clarity: what we list is the original v4.3 MQL5 source as provided by the author. We only cleaned it up for readability — unified the comments in English, removed the licence and trial checks, consolidated the twelve strategies from six parallel arrays into one configuration table, and collapsed the thirty-odd per-tick position rescans into a single snapshot.

Not one number in the strategy tables, session rules, signal thresholds or exit logic was touched — including the three date tables this article criticises. We deleted nothing; they sit verbatim in the source package and are called out by name in its README. If you are going to criticise something, people need to be able to open it and look.

Verify it yourself, in three steps

1. Open the source and search for 2021. All three tables sit in the configuration section in plain sight. No tooling required.
2. Delete them and re-run the identical backtest. Force multiplier to 1, empty pause_dates, then run the same symbol, timeframe, date range and real-tick mode again, and put the two curves side by side. The gap is what those three tables were "contributing". For a testing setup that does not fool you, see how to backtest an EA in MT5.
3. Read the author's live signal, not the backtest. On a live account those tables never match a single day, so the live curve is the strategy's honest level. For the traps in reading signal pages, see verifying an EA with Myfxbook.

So why do we still sell it

We are not going to pretend to be above this. Quantum Queen X is a working grid EA that does make money while a trend cooperates, and its live signal is public and checkable. We sell it — and we do three things alongside that:

• Price it honestly. It is $110 here, not the price tag that a retouched backtest is used to justify.
• State the risk. The product page says plainly that it builds grid positions and that floating drawdown balloons in extreme one-way moves. We publish our own drawdown too.
• Publish the source so anyone can check. We did not delete a single line of those three date tables — they are preserved verbatim in the source-code listing. If you are going to criticise something, people need to be able to see it.

A closing thought for anyone currently staring at an equity curve: when a curve runs from 2020 to today without a serious drawdown, the question to ask is not "how much does it make" but "did it already know the answers". Only the source code can tell you that.

Risk note: this is a technical analysis of source code, not investment advice, and not a legal characterisation of the author's conduct. All EAs and quant strategies can lose money; forex and precious-metals trading is high risk — only trade with money you can afford to lose.