Pine Script 2025 Symbol Data Updates

Pine Script's 2025 update cycle delivered several improvements to how scripts access symbol information, handle non-standard chart data, and share reusable values across scripts¹. These changes may not generate the same excitement as footprint data or dynamic loop boundaries, but they solve real problems that futures traders, alternative chart users, and library authors encounter regularly.

This article covers four symbol and data updates from the first half of 2025: the syminfo.current_contract variable for continuous futures, the PercentageLTP box sizing style for non-standard charts, the time_close improvements for tick and price-based charts, and the new ability for libraries to export constant values. Each of these updates fills a gap that previously required workarounds or was simply impossible to address within Pine Script.

July 2025: syminfo.current_contract

The July 2025 update introduced syminfo.current_contract, a new built-in variable that returns the ticker identifier of the underlying front-month contract when the chart displays a continuous futures symbol¹. If the current symbol is not a continuous futures contract, the variable returns na³.

The Continuous Futures Problem

Continuous futures charts on TradingView display a synthetic price series that stitches together consecutive futures contracts as they roll from one expiration to the next. The chart symbol for a continuous contract uses a special ticker format, such as "ES1!" for the front-month E-mini S&P 500 contract. This continuous ticker is useful for long-term analysis and backtesting, but it does not correspond to an actual tradeable contract.

When a developer builds a strategy on a continuous futures chart and wants to route orders to a broker, the strategy needs to know the specific contract that is currently active. Before July 2025, Pine Script had no built-in way to retrieve this information. Developers had to resort to external lookups, manual configuration inputs, or workarounds involving contract month calculations to determine which specific contract (such as "ESH2025" or "ESM2025") the continuous chart was currently referencing.

How syminfo.current_contract Works

The variable has a straightforward type and behavior:

syminfo.current_contract → simple string

When the chart displays a continuous futures symbol, syminfo.current_contract returns a string containing the ticker identifier of the current underlying contract³. For example, on an "ES1!" chart during March 2025, the variable might return "ESH2025" (the March 2025 E-mini S&P 500 contract). After the roll to the June contract, the same chart would return "ESM2025".

When the chart displays a non-continuous symbol, whether that is a stock, forex pair, crypto, or even a specific individual futures contract, the variable returns na³.

Example Usage

//@version=6
indicator("Current Futures Contract", overlay = true)

// Display the current underlying contract on the chart
if barstate.islast
    string contractInfo = na(syminfo.current_contract)
      ? "Not a continuous contract"
      : "Current contract: " + syminfo.current_contract
    label.new(bar_index, high, contractInfo,
      style = label.style_label_down, color = color.blue)

This simple script displays a label on the last bar showing either the current contract ticker or a message indicating that the chart is not displaying a continuous futures symbol.

Practical Applications

The primary use case for syminfo.current_contract is automated futures trading. When a strategy running on a continuous chart generates an entry or exit signal, the webhook alert can include the actual contract ticker that the broker needs for order execution. This eliminates a mapping step that previously had to happen outside of Pine Script.

• Include the contract ticker in alert messages for webhook-based order routing to platforms like TradersPost
• Display the current contract on the chart as a reference for manual traders who want to confirm which contract they should be trading
• Build contract roll detection logic by comparing the current value to a stored previous value
• Log contract transitions using Pine Logs to track when rolls occur relative to your strategy's positions

For developers building continuous futures contract identification systems, this variable replaces what used to be a multi-step workaround with a single built-in reference.

Related Variables

The syminfo namespace contains several other variables that complement syminfo.current_contract for futures analysis:

• syminfo.ticker returns the symbol name without the exchange prefix, such as "ES1!" for a continuous chart³
• syminfo.tickerid returns the full ticker identifier including the exchange, such as "CME_MINI:ES1!"³
• syminfo.description returns the human-readable symbol description³
• syminfo.type returns the instrument type, which will be "futures" for both continuous and individual contracts³

Together, these variables give scripts comprehensive information about the symbol context, with syminfo.current_contract providing the specific piece that continuous futures analysis was previously missing.

April 2025: PercentageLTP Box Sizing

The April 2025 update added a new box sizing method for non-standard chart types¹. The style parameter of the ticker.renko(), ticker.pointfigure(), and ticker.kagi() functions now accepts the string argument "PercentageLTP", which calculates box sizes as a percentage of the last trading price³.

Non-Standard Chart Types in Pine Script

Pine Script provides functions to create ticker identifiers for requesting data from non-standard chart types⁴. These functions return synthetic ticker IDs that can be passed to request.security() to retrieve Renko, Point & Figure, or Kagi values while running on a standard candlestick chart:

• ticker.renko() creates a ticker for Renko bar data, which plots fixed-size price bricks without regard to time
• ticker.pointfigure() creates a ticker for Point & Figure data, which tracks alternating columns of X's (rising prices) and O's (falling prices)
• ticker.kagi() creates a ticker for Kagi chart data, which reverses direction only when price moves by a specified amount

