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_NOW > 50000`, the e...
Written By Axiom Admin
Last updated 2 days ago
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_NOW > 50000, the engine looks up PRICE_NOW in the map, gets Pine's current close value, 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 diagnostics 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.
Most tables below show both the longhand token and its shorthand alias. The longhand name is the canonical name used in examples and diagnostics because it is easier to read. The alias is for experienced users who want shorter expressions. Both names point at the same runtime value.
Price tokens
These update every bar from the chart's current symbol and timeframe.
When to use which price
PRICE_NOW and PRICE_CLOSE are the same underlying value. The difference is intent. Use PRICE_NOW when the rule reads like "the price available right now." Use PRICE_CLOSE when the rule reads like "the bar's close." On historical bars, both equal the historical bar close. On the realtime bar, both reflect Pine's current developing close value.
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_NOW[1] returns that same previous close through the readability token. 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 TIME_NOW warning
TIME_NOW 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
TIME_NOWwill produce different results each time TradingView recalculates the strategy.Results that depend on
TIME_NOWare 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,
TIME_NOW(or a bar-state token) is the most likely cause.
Use TIME_OPEN or the calendar tokens (BAR_HOUR, BAR_DAY_OF_WEEK, etc.) for time-based logic that needs to be stable across recalculations. Reserve TIME_NOW 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_AVERAGE_PRICE - (50 * MIN_TICK) 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 TIMEFRAME_IS_DAILY 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
BAR_STATE_IS_REAL_TIME 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.
BAR_STATE_IS_CONFIRMED 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 BAR_STATE_IS_CONFIRMED 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_IS_MARKET 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_EQUITYin an allocation expression to scale position size dynamically — smaller after drawdowns, larger after growth.Drawdown gating: Use
STRATEGY_MAX_DRAWDOWN_PERCENT > 15as 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_LOSING_TRADES - STRATEGY_WINNING_TRADES < 5to slow down when the strategy is underperforming.Position awareness:
STRATEGY_OPEN_TRADES > 0tells you whether the strategy has open exposure. Useful in gate conditions for entries that should only fire when flat.
These are useful, 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 > 5will 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_AMOUNT > 0and priced atPOSITION_AVERAGE_PRICEcreates a move-to-breakeven stop after the trade goes green.Flat detection:
POSITION_ACTIVE == FALSEin 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_AMOUNT 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_CONFIRMING, and TREND_FILTER_ACTIVE. It also produces shorthand aliases: TREND_FILTERINACT, TREND_FILTERCONF, and TREND_FILTERACT.
Setup lifecycle is:
ExampleINACTIVE -> CONFIRMING -> ACTIVE
If no confirmation count is configured, the setup can move from INACTIVE directly to ACTIVE when its activation expression passes. If confirmation is configured, CONFIRMING means the activation condition is holding, but the required bars or ticks have not completed yet.
Example use: An entry gate condition of TREND_FILTER_ACTIVE && VOLATILITY_SETUP_ACTIVE requires two independent setups to both be active 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, take profit, or stop loss (e.g., an entry called BREAKOUT_LONG), the engine registers:
Trade-unit lifecycle is:
ExampleINACTIVE -> CONFIRMING -> WORKING -> ACTIVE
Not every unit visits every state. Market orders usually skip WORKING. Units with no confirmation count skip CONFIRMING. A limit entry can go from INACTIVE to WORKING, then ACTIVE after it fills.
Example use: A second entry gated on BREAKOUT_LONG_ACTIVE will only evaluate after the first entry has fired in the current lifecycle. This is how you build add-on entries that pyramid only after the initial entry has actually done its job.
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 diagnostics 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.