Validation, Evaluation, Strategy Testing, Research & Optimisation System

VESTROS logo

Meet VESTROS, a fully automated systematic interpretation and discovery system for extracting & inventing composable features out of uncertain trading logic/indicators/strategies to heavily evaluated, portable, evidence-backed algorithmic systems.

There are thousands of systems, strategies & indicators. Public & private, with new ones written every day. Do they even work? Could they even work? Did the original author find all the possible ways to interpret the outputs of that system? That's not up to you. Take that system and let VESTROS take the wheel:

derive composable features from a strategy source.
test concrete interpretations of those features.
assemble them into complete strategies.

VESTROS invents, evaluates and explores thousands of new innovative ways to interpret the outputs of a system, together with market data, to innovate & discover new ways to reap opportunities in the market.

The aim is to establish exactly what was tested, what failed, what survived, and whether a result still holds after declared costs, execution delay, alternate candle paths (OHLC vs OLHC), nearby parameters, other configured symbols or timeframes, and data that played no part in selecting it. Historically promising candidates can then be replayed, archived, evaluated forward, or exported as provider-neutral signal generators and complete strategies. Fully

Strategy source
   ├─ PineScript (TradingView)
   ├─ MQL4 / MQL5 (MetaTrader)
   ├─ perhaps NinjaScript / EasyLanguage later
   ├─ custom idea
   └─ native TS / other definitions
        ↓
portable calculations / features
        ↓
interpretation, feature & hypothesis discovery
        ↓
research campaigns
        ↓
intensive backtesting & evaluation
        ↓
interesting candidate(s)
        ↓
promotion(s)
        ↓
portable signal generator(s)
        ↓
live execution / third-party backtester / other consumer

VESTROS can help with:

Porting: Convert Pine indicators or strategies into portable, checkpointable TypeScript calculations.
Parity: Compare the port against exported TradingView values on identical candles.
Data preparation: Fetch, cache, validate, and align historical candle series.
Idea generation: Start with the port's declared output types and relationships rather than guessing from names such as trend, signal, or buy. Generate explicit possibilities including threshold crossings, state transitions, breakouts and re-entries, trend changes, regime-gated triggers, and agreement or divergence between compatible indicators. Each idea remains a testable hypothesis, not a claim that it works.
Strategy composition: Turn one idea into a complete policy by declaring the exact long or short entry, any regime gate, stop, target, trailing or time-based exit, position sizing, instrument rules, Pine configuration, data series, fees, slippage, and execution-delay assumptions.
Automated research: Screen complete strategy hypotheses over the development period, discard inactive or economically weak candidates, and carry every distinct screen-positive candidate into provider-history and chronological testing. Bounded boundary and rescue lanes preserve useful negative evidence. Check costs, delays, drawdown, nearby parameters, candle-price paths, symbols, and timeframes where declared. Freeze every surviving candidate before opening the untouched assessment period, never substitute candidates after seeing those results, and materialize only candidates that pass the declared historical gates.
Backtesting: Run deterministic candle simulations with multiple price paths, costs, delays, and shared-capital layouts.
Paper, demo, and live evaluation: Exercise the same application and calculation path with progressively stronger evidence and safety gates.
Evidence and reporting: Produce campaign reports, candidate tear sheets, session captures, replay comparisons, and forward-performance evidence.

Systematic Exploration

Within the research stage:

system (strategy/indicator) outputs
-> possible trigger and regime ideas
-> complete strategy definitions
-> economic screening
-> detailed development testing
-> robustness checks
-> sealed final assessment
-> historically promising candidates

One way to start:

Bring a system script (e.g. a Pine script study/indicator/strategy).
Port and verify the port.
Automatically explore possible interpretations, beyond the vision of the original author.
Run an economic research campaign.
Materialize historically promising candidates.
Test them forward before considering real execution.

All calculations are portable. The engine sees normalized events and order goals. All connectivity (REST API, WebSocket, authentication, etc) is powered by the SDKs built & maintained by Siebly SDKs.

VESTROS currently runs from a repository checkout. npm publication is not configured or maintained. The private package manifest and the prepack and prepublishOnly guards prevent accidental publication.

Systematic Exploration

Port Pine Script v6 to ordinary TypeScript, compare it with a TradingView export, then use the same calculation in backtests, research, paper sessions, demo accounts, or live systems.

A ported Pine script is not necessarily a strategy. It is a deterministic feature generator. Its outputs can be used directly or explored as triggers, filters, amplifiers, exits, regime inputs, and sizing inputs without changing the verified calculation.

