Default Token Reference

Use this page when the real question is about vocabulary.

This is the page for questions like:

• what can the strategy already read without any extra setup?
• what do the built-in values actually mean?
• what live state values are created from my own setup and package names?
• how do custom tokens behave in practice?
• which token family should I reach for first?

That last question matters more than it sounds.

Most token mistakes are not spelling mistakes. Most token mistakes are meaning mistakes. The token exists, but the reader has granted it more authority than it earned.

This page is here to slow that down in a helpful way.

What A Token Is In This Builder

A token is a named value the strategy makes available to your logic.

The logic layer does not read the chart in a vague, direct way. It reads the token surface the builder provides.

That means token choice is not a minor detail. It shapes:

• what your logic can see
• how easy the workflow is to explain
• how easy it is to verify the trade path on the chart
• how much hidden assumption you are importing into the strategy

If you treat tokens casually, the workflow usually becomes harder to trust.

The Three Token Families

The strategy gives you three different families of tokens.

Token family — Where it comes from — What it is best for — Main caution

built-in tokens — published directly by the strategy — market context, time context, strategy context, and position context — readers sometimes assume a familiar name means more than it does

derived state tokens — generated from your setup and package names — checking what the builder is already doing internally in plain workflow terms — naming patterns matter, and sanitization changes the final visible names

custom tokens — registered from your own chart-linked inputs — extending the builder when built-ins are not enough — the source may be real, but the meaning can still be weak or poorly typed

Knowing which family you are using is the first step toward using it well.

The Best Starting Vocabulary

If you are still learning the strategy, do not try to hold the whole token catalog in your head.

Start with a small working set:

Token — Why it is a strong first token

PRICE_CLOSE — easiest price anchor to recognize directly on the chart

PRICE_HLC3 — useful when you want a slightly smoother reference than the close alone

BARSTATE_ISCONFIRMED — teaches the difference between a forming bar and a confirmed bar

POSITION_ACTIVE — helps you separate "idea exists" from "trade exists"

POSITION_AVG_PRICE — useful for management rules that react to the live trade context

SESSION_ISMARKET — helpful when your workflow should care about session context

Those six can teach a large amount of the builder without introducing much ambiguity.

A Good Way To Choose Tokens

When you are deciding which token to use, ask these questions in order:

1. is there already a built-in token for this?
2. if not, does a derived state token express it more cleanly?
3. only if both answers are no, do I really need a custom token?

That order matters because built-in and derived tokens are usually easier to verify than custom ones. They also reduce the number of moving pieces you need to trust.

Built-In Token Groups

The built-in token surface covers several different kinds of context.

Price, volume, time, and symbol context

These are the values most traders reach for first because they are closest to what the chart already shows.

Token — Meaning

PRICE_CLOSE — current bar close also "price now"

PRICE_HIGH — current bar high

PRICE_LOW — current bar low

PRICE_HL2 — current high-low midpoint

PRICE_HLC3 — current high-low-close average

PRICE_HLCC4 — current high-low-close-close average

PRICE_OHLC4 — current open-high-low-close average

VOLUME — current bar volume

BAR_INDEX — running bar count position on the chart

BAR_TIME — current bar open time

TIME_CLOSE — current bar close time

TIMENOW — current time value exposed to the strategy

BAR_YEAR — current bar year

BAR_MONTH — current bar month

BAR_WEEKOFYEAR — current bar week-of-year

BAR_DAYOFMONTH — current bar day of month

BAR_DAYOFWEEK — current bar day of week

BAR_HOUR — current bar hour

BAR_MINUTE — current bar minute

BAR_SECOND — current bar second

MINTICK — minimum tradable tick size for the symbol

SYM_POINTVALUE — symbol point value

SYM_PRICESCALE — symbol price scale

TF_MULTIPLIER — chart timeframe multiplier

How to use this group well

This group is strongest when you want the workflow to respond to what is visibly present on the chart.

Good examples of clear use:

• price relative to a simple reference
• time-of-day or session-aware logic
• minimum tick alignment
• symbol-specific spacing or value logic

This group becomes weaker when you start asking it to solve interpretive problems that belong elsewhere, such as broad trade state or management scope.

Built-In Boolean State Tokens

These tell the strategy whether certain bar, session, or timeframe conditions are true right now.

Token — Meaning

BARSTATE_ISCONFIRMED — the current bar is confirmed rather than still forming

BARSTATE_ISNEW — the strategy is seeing a new bar

BARSTATE_ISLAST — the current bar is the last visible bar

BARSTATE_ISREALTIME — the current bar is in real-time context

SESSION_ISMARKET — the symbol is in regular market session

SESSION_ISPREMARKET — the symbol is in premarket session

SESSION_ISPOSTMARKET — the symbol is in postmarket session

TF_ISINTRADAY — the chart is using an intraday timeframe

TF_ISSECONDS — the chart is using a seconds-based timeframe

TF_ISTICKS — the chart is using a ticks-based timeframe

TF_ISDAILY — the chart is using a daily timeframe

