TradingView indicator guides

WaveTrend with Crosses: Marker Logic and Threshold Limits

A WaveTrend cross marks WT1 moving from one side of its four-bar average, WT2, to the other. This Pineify example draws a circle at WT2 on that bar. It does not filter crosses by the four horizontal levels, wait for bar close, detect divergence or place orders.

Inspect the Pine Script

Separate the public reference from this implementation

LazyBear’s May 27, 2014 WaveTrend publication describes a port of a TS/MT indicator. The February 20, 2016 WaveTrend with Crosses publication by lonestar108 describes added cross visualization and bar highlights. LazyBear in that title identifies the underlying oscillator, not the author of the later publication.

The retained Pineify helper below uses HLC3, a 10-period channel EMA and 21-period smoothing. Its standalone plots include two lines, their difference area, reference levels and cross circles. Unlike the community description, this copy has no barcolor call. Compare actual source rather than assuming every similarly named script has the same display or timing.

Follow the normalization and signal average

AP = (high + low + close) / 3. ESA = EMA(AP, N), D = EMA(abs(AP − ESA), N), CI = (AP − ESA) / (0.015 × D), WT1 = EMA(CI, M), and WT2 = SMA(WT1, 4). The plotted blue area is WT1 − WT2. Neither this difference nor WT1 is a percentage return, a probability or a measurement of trading volume.

For an assumed updated AP of 103, ESA of 100 and D of 2, CI is 100. With M = 21 and previous WT1 = 45, the next WT1 is 45 + (100 − 45) / 11 = 50. If the preceding four WT1 values were 55, 52, 48 and 45, WT2 changes from 50 to 48.75. WT1 has crossed upward at a positive oscillator value; that does not make it an oversold cross.

The factor 0.015 does not impose fixed bounds of −100 and +100. Thresholds are reference values, not caps. The retained helper divides by D without an explicit zero-deviation guard. A constant initial price series can therefore have unavailable normalization; do not interpret a missing circle as evidence of a neutral market.

Read exactly what a circle returns

The helper computes ta.cross(WT1, WT2). An upward cross needs WT1 > WT2 now and WT1 ≤ WT2 previously; a downward cross reverses those inequalities. Equality on the current bar is not itself a cross. When a cross exists, crossPoint is the current WT2 value; otherwise it is na. The black border and colored circle share that same coordinate, not the interpolated intersection between bars.

isBullishCross is true only for an upward cross. False does not mean a downward cross: it is also false on every bar with no cross. To identify a bearish event from these outputs, require an available crossPoint as well as isBullishCross being false. Merely being above WT2 is a continuing state, not a new upward cross on every bar.

The difference crossing zero and WT1 crossing WT2 are the same mathematical event. Using both does not provide independent confirmation. No oversold or overbought condition appears in the cross expression, so circles can appear anywhere on the oscillator scale.

A cross need not match the current direction of WT1

Use hypothetical WT1 histories to test the marker logic directly. With preceding values 0, 12, 12 and 9, previous WT2 is 8.25. If the next WT1 rises to 10, current WT2 becomes (12 + 12 + 9 + 10) / 4 = 10.75. This is a downward cross even though WT1 rose from 9 to 10: the low value leaving the signal window matters.

Conversely, preceding WT1 values 20, 0, 0 and 4 have WT2 = 6. A new WT1 of 3 lowers the current signal average to 1.75, creating an upward cross while WT1 falls. These are synthetic classifier examples, not historical market observations or claims about how often such sequences occur.

The circle alone therefore does not prove acceleration, buyers taking control or a likely price reversal. An expanding difference area also depends on both series. To test a trading rule, separately define price context, confirmation time, entry, exit, size and costs.

Threshold arguments do not control these markers

The helper signature accepts six arguments, but only channelLength and averageLength enter its calculation. obLevel1, obLevel2, osLevel1 and osLevel2 are unused inside the helper. The standalone hline calls separately hardcode +60, +53, −60 and −53. Changing only those four arguments in the function call changes neither circles nor horizontal lines.

Moving a displayed level requires editing its hline value. Filtering events requires an additional Boolean rule, such as an upward cross AND current WT1 below −53; moving a line alone does not add that filter. Decide whether the threshold applies to WT1, WT2, the current bar or the prior bar. For example −62 to −52 can meet a prior-bar −53 test while failing the current-bar test.

The fixed pasted script has no input functions. The separate Visual Editor configuration exposes fields and drawing controls, but that does not add editable length inputs, bar colors or alerts to this standalone example. Product access and available workflows should be checked in the application rather than inferred from a public code listing.

Check an open bar before treating a marker as confirmed