flowchart LR
    A["Pine Script"] --> B["Portable TypeScript port"]
    B --> C["TradingView parity check"]
    C --> D["Automatic research"]
    D --> E["Historical campaign"]
    E --> F["Materialized candidate"]
    F --> G["Backtest or paper"]
    G --> H["Demo or live evaluation"]
    H --> I["Archived extendible candidate"]

Public system archive

The result of a research campaign is typically one or more promising systems. These can be archived as a form of preservation. Archives are currently split into three groups:

Archived & Published, Public: completely visible to the public, including core logic & tearsheets.
Archived & Published, Private: visible to the public, but core logic & system details remain private.
Archived, Private: completely hidden from the public. Not even pushed to this repo.

Published Archives

These can be viewed at any time, via the dedicated web page hosted on GitHub Pages: https://tiagosiebler.github.io/vestros/

Navigate into a system to find out more, including:

Report: overview on the system, including how it works (public archives only), and convenient commands to work with that system.
Tearsheets: detailed reports with technical details on how this strategy performed in the backtest.
OOS Tearsheets: archived systems can later be rerun out of sample (backtest). If available, details are published as an extended tearsheet.
Pine script: coming-soon, copy-pastable Pine script of selected systems, allowing you to reproduce & test them directly in TradingView.

Public Archives

All public archives are found within the archived-systems/public/systems/ directory. They are retained for reproducible historical review and further testing across declared ports, timeframes, symbols, and market conditions. The backtests behind them can be rerun at any time using the commands shown in the report page.

The archive storage and migration guide describes the shared archived-systems/ root, private backups and restore checks.

Add a system to the public archive, using the following command:

vst explore campaign archive <campaign-id> \
  --candidate <handle>/<variant> \
  --system-id <system-id> \
  --public

Any system sent to the public archive is automatically published on the Public System Archive.

Private Archives

All privately archived systems are found within the archived-systems/private/systems/ directory, which should be gitignored at all times.

Add a system to the private archive, using the following command:

vst explore campaign archive <campaign-id> \
  --candidate <handle>/<variant> \
  --system-id <system-id> \
  --private

Any system sent to the private archive will not be shown on the Public System Archive.

If you wish, you can still publish it by adding the --publish command:

vst explore campaign archive <campaign-id> \
  --candidate <handle>/<variant> \
  --system-id <system-id> \
  --private \
  --publish

By including the publish command, you are not exposing the sensitive pieces of a private archive. The archive shown on the Public System Archive will contain the tearsheet and a high level report, but core strategy logic will remain redacted.

For a clearer example, here is how each placeholder actually looks in practice:

vst explore campaign archive campaign-v5-20260811-0002-05dfbc24 \
  --candidate C10919/baseline \
  --system-id btcusdt-4h-c10919-private-v1 \
  --private \
  --publish

Archive Contents

Each package includes its exact strategy and calculation source, data and economic assumptions, compact campaign evidence, tear sheet, generic replay definition, and complete file hashes. Tear sheets retain their route-bound market bars so charts work offline. Replaceable provider caches and raw campaign databases stay out of Git.

Each archive also carries a compact portable-strategy reference attachment. Run vst system extract <system-id> --output portable-strategies to generate a provider-neutral TypeScript strategy with no VESTROS or npm runtime dependency. The archived range is replayed before publication, and historical candles are not copied into the generated workspace. Read the portable strategy guide for the runtime and evidence contract.

Browse the generated catalog with vst system list. Its symbol, timeframe, evidence, campaign, and metric filters all come from archive-bound evidence.

Use --private with campaign archive commands to keep the same complete replay package under ignored archived-systems/private/systems/. Add --publish to expose only its canonical performance report, tear sheet, and redacted presentation under archived-systems/public/presentations/. Replay and portable extraction still require the private counterpart, and derived files must stay below private/.

The first archived system is the BTCUSDT 4h C10919 long system, including its public tear sheet.

[!CAUTION] This is engineering tooling, not financial advice. Included scripts and settings are fixtures, not recommendations. Simulations do not prove profitability or predict exact venue fills. Live execution can lose money and remains disabled until every configured safety gate passes. You should not risk any real money on anything coming from this system.

Run an offline checkout example

VESTROS requires Node.js 24.11.1 or newer within Node.js 24 LTS.