TF_ISWEEKLY — the chart is using a weekly timeframe

TF_ISMONTHLY — the chart is using a monthly timeframe

Why this group matters so much

Boolean state tokens are often where a workflow becomes more disciplined.

They help answer questions like:

• should this rule wait for a confirmed bar?
• should this workflow only operate in certain session conditions?
• does this logic only make sense on intraday charts?

These are not "nice to have" distinctions. They often separate stable behavior from confused behavior.

Strategy Metric Tokens

These tokens tell your logic what the broader strategy is already experiencing.

That can be powerful, but it also deserves restraint. A strategy that constantly reacts to its own performance state can become clever in ways that are hard to trust.

Equity, profit, and drawdown context

Token — Meaning

STRATEGY_EQUITY — current equity value

STRATEGY_INITIAL_CAPITAL — initial capital used by the strategy

STRATEGY_NETPROFIT — current net profit amount

STRATEGY_NETPROFIT_PERCENT — current net profit percentage

STRATEGY_OPENPROFIT — current open profit amount

STRATEGY_OPENPROFIT_PERCENT — current open profit percentage

STRATEGY_GROSSPROFIT — current gross profit amount

STRATEGY_GROSSPROFIT_PERCENT — current gross profit percentage

STRATEGY_GROSSLOSS — current gross loss amount

STRATEGY_GROSSLOSS_PERCENT — current gross loss percentage

STRATEGY_MAX_RUNUP — current maximum runup amount

STRATEGY_MAX_RUNUP_PERCENT — current maximum runup percentage

STRATEGY_MAX_DRAWDOWN — current maximum drawdown amount

STRATEGY_MAX_DRAWDOWN_PERCENT — current maximum drawdown percentage

STRATEGY_MARGIN_LIQUIDATION_PRICE — current margin liquidation price when relevant

Trade averages and counts

Token — Meaning

STRATEGY_AVG_TRADE — average trade result

STRATEGY_AVG_TRADE_PERCENT — average trade result in percentage terms

STRATEGY_AVG_WINNING_TRADE — average winning trade result

STRATEGY_AVG_WINNING_TRADE_PERCENT — average winning trade percentage

STRATEGY_AVG_LOSING_TRADE — average losing trade result

STRATEGY_AVG_LOSING_TRADE_PERCENT — average losing trade percentage

STRATEGY_WINTRADES — count of winning trades

STRATEGY_LOSSTRADES — count of losing trades

STRATEGY_EVENTRADES — count of even trades

STRATEGY_CLOSEDTRADES — count of closed trades

STRATEGY_OPENTRADES — count of open trades

Position-size and holding context from the strategy surface

Token — Meaning

STRATEGY_POSITION_SIZE — current position size

STRATEGY_POSITION_AVG_PRICE — current average position price

STRATEGY_OPENTRADES_CAPITAL_HELD — capital held by open trades

STRATEGY_MAX_CONTRACTS_HELD_ALL — maximum contracts held across all directions

STRATEGY_MAX_CONTRACTS_HELD_LONG — maximum contracts held on the long side

STRATEGY_MAX_CONTRACTS_HELD_SHORT — maximum contracts held on the short side

STRATEGY_LAST_DIRECTION — prior direction proxy exposed by the strategy

When to use strategy metrics carefully

These tokens are best when the broader state genuinely matters to the workflow.

They are less useful when they are being used to decorate a method that already has enough moving pieces.

A good guiding question is:

Would this workflow become clearer or merely more adaptive if I used strategy-state tokens here?

If the answer is only "more adaptive," pause. Adaptation is not automatically an improvement.

Aggregated Position State Tokens

These tokens come from the strategy's own position-state tracking layer. They are especially useful because they tell your logic what the builder considers true about the current position path, not only what raw chart values say.

Position booleans

POSITION_READY — the aggregated position model is initialized and ready

POSITION_ACTIVE — the strategy currently considers a position active

Position metrics

POSITION_DIRECTION — current direction proxy: long, short, or flat state represented numerically (1,0,-1)

POSITION_ACTIVE_TRADES — active trade count in the aggregated position model

POSITION_QUEUED_TRADES — queued trade count in the aggregated position model

POSITION_FILLED_QTY — filled quantity tracked by the aggregated model

POSITION_AVG_PRICE — aggregated fill price

POSITION_PROFIT_AMT — current position profit amount

POSITION_PROFIT_PERCENT — current position profit percentage

POSITION_MAX_RUNUP — current position maximum runup amount

POSITION_MAX_DRAWDOWN — current position maximum drawdown amount

POSITION_MAX_RUNUP_PERCENT — current position maximum runup percentage

POSITION_MAX_DRAWDOWN_PERCENT — current position maximum drawdown percentage

POSITION_COMMISSION_PAID — commission paid by the aggregated model

POSITION_CAPITAL_HELD — capital held by the aggregated model

Why this group is so practical

This group is often the bridge between a market idea and a management idea.

It helps you answer questions like:

• should this management rule only exist once a trade is active?
• should this logic react to the average position price rather than raw market price alone?
• should the workflow respond to current trade profit or drawdown state?

For many readers, these are among the most useful tokens in the whole strategy because they connect the authored workflow to the live trade context directly.

Derived Runtime State Tokens

The strategy also publishes tokens that come from your own package names.

This is one of the most useful parts of the token surface because it lets later logic ask what the builder is already doing without rebuilding that logic from scratch.

How naming works

Your authored names are turned into an uppercase underscore-style base.

In plain terms:

• letters become uppercase
• numbers are preserved
• separators are normalized into underscores
• extra underscores are collapsed

That means a name like "Trend Pullback #1" becomes the base form "TREND_PULLBACK_1."

Setup-state token pattern

Every setup creates four derived state tokens:

Pattern — What it means

base plus _INACTIVE — the setup is inactive

base plus _ACTIVE — the setup is live in some usable sense

base plus _CONFIRMING — the setup is in its confirmation phase

base plus _CONFIRMED — the setup has fully confirmed

For example: TREND_PULLBACK_1_ACTIVE or _INACTIVE

These tokens are extremely useful because they let later workflow pieces react to setup state explicitly instead of trying to reconstruct setup logic somewhere else.

Package-state token pattern

Entries, take profits, and stop losses also create derived state tokens.

Pattern — What it means

base plus _INACTVE — the package is inactive

base plus _WAITING — the package is waiting rather than fully active

base plus _ACTIVE — the package is active

For example: BREAKOUT_ENTRY_ACTIVE or _WAITING

These state tokens are especially helpful when you want later logic to respond to workflow state rather than to market data alone.

Why derived state tokens are worth learning early

They often let you write cleaner logic with less repetition. They are particularly useful in "gate_conditions"

Instead of rebuilding the whole reason a setup or package became valid, you can react to the state the builder already maintains.

That usually makes the workflow:

• easier to read
• easier to verify
• easier to troubleshoot later

Custom Token Contract

Custom tokens are where you extend the strategy's vocabulary with your own chart-linked sources.

This is powerful, but it deserves discipline.

What the custom-token surface gives you

Contract element — Current behavior

slot count — up to 30 custom token rows

naming surface — the strategy exposes the token name exactly as you enter it

source surface — each row reads one chart-linked source

type choices — number or true-or-false

logic lookup — your expressions must reference the name exactly as registered

Number versus true-or-false

This is the most important custom-token distinction on the page.

Type choice — What the strategy does with it — Best use

number — preserves the raw numeric value from the chosen source — when magnitude, distance, or continuous variation matters

true-or-false — treats the source as true only when it is present and above zero — when the source genuinely should behave as a simple threshold state

That true-or-false rule is precise. It is not interpretive.

It does not mean:

• bullish versus bearish
• above average versus below average
• favorable versus unfavorable

It means a much simpler thing:

the source is present and greater than zero.

That can be exactly right. It can also be badly wrong if the source carried richer meaning than a simple above-zero test.

Usually indicators that expose alert conditions are best used for true-or-false tokens.

A practical way to choose the type

Use number when:

• the source has meaningful scale
• the source can be positive, negative, or neutral in ways that matter
• you are not yet sure what threshold logic you want

Use true-or-false when:

• the source is already naturally binary in meaning (alert conditions e.g Is Bullish, Is Bearish)
• above-zero genuinely means the state is active
• you want a clear yes-or-no surface and you have verified that the threshold interpretation is appropriate

Good custom-token habits

• choose names that are specific and easy to recognize later
• avoid names that look too similar to built-in tokens
• verify the token on the chart before letting it drive important logic
• keep the number of custom tokens small until the base workflow is understandable
• prefer explicit meaning over clever naming

Common custom-token mistakes

Mistake — Why it hurts

naming drift between the token row and the expression — the logic cannot read what you think it is reading

using true-or-false for a nuanced oscillator or source — the token silently throws away useful information

trusting the source without visual verification — the workflow inherits assumptions you never checked

adding many custom tokens before the built-in path is stable — basic confusion gets buried under extra vocabulary

The Fastest Way To Verify Token Meaning

When a token matters to the workflow, verify it in layers:

1. confirm the token exists
2. confirm you understand what family it belongs to
3. confirm its value or state on the chart
4. confirm that the meaning you are giving it matches what it actually represents

That final step is the one people skip most often.

A token can be wired perfectly and still be conceptually wrong for the job you gave it.

A Good Token Discipline For New Workflows

If you want a calm progression, build token complexity in this order:

1. built-in market and bar-state tokens
2. built-in position-state tokens
3. derived setup and package-state tokens
4. only then custom tokens if the workflow still needs them

That order reduces the number of invisible assumptions you have to carry at once.

Where To Go Next

read Expression Language Reference when the token exists but the logic using it still is not valid

read YAML Section Reference when the token question is really about where that logic belongs

read Worked YAML Examples when you want to see tokens used inside full strategy patterns

read Troubleshooting when you already have a concrete token or state symptom and want the shortest likely cause