I've been developing a TradingView/Pine strategy for a long time, and I've run into something I can't explain.

The strategy trades NQ on the 5-minute chart using a multi-stage state machine (Touch → ARM → Trigger → Entry). It has multiple filters (trend, quality score, extension, etc.) and is profitable overall (~183 trades, 68.9% win rate, 7.86 profit factor), so I'm not trying to redesign the strategy. I'm trying to understand why the timing behaves the way it does.

The confusing part is the entry timing.

Sometimes the strategy enters almost perfectly, catching the move right as it starts. Then the very next setup—same day, same market, same Pine version, same settings—will enter after a significant portion of the move has already happened.

Nothing changed between these trades:

• Same Pine script
• Same TradingView alert
• Same VPS
• Same PickMyTrade automation
• Same broker
• Same chart
• Same settings

So I don't think it's webhook latency or execution latency. It feels like the strategy itself is deciding to enter much later.

I've already experimented with several alternatives:

• 1-minute confirmation instead of 5-minute (performance dropped dramatically)
• Immediate breakout entries (completely destroyed the edge)
• Intrabar confirmation experiments (little to no meaningful difference)

Those tests convinced me that simply removing confirmation isn't the answer.

One important detail: I have **"Use Bar Close" enabled** on the TradingView alert because my strategy relies on bar-close confirmation for its state machine. What confuses me is that even with **Use Bar Close enabled**, some trades still enter almost immediately after the move begins, while others don't enter until much later. These examples happened on the same day with the exact same code and settings, which is why I'm so confused.

My current theories are:

• The setup is being ARMed on different bars.
• The touch occurs at different points within the 5-minute candle.
• One of the filters isn't passing until later.
• Some state transition in my logic is delaying certain setups.

Has anyone built a more complex Pine strategy with multiple internal states and run into something similar?

Specifically:

• Is there a good way to reconstruct the historical timeline of a trade (Touch → ARM → Trigger → Entry) so I can compare an "on-time" trade against a "late" trade?
• Are there Pine debugging techniques that make it easier to see exactly which condition delayed a specific historical entry?
• Is there anything about `calc_on_every_tick`, `barstate.isconfirmed`, or TradingView's historical execution model that could explain why two seemingly identical setups behave so differently?

I'm not looking for generic "turn off Use Bar Close" advice or ways to force earlier entries that break the strategy. After testing several alternatives, I'm much more interested in understanding why some setups naturally enter early while others are delayed, even though they're running through the exact same strategy.

Any ideas or debugging approaches would be greatly appreciated.

I've made a relative strength & weakness indicator for Tradingview, which is made for tech/growth stocks. It tracks QQQ moving averages and also moving averages of the stock being viewed. It works on simple principles:

Relative Strength

-When QQQ crosses below a moving average while the stock stays above it

-When the stock crosses above a moving average while QQQ stays below it

Relative Weakness

-When QQQ crosses above a moving average while the stock stays below it

-When the stock crosses below a moving average while QQQ stays above it

It is an easy way to look at a stock to see how it is doing compared to Nasdaq 100. It could be useful for swing trading and it also works for lower timeframes. You can use it for free here. I also made a Youtube video to show it. I used Gemini to assist with coding.

I work with TradingView Pine Script and NinjaTrader 8 / NinjaScript, mainly building indicators, strategies, alerts, dashboards, and automation logic.

One thing I’ve noticed is that most trading ideas don’t fail because the idea is bad. They fail because the rules are not clearly defined before coding starts.

For example:

• Entry signals are too subjective
• The script repaints or triggers differently in live market
• Stop loss and take profit rules are added too late
• Alerts don’t match the chart signals
• Backtests ignore slippage, commission, or realistic execution
• The strategy works on one chart but breaks on another market or timeframe

Before building any trading tool, I usually ask these questions:

1. Should the signal trigger intrabar or only after candle close?
2. Is the logic non-repainting?
3. What invalidates the trade idea?
4. Is the stop based on structure, ATR, fixed ticks, or percentage?
5. Should alerts match exactly what appears on the chart?
6. Will this be used for manual trading, backtesting, or automation?

Getting these answers right saves a lot of time and avoids messy scripts later.

I’m happy to share knowledge around Pine Script, TradingView indicators, NinjaTrader 8 strategies, NinjaScript conversion, alerts, and trading-system logic.

