Default Tokens

Default Tokens

Every expression you write in the YAML references named values called tokens. The engine refreshes the entire token map on every bar before evaluating any of your expressions. When you write PRICE_CLOSE > 50000, the engine looks up PRICE_CLOSE in the map, gets the current bar's close price, and compares it to the literal 50000.

This page documents every token the engine makes available by default — before you connect a single custom indicator. These are the building blocks your expressions have access to out of the box. Custom tokens (your external indicators) are covered at the end.

When examples use names like EMA_200, RSI_K, or ATR_14, assume those are custom tokens you connected from indicators on your chart. They are not built in.

Token names are case-sensitive. PRICE_CLOSE works. price_close does not. Price_Close does not. Get the casing wrong and the engine will raise an "Unknown identifier/token" error during first-bar validation — the strategy will not run. The error table will show exactly which token name was not found. If the strategy is failing to load, check your token names first.

For the full expression syntax — operators, functions, and how to combine tokens into conditions — see Expression Reference.

Price tokens

These update every bar from the chart's current symbol and timeframe.

When to use which price

Most conditions use PRICE_CLOSE because that is the price the bar settles at. Use PRICE_HIGH and PRICE_LOW when you care about the extremes — breakouts, range boundaries, stop placement. The averaged variants (HL2, HLC3, HLCC4, OHLC4) are useful when you want a single number that smooths out the bar's range. They are not better or worse than PRICE_CLOSE — they are different questions about the same bar.

History references

Any numeric token supports a history suffix. PRICE_CLOSE[1] returns the previous bar's close. PRICE_CLOSE[10] returns the close from 10 bars ago. The syntax is TOKEN_NAME[N] where N is a non-negative integer. No spaces inside the brackets. See Expression Reference for full details.

Bar and time tokens

The TIMENOW warning

TIMENOW returns the actual current wall-clock time when the script evaluates. On historical bars during a backtest, this is the time of the recalculation — not the time the bar originally occurred. This means:

• A condition using TIMENOW will produce different results each time TradingView recalculates the strategy.

• Results that depend on TIMENOW are not stable across sessions. If you close your browser and reopen the chart, the results may change.

• If your strategy's results changed overnight without any YAML changes, TIMENOW (or a bar-state token) is the most likely cause.

Use BAR_TIME or the calendar tokens (BAR_HOUR, BAR_DAYOFWEEK, etc.) for time-based logic that needs to be stable across recalculations. Reserve TIMENOW for real-time-only logic where you genuinely need the current wall-clock time.

Symbol information tokens

These are constants for a given symbol — they do not change bar to bar. They are most useful inside price expressions for exits: calculating a stop loss as POSITION_AVG_PRICE - (50 * MINTICK) means "50 ticks below my average entry price," which adapts automatically to whatever symbol you are charting.

Timeframe tokens

Timeframe tokens are useful as gate conditions when you build a strategy that should only evaluate on certain chart resolutions. A strategy tuned for daily charts can use TF_ISDAILY as a setup gate to prevent accidental evaluation on an intraday chart where the assumptions would be wrong.

Bar state tokens

The historical recalculation trap

BARSTATE_ISREALTIME is always false during a backtest and always false on historical bars during a recalculation. If you use it in a gate or trigger condition, that condition will never fire in the backtest. Your results will show zero trades, and everything will look like the condition is simply too strict — when in reality it is a bar-state token that cannot be true in the test environment.

BARSTATE_ISCONFIRMED is the most practically useful bar-state token. If you want a condition to only trigger on the bar's close (not on intra-bar ticks during real-time evaluation), gating on BARSTATE_ISCONFIRMED achieves that. Note: in backtesting, all bars are confirmed by definition, so this gate has no filtering effect on historical data. It matters only for real-time behavior.

Session tokens

Session tokens are most relevant for equities and futures where pre-market and post-market behavior differs from the regular session. For 24/7 crypto markets, SESSION_ISMARKET is typically always true. Check your exchange's session definition on TradingView if session gating does not behave as expected.

Strategy statistics tokens

These report the strategy tester's cumulative performance metrics. They update as trades are processed.

How strategy tokens enable adaptive logic

Strategy statistics tokens let your rules respond to what the strategy is doing, not just what the market is doing. Examples:

• Equity-based position scaling: Use STRATEGY_EQUITY in an allocation expression to scale position size dynamically — smaller after drawdowns, larger after growth.

• Drawdown gating: Use STRATEGY_MAX_DRAWDOWN_PERCENT > 15 as a setup gate condition to pause new entries after a significant drawdown, even before the risk circuit breaker threshold is reached.

