MTF Stochastic Confluence [FibonacciFlux] — Indicator by FibonacciFlux — TradingView

WHAT IT COMPUTES

Stochastic %K is computed on 15m, 1H and 4H bars, each inside its own timeframe, and pulled onto the chart. Their weighted mean becomes the white composite line; the weighted spread around it becomes a coherence term. Two scores are then built, one for each direction:

score = 100 x position x (0.30 + 0.25 coherence + 0.30 turn + 0.15 cross)

where position is how deep the three legs sit inside the extreme (1.0 at or beyond the oversold line, falling linearly to 0 across the soft band above it), turn is how fast they are coming back out, and cross is how many have %K above %D. A trigger needs three things at once: all three legs to have visited the same extreme within the last sixteen bars, at least two to be turning, and the score to clear its threshold.

THE TRIGGER ALMOST NEVER FIRES, AND NOT BECAUSE THE MARKET IS QUIET

Over 5,982 scored bars of 15m data from 2026-06-25 to 2026-08-26, at the default threshold of 70, this fires 2 bull and 4 bear signals on BINANCE:BTCUSDT, 0 bull and 2 bear on ETHUSDT, 1 bull and 2 bear on SOLUSDT. Six signals in two months on the busiest of the three, and ETHUSDT produces no bullish signal at all.

The reason is in the formula. The bracket is bounded above by 1.0, so a score of 70 needs position at or above 0.70 even if coherence, turn and cross are all perfect. In practice the bracket never gets near 1 on the bars where it would matter: its median is 0.63 across all bars, but on bars deep enough in the extreme to matter (position at or above 0.85) the median falls to 0.58 and the maximum falls from 0.98 to between 0.72 and 0.77.

That is not bad luck, it is the design. Position and the bracket are negatively correlated – -0.35 on BTCUSDT, -0.38 on ETHUSDT, -0.37 on SOLUSDT – because they ask for opposite things. Position is high only while price is still deep inside the extreme; turn and cross are high only once a leg has started climbing back out, which raises %K and destroys position. The source comment calls the position term “a hard gate through multiplication” so that alignment in the middle of the range cannot generate a reversal score. It does that. It also multiplies away the bars it was built to select.

The scale of the loss: if the bracket were 1, BTCUSDT would have 1,060 bars at or above 70. With the real bracket it has 8, and after the arming and turning gates and the one-shot latch, six signals.

The clearest way to see it is the slider itself. The highest score this formula produced anywhere in the sample – three instruments, both data modes, roughly 36,000 bars – is 74.46. The threshold input runs from 40 to 95 in steps of 1, so 21 of its 56 positions cannot ever fire, whatever the market does. The top 38% of the control is dead travel.

Lowering the threshold to 50 gives 10 bull and 21 bear signals on BTCUSDT over the same window, 5 and 17 on ETHUSDT, 8 and 21 on SOLUSDT. Nothing in this publication validates that setting – it is stated so the shape of the knob is visible, not recommended.

ONE ADVERTISED FILTER IS INERT AT THE DEFAULTS

“Require at least two timeframes turning” removes exactly zero signals at the default threshold, on all three instruments: 6/6 on BTCUSDT counting both directions, 2/2 on ETHUSDT, 3/3 on SOLUSDT. It only starts to bite lower down – at a threshold of 60 it removes 2, 4 and 9 respectively. At the shipped defaults the score gate has already removed everything the turn gate would have.

THE DEFAULT USED TO BE THE REPAINTING MODE

The previous version shipped with the HTF data mode set to “Developing HTF”, which reads the 1H and 4H bars while they are still forming. What that costs, measured by replaying every 15m bar as if it were the live bar and comparing against what the same bar shows once its higher-timeframe bar has closed, on BTCUSDT over 5,983 bars:

The 1H %K settles a median of 1.13 points away from what was displayed, p90 5.35, maximum 21.18. The 4H %K a median of 1.41, p90 5.79, maximum 27.37. More to the point for this script, the sign of the per-timeframe turn – one of the three gates the trigger depends on – flips after the fact on 10.2% of bars for the 1H leg and 12.7% for the 4H, and the %K/%D cross flips on 7.7% and 8.1%. ETHUSDT and SOLUSDT give the same figures within a tenth of a point.

The default is now “Confirmed only”. The developing mode is still there, and its tooltip now says the word repaints.

One surprise came out of checking this, and it is worth stating because the setting’s name misleads. On historical bars, switching between the two modes does not change the 1H or 4H legs at all – they are bit-identical across every one of 6,000 bars on all three instruments, because request.security resolves both to the last closed higher-timeframe bar. What the setting actually changes is the 15m leg, which is the chart’s own timeframe: Confirmed reads the previous chart bar and Developing the current one, and they differ on essentially every bar, by up to 33 points. So the input labelled “HTF data mode” is, in history, a 15m setting. The repaint measured above is a separate thing: it is what the chart showed live, not what this toggle does to the past.

WHAT WAS TESTED INSTEAD, AND WHAT IT SAYS

Six events cannot be tested. What can be tested are the states this script draws often enough to have a sample: both strict three-timeframe extremes, both armed windows, both score bands, the composite extremes and high coherence. Testing all eleven at horizons of 4, 16 and 96 bars, in both signed and absolute return, counted as episodes rather than overlapping bars, against 500 shared circular shifts of the forward-return series:

BTCUSDT gives a largest standardised effect of 3.56 across 66 tests, against a family whose own median maximum on a shifted copy is 2.37; family-wise p = 0.120. SOLUSDT gives 3.00 against 2.33, p = 0.202. ETHUSDT gives 6.14 against 2.11, p = 0.008 – the only cell in the batch that clears its own family-wise correction.

