You cannot write honest backtests without understanding how PineScript processes data. The execution model determines what information your script has access to at each point in time, and misunderstanding it is the root cause of most backtest errors.
PineScript is a series-based language. Every variable is implicitly a time series. When you write close, you are not accessing a single number — you are accessing the entire history of closing prices. close gives you the current bar's close. close[1] gives you the previous bar's close. close[10] gives you the close from ten bars ago. This history operator [] is how you reference past values.
On historical bars, the script executes once per bar, at the bar's close. This is critical. When TradingView processes historical data, each bar's open, high, low, and close are all known simultaneously. Your script sees the complete bar — including the close — before making any decisions. In real time, the script executes on every tick (or once per bar close, depending on settings), and the close is the last traded price, which changes constantly until the bar closes.
This asymmetry between historical and real-time execution is the single biggest source of backtest-to-live divergence. A strategy that enters "on the close" in a backtest was entering at a known price. In live trading, it enters at whatever price exists when the bar closes, which might be several ticks away from where the entry signal was generated.
Here is the execution flow on historical data:
- Bar opens. PineScript has access to
open, high, low, close, and volume for this bar and all previous bars.
- Script logic evaluates conditions using these values.
- If
strategy.entry() or strategy.order() is called, the order fills on the next bar's open (by default) or at the current bar's close (with process_orders_on_close = true).
- Move to the next bar and repeat.
The process_orders_on_close parameter in the strategy() declaration changes fill behavior. When set to true, orders generated on bar N fill at bar N's close instead of bar N+1's open. This matters enormously for momentum strategies where the close-to-open gap can be significant in crypto. Use process_orders_on_close = false (the default) for more conservative backtests. Using true assumes you can execute at exactly the closing price, which is rarely possible in practice.
//@version=6
strategy("Execution Model Demo", overlay = true,
default_qty_type = strategy.percent_of_equity,
default_qty_value = 100,
process_orders_on_close = false,
calc_on_every_tick = false)
// This condition uses the CONFIRMED close of the current bar.
// On historical data, this is always known.
// In real-time, this only fires after bar confirmation.
longCondition = ta.crossover(ta.sma(close, 20), ta.sma(close, 50))
if longCondition
strategy.entry("Long", strategy.long)
// This order fills at the NEXT bar's open (process_orders_on_close = false)
// That is more realistic than filling at the signal bar's close
The calc_on_every_tick parameter controls real-time behavior. When false, the script recalculates only once when the bar closes, which means real-time behavior matches historical behavior — signals only fire on confirmed bars. When true, the script recalculates on every price update, which can generate intra-bar signals that flip back and forth before the bar closes. For backtesting, calc_on_every_tick = false produces more honest results because it matches the once-per-bar historical execution.
Understanding bar states is essential for writing non-repainting logic. PineScript provides barstate.isconfirmed, barstate.isrealtime, barstate.ishistory, and barstate.islast. The most important is barstate.isconfirmed, which returns true only when the current bar has closed. Wrapping your entry logic in an if barstate.isconfirmed block ensures signals only fire on confirmed data — identical behavior in backtesting and live trading.
//@version=6
strategy("Confirmed Bars Only", overlay = true,
default_qty_type = strategy.percent_of_equity,
default_qty_value = 10)
smaFast = ta.sma(close, 10)
smaSlow = ta.sma(close, 30)
// Only generate signals on confirmed (closed) bars
if barstate.isconfirmed
if ta.crossover(smaFast, smaSlow)
strategy.entry("Long", strategy.long)
if ta.crossunder(smaFast, smaSlow)
strategy.close("Long")
Variable declaration scope also affects execution. Variables declared with var persist across bars — they are initialized once and retain their value. Variables without var are recalculated on every bar. Misusing var is a common source of bugs where state from previous bars leaks into current calculations.
The execution model interacts with market regime detection in important ways. If your regime filter uses a long-lookback indicator (like a 200-period moving average), the first 200 bars of your backtest have incomplete data. PineScript handles this with na values, but if you do not check for na, your strategy might generate spurious signals during the warmup period. Always guard against na:
//@version=6
strategy("Safe Warmup", overlay = true)
sma200 = ta.sma(close, 200)
// Guard against na during warmup
if not na(sma200) and barstate.isconfirmed
if close > sma200
strategy.entry("Long", strategy.long)
- One more subtlety: PineScript re-executes on every historical bar sequentially. This means that state management through
var variables works as a forward-only state machine. You cannot look ahead. But you can inadvertently create lookahead bias through request.security() calls, which is covered in detail later. The execution model is your friend if you respect it, and your enemy if you assume it works like a general-purpose programming language.
A PineScript strategy script has a predictable structure. Understanding each component prevents the configuration errors that silently corrupt backtest results.
The strategy() declaration is the most important line in your script. It controls commission modeling, slippage, position sizing defaults, margin requirements, and fill assumptions. Getting these wrong invalidates every trade in your backtest.
//@version=6
strategy("BTC Momentum Strategy",
overlay = true,
initial_capital = 10000,
default_qty_type = strategy.percent_of_equity,
default_qty_value = 10,
commission_type = strategy.commission.percent,
commission_value = 0.075,
slippage = 2,
process_orders_on_close = false,
calc_on_every_tick = false,
pyramiding = 0,
margin_long = 100,
margin_short = 100,
max_bars_back = 5000,
currency = currency.USD)
Let us break down every parameter that matters for honest crypto backtesting.
initial_capital sets your starting balance. This affects percentage-based position sizing and equity curve calculations. Set it to a realistic amount. Testing with $10,000,000 initial capital hides drawdown severity — a 5% drawdown on $10M is $500K, which feels different than 5% on a $10K account, but the percentage is what matters for strategy evaluation.
commission_type and commission_value model trading fees. For crypto spot, 0.1% taker fee is standard on most exchanges. For perpetual futures, 0.04-0.075% is typical. Use strategy.commission.percent and set the value per side. PineScript applies commission on both entry and exit, so a commission_value of 0.075 means you pay 0.075% to enter and 0.075% to exit — 0.15% round trip. This matches most crypto futures exchanges. If you are backtesting a high-frequency scalping strategy, this cost adds up fast and can turn a profitable backtest into a losing one.
slippage is measured in ticks (minimum price increments). On BTCUSDT, one tick is typically $0.10. Setting slippage to 2 means your fills are 2 ticks worse than the signal price — $0.20 per side on BTC. For altcoins with wider spreads, increase this to 3-5. For illiquid altcoins, 10+. Crypto markets are thin compared to equities, and slippage is where many "profitable" strategies actually die. If you are reading orderflow to find liquid entry zones, you can justify lower slippage assumptions.
pyramiding controls how many entries in the same direction are allowed. Setting it to 0 means only one position at a time — no adding to winners or losers. Setting it to 3 allows up to three stacked entries. Pyramiding dramatically changes backtest results and must match your actual trading plan.
margin_long and margin_short set margin requirements as percentages. 100 means no leverage (1x). 50 means 2x leverage. 10 means 10x leverage. For futures strategies, set this to match your actual leverage. Running a backtest at 10x leverage while planning to trade at 3x produces meaningless results.
default_qty_type and default_qty_value control position sizing when strategy.entry() does not specify a quantity. strategy.percent_of_equity sizes positions as a percentage of current equity. strategy.fixed uses a fixed number of contracts. strategy.cash uses a fixed dollar amount. For proper position sizing strategies, strategy.percent_of_equity is usually correct because it naturally compounds gains and reduces exposure after losses.
After the strategy declaration, a typical script follows this structure:
//@version=6
strategy("Template Strategy", overlay = true,
initial_capital = 10000,
default_qty_type = strategy.percent_of_equity,
default_qty_value = 10,
commission_type = strategy.commission.percent,
commission_value = 0.075,
slippage = 2,
process_orders_on_close = false,
pyramiding = 0)
// === INPUTS ===
fastLen = input.int(10, "Fast MA Length", minval = 1)
slowLen = input.int(30, "Slow MA Length", minval = 1)
atrLen = input.int(14, "ATR Length", minval = 1)
atrMult = input.float(2.0, "ATR Stop Multiplier", step = 0.1)
useDateFilter = input.bool(true, "Use Date Filter")
startDate = input.time(timestamp("2023-01-01"), "Start Date")
endDate = input.time(timestamp("2026-01-01"), "End Date")
// === INDICATORS ===
fastMA = ta.sma(close, fastLen)
slowMA = ta.sma(close, slowLen)
atrVal = ta.atr(atrLen)
// === DATE FILTER ===
inDateRange = not useDateFilter or (time >= startDate and time <= endDate)
// === CONDITIONS ===
longCondition = ta.crossover(fastMA, slowMA) and inDateRange
shortCondition = ta.crossunder(fastMA, slowMA) and inDateRange
// === EXECUTION ===
if longCondition and barstate.isconfirmed
strategy.entry("Long", strategy.long)
strategy.exit("Long Exit", "Long",
stop = close - atrMult * atrVal,
limit = close + atrMult * atrVal * 2)
if shortCondition and barstate.isconfirmed
strategy.entry("Short", strategy.short)
strategy.exit("Short Exit", "Short",
stop = close + atrMult * atrVal,
limit = close - atrMult * atrVal * 2)
// === PLOTTING ===
plot(fastMA, "Fast MA", color.new(color.blue, 0))
plot(slowMA, "Slow MA", color.new(color.red, 0))
Notice the date filter. This is essential for walk-forward analysis. You optimize on one date range (in-sample), then test on another (out-of-sample). Without a date filter, you are always testing on the same data you optimized on, which guarantees overfitting.
The strategy.exit() function deserves special attention. It sets stop-loss and take-profit levels relative to the entry. The stop parameter is the price at which you exit for a loss. The limit parameter is the price at which you take profit. You can also use trail_price and trail_offset for trailing stops, trail_points for point-based trailing, or profit and loss for tick-based exits.
For crypto risk management, ATR-based stops are superior to fixed-percentage stops because they adapt to volatility. When BTC is ranging in a tight channel, ATR contracts and your stops tighten. When BTC is in a volatile breakout, ATR expands and your stops widen. This keeps your risk per trade approximately constant in volatility-adjusted terms, which is how professional position sizing works.
The entry logic is where most traders spend their time. It is the least important part of the strategy.
That statement sounds contrarian, but it is backed by decades of quantitative research. Van Tharp demonstrated that random entries with proper position sizing and exit management can be profitable. The expectancy of a system depends on three variables: win rate, average win, and average loss. Your exits control two of those three. Your entries only influence one.
This does not mean entries are irrelevant. A good entry increases win rate and reduces the time spent in drawdown. But a great entry paired with bad exits will lose money, while a mediocre entry paired with great exits can be profitable. Build your exit logic first, then refine entries.
The worst entries in PineScript use lagging indicators with no confirmation logic. A simple moving average crossover fires hundreds of times in ranging markets, generating whipsaw after whipsaw. Each whipsaw costs commission and slippage. By the time the trend actually begins, you have already lost enough on false signals to diminish the trend capture.
Better entries combine a trend filter with a trigger:
//@version=6
strategy("Filtered Entry", overlay = true,
initial_capital = 10000,
default_qty_type = strategy.percent_of_equity,
default_qty_value = 10,
commission_type = strategy.commission.percent,
commission_value = 0.075,
slippage = 2)
// Trend filter: 200 EMA
ema200 = ta.ema(close, 200)
// Trigger: Pullback to 20 EMA in uptrend
ema20 = ta.ema(close, 20)
// Volatility: ADX filter for trending conditions
[diPlus, diMinus, adxVal] = ta.dmi(14, 14)
// Volume confirmation
volSMA = ta.sma(volume, 20)
volSpike = volume > volSMA * 1.5
// Entry: Price above 200 EMA (uptrend) + touches 20 EMA (pullback) +
// ADX > 25 (trending) + volume spike (confirmation)
longEntry = close > ema200 and
low <= ema20 and close > ema20 and
adxVal > 25 and volSpike
if longEntry and barstate.isconfirmed
strategy.entry("Long", strategy.long)
This entry has four independent conditions that must align. Each condition reduces the number of signals, but the signals that pass all four filters have a higher probability of success. The ADX indicator filters out ranging environments where trend-following entries get chopped up. The volume spike confirms institutional participation. The pullback to the 20 EMA provides a better entry price than chasing the breakout.
For mean reversion entries — which work well when funding rates are extreme or Bollinger Bands are stretched — the logic inverts:
//@version=6
strategy("Mean Reversion Entry", overlay = true,
initial_capital = 10000,
default_qty_type = strategy.percent_of_equity,
default_qty_value = 10,
commission_type = strategy.commission.percent,
commission_value = 0.075,
slippage = 2)
// Bollinger Bands for deviation measurement
[bbMid, bbUpper, bbLower] = ta.bb(close, 20, 2.5)
// RSI for momentum confirmation
rsiVal = ta.rsi(close, 14)
// Mean reversion long: price below lower band + RSI oversold
mrLong = close < bbLower and rsiVal < 30
// Mean reversion short: price above upper band + RSI overbought
mrShort = close > bbUpper and rsiVal > 70
if mrLong and barstate.isconfirmed
strategy.entry("MR Long", strategy.long)
if mrShort and barstate.isconfirmed
strategy.entry("MR Short", strategy.short)
Three exit types define your strategy's risk-reward profile: stop-loss, take-profit, and trailing stop.
Fixed stop-losses are the simplest. You risk X% of price movement. If BTC is at $60,000 and your stop is 2% below, you exit at $58,800. The problem with fixed stops in crypto is that volatility changes dramatically between market regimes. A 2% stop that works perfectly during a low-volatility accumulation phase will get triggered constantly during a high-volatility distribution phase.
ATR-based stops adapt to volatility:
//@version=6
strategy("ATR Exit System", overlay = true,
initial_capital = 10000,
default_qty_type = strategy.percent_of_equity,
default_qty_value = 10,
commission_type = strategy.commission.percent,
commission_value = 0.075,
slippage = 2)
atrLen = input.int(14, "ATR Length")
slMult = input.float(2.0, "Stop Loss ATR Multiple", step = 0.1)
tpMult = input.float(3.0, "Take Profit ATR Multiple", step = 0.1)
usTrail = input.bool(true, "Use Trailing Stop")
trMult = input.float(1.5, "Trail ATR Multiple", step = 0.1)
atrVal = ta.atr(atrLen)
ema50 = ta.ema(close, 50)
ema200 = ta.ema(close, 200)
longCondition = ta.crossover(ema50, ema200) and barstate.isconfirmed
if longCondition
stopPrice = close - slMult * atrVal
limitPrice = close + tpMult * atrVal
strategy.entry("Long", strategy.long)
if usTrail
strategy.exit("Long Exit", "Long",
stop = stopPrice,
trail_price = close + trMult * atrVal,
trail_offset = math.round(trMult * atrVal / syminfo.mintick))
else
strategy.exit("Long Exit", "Long",
stop = stopPrice,
limit = limitPrice)
The risk-reward ratio is embedded in the relationship between slMult and tpMult. A 2:3 ratio means your take-profit is 1.5x your stop-loss distance. This means you need a win rate above 40% to break even (excluding fees). A 1:3 ratio only needs 25% win rate. The math of expectancy governs these relationships, and understanding it lets you build strategies that are profitable even with low win rates.
Time-based exits are underused in crypto. If your thesis is that funding rate extremes mean-revert within 24 hours, a trade that has been open for 48 hours has already outlived its hypothesis. Closing it removes dead-weight positions that consume margin and mental bandwidth:
//@version=6
strategy("Time-Based Exit", overlay = true,
initial_capital = 10000,
default_qty_type = strategy.percent_of_equity,
default_qty_value = 10,
commission_type = strategy.commission.percent,
commission_value = 0.075,
slippage = 2)
maxBarsInTrade = input.int(24, "Max Bars in Trade")
var int entryBar = na
longCondition = ta.rsi(close, 14) < 30 and barstate.isconfirmed
if longCondition and strategy.position_size == 0
strategy.entry("Long", strategy.long)
entryBar := bar_index
// Time-based exit
if strategy.position_size > 0 and not na(entryBar)
if bar_index - entryBar >= maxBarsInTrade
strategy.close("Long", comment = "Time Exit")
Combining multiple exit types — stop-loss, take-profit, trailing stop, and time exit — creates a robust exit system that handles different outcomes. The stop protects against catastrophic loss. The take-profit locks in gains at a predetermined target. The trailing stop captures extended moves. The time exit removes trades that are not working within the expected timeframe. This is how discretionary and systematic traders differ in their approach to trade management.
Position sizing determines whether a winning strategy makes you rich or blows up your account. Two traders can run identical entry and exit logic and get opposite results purely from position sizing differences.
Most PineScript scripts use default_qty_type = strategy.percent_of_equity and set a fixed percentage. This is better than fixed contract sizing, but it is not optimal for crypto. Crypto volatility varies 3-5x between regimes. A position sized at 10% of equity when BTC is in a low-volatility accumulation phase becomes a wildly different risk exposure when BTC enters a high-volatility distribution phase.
The simplest proper method. Risk a fixed percentage of equity on every trade:
//@version=6
strategy("Fixed Fractional", overlay = true,
initial_capital = 10000,
default_qty_type = strategy.cash,
default_qty_value = 100,
commission_type = strategy.commission.percent,
commission_value = 0.075,
slippage = 2)
riskPct = input.float(1.0, "Risk Per Trade %", step = 0.1) / 100
atrLen = input.int(14, "ATR Length")
atrStopMult = input.float(2.0, "ATR Stop Multiple", step = 0.1)
atrVal = ta.atr(atrLen)
stopDist = atrStopMult * atrVal
riskAmount = strategy.equity * riskPct
// Position size = risk amount / distance to stop
posSize = riskAmount / stopDist
ema20 = ta.ema(close, 20)
ema50 = ta.ema(close, 50)
longCondition = ta.crossover(ema20, ema50) and barstate.isconfirmed
if longCondition and not na(atrVal) and stopDist > 0
strategy.entry("Long", strategy.long, qty = posSize)
strategy.exit("Long SL", "Long", stop = close - stopDist)
This calculates position size dynamically so that if the stop-loss is hit, you lose exactly riskPct of equity. Wider stops get smaller positions. Tighter stops get larger positions. The dollar risk per trade remains constant regardless of volatility.
For traders with enough data to estimate their edge parameters, volatility-adjusted sizing based on a simplified Kelly criterion maximizes long-term growth:
//@version=6
strategy("Volatility Adjusted Sizing", overlay = true,
initial_capital = 10000,
default_qty_type = strategy.cash,
default_qty_value = 100,
commission_type = strategy.commission.percent,
commission_value = 0.075,
slippage = 2)
estWinRate = input.float(55.0, "Estimated Win Rate %", step = 1.0) / 100
estRR = input.float(2.0, "Estimated R:R Ratio", step = 0.1)
kellyFrac = input.float(0.25, "Kelly Fraction (0.25 = quarter Kelly)", step = 0.05)
atrLen = input.int(14, "ATR Length")
atrStopMult = input.float(2.0, "ATR Stop Multiple", step = 0.1)
atrVal = ta.atr(atrLen)
stopDist = atrStopMult * atrVal
// Kelly percentage: W - (1 - W) / R
kellyPct = estWinRate - (1 - estWinRate) / estRR
// Use fractional Kelly to reduce variance
riskPct = math.max(kellyPct * kellyFrac, 0.005)
riskPct := math.min(riskPct, 0.05)
riskAmount = strategy.equity * riskPct
posSize = stopDist > 0 ? riskAmount / stopDist : 0
ema20 = ta.ema(close, 20)
ema50 = ta.ema(close, 50)
longCond = ta.crossover(ema20, ema50) and barstate.isconfirmed
if longCond and posSize > 0
strategy.entry("Long", strategy.long, qty = posSize)
strategy.exit("Long SL", "Long", stop = close - stopDist)
Full Kelly sizing is too aggressive for crypto. It assumes perfect knowledge of your edge parameters, zero correlation between trades, and normally distributed returns — none of which hold in crypto markets. Quarter Kelly (kellyFrac = 0.25) provides 75% of the growth rate with dramatically less drawdown risk. This is standard practice at quantitative funds and aligns with variance and probability principles that govern long-term trading outcomes.
Another approach is to scale position size with equity, increasing after wins and decreasing after losses. PineScript handles this naturally when you use strategy.percent_of_equity, but you can make it more aggressive or conservative:
//@version=6
strategy("Anti-Martingale", overlay = true,
initial_capital = 10000,
default_qty_type = strategy.percent_of_equity,
default_qty_value = 10,
commission_type = strategy.commission.percent,
commission_value = 0.075,
slippage = 2)
baseRiskPct = input.float(10.0, "Base Position %", step = 1.0) / 100
drawdownAdj = input.bool(true, "Reduce Size in Drawdown")
// Track peak equity
var float peakEquity = strategy.initial_capital
peakEquity := math.max(peakEquity, strategy.equity)
// Current drawdown percentage
currentDD = (peakEquity - strategy.equity) / peakEquity
// Reduce position size linearly as drawdown increases
ddMultiplier = drawdownAdj ? math.max(1.0 - currentDD * 2, 0.25) : 1.0
adjPct = baseRiskPct * ddMultiplier
posSize = strategy.equity * adjPct / close
ema20 = ta.ema(close, 20)
ema50 = ta.ema(close, 50)
longCond = ta.crossover(ema20, ema50) and barstate.isconfirmed
if longCond and posSize > 0
strategy.entry("Long", strategy.long, qty = posSize)
This reduces position size as drawdown deepens, preserving capital during losing streaks. A 10% drawdown halves the position size (with the 2x multiplier). A 20% drawdown reduces position size to 60% of normal. This is a mathematically sound approach to managing drawdowns and matches how professional traders scale their risk.
Use the position size calculator to check your sizing before deploying any strategy live.
Repainting is when an indicator or strategy changes its past values on historical bars. A signal that showed "buy" yesterday now shows nothing. An indicator value that was 50 yesterday is now 48. The backtest shows perfect entries at exact bottoms and tops — because the script retroactively adjusted its output after seeing what happened next.
Repainting is the single most destructive backtest artifact. A repainting strategy can show 90%+ win rates and astronomical returns in backtesting while losing money consistently in live trading. The backtest is literally using future information that was not available at the time the trade would have been taken.
1. Using close on the current bar without confirmation.
On historical data, close on any bar is the final close. But in real time, close is the last traded price, which changes tick by tick until the bar closes. If your entry logic triggers mid-bar based on close, it might untrigger before the bar finishes. The backtest sees only the final confirmed value, so it looks like the signal was always correct.
- Fix: Use
barstate.isconfirmed to ensure you only act on completed bars.
2. request.security() with lookahead enabled.
The request.security() function fetches data from other symbols or timeframes. Prior to Pine v3, lookahead was enabled by default, which meant the function returned the current bar's value from the requested timeframe before that bar closed. In Pine v6, the default is lookahead = barmerge.lookahead_off, but many old scripts and tutorials still use barmerge.lookahead_on — and this directly leaks future data into your backtest.
3. Requesting a higher timeframe and using its current close.
Even with lookahead_off, requesting a higher timeframe produces subtle repainting. When you request the daily close from a 1-hour chart, the daily close only becomes available after the daily bar closes (at midnight UTC). On historical data, PineScript correctly aligns this — but only if you index with [1] to get the previous completed daily bar. Using the current daily bar without [1] accesses data that was not available at the time.
4. ta.pivothigh() and ta.pivotlow() with right bars.
Pivot detection requires future bars to confirm the pivot. ta.pivothigh(high, 5, 5) needs 5 bars after the peak to confirm it was a pivot. This means the pivot is only identified 5 bars late — but on the chart, PineScript plots it at the pivot bar itself, making it look like you could have known about it in real time. You could not.
5. Strategies that use security() to fetch a lower timeframe.
Fetching a lower timeframe (e.g., 5-minute data on a 1-hour chart) is inherently repainting because multiple lower-timeframe bars fit within one higher-timeframe bar, and PineScript picks which lower-timeframe value to display on the historical higher-timeframe bar.
Before trusting any PineScript backtest, run through this checklist:
//@version=6
indicator("Repainting Detector", overlay = true)
// Check 1: Are we using confirmed bars?
isConfirmed = barstate.isconfirmed
// Check 2: Does any request.security() call use lookahead_on?
// Search your code for: lookahead = barmerge.lookahead_on
// If found -> REPAINTING
// Check 3: Does any request.security() call fetch a higher TF
// without indexing [1]?
// htfClose = request.security(syminfo.tickerid, "D", close) // REPAINTS
// htfClose = request.security(syminfo.tickerid, "D", close[1]) // SAFE
// Check 4: Are pivot functions used for entry signals?
// ta.pivothigh() and ta.pivotlow() ALWAYS repaint
// They require right-side bars to confirm, then plot retroactively
// Check 5: Is the strategy using realtime-only functions in backtesting?
// ticker.heikinashi(), ticker.renko(), ticker.kagi() can cause issues
// Visual repainting test: add to chart, watch for signal changes
plotshape(isConfirmed and ta.crossover(ta.sma(close, 10), ta.sma(close, 30)),
"Signal", shape.triangleup, location.belowbar, color.green)
The easiest repainting test is the "fresh eyes" test. Add your indicator or strategy to a real-time chart. Write down every signal as it appears. Wait for the bar to close. If any signal disappears, changes, or moves to a different bar — you have repainting. Do this for at least 20-30 bars. It is tedious. It is also the only way to be certain.
Here is a non-repainting strategy template that uses every safeguard:
//@version=6
strategy("Non-Repainting Template", overlay = true,
initial_capital = 10000,
default_qty_type = strategy.percent_of_equity,
default_qty_value = 10,
commission_type = strategy.commission.percent,
commission_value = 0.075,
slippage = 2,
process_orders_on_close = false,
calc_on_every_tick = false)
// All indicator calculations use confirmed bar data
// because calc_on_every_tick = false means we only calc on bar close
smaFast = ta.sma(close, 10)
smaSlow = ta.sma(close, 30)
rsiVal = ta.rsi(close, 14)
// Higher timeframe data: use [1] to get PREVIOUS completed bar
dailyClose = request.security(syminfo.tickerid, "D", close[1],
lookahead = barmerge.lookahead_off)
// Confirm trend on daily timeframe using previous day's close
dailyUptrend = close > dailyClose
// Entry only on confirmed bars with non-repainting HTF filter
if barstate.isconfirmed and dailyUptrend
if ta.crossover(smaFast, smaSlow) and rsiVal > 50
strategy.entry("Long", strategy.long)
if ta.crossunder(smaFast, smaSlow)
strategy.close("Long")
This template avoids every repainting source: confirmed bars only, lookahead_off, [1] index on higher-timeframe data, process_orders_on_close = false, and calc_on_every_tick = false. The backtest from this script will closely match live performance. For a deeper dive on backtesting methodology, that guide covers the statistical foundations.
The request.security() function is the most powerful and most dangerous function in PineScript. It lets you access data from other symbols, other timeframes, and other data feeds — all from a single script. It is also the single biggest source of repainting, lookahead bias, and misleading backtest results.
Multi-timeframe analysis is fundamental to crypto trading. You might want to trade on the 1-hour chart but only take longs when the daily trend is up. Or you might want a 4-hour Ichimoku Cloud to define support/resistance levels while using 15-minute price action for entries.
//@version=6
strategy("MTF Strategy", overlay = true,
initial_capital = 10000,
default_qty_type = strategy.percent_of_equity,
default_qty_value = 10,
commission_type = strategy.commission.percent,
commission_value = 0.075,
slippage = 2)
// Higher timeframe: Daily EMA 200 for trend direction
dailyEma200 = request.security(syminfo.tickerid, "D",
ta.ema(close, 200)[1],
lookahead = barmerge.lookahead_off)
// Higher timeframe: 4H RSI for momentum
fourHrRsi = request.security(syminfo.tickerid, "240",
ta.rsi(close, 14)[1],
lookahead = barmerge.lookahead_off)
// Current timeframe: entry signal
ema20 = ta.ema(close, 20)
ema50 = ta.ema(close, 50)
// Multi-timeframe confluence:
// Daily uptrend + 4H momentum positive + 1H crossover
longSignal = close > dailyEma200 and
fourHrRsi > 50 and
ta.crossover(ema20, ema50)
if longSignal and barstate.isconfirmed
strategy.entry("MTF Long", strategy.long)
Notice the [1] after the indicator calculation inside request.security(). This ensures you are using the previous completed bar from the higher timeframe. Without [1], you access the current higher-timeframe bar, which has not closed yet and will change — classic repainting.
You can fetch data from other symbols to build correlation-based or relative-strength strategies:
//@version=6
strategy("Cross Symbol", overlay = true,
initial_capital = 10000,
default_qty_type = strategy.percent_of_equity,
default_qty_value = 10,
commission_type = strategy.commission.percent,
commission_value = 0.075,
slippage = 2)
// BTC dominance as a regime filter
btcDom = request.security("CRYPTOCAP:BTC.D", timeframe.period,
close[1], lookahead = barmerge.lookahead_off)
// ETH/BTC ratio for relative strength
ethBtc = request.security("BINANCE:ETHBTC", timeframe.period,
close[1], lookahead = barmerge.lookahead_off)
ethBtcSma = request.security("BINANCE:ETHBTC", timeframe.period,
ta.sma(close, 20)[1], lookahead = barmerge.lookahead_off)
// Trade ETH long when: BTC dom falling + ETH/BTC above its 20 SMA
ethStrong = btcDom < 50 and ethBtc > ethBtcSma
ema20 = ta.ema(close, 20)
ema50 = ta.ema(close, 50)
longCond = ta.crossover(ema20, ema50) and ethStrong and barstate.isconfirmed
if longCond
strategy.entry("ETH Long", strategy.long)
When fetching higher-timeframe data, the gaps parameter controls how values are displayed on lower-timeframe bars between updates. barmerge.gaps_off (default) fills gaps by carrying the last known value forward. barmerge.gaps_on inserts na values between higher-timeframe updates.
For strategy scripts, always use barmerge.gaps_off (or omit the parameter). You want the last known higher-timeframe value to persist, not na gaps that would break your conditional logic.
Mistake 1: Fetching lower timeframes.
// DON'T DO THIS — fetching 5m data on a 1H chart
fiveMinClose = request.security(syminfo.tickerid, "5", close)
// This REPAINTS because multiple 5m bars exist within one 1H bar
// PineScript arbitrarily picks which 5m value to show on the 1H bar
Only fetch equal or higher timeframes. Lower timeframe requests produce undefined behavior on historical data.
Mistake 2: Omitting [1] on higher timeframe expressions.
// REPAINTS — uses current daily bar which hasn't closed
dailyClose = request.security(syminfo.tickerid, "D", close)
// SAFE — uses previous completed daily bar
dailyClose = request.security(syminfo.tickerid, "D", close[1],
lookahead = barmerge.lookahead_off)
Mistake 3: Using lookahead = barmerge.lookahead_on without understanding it.
Lookahead was designed for a specific use case: aligning data from different timeframes for non-trading purposes (like displaying an indicator). Using it in a strategy gives your backtest perfect foresight. The backtest will look incredible. Live trading will not.
Mistake 4: Assuming request.security() calculations happen independently.
When you pass an expression like ta.ema(close, 200) to request.security(), PineScript calculates that EMA on the requested timeframe's data. This is correct and useful. But the calculation happens within the security context, not your chart's context. The EMA history, bar count, and na handling all operate on the requested timeframe.
For deep multi-timeframe strategies that combine technical analysis with AI insights, understanding these mechanics is essential for building reliable signal pipelines.
Theory is useless without application. Let us build a complete, non-repainting strategy from scratch: a funding rate mean reversion system for BTC perpetual futures.
When perpetual futures funding rates reach extremes, the market is one-sided. Extremely positive funding means longs are paying shorts — too many longs. Extremely negative funding means shorts are paying longs — too many shorts. These extremes tend to mean-revert as overleveraged positions get squeezed. This is a well-documented inefficiency in crypto derivatives markets, explained in detail in the perpetual swaps and funding rate strategies guide.
TradingView does not provide direct funding rate data in PineScript. However, you can access funding rate proxies through the spread between perpetual and spot prices, or use exchanges that publish funding rate charts (like BINANCE:BTCUSDTPERP funding rate). For this strategy, we will use a price-derived approach combined with momentum indicators as a proxy for positioning extremes.
In a production environment, you would use the Thrive Data Workbench to access actual funding rate data and build backtests with custom signals.
//@version=6
strategy("Funding Rate Fade", overlay = true,
initial_capital = 10000,
default_qty_type = strategy.cash,
default_qty_value = 1000,
commission_type = strategy.commission.percent,
commission_value = 0.04,
slippage = 3,
process_orders_on_close = false,
calc_on_every_tick = false,
pyramiding = 0,
margin_long = 20,
margin_short = 20)
// === INPUTS ===
rsiLen = input.int(14, "RSI Length", minval = 2)
rsiOB = input.float(78.0, "RSI Overbought", step = 1.0)
rsiOS = input.float(22.0, "RSI Oversold", step = 1.0)
bbLen = input.int(20, "Bollinger Band Length", minval = 2)
bbDev = input.float(2.5, "BB Deviation", step = 0.1)
atrLen = input.int(14, "ATR Length", minval = 1)
atrStopMult = input.float(2.0, "ATR Stop Multiple", step = 0.1)
atrTPMult = input.float(3.0, "ATR TP Multiple", step = 0.1)
riskPct = input.float(2.0, "Risk Per Trade %", step = 0.5) / 100
maxBarsHeld = input.int(48, "Max Bars Held", minval = 1)
useDateFilter = input.bool(true, "Use Date Filter")
startDate = input.time(timestamp("2023-01-01"), "Start Date")
endDate = input.time(timestamp("2026-01-01"), "End Date")
// === REGIME FILTER (Daily Timeframe) ===
dailyAtr = request.security(syminfo.tickerid, "D",
ta.atr(14)[1], lookahead = barmerge.lookahead_off)
dailyAtrSma = request.security(syminfo.tickerid, "D",
ta.sma(ta.atr(14), 20)[1], lookahead = barmerge.lookahead_off)
// High volatility regime = favorable for mean reversion
highVolRegime = not na(dailyAtr) and not na(dailyAtrSma) and
dailyAtr > dailyAtrSma * 1.2
// === INDICATORS ===
rsiVal = ta.rsi(close, rsiLen)
[bbMid, bbUpper, bbLower] = ta.bb(close, bbLen, bbDev)
atrVal = ta.atr(atrLen)
// Volume confirmation
volSma = ta.sma(volume, 20)
highVol = volume > volSma * 1.3
// === POSITION SIZING ===
stopDist = atrStopMult * atrVal
riskAmount = strategy.equity * riskPct
posSize = stopDist > 0 ? riskAmount / stopDist : 0
// === DATE FILTER ===
inDateRange = not useDateFilter or (time >= startDate and time <= endDate)
// === ENTRY CONDITIONS ===
// Fade overbought: RSI extreme + price above upper BB + high volume + high vol regime
shortEntry = rsiVal > rsiOB and close > bbUpper and highVol and
highVolRegime and inDateRange and barstate.isconfirmed
// Fade oversold: RSI extreme + price below lower BB + high volume + high vol regime
longEntry = rsiVal < rsiOS and close < bbLower and highVol and
highVolRegime and inDateRange and barstate.isconfirmed
// === TRACK ENTRY BAR ===
var int entryBar = na
// === EXECUTION ===
if longEntry and strategy.position_size == 0 and posSize > 0
strategy.entry("Fade Long", strategy.long, qty = posSize)
strategy.exit("FL Exit", "Fade Long",
stop = close - stopDist,
limit = close + atrTPMult * atrVal)
entryBar := bar_index
if shortEntry and strategy.position_size == 0 and posSize > 0
strategy.entry("Fade Short", strategy.short, qty = posSize)
strategy.exit("FS Exit", "Fade Short",
stop = close + stopDist,
limit = close - atrTPMult * atrVal)
entryBar := bar_index
// === TIME EXIT ===
if strategy.position_size != 0 and not na(entryBar)
if bar_index - entryBar >= maxBarsHeld
strategy.close_all(comment = "Time Exit")
entryBar := na
// === PLOTTING ===
plot(bbUpper, "BB Upper", color.new(color.red, 50))
plot(bbMid, "BB Mid", color.new(color.gray, 50))
plot(bbLower, "BB Lower", color.new(color.green, 50))
bgcolor(highVolRegime ? color.new(color.yellow, 95) : na)
Why 5x leverage (margin = 20)? Funding rate fades are high-conviction, short-duration trades. The edge relies on mean reversion within hours. Moderate leverage amplifies the small per-trade edge without risking liquidation on a typical adverse move. Still, you must understand risk management before using any leverage.
Why RSI + Bollinger Bands? RSI measures momentum extremes. Bollinger Bands measure price deviation from the mean. When both are extreme simultaneously, you have momentum exhaustion at a statistical extreme — a double confirmation of mean reversion conditions.
Why a volume filter? Extremes without volume are meaningless. A price spike on low volume is noise. A price spike on high volume means participants are committing capital at extreme levels, which creates the crowded positioning that drives reversion.
Why a regime filter? Mean reversion works in volatile, ranging markets. In low-volatility trending markets, "extremes" are just the beginning of a trend, and fading them loses money. The ATR regime filter ensures you only trade when volatility is elevated relative to its recent average.
Why a time exit? The funding rate fade thesis has a specific time horizon. If the reversion has not happened within 48 bars (48 hours on 1H), the thesis is wrong, and holding longer introduces random risk. This is how you avoid the trap of letting losers run under the hope that "it will come back."
This strategy structure — thesis-driven entry, volatility-adapted sizing, regime filter, time-bounded hold — is the template for every professional strategy. The specific indicators change. The framework does not. For a broader catalog of approaches, the top 10 crypto trading strategies for 2026 covers complementary methods.
Raw equity curves tell you the overall trajectory. Monthly performance tables tell you when and how a strategy makes money. Both are essential for strategy evaluation, and PineScript v6 has the tools to build them.
PineScript's table object lets you build visual performance dashboards directly on the chart. Here is a complete monthly returns table:
//@version=6
strategy("Monthly Table Demo", overlay = true,
initial_capital = 10000,
default_qty_type = strategy.percent_of_equity,
default_qty_value = 10,
commission_type = strategy.commission.percent,
commission_value = 0.075,
slippage = 2)
showTable = input.bool(true, "Show Monthly Table")
// Simple strategy for demonstration
ema20 = ta.ema(close, 20)
ema50 = ta.ema(close, 50)
if ta.crossover(ema20, ema50) and barstate.isconfirmed
strategy.entry("L", strategy.long)
if ta.crossunder(ema20, ema50) and barstate.isconfirmed
strategy.close("L")
// === MONTHLY PERFORMANCE TABLE ===
var float[] monthlyReturns = array.new_float(0)
var int[] monthlyYears = array.new_int(0)
var int[] monthlyMonths = array.new_int(0)
var float prevMonthEquity = strategy.initial_capital
var int prevMonth = month(time)
var int prevYear = year(time)
curMonth = month(time)
curYear = year(time)
if curMonth != prevMonth or curYear != prevYear
monthlyReturn = (strategy.equity - prevMonthEquity) / prevMonthEquity * 100
array.push(monthlyReturns, monthlyReturn)
array.push(monthlyYears, prevYear)
array.push(monthlyMonths, prevMonth)
prevMonthEquity := strategy.equity
prevMonth := curMonth
prevYear := curYear
if showTable and barstate.islast
var table perfTable = table.new(position.bottom_right, 14, 20,
bgcolor = color.new(color.black, 10),
border_width = 1,
border_color = color.gray)
// Header row
months = array.from("Jan", "Feb", "Mar", "Apr", "May", "Jun",
"Jul", "Aug", "Sep", "Oct", "Nov", "Dec", "Total")
table.cell(perfTable, 0, 0, "Year",
text_color = color.white, text_size = size.small)
for i = 0 to 12
table.cell(perfTable, i + 1, 0, array.get(months, i),
text_color = color.white, text_size = size.small)
// Find unique years
var int[] uniqueYears = array.new_int(0)
array.clear(uniqueYears)
for i = 0 to array.size(monthlyYears) - 1
yr = array.get(monthlyYears, i)
if not array.includes(uniqueYears, yr)
array.push(uniqueYears, yr)
// Fill table
for row = 0 to array.size(uniqueYears) - 1
yr = array.get(uniqueYears, row)
table.cell(perfTable, 0, row + 1, str.tostring(yr),
text_color = color.white, text_size = size.small)
yearTotal = 0.0
for m = 1 to 12
monthReturn = 0.0
for i = 0 to array.size(monthlyReturns) - 1
if array.get(monthlyYears, i) == yr and array.get(monthlyMonths, i) == m
monthReturn := array.get(monthlyReturns, i)
cellColor = monthReturn > 0 ? color.new(color.green, 60) :
monthReturn < 0 ? color.new(color.red, 60) : color.new(color.gray, 80)
table.cell(perfTable, m, row + 1,
str.tostring(monthReturn, "#.#") + "%",
bgcolor = cellColor,
text_color = color.white,
text_size = size.tiny)
yearTotal += monthReturn
yearColor = yearTotal > 0 ? color.new(color.green, 40) : color.new(color.red, 40)
table.cell(perfTable, 13, row + 1,
str.tostring(yearTotal, "#.#") + "%",
bgcolor = yearColor,
text_color = color.white,
text_size = size.small)
Monthly tables expose patterns that equity curves hide. You might discover your strategy makes all its money in Q4 and loses in Q1-Q2. Or that it only works during high-volatility months and bleeds during consolidation. These patterns inform regime-based trading decisions — you can deploy the strategy only during favorable months.
Look for these red flags in your monthly table:
- Clustered winners: If 80% of annual returns come from 2-3 months, your strategy might be dependent on a specific market condition rather than having a persistent edge.
- Alternating red/green: Consistent monthly chop suggests the strategy is capturing noise, not signal.
- Deteriorating recent performance: If early years are green and recent years are red, the edge may be decaying — other participants have discovered and arbitraged it.
- Correlation with BTC trend: If green months perfectly align with BTC rallies and red months with drawdowns, your "strategy" is just leveraged beta.
For performance attribution, decompose returns by entry signal type, market regime, and time of day. This tells you which components of your strategy contribute to the edge and which are dead weight.
The monthly table is also essential for tracking your trading performance. When you deploy the strategy live, compare actual monthly returns against backtested expectations. Systematic deviation suggests either the edge has changed or execution differs from backtest assumptions.
Walk-forward analysis is the gold standard for validating that a strategy generalizes beyond its training data. It is the difference between a curve-fitted illusion and a genuine trading edge.
A static backtest optimizes parameters on the entire dataset, then evaluates performance on the same dataset. This is circular reasoning. Of course the strategy works on data it was tuned to fit. The question is whether it works on data it has never seen.
Imagine you build a strategy on BTC 1H from 2022-2025. You optimize the MA lengths, RSI thresholds, ATR multipliers — all on this same data. Your equity curve looks great. You deploy in January 2026. It loses money. The parameters were perfectly calibrated to 2022-2025 market conditions, which do not repeat in 2026.
Walk-forward analysis divides your data into sequential windows. Each window has an in-sample (IS) period for optimization and an out-of-sample (OOS) period for validation. The key rule: you optimize on IS data, then test on OOS data without changing parameters.
The process:
- Window 1: Optimize on Jan 2022 - Dec 2023 (IS). Test on Jan 2024 - Jun 2024 (OOS).
- Window 2: Optimize on Jul 2022 - Jun 2024 (IS). Test on Jul 2024 - Dec 2024 (OOS).
- Window 3: Optimize on Jan 2023 - Dec 2024 (IS). Test on Jan 2025 - Jun 2025 (OOS).
- Combine: Stitch together all OOS results into a single equity curve.
The combined OOS equity curve represents how your strategy would have performed if you had re-optimized every 6 months — which is a realistic deployment scenario.
In PineScript, you implement walk-forward analysis using date filters:
//@version=6
strategy("Walk Forward Window", overlay = true,
initial_capital = 10000,
default_qty_type = strategy.percent_of_equity,
default_qty_value = 10,
commission_type = strategy.commission.percent,
commission_value = 0.075,
slippage = 2)
// Window selection: change these for each walk-forward step
windowStart = input.time(timestamp("2024-01-01"), "Window Start")
windowEnd = input.time(timestamp("2024-07-01"), "Window End")
inWindow = time >= windowStart and time < windowEnd
// Strategy parameters (optimized on in-sample, frozen for OOS)
fastLen = input.int(12, "Fast MA")
slowLen = input.int(26, "Slow MA")
rsiLen = input.int(14, "RSI Length")
rsiThr = input.float(50, "RSI Threshold")
emaFast = ta.ema(close, fastLen)
emaSlow = ta.ema(close, slowLen)
rsiVal = ta.rsi(close, rsiLen)
longCond = ta.crossover(emaFast, emaSlow) and rsiVal > rsiThr
shortCond = ta.crossunder(emaFast, emaSlow) and rsiVal < 100 - rsiThr
if inWindow and barstate.isconfirmed
if longCond
strategy.entry("Long", strategy.long)
if shortCond
strategy.close("Long")
if not inWindow and strategy.position_size != 0
strategy.close_all(comment = "Outside Window")
You would run this script multiple times, changing the window dates and optimizing fastLen, slowLen, rsiLen, and rsiThr on each IS period, then recording OOS performance. The process is manual in PineScript but can be automated in Python.
The walk-forward efficiency ratio (WFE) measures how much of your in-sample performance survives out-of-sample:
WFE = (OOS Annual Return) / (IS Annual Return) × 100%
- WFE > 50%: Strong. The strategy retains most of its edge out-of-sample.
- WFE 30-50%: Acceptable. There is some overfitting, but the strategy still has an edge.
- WFE < 30%: Weak. Most of the in-sample performance was curve-fitting.
- WFE < 0%: The strategy loses money out-of-sample. Discard it.
A strategy with a WFE above 50% across multiple walk-forward windows has cleared a serious validation hurdle. Combined with positive results from Monte Carlo simulations, it is worth deploying with real capital.
Standard walk-forward uses calendar-based windows. A more sophisticated approach uses regime-based windows, where you separate bull, bear, and sideways periods and test whether the strategy works in each. This is critical in crypto because market regimes determine which strategy types work.
A trend-following strategy should make money in trending regimes and lose (or break even) in ranging regimes. If it makes money across all regimes equally, something is suspicious — probably overfitting. If it makes money only in the specific regime present during the IS period, it will fail when the regime changes.
For building profitable trading systems, walk-forward analysis is non-negotiable. Every professional quant shop uses some variant of this methodology to separate signal from noise in their strategy development pipeline.
You have a strategy. It passes walk-forward analysis. The out-of-sample equity curve trends upward. But is the edge statistically significant, or could these results have occurred by random chance?
Statistical validation answers this question with numbers, not intuition. The core metrics are profit factor, Sharpe ratio, expectancy, and sample size — each telling you something different about your edge.
Profit factor = gross profits / gross losses. PineScript reports this in the strategy tester.
- PF < 1.0: Losing strategy. Gross losses exceed gross profits.
- PF 1.0 - 1.3: Marginal. Barely profitable. Fees and slippage adjustments could flip it negative.
- PF 1.3 - 1.7: Decent edge. Viable if consistent across market regimes.
- PF 1.7 - 2.5: Strong edge. Worth deploying with proper risk management.
- PF > 2.5: Suspicious. Likely overfitted unless the sample size is very large and the strategy has passed OOS validation.
A PF of 1.5 means for every dollar lost, you make $1.50. Over 200 trades, this compounds significantly. Use the profit-loss calculator to model how profit factor translates to actual returns at different trade frequencies.
The Sharpe ratio measures risk-adjusted returns. Annualized Sharpe = (Mean Annual Return - Risk-Free Rate) / Standard Deviation of Returns.
- Sharpe < 0.5: Poor. Not enough return for the risk taken.
- Sharpe 0.5 - 1.0: Acceptable. Typical for a retail crypto strategy.
- Sharpe 1.0 - 2.0: Strong. Professional-grade performance.
- Sharpe > 2.0: Exceptional. Verify you are not overfitting or underestimating risk.
Crypto strategies typically have lower Sharpe ratios than equities strategies because crypto volatility is higher. A Sharpe of 1.0 in crypto is equivalent to roughly 1.5-2.0 in equities, after adjusting for the volatility difference.
Expectancy = (Win Rate × Average Win) - (Loss Rate × Average Loss). This is the expected dollar return per trade.
Win Rate: 55%
Average Win: $200
Average Loss: $120
Expectancy = (0.55 × $200) - (0.45 × $120) = $110 - $54 = $56 per trade
Over 200 trades, a $56 expectancy produces $11,200 in expected profits. But expectancy alone does not tell you about variance. You might have 10 consecutive losers before the expectancy converges. This is where sample size matters.
How many trades do you need before your results are statistically meaningful? The answer depends on your win rate and the variance of your returns.
For a t-test at 95% confidence with a win rate of 55% and typical crypto return distributions, you need approximately 200+ trades for the results to be statistically significant. At 60% win rate, roughly 100 trades suffice. At 52%, you might need 500+.
A backtest showing a 90% win rate over 15 trades tells you nothing. The confidence interval is so wide that the true win rate could be anywhere from 65% to 99%. You need data. Lots of it.
PineScript does not provide a built-in t-test, but you can compute the core statistics:
//@version=6
strategy("Stats Dashboard", overlay = true,
initial_capital = 10000,
default_qty_type = strategy.percent_of_equity,
default_qty_value = 10,
commission_type = strategy.commission.percent,
commission_value = 0.075,
slippage = 2)
showStats = input.bool(true, "Show Stats Table")
// Simple strategy
ema20 = ta.ema(close, 20)
ema50 = ta.ema(close, 50)
atrVal = ta.atr(14)
if ta.crossover(ema20, ema50) and barstate.isconfirmed
strategy.entry("L", strategy.long)
strategy.exit("LX", "L", stop = close - 2 * atrVal, limit = close + 3 * atrVal)
if ta.crossunder(ema20, ema50)
strategy.close("L")
// === CUSTOM STATISTICS ===
var float[] tradeReturns = array.new_float(0)
var float lastEquity = strategy.initial_capital
if strategy.closedtrades > 0 and barstate.isconfirmed
totalTrades = strategy.closedtrades
if totalTrades > array.size(tradeReturns)
// New trade closed — record return
lastTradeProfit = strategy.closedtrades.profit(totalTrades - 1)
lastTradeEntry = strategy.closedtrades.entry_price(totalTrades - 1)
tradeReturnPct = lastTradeEntry != 0 ? (lastTradeProfit / lastTradeEntry) * 100 : 0
array.push(tradeReturns, tradeReturnPct)
if showStats and barstate.islast and array.size(tradeReturns) > 1
n = array.size(tradeReturns)
// Mean return
meanReturn = array.avg(tradeReturns)
// Standard deviation
sumSqDev = 0.0
for i = 0 to n - 1
dev = array.get(tradeReturns, i) - meanReturn
sumSqDev += dev * dev
stdDev = math.sqrt(sumSqDev / (n - 1))
// Sharpe-like ratio (per trade)
sharpePerTrade = stdDev != 0 ? meanReturn / stdDev : 0
// t-statistic
tStat = stdDev != 0 ? (meanReturn * math.sqrt(n)) / stdDev : 0
// Win rate
wins = 0
for i = 0 to n - 1
if array.get(tradeReturns, i) > 0
wins += 1
winRate = wins / n * 100
// Max consecutive losses
var int maxConsecLoss = 0
var int curConsecLoss = 0
maxConsecLoss := 0
curConsecLoss := 0
for i = 0 to n - 1
if array.get(tradeReturns, i) < 0
curConsecLoss += 1
maxConsecLoss := math.max(maxConsecLoss, curConsecLoss)
else
curConsecLoss := 0
var table statsTable = table.new(position.top_right, 2, 8,
bgcolor = color.new(color.black, 10),
border_width = 1, border_color = color.gray)
table.cell(statsTable, 0, 0, "Metric", text_color = color.white, text_size = size.small)
table.cell(statsTable, 1, 0, "Value", text_color = color.white, text_size = size.small)
table.cell(statsTable, 0, 1, "Trades", text_color = color.white, text_size = size.small)
table.cell(statsTable, 1, 1, str.tostring(n), text_color = color.white, text_size = size.small)
table.cell(statsTable, 0, 2, "Win Rate", text_color = color.white, text_size = size.small)
table.cell(statsTable, 1, 2, str.tostring(winRate, "#.#") + "%",
text_color = winRate > 50 ? color.green : color.red, text_size = size.small)
table.cell(statsTable, 0, 3, "Mean Return", text_color = color.white, text_size = size.small)
table.cell(statsTable, 1, 3, str.tostring(meanReturn, "#.##") + "%",
text_color = meanReturn > 0 ? color.green : color.red, text_size = size.small)
table.cell(statsTable, 0, 4, "Std Dev", text_color = color.white, text_size = size.small)
table.cell(statsTable, 1, 4, str.tostring(stdDev, "#.##") + "%",
text_color = color.white, text_size = size.small)
table.cell(statsTable, 0, 5, "Sharpe/Trade", text_color = color.white, text_size = size.small)
table.cell(statsTable, 1, 5, str.tostring(sharpePerTrade, "#.##"),
text_color = sharpePerTrade > 0.1 ? color.green : color.red, text_size = size.small)
table.cell(statsTable, 0, 6, "t-Stat", text_color = color.white, text_size = size.small)
table.cell(statsTable, 1, 6, str.tostring(tStat, "#.##"),
text_color = tStat > 2.0 ? color.green : color.orange, text_size = size.small)
table.cell(statsTable, 0, 7, "Max Consec Loss", text_color = color.white, text_size = size.small)
table.cell(statsTable, 1, 7, str.tostring(maxConsecLoss),
text_color = color.white, text_size = size.small)
The t-statistic is the most important number in your validation dashboard. It measures whether your mean return is statistically different from zero.
- t-stat > 2.0 (p < 0.05): Your edge is statistically significant at the 95% confidence level. There is less than a 5% chance that these results occurred by random luck.
- t-stat > 2.6 (p < 0.01): Significant at 99% confidence.
- t-stat < 2.0: Not statistically significant. Your results could be random chance.
With 200 trades, a win rate of 55%, and a mean return of 0.5% per trade, a t-stat above 2.0 means you likely have a real edge. But context matters. If you tested 100 parameter combinations and picked the best one, you need to apply a Bonferroni correction: divide your significance threshold by the number of tests. At 100 tests, you need a t-stat above roughly 3.3 to maintain 95% confidence.
This is why edge calculation matters so much. Without statistical rigor, you are trading on faith. With it, you are trading on evidence. The win rate calculator can help you quickly check whether your win rate is sufficient given your risk-reward profile.
PineScript is excellent for prototyping and visual backtesting. It is not a production execution environment. Understanding when and how to graduate from PineScript to Python determines whether your validated edge actually makes money or remains a theoretical curiosity.
1. No portfolio-level testing. PineScript runs one strategy on one symbol at a time. You cannot test a portfolio of BTC, ETH, SOL, and AVAX strategies simultaneously. Portfolio-level risk — correlation between positions, aggregate drawdown, sector exposure — is invisible.
2. No custom data sources. PineScript accesses only TradingView's data feeds. If your edge depends on on-chain data, funding rates, order book depth, or social sentiment, you cannot incorporate it directly. The best crypto trading tools stack typically includes external data sources that PineScript cannot reach.
3. Execution is approximate. PineScript fills orders at the next bar's open or the current bar's close. Real execution involves limit orders, partial fills, queue priority, and exchange-specific mechanics. The gap between PineScript fills and actual fills grows with position size and market illiquidity.
4. No programmatic optimization. Walk-forward analysis in PineScript is manual. In Python, you can automate the entire process: split data into windows, optimize parameters with cross-validation, compute walk-forward efficiency, and run Monte Carlo simulations — all in one script.
5. Limited statistical testing. PineScript can compute basic statistics, but proper machine learning analysis, distribution fitting, regime detection, and advanced statistical tests require Python libraries like scipy, statsmodels, and scikit-learn.
Do not rewrite your entire strategy in Python from scratch. Use PineScript as the idea validation stage and Python as the production stage.
- Prototype in PineScript. Build the strategy, visual-test it on charts, iterate on entry/exit logic. PineScript's instant chart feedback is unbeatable for rapid iteration.
- Validate in PineScript. Run the strategy across multiple symbols and timeframes. Check for repainting. Verify the equity curve across different market regimes.
- Export logic to Python. Translate the validated Pine Script logic into Python using pandas, numpy, and a backtesting framework like backtrader, vectorbt, or a custom engine.
- Rigorous validation in Python. Run walk-forward analysis, Monte Carlo simulation, and statistical significance tests with full automation. Python frameworks support advanced analytics that PineScript cannot match.
- Paper trade. Connect your Python strategy to an exchange testnet via API. Run it for
2-4 weeks. Compare results against backtest expectations.
- Deploy with reduced size. Go live with
10-25% of intended capital. Scale up only after 50+ live trades confirm the backtest performance.
Here is the funding rate fade strategy translated into Python pseudocode (not executable, but structurally accurate):
import pandas as pd
import numpy as np
def funding_rate_fade(df, rsi_len=14, rsi_ob=78, rsi_os=22,
bb_len=20, bb_dev=2.5, atr_len=14,
atr_stop_mult=2.0, atr_tp_mult=3.0,
risk_pct=0.02, max_bars=48):
"""
Vectorized backtest of funding rate fade strategy.
df must have columns: open, high, low, close, volume
"""
df['rsi'] = compute_rsi(df['close'], rsi_len)
df['bb_upper'], df['bb_mid'], df['bb_lower'] = compute_bb(
df['close'], bb_len, bb_dev)
df['atr'] = compute_atr(df['high'], df['low'], df['close'], atr_len)
df['vol_sma'] = df['volume'].rolling(20).mean()
# Entry signals
df['long_signal'] = (
(df['rsi'] < rsi_os) &
(df['close'] < df['bb_lower']) &
(df['volume'] > df['vol_sma'] * 1.3)
)
df['short_signal'] = (
(df['rsi'] > rsi_ob) &
(df['close'] > df['bb_upper']) &
(df['volume'] > df['vol_sma'] * 1.3)
)
# Simulate trades with position sizing and exits
trades = simulate_trades(df, risk_pct, atr_stop_mult,
atr_tp_mult, max_bars)
return trades
The Python version can then be fed into a walk-forward optimizer, a Monte Carlo engine, and a statistical significance tester — all automated. For traders using the Thrive platform, the Data Workbench provides these capabilities without requiring Python coding, bridging the gap between PineScript prototyping and production validation.
- The key insight: PineScript tells you if an idea is worth pursuing. Python (or Thrive's Workbench) tells you if it is worth trading. Both stages are necessary. Skipping PineScript means slow iteration. Skipping Python means unvalidated execution. For a complete guide on going from idea to AI-powered trading system, that article covers the full pipeline.
As your PineScript strategies grow complex, code organization becomes critical. PineScript v6 supports libraries, user-defined types (UDTs), and methods — tools that transform spaghetti scripts into maintainable codebases.
UDTs let you bundle related data into a single object. For strategy development, this is useful for trade state management, signal bundling, and configuration:
//@version=6
strategy("UDT Strategy", overlay = true,
initial_capital = 10000,
default_qty_type = strategy.percent_of_equity,
default_qty_value = 10,
commission_type = strategy.commission.percent,
commission_value = 0.075,
slippage = 2)
// Define a trade setup type
type TradeSetup
bool isValid
int direction // 1 = long, -1 = short
float entryPrice
float stopLoss
float takeProfit
float positionSize
string reason
// Function to evaluate long setups
evaluateLong(float atrVal, float riskPct) =>
ema20 = ta.ema(close, 20)
ema50 = ta.ema(close, 50)
rsiVal = ta.rsi(close, 14)
setup = TradeSetup.new()
setup.isValid := ta.crossover(ema20, ema50) and rsiVal > 50
setup.direction := 1
setup.entryPrice := close
setup.stopLoss := close - 2 * atrVal
setup.takeProfit := close + 3 * atrVal
stopDist = 2 * atrVal
riskAmt = strategy.equity * riskPct
setup.positionSize := stopDist > 0 ? riskAmt / stopDist : 0
setup.reason := "EMA cross + RSI confirm"
setup
atrVal = ta.atr(14)
riskPct = 0.01
longSetup = evaluateLong(atrVal, riskPct)
if longSetup.isValid and barstate.isconfirmed and longSetup.positionSize > 0
strategy.entry("Long", strategy.long, qty = longSetup.positionSize)
strategy.exit("Long Exit", "Long",
stop = longSetup.stopLoss,
limit = longSetup.takeProfit)
UDTs make your code self-documenting. Instead of tracking six separate variables for a trade setup, you have one TradeSetup object that encapsulates everything. When you add a new strategy component — say a divergence filter — you add a field to the type rather than another loose variable.
PineScript libraries let you share code across scripts. Create a library with reusable functions, then import it into your strategies. This eliminates copy-pasting indicator calculations across scripts:
//@version=6
// @description Common strategy utilities
library("StrategyUtils", overlay = false)
// @function Calculate ATR-based position size
// @param equity Current equity value
// @param riskPct Risk percentage per trade (0.01 = 1%)
// @param atrVal Current ATR value
// @param atrMult ATR multiplier for stop distance
// @returns Position size in units
export atrPositionSize(float equity, float riskPct, float atrVal, float atrMult) =>
stopDist = atrMult * atrVal
riskAmount = equity * riskPct
stopDist > 0 ? riskAmount / stopDist : 0.0
// @function Check if current regime is high volatility
// @param atrLen ATR lookback period
// @param smaLen SMA smoothing period for ATR
// @param threshold Multiplier threshold (e.g., 1.2 = 20% above average)
// @returns True if current ATR exceeds threshold × average ATR
export isHighVolRegime(int atrLen, int smaLen, float threshold) =>
atrVal = ta.atr(atrLen)
atrAvg = ta.sma(ta.atr(atrLen), smaLen)
not na(atrVal) and not na(atrAvg) and atrVal > atrAvg * threshold
// @function Non-repainting higher timeframe value
// @param sym Symbol string
// @param tf Timeframe string
// @param expr Expression to evaluate
// @returns Previous completed bar's value from the requested timeframe
export safeHTF(string sym, string tf, float expr) =>
request.security(sym, tf, expr[1], lookahead = barmerge.lookahead_off)
Import and use the library in your strategy:
//@version=6
strategy("Using Library", overlay = true,
initial_capital = 10000,
default_qty_type = strategy.cash,
default_qty_value = 100,
commission_type = strategy.commission.percent,
commission_value = 0.075,
slippage = 2)
import YourUsername/StrategyUtils/1 as su
atrVal = ta.atr(14)
posSize = su.atrPositionSize(strategy.equity, 0.01, atrVal, 2.0)
highVol = su.isHighVolRegime(14, 20, 1.2)
ema20 = ta.ema(close, 20)
ema50 = ta.ema(close, 50)
if ta.crossover(ema20, ema50) and highVol and barstate.isconfirmed and posSize > 0
strategy.entry("L", strategy.long, qty = posSize)
strategy.exit("LX", "L", stop = close - 2 * atrVal)
PineScript v6 supports methods on UDTs. This lets you attach behavior to your data types:
//@version=6
strategy("Methods Demo", overlay = true,
initial_capital = 10000,
default_qty_type = strategy.cash,
default_qty_value = 100,
commission_type = strategy.commission.percent,
commission_value = 0.075,
slippage = 2)
type RiskManager
float maxRiskPct
float maxDrawdownPct
float peakEquity
method init(RiskManager rm, float maxRisk, float maxDD) =>
rm.maxRiskPct := maxRisk
rm.maxDrawdownPct := maxDD
rm.peakEquity := strategy.initial_capital
rm
method update(RiskManager rm) =>
rm.peakEquity := math.max(rm.peakEquity, strategy.equity)
rm
method currentDrawdown(RiskManager rm) =>
rm.peakEquity > 0 ? (rm.peakEquity - strategy.equity) / rm.peakEquity : 0.0
method canTrade(RiskManager rm) =>
rm.currentDrawdown() < rm.maxDrawdownPct
method getPositionSize(RiskManager rm, float stopDist) =>
if not rm.canTrade() or stopDist <= 0
0.0
else
riskAmt = strategy.equity * rm.maxRiskPct
riskAmt / stopDist
// Initialize risk manager
var RiskManager rm = RiskManager.new().init(0.01, 0.15)
rm.update()
atrVal = ta.atr(14)
stopDist = 2 * atrVal
posSize = rm.getPositionSize(stopDist)
ema20 = ta.ema(close, 20)
ema50 = ta.ema(close, 50)
if ta.crossover(ema20, ema50) and rm.canTrade() and barstate.isconfirmed and posSize > 0
strategy.entry("L", strategy.long, qty = posSize)
strategy.exit("LX", "L", stop = close - stopDist)
// Stop trading when max drawdown is hit
if not rm.canTrade() and strategy.position_size != 0
strategy.close_all(comment = "Max DD Hit")
The RiskManager type encapsulates all risk logic. The canTrade() method checks whether you have exceeded maximum drawdown. The getPositionSize() method calculates position size with the drawdown check built in. This is clean, testable, reusable code — the kind you need when your strategy complexity grows.
Organizing your PineScript code with libraries, UDTs, and methods pays dividends when you have multiple strategies to maintain. Instead of debugging the same position sizing calculation across 10 scripts, you fix it once in the library and every strategy that imports it is updated. This mirrors how professional quantitative teams organize their code — and it is equally important for solo systematic traders managing multiple strategies.
For further signal research, the Thrive Data Workbench provides a SQL-based environment where you can query on-chain data, derivatives metrics, and market microstructure data — feeding ideas into your PineScript prototyping pipeline.
There is no universally best timeframe. The right timeframe depends on your strategy type. Scalping strategies operate on 1-5 minute charts but require tick-level accuracy that PineScript cannot provide — the execution model rounds to bar-level fills. Swing strategies on 4H-Daily charts are the sweet spot for PineScript backtesting because bar-level fill approximation is close to reality. Mean reversion strategies often work on 1H-4H. Trend-following strategies work on Daily-Weekly. Test your strategy on at least three timeframes. If it only works on one, you probably have a curve fit. If it works on 1H, 4H, and Daily with similar edge characteristics, the signal is likely real. The Thrive Academy covers timeframe selection in its Quantitative Modules.
Overfitting prevention starts with limiting the number of parameters you optimize. Every parameter you tune is a degree of freedom that can fit noise. A strategy with 3 parameters optimized across 10 values each tests 1,000 combinations. With 10 parameters, you are testing 10 billion. The more combinations tested, the higher the probability of finding a spurious result. Practical rules: limit optimization to 3-5 key parameters. Use walk-forward analysis to validate out-of-sample. Apply a Bonferroni correction to your significance threshold. Prefer parameter robustness (the strategy works across a range of values) over parameter precision (the strategy only works at one specific value). If changing your MA length from 20 to 22 destroys the strategy, it is overfit. If it degrades gracefully from 15 to 30, you have a robust signal. For a complete treatment, see the guide on variance and probability in crypto trading.
PineScript itself does not execute live trades. TradingView offers alerting functionality where your strategy generates alerts that can be sent to external services via webhooks. Those external services (like 3Commas, Autoview, or custom webhook receivers) then execute the trades on your exchange. This introduces latency, potential failure points, and execution differences from your backtest. For serious automated execution, graduating to Python with exchange API connections is recommended. The webhook approach works for lower-frequency strategies (Daily, 4H) where a few seconds of latency is irrelevant. For higher-frequency strategies, the latency kills the edge. The article on AI-powered crypto trading covers the full spectrum from manual to fully automated execution.
Repainting occurs when an indicator or strategy changes its historical values after new data arrives. A signal that appeared on a past bar disappears or moves when you refresh the chart. The most common causes are: using request.security() with lookahead = barmerge.lookahead_on, referencing the current bar's close in real-time calculations without barstate.isconfirmed, using pivot functions (ta.pivothigh, ta.pivotlow) for entry signals, and fetching lower-timeframe data. To detect repainting: add your script to a live chart, record signals as they appear in real-time, wait for bars to close, and check if any signals changed or disappeared. Run this test for at least 30 bars. A non-repainting script produces identical signals in backtesting and live execution. The repainting section of this article provides a complete checklist and a non-repainting strategy template. For building and backtesting custom signals, repainting prevention is the first quality gate.
PineScript backtesting is directionally accurate but quantitatively approximate. The main sources of divergence between backtest and live results are: fill price differences (backtest fills at next bar open; live fills depend on liquidity, spread, and order type), slippage underestimation (the default slippage of 0 ticks is unrealistic), commission underestimation (the default of 0% is unrealistic), funding rate costs on perpetual futures (not modeled in PineScript), exchange-specific mechanics (liquidation engines, insurance funds, auto-deleveraging), and market impact from your own orders (irrelevant for small accounts, significant for larger ones). With realistic commission and slippage settings, a non-repainting PineScript strategy can approximate live performance within 10-20% for liquid assets like BTC and ETH on timeframes of 1H or above. For illiquid altcoins or sub-1H timeframes, the approximation degrades significantly. This is why professional traders use PineScript for rapid prototyping but validate in Python or a platform like Thrive's Workbench before going live.
strategy.entry() manages a named position. It tracks the position state, allows pyramiding control, and works with strategy.exit() for stop-loss and take-profit orders. If you call strategy.entry("Long", strategy.long) when you are already in a long position with pyramiding = 0, nothing happens — it does not add to the position. strategy.order() is a raw order that does not manage position state. It fills regardless of existing positions and does not interact with strategy.exit(). For most strategy scripts, use strategy.entry() and strategy.exit() exclusively. Use strategy.order() only when you need manual position management — for example, a custom trailing stop that adjusts the stop order on every bar. The distinction matters because strategy.order() can create unintended position flips (going from long to short in a single bar) if you are not careful with the quantity and direction parameters.
The minimum depends on your strategy's win rate and return distribution. As a general rule: 200+ trades at 95% confidence for strategies with win rates near 50-55%. Fewer trades are needed at higher win rates (100+ at 60% win rate) and more are needed at lower win rates (500+ at 52% win rate). But trade count alone is insufficient — you also need the trades distributed across multiple market regimes (bull, bear, sideways, high-vol, low-vol). A strategy with 300 trades all during a bull market tells you nothing about bear market performance. The sample size article covers the mathematics in depth, including how to calculate the exact sample size needed for your specific edge parameters.
PineScript can access some on-chain data through TradingView's data feeds, but coverage is limited. TradingView provides some on-chain metrics for major chains (like BTC active addresses through certain ticker symbols), but the depth and breadth of on-chain data available does not match dedicated on-chain platforms. For strategies that require funding rates, open interest, exchange flows, whale tracking, or smart money analysis, you need external data sources. The workaround is to use PineScript for the technical analysis component and pair it with an external platform for on-chain signals. TradingView's webhook alerts can trigger based on technical conditions, while your execution layer incorporates on-chain filters. Alternatively, the Thrive platform combines on-chain data, derivatives metrics, and technical analysis in a single environment — eliminating the need to stitch together multiple tools. The crypto trading signals guide covers how to combine signal sources effectively.
Pine Script v6. Always use the latest version for new work. v6 introduced methods, improved type system, better request.security() behavior (lookahead off by default), enhanced strategy.* functions, and numerous quality-of-life improvements. Older scripts written in v3-v5 may have repainting issues baked into their request.security() calls because earlier versions defaulted to lookahead = barmerge.lookahead_on. When converting old scripts to v6, audit every security() call (now request.security()) for lookahead behavior. The migration is straightforward for simple scripts but requires careful testing for complex multi-timeframe strategies. TradingView provides a migration guide, but the most important change is verifying that your v6 conversion produces identical signals to the original — any difference in signal generation during conversion likely means the original was repainting and you were getting artificially good results.
PineScript does not natively support running multiple strategies simultaneously on the same chart. Each strategy() declaration is one strategy. To combine strategies, you have three options. First, ensemble signals within a single script: calculate signals from multiple sub-strategies and enter only when a majority (or a specific combination) agree. This is the simplest approach and works well for 2-3 sub-strategies. Second, run strategies on separate charts and combine alerts: each strategy sends alerts to an external system that manages position sizing across the portfolio. Third, graduate to Python where portfolio-level backtesting is native — frameworks like vectorbt can run thousands of strategies across hundreds of assets simultaneously. For crypto risk management at the portfolio level, the Python approach is necessary because PineScript cannot model correlation between positions, aggregate exposure, or portfolio-level drawdown. The systematic vs. discretionary trading article discusses when combining strategies adds value versus adding complexity.
PineScript is a prototyping tool, not a production platform. Used correctly — with realistic cost modeling, repainting prevention, proper position sizing, and statistical validation — it accelerates strategy development by an order of magnitude. Used incorrectly, it produces convincing backtests that lose money in live markets.
The workflow that works: formulate a hypothesis based on market structure understanding. Code the hypothesis in PineScript v6 using the non-repainting template. Run it across multiple symbols and timeframes with realistic commissions and slippage. Build a monthly performance table. Run walk-forward analysis. Compute the t-statistic. If the strategy survives all of these tests, graduate it to Python or the Thrive Data Workbench for production-grade validation with Monte Carlo simulation and regime-segmented testing.
The strategies that survive this gauntlet are rare. That is the point. You want rare. You want the strategy that passed every test, not the one that looked good on a single chart. The market will find every weakness in your backtest. Your job is to find those weaknesses first.
Start with the templates in this guide. Modify the entry logic to match your trading thesis. Keep the risk management, position sizing, and validation framework intact. Those are the parts that separate professional quantitative analysis from amateur chart pattern gambling.
Your edge exists somewhere in the intersection of your market knowledge, rigorous testing, and disciplined execution. PineScript helps you find it. Statistics help you prove it. Capital allocation helps you profit from it. None of those steps are optional.
Build your first strategy today with the Thrive platform — access on-chain data, derivatives metrics, and institutional-grade backtesting tools in one place. Or start with the Thrive Academy to build the market knowledge that generates strategy hypotheses worth testing.
![PineScript Strategy Backtesting: Build, Test, and Validate a Crypto Trading Edge [2026]](/_next/image?url=%2Fblog-images%2Ffeatured_pinescript_strategy_backtesting_crypto_guide_1200x675.png&w=3840&q=75&dpl=dpl_Cczq4cjzmxhQmkRTUv7fvH7UTi6e)