Pine Script v6 Neuerungen was 2026 für Strategien zählt.

Pine Script v6 hat 2026 mehrere Neuerungen bekommen, die für Strategien zählen: Volume-Footprint-Daten per request.footprint() (Januar), den Parameter calc_on_every_history_tick für Strategietests auf Tick-Ebene historischer Bars (Juli) sowie das Schlüsselwort once, Binärsuche in Arrays eigener Typen und einen Pine Screener mit Indizes als Symbolquelle (August). Alle diese Funktionen gibt es nur in v6. Bestehende v5-Skripte laufen weiter, bekommen aber keine neuen Sprachfunktionen mehr. Stand Oktober 2026 fasst dieser Artikel zusammen, was sich geändert hat, zeigt kurze Codebeispiele und ordnet ein, wann sich die Migration von v5 lohnt. Er ergänzt meinen älteren Grundlagenartikel, der noch auf Version 5 beruht, und benennt offen, wo auch die genaueren Strategietests in TradingView an Grenzen stoßen.

Was ist neu in Pine Script v6 seit 2026?

Pine Script ist die Skriptsprache von TradingView für Indikatoren, Strategien und Bibliotheken. Version 6 kam Ende 2024 (Release Notes: November 2024, Blog-Ankündigung am 10. Dezember 2024) und brachte unter anderem dynamische Datenabfragen, eine verkürzte Auswertung von and und or sowie Strategien, die beim Überschreiten von 9.000 Trades nicht mehr abbrechen, sondern die ältesten Orders aus dem Ergebnis entfernen. Seitdem erweitert TradingView die Sprache in kurzen Abständen, 2025 fast jeden Monat. Die offiziellen Release Notes sind die verlässlichste Übersicht.

Für das Jahr 2026 sind diese Neuerungen dokumentiert (Auswahl, Stand Oktober 2026):

Dazu kamen schon 2025 kleinere Änderungen, etwa längere Strings (bis 40.960 statt 4.096 Zeichen) und neue Optionen für Inputs und Plots. Wer meinen Grundlagenartikel TradingView Pine Script: wann sinnvoll, wann limitiert kennt: Die dortige Einschätzung zu Stärken und Grenzen gilt weiter. Neu ist vor allem, dass sich Strategien in v6 genauer testen lassen und dass mehr Marktdaten im Skript ankommen.

Was liefert request.footprint() in Pine Script?

Ein Volume Footprint zerlegt einen Bar in gleich große Preiszeilen und zeigt für jede Zeile Kauf- und Verkaufsvolumen. Laut Dokumentation stuft TradingView dabei Volumen aus niedrigeren Zeitebenen anhand der Kursbewegung innerhalb des Bars als „buy“ (aufwärts) oder „sell“ (abwärts) ein. Seit Januar 2026 können Skripte diese Daten mit request.footprint() abrufen. Pflicht ist die Zeilenhöhe in Ticks, optional folgen der Prozentsatz für die Value Area (Standard 70) und ein Prozentsatz für Ungleichgewichte, sogenannte Imbalances (Standard 300). Die Funktion gibt ein footprint-Objekt zurück oder na, wenn für den Bar keine Daten vorliegen. Ein Skript darf sie nur einmal aufrufen.

Aus dem Objekt lesen Sie unter anderem:

• buy_volume(), sell_volume() und delta() für den ganzen Bar,
• poc(), vah() und val() als volume_row-Objekte für Point of Control (Preiszeile mit dem höchsten Volumen) sowie Ober- und Untergrenze der Value Area,
• up_price() und down_price() für die Preisgrenzen einer Zeile.

//@version=6
indicator("Footprint-Delta", overlay = false)
// 100 Ticks je Zeile, Value Area 70 %
footprint fp = request.footprint(100, 70)
float barDelta = na
float pocMid = na
if not na(fp)
    barDelta := fp.delta()
    volume_row poc = fp.poc()
    pocMid := (poc.up_price() + poc.down_price()) / 2
plot(barDelta, "Delta", style = plot.style_columns)
plot(pocMid, "POC-Mitte", display = display.data_window)

Zwei Punkte sind für die Praxis wichtig. Erstens setzt die Funktion einen Premium- oder Ultimate-Plan voraus. Ein Skript, das Sie veröffentlichen oder an andere weitergeben, funktioniert also nicht bei jedem Nutzer gleich. Zweitens sollten Sie immer auf na prüfen, sonst bricht die Logik auf Bars ohne Footprint ab. Wie aussagekräftig diese Einstufung von Kauf- und Verkaufsvolumen ist, hängt vom Markt und von der Datenquelle ab. Laut TradingView-Hilfe zeigt die Plattform das Volumen, das der jeweilige Datenanbieter liefert. Bei manchen Devisenpaaren und CFDs fehlt echtes Handelsvolumen, teils steht nur Tick-Volumen zur Verfügung, also die Zahl der Kursaktualisierungen. Einen Footprint auf dieser Basis sollten Sie entsprechend vorsichtig lesen.

