Testing communities

A single browser can only test so many combinations before the afternoon is gone. A testing community splits one parameter space across many machines. An admin publishes a campaign, members opt in to compute part of it on their own TradingView account, and the results come back into one ranked table. None of this touches your own sweeps, which keep working exactly as the main documentation describes.

What this is

The strategy itself is never uploaded. A community records only the strategy's stable identity and its display name, which is what lets two machines agree they are testing the same thing.

Where each part lives

Community actions never wait on a run. You can create, join, approve, publish and manage while an optimization run of your own is in progress, and none of it disturbs the run.

Communities and members

Creating one

Load the strategy on your chart, open the Communities tab, and press Create. You give it a name, an optional description, and a visibility:

• Open: anyone with the invite code joins immediately.
• Private: the code produces a request an admin approves or rejects. Until then the applicant sees only the name, description, visibility and strategy, never the roster and never the member count.

The community lives with your account, not with the browser it was created in, and the same strategy can carry more than one community.

Invite codes

Each community has one active code, shown as two five-character groups with a copy action.Rotate it and the old one stops working for new joins while every existing membership is untouched. Revoke it and nobody new can join at all until you issue another.

Every refusal of a code reads the same: invalid. A code that never existed, one that was revoked, one that was replaced, a community with no active code, a blocked account, an account inside its cooldown. All of them get that one answer, on purpose, so a code cannot be probed for information.

Joining

Pasting a code previews the community first: its name, description, visibility, the strategy it is built around, and a statement of what joining will show its admins about you. Nothing has joined at that point. Confirming needs the community's strategy on your chart; without it the refusal names the strategy you need. A preview is not a reservation, so a seat or a cap that was free at preview time can still refuse the confirm.

Roles

A rejected request cannot be retried for three days. A removed-and-blocked account gets the generic invalid-code answer, including against a fresh code; unblocking lets it join again as a new membership, and the old one survives as history. The sole owner cannot leave or demote itself: transfer ownership or delete the community. Deleting one ends every membership, kills its codes, and frees the slot it occupied against your cap.

History depth

A backtest is only as long as the price history the account running it can load. So the panel measures how far back your own TradingView account reaches. What it records is a bar count, the symbol and timeframe it was measured on, and the time of the reading. No plan name, no credentials, nothing else.

• It is kept current by your own actions in the Communities tab. There is no background polling.
• An upgrade takes effect immediately. A lower reading only replaces a higher one after 90 days, so measuring on a short-lived symbol cannot look like a downgrade.
• An admin sees each member's claimed tier (5,000 / 10,000 / 20,000 / 40,000 bars) on the roster, explicitly marked unverified: it is a value the member's own machine reported. A member sees their own value and nobody else's.
• It blocks nothing by itself. Creating, joining and every admin action work with no measurement at all. Its only use is as a campaign requirement.

Campaigns

From a community, choose New campaign with the community's strategy on your chart. The form refuses to open on any other strategy, and it names the one to load. The target strategy is shown read-only: a campaign cannot point somewhere else.

You define:

• The parameter space. Each input is fixed, a range, or a value set, exactly as in your own sweeps, plus the symbols and timeframes to cover. The combination count updates as you edit, and the server recomputes it from the definition rather than trusting the number the form showed.
• The history depth required, one of 5,000 / 10,000 / 20,000 / 40,000 bars, or no requirement. As you change it the form says how many active members meet it, and reports members with no measurement separately as unknown. It never names anybody.
• Who would run what. A check-on-demand tells you how many members would run the paid variant, how many the free one, and how many could not be resolved. It reads each member's plan, so it runs only when you ask for it.

You can start a campaign from a configuration you already saved locally for that strategy. The draft is prefilled from it and editing the draft leaves the source configuration untouched.

The ceilings

Each refusal names its own ceiling and your current count, so an oversized space is never a generic error. Two admins editing one draft is safe: the first save wins and the second is refused as stale, with nothing merged behind either of their backs.

Free and paid variants

Members are not on the same plan, so a campaign can carry two versions of its space. You run the one your own plan resolves to. The server resolves it again each time you open the campaign, so an upgrade takes effect on the next view with nothing to press.

• The free variant is capped at 2 swept inputs of 10 values each. That is a property of the free tier, not of whoever publishes.
• The form prefills it from the paid variant deterministically: the first swept inputs in strategy order, downsampled to the allowed number of values with the first and last kept. Ask for the prefill twice and you get the same variant.
• Delete the free variant and the campaign publishes for subscribers only. The form says so before you publish, and free members then see a named ineligible verdict with the upgrade path rather than silence.

