--- title: "Okala 80/20 Trading Strategy: Rules & TradingView Backtest" slug: okala-80-20-strategy-pine-script date: 2026-09-24 modified: 2026-09-24 author: Bhavishya Goyal excerpt: "" meta_description: "We test an independent Okala 80/20 strategy adaptation on TradingView. See the Pine rules, actual NQ backtest results, trade examples and demo workflow." focus_keyword: Okala 80/20 strategy canonical_url: "https://blog.pickmytrade.io/okala-80-20-strategy-pine-script/" og_title: "Okala 80/20 Trading Strategy: Rules & TradingView Backtest" og_description: "We test an independent Okala 80/20 strategy adaptation on TradingView. See the Pine rules, actual NQ backtest results, trade examples and demo workflow." og_image: "https://blog.pickmytrade.io/wp-content/uploads/2026/09/okala-80-20-strategy-hero-1024x576.avif" schema_type: FAQPage categories: - Futures - TradingView tags: [] reading_time: 20 word_count: 4868 robots: "index, follow" lang: en-US --- # Okala 80/20 Trading Strategy: Rules & TradingView Backtest ![AI editorial portrait illustration of Okala beside the title Okala 80/20 Strategy on a white, blue and purple background.](https://blog.pickmytrade.io/wp-content/uploads/2026/09/okala-80-20-strategy-hero.avif)AI-generated editorial illustration of Okala. Independent educational analysis; no endorsement implied. *AI-generated editorial illustration of Okala. Independent educational analysis; no endorsement implied.* What happens when you turn parts of the **Okala 80/20 strategy** into explicit trading rules and run them through TradingView? We built an independent Pine Script adaptation and inspected its simulated NQ trades. This case study shows what we tested, how it performed and what the numbers can actually tell us. Table of Contents 1. [How does the Okala 80/20 strategy work?](https://blog.pickmytrade.io/#how-does-the-okala-80-20-strategy-work) 2. [What do the 20 and 80 levels mean?](https://blog.pickmytrade.io/#what-do-the-20-and-80-levels-mean) 3. [Is there an Okala Pine Script already?](https://blog.pickmytrade.io/#is-there-an-okala-pine-script-already) 4. [What exactly did we test?](https://blog.pickmytrade.io/#what-exactly-did-we-test) 5. [Why the timeframe and entry timing still differ](https://blog.pickmytrade.io/#why-the-timeframe-and-entry-timing-still-differ) 6. [How cross-section retest entries are defined](https://blog.pickmytrade.io/#how-cross-section-retest-entries-are-defined) 7. [How the Fork adaptation is defined](https://blog.pickmytrade.io/#how-the-fork-adaptation-is-defined) 8. [How did our adaptation perform on TradingView?](https://blog.pickmytrade.io/#how-did-our-adaptation-perform-on-tradingview) 9. [Inside the backtest: the actual entries](https://blog.pickmytrade.io/#inside-the-backtest-the-actual-entries) 10. [Why did the test produce so few trades?](https://blog.pickmytrade.io/#why-did-the-test-produce-so-few-trades) 11. [What would make the evidence stronger?](https://blog.pickmytrade.io/#what-would-make-the-evidence-stronger) 12. [Worked example: a hypothetical Fork near 25,020](https://blog.pickmytrade.io/#worked-example-a-hypothetical-fork-near-25020) 13. [How to reproduce and extend the TradingView test](https://blog.pickmytrade.io/#how-to-reproduce-and-extend-the-tradingview-test) 14. [Next step: a separate Tradovate demo execution test](https://blog.pickmytrade.io/#next-step-a-separate-tradovate-demo-execution-test) 15. [Frequently asked questions](https://blog.pickmytrade.io/#frequently-asked-questions) 16. [What this TradingView test tells us](https://blog.pickmytrade.io/#what-this-tradingview-test-tells-us) **What this test covers:** our V4 cross-section retest rules and a confirmed-candle Fork adaptation. It does not reproduce Okala’s full discretionary method, his 200-second execution or his personal trading performance. Every recorded entry in these samples came from the cross-section rules; no Fork qualified. **Results at a glance — updated 25 September 2026:** the three-minute baseline returned −$860 from two entries. The five-minute comparison returned +$120 from two entries; removing its 20/80 proximity filter produced ten entries and −$935. All figures include the modeled costs. The samples are small and do not establish an edge. Below, we explain the settings, inspect the trades and outline a separate demo execution test. > **What you will learn from this test** > > > > > > > > - The Okala 80/20 strategy pairs Nasdaq price levels ending in 20 or 80 with Fork and H setups. Here 80/20 means those price endings, not an 80% win rate. > - Public TradingView scripts exist for the method, but we found no verified open-source Strategy Tester version. We wrote an independent Pine Script adaptation, which is not Okala’s official script. > - How to read net profit, drawdown and entry counts together. Four partial-exit rows can represent only two trading decisions, and a positive two-entry result is not enough to validate a strategy. > - How a later Tradovate demo test through PickMyTrade could check order handling separately from strategy performance. That general route is documented; this script has not completed that test. ## How does the Okala 80/20 strategy work? {#how-does-the-okala-80-20-strategy-work} Okala’s own website identifies him as the founder of 8020 Trading Pit and names Fork, Cross Section, h Pattern and Repairs as components of the 8020 Liquidity Code. It associates these setups with 80/20 price levels. [Okala’s official profile](https://8020tradingpit.com/okala) The attention-grabbing story is the reported payout total. His website claims more than $5 million in prop-firm payouts, including trading from a phone. That is a statement from the business promoting the method; we did not obtain an independent account audit. It does not establish what another trader, or our code, will earn. [Official About page](https://8020tradingpit.com/about) Even the creator’s course listing says the material alone will not make a buyer profitable. Treat the method as something to study and evaluate, rather than a shortcut to a payout. [Official course listing](https://whop.com/8020/8020-pdf/) ### What do the 20 and 80 levels mean? {#what-do-the-20-and-80-levels-mean} The public explanation refers to price endings, not an 80% win rate or an RSI setting. Examples are 25,020, 25,080 and 25,120. TradeZella’s interview companion describes a Fork as a failed push lower followed by recovery, an H as bearish continuation after a weak bounce, a Cross-Section as entry refinement, and a Repair as a potential revisit area. [Public method summary](https://www.tradezella.com/strategies/80-20-nasdaq-strategy) A useful arithmetic detail: the gap between 25,020 and 25,080 is **60 points**; the gap from 25,080 to 25,120 is **40 points**. A script that draws a line every 20 points is implementing a different grid. Marking a location is only the first step. You still need to decide what reaction qualifies, when to enter, where to exit and when to stand aside. Calling a level a liquidity area does not, by itself, prove the presence of particular orders or a predictable reaction. ## Is there an Okala Pine Script already? {#is-there-an-okala-pine-script-already} There are public scripts associated with the method. Their names do not tell you whether they can run a backtest. | Public listing | What we could verify | What it does not establish | | --- | --- | --- | | 8020 System Indicator by lucymatos | The listing labels it open source and describes level and pattern annotations. | We inspected its public description and source tab, but did not verify an official Okala algorithm or a Strategy Tester implementation. | | Okala 8020 Strategy – NQ Scalper v3 by pevide | TradingView identifies it as a protected indicator. | “Strategy” in the title does not mean editable source or a verified backtest. | See the [8020 System Indicator listing](https://www.tradingview.com/script/2ApM2DO5-8020-System-Indicator/) and the [protected NQ Scalper listing](https://www.tradingview.com/script/nx9PasYg-Okala-8020-Strategy-NQ-Scalper-v3/). Our search did not locate a suitable, verified open-source strategy to reuse. We therefore wrote an original **mechanical adaptation**. It uses a Pine `strategy()` declaration and explicit simulated entry and exit orders. No third-party Pine source was copied. ## What exactly did we test? {#what-exactly-did-we-test} We used `okala-8020-source-retest-v4.pine`, an independent research implementation. The settings below define our experiment. They include assumptions where the public explanations leave room for trader judgment. The complete tested source appears later so you can inspect and reproduce the rules. The revision follows the [original H and cross-section explanation](https://www.youtube.com/watch?v=jsUTbjwpFVk&t=1397s) and [later Fork demonstration](https://www.youtube.com/watch?v=FqevvpZW6y4&t=335s). In these explanations, an H describes structure; the example entry waits for a cross-section retest. V4 removes the earlier automatic H-breakdown short. Repairs can be targets or entry references; they are not automated here. ![Three cards connect 20 and 80 levels with Fork or H patterns and an independent Pine strategy.](https://blog.pickmytrade.io/wp-content/uploads/2026/09/okala-80-20-rules-workflow.avif) The implementation is an independent mechanical adaptation, not an official Okala script. *The implementation is an independent mechanical adaptation, not an official Okala script.* The illustration summarizes the concepts. The numerical implementation below is independent research; an H label in a diagram does not mean the script reproduces every H setup. | Component | V4 implementation | | --- | --- | | Instrument and chart | NQ or MNQ, standard three-minute candles by default; not 200-second execution | | Cross-section entry | Two strong same-direction candles define a junction; place a limit for a subsequent retest within five bars | | Level confluence | The junction must be within two points of a 20/80 level by default | | Fork long | Consecutive selloff, middle lower-low rejection and third-candle failed break; confirmation at bar close | | Position and exits | Two contracts: one at +15 points, one runner; 10-point initial stop | | Runner | After an actual TP1 fill is observed at bar close, ratchet the stop to entry or beyond the completed candle extreme | | Windows and cap | 09:30–11:30 and 15:00–16:00 New York; three entries/day. These exact controls are our test choices | | Simulation | Initial capital $100,000; 5% margin; $2.50/contract/side; two-tick slippage; one-tick limit penetration | | Omissions | No full H classification, 10-minute structural judgment, repair logic, dynamic scaling or verified broker automation | ### Why the timeframe and entry timing still differ {#why-the-timeframe-and-entry-timing-still-differ} Okala describes 10-minute context and 200-second execution. He explicitly distinguishes three minutes from 200 seconds in the [later interview](https://www.youtube.com/watch?v=FqevvpZW6y4&t=270s). Pine’s native seconds multipliers do not include 200 seconds. V4 therefore uses a clearly labelled three-minute adaptation. Changing candle duration changes the patterns and fills. [Pine timeframe specification](https://www.tradingview.com/pine-script-docs/concepts/timeframes/) ### How cross-section retest entries are defined {#how-cross-section-retest-entries-are-defined} Each of two same-direction candles must have a body of at least 10 points and at least 60% of its range. The first close and second open must be within 0.5 point; the first close defines the tick-rounded junction. By default, it must be within two points of a 20/80 level. These numerical thresholds are our assumptions, not verified creator parameters. The limit order is submitted only after the second candle closes. Only a later bar can fill it, with one tick of penetration required in this test. It expires after five following bars or at the window boundary. The script retains one pending setup at a time. Disabling the confluence switch is a diagnostic comparison, not the published default. ### How the Fork adaptation is defined {#how-the-fork-adaptation-is-defined} Candle A closes bearish. B makes a lower low than A, with at least 45% lower wick and no more than 45% body. Its lower wick must interact with a 20/80 level. C stays strictly above B’s low, approaches within two points, and closes bullish above B’s close. An equal low fails V4. The signal-close 10-point stop must also fit below B’s low with one tick of room. The code submits a market order after C closes. Okala can enter while that candle develops, so this is a material approximation. Next-open gaps can still alter the actual risk. No Fork entry passed all V4 conditions in the samples reported below; the historical results shown are cross-section trades. ## How did our adaptation perform on TradingView? {#how-did-our-adaptation-perform-on-tradingview} | Test | History | Entries / exit rows | Net after modeled costs | | --- | --- | --- | --- | | 3m default; confluence on | Sep 7–24, 2026 | 2 / 4 | −$860 | | 5m comparison; confluence on | Aug 31–Sep 24, 2026 | 2 / 4 | +$120 | | 5m diagnostic; confluence off | Aug 31–Sep 24, 2026 | 10 / 20 | −$935 | These are observed TradingView results on standard CME_MINI_DL:NQ1! candles with ETH data and the simulation settings above, without Bar Magnifier. Partial exits are separate rows: four reported trades here represent only two entries. The default maximum drawdown was $860. The five-minute comparison’s drawdown was $430; the diagnostic’s was $1,460. The intervals have different candle construction and loaded histories, so this is not proof of timeframe superiority. During validation, the initial two-contract test could not fund entries with $50,000 capital and 5% margin. At NQ 30,000, the modeled margin is 2 × 30,000 × $20 × 5% = $60,000. V4 uses $100,000 simulated capital to accommodate that model. This is a simulation correction, not a statement of current broker margin requirements. The earlier V3 one-contract test lost $350 across four entries; its sizing differs from V4. **Conclusion of testing:** V4 compiles and executes, but the default sample loses money and the two-entry positive comparison is too small to validate an edge. Bar-close timing, discretionary market context and missing repairs remain gaps. These results must not be attributed to Okala’s own trading performance. ## Inside the backtest: the actual entries {#inside-the-backtest-the-actual-entries} The table below includes every entry from the baseline and the five-minute comparison. Dates and entry times are in **New York time**; the saved TradingView captures display India time. Each entry used two NQ contracts. These are broker-emulator fills, not live trades. | Run / entry time (New York) | Direction and entry | Recorded exits | Net after costs | | --- | --- | --- | --- | | 3m · Sep 9, 2026 · 10:27 | Short at 29,518.75 | Both contracts stopped at 29,529.25 | −$430 | | 3m · Sep 21, 2026 · 15:48 | Long at 30,819.25 | Both contracts stopped at 30,808.75 | −$430 | | 5m · Sep 22, 2026 · 15:40 | Long at 31,020.75 | One at 31,035.75; runner at 31,033.75 | +$550 | | 5m · Sep 24, 2026 · 10:10 | Long at 30,578.75 | Both contracts stopped at 30,568.25 | −$430 | For the first short, the 10.5-point adverse move cost $210 per contract at NQ’s $20 point value. Adding $5 round-trip commission gives a $215 loss per contract, or **$430 for the entry**. The simulated fill already includes the applicable slippage; adding it again would double-count it. Both baseline entries stopped within their entry bars under the emulator’s assumptions. The five-minute winner closed its first contract for $295 net and its runner for $255 net. That $550 gain minus the other entry’s $430 loss explains the **+$120 comparison total**. Showing only the winner would give an incomplete picture. ### Why did the test produce so few trades? {#why-did-the-test-produce-so-few-trades} In the three-minute baseline, the script submitted four cross-section limit setups: two filled and two expired. No Fork passed all the programmed conditions. Requiring a strong two-candle junction near a 20/80 level, followed by a qualifying retest inside the allowed window, restricts entries. A setup count is not a filled-trade count. In the five-minute diagnostic, disabling _confluence_—the requirement that the junction sit near a 20/80 level—increased entries to ten, but the result was −$935. That comparison changes a core rule. It neither validates the original method nor shows that more trades make a system better. ### What would make the evidence stronger? {#what-would-make-the-evidence-stronger} Two entries cannot answer whether a strategy has a durable advantage. These runs also use different candle construction and loaded histories. Before comparing timeframes, use a common date window and consistent settings. Then evaluate rules fixed in advance on a separate period, inspect both accepted and rejected setups, and report costs, drawdown and trade count alongside profit. This larger evaluation has not been completed. ## Worked example: a hypothetical Fork near 25,020 {#worked-example-a-hypothetical-fork-near-25020} These are invented teaching candles, not a captured trade or evidence of profitability. | Candle | Open | High | Low | Close | | --- | --- | --- | --- | --- | | A | 25,040 | 25,042 | 25,025 | 25,027 | | B | 25,026 | 25,028 | 25,020 | 25,025 | | C | 25,024 | 25,029 | 25,020.50 | 25,028 | B’s lower wick is five of its eight range points (62.5%), and its body is one point (12.5%). B undercuts A; C stays above B and closes bullish above B’s close. At C’s 25,028 close, the required room to B’s low plus one tick is 8.25 points, within the 10-point stop budget. Session, pending-order and daily-cap conditions must also pass. If the next bar opens at 25,028.50 and receives two ticks of slippage, the hypothetical fill is 25,029. The initial stop is 25,019 and TP1 is 25,044 for one of two contracts. The other contract starts with the same stop; only after an actual TP1 fill is observed at bar close does its breakeven/trailing logic activate. A price-level breakeven exit can still lose money after costs. Different next-open prices change this example. This example illustrates the code contract, not the creator’s intrabar execution. NQ is $20 per index point and MNQ is $2, with a 0.25-point tick. [CME NQ specifications](https://www.cmegroup.com/markets/equities/nasdaq/e-mini-nasdaq-100.contractSpecs.html), [CME MNQ specifications](https://www.cmegroup.com/markets/equities/nasdaq/micro-e-mini-nasdaq-100.contractSpecs.html). ## How to reproduce and extend the TradingView test {#how-to-reproduce-and-extend-the-tradingview-test} **Reproduce our V4 experiment:** open the code below and copy it into a new TradingView Pine Editor strategy. This is the version used for the reported results and supersedes the earlier download. **The default test lost $860; this is research code, not a validated profitable system.** ### Open the complete V4 Pine Script (click to expand) ``` //@version=6 // Independent PickMyTrade research implementation, 2026-09-24. // Primary references and exact gaps: V4-SOURCE-AUDIT.md. // Not official Okala code. 3m is NOT 200s. No profitability claim. // No third-party Pine source copied. Numeric pattern thresholds are assumptions. strategy("Okala 80/20 - Source Retest V4 ", shorttitle="8020 V4", overlay=true, pyramiding=0, initial_capital=100000, default_qty_type=strategy.fixed, default_qty_value=2, commission_type=strategy.commission.cash_per_contract, commission_value=2.5, slippage=2, backtest_fill_limits_assumption=1, margin_long=5, margin_short=5, calc_on_every_tick=false, calc_on_order_fills=false, process_orders_on_close=false, max_lines_count=30) string GM = "Research definitions - not official numerical rules" string GT = "Chart and entry windows - New York" string GR = "Demo order management" string TZ = "America/New_York" string chartTF = input.timeframe("3", "Required chart timeframe (3m is an adaptation)", group=GT) string morning = input.session("0930-1130", "Morning window (end is our assumption)", group=GT) bool afternoon = input.bool(true, "Include last New York hour", group=GT) bool useDates = input.bool(false, "Restrict dates", group=GT) int fromDate = input.time(timestamp("01 Jan 2025 00:00 +0000"), "From", group=GT) int toDate = input.time(timestamp("01 Jan 2030 00:00 +0000"), "To exclusive", group=GT) bool enableXS = input.bool(true, "Cross-section first-retest limit entries", group=GM) bool requireLevel = input.bool(true, "Require 20/80 confluence (off = diagnostic only)", group=GM) bool enableFork = input.bool(true, "Fork confirmed-bar adaptation", group=GM, tooltip="Original enters while third candle develops. This version confirms it at close, then enters next bar: a material timing difference.") float levelTol = input.float(2, "Cross-section / 20-80 confluence distance (points)", minval=0, step=0.25, group=GM) float bodyRatio = input.float(0.6, "Cross-section minimum body/range", minval=0.1, maxval=1, step=0.05, group=GM) float minBody = input.float(10, "Cross-section minimum body (points)", minval=0.25, step=0.25, group=GM) float junctionTol = input.float(0.5, "Maximum close/open junction gap (points)", minval=0, step=0.25, group=GM) int pendingBars = input.int(5, "Limit lifetime in following bars", minval=1, maxval=30, group=GM) float wickRatio = input.float(0.45, "Fork middle lower-wick/range minimum", minval=0.1, maxval=0.9, step=0.05, group=GM) float forkBody = input.float(0.45, "Fork middle body/range maximum", minval=0.1, maxval=0.9, step=0.05, group=GM) float forkRetest = input.float(2, "Fork third-candle low retest distance", minval=0.25, step=0.25, group=GM) bool splitExit = input.bool(true, "Two contracts: one at TP1, one runner", group=GR) float stopPoints = input.float(10, "Initial stop (points)", minval=0.25, step=0.25, group=GR) float tpPoints = input.float(15, "TP1 (points)", minval=0.25, step=0.25, group=GR) int maxTrades = input.int(3, "Daily entry cap (our demo safeguard)", minval=1, maxval=100, group=GR) if barstate.isfirst if not chart.is_standard or not timeframe.isintraday or timeframe.in_seconds() != timeframe.in_seconds(chartTF) or timeframe.in_seconds() >= 600 runtime.error("Use standard intraday candles below 10m and match Required chart timeframe. 3m does not reproduce 200s.") if syminfo.type != "futures" or not (syminfo.root == "NQ" or syminfo.root == "MNQ") runtime.error("This research version requires NQ or MNQ futures.") if useDates and fromDate >= toDate runtime.error("From must precede To.") f_nearest(float p) => float b = math.floor(p / 100) * 100 float answer = b - 20 for k = 0 to 2 float candidate = k == 0 ? b + 20 : k == 1 ? b + 80 : b + 120 if math.abs(candidate - p) float b = math.floor(p / 100) * 100 p >= b + 80 ? b + 80 : p >= b + 20 ? b + 20 : b - 20 bool am = not na(time(timeframe.period, morning + ":23456", TZ)) bool pm = afternoon and not na(time(timeframe.period, "1500-1600:23456", TZ)) bool nextAM = not na(time(timeframe.period, morning + ":23456", TZ, bars_back=-1)) bool nextPM = afternoon and not na(time(timeframe.period, "1500-1600:23456", TZ, bars_back=-1)) bool window = am or pm bool submitWindow = (am and nextAM) or (pm and nextPM) bool datesOK = not useDates or (time >= fromDate and time_close nz(strategy.closedtrades[1]) bool newlyFilled = strategy.opentrades > nz(strategy.opentrades[1]) or (justExited and strategy.position_size[1] == 0) if newlyFilled entriesToday += 1 float body = math.abs(close - open) float span = high - low bool strong = span > 0 and body >= minBody and body / span >= bodyRatio float junction = math.round_to_mintick(close[1]) bool joined = math.abs(open - close[1]) <= junctionTol bool confluence = not requireLevel or math.abs(junction - f_nearest(junction)) open and close[1] > open[1] and joined and confluence bool xsShort = strong and strong[1] and close < open and close[1] 0 and math.min(open[1], close[1]) - low[1] >= span[1] * wickRatio and body[1] <= span[1] * forkBody bool fork = close[2] < open[2] and low[1] low[1] and low open and close > close[1] and low[1] <= support + levelTol // Skip a late confirmed entry if even its SIGNAL-close stop would sit above the low. // Next-open gaps can still alter the actual fill. This is not an intrabar entry model. bool forkRiskOK = close - low[1] + syminfo.mintick = pendingBars or entriesToday >= maxTrades) strategy.cancel_all() pendingDir := 0 cancelled += 1 if strategy.position_size == 0 runnerStop := na runnerActive := false if strategy.position_size == 0 and pendingDir == 0 and not justExited and submitWindow and datesOK and entriesToday 0 int last = strategy.closedtrades - 1 string exitID = strategy.closedtrades.exit_id(last) bool sameEntry = strategy.closedtrades.entry_time(last) == strategy.opentrades.entry_time(0) bool targetFill = strategy.position_size > 0 ? strategy.closedtrades.exit_price(last) >= strategy.position_avg_price + tpTicks * syminfo.mintick : strategy.closedtrades.exit_price(last) 0 ? math.max(strategy.position_avg_price, low - syminfo.mintick) : math.min(strategy.position_avg_price, high + syminfo.mintick) runnerStop := na(runnerStop) ? candidate : strategy.position_size > 0 ? math.max(runnerStop, candidate) : math.min(runnerStop, candidate) if strategy.position_size > 0 strategy.exit("L-RUN", "L", qty=1, stop=runnerStop, alert_message="RESEARCH_LONG_RUNNER_EXIT") else strategy.exit("S-RUN", "S", qty=1, stop=runnerStop, alert_message="RESEARCH_SHORT_RUNNER_EXIT") if not submitWindow or not datesOK or newDay strategy.cancel_all() pendingDir := 0 if strategy.position_size != 0 strategy.close_all(comment="Research window end", immediately=true, alert_message="RESEARCH_TIME_EXIT") plot(pendingDir != 0 ? pendingLevel : na, "Pending cross-section", color=color.orange, style=plot.style_linebr) plot(runnerActive ? runnerStop : na, "Runner stop", color=color.red, style=plot.style_linebr) plotshape(takeFork, title="Confirmed Fork submission", style=shape.triangleup, location=location.belowbar, color=color.teal, text="F") plot(longSetups, "XS long limit submissions", display=display.data_window + display.status_line) plot(shortSetups, "XS short limit submissions", display=display.data_window + display.status_line) plot(forkSetups, "Confirmed Fork submissions", display=display.data_window + display.status_line) plot(cancelled, "Unfilled limits cancelled", display=display.data_window + display.status_line) var table info = table.new(position.top_right, 1, 4, bgcolor=color.new(color.navy, 15)) if barstate.islast table.cell(info, 0, 0, "V4 source-based RESEARCH", text_color=color.white) table.cell(info, 0, 1, "Not official | 3m is not 200s", text_color=color.silver) table.cell(info, 0, 2, "XS retest + confirmed Fork | NO H-break entry", text_color=color.white) table.cell(info, 0, 3, splitExit ? "2 contracts; TP1 + bar-close runner" : "1 contract; full TP1 exit", text_color=color.white) ``` V4 has been compiled in TradingView; when importing your own copy, compile it in Pine Editor. Use a standard NQ or MNQ candlestick chart, set it to three minutes, and inspect every compilation or runtime message. A successful compile would establish that TradingView accepts the code; it would not establish an edge. Then run separate studies for cross-section retests and the optional Fork adaptation. V4 does not classify full H structures. Keep a record of the symbol, contract, dates, timeframe, inputs, fees and slippage. Continuous contracts are useful for exploration, but contract rolls and adjustments can affect the historical price levels being tested. Use this sequence: 1. Check individual trades against the written rules and distinguish signal time from fill time. 2. Inspect bars where both the stop and target could have traded. Lower-timeframe inspection can help reveal ambiguity. 3. Include losing periods and trades that fail immediately after entry. 4. Test parameter changes on an earlier sample, then freeze the settings before evaluating a separate later period. 5. Record expectancy after costs, drawdown, trade count and long/short results—not only the percentage of winners. TradingView strategies use a broker emulator. Default market-order fills generally occur on the next available tick; historical results depend on the available bars and simulation assumptions. Standard candles avoid the additional problems of synthetic chart prices. [TradingView strategy documentation](https://www.tradingview.com/pine-script-docs/concepts/strategies/) Our defaults include $2.50 commission per contract per side, two ticks of slippage on applicable fills and 5% simulated margin. Those are test inputs, not current broker terms. Adjust them, especially when comparing NQ with MNQ. Thirteen local code checks passed, and the source read back from TradingView matched the delivered file. All recorded trade rows were reconciled for costs, grouping and session times. These checks do not establish profitability or full fidelity to the original method. Freeze the rules before any new out-of-sample evaluation. ## Next step: a separate Tradovate demo execution test {#next-step-a-separate-tradovate-demo-execution-test} A backtest checks simulated behavior on past bars. A separate demo exercise can check whether alerts and orders match as new signals arrive. It cannot turn a losing backtest into evidence of an edge. The proposed execution test for this custom script would use: **TradingView strategy order-fill alert → PickMyTrade → Tradovate demo account.** ![TradingView strategy alerts pass through PickMyTrade to a Tradovate demo account.](https://blog.pickmytrade.io/wp-content/uploads/2026/09/okala-pickmytrade-tradovate-demo.avif) General documented demo route. This custom strategy has not completed an end-to-end broker test. *General documented demo route. This custom strategy has not completed an end-to-end broker test.* PickMyTrade documents strategy-alert setup and recommends the trade-action placeholder `{{strategy.order.action}}` in its generated configuration. Its demo guide covers connecting Tradovate in simulation mode. That verifies the general workflow, not a completed test of this particular script. [Strategy automation guide](https://docs.pickmytrade.trade/docs/automate-tradingview-strategies/), [Tradovate demo guide](https://docs.pickmytrade.trade/docs/tradovate-demo-account/) Generate the account-specific alert configuration in PickMyTrade. The script’s plain labels, such as `RESEARCH_FORK_LONG`, are diagnostic tags, not a ready-to-route webhook message. Check symbol mapping, contract quantity and the selected demo account before activating the test. Verify a two-contract entry, a one-contract TP1 exit, the remaining runner’s stop, a full stop-out and a time-window exit. Compare the TradingView event, PickMyTrade log and resulting demo position. An exit must flatten the intended quantity rather than accidentally open an opposite position. A simulated bracket in Pine is not automatically a resting broker-side stop. Decide which system manages protection and exits, and reconcile their behavior in demo. Also recreate alerts after changing script settings so the alert uses the intended configuration. [TradingView alert guidance](https://www.tradingview.com/pine-script-docs/faq/alerts/) If one alert ever creates two orders, our guide to [why a non-repainting strategy can still fire twice](https://blog.pickmytrade.io/non-repainting-strategy-still-fires-twice-heres-why/) explains where the duplicate can come from. For the session window, see [Restrict Automated Trading to RTH: Session Windows That Hold](https://blog.pickmytrade.io/restrict-automated-trading-to-rth-session-windows-that-hold/), which covers what a fixed window does when daylight saving changes. ## Frequently asked questions {#frequently-asked-questions} **Is this Okala’s official Pine Script?** No. It is an independent mechanical adaptation with documented choices. We have not verified an official, public, editable Pine strategy from Okala. **Does 80/20 mean an 80% win rate?** No. It refers to price endings. V4 has small recorded backtests, including a losing default sample; they do not establish a reliable future win rate. **Can I use three-minute candles instead of 200 seconds?** You can test our three-minute adaptation, but it is a different candle construction. Do not label its results a test of the original 200-second execution process. **Does it include Cross-Section entries or Repair targets?** V4 includes cross-section retest entries, a confirmed-bar Fork adaptation, partial profit and a bar-close breakeven/trailing runner. It does not implement repair logic or full H classification. **Can it automate a prop-firm account immediately?** No. V4 has been compiled and sampled historically, but its default test loses money and broker demo execution has not been verified. No backtest establishes compliance with a firm’s current rules, limits or drawdown calculation. **What should I do first?** Start with the source and its written rule sheet. Compare several qualifying and rejected patterns, then record a TradingView test before considering the [PickMyTrade demo execution workflow](https://docs.pickmytrade.trade/docs/tradovate-demo-account/). ## What this TradingView test tells us {#what-this-tradingview-test-tells-us} Our baseline adaptation lost money in the observed sample. The five-minute comparison was slightly positive, but just two entries cannot establish repeatable profitability. The useful result is a documented experiment: explicit rules, visible assumptions and trades we can inspect. The next research step is to check fidelity to the source method, freeze the rules and evaluate a larger, separate sample. This test does not establish whether Okala’s own discretionary trading is profitable. _**Disclaimer:** This content is for informational purposes only and does not constitute financial, investment, or trading advice. Trading and investing in financial markets involve risk, and it is possible to lose some or all of your capital. Always perform your own research and consult with a licensed financial advisor before making any trading decisions. The mention of any proprietary trading firms, brokers, does not constitute an endorsement or partnership. Ensure you understand all terms, conditions, and compliance requirements of the firms and platforms you use._ Also Checkout: [Brokers That Connect to TradingView for Automated Trading](https://blog.pickmytrade.io/brokers-that-connect-to-tradingview-for-automated-trading/) **Automate Your TradingView Strategies** Connect your alerts with [PickMyTrade](https://pickmytrade.io "PickMyTrade") — automated trade execution, no coding required. [Start free →](https://pickmytrade.io/pricing) For AI tools & developers:[View Markdown →](https://blog.pickmytrade.io/okala-80-20-strategy-pine-script.md)