There is no barstate.isconfirmed gate. Suppose prior closed WT1 = −56 and WT2 = −55. With preceding WT1 values −54, −55 and −56, an early current WT1 of −53 gives WT2 = −54.5 and an upward circle. If the same bar closes with WT1 = −57, WT2 is −55.5 and the circle disappears. Those values follow the four-bar average; they are not a measured trading outcome.

The lines and circles can update during the open bar under Pine’s realtime execution and rollback. A close-confirmed adaptation needs an explicit gate and alert conditions. This example has neither alerts nor a higher-timeframe request, pivot detector, strategy orders or a backtest.

See the WaveTrend oscillator guide for a separate adaptation with a zero-deviation guard and confirmed cross alerts. Those additions change implementation behavior; they should not be silently attributed to the retained source here. No best timeframe, comparative win rate or fixed signal-frequency reduction is established by either formula.

Pine Script v6: implementation and limits

This source retains the fixed 10/21 calculation and its original display. Its four threshold arguments are unused, while hline values are literal constants. It has no explicit zero-deviation guard or close-confirmation gate. The preview is not evidence of performance.

Pine Script v6
// This source code is subject to the terms of the Mozilla Public License 2.0 at https://mozilla.org/MPL/2.0/
// © Pineify

//@version=6
indicator(title="WaveTrend with Crosses", overlay=false, max_labels_count=500)

p_ta_wave_trend_cross(simple int channelLength, simple int averageLength, simple float obLevel1, simple float obLevel2, simple float osLevel1, simple float osLevel2) =>
    ap = hlc3
    esa = ta.ema(ap, channelLength)
    d = ta.ema(math.abs(ap - esa), channelLength)
    ci = (ap - esa) / (0.015 * d)
    tci = ta.ema(ci, averageLength)

    wt1 = tci
    wt2 = ta.sma(wt1, 4)
    wtDiff = wt1 - wt2

    isCross = ta.cross(wt1, wt2)
    crossPoint = isCross ? wt2 : na
    isBullishCross = isCross and (wt1 > wt2)

    [wt1, wt2, wtDiff, crossPoint, isBullishCross]

[wt1, wt2, wtDiff, crossPoint, isBullishCross] = p_ta_wave_trend_cross(10, 21, 60, 53, -60, -53)

hline(0, "Zero", color=color.rgb(120, 123, 134, 0), linewidth=1)
hline(60, "OB Level 1", color=color.rgb(239, 83, 80, 0), linewidth=1)
hline(53, "OB Level 2", color=color.rgb(239, 83, 80, 0), linewidth=1)
hline(-60, "OS Level 1", color=color.rgb(38, 166, 154, 0), linewidth=1)
hline(-53, "OS Level 2", color=color.rgb(38, 166, 154, 0), linewidth=1)
plot(wt1, "WT1", color.rgb(0, 230, 118, 0), linewidth=2)
plot(wt2, "WT2", color.rgb(255, 82, 82, 0), linewidth=2)
plot(wtDiff, "Diff", color.rgb(33, 150, 243, 80), style=plot.style_area)
plot(crossPoint, "Cross Border", color.black, style=plot.style_circles, linewidth=3)
plot(crossPoint, "Cross", isBullishCross ? color.rgb(0, 230, 118, 0) : color.rgb(255, 82, 82, 0), style=plot.style_circles, linewidth=2)
Existing indicator chart preview
Existing visual preview. Verify exact values against the source; the image is not a performance result.

Specify a checkable adaptation in Pineify

Ask the Pine Script AI Coding Agent to expose the two lengths as inputs, connect threshold inputs to reference lines, and define a separate optional filter for confirmed crosses. Specify which line and which bar the filter uses. Preserve applicable source notices, validate the final code and compare numerical outputs before creating alerts or testing order rules.

Open Pine Script AI Coding Agent

Educational indicator analysis. No measured trading performance is established here. Syntax validation does not prove formula equivalence, execution assumptions or profitability.

Implementation questions

The linked 2016 publication is by lonestar108 and builds on LazyBear’s 2014 WaveTrend oscillator. The Pineify source shown here is a specific implementation whose plots and timing should be checked separately.

No. They are unused in this helper. Horizontal lines are separate hardcoded plot calls, and crosses are detected at any oscillator level.

No. It is false on a downward cross and on bars with no cross. Check that crossPoint is available before treating it as a bearish cross event.

Yes. WT2 is a rolling four-bar average. Removing an older low value can make WT2 rise above WT1 even while WT1 itself rises.

No. This copy has no close gate. Its circles can appear and disappear on the current bar as price and the two lines change.

It contains no alert conditions or strategy orders. Those require explicit additions and separate checks for timing, costs and execution.