Optimization Module Reference

HyperionX optimization is not only a grid search. The platform has separate concepts for strategy parameters, optimizers, fitness scoring, money management, commissions, validation, and performance metrics.

Module Categories

Category	Purpose
Optimizers	Decide how parameter combinations are searched.
OptimizationFitnesses	Score and rank results.
MoneyManagements	Control sizing and capital behavior.
Commissions	Model fees and costs.
Strategies	Provide the logic being tested.

Strategy Parameters

Use [HyperionXProperty] for values that should appear in optimization and validation workflows.

[HyperionXProperty]
[Display(Name = "Fast Period", GroupName = "Parameters", Order = 1)]
public int FastPeriod { get; set; }

The current optimizer creates editable search parameters only for [HyperionXProperty] values of type int, double, bool, or an enum. Other marked property types can still appear in script settings, but they are not automatically converted into optimizer parameters.

Keep parameter ranges realistic. A large search over meaningless values produces noise, not edge.

Fitness Scoring

A fitness module should rank results by the behavior the trader actually wants. Net profit alone is not enough.

The base API is:

public class MyFitness : OptimizationFitness
{
    public MyFitness()
    {
        Name = "My Fitness";
    }

    public override void OnCalculatePerformanceValue(StrategyBase strategy)
    {
        Value = strategy.NetProfit ?? 0;
    }
}

Set Value to the score that should be maximized by the optimizer.

Useful inputs include:

• net profit
• max drawdown
• profit factor
• Sharpe
• trade count
• average trade
• largest loss
• consecutive losses
• commission and slippage
• stability across nearby parameters

Closely Guarded Island Penalty

HyperionX research should penalize isolated winners. An isolated winner is a parameter set that looks strong but is surrounded by weak neighboring values.

Example:

Fast	Slow	Stop	Target	Net Profit	Neighbor Quality
17	43	38	74	$42,000	Weak
18	43	38	74	$4,500	Weak
17	44	38	74	-$1,200	Weak
16	42	36	70	$31,000	Strong cluster

The first row has higher profit, but its edge is fragile. A professional optimizer should prefer stable clusters over one lucky island.

The exact production formula can remain proprietary. The public concept is:

research score =
    base performance score
    - drawdown penalty
    - low-trade-count penalty
    - fee/slippage sensitivity penalty
    - isolated-neighbor penalty

This gives HyperionX a testing advantage because it rewards durable behavior instead of curve-fit peaks.

Walk-Forward Workflow

A robust workflow:

1. Optimize on in-sample data.
2. Select stable parameter regions, not only the top row.
3. Test selected parameters out of sample.
4. Roll the window forward.
5. Aggregate the out-of-sample results.
6. Review degradation, drawdown, and trade distribution.
7. Only then test in playback or simulation with an explicitly selected LocalPaper account. Playback does not select it automatically; the current release-candidate build rejects external-account order mutations while Playback is active.

Commission And Slippage

Commission models and slippage assumptions should be active before trusting backtest results. A system that only works with zero fees is not a production system.

Commission modules implement:

public override double GetCommission(Trade trade)
{
    return 0;
}

For crypto, futures, equities, and broker-specific routing, the commission model should account for:

• maker/taker fee differences
• minimum commission
• exchange fees
• account type
• leverage costs where relevant
• expected spread/slippage

Money Management

Money management modules implement:

public override int GetQuantity(double price, double mult)
{
    return 1;
}

In the active release-candidate StrategyBase, selecting a money-management module applies it to every strategy entry, including managed helpers and direct entry submissions. Return values are interpreted as follows:

Return value	Current release-candidate behavior
Positive	Replaces the requested entry quantity.
-1	Preserves the strategy's requested quantity.
0 or another negative value	Suppresses creation of the entry order.

This behavior changed during the 1.1.10 release audit and must be treated as a release-sensitive Preview contract until the signed package is frozen and certified. It is not an account-level maximum-size or loss guard, and it does not replace provider validation. Test managed and direct entries in every intended calculation and account mode after an upgrade.

Within that boundary, a module can separate entry logic from research sizing logic and test approaches such as:

• fixed quantity
• fixed notional/USD size
• percent of equity
• volatility-adjusted sizing
• drawdown-based reduction
• account-specific limits

Treat live multi-client or multi-account sizing as strategy and account-risk logic. Confirm the final quantity at the order/account layer rather than assuming the selected module enforced a broader risk policy.

Product-owned defaults and reserved names

The active release-candidate source registers four defaults independently of the custom assembly: Default Optimizer, Max Net Profit, Strategy control, and No commission. Those display names are reserved case-insensitively. A custom optimizer, fitness, money-management, or commission type with a matching name is skipped during discovery and logged.

Use a distinct Name for every custom module. Candidate source and installer-manifest coverage do not prove fresh-install availability; verify discovery with the exact clean, signed installer before depending on these defaults.