Who sees which, and who runs which

• A free member sees and runs the free variant only. The subscriber space is beyond their plan, so it is not part of the campaign they are shown.
• A subscriber sees both spaces, because their plan covers both, and runs the subscriber one. Admins see both because they author them.
• The variant is re-resolved by the server on every slice handed out, never taken from the contributor's browser. A plan that stops covering the space a stretch was started under stops that stretch rather than quietly moving it.

Where the two spaces meet

The two variants are not nested and not multiplied: each enumerates its own space, and they meet at the identity of a single combination. That identity is every value the variant writes, its pinned values included, together with the symbol and the timeframe.

• A cell both spaces contain is computed once, by whichever member reaches it first, and one pooled row then stands for both. Nobody repeats the other's work, and the campaign's combination count is the distinct total rather than the two added up.
• Pinning a shared input differently splits the cell. If the paid variant fixes an input at 3 and the free one at 5, the two are different measurements of different configurations, so each space gets its own cell and both are computed.
• The Variant column is how you tell them apart afterwards. A campaign whose free space sits entirely inside its paid one produces exactly the same table as one whose spaces are disjoint, because a cell computed once carries no trace of the other space. Filter Variant to Free and you are looking at the cells the free members actually reached.
• Cross-checking crosses the two freely: where a cell exists in both spaces, a free member's answer is a valid second opinion on a subscriber's, and the numbers are compared the same way.

Publishing and closing

Publishing freezes the definition. The parameter space, the symbols, the timeframes and the history requirement cannot change afterwards, because rows already submitted answer the old question. The name and the description can change, and the rename is recorded. To change the space, duplicate the campaign into a new draft. Every action, from publish to delete, lands in the community's audit trail with who did it and when.

Do you qualify

Opening a published campaign resolves a verdict for you, on the spot. It is never stored and never cached, so it always reflects the chart and the account you have right now.

The symbol check is passive: it never drives your chart, never loads a symbol onto it, and never disturbs a run in progress. Symbols shared between campaigns are checked once and reused for a few minutes. In the cross-community campaign list, the ones your stored depth and plan already satisfy come first, and that ordering is marked provisional. The strict answer needs your machine, and opening the campaign is what asks it.

Contributing your machine

On an eligible campaign, the Contribute control shows the exact categories your machine will send and waits for you to accept them. That happens every time you start, not once and then silently. You can set Stop after a number of combinations, or leave it with no limit.

Once it starts:

• Work arrives in slices. The first is small, to measure how fast your machine actually is, and the next ones are sized from that. A new slice arrives with no interaction.
• You see the slice as done against total, what this stretch has completed, your total for the campaign, how much of the campaign is covered, and anything waiting to be sent.
• Nothing is handed out twice. Combinations are leased to one machine at a time. A slice you are given and do not finish returns to the pool for somebody else, and reopening a browser soon enough picks your own work back up.
• One machine per member per campaign. Starting on a second machine while the first is live is refused, naming the campaign already running.
• Closing the side panel is not a stop. The toolbar badge shows that you are contributing, and reopening the panel finds the stretch running with its Stop control live. Closing the tab or changing the chart's symbol, timeframe or strategy does stop it, and says which one moved.
• Your own pacing is honoured. If you use the anti-detection throttle, a contribution throttles the same way. A campaign cannot override it.
• Stop hands the rest back. The combination in flight is abandoned, what you finished is submitted, and the remainder returns to the pool. An abandoned combination is not recorded as a failure.

When the network drops

Rows keep being computed and written locally, and the queue of things to send grows. If the connection stays down long enough that the queue cannot drain, computing stops. The panel then says it cannot reach the community, while retries continue in the background. When you are back the queue goes out first, and if the work had already returned to the pool a fresh slice starts. None of that is an error: nothing was lost and nothing is sent twice.

If your browser cannot store results locally, contributing stops and names that as the cause, and nothing further is transmitted. The local copy is the point; there is no mode where the community gets a row your own explorer does not.

Steering the pool

An admin sees the campaign's pool in the panel:

• Covered against total, in flight, remaining, failing, unreachable, and how many members are contributing right now, plus a completed and failed count per contributor.
• A sample of what is failing, with the symbol, the timeframe and the reasons.
• Unreachable is an access gap, not a failure. When no contributor can load a symbol, the symbol is named, and the campaign can report itself done as far as it can go while saying those combinations were never computed by anyone.
• Reclaim work in flight returns everything handed out and unfinished to the pool. Finished work is kept, and the contributors keep running and pick up new work at their next check-in, within two minutes. Pausing the campaign reaches everybody in the same two minutes.

Cross-checking

A campaign can ask a second contributor to recompute a share of its combinations. The share is set in basis points, where 10000 is every combination, and it can be changed at any time, including mid-run. A change applies only to combinations nobody has covered yet, so raising it never reopens settled work.

The pool shows the achieved share next to the target, because a mid-run change and a stopped partner both make them differ. A combination still waiting for its second answer when the campaign would otherwise complete is flagged as not cross-checked, and the campaign completes. Nothing waits forever on a partner. A contributor sent cross-check work is told that the batch double checks combinations another member already computed.

Pooled results

From the campaign, Open pooled results opens the explorer on that campaign's table. There is one row per combination, not one per submission. When two members computed the same combination, the row you see is the earlier of the two answers. The second one rides along inside it as the cross check, so a disagreement never appears as two competing rows.

The columns come from the campaign definition rather than from the rows, so the table has the same shape on an empty pool and on a full one:

There are no parameter columns, exactly as in your own results table. Open a row and its Parameters tab shows the complete configuration behind it, the campaign's pinned values included and the swept ones marked. You can still sort and filter by any swept input.

It opens sorted by net profit, descending, so the best-performing configuration is the first row. Sort by any metric, by a swept input, or by the pair, timeframe, variant or either end of the range. Rows with no value for that column sort last in both directions, so an empty cell never wins a ranking, and an absent value renders as a hyphen, because a zero is a different fact.

Contributor and Confidence do not sort at all, and draw no sort affordance suggesting they might. The first is resolved after a page has been read, the second is worked out per row, so neither is something the server could order by.

Filter by contributor, symbol, timeframe, variant, confidence, a parameter value, a metric threshold or a range bound. The match count you see is the server's count of the whole filtered set, not of the page you have loaded. The contributor filter offers the members whose rows you have actually loaded, because the roster itself is an admin-only read.

Rows arrive 50 at a time, with first, previous, next and last, and the pager names which rows you are on out of the whole matched set. The view is pinned to the moment you opened it, so paging can neither repeat nor skip a row while other members are still submitting. A freshness indicator counts what has landed since; refreshing picks it up and keeps your sort and filters. The address carries the whole view, the page included, so a copied link opens the same rows in the same order.

The tested range

Range From and Range To are the period TradingView itself reported for that backtest, kept exactly as it arrived. It is never converted to a bar count, and it is not something a campaign sets: a campaign says which inputs, symbols and timeframes to cover, never which dates. How far back a run reaches is decided by the account that ran it and by the moment it ran, which is why two rows of one campaign can carry different ranges.

• Filter it as a pair of bounds, one for each end, over a calendar day.
• Two ranges are the same period only when both ends match exactly. TradingView reports the range in seconds or in milliseconds depending on the report, so both are read on one scale before they are compared and a scale difference is never mistaken for a different period. Ends that differ at all make the pair a range mismatch, and their metrics are then not compared.
• A missing or inverted range makes the row low sample, on its own, whatever its trade count says. A row that cannot say what period it covers cannot support a decision.
• The row detail also shows the range as a span, so "2y 3mo" is there beside the two dates.

Export writes the entire filtered set in the active sort order with the columns on screen, not just the loaded page. A set too large to export is refused before anything downloads, with the ask to narrow the filters, and export itself needs a plan that includes it.

Opening a row can reproduce it on your own chart and show your numbers beside the submitted ones, marked when the two fall outside the campaign's tolerance. If it cannot, it says which of the three reasons applies: the symbol will not load for you, no strategy is on the chart, or the strategy is a different one. You can also load a pooled row's configuration into the side panel through the same load path your own rows use. Nothing about the contributing member is applied anywhere.

Confidence and judgement

Every row carries one or more confidence flags describing how well it is corroborated. Nothing is stored: the flags are worked out each time the view loads, from the row, the second answer if there is one, and the campaign's two judgement settings.