On Windows, run these commands with Linux Node/npm inside WSL, keeping the checkout and runtime state in WSL's Linux filesystem. See Windows execution through WSL for setup and working safely from an existing Windows checkout.

npm install
npm run build

# todo: explain what this simple-bb thing is
node examples/portable/simple-bb.mjs

# run health checks
node dist/cli/bin.js doctor

# list available commands
node dist/cli/bin.js --help

The build compiles source and bundled public ports only. It does not read historical datasets, .tvt caches, credentials, or the network. Small deterministic calculation fixtures live beside their ports under pineports/*/fixtures/; they are separate from reusable datasets.

The portable example uses five local closes and makes no network requests. It prints "outputsMatch": true when batch and one-bar-at-a-time evaluation agree. doctor checks the local Node.js and SQLite requirements without loading an exchange adapter or making a network request. The built CLI entry point works directly from the checkout. When the CLI starts, it automatically loads an optional .env file from the current working directory. Existing process environment values take precedence.

If you want the shorter vst command while developing, link this checkout once:

npm link
hash -r
vst --help

npm link: points the global development command at this checkout.
hash -r: clears zsh's cached command lookup after the link is created.
- It is a shell command and has nothing to do with VESTROS evidence hashes.
- If you skip the link, replace vst in the commands below with node dist/cli/bin.js.

Run an exploration campaign

Automated campaigns are the ordinary unattended path from verified Pine ports through data preparation, typed hypothesis generation, economic screening, development, robustness, sealed assessment, reporting, and eligible-only materialization. The automated campaign guide owns the current command surface, configuration, search stages, economic gates, resume behavior, evidence labels, and report interpretation.

Create a reviewable configuration, validate it, and preview the resolved plan:

vst explore campaign config scaffold campaign.json \
  --ports simple-bb \
  --exchange bybit \
  --environment mainnet \
  --market linear \
  --symbols BTCUSDT \
  --timeframes 4h \
  --from 2025-01-01 \
  --to 2026-01-01

vst explore campaign config validate campaign.json
vst explore campaign start --config campaign.json

The preview is read-only. Repeat the final command with its exact printed --accept-preview hash to create and run the campaign. Interrupted work resumes from the retained campaign ID:

vst explore campaign list
vst explore campaign status <campaign-id>
vst explore campaign resume <campaign-id>
vst explore campaign report <campaign-id>
vst explore campaign diagnose <campaign-id> --method cscv-pbo-v1
vst explore campaign diagnose <campaign-id> --method cscv-pbo-v1 \
  --accept-preview <sha256>

The first diagnose command previews the exact report-only sidecar. Repeat it with the printed hash to retain that artifact, or use --run to retain it without a separate acceptance step. The command requires a completed, non-retrospective V5 campaign and leaves its frozen report unchanged.

A completed no-selection result is valid evidence. Assessment results do not rerank or replace the frozen cohort, and the toolkit does not invent one campaign-wide winner. Materialized programs remain unarmed and do not authorize external execution.

What each campaign phase means

A campaign starts with many strategy hypotheses, then spends more testing time on those with promising evidence. Passing a phase means a candidate qualifies for the next checks. It does not establish that the strategy will work in live trading. Later phases may have no qualifying candidates to evaluate.

Phase	What it does
Preparation	Fetch or reuse historical market data, prepare the verified strategy runtime, and save the inputs needed for evaluation.
Candidate generation / catalogue preparation	Build distinct strategy configurations, including their signals, parameters, and market bindings. A prepared candidate is a hypothesis ready to test, not a completed backtest.
Screening	Run initial historical evaluations to find candidates with completed trades, positive returns, consistency across chronological blocks, and acceptable drawdown under the campaign's rules.
Promotion planning	Review the saved screening results, determine which candidates qualify, resolve exact behavior duplicates, and save the selection for deeper testing. `Qualifications` means processing each candidate's evidence; `selection` determines the cohort that advances.
Extended-history risk audit	Replay promoted strategies over the available longer history before the assessment boundary to check whether the initial screen missed unacceptable risk.
Development	Evaluate surviving candidates across chronological folds, execution assumptions, and cost scenarios to check whether their performance holds across different conditions.
Robustness	Stress qualifying strategies with higher costs, execution delays, and applicable nearby parameter settings. A strategy that only works under one precise assumption can fail here.
Sizing refinement	Where enabled, compare bounded position-sizing alternatives. Each alternative must pass its required development and robustness checks.
Sealed assessment	Freeze the selected strategies before evaluating them on the held-out period. Assessment results do not trigger another round of selection or tuning.
Final replays and reporting	Run the applicable complete-history checks and assemble results, evidence labels, and reports. A campaign can finish successfully without selecting a strategy.

Generation and screening can occur in separate base and refinement rounds. Management research can also add policy comparisons and execution checks. The accepted campaign configuration determines which work applies.

Promotion is not simply “take the highest returns”. The documented adaptive policy advances every distinct screen-positive representative, with a small bounded allowance for near misses and exploratory candidates. For example, a profitable strategy may advance from screening but fail robustness when an extra bar of execution delay removes its profit. The economic funnel owns the exact gates, thresholds, and later-stage rules; the search stages explain base and refinement generation.

Reading campaign progress

Candidates and evaluation jobs are different units. 10,000/10,000 prepared means the candidate catalogue is ready. A subsequent worker count such as 2,311/15,595 settled counts evaluation jobs whose results have been durably recorded. One candidate can require multiple jobs, so the larger total does not mean more strategy hypotheses were generated.
Promotion qualifications count candidates again. 1/10,000 candidates means one candidate's qualification record has been processed using its screening evidence.
“Calibrating” in promotion progress refers to timing estimates. The CLI is collecting initial progress samples to estimate speed and ETA. It is not calibrating strategy parameters or starting another testing phase.
Check the scope of an ETA. Compute and commit estimates describe their reported workload. They should not be read as a whole-campaign forecast: later work depends on how many candidates qualify.
A named coordinator blocker can describe normal waiting. For example, coordinator-promotion-planning means downstream work is waiting for the promotion plan. The label alone does not establish an error or a stall.

`--run` & `--resume`

Campaigns can also be run in one command, skipping the validate and start phase, using --run:

vst explore campaign start zone-radar
	--preset wide-20k
	--max-candidates 10000
	--max-drawdown 50
	--port-parameters search
	--port-parameter-budget auto
	--trade-management search
	--trade-management-probe-budget auto
	--execution-timeframe auto
	--exchange bybit
	--environment mainnet
	--market linear
	--symbols ETHUSDT
	--timeframes 1h,4h
	--from 2024-06-01T08:00:00Z
	--to 2026-08-07T00:00:00Z
	--run

Note: if a matching campaign already exists, this will overwrite it with a fresh campaign.

If you wish to resume an existing campaign that was previously started like this, just change --run to --resume:

Campaigns can also be run in one command, skipping the validate and start phase, using --run

vst explore campaign start zone-radar
	--preset wide-20k
	--max-candidates 10000
	--max-drawdown 50
	--port-parameters search
	--port-parameter-budget auto
	--trade-management search
	--trade-management-probe-budget auto
	--execution-timeframe auto
	--exchange bybit
	--environment mainnet
	--market linear
	--symbols ETHUSDT
	--timeframes 1h,4h
	--from 2024-06-01T08:00:00Z
	--to 2026-08-07T00:00:00Z
	--resume

Resume after updates

As long as the parameters are the same, it will automatically match your previously started campaign. If you pulled recent changes while your campaign hasn't finished and wish to resume it, the system might complain with integrity checks.

You can force the system to resume using this flag: --allow-runtime-mismatch.

Run a Cartesian combination study

For a completed campaign, preview a complete Cartesian combination study:

vst explore campaign combine-search <campaign-id> --preset complete-cartesian

Add --run to accept the current preview and execute the study:

vst explore campaign combine-search <campaign-id> --preset complete-cartesian --run

Without --run, the command only previews the study. See the full combination guide for population, sizing, execution, and continuation options.

Getting Started

I want to...	Start here
Give a Pine port to a coding agent	Agent porting workflow
Walk from Pine to a first backtest	Pine to backtest tutorial
Port Pine v6 myself	Porting Pine to Node.js
Find a Pine-compatible built-in	Pine stdlib reference
Use a port in another framework	Portable ports
Use an archived strategy in another system	Portable strategies
Compare a port with TradingView	TradingView export
Backfill or reuse historical bars	Datasets
Run verified ports through unattended research	Automated research campaigns
Backtest a study or explore a hypothesis	Research workflow
Read a performance tear sheet	Run reports
Paper trade or connect Bybit	SimpleBB application
Understand the architecture	Package boundaries
Browse every guide	Guide index

Find existing ports

Public Pine ports live under pineports/, one self-contained folder per slug. Private ports live under the ignored private/pineports/ collection. src/pine/ contains reusable Pine-compatible calculations and stdlib plumbing, not individual script ports.

Toolkit-owned TradingView instrumentation lives under evidence/. Those public harnesses support stdlib parity checks but are not indicator ports, campaign inputs, or package exports.

node dist/cli/bin.js port list --public
node dist/cli/bin.js port list --private
node dist/cli/bin.js port list --all

The inventory shows every port and its lifecycle state. The guided campaign selector shows the smaller set which can currently generate automatic research hypotheses.

Port a Pine v6 script

Put protected, invite-only, unpublished, or unresolved Pine files in private/inbox/pinescripts/. The folder is ignored by Git. Migrate older Pine with TradingView first. For linked TradingView publications marked open source, follow the public Pine inbox source-retention rule and create the port in the public collection.

node dist/cli/bin.js port prepare my-indicator \
  --from-pine inbox/pinescripts/sources/MyIndicator.pine \
  --root .

Review the preview, then add --write:

node dist/cli/bin.js port prepare my-indicator \
  --from-pine inbox/pinescripts/sources/MyIndicator.pine \
  --write \
  --root .

node dist/cli/bin.js port status my-indicator --root .

Each port keeps its Pine source, TypeScript module, manifest, fixtures, provenance, and guidance together. Standard Pine functions belong in the shared vestros/pine/stdlib boundary so later ports can reuse them.

Compare with TradingView

Parity is a direct calculation check:

same confirmed candles and inputs
  -> Pine export outputs
  -> TypeScript outputs
  -> compare

node dist/cli/bin.js parity guide my-indicator --root .

node dist/cli/bin.js port parity-check my-indicator ./exports/chart.csv \
  --tail closed \
  --symbol BTCUSDT \
  --feed BYBIT \
  --timeframe 1H \
  --timezone UTC \
  --session 24x7 \
  --chart-type candles \
  --root .

TradingView may have hidden warm-up history before the first exported row. Provide equivalent confirmed seed history, then compare the aligned range. Feed, symbol, timeframe, and chart settings reproduce the evidence run. They do not restrict the port to that venue or dataset.

Use a port directly

A port does not need the CLI, runtime, exchange adapter, journal, or TradingView.

import { evaluateSimpleBbBars } from "vestros/pineports/simple-bb";

const outputs = evaluateSimpleBbBars(candles, {
  length: 20,
  multiplier: 2,
});

Streaming kernels accept one confirmed input at a time and expose checkpoints:

import { createSimpleBbPort } from "vestros/pineports/simple-bb";

declare const confirmedCloses: readonly (number | null)[];

const kernel = createSimpleBbPort({
  length: 20,
  multiplier: 2,
}).createKernel();

for (const close of confirmedCloses) {
  console.log(kernel.step(close));
}

const checkpoint = kernel.checkpoint();

Batch evaluation repeats the same streaming calculation.

Research verified ports

Use vst explore campaign config scaffold to record the ports, provider, environment, market, symbols, timeframes, UTC range, and research settings. Validate the config, preview it with campaign start, then repeat the same command with the exact preview hash. VESTROS prepares missing confirmed history only after acceptance and continues through economic screening, development, robustness, sizing, sealed assessment, reporting, and historically-promising-only materialization.

The foreground command keeps bounded progress visible. Use campaign list or campaign status for retained state and campaign resume after an interruption. Resume uses retained datasets and port bindings offline with the accepted configuration unchanged.

Read the automated campaign guide for config, preview, acceptance, progress, resume, report, backtest, and archive commands. The lower-level study commands below remain available when you want direct control.

For example, selecting BTCUSDT, 1h,4h, and the 2025 calendar year creates one selected series for each symbol and timeframe coordinate. Automatic layouts admit current-series, synchronized cross-symbol, and strict-prior cross-timeframe hypotheses when the selection supports them. The exact ports, series roles, alignment, entry, gates, exits, and sizing stay visible in each program. Candidate slots count unique program definitions, including each layout. Folds, costs, candle paths, and robustness coordinates add work without consuming more slots.

Candidate generation balances canonical ideas, seeded typed proposals, development-evidence refinement, and uniform rescue. Candidate definitions and generator state are retained, so worker timing cannot change what was tried.

Once a port is reviewed, this discovery path does not require a coding agent or model. The calculation contract, causal feature catalog, reviewed layouts, and frozen research rules provide the guidance. A no-selection campaign remains a valid result. Its cumulative report explains the funnel and retained evidence. Materialized applications remain unarmed and do not authorize external execution.

Dataset commands are available when you want to bookmark a useful range, reuse it explicitly, inspect it, or prune cached data:

node dist/cli/bin.js dataset backfill bybit-btc-1h-2025
node dist/cli/bin.js dataset verify bybit-btc-1h-2025

node dist/cli/bin.js backtest examples/research/simple-bb-1h-2025.study.mjs \
  --dataset bybit-btc-1h-2025

Create and backfill a Bybit dataset directly when no manifest exists yet:

node dist/cli/bin.js dataset backfill \
  --exchange bybit \
  --market linear \
  --symbol BTCUSDT \
  --timeframe 1h \
  --from 2025-01-01 \
  --to 2026-01-01

For several symbols or timeframes, save one bounded grid and reuse it:

node dist/cli/bin.js dataset grid scaffold core-2025 \
  --exchange bybit \
  --market linear \
  --symbols BTCUSDT,ETHUSDT,SOLUSDT \
  --timeframes 15m,1h \
  --from 2025-01-01 \
  --to 2026-01-01 \
  --suite core-1h-2025 \
  --suite-timeframe 1h
node dist/cli/bin.js dataset grid preview core-2025
node dist/cli/bin.js dataset grid backfill core-2025
node dist/cli/bin.js dataset grid verify core-2025

The backtest prints a concise report and retains its canonical result, full account trace, scored candles, trade markers, and execution profile under .tvt/backtests/<result-hash>/. Open the generated full-year HTML tear sheet to inspect the example without running it.

Use a declarative blueprint to define bounded parameter and application variants:

node dist/cli/bin.js explore scaffold my-study
node dist/cli/bin.js explore validate my-study
node dist/cli/bin.js explore preview my-study
node dist/cli/bin.js explore run my-study --workers 2

The scaffold contains visible placeholders. Connect its dataset suite, application factory, policy factory, parameter bindings, costs, and instrument rules before running it.

Generate a bounded set of explicit hypotheses from one or more public, parity-verified ports:

node dist/cli/bin.js explore auto simple-bb \
  --suite bybit-linear-btc-eth-sol-1h-2025 \
  --max-candidates 25

node dist/cli/bin.js explore auto simple-bb,hma \
  --suite bybit-linear-btc-eth-sol-1h-2025 \
  --max-candidates 25

The manifest already says which outputs are numeric, exact integers, booleans, or encoded categories. VESTROS uses those facts directly. The generated strategy motif capability reference owns the exact inventory, counts, and surface reachability. Examples from the current automatic and campaign catalogs include:

transitions between rises and falls over 1, 4, or 16 confirmed bars, volatility-normalized change over those horizons, one-bar acceleration crossing zero, 20 or 60-bar rolling trend direction changes, and rolling 20-bar z-score crossings;
one-bar change zero-cross events kept active through 1, 4, or 16 later confirmed bars, with a matching window-expiry exit;
one-bar change which keeps the same direction for 2 or 3 confirmed bars;
a 20-bar z-score which remains beyond +1 or -1 for 2 or 3 confirmed bars;
a 20-bar z-score which is beyond the same extreme on 2 of the latest 3 or 3 of the latest 5 confirmed bars;
a 20-bar z-score hysteresis lifecycle which enters beyond +1 or -1 and exits through +0.25 or -0.25;
breakouts above or below the complete previous 20 or 60-bar range, plus breakout and return transitions around the previous maximum;
transitions into the upper or lower fifth of the previous 20 or 60-bar value distribution, using deterministic midranks for ties;
crossings between a reviewed numeric series and its comparable bar field;
ordered-band breakouts and re-entries;
causal sparse-level breakouts, starting only when the level becomes knowable;
exact boolean and encoded-state transitions;
crossings between two reviewed comparable numeric series;
z(left) - z(right) crossing zero;
z(left - right) crossing +1 or -1, only when both series have reviewed comparability evidence;
corr(change(left), change(right), 20) as a non-directional regime gate;
lagged change correlation at 1, 2, and 4 bars as a non-directional gate;
8, 20, and 60-bar trend efficiency as high or low regime gates;
prior 8-bar feature volatility divided by prior 32-bar feature volatility as fixed high and low regime gates;
the legacy prior 20-bar level volatility divided by prior 60-bar level volatility as fixed high and low regime gates; this is not a Lo-MacKinlay variance-ratio test;
prior-window location shifts, reviewed pair-regression residuals, and normalized-change CUSUM events;
the current value against the complete prior 60-value median and MAD, crossing fixed positive or negative extremes;
the 20-bar z-score of log1p(volume), including the current confirmed bar, as a high or low regime gate when volume is an admitted market field;
current true range divided by the prior 14-bar Wilder ATR as a high or low regime gate when high, low, and close are admitted market fields;
the downside share of squared variation from 60 complete prior log returns as a high-only regime gate when close is an admitted market field;
one directional or event trigger qualified by one current correlation, lagged association, trend-efficiency, prior feature-volatility, legacy prior level-volatility ratio, prior downside-semivariance share, current volume-surprise, current true-range-to-prior-ATR, or same-source prior-percentile gate;
campaign refinement-only Parkinson range-volatility and heteroskedasticity-robust Lo-MacKinlay variance-ratio regime gates;
8, 20, and 60-bar relative strength between two series, crossing zero;
a campaign sequence in which event A is followed by event B on a strictly later confirmed bar within a fixed 1, 4, or 16-bar window;
signed agreement and divergence between two changing series;
coherent extreme-entry and return-from-extreme exit lifecycles;
same-series pair relationships between outputs from selected portable ports;
independent and combined lower-to-higher timeframe hypotheses across every selected fixed candle interval.

Gate values update from confirmed data on each bar. Their formulas and thresholds are frozen before validation. A gate can depend on another declared feature, but it cannot quietly retune itself after seeing trade results.

Sparse levels can remain relevant indefinitely, so those candidates require a clear historical starting point. The guided flow prepares compatible history automatically instead of asking the user to understand startup or cache internals.

This is a deliberately bounded starting catalog, not a claim that these are all the relationships which may contain useful information.

Pine Script research recipes explains how these calculation outputs become explicit candidates, what kinds of interpretations are generated, and how they are evaluated at scale.

Numeric encoding values are never treated as category order. Every retained relationship and action interpretation is shown before it can run. See the relationship catalog for what is implemented, what comes next, and what is deliberately excluded. The research recipe capability matrix shows which wider quantitative methods are executable, which are only partial, and which need new evidence contracts before they can be tested safely. Development-only precursor diagnostics report lagged event response, feature quantiles, Spearman rank association, and response decay. They remain isolated from executable policy input.

A call without --accept-preview prepares required historical data and then shows a concise read-only preview. Select Show technical details to inspect every candidate retained under --max-candidates, including its graph or recipe, action interpretation, identity, and generated, duplicate, rejected, retained, and omitted counts. In an interactive terminal, select Start development directly. The process then guides development through shortlist, robustness, the one-way holdout decision, reporting, and an unchanged-candidate backtest. A passing one-series application can then become a runnable Bybit paper and demo program without adding provider code to the research worker. Paper uses live public candles and the local modeled account. Demo stays disarmed until explicitly enabled. Run vst explore guide <study-id> to return later. Per-family coverage also shows how many candidates and source groups were retained or omitted. Output names never imply trading meaning. Accepted candidates enter the ordinary frozen research workflow. Startup history warms the selected calculations and stateful generated features without creating decisions or scored trades.

In an interactive terminal, bare vst explore starts at Explore home. It can reopen a study or guide a new repository from raw Pine through research. Required historical data prepares and caches itself. Interactive menus update in place below the preview or report that led to them, then collapse to one selected-action line. A Next step rule separates each choice from the preceding command output. The menu leads with readable labels, shows the selected choice's explanation as indented parenthetical context when available, and keeps key hints in one footer. A bounded viewport prevents larger menus from taking over the screen.

Generated automatic and precursor previews show their study ID. A default ID includes the candidate cap and moves to the next free suffix when an earlier study or partial blueprint already owns that name. Accepting the exact same generated files confirms and reuses them. A matching retained study opens its guide. Different immutable contents are never overwritten silently.

The automatic preview names each retained hypothesis, explains the action mapping, and shows how the candidate count expands across markets, folds, costs, and candle paths. --max-candidates means exactly what it says: keep up to that many generated hypotheses. It is not a cash or risk budget.

Look for earlier confirmed features which repeatedly precede an explicitly declared later event:

node dist/cli/bin.js explore precursor pivot-knowability \
  --suite bybit-linear-btc-eth-sol-1h-2025 \
  --label later-confirmed-pivot-high \
  --max-candidates 10

Later events label frozen earlier rows during discovery only. Every accepted policy is then replayed from fresh state with no label, future bar, or Pivot attribution available to it. This finds associations worth testing, not causation or profit.

Reviewed application templates remain available for relationships or layouts which structural facts cannot prove:

node dist/cli/bin.js explore compose --auto \
  --ports simple-bb,hma \
  --max-candidates 2 \
  --study-id simple-bb-hma-study

This path uses declared semantic roles, reviewed output shapes, and registered factories. It is useful for supporting timeframes and custom relationships. Accept the printed preview hash to write the ordinary research blueprint, or use explore start --auto for the guided path.

Start a new single-series study from a public parity-verified port whose manifest declares a discrete encoded output:

node dist/cli/bin.js explore binding scaffold simple-bb \
  --suite bybit-linear-btc-eth-sol-1h-2025

node dist/cli/bin.js explore start --binding simple-bb-research

The preview prints the exact accepted command. The binding keeps output meaning, actions, sizing, and instrument assumptions visible rather than hiding them in generated code.

Research uses chronological development folds, declared costs, both supported candle paths, deterministic candidate order, and a sealed final holdout. It may return no technical selection. Run reports provide terminal, JSON, and self-contained HTML views without ranking by PnL alone.

Select a runtime target

One program can register several normalized targets:

Target	Data	Account and fills	External writes
`fixture/backtest`	Local fixture	Deterministic model	Impossible
`bybit/backtest`	Manifest-backed public dataset	Deterministic model	Impossible
`bybit/paper`	Live public bars	Isolated local model	Impossible
`bybit/log`	Live public bars	Goals only	Impossible
`bybit/demo`	Bybit demo	Demo account	Explicit arming required
`bybit/testnet`	Bybit testnet	Testnet account	Full configuration required
`bybit/live`	Bybit mainnet	Real account	Disabled by default

Paper example:

node dist/cli/bin.js run examples/runtime/simple-bb.application.mjs \
  --exchange bybit \
  --execution paper \
  --session bybit-paper

Disarmed demo example:

TVT_BYBIT_EFFECT=disabled \
node dist/cli/bin.js run examples/runtime/simple-bb.application.mjs \
  --exchange bybit \
  --execution demo \
  --session bybit-demo-readonly

Read the Bybit demo guide before enabling any external effect. Bybit connectivity uses the Siebly bybit-api SDK.

For public historical Binance Spot and USD-M perpetual datasets, see the Binance data guide. For OKX Spot and USDT perpetual datasets, see the OKX data guide. These source-module adapters use the existing dataset backfill and offline verification workflow.

Architecture

Pine v6 port
  -> confirmed calculation
  -> provider-neutral strategy policy
  -> order goals
  -> normalized venue session
       -> simulation
       -> live data with paper execution
       -> provider demo, testnet, or live

Use provider-neutral contracts and local venue factories from vestros/exchange. Runtime hosts use vestros/runtime. Import Bybit only from vestros/exchange/bybit. Core, application, data, profiling, reporting, research, runtime, session, paper, and simulation code cannot import the provider adapter.

Campaign V5 can add worker machines without a broker or shared database. See campaign clustering for the authenticated join, lease, result durability, and reconnect design.

For candle-only simulation, a decision at candle N close is pending immediately and normally becomes executable at candle N+1 open. The runtime does not wait for candle N+1 to close. Path-sensitive runs compare O-H-L-C with O-L-H-C without inventing spread, funding, depth, queue position, or path probability.

For coding agents

Use AGENTS.md for project constraints and task-specific routing. Read the contracts the task needs; porting references apply to Pine work.

The package boundary guide explains public facade ownership and the checks for exports, aliases and provider isolation.

Verify a checkout

Choose checks using the affected-contract rule. For a full verification gate on a supported execution platform:

npm run verify

This checks repository containment, portable calculations, types, tests, builds, generated artifacts, and the application smoke path.

To check the local package boundary and a linked consumer:

npm run build
npm run check:package
npm run check:linked-consumer

The linked-consumer check creates an npm-link-like node_modules symlink and imports representative public exports without invoking npm pack, install, or publish. npm link remains available for local CLI development as described above; it does not imply a registry package or publication workflow.

See CONTRIBUTING.md before changing the repository. Toolkit-owned material uses the MIT licence. Third-party material retains its own terms and must appear in THIRD_PARTY_NOTICES.md.

Public System Archive

Try in TradingView

BTCUSDT 4h C10919 system

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows

Past year vs earlier 12-month windows