Technology

Pine parity

PyneCore reproduces the Pine Script reference output at the bit level. Across 61.8M compared bars, 99.64% land on exactly the same double as the TradingView reference values; the remainder stays inside a published 1e-9 relative tolerance band. Script-by-script results are public at wild.pynesys.io .

This is not aspirational — it is the explicit acceptance criterion built into the test suite. Every Pine function is verified against TradingView reference values, with floating-point comparison under that tolerance.

The test infrastructure is unusual: tests are themselves Pyne scripts. Each test file is both a runnable Pyne program and a pytest case, executed by the same runtime that ships to users. This catches behavioral drift that traditional unit tests miss — if a test passes, the production runtime passes too.

CSV reference data for indicators and strategies is exported directly from TradingView and committed to the repository. New Pine features are tested against actual reference output, not against a separate specification.

Architecture

PyneCore is a from-scratch Python runtime, not a wrapper or interpreter. Pine-like semantics — Persistent variables, Series, function isolation, NA handling — are produced by AST transformations that rewrite Python code at import time. The output is regular Python that runs on any standard interpreter.

The runtime has zero external dependencies. The full PyneCore package depends only on the Python standard library. This is a deliberate constraint, not a coincidence: zero dependencies makes the runtime portable to constrained environments — most importantly, the browser via WebAssembly.

The architecture splits into two parts. PyneCore — the open-source runtime — executes Pyne scripts. PyneComp — the closed-source compiler — translates Pine Script source into Pyne. The split is intentional. See the open source vs commercial section below.

Integration model

Three integration patterns, in order of increasing depth.

API today. REST API at api.pynesys.io with self-service monthly plans. Submit Pine Script source, receive Pyne output. Suitable for indie projects, prototypes, and back-office automation.

Browser execution (Q4 2026). Full PyneCore loaded into the browser via Pyodide WebAssembly. Strategies execute on the user’s machine with no server-side compute. Suitable for embedded backtesting and live execution within partner platforms.

Embeddable SDK (Q1 2027). Drop-in JavaScript SDK that bundles the WASM runtime, charting, and execution UI. White-label by configuration. Designed for brokers, exchanges, and fintech apps that want Pine-compatible execution branded as their own feature.

All three patterns share the same runtime. The only difference is deployment.

Compatibility

Pine Script v6 is the target language, and version upgrades are automatic. PyneComp runs v4 to v5 and v5 to v6 conversion during compilation, pinned to the reference converter’s own behavior, so an older source compiles without a manual rewrite. Pre-v4 scripts are normalized to a v4 shape first and most of them compile as well, but that path is best-effort and outside the supported scope.

Coverage is substantial: 74 technical indicators under ta.*, plus math.*, str.*, array.*, matrix.*, map.*, color.*, timeframe.*, session.*, plot, hline, fill, and the full v6 type system — series, persistent variables, varip, user-defined types, enums, and Pine libraries.

Strategy support includes the harder cases: bar magnifier for intra-bar precision, calc_on_order_fills with variable rollback, OCA groups, trailing stops, and multi-timeframe access via request.security. The execution model mirrors the reference implementation, including order fill timing, commission and slippage models, margin calls, and equity calculation.

The known gaps are deliberate. Drawing objects — line.*, label.*, box.*, table.*, polyline.* — accept every API call and their state is tracked, but the runtime has no built-in chart rendering; output is CSV, and visualization is a planned plugin. External data sources such as request.financial and request.economic are plugin extension points rather than core features, for the same reason: they are not part of executing a strategy. The full compatibility matrix lives in the pynecore.org documentation and is updated with each release.

Performance

CPython execution closely matches Pine Script performance for typical scripts. The runtime is implemented in pure Python without C extensions, which simplifies portability without sacrificing speed.

PyPy is validated and yields a 5x speedup with zero code changes — a direct consequence of the zero-dependency architecture. There is nothing for PyPy to fall back from.

WebAssembly execution via Pyodide runs at approximately one-third of CPython speed. For live trading at one bar per minute, this is more than sufficient. For limited-bar backtests in the browser, the latency is imperceptible.

Heavy backtests on long histories should run server-side or under PyPy on the user’s machine. The choice is per-use-case, not per-runtime.

Open source vs commercial

PyneCore is licensed under Apache 2.0. The full source, test suite, and documentation are public on GitHub . Community contributions are welcomed via standard pull request flow. Commercial use is permitted under standard Apache 2.0 terms, including embedding in proprietary products, with attribution per the project’s NOTICE file.

PyneComp — the Pine Script to Pyne compiler — is closed source and offered as a SaaS service. This split is deliberate. The runtime is the foundation; making it open ensures portability, transparency, and ecosystem trust. The compiler is the engineering investment that translates a closed scripting language into the open runtime, and keeping it commercial is what funds the work.

The result is an ecosystem where the integration surface — PyneCore — is permanently free to use, and the value-added service — PyneComp — sustains the project. Partners integrating PyneCore are not building into a vendor trap.