pineforgeGet started
Origin

Why we built PineForge.

Three forks not taken. Two years chasing four broken parity cases. One thesis: PineScript deserves a real runtime.

Why offline reproducibility

TradingView is where most Pine strategies live, and for good reason — instant chart-side iteration, a huge community, social sharing. What it doesn't ship is an offline runtime: you can't pin the engine version, you can't run a backtest in CI, you can't reproduce a trade-list bit-for-bit on another machine.

For browsing chart ideas, none of that matters. For building a strategy you'd put real money behind, all of it matters. The gap between "I see a number in a browser" and "I have an audit trail" is what we set out to close — without leaving the Pine language behind.

Why not contribute to PyneCore

PyneCore is the most ambitious open-source PineScript engine. We use it ourselves as a second-opinion oracle. We considered upstreaming everything we built. Two reasons we didn't:

We treat PyneCore as the second source. Every PineForge release runs the parity sweep against both PyneCore and TradingView. Their excellent tier rate is high enough that disagreements between the two engines are almost always one of them having a bug — usually ours.

Why not extend Backtrader

Backtrader is the workhorse of Python algo trading. Solid, well-loved, and the wrong shape for this job. It's a Python-native backtesting framework that happens to support custom strategy classes. Pine is a different language with different semantics — you can't fake `request.security()` lookahead, intra-bar order processing, or `oca_name` exit groups by writing more Python.

And again: a Backtrader strategy is Python source, distributable as Python source. The compiled-binary marketplace requires a transpile step that produces a deployable artifact. Backtrader's surface doesn't expose that.

The 158/162 chase

We started with 9 strategies and 76% strict parity. Two years later: 162 strategies, 158 strict. The gap from 76 to 96.9% wasn't built by writing more codegen — it was built by chasing four-decimal-place divergences, one at a time, for weeks each.

Most of those weeks were spent matching TradingView's specific definitions of words like "exit", "fill", "trail" — the Pine documentation describes the API; the exact semantics of order processing only become visible when you diff trade lists bar by bar. We did that, kept asking why ours and the reference disagreed, and ironed out the differences one at a time.

The four still-open cases are the interesting ones — corner cases that took the most digging and remain on our roadmap to close. We treat them as research, not embarrassment.

What's next

Q3 2026: Optuna integration ships. Optimize any strategy on any one-line objective function — Sharpe, drawdown, profit factor, your own Python lambda. Walk-forward analysis built in, out-of-sample is the default not an afterthought.

Q4 2026: Hosted Studio launches. Project workspace, backtest, optimize, compare, paper-trade — all in a browser, all running on the same `.so` you'd run locally via the CLI today. Wave-1 access goes to the early-access waitlist first.

2027: Marketplace opens. Sellers publish compiled `.so` binaries with seller-defined license bounds: time, machine, broker, symbol, input ranges. Buyers run on their data, never see source. Same delivery model that worked for MQL5 — except the strategies are written in Pine, the runtime is auditable, and the licenses are revocable.

The 1% that can't be hand-written

Every parity engine we've ever read about was built and abandoned by someone who got bored at 90%. The last 10% is repetitive, high-effort, low-glamour work — it has to be done by people who get genuinely excited about explaining why two trade lists disagree by 0.0001%.

That's the team. That's the discipline. That's what makes the runtime worth running your money on.