Each of these functions requires a style parameter that determines how the box or reversal size is calculated. Before April 2025, the available styles included fixed-value approaches like "ATR" (Average True Range) and absolute point values. These styles define box sizes in absolute terms, which creates a problem when the same script is applied to instruments at very different price levels.

How PercentageLTP Works

The "PercentageLTP" style calculates the box size as a user-defined percentage of the last trading price. This means the box size automatically scales with the instrument's price level. A 1% setting on a $50 stock produces a $0.50 box, while the same 1% setting on a $500 stock produces a $5.00 box.

//@version=6
indicator("Renko with PercentageLTP", overlay = true)

// Create a Renko ticker with 0.5% box size based on last trading price
string renkoTicker = ticker.renko(syminfo.tickerid, "PercentageLTP", 0.5)

// Request the Renko close price
float renkoClose = request.security(renkoTicker, timeframe.period, close)

plot(renkoClose, "Renko Close", color = color.blue, linewidth = 2)

The third parameter (0.5 in this example) specifies the percentage value. This means each Renko brick represents a 0.5% price movement relative to the last trading price.

Benefits of Percentage-Based Sizing

Percentage-based box sizing solves the portability problem that fixed-size approaches create:

• A single script works correctly across instruments at different price levels without parameter adjustment
• The same settings remain appropriate as an instrument's price changes significantly over time, such as a stock that doubles from $50 to $100
• Multi-symbol analysis scripts can apply consistent relative sensitivity across their entire universe
• Backtesting over long historical periods produces more consistent behavior as the box size scales with the changing price level

For Point & Figure and Kagi charts, the same percentage-based logic applies. Point & Figure box sizes and Kagi reversal amounts become relative rather than absolute, keeping the chart's sensitivity proportional to the instrument's current price.

When to Use PercentageLTP

The PercentageLTP style is best suited for scripts that operate across multiple instruments or over long time periods where price levels change substantially. If your script analyzes a single instrument over a short period with a stable price, fixed-size approaches like ATR may still be more intuitive. The choice depends on whether you need the box size to adapt automatically to changing price levels.

May 2025: time_close Improvements

The May 2025 update fixed a data availability gap in the time_close variable that affected scripts running on tick-based and price-based chart types¹.

The Problem with time_close on Non-Standard Charts

The time_close variable returns the closing timestamp of the current bar as a UNIX timestamp in milliseconds³. On standard time-based charts (1-minute, hourly, daily, etc.), each bar has a predetermined closing time based on the timeframe, so time_close always provides a valid value.

On tick charts and price-based charts such as Renko, line break, Kagi, point & figure, and range charts, bars do not close at predetermined times. A Renko brick closes when price moves by the box size, which could take seconds or hours. Because the closing time is unpredictable while a bar is still forming, time_close returns na for the latest realtime bar on these chart types. That behavior is expected and still applies.

However, before the May 2025 fix, there was an additional problem: time_close also returned na for recently elapsed realtime bars on these chart types. Once a Renko brick closed and a new one began forming, the closed brick should have had a valid closing timestamp. But the variable was not updating correctly, leaving a gap in the data.

What Changed

After the May 2025 update, time_close correctly reports the closing timestamp for all elapsed (confirmed) bars on tick and price-based charts¹. The variable still returns na for the single latest realtime bar whose closing time is not yet determined, which is the expected behavior. But all previous bars now have valid timestamps as soon as they are confirmed.

The fix also applies to the time_close() function, which works similarly but accepts additional parameters for specifying a timeframe and session³. Both the variable and the function now behave consistently on non-standard chart types.

Accessing Previous Bar Timestamps

One practical pattern that benefits from this fix is using the history-referencing operator to access the previous bar's closing time:

//@version=6
indicator("Previous Bar Close Time")

// On tick/price-based charts, time_close[1] now correctly returns
// the closing timestamp of the previous (confirmed) bar
plot(time_close[1], "Previous bar's closing timestamp")

Before the fix, time_close[1] would show na on all realtime bars of tick charts and price-based charts. After the fix, it correctly returns the closing timestamp of the most recently confirmed bar.

Impact on Trading Strategies

This fix matters for strategies and indicators that use timestamps for trade management logic on non-standard charts. Common scenarios include:

• Session filtering on Renko charts, where the strategy needs to know whether a bar closed within or outside regular trading hours
• Time-based exit conditions that close positions after a certain duration, requiring accurate bar timestamps
• Logging and analysis scripts that record when specific price levels were reached on tick or range charts
• Multi-timeframe strategies on non-standard charts that compare bar close times across different contexts

For automated trading systems that send alerts based on Renko or range chart signals, accurate timestamps ensure that the alert message includes correct timing information. Platforms like TradersPost that receive these alerts can use the timestamp to log exactly when the signal condition was confirmed.

