Settings

Every number in the Properties and Inputs tabs shapes your results. Some shape them a lot. This page groups settings by how much they affect what the strategy tester reports, so you can focus your attention where it m...

Written By Axiom Admin

Last updated About 1 month ago

Settings

If you have not reviewed the Properties tab yet, go back to Quick Start. The strategy will not run until you confirm that review.

Tier 1 — Settings that change everything

These settings affect every trade, every equity calculation, and every metric in the results. Changing any one of them will produce a different equity curve from the same YAML and the same historical data. They are not just parameters — they are the assumptions your results are built on. Two users running the same YAML on the same chart with different Tier 1 settings are running different tests. Comparing their results is meaningless unless these settings match.

Initial capital

Default: 100,000 · Location: Properties tab

The baseline for all percent-of-equity calculations. Every entry's allocation percent is computed against equity derived from this starting number. If you change initial capital from 100,000 to 10,000, every position size changes, every equity curve scales differently, and every percent-based metric shifts.

Set this to something realistic for your actual account. A strategy that looks profitable at 100,000 may behave differently at 10,000 because position sizes round differently and commission eats a larger share.

Commission

Default: 0.1% per trade · Location: Properties tab

Applied to every simulated fill — entries and exits. The default is reasonable for some crypto spot exchanges, but it is wrong for most equities brokers (who charge per share) and most futures brokers (who charge per contract). It may also be wrong for your specific crypto exchange.

What breaks when commission is wrong: If commission is set too low, the equity curve is flattered. Strategies that look marginally profitable at 0.05% commission may be unprofitable at 0.1%. If you are testing a high-frequency strategy with many round trips, even small commission differences compound fast.

Check your broker's actual fee schedule. Use that number. Do not guess.

Slippage

Default: 15 ticks per fill · Location: Properties tab

Simulated price impact applied to every fill. On a MARKET buy, the fill price worsens by 15 ticks. On a MARKET sell, it worsens by 15 ticks in the other direction. Limit orders are also affected — the tester requires the price to move 15 ticks past the limit before it considers the order filled (controlled by the backtest_fill_limits_assumption setting, which also defaults to 15).

15 ticks is a ballpark. For a liquid large-cap equity, it may be too conservative. For a low-liquidity altcoin, it may be wildly optimistic.

What breaks when slippage is wrong: Slippage at 0 produces the most flattering possible results. Every strategy looks better with no slippage. This is the single easiest way to fool yourself. If your strategy is profitable at 0 slippage but unprofitable at 15 ticks, the profitability was likely a fiction of the fill model, not a property of your rules.

Sensitivity test: Run your strategy at 0, 5, 10, and 15 ticks of slippage. If the equity curve collapses as slippage increases, the edge is thin enough that real-world execution costs will likely erase it.

Pyramiding

Default: 50 · Location: Properties tab

The maximum number of concurrent open trades the strategy tester will allow. Fifty is the script's default because the tool supports complex multi-entry, multi-setup strategies that may legitimately need many concurrent positions.

But 50 is not a recommendation. For most strategies, 50 concurrent positions is unrealistic. If you have two entry types that can each fire multiple times, combined with percent-of-equity sizing, the compounding position size can grow far beyond what your actual account would support.

What breaks when pyramiding is too high: Position sizes balloon. The tester happily opens 30 concurrent trades at 10% of equity each, producing a theoretical position that represents 300% of equity. This shows a leveraged result that may not be achievable or survivable in reality. Worse, as the strategy accumulates unrealized profit from those open trades, the equity base grows, which makes each subsequent entry larger (because sizing is percent of equity). The compounding effect can produce equity curves that look explosive on the way up — and would be equally explosive on the way down in a drawdown scenario.

The interaction between pyramiding and percent-of-equity sizing is the single most common source of unrealistic backtest results. A strategy with 50 pyramiding and 10% sizing is not a 10% risk strategy — it is a strategy that can deploy 500% of its initial capital across concurrent trades. Before interpreting any result, make sure the pyramiding limit and the allocation size together represent a total exposure you would actually accept in a live account.

Set pyramiding to the number of concurrent positions your strategy actually intends. If you are testing a single-entry, single-exit strategy, set it to 1.

Default quantity type and value

Default: percent_of_equity at 10% · Location: Properties tab

How the tester computes the base position size. At 10% of equity, the default entry quantity represents 10% of current equity.

This interacts with entry_allocation_percent in the YAML. The YAML field is a multiplier against this base: entry_allocation_percent: 100 means 100% of the Properties default (the full 10% of equity in this case). entry_allocation_percent: 50 means 50% of the Properties default (5% of equity). All entry allocation percentages in a direction must sum to 100%.

