10 November 2026 · TradingView Weekly. This week’s practical question is whether a familiar chart or script still means what you think it does. New data sources and market access expand what can be researched; revised creator rules and better-specified calculation settings change what needs to be recorded. The useful next step is a targeted check of freshness, access or signal timing.
TL;DR — 10 November
- Macro data: TradingView’s 9 November announcement describes a 5 November feed migration. Check the latest observation, not merely whether the symbol still loads.
- Market access: Muscat chart data and Upstox connectivity are different capabilities: research coverage versus broker execution.
- Script sellers: new terms replace the old November restriction. Plan for private-script transition dates and February seat accounting.
- Pine research: no November language release was verified. July historical-tick controls deserve a settings review, while the new Wave Effort Map illustrates why endpoint time and confirmation time must be logged separately.
This report was prepared with AI from the linked public sources. Verify the original material and test implementations independently. It is not a recommendation to buy, sell or trade any investment.
Get TradingView updates in your inbox
Follow Pine Script, screening tools and platform changes alongside MetaTrader in the shared Trading Development newsletter.
Select Trading Development in the free signup flow. Already a member? Sign in and update your email preferences. Unsubscribe anytime.
| Subject | What to check |
|---|---|
| Economic feed · 9 November | Migration continuity and observation freshness; the actual cutover was 5 November. |
| Muscat and Upstox | New Omani chart coverage and an Indian broker connection, with different checks for each. |
| Creator rules · 6 November | Private-script conversion, renewal records and future seat capacity. |
| Pine development | No newly verified language release; explicitly dated July strategy-testing context. |
| Screeners and alerts | Reproducible scan inputs and versioned running-alert configurations. |
| Community method | One author-dated 6 November tool; a proposed event-log study with no performance claim. |
| Validation | Data context, confirmation delay, session alignment, execution assumptions and costs. |
| Earlier catch-up | 5 November crypto fundamentals, absent from the prior report and labelled as earlier context. |
Platform changes: verify the data behind the interface
This edition’s platform news concerns three different capabilities: where macroeconomic observations come from, which markets can be charted, and which broker accounts can execute from the chart. Those distinctions determine what a developer should verify. A successful symbol search proves neither that its latest observation is current nor that an account can trade it.
Economic data moves to an in-house feed
TradingView’s 9 November announcement describes an economic-data feed change that took place on 5 November. The platform now obtains the data directly from publishing institutions, including statistical offices, central banks, the World Bank and IMF. TradingView says existing symbols, names, histories and saved watchlists remain intact. The Economic Calendar, Macro Maps and country views also use the replacement feed. Official TradingView announcement.
There is an important coverage boundary: some narrow series and annual indicators for smaller economies are still waiting to be connected, even though their history and symbols remain accessible. Practical interpretation: check the latest observation date, frequency and unit of a series against its original publisher before treating an unchanged chart as evidence of a fresh release. For a recurring macro workflow, retain one before-and-after observation log and distinguish revised historical values from newly published observations. The announcement is a continuity claim and coverage update, not proof that every series is current.
Muscat data adds stocks, bonds and indices
The 9 November Muscat Stock Exchange announcement adds Omani stocks, indices, government bonds and sukuk to TradingView. Examples include Bank Muscat, OQ Exploration and Production and Oman Telecommunications. Users can find the instruments through Symbol Search with the MSX: prefix. This expands charting coverage; the article does not establish an execution route through a connected broker. Official TradingView announcement.
Practical interpretation: start with a small, clearly identified watchlist and record each instrument’s currency, session and latest timestamp before comparing it with a regional benchmark. A bond price, stock price and index level answer different questions; placing them together does not make their percentage changes economically interchangeable. The release does not specify a universal delay or entitlement rule, so inspect the actual symbol’s data status rather than assume that inclusion means live, universally available data. This is a useful research expansion, without a demonstrated trading advantage.
Upstox integration connects Indian execution to Supercharts
TradingView announced the Upstox connection on 6 November. Connected clients in India can place stock, ETF, futures and options orders from Supercharts across NSE, BSE and MCX. The stated route is to open Trade, choose Upstox and sign in. The announcement quotes ₹20 per executed equity-delivery or options order; intraday and futures brokerage is ₹20 or a percentage of order value, whichever is lower, without specifying that percentage. Official TradingView announcement.
Practical interpretation: treat this as an interface integration, not an all-in cost or eligibility guarantee. Before placing an order, match exchange, contract, expiry, product type and account permissions between the chart and order ticket. Keep brokerage separate from taxes, exchange charges, slippage and data subscriptions when assessing costs. A sensible first check is a non-executing comparison of the intended chart symbol and the available order instrument. No account connection or execution was tested for this report, and the publication date does not independently establish the first day the service was available.
Boundary-day catch-up: crypto fundamentals on symbol pages
Boundary-day catch-up, announced 5 November: crypto symbol pages now group Financials, Network, Derivatives, Ownership and Social under Fundamentals, with metrics also accessible through Supercharts and the Details panel. This item was absent from the prior report, but that edition supplied no precise cutoff; it should not be relabelled as a 6–10 November launch. Official TradingView announcement.
Practical interpretation: compare like-for-like measurements. Network metrics are daily, widgets vary by coin, and an address can represent many customers of an exchange. Record the provider, interval and definition beside each figure instead of treating valuation ratios, social activity and on-chain transfers as equivalent signals. The platform explicitly frames Bitcoin valuation models as reference points rather than forecasts. More context can improve a research question without establishing a profitable prediction.
A useful migration check for a macro dashboard
Our proposed research procedure: choose three series already used in your dashboard, including one less common series. For each, record the publisher, unit, seasonal-adjustment convention, observation period, release date and last visible value. Compare that record with the original institution’s release before changing any calculation. Keep “new observation,” “revision” and “unchanged since last check” as separate outcomes.
For example, a monthly observation labelled October can be released in November. A historical model that assigns that observation to the first day of October would use information before its publication. A current chart alone cannot establish the historical information set. If a research question depends on first-release values, obtain a suitable dated release archive or mark that experiment unsupported. Do not silently substitute today’s revised series for what an earlier decision-maker could have known.
This check is deliberately small enough to repeat. If one series is stale or inconsistent, isolate that input and document the affected output instead of declaring the entire dashboard reliable because its other charts still load. The proposed check has not been executed for this report; it is a reproducibility procedure, not a finding about any particular macro series.
Script sellers: replace the old November deadline with the published rules
New announcement, 6 November 2026. TradingView says the previously announced 1 November sales restriction will not take effect. External sales can continue alongside Marketplace sales. Its current Marketplace fee is 0%; that is a current rate, not a permanent guarantee. The announced access-management API is planned for the end of December, so it should not be treated as a currently verified integration. Read the new-terms announcement rather than relying on the October clarification covered in the previous edition.
The current invite-only rules set out the operational dates and limits:
- 15 November 2026: conversion of private invite-only scripts to public scripts becomes available.
- 1 December 2026: a private script with more than five users cannot add users or publish updates until converted or reduced to five users or fewer.
- 1 February 2027: seat accounting begins. Premium or higher includes 100 seats; extensions add 100 for USD 300 per month plus applicable taxes.
- One person uses one seat per author account across that author’s scripts. Marketplace purchases do not use seats. Access granted before 1 February 2027 is exempt until extended or another script is added on or after that date. Reaching capacity prevents new grants or extensions; it does not remove existing access.
Practical implication: a small script business needs an access inventory before it needs a new payment integration. Keep script visibility, active users, expiry dates and intended renewals in separate fields. Estimate future seat demand from grants and renewals that actually trigger it, not from the total lifetime customer count. Review private-script conversion with the people maintaining the code, because an update restriction can affect support work as well as sales.
Public invite-only does not mean open-source. It describes a publicly listed script whose use requires permission; code availability is a separate question, as the script-selling FAQ explains. A protected publication hides its implementation, while an open-source publication permits inspection subject to its licence. For any purchased tool, ask what behavior can be checked without relying solely on a vendor’s backtest or screenshot. Consult the applicable Terms of Use and current rules for your arrangement; this is a dated product-policy summary.
Pine development: no verified November language release
At this edition’s cutoff, the official Pine release log still ends at October 2026. We found no November language release to announce. October’s input alignment and September’s table-panel changes were covered previously and are not repeated as new launches.
Earlier context, July 2026: the same log documents calc_on_every_history_tick, available on standard charts for Premium and Ultimate users. It allows calculations at available historical ticks, with price and volume values progressing to approximate the developing bar. July also introduced the “Bar detalization” menu in place of the former Bar Magnifier control. These are useful maintenance details for anyone reproducing an older strategy tutorial, but they are not changes first released this week.
The current strategy documentation makes the limitation important: historical tick execution does not eliminate repainting, and its information depends on the selected historical detail. In particular, barstate.isconfirmed remains true on historical bars even during those intrabar executions. An extra calculation after an order fill can also expose final historical-bar values before a comparable live decision could know them. More detailed simulation is not a guarantee of identical live behavior.
Review behavior before comparing performance
Our suggested maintenance exercise: take one existing, documented strategy and freeze its code and inputs. Keep one run with the original calculation settings. In a separate run change only historical tick execution, then compare the first ten trades where entry time, exit time or trade count differs. For each difference, write down which input became available and which setting allowed the calculation. Do not begin by choosing the run with the higher return.
If a result changes, classify the reason as signal timing, fill assumption, data coverage or a code defect. A change in simulated profit without an explanation of the changed events is a warning to investigate, not evidence that a new setting improved the underlying idea. Keep the rejected version and its settings in the research record. This proposed exercise has not been run here and produces no performance claim.
Keep improving your TradingView workflow
Get the next research edition with concrete platform changes, source links and limits worth testing. TradingView and MetaTrader share the Trading Development newsletter.
Select Trading Development in the free signup flow. Already a member? Sign in and update your email preferences. Unsubscribe anytime.
Screeners and alerts: keep the research state reproducible
No new screener or alert release was verified in the checked official category feeds. The current Pine Screener requirements still specify one indicator, a 500-bar calculation window and up to 40 separate data requests. A usable filter needs a supported plot or alert condition. Unsupported timeframe, symbol and time inputs use their script defaults. Changing the source, indicator, inputs, timeframe or filters requires a rescan. These constraints are current documentation, not a new November release.
Development implication: save the effective scan configuration beside the shortlist. Record which universe was selected and when it was scanned; distinguish an empty result from an invalid or incomplete scan. For a small control set, include a symbol expected to pass, one expected to fail and one with insufficient history. Resolve chart-versus-screener disagreements before interpreting differences as market events. A screen is a selection process; without entry, exit and position rules it is not a trading system.
The alerts documentation explains a different persistence rule. A running alert retains a snapshot of its script, inputs, main symbol and timeframe from creation. Later chart or code edits do not update that instance. Pine code defines possible events; it does not itself create the running alert. Events occur on realtime bars. Waiting for bar close can avoid some transient triggers, but does not repair every higher-timeframe or retrospective-plotting issue.
Suggested release record: give a research alert a human-readable version and record its symbol, timeframe, input values, intended event and creation time. When changing logic, deliberately retire and recreate the relevant alert through the normal interface, then record the first observed event. Preserve the old record so a message received later can be traced to the version that generated it. This is an operational checklist; no alerts, accounts or orders were changed for this edition.
Community method: Wave Effort Map and the time of confirmation
Author-dated 6 November 2026. Auction Foundry’s Wave Effort Map manual compares finalized waves using volume, endpoint distance, time and bars. It declares MPL 2.0 open-source status; the inaccessible TradingView listing prevented independent code inspection.
The manual describes later closed-bar confirmation using ATR stored at the extreme, followed by retrospective drawing. Developing legs are excluded. Volume is not signed order flow; missing volume remains unavailable, and elapsed time includes gaps. These are author descriptions, not independently tested behavior or evidence of a trading edge.
Proposed evaluation: treat the first observed confirmation as time zero, then compare consecutive observations under fixed, recorded conditions.
A fresh research exercise: compare event records, not attractive drawings
Use one instrument and a fixed observation window chosen before inspecting results. Choose standard time-based candles and record the exchange, interval, session, price-adjustment setting and available volume definition. Keep the same settings throughout the observation period. The objective is a clean event log, not a portfolio or a recommendation to trade.
- Record both times. For each newly finalized event, record its measured endpoint and the first bar close at which you observed confirmation. Keep the recorded event even if a later chart reload looks different.
- Record what was available. Save the displayed measurements, their units, the data timestamp and any missing-value status. Do not replace an unavailable volume field with zero or rank it as low activity.
- Use a simple comparison. Compare a predeclared subset, such as events with greater volume but shorter distance than the previous wave, with all eligible finalized events. Keep the definition fixed and disclose the number excluded for missing inputs.
- Start the outcome clock at observation. An illustrative evaluation could measure price change after a fixed number of subsequent completed bars. Specify that horizon before collecting observations, and keep it the same for the subset and baseline.
- Reserve a later period. Use an initial period to check that the measurements and logs work. Evaluate the unchanged rule on a separate later period. If you change it, label that a new experiment rather than merging the most favorable pieces.
Report the sample size, missing-data rate, confirmation-delay distribution and full outcome distribution before drawing a conclusion. A few memorable reversals are not an adequate comparison. Even an apparent difference between groups may reflect instrument selection, volatility conditions or overlapping observations. Record consecutive events and unsuccessful examples, not just screenshots chosen after a price move.
This proposed procedure deliberately separates a descriptive indicator from a trading test. A trade study would additionally need an executable entry time, order type, sizing, exits, simultaneous-position limits and costs. Those choices could materially change the result. No such test, source-code audit or forward-performance evaluation was performed for this report.
Validation checklist: data, sessions, timing and execution
Preserve the complete data context
The session documentation distinguishes exchange-session context from time-based session definitions; session boundaries should align with the intended chart bars. The data-request documentation also distinguishes symbol contexts and modifiers such as session and adjustment. These settings belong in the experiment record alongside the symbol name.
For a cross-market study, decide whether observations are aligned by local trading date, UTC time or the most recent completed session. Do not combine a fresh observation in one market with a stale one in another without labelling the difference. If a market is closed, “unchanged” should not automatically be interpreted as a low-volatility signal. Keep currency and contract identity explicit when comparing levels; percentage normalization does not remove differences in session length or instrument structure.
Separate three timing questions
First ask when the input existed, then when the script evaluated it, then when an actionable observation or simulated fill occurred. TradingView’s repainting discussion distinguishes ordinary open-bar updates, higher-timeframe differences, retrospective plotting and future leakage. These are different mechanisms. A “non-repainting” label is not enough to determine whether a plotted historical opportunity could have been observed at the depicted time.
For a completed higher-timeframe condition, record the source bar’s completion as well as the lower-timeframe chart bar used for the observation. For a delayed pivot or wave, retain the confirmation delay. For a current-bar condition, decide in advance whether intrabar changes are acceptable and whether the study can reproduce them. These choices should follow the research question, not the appearance of the final equity curve.
Make simulated costs and fills explicit
The official strategy reference covers commission, slippage and order-fill assumptions. Historical simulation is not broker execution. Record the actual settings used, including execution timing and the treatment of limit orders, before comparing runs.
A useful sensitivity check is to repeat an unchanged rule with less favorable cost and fill assumptions and report how many trades cease to qualify. Keep brokerage, exchange charges, tax treatment where relevant, bid/ask spread and slippage conceptually separate so they are not accidentally omitted or counted twice. A hypothetical test that ignores a meaningful cost cannot establish a practical edge. A profitable simulation under one setting also does not prove that real orders would fill in the same sequence.
Use any platform data and integrations within their applicable usage terms. The existence of alerts or broker connectivity should not be taken as blanket authorization for automated execution. This edition is educational research and makes no recommendation to connect an account or deploy a trading bot.
What to do with this week’s changes
For a macro workflow, the immediate task is to check observation freshness across the feed transition. For a script vendor, inventory access and update the transition calendar. For a Pine developer, capture the calculation settings that make a backtest reproducible. For an indicator researcher, log when a new measurement actually becomes available before testing what follows it.
Choose one of those tasks and define the evidence that would count as success. A smaller, repeatable check is more useful than simultaneously changing data feeds, script settings and selection rules and then trying to explain the result afterward. Retain the old configuration, the new configuration and the reason for the change. That record makes the next weekly review cumulative instead of a fresh round of guesswork.
Source scope and methodology
Research cutoff: 10 November 2026, 08:14:27 SAST (06:14:27 UTC). The news window begins 6 November, following the previous edition’s stated 5 November end date. That edition did not provide an exact intraday research cutoff; its source-page update timestamp is not treated as one. Platform announcement dates were checked against primary page metadata. The 9 November economic announcement describes a 5 November event. Crypto fundamentals are explicitly boundary-day catch-up, and July Pine behavior is explicitly earlier context.
We opened full official announcements, current Pine documentation, current script rules and the author’s full community manual. Category feeds were checked but are not assumed exhaustive: the accessible 6 November script-selling article was absent from one feed view. No new Pine language release, screener release or alert release was verified in the stated window. No code compilation, live chart experiment, brokerage connection, order, indicator audit or performance test is claimed. Links and facts may change after the cutoff.
Educational analysis, not investment advice. No script endorsement, personalized investment recommendation or verified return claim is made.
Forwarded this TradingView edition?
Get your own copy through Trading Development, our shared newsletter for TradingView, Pine Script, MetaTrader and MQL.
Select Trading Development in the free signup flow. Already a member? Sign in and update your email preferences. Unsubscribe anytime.