Magic Number

Magic number is a numeric identifier attached to a trade by a MetaTrader Expert Advisor (EA) or script. It lets the program recognize which orders, deals, or positions belong to its own strategy instead of treating every trade on the account as interchangeable. That distinction matters when several robots, manual trades, or strategy instances share one account, because the software must know what it is allowed to modify, close, trail, or report.

How the Identifier Travels Through a Trade

When an EA submits a request, it writes its chosen identifier into the trade request. MetaTrader then exposes that value through platform properties such as OrderMagicNumber() in MQL4 and ORDER_MAGIC, DEAL_MAGIC, or POSITION_MAGIC in MQL5. The exact object matters: an order is an instruction, a deal is an execution, and a position is the resulting market exposure.

A sound EA filters the account state before acting. It usually checks the magic number and the symbol, then confirms the trade type and current state. Filtering only by symbol is risky; two strategies may trade EURUSD at the same time but use different exits. Filtering only by magic number can also be too broad when one identifier is reused across several symbols or chart instances.

Choosing a Number Without Creating Collisions

The platform does not provide a universal registry of magic numbers. Developers choose the value, so uniqueness is an application-level responsibility rather than a broker guarantee. A collision occurs when two EAs use the same number and each assumes the other EA's trades are its own. The visible symptom may be strange stop-loss changes, duplicate closes, or a strategy reporting positions it never opened.

• Assign a distinct range to each strategy, environment, or account group.
• Store the assignment in source control, deployment notes, or a configuration registry.
• Avoid changing the number while live trades from the previous configuration remain open.
• Log the magic number, symbol, ticket, and action whenever the EA changes a trade.

The value itself carries no built-in meaning. Teams sometimes encode strategy, timeframe, or instance information into the digits, but that convention works only if it is documented and checked for overflow or duplication. A simple allocated ID is often easier to maintain than an elaborate formula.

Manual Trades, Zero Values, and Ownership Rules

Manual trades are commonly associated with a magic number of 0, while automated programs use non-zero values. That is a convention, not a security boundary. A script can submit 0, and imported or broker-side activity may not follow the pattern a developer expects. An EA that manages manual positions should therefore make that behavior explicit instead of assuming every zero-magic trade is safe to touch.

Ownership rules should be narrow. For example, a trailing-stop module may be configured to manage only trades with one magic number, on one symbol, and in one account mode. This prevents a helper utility from quietly interfering with discretionary trades or another robot. The rule sounds fussy, but a small filter mistake can become an account-wide incident.

MQL4 and MQL5 Behave Differently

In MQL4, EAs usually iterate through open orders, select each ticket, and compare its magic number before acting. In MQL5, the trade model separates orders, deals, and positions, so the correct property depends on what the code is inspecting. Developers porting an EA from MT4 often keep the old mental model and accidentally query the wrong object.

Account mode adds another wrinkle. A hedging account can hold several positions for the same symbol, which makes per-position ownership easier to preserve. A netting account keeps one net position per symbol. If several strategies trade that symbol, their executions can merge into one exposure, so a single position-level magic value may not provide a complete strategy ledger. In that case, operators usually reconstruct ownership from orders and deals, or prevent multiple independent strategies from sharing the same netted symbol.

Common Failure Modes and How to Diagnose Them

Logs are the fastest diagnostic tool. Each decision should record why a trade matched or failed the ownership filter. Without that evidence, developers tend to blame timing, broker behavior, or the platform when the real issue is a stale configuration or a reused identifier.

Designing Magic Numbers for Production Systems

A magic number should be treated as persistent configuration. Restarts, chart changes, server migrations, and software updates must not silently generate a new value while positions remain active. Random generation at startup is especially dangerous: the EA may lose the ability to manage its own open trades after a terminal restart.

For multi-account systems, the magic number is only one part of identity. Production records should also capture the broker account, symbol mapping, strategy version, ticket or position identifier, and timestamps. This is vital when a trade copier or execution service translates symbols such as EURUSD and EURUSD.a, because identical magic numbers do not prove that two broker objects represent the same intended trade.

Magic numbers also have limits. They do not stop another program from editing a trade, prove who created it, or replace a database audit trail. They are lightweight routing labels inside a trading workflow. Used with strict filters and durable records, they reduce accidental cross-strategy interference; used casually, they create a false sense of ownership.

When One Magic Number Is Not Enough

One identifier can be sufficient for a simple EA running on one symbol. It becomes less useful when the system has several sub-strategies, partial exits, portfolio-level risk controls, or external execution services. In those cases, teams may assign separate numbers by strategy component and keep richer metadata in comments, logs, or an external database.

Trade comments can help humans read activity, but brokers may truncate or alter them, so they should not be the sole machine identifier. External IDs are more flexible, yet they add synchronization work and failure handling. The practical approach is layered: use the magic number for fast platform-side filtering, then use persistent records for audit, reconciliation, and recovery.