This also interacts with pyramiding. If pyramiding allows 5 concurrent trades and the base is 10% of equity with a single entry at 100% allocation, you can have 50% of equity deployed — which may be fine or may be extreme, depending on your thesis.

Tier 2 — Settings that change specific behaviors

Strategy direction

Default: Long Only · Location: Inputs tab

Controls which YAML sections are evaluated. In Long Only, all short-side YAML is ignored. In Short Only, all long-side YAML is ignored. In Swing Mode, both sides are active and a long entry can close an existing short position (and vice versa).

Swing Mode is the most powerful and the most confusing. Direction reversals interact with pyramiding, OCA groups, and position cycle management in non-obvious ways. Test each direction in isolation before enabling Swing Mode.

Limit Order TTL (Time to Live)

Default: no global TTL · Location: per-entry YAML field entry_expire_after_bars

There is no user-facing global TTL control in this build. Non-MARKET entry order expiration is controlled per-entry via entry_expire_after_bars in the YAML. If you do not set entry_expire_after_bars on an entry, the order has no automatic expiration — it remains working until it fills, is cancelled by cancel_when, or the position cycle resets.

Risk controls

Four circuit breakers, all in the Inputs tab:

Control	Default	What triggers it
Max strategy drawdown	20% of equity	Drawdown from peak equity exceeds threshold
Max consecutive loss days	5 days	N consecutive losing days
Max intraday loss	10% of equity	Intraday loss exceeds threshold
Max intraday filled orders	10	N fills in one session

When any of these triggers, all new entries halt. No alert fires. No special message appears beyond the normal absence of new trades. The halt is silent.

See Rules & Risk for more on how these interact with the engine.

User consent checkbox

Default: unchecked · Location: Inputs tab

The strategy will not run until this is checked. It exists to force a review of the Properties tab before testing begins. If you check it without reviewing, the protection is meaningless — but you will not know that until your results depend on an assumption you never verified.

Tier 3 — Settings that matter in specific scenarios

Fill model settings

These live in the Properties tab and control how the tester simulates order fills:

Setting	Default	What it controls
Fill orders on standard OHLC	true	Fills use only the bar's OHLC — no intra-bar price sequence
Process orders on close	false	MARKET entries execute on the next bar's open, not the current bar's close. Note: MARKET exits use `immediately = true` and execute same-bar regardless of this setting.
Use bar magnifier	false	Whether the tester uses lower-timeframe data for fill resolution
Backtest fill limits assumption	15 ticks	How far past a limit price the market must trade before the order fills

Changing any of these changes the fill model, which changes the results. Results from one fill model are not directly comparable to results from another. If you change these settings, treat the new run as a different test, not a continuation of the old one.

Calculation settings

Setting	Default	What it controls
Calc on every tick	true	In real-time, the script recalculates on every tick. In backtesting, this has no effect (only confirmed bars are used).
Calc bars count	50,000	Maximum historical depth for the backtest

Currency

Default: USDT · Location: Properties tab

The accounting currency for equity and profit calculations. Must match the denomination of the trading pair. If you are testing on BTCUSD but the currency is set to USDT, profit calculations may not reflect what you expect.

Custom tokens

The Custom Token Section (Inputs tab) gives you 30 slots to connect external indicator outputs to the expression language. Without custom tokens, your expressions can only reference the built-in price, time, strategy, and position tokens.

Each slot has three fields:

Field	What it does	What to watch for
Name	The token name used in expressions	Case-sensitive. Must be unique across all token types. A collision produces a warning; the first-registered token wins.
Type	Number or True/False	Must match the indicator's output type. Mismatches produce unexpected values.
Source	The indicator plot on your chart	Must be connected to the correct plot. If the indicator has multiple outputs, make sure you select the right one.

Token name errors: If you reference a token name in an expression that does not exist in the token map, the engine raises an "Unknown identifier/token" error and the strategy will not run. This means a typo in a token name is caught during validation, not at runtime. However, a custom token that is correctly named but whose source connection is broken will report 0 or na on every bar — which passes validation but produces wrong results. Always verify your custom tokens with the token diagnostics label. See Default Tokens for the full list of built-in tokens.

Diagnostic toggles

Three diagnostic overlays, all in the Inputs tab:

Toggle	What it shows	When to use it
Show schema summary table	Parsed counts of setups, entries, TPs, and SLs per direction	After pasting or editing YAML — confirms the engine parsed what you intended
Show expression value label	Every expression with its current value, evaluation status (EVAL/SKIP/EMPTY), and usage status	When debugging conditions that do not fire or fire unexpectedly
Show token diagnostics label	All registered custom tokens with their current values	When verifying that external indicators are feeding the correct data

These are your primary debugging tools. Get in the habit of enabling the schema summary after every YAML edit and the expression diagnostics whenever behavior surprises you.