[Technical Report] Farewell MT4. Execution environment migration to cTrader based on process design and logic synchronization

■ Introduction: The Disparity Between a Perfect Blueprint and an Imperfect Manufacturing Line

In the early morning observing environment wrapped in silence. The Python backtest results displayed on the monitor quietly demonstrated the robustness of the logic built by our Semura Lab. After more than a decade of harsh walk-forward testing (WFA), data showing a win rate of 55–57% with drawdown kept to an absolute minimum is not the product of overfitting. It is the “true value” that captures the fundamental physical laws of the market (edge).

However, the moment we attempted to deploy this perfect blueprint into the real environment, we have consistently confronted one structural barrier. The physical constraint of the legacy platform that has long been regarded as an industry standard: MT4.

■ 1. The Antique (MT4) Impedes Process Design

As a cold hard fact, at our current level of requirements, MT4 is merely an antique. It demands extremely tight take-profit and stop-loss (risk-reward ratio 1:1) of 5–8 pips, and its 32-bit architecture and processing delays exceed acceptable limits for the front end that enforces precise logic tracking even the fluctuations of the spread.

I am not a programmer who clings to the beauty of code. I am a “process design engineer” who builds the flow of information and the overall system logic. Even if the blueprint (Python) is perfect, forcing the logic to conform to MT4’s obsolete specifications is an engineering impossibility to tolerate. Tools should serve the process, not govern it; the process must govern the tools.

（※However, there remains a possibility that MT4 could be reused in future projects as a ultra-lightweight execution dummy that merely receives signals, with computational load minimized to the extreme. But at least we will completely withdraw from the main battlefields where complex logic is constructed and validated.）