The first four are one question with four answers, so a row carries exactly one of them: is there a second answer this view believes, did it cover the same period, did it see the same data, did it reach the same numbers. Low sample is judged separately and stacks, which is why a row can read "disputed" and "low sample" at once. The badge in the table shows the most serious flag the row holds; the row keeps the whole set, and opening it lists every one with its reason.

Two admin settings decide where the lines fall, per campaign:

• Minimum trades before a row counts, 30 by default. Below it a row is low sample and is out of the default view.
• Tolerance, in basis points, 10 by default, which is 0.10%. It is how far two answers for the same combination may differ before they count as disagreeing, measured against the larger of the two magnitudes so a metric that changes sign does not get a different verdict depending on who submitted first. The closed trade count is the exception and is compared exactly: a whole trade is not a rounding difference.

Both are applied when results are read, never written onto a row. Changing either relabels every row the next time the view loads: no rebuild, no job, nothing to wait for. Excluding a contributor works the same way, because it is only a flag on the contributor. Their rows leave the default view and a combination they were half of falls back to single source. Nothing they submitted is deleted or altered, so counting them again brings the previous flags back exactly.

Two metrics being absent on both sides counts as agreement, because neither machine reported them and there is nothing to disagree about. One side reporting a value and the other not counts as a disagreement, so a half-empty submission cannot confirm a complete one.

Who may read them

The owner and admins always read the pooled table. For everybody else it is a decision, taken per campaign:

• Grant a member, and they get a read-only view: no campaign controls, no grant management, no trust actions.
• Grant the whole community, and anybody who joins later inherits it. The confirmation says so before you do it.
• Deny a member, and that beats a community-wide grant. Lifting the denial restores access.
• A grant belongs to a membership, so leaving and rejoining lapses it. A denial resolves to the account, so rejoining does not clear it. Removing a member ends access whatever grant existed.
• Every decision is listed with who took it and when.

Every refusal is the server's, not a hidden button: requesting a campaign you have no grant for is refused whether you go through the interface or not. And the data behind the table names members by their community display name only. No email address and no account identifier is ever part of it.

What leaves your machine

Your own optimization work stays local, as it always has. Contributing to a campaign is the one thing that sends result data anywhere. It is opt-in per campaign, and the panel lists the categories before the first combination runs:

Joining a community, before any contribution, transmits less: the strategy's identity and display name, your community display name, and your measured history depth. What never leaves your machine under any of this is your Pine source and strategy logic, your chart data, equity curves, trade lists, and your TradingView credentials. The privacy policy lists every stored field.

Plans and limits

Which plan carries which capability lives in the pricing table, which reads straight from our billing system. The numbers below are the caps the server enforces once you have it.

Reading pooled results is an admin's decision rather than a plan feature, so a free member who was granted access reads the table. Exporting it is the same paid capability that exports your own results.

Troubleshooting

FAQ

Do I lose my results if I leave the community?

No. Everything you computed is in your own explorer, labelled with the campaign, and it survives leaving, being removed, the campaign closing and the community being deleted.

Can an admin see my other strategies or my own sweeps?

No. A campaign only ever carries the community's strategy, and only rows you computed for that campaign are submitted. Nothing else about your machine is readable by anyone.

Can other members see who I am?

They see your community display name. Admins additionally see the TradingView identifier your membership reports and your measured history depth. Emails and account identifiers are never part of the community data.

Is a contributed number more trustworthy than my own?

It is the same Strategy Tester on somebody else's account, so it is as good as their data. That is exactly what cross-checking, the tolerance and the trust flags are for: a second machine either agrees within tolerance or the row is flagged with both answers shown.

Can two members test the same combination by accident?

No. Combinations are leased to one machine at a time, and a second pass only happens when an admin asks for it through the cross-check share, in which case both answers are kept and attributed.

Does contributing use up my own quota?

Combinations you contribute count in your usage exactly like combinations you tested for yourself. There is no separate accounting and no hidden extra.

Can I contribute while running my own sweep?

Not on the same chart: a run and a contribution both drive the Strategy Tester, so the second is refused while the first holds the chart. Managing communities, reading verdicts and publishing all work during a run.

What happens to a campaign if the owner's plan lapses?

Published campaigns keep running and stay contributable. Only publishing a new one is refused. Nothing is auto-paused or auto-closed.

Stuck, or something reads wrong? Email support@stratopti.com with what the panel says and what you were doing. The rest of the tool is covered in the main documentation.