From Contract Rules to Paper Trading: A Complete Checklist for MGC Micro Gold Futures

Adding MGC to a watchlist takes seconds. Getting it to run by rule inside a strategy instance usually takes weeks, and most of that time is not spent on the strategy. It is spent turning a pile of vague words into definitions you can check: what one tick of this contract is worth, how a continuous series is stitched together, which 23 hours a daily bar actually covers, whether one tick of slippage is enough, and which state the phrase "it's running" refers to.

This checklist follows the order a real research effort takes: contract first, then data, then cost, then parameters, and only then paper trading. Where possible, each section gives a definition you can verify rather than advice that feels reassuring.

The one-minute version

• MGC is a 10 troy-ounce COMEX micro gold future with a 0.10 dollar-per-ounce tick, which is 1 dollar per contract per tick.
• Continuous futures are constructed. Without adjustment, a roll date manufactures a gap that never happened.
• A COMEX trading day runs from 18:00 ET to 17:00 ET the next day. A naive timestamp needs a declared timezone, or the same file produces two different results.
• Cost is never "one tick". It is several ticks plus commissions, and a conclusion should survive 0, 1 and 2 ticks of slippage.
• "Running" means at least five separate states. Missing one of them is not running.

Separate the three environments first

Backtesting, broker paper trading and a product demo answer three different questions. Blending them produces conclusions that cannot be supported by any of them:

• Backtesting answers "what would these rules have done on this historical data". The answer depends entirely on data quality and execution assumptions.
• Paper trading answers "what do these rules do through this connection, this account and this execution path". It tests the workflow.
• Demo answers "what does this software look like". Its quotes and fills are samples, not market evidence.

A smooth run in paper trading shows the pipeline works. It says nothing about edge. A profitable demo session says even less: it does not even show the pipeline works. None of the three can serve as evidence for another. Record the environment label on the first line, and use the fields in A Paper Trading Review Checklist rather than inventing new ones each time.

The contract facts: three numbers define your risk unit

The multiplier is 10, so a 1 dollar move in the underlying moves one contract by 10 dollars. GC, the standard gold future, is 100 ounces with a 10 dollar tick. MGC is one tenth of it in both size and tick value. That is the whole meaning of "micro": a different size, not a different underlying.

Those three numbers together determine one thing: the smallest risk unit you can actually take. At 4,000 dollars per ounce, one MGC contract carries roughly 40,000 dollars of notional value. With an 8 dollar stop distance, one contract risks 80 dollars. An 8,000 dollar account with a 1% per-trade risk budget can take exactly one contract; a 4,000 dollar account cannot take even one. Futures do not have fractional contracts, and shrinking the risk budget does not make the unit finer.

Do not copy these numbers by hand into order logic. At order time, read the multiplier and tick from the contract details your broker returns, and keep prices on the tick grid: limit and stop prices are normalized to the minimum increment, or the order gets rejected, or fills somewhere you did not intend.

Rollover: a continuous series is constructed

Futures expire, and research needs a long series. Stitching several expiring contracts into one continuous history is a modeling decision, not a data transfer.

The three common approaches each pay a price:

• No adjustment. A gap appears on every roll date, produced by two different contract prices. It belongs to no market. If a strategy opens or stops out near a roll, the backtest quietly contains a gain or loss that came from data construction.
• Difference adjustment. Historical prices are shifted by the spread. The price level becomes continuous, but early prices are rewritten to values that never traded.
• Ratio adjustment. Prices are scaled. The relative structure of returns survives better; absolute price levels still change.

None of these is "correct". The only requirement is that the choice is written down. A research record should state which method was used, which dates the rolls fell on, and whether any roll landed inside the sample.

More error-prone than the method is the main-contract rule. "Use the nearest month" is the easiest rule to write and often the wrong one, because the front month is frequently the least liquid. In our own implementation the switch requires evidence: the next month has to exceed the previous month in volume across two consecutive complete sessions before the main contract is considered to have moved. If the evidence is missing, if dates are interrupted, or if volume cannot be confirmed, the state stays where it is rather than defaulting to the nearest month. It is a conservative rule, and its purpose is to avoid changing the instrument a backtest is measuring while nobody is looking.

A live instance has a separate constraint: the execution contract is frozen. A roll does not rewrite the contract used by an instance that already holds a position, and rebinding is refused outright while the old contract still has a position or working orders. "It expires, so the system rolls it" is a wrong expectation. A roll is an operation, not an automatic behaviour.

Session clocks: the sample boundary is a definition

A COMEX gold trading day opens at 18:00 ET and closes at 17:00 ET the next day, with a maintenance window between 17:00 and 18:00. A trading day therefore spans two calendar dates. A daily bar labelled November 2 actually covers 18:00 ET on November 1 through 17:00 ET on November 2.

Two specific traps follow.

First, a naive timestamp has no unique meaning. Take the same CSV with no timezone marker. Interpreted in exchange time (ET) versus UTC+8, bar boundaries shift by 12 to 13 hours, and the same strategy produces entirely different samples from the same file. The convention we use is that naive timestamps are always interpreted in the contract's exchange timezone, while the real IB data path uses epoch seconds so no string-based timezone inference happens at all. That removes "which timezone is this machine in" as a hidden variable.

Second, the ET offset changes twice a year. In the week of a daylight-saving switch, the UTC instant corresponding to 18:00 jumps by an hour. A fixed offset applied to session boundaries is wrong twice a year, and usually wrong during the two most interesting weeks.

The verification is unglamorous: pick a known holiday or early close, count the bars for that day, then print the boundaries of the first and last bar and compare them against the exchange calendar. Those two steps catch most "the data looks fine" problems.

Cost is never "one tick"

