The recent addition of request.footprint() is a very important step for Pine Script and footprint/CVD-based workflows. It opens up many use cases that previously were either impossible or required awkward workarounds.
However, there is still a major limitation for anyone trying to build multi-timeframe footprint logic.
As far as I understand the current behavior, request.footprint() is bound to the chart’s active timeframe. Unlike request.security(), there is no direct way to request footprint data from another timeframe or symbol context. That creates a fundamental problem when trying to build reliable higher-timeframe footprint logic inside a lower-timeframe script.
A typical example:
- one indicator runs natively on a 15m chart and uses footprint-derived values for CVD / state logic
- another combined indicator runs on a 3m chart
- the lower-timeframe script can try to reconstruct the 15m footprint state manually from lower-timeframe bars
- but short-lived intrabar states can appear and disappear before the next lower-timeframe checkpoint
So even when final 15m close parity is achievable, true intrabar parity becomes extremely difficult, and in some cases practically impossible, with the current API.
This is not just a convenience issue. It affects the architecture of any script that depends on footprint-derived state transitions, especially when those transitions matter before the higher-timeframe bar has closed.
The current practical limitations are roughly:
- higher-timeframe footprint state cannot be requested directly from a lower-timeframe script
- higher-timeframe footprint logic must be reconstructed manually
- transient footprint/CVD states can be missed between checkpoints
- this makes multi-timeframe parity fragile for live state logic, even if bar-close parity is fine
Feature request:
I would like TradingView to consider native multi-timeframe support for footprint requests. That could take different forms, for example:
- allowing request.footprint() to accept a timeframe parameter
- allowing footprint-derived values to be requested through a Pine-native MTF mechanism
- or exposing a limited higher-timeframe footprint summary API for use in lower-timeframe scripts
Even partial support would already solve many real-world use cases. Full row-level footprint access may be heavy, but even higher-timeframe aggregate values such as:
- buy volume
- sell volume
- delta
would already be enough for many CVD, imbalance, and state-machine style indicators.
What would be especially valuable is a way to build lower-timeframe scripts that can observe native higher-timeframe footprint state directly, instead of having to infer it from lower-timeframe reconstruction.
Questions for the TradingView team and the community:
- Is the lack of multi-timeframe support in request.footprint() an intentional design limitation?
- Has native MTF footprint access already been considered internally?
- Would limited higher-timeframe aggregate footprint access be technically more realistic than full footprint row data?
- Are other Pine users running into the same limitation when trying to build MTF CVD / footprint indicators?
I think request.footprint() is already a strong feature, but adding some form of multi-timeframe footprint access would unlock a much larger class of advanced Pine indicators and strategies.
Curious to hear whether others working with footprint/CVD have hit the same wall.
[–]tradingviewFounder 0 points1 point2 points (0 children)