Was bringt calc_on_every_history_tick für Strategietests?

Bisher lief eine Strategie auf historischen Bars in der Regel einmal pro Bar, am Schluss. Den Weg des Preises innerhalb des Bars musste der Broker-Emulator schätzen. Laut Dokumentation nimmt er an: Liegt der Eröffnungskurs näher am Hoch als am Tief, verlief der Kurs von Open über High und Low zum Close, sonst umgekehrt. Bei Strategien mit engen Stops und Zielen im selben Bar entscheidet diese Annahme oft darüber, ob ein Trade als Gewinn oder Verlust zählt.

Seit Juli 2026 gibt es in strategy() den Parameter calc_on_every_history_tick. Steht er auf true, läuft das Skript auf jedem historischen Bar einmal für jeden verfügbaren Tick. close, high, low und volume entwickeln sich dabei so, wie sie es während des laufenden Bars getan hätten. TradingView nennt als Ziel genauere Berechnungen und Fills sowie ein geringeres Risiko von Lookahead-Bias, also der Nutzung von Informationen, die zum Entscheidungszeitpunkt noch nicht vorlagen.

//@version=6
strategy("Tick-Test", overlay = true,
     calc_on_every_history_tick = true)

Die Einschränkungen nennen Release Notes und Handbuch: Die Funktion gilt nur für Standard-Charts und für Premium- und Ultimate-Pläne. Die Detailtiefe hängt an der Einstellung „Bar detalization“, die die frühere Bar-Lupe (Bar Magnifier) ersetzt. Aus niedrigeren Zeitebenen lassen sich laut Handbuch höchstens 200.000 Bars laden. Wo für ältere Bars keine Intrabar-Daten existieren, greift wieder die Standardannahme. Und weil das Skript pro Bar für jeden verfügbaren Tick statt nur einmal läuft, führt es entsprechend mehr Berechnungen aus. Konkrete Angaben zu Rechen- oder Ladezeiten macht TradingView dazu nicht. Mit dem Update kamen neue Menüs im Strategiebericht, unter anderem „Script execution“, „Limit order execution“, eine einstellbare Ausführungsverzögerung und Hebel-Felder für Long und Short anstelle der Margin-Prozente.

Das Schlüsselwort once und Binärsuche in UDT-Arrays.

Seit August 2026 kennt Pine Script die Struktur once. Sie führt einen Block aus, sobald die Bedingung wahr ist. Ist das einmal auf einem abgeschlossenen Bar geschehen, läuft der Block nie wieder, egal was die Bedingung später ergibt. Die Bedingung ist optional, es gibt kein else und keinen Rückgabewert. Typische Einsätze sind einmalige Initialisierungen, das erste Auftreten eines Ereignisses oder ein einmaliges Setzen von Zeichenobjekten.

//@version=6
indicator("once-Demo", overlay = true)
bool crossUp = ta.crossover(ta.sma(close, 20), ta.sma(close, 50))
// feuert nur beim ersten bestätigten Kreuz im gesamten Chart
once crossUp and barstate.isconfirmed
    label.new(bar_index, low, "Erstes Kreuz")

Wichtig ist der Zusatz barstate.isconfirmed. Auf einem Echtzeit-Bar wertet Pine den noch nicht ausgelösten once-Block bei jedem Tick aus. Durch den Rollback (das Zurücksetzen auf den Stand vor dem Tick) kann er innerhalb eines Bars mehrfach feuern. Für varip-Variablen, Strategie-Befehle, alert()-Aufrufe oder Log-Einträge, die der Rollback nicht zurücknimmt, wäre das ein echter Fehler. Die Dokumentation nennt genau diesen Zusatz als Abhilfe.

Die zweite Neuerung betrifft benutzerdefinierte Typen (UDT, User-Defined Types). Seit April lassen sich Arrays solcher Objekte mit sort_field nach einem Feld sortieren, seit August auch per Binärsuche durchsuchen: array.binary_search(), array.binary_search_leftmost() und array.binary_search_rightmost() akzeptieren denselben Parameter. Voraussetzung ist, dass das Array aufsteigend nach genau diesem Feld sortiert ist, sonst sind die Ergebnisse falsch.

type Level
    float price
    int   touches

var array<Level> levels = array.new<Level>()
// ... Levels befüllen ...
array.sort(levels, sort_field = "price")
int idx = array.binary_search_leftmost(levels, close, sort_field = "price")

Für Skripte, die viele Preislevel, Zonen oder Ereignisse verwalten, spart das Schleifen und damit Laufzeit. Gerade zusammen mit calc_on_every_history_tick zählt jede eingesparte Schleife.

Was kann der Pine Screener mit Indizes?

