Best Practices

Strategy Design

Start simple, add complexity carefully

The most common mistake in algorithmic strategy development is adding too many conditions too quickly. A strategy with 5+ conditions may appear to improve backtest metrics, but is often overfitting to historical noise — it has "memorized" the data rather than captured a genuine edge.

Start with the simplest possible expression of your hypothesis: one entry signal and one exit signal. Backtest it. Then add conditions one at a time, and verify each addition actually improves out-of-sample behavior using the analytics modules — particularly Condition Removal Impact.

Separate entry and exit logic

Keep entry and exit conditions independent. Entry conditions should identify favorable setups; exit conditions should manage risk once in a trade. Avoid using the same indicator value for both — this creates circular logic where entries and exits trigger too close together.

Always gate on IN_POSITION

Structure your strategy so buy logic only runs when not in a position, and sell logic only runs when in a position:

// Typical structure:
if (NOT In Position) {
  if (entry condition) {
    BUY $500
  }
} else {
  if (Take Profit 5%) {
    SELL 100%
  }
  if (Stop Loss 3%) {
    SELL 100%
  }
}

Skipping the IN_POSITION guard can cause duplicate buy signals or premature exits. The runner won't open a second position if one is already open, but without the guard, buy conditions will still evaluate on every tick even while holding a position, consuming unnecessary processing and creating misleading condition log entries.

Use cooldown bars to prevent overtrading

After a trade closes, many strategies generate new entry signals before the market has settled. The Cooldown Bars block enforces a minimum waiting period before re-entry:

if (NOT In Position AND Cooldown Bars >= 5) {
  if (entry condition) {
    BUY $500
  }
}

Test each timeframe deliberately

When using multiple timeframes, the primary timeframe (the first in the@hornpub-timeframes manifest) drives the bar loop in backtesting and the run interval in live mode. Use higher timeframes for trend filters and the primary timeframe for entry signals. Mixing them carelessly can create look-ahead bias in backtests.

Backtest Workflow

A backtest is only as useful as the process around it. Follow this workflow to get meaningful results:

1. Define your hypothesis first

Write down what market behavior your strategy is trying to capture before building it. "RSI divergence on 1h in an uptrend" is a hypothesis. Randomly adding indicators until backtest metrics look good is not a strategy — it is overfitting.

2. Run an initial backtest with maximum available data

Use the maximum available range for your timeframe. For 1h strategies, up to 1 year is available. For daily strategies, up to 5 years. A longer test reduces the risk of drawing conclusions from a lucky period.

3. Evaluate the full analytics suite

Don't stop at the summary metrics. Review all 8 analytics modules in order:

4. Walk-forward test

After iterating, run a final backtest on a date range you haven't touched during development. If performance degrades significantly on unseen data, the strategy has overfitted. Consider simplifying before proceeding to paper mode.

5. Check behavior across different market regimes

Use the Regime Analysis module to confirm the strategy performs across multiple regime combinations (uptrend + high vol, uptrend + low vol, downtrend, sideways). A strategy that only works in "bull market + high volatility" will fail badly during other periods.

Using Analytics Modules Effectively

Signal Quality as your primary signal filter

The Signal Quality module shows whether buy signals were followed by favorable price moves. A "Good" signal is one where the maximum favorable excursion (MFE) after entry outweighs the maximum adverse excursion (MAE). Target a Good rate above 50% for buy signals. A strategy where most buy signals are "Bad" has inverted logic — consider reversing the entry condition or switching to a different indicator.

Condition Removal Impact for pruning

For each condition in your strategy, this module asks: "if we removed this condition, would signal quality improve?" If removing a condition improves quality, that condition is filtering out more good signals than bad ones — it is actively hurting the strategy. Remove it. Only keep conditions that, when removed, make signal quality worse.

Strategy Autopsy for condition diagnosis

The Autopsy module compares how often each condition was true in winning trades vs. losing trades. A condition that appears with equal frequency in wins and losses (near 0% differential) is providing no discriminating power. A condition that appears much more in winning trades than losing trades is a genuine edge component — keep it and consider making it stricter.

Regime Analysis for risk assessment

Before going live, use Regime Analysis to understand in which market regimes the strategy performs well and poorly. If the strategy has a negative win rate in downtrends, add a Trend Direction filter to block entries during downtrends. If it performs badly in low volatility, add a Volatility Regime filter.