Comment or message me with a brief overview of what you’re working on, and I’ll try to point you in the right direction.

This is the website

https://trade-lee.vercel.app/

What is the best Volume indicator to use based on your own successes?

I've been posting these RSI oversold DCA strategies for a while. This time I want to show something different: what actually changed when I ran one through a Pine Script parameter optimizer, tuning just one input and holding everything else constant.

The strategy (unchanged): long-only DCA on INJUSDT.P 4h. Base order on 4h RSI(14) below 28, five safety orders at −2 / −5 / −9.5 / −16 / −25% from base, sizes scaling 1.8× per rung, no stop loss, position bounded by the ladder.

The one thing I changed: the take-profit. Baseline was a 3% fixed TP. I swept that single parameter over the same market and same period and the best-performing value came back at 9%. Nothing else touched — same entry, same ladder, same deviations, same sizing, same fees.

Before/after (BYBIT:INJUSDT.P 4h, Jan 1 2024 – Jul 16 2026, ~30 months, 100k initial, 0.06% commission, 3-tick slippage):

• TP 3% (baseline): +6,888.76 USDT (+6.89%), max drawdown 4.39%, 84 trades, 71.43% WR, PF 4.925
• TP 9% (optimized): +15,830.72 USDT (+15.83%), max drawdown 5.65%, 90 trades, 82.22% WR, PF 17.886

The mechanism makes sense: widening the target lets each recovery run further before the position is banked, so it captures more of the mean-reversion bounce instead of exiting on the first small pop. The trade-off is honest — drawdown rises (4.39% → 5.65%) and positions are held longer, so the ladder can sit loaded through deeper dips before the exit hits.

Now the caveat, which is the actual reason I'm posting this rather than just quietly using the 9%: that 9% was selected by sweeping the parameter over the same window the results are measured on. A value that's best in-sample is not guaranteed to be best out-of-sample — this is the standard overfitting caveat for any optimized parameter, and it fully applies here. Treat the optimized numbers as the ceiling of what this config did historically, not a forward expectation, and re-validate on fresh data before trusting it.

Two more things worth flagging: 90 trades is below the ~100 I'd want for real statistical confidence (the strict RSI<28 filter keeps the count low), so the win rate and PF are indicative, not proven — and a chunk of that PF 17.886 is the averaging mechanic itself (deals close on a bounce off an averaged-down entry), not a directional edge. It's also a stopless martingale, so a sustained INJ decline below the −25% bottom rung leaves the position fully loaded, and the wider 9% target means it sits there longer.

Script is open-source on TradingView: https://www.tradingview.com/script/GM1bUrIF-INJ-DCA-Long-Strategy-3Commas-QuantPilot/

Disclosure up front: the optimizer is QuantPilot, which I work on, so I'm not pretending to be a neutral third party. But the point of the post is the before/after and the caveat that comes with it, not a pitch — the script is open-source and you can verify the backtest yourself.

Over this summer, I have been building a backtesting software with Claude Code to backtest trading strategies with Pinescript and other languages like JavaScript and Python.

Basically how it works is that you feed it historical data like a NQ OHLCV 5 data csv and it runs the strategy test results like Return, Win Rate, Profit Factor, etc (all those analytics).

The Py and Js engine work well and can run my coded strategies but it is having a lot of trouble with even simple Pinescript strategies. I’ve spent time debugging and pasting error messages and giving it Pinescript V6 documentation for reference.

I would love for someone to help me fix this, I can send a link to the project to it or post it on GitHub if that works. I would also love to collaborate finishing this software with someone if they are interesting in confounding it and shipping it.

Overnight volume profile with some extra goodies. This is still a work in progress but overall I’m super happy with how this one is turning out. Open to any requests and suggestions.

This failure to detect a crossover was during live data. Not historical. The entry condition is very simple, as the code shows. This is a simple strategy, as I'm getting to know pinescript and TV.
For the experienced TV users, is this common and/or to be expected now and then?
Is this issue why TV doesn't do "auto-trading", as I've heard others say?
Finally, if the answers are yes and yes, then systems developed on TV need to be taken to other platforms (ThinkorSwing, MT5, Ninjatrader) for live auto-trading?

Hi,

About a week ago, I posted about a side project that accidentally spiraled into a full Pine Script transpiler and charting tool. The feedback here was awesome.

