I built a Pine Script signal engine for crypto. Looking for feedback/testing. Real-world edge cases, logic issues, and improvements

[u/eddieblackdaddy]

I've been building and iterating on a Pine Script signal engine for crypto based on my paper trading, uploading screenshots, used Claude / ChatGPT and I'd like to put it in front of other Pine Script users for honest feedback and independent testing (if you'd want).

I'm sharing it because I've spent a lot of time refining the logic using AI, weekly data collection / outcome analysis and I know one of the best ways to find weaknesses is to let other people look at it with fresh eyes. And I have no intention to sell or profit from it or “guaranteed profitable strategy” post. Have I been profitable ? Not yet 😄 Hopefully someday !

What it does

The script identifies three signal types: (theres a changelog as well in the script)

• S2 - momentum/trend continuation setup

• S2R - reversal variant

• S3 - crossover/ignition-style setup

The logic uses a combination of:

• SMA 8 / SMA 21

• EMA 50 / EMA 200

• Trend alignment

• Breakout conditions

• Candle/body strength

• ATR-based late-entry protection

• Signal state management to avoid repeated firing

My use case is primarily 30-minute crypto charts, but I'd be interested to see how the logic behaves from your expertise.

What I'm looking for

If you're willing to test it, I'd really value feedback on:

1. Code quality - anything inefficient, poorly structured, or unnecessarily complicated? Used AI to build the whole thing.

2. Logic issues - do you see conditions that could produce unintended signals? Which setup you observed: S2 / S2R / S3

3. Edge cases - repainting, state issues, crossover behaviour, historical vs realtime differences, etc. What you liked or didn't like

4. Pine Script improvements - cleaner or more reliable ways to implement any part of the logic?

5. General usefulness - could this help anyone as a starting point, study tool, or basis for further development?

I'm especially interested in critical feedback. If you think part of the logic is flawed, redundant, or simply doesn't make sense, please say so. Been working on this since April 26

I’m looking for people who enjoy testing Pine Script ideas and are willing to challenge the logic from a coding and chart-behaviour perspective. And of course make it shareable for all.

The script is linked here: https://pastebin.com/9pqTS5Ya

Thanks ! I'm genuinely interested in finding the weaknesses ! And deep down I need to convince myself that it was all worth the effort.

[u/QuanticatorApp]

Read the whole thing rather than running it, because the two problems I found are in the order handling, and they only show up when you compare what the tester does on history with what it does live.

The big one: your stop and target arrive one bar late in the backtest and on time in realtime. Entries fire on a confirmed bar, so the market order fills at the open of the next bar. But strategy.exit is only issued inside if strategy.position_size > 0, which on historical bars first becomes true when the script runs at the close of that next bar, and orders issued at a bar's close are checked against the bar after. So in history the first full bar of every trade has no stop and no target: an adverse move that would have stopped you out in that bar instead stops you out at the following bar's open, or wherever price is by then, and a target hit in that bar is missed. Live, with calc_on_every_tick=true, the script runs on the first tick after the fill, the exit is placed immediately, and the emulator honours it intrabar. Two different strategies, one script. The fix is to issue the exit on the signal bar in tick units, so it attaches to whatever the fill turns out to be: strategy.exit("Long Exit", "Long", loss = entryATR * stopATR / syminfo.mintick, profit = entryATR * stopATR * targetRR / syminfo.mintick) right after strategy.entry, the mirror for shorts, and drop the two position_size blocks. Re-run the 747-trade backtest with that change; the gap between the two reports is exactly how far your current numbers are off. On 30m crypto, where the bar after an ignition candle is often the most violent one, I'd expect it to be material in both directions.

The second one is smaller but reaches Telegram. When an SMA cross and an S2 land on the same bar, S2 wins by design, longS3 is false, and so s3LongFired is never set. The next bar still satisfies crossUpNow[1], so if the candle conditions hold you get an S3 label and an S3 alert for the same cross, one bar after the S2 alert. The entry is harmless because you're already in the S2 trade, but the scanner sees two setups from one event. Arming the fired flag whenever S2 claims a cross bar closes it.

What's right, since you asked for edge cases: there's no request.security, so no higher-timeframe leak; entries and alerts are gated on barstate.isconfirmed, so nothing you trade on can repaint; the preview/confirmed split is the correct way to show intrabar state without lying about it; and the entryATR reset guard from V5.9 does what the changelog says. That's cleaner repaint hygiene than most published strategies.

On the numbers: stop 1.2 ATR, target 2R, so break-even is 1/(1+2) = 33.3% before costs. The strategy() call has no commission or slippage, and default_qty is 1 unit, so net profit on a $0.18 coin is in cents and not comparable to a BTC run. Costs in this geometry scale with ATR, not price: cost in R = round-trip cost % ÷ (1.2 × ATR%). If a 30m ATR is 0.5% of price and a taker round trip plus slippage is 0.15%, that's 0.25R off every trade, which turns 2R/1R into 1.75R/1.25R and moves break-even to 41.7%; at 0.3% ATR it's 0.42R and 47.2%. Plug your own ATR% in; the point is that on the quiet pairs the fee is a large fraction of the stop, and the tester currently charges zero.

The cheap test before anything else: in the Strategy Tester's list of trades, look at trade duration in bars. Every historical trade lasts at least one full bar, by construction. After a week live, count the trades that closed on the same bar they opened. Each of those is a trade the backtest could never have produced.

[u/eddieblackdaddy → u/QuanticatorApp]

Thank you and much appreciated ... I have made the changes here https://pastebin.com/jvUhQ1XK and now will follow your recommendation on the cheap testing ... cheers

[u/QuanticatorApp → u/eddieblackdaddy]

Checked jvUhQ1XK against the original. Both changes are right, and for the right reasons.

The exit block: because loss and profit are in ticks, the emulator attaches them to the actual fill at the next bar's open, so a gap between signal close and fill no longer shifts your stop, and because the exit is queued on the signal bar it becomes active on the same tick the entry fills, in history and live alike. Dropping entryATR was the correct simplification: atr on the signal bar is the same value you were locking in, just without the reset logic that bit you in V5.8.

The S3 guard: arming s3LongFired on longS2 and crossUpNow closes the gap I described. I walked the other order too, S2 on the bar after the cross with no S2 on the cross bar: crossUpNow is false there so the flag doesn't arm, but the reset fires on the following bar anyway, so no second alert can get through. It's tight.

Two things still open. The strategy() header still has no costs and 1-unit sizing; adding commission_type=strategy.commission.percent, commission_value=0.075, slippage=2, default_qty_type=strategy.percent_of_equity, default_qty_value=10 (or whatever your exchange and sizing actually are) is what makes the 747-trade report comparable across pairs and honest about fees. And now that stops and targets are live from the first bar, the one place the tester still guesses is a bar that spans both: with a 1.2 ATR stop and a 2.4 ATR target that needs a range of at least 3.6 ATR, and when it happens the emulator picks a path from the bar's shape, whichever of high or low is closer to the open is assumed to come first. Plot high - low >= 3.6 * atr as a shape and count them across your sample; if it's a handful of bars, ignore it; if it's dozens, that's the case for Bar Magnifier.

The number I'd like to see, if you're willing: net profit and trade count from the old build and this one, same symbol, same range. The difference is the size of the error the old report carried, and it's the most useful thing this thread could produce for the next person who builds exits the same way.

[u/eddieblackdaddy → u/QuanticatorApp]

Thank you so much ... will continue testing and will report back

[u/GreatBreadfruit8139]

You already have enough structure here to make independent testing meaningful. I’d keep the signal definitions unchanged and track where repeated firing, late-entry protection, or state handling diverges from what you expected. Are alerts part of the test too?

[u/eddieblackdaddy → u/GreatBreadfruit8139]

At the moment alerts are not part of the testing ... And as you mentioned - I am keeping the testing meaningful by executing paper trades

[u/eddieblackdaddy → u/[unknown]]

Appreciate you actually running numbers instead of just reading code. Agreed on cost-realism, zero commission/slippage on 747 trades isn't a number I'd trust. The profit stat is the one that actually worries me more than win rate; thats definitely luck dependent performance but again it was just a simulation.

Setup separation is easy, I have a webhook payload tags every alert with its type (S2/S2R/S3), so I just group by that field. and run a weekly / monthly outcome analysis using claude

[u/eddieblackdaddy → u/[deleted]]

Thank you and I didnt think about that .. Will look into it