Paper → Live Transition

The transition from paper to live is where most avoidable losses happen. Follow these principles to manage the transition safely.

Paper mode duration

Run the strategy in paper mode for at least 1–2 weeks at the same run interval and symbol configuration you intend to use live. Paper mode does not account for slippage or fees, but it will reveal logic errors, timing issues, and behavioral surprises that don't show up in backtests. If the paper results diverge significantly from the backtest projection, investigate before going live.

Start small

Set the BUY block's USD amount to a small fraction of what you eventually intend to trade. Start at 10–20% of your target size. Verify the first few live trades match expectations — check the Trade Detail Modal for correct conditions, fill prices, and slippage — before scaling up.

Use Max Trades Per Day as a circuit breaker

During the initial live period, set Max Trades Per Day to 1 or 2. This caps the downside if the strategy produces a burst of incorrect signals. Once you've observed stable behavior over several weeks, you can relax the limit.

Monitor the first 48 hours closely

Check the Logs tab frequently during the first two days of live operation. Confirm each run produces the expected log pattern: "Run started → [Result log] → Run finished OK". Any error-level logs in this period should be investigated immediately.

Risk Management

Always use a stop loss

Every strategy that opens long positions should have a stop loss condition. Without one, a single bad trade on a volatile move can wipe out months of gains. The Stop Loss block evaluates against entry price in real time — it is the simplest and most reliable way to cap downside per trade.

Position sizing

The BUY block takes a fixed USD amount. This is simple but ignores account size as the account grows or shrinks. For more sophisticated sizing, use the Position Valueblock to gate exits and the account context to scale entries. A common rule is never risk more than 1–2% of account capital per trade — size the BUY USD accordingly.

Diversification

Running the same strategy on multiple symbols increases exposure but can also diversify risk if the symbols are not highly correlated. However, be aware that in a broad market selloff, most crypto pairs move down simultaneously — correlation increases during stress. Position sizes should be reduced when running on multiple symbols.

Market hours and liquidity

Consider using Trade Hours to restrict entries to periods of higher liquidity. For BTC and ETH, liquidity is reasonable 24/7. For smaller-cap pairs, avoid trading during low-activity hours where spreads widen and MARKET orders can produce significant slippage.

Never trade capital you cannot afford to lose

This is not a disclaimer — it is a constraint that should literally inform the USD amount you configure in the BUY block. Algorithmic strategies can and do lose money, including rapidly, under unexpected market conditions. Backtest performance is not a guarantee of future results.

Debugging Strategies

Strategy not trading when expected

Open the Logs tab and look at the "Result" log for each run. If you see "No trade conditions met" repeatedly, the entry conditions are not being satisfied. Run a backtest over recent data and check the Trigger Stats module — it will show the true rate of each condition. A condition that is never true will block all entries.

Strategy trading too frequently

Check the Strategy Behavior module in backtest — look at average hold time and signal frequency. If signals fire on nearly every bar, the conditions are too loose. Use the Cooldown Bars block to enforce a minimum gap, or tighten the entry conditions using Trigger Stats to find conditions with low true rates.

Unexpected trade timing

Open the Trade Detail Modal for an unexpected trade. Review the condition table carefully. Each row shows the exact value at the time the trade was placed. If a condition has an unexpected value (e.g. an indicator is in range you didn't expect), the data is correct — your expectation of the indicator's behavior was wrong. Verify the calculation in the Blocks Reference and compare with your charting tool.

Indicators returning NaN

NaN values from indicators usually mean insufficient data. This happens when the loaded candle count is less than the indicator's minimum required bars (typically 2× the period for RSI, 1× for SMA/EMA). In backtesting, the warmup period handles this automatically. In live mode, the kline cache needs to have accumulated enough history after the first bootstrap. For very slow timeframes (1d), this can take longer.

Live results differ from backtest

Some divergence is expected — paper/backtest fills at mark price with no fees; live fills at real market price with fees and slippage. Large divergence usually indicates one of: (1) the strategy is sensitive to the exact entry price (tight TP/SL), (2) the backtest range ended before a regime change, or (3) the strategy overfitted to historical data. Use the Regime Analysis module to check whether live behavior matches a regime the backtest performed poorly in.