• Win/loss filtering: After a losing streak, you might gate entries on STRATEGY_LOSSTRADES - STRATEGY_WINTRADES < 5 to slow down when the strategy is underperforming.

• Position awareness: STRATEGY_OPENTRADES > 0 tells you whether the strategy has open exposure. Useful in gate conditions for entries that should only fire when flat.

These are powerful, but they come with a warning: building conditions that reference strategy statistics creates feedback loops. A condition that pauses trading after drawdown will produce a different equity curve than the same strategy without the pause — and that different equity curve changes when the pause triggers, which changes the drawdown, which changes when the pause triggers. Test carefully and watch for recursive effects.

Position state tokens

These describe the current aggregated position across all setups and entries.

What position tokens are good for

Position tokens let your exits and entries respond to how the current trade is performing:

• Trailing behavior: A take profit gated on POSITION_PROFIT_PERCENT > 5 will not trigger until the position has moved at least 5% in your favor. Combine with a price expression to set the actual exit level.

• Breakeven stops: An exit triggered when POSITION_PROFIT_AMT > 0 and priced at POSITION_AVG_PRICE creates a move-to-breakeven stop after the trade goes green.

• Flat detection: POSITION_ACTIVE == FALSE in a gate condition prevents entries from evaluating when you already have exposure. Useful for single-trade strategies.

One important qualifier: POSITION_MAX_RUNUP* and POSITION_MAX_DRAWDOWN* are not per-trade excursion counters in this build. The strategy currently populates them from TradingView's strategy-level strategy.max_* series. If you need live open-position behavior, use POSITION_PROFIT_AMT or POSITION_PROFIT_PERCENT instead.

Dynamic state tokens

When you define named setups, entries, and exits in your YAML, the engine automatically creates boolean state tokens for each one. These tokens let expressions in one part of your strategy check the state of another part.

Setup state tokens

For every named setup (e.g., a setup called TREND_FILTER), the engine registers:

So a setup called TREND_FILTER produces TREND_FILTER_INACTIVE, TREND_FILTER_ACTIVE, TREND_FILTER_CONFIRMING, and TREND_FILTER_CONFIRMED.

Example use: An entry gate condition of TREND_FILTER_CONFIRMED && VOLATILITY_SETUP_CONFIRMED requires two independent setups to both be confirmed before the entry can fire. This is how you build composite regime filters without cramming everything into a single setup's activation expression.

Entry and exit state tokens

For every named entry or exit (e.g., an entry called BREAKOUT_LONG), the engine registers:

Example use: A second entry gated on BREAKOUT_LONG_ACTIVE will only evaluate when the first entry has already filled and has an open trade. This is how you build add-on entries that pyramid into an existing position only after the initial entry is confirmed.

Naming requirements

The state token name is derived from the name you give the setup, entry, or exit in your YAML. The engine converts it to an uppercase, underscore-separated form for use in expressions. Keep your names simple and token-friendly — alphanumeric characters and underscores. Avoid spaces and special characters in names.

Custom tokens

Custom tokens are the bridge between external indicators on your chart and the expression language. The strategy provides 30 slots, each with three fields: name, type, and source. See Settings for the configuration details.

Once a custom token is registered, it is indistinguishable from a built-in token inside an expression. MY_EMA > PRICE_CLOSE works exactly the same way as STRATEGY_EQUITY > 100000 — the engine looks up the name, gets the value, applies the operator.

What custom tokens make possible

Any indicator output on your TradingView chart can become a token. Moving averages, RSI, Bollinger Bands, volume profiles, custom scripts — if it produces a plot on the chart, you can wire it into the expression language.

This is the mechanism that makes the strategy builder extensible without needing to build indicators into the engine. The engine does not calculate EMAs or RSIs. It does not need to. You add the indicator you trust to your chart, connect its output as a custom token, and reference it in your expressions. The indicator does the calculation. The strategy builder does the logic.

What happens if a token name is wrong

If you reference a token name in an expression that does not exist — because of a typo, because you forgot to register it, or because the name does not match — the engine raises an "Unknown identifier/token" error during first-bar validation. The strategy will not run, and the error table will identify the unrecognized name.

This applies to both built-in tokens and custom tokens. A mistyped custom token name like ema_50 instead of EMA_50 is caught and reported.

After connecting custom tokens, verify that they are reporting sensible values using the token diagnostics label (Show token value label in the Inputs tab). A token that exists but reads 0 on every bar means the source connection is broken — the name is correct but the data is not flowing.

Quick reference — all default tokens

Numeric tokens (Number type)

Boolean tokens (True/False type)