Beginners treat one tick as the cost of a trade. The real cost is a stack of tick-denominated quantities:

• Bid-ask spread: the half spread paid relative to mid, on every leg.
• Entry slippage: the drift between the signal price and the fill.
• Exit slippage: stops usually fill worse than limits, especially when volatility is high.
• Commission: use your actual broker statement. Do not fill in zero, and do not copy someone else's number.

An arithmetic example, included only to show the structure: a 1 tick spread, 1 tick of slippage per side, and roughly 2.50 dollars round-turn commission puts the cost of one round turn near 5.50 dollars (0.5 tick half spread times two sides equals 1 dollar, 1 tick of slippage times two sides equals 2 dollars, plus commission). Stop slippage is additional. That figure is nobody's published rate; it exists to make one point: a tick is 1 dollar, and the cost is not 1 dollar.

A sensitivity sweep is more useful than arguing over an exact figure. Run the same test at 0, 1 and 2 ticks of slippage. If the conclusion flips at 1 tick it was never a conclusion. If it survives all three, the cost assumption is no longer the interesting question.

Parameter optimization produces candidates, not conclusions

The more parameter combinations you try on the same history, the more likely one of them fits the noise. This is arithmetic, not attitude: after 200 trials the best in-sample result necessarily looks good, and part of that goodness comes from the selection itself.

A few rules that measurably reduce self-deception:

• Record the search size. Write down how many combinations were tried and what they were, not just the winner.
• Change one variable at a time. Move the stop and the bar interval together and you cannot attribute the improvement.
• Hold out data. Either a later time slice or a rolling walk-forward, but the out-of-sample data stays unread until parameters are fixed.
• Change the wording of the conclusion. Replace "these parameters are best" with "on this data and under these cost assumptions, these parameters are a candidate". For the systematic treatment of backtest overfitting, Bailey et al., The Probability of Backtest Overfitting, is worth reading (paper).

For how to write the scope of a study down in the first place, Planning Reproducible Strategy Research covers that order.

Before paper trading, define what "running" means

This is the part most often skipped and most often responsible for surprises. "Start" looks like a button, but inside a system it is the result of several conditions being true at once. Compress those conditions into a single button and people conclude "I pressed start, so it is running".

At least five states should be kept apart:

1. Configuration saved — parameters and a version are written to disk. No trading action.
2. Activated — one version becomes the current effective version. Still no trading.
3. Instance enabled — this instance is permitted to run. Still no trading.
4. Started (RUNNING) — only an explicit start action reaches this state.
5. Live permission — an authorization independent of all of the above, granted per instance.

If any of the first four fails, the instance stays where it was; it does not end up "roughly running". Keeping them separate is what makes troubleshooting possible: when a start is refused, you can tell immediately whether the version was never activated, the instance was never enabled, or it was simply never started.

A real start also has to satisfy a set of gates at the same time. Miss one and the instance stays unstarted:

• the broker paper connection is confirmed, not "was connected earlier";
• an account safety snapshot is ready;
• automated trading permission is unlocked;
• position and working-order reconciliation is complete, with no unresolved orders;
• an activated strategy version exists;
• an execution contract has been selected and validated;
• independent real-time data for that instrument is ready and matches the frozen contract and interval;
• at least one completed bar exists;
• position ownership is clear, with no unattributed or externally held position in the same instrument.

The last one blocks starts more often than people expect. A position in the account is not automatically the strategy's position. An unattributed position cannot be taken over by automated logic; it must be attributed manually, or closed at the broker first. The rule looks bureaucratic, and what it prevents is automated logic managing a position whose entry price, initial stop and intent it does not know.

There is one more confirmation after entry that is easy to overlook: the protective stop has to exist at the broker and be confirmed. A fill only means someone took the other side; it does not mean risk is controlled. If the protective stop is not confirmed, the instance should sit in a waiting state rather than treat the entry as complete.

Stopping is not flattening

stop and disable mean "stop taking new actions", not "clear the position". They do not close anything. They record an audit warning and leave the position where it is for you to handle. That is deliberate: forced liquidation during thin liquidity can be worse than doing nothing. But it requires the operator to treat "stopped" and "flat" as two separate confirmations.

One more thing worth knowing in advance: after a process restart, transient run states are not restored as "still running". On load they are normalized to stopped, and resuming requires an explicit start again. "It should pick up where it left off after a restart" is another wrong expectation, and it is exactly where unexpected exposure tends to begin.

Finally, one boundary that should never be treated as a setting: maximum loss, hard stop, disaster stop, account and position risk limits, preflight checks and order validation gates do not change with a strategy version, a parameter search or any automated selection. A model may suggest when to enter. It cannot widen its own loss limit.

A review checklist you can use directly

The table below can be copied into your own records. Its purpose is not to judge the strategy but to make the context reconstructable later.

Limits, and the next step

This article contains no performance figures and does not assess whether MGC suits you. Contract specifications, margin and session hours change with the exchange and the broker; treat every number here as something to confirm against the current exchange specification and your own statements.

Honest limits remain. The risk unit of a micro contract is a whole contract, so position sizing is coarse at small account sizes. Gold reacts to macro events, and an overnight gap can clear a stop price without effort: a stop protects the ordinary case, not the worst case. And the liquidity assumed in a backtest may not exist during genuinely thin hours.

The next step needs no new tooling. Turn the table above into your own workflow, and on data you already know, write down four definitions first: contract, timezone, roll, cost. Until those are settled, any equity curve is only a good-looking picture.

If you want an existing workhorse for that pipeline, the public Algoryn beta puts MGC historical backtesting, parameter optimization and paper instance management in one Windows desktop workspace, paper trading only. The tool does not change the order of operations, though: get the definitions right first, then let the program run.