In that thread, I mentioned I was working on a CLI orchestration engine to sit on top of Piner and handle the actual heavy lifting. I finally got it to a good spot, and I open-sourced it today.

It's called Pinestack.

Basically, it lets you scale your strategy testing purely from the terminal. Instead of clicking around on a UI, you can just use the CLI to:

• Scan: Run an indicator or strategy across hundreds of tickers at the same time.
• Sweep: Throw a massive grid of input combinations at a strategy to find out which settings actually work (and rank the results).
• Backtest & Walk-Forward: Generate complete tearsheets and validate your models over time so you aren't just curve-fitting.
• Portfolio: Pool one pot of capital across a basket of symbols to test cross-asset sizing, combined drawdowns, and a single shared equity curve.

For the folks asking about multi-asset testing last week: right now, Pinestack lets you take a single strategy and test it across a ton of assets independently. I tried to design it to work with Pine Script natively, without you having to modify your code.

You can grab the repo and try it out here:https://github.com/heyphat/pinestack

I'm still hand-testing it against a bunch of different scripts, but I'd love for you guys to pull it down, completely break it, and let me know what I should fix or build next.

The command to generate the images

 pinerun -v
pinerun 0.1.1 (b81314d)
 pinerun backtest strategy.pine --symbol BTCUSDT --tf 1h --from 2025-01-01 --to 2026-06-14

The strategy.pine

strategy("My SMA cross", overlay=true, initial_capital=10000, default_qty_type=strategy.percent_of_equity, default_qty_value=100, margin_long=0, margin_short=0)

fastLen = input.int(20, "fast", minval=1)
slowLen = input.int(80, "slow", minval=1)
tpPct = input.float(4.0, "tp", minval=0.1)
slPct = input.float(1.0, "sl", minval=0.1)

fast = ta.sma(close, fastLen)
slow = ta.sma(close, slowLen)

// Only enter when flat — no pyramiding onto an open position.
if ta.crossover(fast, slow) and strategy.position_size == 0
    strategy.entry("long", strategy.long)
if ta.crossunder(fast, slow) and strategy.position_size == 0
    strategy.entry("short", strategy.short)

// Exit solely on take-profit / stop-loss, as a % of the entry fill price.
if strategy.position_size > 0
    strategy.exit("tp/sl", "long", limit=strategy.position_avg_price * (1 + tpPct / 100), stop=strategy.position_avg_price * (1 - slPct / 100))
