Aethon Phantom v11

Aethon Phantom v11 explores a detailed approach to automated XAUUSD trading, combining eight session modules with momentum checks across two timeframes. Each module has its own trading window and bar schedule. This gives the underlying design a specific rhythm: it waits for a scheduled opportunity, checks the conditions assigned to that session, and manages any resulting positions as a basket. For traders interested in how a gold EA makes and manages decisions, Phantom provides a concrete example of a strategy with several layers of timing and execution logic.

The particular v11 build reviewed here is a research experiment. Its saved test includes trade-direction changes on dates chosen after reviewing historical market behaviour. Those changes materially affect the results. This page therefore explains the design and the experiment openly, rather than presenting its simulated gains as evidence that customers could have achieved the same outcome using a rule available in advance. A credible product description should make that distinction easy to see before a visitor reaches a performance chart or considers buying a licence.

Eight modules with their own trading windows

The underlying session framework contains eight named modules: Vega, Rigel, Altair, Lyra, Orion, Deneb, Sirius and Castor. They do not all evaluate the same bar interval or trade throughout the entire day. Instead, each checks its own conditions during a defined window. This structure lets the strategy distinguish between opportunities occurring at different times, with separate settings for the individual modules. It also makes the design easier to examine: a researcher can identify which session generated an entry and investigate the behaviour of that module independently.

Session timing matters because the same indicator reading can occur under different trading conditions. A signal during a quieter part of the day may develop differently from a signal during a more active period. Phantom's framework responds to that problem by assigning entry opportunities to specific windows. It does not establish that those windows will remain profitable. Their value is that they create a defined, testable framework, so a trading decision can be traced to a session, a bar and a known set of conditions.

Momentum confirmation across two timeframes

Entries use two DeMarker readings on two timeframes. Both must fall within the module's specified zones before the underlying entry condition is satisfied. In the ordinary framework, upper-zone conditions support buy entries and lower-zone conditions support sell entries. Checks occur at the opening of the module's own bar. This gives the entry process a measurable basis and avoids describing the EA as trading on an undefined sense of market direction. Its decisions originate in specific readings evaluated at specific times.

Two confirmations still share the limitations of the data and indicators behind them. They can agree immediately before a reversal, or remain aligned while an existing basket moves into a loss. A description of Phantom should therefore explain what the filters check without calling them proof of an upcoming move. For a prospective user, the useful question is how the complete system behaves when the signal is wrong, including the additional positions it may open and the exposure those positions create together.

Positions managed as one basket

Once a basket is open, the strategy manages its positions collectively. Additional legs use equal lot sizes, and the documented logic allows an extra leg at most once per minute when price has moved the required fixed dollar distance beyond the worst existing leg. The basket then seeks a shared exit when its combined price condition reaches the configured target. New baskets start only when the account has no existing open basket, and the strategy does not immediately start another on the same minute a basket closes.

Equal-sized additions are an important design detail, but they do not prevent exposure from increasing. Ten equal-sized positions commit more volume than one. If the market continues moving against the basket, floating losses and margin requirements can rise even though the lot size of each additional position stays unchanged. The reviewed settings allow up to 100 legs, while the optional basket percentage stop is disabled in the saved test. That combination makes the basket's adverse-path behaviour especially important when assessing the design.

What changes in the v11 experiment

The reviewed v11 build adds a date-specific override to the underlying v5 final logic. On 6 and 7 October 2026, every new basket opens as a sell. Buy-session signals still determine when an entry qualifies, but the resulting trade direction is reversed on those dates. Existing sell-session entries remain sells. The source explicitly describes the dates as selected after seeing the market. The saved report includes the corresponding date input, confirming that this was part of the tested configuration.

That is a counterfactual experiment: it asks what the basket system would have done with different directions on known historical days. Such an experiment can help a developer investigate sensitivity to directional exposure. It does not provide a deployable method for identifying future dates on which direction should be reversed. A buyer evaluating automated trading needs rules that can operate using information available at the moment of decision. The difference between those two situations is central to understanding the figures below.

The saved research figures

The local v11 report covers 1 April to 24 October 2026 on XAUUSD, starting with $10,000. It records $26,899.70 net profit, a 3.71 profit factor and 421 trades. Its profitable-trade percentage is 81.71%, and maximum relative equity drawdown is 26.64%. The tester labels the history as 100% real ticks. The arithmetic return on the starting deposit is 269.00%, rounded to two decimals. These figures describe the saved experiment, including its hindsight override; they are not suitable as an advertised investment-performance claim.

The accompanying research chart is labelled accordingly. It shows reported account balance after deals, rather than reconstructing a continuous floating-equity history. A rising balance line can coexist with significant open losses between closes. Likewise, high tick-history quality describes the historical data used by the tester; it does not remove hindsight from the trading rules. Both distinctions matter here because the most visually appealing part of a simulation can otherwise draw attention away from the way the simulation was constructed.

Position sizing and account exposure

The framework supports balance-based sizing and a fixed-lot alternative. These choices affect how position volume changes as the simulated balance rises or falls. They should be reviewed alongside basket spacing, the maximum number of legs and the optional percentage stop. Comparing only the final profit can conceal the degree to which a result depends on compounding exposure. A useful evaluation examines the entire configuration together, rather than treating a single sizing input as a complete measure of risk.

The reviewed basket system has no stop-loss by default and averages into adverse moves. A prolonged directional market can therefore cause severe losses, including the loss of the entire account. Calendar controls and session filters restrict when new baskets begin, but they do not turn an existing basket into a position with a fixed maximum loss. Visitors should understand that distinction before considering any future commercial version of this framework. A schedule is an entry rule, not a substitute for a defined exit under adverse conditions.