That ETHUSDT result is worth naming precisely, because it is about the size of moves and not their direction. Bars entering a bear-score-above-50 episode are followed by larger absolute four-bar returns: 0.712% against a 0.328% baseline, 2.17 times, over 60 episodes, p = 0.0005 at 2,000 shifts, and 0.607% after dropping the single largest event. The direction of that effect replicates on the other two instruments but the significance does not: BTCUSDT gives 1.278 times at p = 0.060 over 70 episodes and SOLUSDT 1.354 times at p = 0.053 over 84. The mirror state – bull score above 50 – shows nothing anywhere: 0.72, 1.07 and 1.07 times.

So the honest reading is: a high bear score marks bars that are about to move more, on one instrument convincingly and on two others suggestively, and it says nothing about which way. Directionally it points, if anything, the wrong way: the mean signed one-hour return after a bear-score-above-50 episode is +0.038%, +0.109% and +0.153% on the three instruments, all positive, against baselines of +0.017%, +0.028% and +0.024%.

WHAT THAT WINDOW COULD HAVE DETECTED

62 days of 15m bars hold 1,494 non-overlapping one-hour windows, 372 four-hour windows and 61 daily ones. For a state occupying a quarter of them, the smallest mean difference detectable at 80% power is 0.065% at one hour, 0.255% at four hours and 1.603% at one day. The one-hour and four-hour tests above are therefore real tests. The daily horizon is not: nothing short of an enormous daily edge could show up in 61 windows, so a null result there means very little.

WHAT CHANGED IN THIS VERSION

An entire “Forward outcome audit” section was dead code. A settings toggle promised a “statistics table” that did not exist anywhere in the file – no table, no cell, no label – and the hit rates and Wilson lower bounds it computed were never rendered by anything. The arrays, the win counters and both helper functions fed only those six unreachable numbers. The promise was deleted rather than the table built, which took the file from 242 lines to 197 with no change to a single plotted value.

The two score areas were declared last, so they were painted over the lines they were meant to annotate: at least one plotted line sat underneath one of them on 38.7% of bars, a median of 13.4 points deep, with the 4H %K line covered on 16.8% and the white composite on 11.2%. They are now declared first and much fainter, because they are context rather than the subject. The 4H line was linewidth 4, which made the slowest and most stepped series the loudest thing in the pane; the composite now leads instead. The armed shading reused the same lime and red as the score areas, so three different things were saying red – it is one neutral wash now, and its title says what it means. The tiny “3” glyphs on the extreme markers and the “MTF+”/”MTF-” labels on the triggers are gone.

The bear score area was drawn the wrong way up. Both areas were anchored at 0 and grew upward, but a bear reading means %K is high – so the red area lived at the bottom of the pane, under the oversold line, covering it on 45.4% of bars of BTCUSDT (38.8% on ETHUSDT, 41.8% on SOLUSDT), and could never reach the overbought line it is about: its maximum over 5,982 bars is 71.75. Each score is now drawn at the end of the pane its own condition lives at – the bull score up from 0, the bear score down from 100.

The title’s en-dashes and one Unicode minus sign became ASCII, 770 box-drawing characters in the comment separators became hyphens, an MPL header was added, and the two threshold inputs and the data-mode input now carry the measurements above in their tooltips. The alert messages no longer say a filter was “passed” and say in their own text how rarely they fire.

WHAT ACTUALLY MOVES THE OUTPUT

Not the threshold everyone will reach for first. Measured on BTCUSDT against the defaults over 5,700 bars after warm-up, the %K smoothing is the single most consequential setting for whether this script does anything at all: at 1 it produces 20 signals, at the default 3 it produces 6, at 6 it produces zero. The slope-for-full-turn input is next – at 2 it gives 12 signals, at 20 it gives zero – and it moves the composite by exactly nothing, because it only touches the gates.

For the composite line itself, the timeframe weights dominate: a 4H-heavy setting moves it by a median of 8.07 points, equal weights by 3.47, against 4.42 for a %K length of 9 and 3.82 for 21. The soft band, the cluster window and the %D smoothing move the composite by exactly zero – they only change which bars are eligible.

WHAT THE MEASUREMENTS COVER

All of it is 15m data from 2026-06-25 to 2026-08-26, 62 days, on three instruments, in a window where BTCUSDT rose 26.5%, ETHUSDT 48.4% and SOLUSDT 38.7%. That matters here: in a rising window the three legs sit above 50 more often than below – 51.6% to 61.3% of bars on BTCUSDT – which is why the bear side of the pane is busier than the bull side and why bearish arming is roughly twice as common as bullish. Nothing was tested outside that window, in a falling market, or on a non-crypto instrument. Everything is measured on the Confirmed data mode; the Developing mode is measured only for its repaint, above.

HOW THE NUMBERS WERE CHECKED

The whole computation was reimplemented outside Pine and cross-checked against this chart’s Data Window: thirty quantities on ten bars – all three %K and %D legs and their bar-to-bar changes, the composite, dispersion, coherence, both position terms, both scores, both armed flags, both strict-extreme flags and both triggers – with two of the ten bars carrying events, including one that fires the bearish trigger, so the event and latch paths were exercised rather than assumed. All 300 values round to the exact two decimals TradingView prints, with a worst raw difference of 5.0e-3, the display’s own rounding floor.

Open source under MPL 2.0. Nothing here is a forecast, a signal service, or a claim of profitability.