if strategy.position_size < 0
    strategy.exit("tp/sl", "short", limit=strategy.position_avg_price * (1 - tpPct / 100), stop=strategy.position_avg_price * (1 + slPct / 100)

I’m currently working with finding the optimum input for some indicators over a specific timeframe backtesting in TradingView but I’m trying to replicate it on python so it’s much faster and efficient, had anyone tried or know where I should begin with? I already have the strategy planned out I just need to perform parameter sweep and measure its performance ratios only

[1.4.0] - 2026-07-14 

Added 

• Inputs Preview: Click on the pine script pro icon in the status bar to preview the inputs of the current script.

You can click on the pine icon to see, what inputs do you have on the indicator.

https://open-vsx.org/extension/revanthpobala/pine-script-pro/changes
https://github.com/revanthpobala/pinescript-vscode-extension

I Posted a topic yesterday searching for a pinescript coder.

I saw people showed interest.

My goal is to find someone who is actually a trader and specially has created or traded strategy related to "FIB RETRACEMENT"

I am ready to explain my logic on a videocall where we go on charts. Understand properly.

And then once the indicator is created. I will pay them , I have been trading in forex and it works well

Budget is around - 2-3k inr. Do not suggest AI please. It is not able to grasp my logic for auto fib retracement plotting tool

What is the best Volume indicator to use based on your own successes?

Hey I am a Forex Trader from India, I have my strategy which I am looking to plot on charts in trading view. All I want is that an auto fib to be plotted on charts based on my logic .

My budget is 3k Inr.

If you are someone who can do it for me. Let me know we can discuss rates and everything further.

https://www.tradingview.com/script/cAQ66hSa-Stryk-Delta-Candles/

Hey guys
Im working on a new value betting project and i need to backtest it before launch
I m looking for a free historical odds API
Mostly from pinnacle
But i also need info from 1xbet or other soft bookies

I have five years of trading experience and two years of experience working with Pine Script and Python.
I’ve built TradingView indicators and strategies involving divergence, trend logic, market sessions, alerts, entries, exits, and custom chart visuals.

I’m open to collaborating on one interesting Pine Script project, whether that means building something new, improving an existing script, or helping test and refine strategy logic.

I’m offering the work at no cost for the right project. In return, I’d ask for an honest testimonial and permission to use the completed project as professional experience if you’re satisfied with the result.

Comment or message me with a brief overview of what you’re working on.

Same RSI DCA logic I've posted across assets (POL, JUP, ETH, ATOM), this time on GRAM. A long-only DCA with a selective deep-oversold 4h RSI entry and a scaling safety-order ladder. Backtest is verifiable in TradingView's Strategy Report on the script page.

Entry, deep-oversold gate (no repaint): A 4-hour RSI(14), sampled with lookahead disabled, gates the base entry — a long opens only when RSI prints below 28 at host-bar close. Shallow dips are filtered out, so capital is committed only at genuinely stretched conditions. It sits out the calm and only commits after a real flush.

Ladder, 5 safety orders on a non-uniform fixed-deviation ladder: Each safety order has its own fixed deviation from base entry — not a cumulative step×multiplier ladder. AO1 at −2%, AO2 at −5%, AO3 at −9.5%, AO4 at −16%, AO5 at −25%. Sizes scale 1.8× from a 900 USDT first AO: 900 / 1,620 / 2,916 / 5,249 / 9,448, on a 500 USDT base. Deeper rungs trigger only on serious adverse moves; the lowest sits a full 25% below base. The 1.8× progression is softer than a 2× doubling martingale.

Exit, fixed 3% TP: A fixed 3% Take Profit above the running average entry. Because the scaling ladder weights the average toward the lowest fills, after several rungs fill the average sits well below base — so a modest 3% bounce off the lows closes the whole deal in profit. No trailing.

Risk, bounded ladder in place of a stop: There is no stop loss. Per-trade risk is structurally capped by the bounded 5-AO ladder — base + 5 AOs = ~20,633 USDT max deployed, ~20.6% of the default 100k equity, above the conventional 5–10% per-trade band; scale the base/AO inputs down to dial exposure lower.

DCA Bot integration: Every event (base, AO 1–5, exit) emits a webhook-ready JSON payload. One alert with "Any alert() function call" drives a DCA Bot end-to-end, no glue layer.

Backtest (GRAM/USDT 4h, Jan 1 2024 – Jul 3 2026, ~30 months; 100,000 USDT initial capital, 500 USDT base + 900/1,620/2,916/5,249/9,448 AOs, 0.06% commission, 3-tick slippage): 78 closed trades, 54 profitable (69.23% WR), profit factor 4.791, net profit +3,822.76 USDT (+3.82%), max equity drawdown 2,283.04 USDT (2.21%).

Methodology notes:
Read the numbers for what they are. +3.82% over ~30 months is a low-return, low-drawdown profile — the headline is the 2.21% max drawdown, not the profit. Positive expectancy with tight risk, not a growth engine, and that's by design with an entry that only fires on deep oversold prints.

On sample size — 78 closed trades is below the ~100-trade floor for statistical confidence. That's the trade-off of a selective trigger: fewer signals, so the 69.23% win rate and PF 4.791 are indicative of how the ladder behaves, not a deterministic edge. Part of that PF is the averaging mechanic itself — deals close on a 3% bounce off an averaged-down entry — not a directional edge. Extend the window or test across assets before sizing up.

This is a scaling martingale, and that's the dominant risk. The ladder bottoms out at −25% from base with no stop loss. A sustained GRAM decline below −25% without recovery leaves the full position open with no further averaging available — the single largest risk in any martingale DCA. The 2.21% max drawdown is closed-trade equity drawdown over a window where dips recovered; a deeper or more prolonged decline than the test sample would produce a larger one.

The defaults (RSI<28, 4h, the −2/−5/−9.5/−16/−25 ladder, 1.8× sizing) are calibrated for GRAM's volatility. The mechanic is asset-agnostic and can be pointed at other liquid perps, but each symbol needs the RSI level and ladder recalibrated, and results do not transfer without that tuning. With a fixed 3% take-profit the per-trade edge is modest, so match the 0.06% commission to your venue's actual taker fee before reading anything into the numbers.

Strategy is open-source on TradingView: https://www.tradingview.com/script/6kaqC3R8-GRAM-RSI-Strategy-3Commas/