Clenow Follow The Trend - Futures Trading Strategy

Here are concrete bugs and issues in Chetan's code that would lead to major problems or cause the strategy to lose equity or break futures handling in QuantConnect:

1. Incorrect Property and API Attribute References (Critical)

• The code uses lower-case property names for core QuantConnect objects, which are case-sensitive:

  • self.portfolio → should be self.Portfolio
  • self.securities → should be self.Securities
  • self.is_warming_up → should be self.IsWarmingUp
  • self.futures_list's items: .mapped, .symbol_properties → should be .Mapped, .SymbolProperties
  • data.symbol_changed_events → should be data.SymbolChangedEvents
  • data.bars → should be data.Bars

  These will all raise AttributeError at runtime, causing the algorithm to halt or behave unpredictably. No trades or signals will execute as intended.

2. Indicator Calculation and Price Reference Are on the Canonical Symbol (Logical Bug)

• All indicators (SMA, EMA, ATR, min, max) and the close price (self.close) are based on the root/canonical Symbol.
• In QuantConnect, you must use the currently mapped (active/rolled) contract for trading decisions, price, and indicator computations.
• Using the canonical symbol for indicator signals can give you "ghost" signals (from back-adjusted data not tradable in real time) and misaligns entries/exits from the real contracts. This causes trades to trigger at prices that are not available, or after a contract is no longer liquid.

3. Rollover/Contract Mapping Issues

• Rollover logic sets pending_roll using positions for symbols even where the position size is zero; this can cause roll attempts forever on non-held contracts.
• When rolling, old positions are closed using MarketOrder(old_symbol, -quantity, tag="Rollover"), but any existing stop or risk orders on the old contract are left open—these could be triggered later, leading to positions in illiquid or expired contracts.
• A corresponding stop/risk order is not opened immediately on the new contract after roll, leaving the position unprotected.

4. Position Sizing Is Unsafe

• The position sizing calculation:

  num_contracts = round((self.risk_factor * self.portfolio.total_portfolio_value) / (atr20 * point_value))
  

  will blow up if atr20 is zero (indicator not fully ready/warmed up). This creates zero-division or very large numbers.
• There is no robust check for indicator .IsReady before using .Current.Value.

5. Entry/Exit and Signal Handling

• When checking for entry/exit signals and placing new trades, the code only checks for currently held investments, but would ignore pending open orders, possibly stacking orders and opening more positions than intended.
• The exit logic uses the mapped symbol, which is correct, but the entry logic could act on the wrong series if indicator is computed on canonical, while order is placed on mapped.

6. Dictionary Keys and Duplicates

• HRW_WHEAT is present twice in the futures list. Since the key in self.futures_data is the canonical symbol, it will overwrite itself and cause confusion/errors in indicator storage and position tracking.

7. Wrong DataMappingMode Settings

• Setting DataMappingMode.OPEN_INTEREST with contract_depth_offset=0 means the canonical can "jump" to any contract that suddenly gets highest OI. On illiquid contracts, this can cause premature or unexpected rolls away from front-month, increasing noise and trading costs.

8. Trailing Stop and Order Event Logic

• The code creates a trailing stop whenever a long entry is filled. If roll logic or exit logic triggers, any old stops on the previous contract remain open.
• Additionally, sign conventions in trailing_stop_order could become confusing or incorrect if you start shorting.

Summary:

• The main root cause is the (Python-case sensitive) use of wrong-case property names, which will prevent the algorithm from running as intended.
• Indicator signals are mismatched to tradable contracts, likely causing signals on unavailable prices.
• The rollover logic is incomplete and mishandles alive stop orders.
• Position sizing can crash due to indicator warmup or zero division.
• Portfolio/invested detection does not account for pending risk orders or duplicate contract roots.

To fix:

• Always use the correct QuantConnect property names (capitalized).
• Ensure all trade logic, indicators, and order placements work with the mapped (current) contract symbol, not the canonical.
• Clean up rollover logic to cancel/replace stops and not act on zero-quantity rolls.
• Check indicator readiness before entry sizing.
• Remove duplicate futures roots from your Universe.

Would you like concrete examples on how to correct any specific part of the code?

Sources: Debugging - QuantConnect.com, Key Concepts - QuantConnect.com, docs writing algorithms securities asset classes futures handling data, Key Concepts - QuantConnect.com, Key Concepts - QuantConnect.com

Mia's answer wasn't really helpful, if anyone else has any ideas, please let me know 

Hey Chetan, I'd be happy to help you build this strategy! From what I've found online it looks like the strategy employs the entry model you referenced, an ATR based sizing model, and a trailing stop loss = 3 * ATR(100)If you'd be willing to share your logic I'd love to help you build it out and get it running!

Thanks Graham! The logic is:

Universe: A large basket of diversified futures (Currencies, Dairy, Energy, Financials, Grains, Indices, Meats, Metals, Softs). Maybe pick 50 that are regularly traded.

Entry: If EMA(50) > EMA(100) and Price is at 100 day high, go long

Exit: If Price hits 50 day low, exit

Sizing: Using ATR(20), risk approx 0.15% of the portfolio daily on any one position.

Stops: It does not appear that Clenow uses stops in his strategy. Feel free to optionally add one.

I think that covers it. You can take a look at the backtest that I attached in the original post to give you an idea about how I thought about it. Thank you again for your help!