Der Pine Screener wendet ein Indikator-Skript auf viele Symbole gleichzeitig an und filtert nach dessen Plots oder Alarmbedingungen. Bisher war eine Watchlist die Symbolquelle. Seit August 2026 lässt sich alternativ ein Index wählen, etwa S&P 500, Nasdaq 100 oder DAX. Die Release Notes nennen bis zu 4.000 Symbole, der begleitende Blogbeitrag spricht von Universen bis 3.500 Symbolen. Rechnen Sie also mit einer Größenordnung von einigen Tausend.

Einschränkungen nach Dokumentation und Blog:

• Nur Indikatoren mit mindestens einem plot*()- oder alertcondition()-Aufruf werden unterstützt. Strategien laufen im Screener nicht.
• Es gilt jeweils eine Symbolquelle, Watchlist oder Index, keine Mehrfachauswahl.
• Ein Wechsel der Quelle verwirft die bisherigen Ergebnisse.

Für systematische Ansätze ist der Screener ein Werkzeug zur Vorauswahl, kein Backtest. Ein Index von heute enthält die Mitglieder von heute. Wer damit historische Auswertungen macht, baut sich einen Survivorship-Bias ein, also eine Verzerrung durch ausgeschiedene Titel, die in der Liste fehlen.

Lohnt sich die Migration von Pine Script v5 auf v6?

TradingView schreibt zur Einführung von v6, dass die Änderungen keine Skripte in älteren Versionen beeinträchtigen. Gleichzeitig kommen neue Funktionen nur noch in der neuesten Version. Ein v5-Skript, das zuverlässig tut, was es soll, müssen Sie also nicht anfassen. Sobald Sie eine der neuen Funktionen nutzen wollen, führt kein Weg an v6 vorbei.

Der Pine Editor bietet einen Konverter: Im Menü „Manage script“ steht „Convert code to v6“. Das setzt voraus, dass das v5-Skript fehlerfrei kompiliert. Laut Migrationsleitfaden kann das Ergebnis in seltenen Fällen Kompilierfehler enthalten. Dazu kommen Änderungen, die Nacharbeit verlangen oder, gefährlicher, ohne Fehlermeldung das Verhalten ändern:

Mein Vorgehen bei Strategien: Vor der Konvertierung die Kennzahlen des v5-Laufs festhalten (Anzahl Trades, Netto-Ergebnis, maximaler Drawdown, einige Einzeltrades mit Zeitstempel), dann konvertieren und vergleichen. Weichen die Werte ab, liegt das fast immer an einer der Änderungen aus der Tabelle. Erst wenn der v6-Lauf das bekannte Verhalten reproduziert, kommen neue Funktionen wie calc_on_every_history_tick dazu, und zwar einzeln, damit jede Abweichung einer Ursache zuzuordnen bleibt.

Wo stoßen TradingView-Strategietests an Grenzen?

Die Neuerungen machen TradingView-Backtests genauer, aber nicht zur Prognose. Einige Grenzen bleiben auch mit Tick-Berechnung bestehen:

• Datenhistorie: Intrabar-Daten reichen nicht beliebig weit zurück. Wo sie fehlen, gilt wieder die Standardannahme zum Kursverlauf im Bar. Ein Test über viele Jahre mischt dann zwei Genauigkeitsstufen.
• Fills und Kosten: Slippage, Kommission und Ausführungsverzögerung sind Eingaben, die Sie selbst schätzen. Laut Handbuch lässt sich Slippage nicht exakt simulieren, und Liquidität fließt nur über vereinfachte Annahmen ein, etwa zur Ausführung von Limit-Orders.
• Datenquelle: TradingView-Kurse und -Volumen stammen nicht zwingend vom Broker, über den später gehandelt wird. Spreads und Ticks können abweichen.
• Überanpassung: Mehr Detail verführt zu mehr Parametern. Eine Strategie, die nur mit exakt abgestimmten Werten auf einem Symbol funktioniert, ist meist an die Vergangenheit angepasst.
• Planabhängigkeit: Footprint und Tick-Berechnung brauchen Premium oder Ultimate. Ergebnisse sind damit für andere Nutzer nicht ohne Weiteres reproduzierbar.
• Ausführung: TradingView handelt nicht selbst für Sie. Der Weg vom Alarm zur Order über Webhooks oder Broker-Anbindungen bringt eigene Verzögerungen und Fehlerquellen.

Dazu kommt das grundsätzliche Risiko: Gehebelte Produkte können zum Totalverlust führen, und kein Backtest sagt künftige Ergebnisse voraus. Wie der Übergang vom Test in den Live-Betrieb gelingt und welche Fallen typisch sind, beschreibe ich in Vom Backtest zur Live-Strategie.

Was Sie jetzt konkret tun können.