June 2025: Library Constant Exports

The June 2025 update expanded what Pine Script libraries can share with importing scripts by allowing the export of user-defined constant variables¹. Before this update, libraries could only export functions, user-defined types (UDTs), and enums⁴. Sharing a constant value like a mathematical ratio or a configuration threshold required wrapping it in a getter function, which added unnecessary overhead.

How Constant Exports Work

Library authors can now use the export keyword together with the const qualifier on variable declarations. The exported constants must be one of the following types: int, float, bool, color, or string³. These types align with the "const" qualifier in Pine Script's type system, meaning the values must be determinable at compile time⁴.

//@version=6
// @description Shared mathematical and configuration constants
library("TradingConstants")

export const float GOLDEN_RATIO = 1.618033988749895
export const float SILVER_RATIO = 1.0 + math.sqrt(2)
export const int   MAX_LOOKBACK = 500
export const color BULL_COLOR   = #00FF00ff
export const color BEAR_COLOR   = #FF0000ff
export const string DEFAULT_TF  = "D"

An importing script can then use these constants directly:

//@version=6
indicator("Using Library Constants", overlay = true)
import userName/TradingConstants/1 as tc

// Use exported constants directly
float level = close * tc.GOLDEN_RATIO
color barColor = close > open ? tc.BULL_COLOR : tc.BEAR_COLOR

plot(level, "Golden Ratio Level", color = barColor)

Restrictions on Exported Constants

Exported constants have the same restrictions as any "const"-qualified variable in Pine Script. The value must be known at compile time, which means it can be a literal value, a built-in constant, or an expression involving only other constants and supported compile-time functions. The following would not work because it depends on runtime data:

// This would NOT compile - close is a runtime value, not a constant
// export const float THRESHOLD = close * 0.01  // Error

The supported types for exported constants are limited to int, float, bool, color, and string³. You cannot export constant arrays, matrices, or UDT instances, as these types do not support the "const" qualifier⁴.

Practical Applications

Constant exports are useful for several categories of shared code:

• Mathematical constants like ratios, pi multiples, or statistical thresholds shared across multiple indicators
• Color schemes that maintain visual consistency across a suite of related scripts
• Configuration defaults such as standard lookback periods, session definitions, or timeframe strings
• String constants for standardized alert message formats or label text templates

For teams of developers or for individual developers who maintain multiple related scripts, constant exports reduce duplication and ensure consistency. When a value needs to change, updating it in the library automatically propagates the change to all importing scripts.

Why This Matters for the Pine Script Ecosystem

Before constant exports, sharing a simple value like a Fibonacci ratio between scripts required creating a function:

// Old approach: function wrapper for a constant
export goldenRatio() => 1.618033988749895

This worked, but it was verbose and obscured the intent. The function call tc.goldenRatio() looks like it performs a computation, when really it just returns a fixed value. With constant exports, tc.GOLDEN_RATIO clearly communicates that the value is a constant, not a calculated result. This makes code more readable and aligns with naming conventions in other programming languages.

For a deeper look at library constant exports including examples of exporting color palettes and configuration objects, see our dedicated guide on Pine Script library constant exports.

Summary of Symbol and Data Changes

The four updates covered in this article address distinct areas of Pine Script's data handling:

• syminfo.current_contract (July 2025): Returns the actual contract ticker for continuous futures symbols, enabling accurate order routing in automated futures trading
• PercentageLTP box sizing (April 2025): Adds percentage-based box sizes to ticker.renko(), ticker.pointfigure(), and ticker.kagi() for proportional sensitivity across instruments
• time_close improvements (May 2025): Fixes closing timestamp availability on tick and price-based charts so elapsed bars report accurate close times
• Library constant exports (June 2025): Allows libraries to export constant values directly, replacing the need for getter function workarounds

Each of these changes removes a limitation or workaround that developers previously had to manage manually. For automated trading workflows, the syminfo.current_contract variable and the time_close fix are particularly valuable because they provide data that strategies need for accurate signal generation and order routing.

Connecting Pine Script to Automated Execution

With these symbol and data improvements, Pine Script strategies have access to more precise information about what they are trading and when conditions are confirmed. The natural next step is connecting those strategies to automated execution.

TradersPost bridges the gap between TradingView alerts and broker order execution⁵. When your Pine Script strategy identifies a trading signal on a continuous futures chart, it can include the syminfo.current_contract value in the alert message so the execution platform knows exactly which contract to trade. Combined with accurate time_close data for timing and expanded string limits for detailed alert payloads, these 2025 updates make Pine Script strategy automation more reliable than ever.

References

¹ Pine Script Release Notes
² Pine Script v5 to v6 Migration Guide
³ Pine Script v6 Language Reference
⁴ Pine Script User Manual
⁵ TradersPost — Automated Trading Platform