1. Bestand sichten: Listen Sie Ihre Skripte nach Version auf. Stabile v5-Indikatoren ohne Bedarf an neuen Funktionen dürfen bleiben.
2. Referenzlauf sichern: Für jede Strategie, die Sie migrieren, Kennzahlen und einige Einzeltrades aus dem v5-Lauf dokumentieren.
3. Konvertieren und vergleichen: Konverter nutzen, dann die Änderungen aus der Tabelle oben gezielt prüfen, vor allem Division, bool-Logik und Margin.
4. Tick-Berechnung testen: Denselben Zeitraum mit und ohne calc_on_every_history_tick laufen lassen. Große Unterschiede zeigen, dass Ihre Strategie stark vom Verlauf innerhalb der Bars abhängt. Das ist eine wichtige Information über ihre Robustheit.
5. Neue Funktionen gezielt einsetzen: once mit barstate.isconfirmed für einmalige Ereignisse, Binärsuche für viele Level, Footprint nur dort, wo die Volumendaten des Marktes belastbar sind.
6. Forward-Test einplanen: Vor echtem Kapital über Wochen auf einem Demokonto oder mit kleinster Größe prüfen, ob Live-Fills zum Test passen.

Wenn eine Strategie aus TradingView heraus wächst, etwa weil Sie Ausführung, Risikokontrolle und Protokollierung selbst in der Hand haben wollen, ist die Umsetzung in MQL5 oder Python der nächste Schritt. Wie ich dabei vorgehe, steht auf der Seite zur Trading-Automatisierung.

Häufige Fragen.

Laufen Pine-Script-v5-Skripte 2026 noch?

Ja. TradingView hat bei der Einführung von v6 erklärt, dass die Änderungen keine Skripte in älteren Pine-Versionen beeinträchtigen. Neue Sprachfunktionen wie request.footprint(), calc_on_every_history_tick oder once gibt es allerdings nur in v6. Wer sie nutzen will, muss das Skript konvertieren und danach prüfen, ob es sich noch gleich verhält.

Wie migriere ich ein Pine Script von v5 auf v6?

Im Pine Editor wählen Sie im Menü Manage script den Eintrag Convert code to v6. Das v5-Skript muss vorher fehlerfrei kompilieren. Anschließend sollten Sie Verhaltensänderungen prüfen: die Division ganzzahliger Konstanten liefert jetzt Nachkommastellen, bool-Werte können nicht mehr na sein, and und or werten verkürzt aus, und die Standard-Margin für Strategien liegt bei 100 Prozent.

Was macht calc_on_every_history_tick in Pine Script?

Der Parameter in strategy() lässt eine Strategie auf historischen Bars für jeden verfügbaren Tick laufen statt nur einmal pro Bar. Kurs- und Volumenvariablen entwickeln sich dabei wie im laufenden Bar. Das macht Order-Fills im Test realistischer, vervielfacht aber die Zahl der Skriptausführungen. Laut TradingView gilt die Funktion für Standard-Charts mit Premium- oder Ultimate-Plan.

Welcher TradingView-Plan ist für request.footprint() nötig?

Laut TradingView setzt request.footprint() einen Premium- oder Ultimate-Plan voraus. Die Funktion liefert pro Bar als Kauf und Verkauf eingestuftes Volumen, Delta, Point of Control und Value Area oder na, wenn keine Daten vorliegen. Skripte, die Sie weitergeben, verhalten sich deshalb bei Nutzern mit kleineren Plänen anders.

Sind TradingView-Backtests mit Tick-Daten realistisch?

Realistischer als vorher, aber weiterhin eine Simulation. Intrabar-Daten reichen nicht beliebig weit zurück, Slippage und Kommissionen sind geschätzte Eingaben, und Liquidität geht nur über vereinfachte Annahmen ein. Vor echtem Kapitaleinsatz gehört ein Forward-Test auf einem Demokonto oder mit kleinster Positionsgröße dazu.

Quellen und Stand.

• Pine Script Release Notes — TradingView
• Pine Script v6 has landed — TradingView Blog
• To Pine Script version 6 (Migration Guide) — TradingView
• Volume footprints in Pine Scripts — TradingView Blog
• Strategies — TradingView Pine Script User Manual
• Conditional structures — TradingView Pine Script User Manual
• Pine Screener update — TradingView Blog
• Other timeframes and data: request.footprint() — TradingView Pine Script User Manual
• The Volume indicator on my chart looks odd or displays zero (or n/a) values — TradingView Help Center

Stand: 6. Oktober 2026. Produkte, Funktionen und Preise ändern sich schnell; maßgeblich sind die Angaben der Anbieter und Behörden.

Sie wollen eine TradingView-Strategie sauber testen oder in ein eigenes Handelssystem überführen? Unverbindlich anfragen — wir klären Regelwerk, Testumfang und den Weg zur automatisierten Ausführung. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.