167 strategies, by the numbers

The figures in this post were measured on May 9, 2026 and are kept as they were. For current results, see how we measure parity.

Numbers updated 2026-05-09 to reflect the new corpus size (167 reference strategies, 165 at strict parity).

In May 2026 we said "165 of 167 strategies pass strict parity." The claim only means something if you know what the 167 were. This is a guided tour of the corpus as it stood then.

Why a corpus matters

Without a fixed reference set, "parity" is a feeling. You run a few strategies, they look close enough, you ship. Then a user tries something with OCA exit groups or request.security in a loop and nothing matches. The bugs were always there; you just hadn't tested for them.

A held-out corpus changes that. At the time, maintainers re-ran the same 167 strategies on the same canonical OHLCV, on their own machines, for any change that could affect parity. If the count of passing strategies went up, something improved. If it went down, a regression had landed. The corpus is a regression harness disguised as a backtest gallery.

The 167 strategies also worked as a public attestation. We committed the engine outputs (trade counts, total returns, Sharpe ratios) to the gallery so anyone could see what the engine produced. That's different from a press release claiming parity.

The three categories

On 2026-05-09 the 167 strategies sat in three folders: basic, community, and validation (a fourth, parity-anomalies, held one probe kept out of the count). They weren't ranked by quality; they described where the strategies came from and what they tested. (Today's public corpus keeps its 312 graded strategies under validation/.)

basic: 9 strategies

The basic category holds canonical, well-known strategy types: MA cross, Supertrend, Stochastic Slow, Parabolic SAR, Keltner Channel, Inside Bar, Pivot Extension, and a volatility expansion method. These are the textbook examples you'd find in any introductory algo-trading course.

They're in the corpus because textbook examples are where compilers break in embarrassing ways. If an MA cross doesn't produce the right trade list, everything else is suspect. basic is the sanity layer.

The 9 basic strategies in the corpus ranged from 13 trades (the greedy strategy, very selective) to 7,299 trades (the volatility expansion strategy, which fires frequently on 15-minute bars). That's a spread of more than 500× within the "simple" category, which says more about strategy selectivity than strategy complexity.

community: 11 strategies

The community category holds Pine scripts contributed by the algo-trading community. Real-world authorship means real-world variation: different coding styles, different use of built-ins, different edge cases in how position sizing and exit logic are wired.

The 11 community strategies include a 4-EMA RSI filter, a Break-of-Structure curve detector, a liquidity sweep strategy, a trend-following system called MarketShift, and others. Trade counts ranged from 72 (VCP, a very selective multi-signal strategy) to 2,643 (IES, the most active). Return spread is wide: IES returned +$58,430 over the backtest window and MarketShift +$3,388, while the weakest community strategy lost $678. Corpus inclusion says nothing about whether a strategy is profitable, only that it compiles and produces trades.

Community scripts are the hardest category to maintain parity on. Authorship diversity means the scripts exercise unusual combinations of Pine features that validation suites don't always anticipate. When we find a new parity gap, it usually lives here first.

validation: 147 strategies

The validation category was the largest by far: 147 of the 167 corpus entries. These are synthetic strategies designed to exercise specific Pine semantics, not to be profitable, but to prove that a particular language feature maps correctly to C++ output.

A few examples of what individual validation strategies targeted at the time:

• 41-partial-exit-qty-percent: tests strategy.exit(qty_percent=...) for partial position unwinding. If the engine over-emits exit fills, this is the strategy that catches it.
• request.security variants: verify that higher-timeframe lookups resolve at the correct bar with lookahead=barmerge.lookahead_off, with and without gaps.
• OCA exit groups: verify that when one exit in a strategy.oca.reduce group fills, the other exit in the group is reduced by the filled quantity.
• Trailing stop variants: test that trailing stop ratchet logic tracks the high-water mark correctly across gaps and limit fills.
• UDT method tests: verify that Pine v6 user-defined type methods compile to the right C++ struct operations.

The "if this strategy passes, feature X is covered" logic is explicit in how we add to this folder. When a community script exposes a new edge case, we usually write a minimal synthetic reproducer and add it to validation.

How the numbers actually look

All 167 strategies in the corpus at the time ran on the same asset and timeframe: ETHUSDT at 15-minute bars. This is a deliberate constraint: using one canonical OHLCV makes cross-strategy comparison meaningful and removes asset-specific factors from the parity analysis.

Trade count distribution:

The median strategy in the corpus produced 732 trades over the backtest window. The lowest was 13 (the greedy strategy, highly selective). The highest was 11,851. This spread matters for parity testing: a strategy with 13 trades and one misplaced exit has an 8% error rate; the same bug on a 5,000-trade strategy shows up in aggregate metrics even if most trades match.

Sharpe distribution:

The gallery computed Sharpe per trade (the mean of each trade's percentage return over its standard deviation, not annualized), so the values were small. Most corpus strategies were included for their Pine feature coverage, not their risk-adjusted returns. The median Sharpe across the 167 strategies was 0.021. 106 of 167 strategies had a positive total return over the backtest window; 61 were negative.

We surfaced these numbers in the gallery rather than filtering for "good" strategies. If you were browsing for inspiration, the return and Sharpe columns told you what to look at. If you're reading for parity verification, the actual numbers are beside the point. What matters is that PineForge and TradingView produce the same numbers.

What every corpus strategy must do

Inclusion in the corpus requires four things:

1. Compile in PineForge codegen. If it doesn't compile, it can't be tested. This is a higher bar than it sounds. Some community Pine scripts import libraries, and codegen compiles those only when it is given each library's source.

2. Produce at least one trade on the canonical OHLCV. A strategy that compiles but never fires an entry can't have its trade list compared to anything.

3. Have a TradingView reference CSV. Every corpus strategy has a committed TradingView "List of Trades" export: tv_trades.csv, or, for one self-test strategy, one trades-<mode>.csv per mode. This is the ground truth the engine's output gets diffed against.

4. Have its engine output committed alongside the Pine source. The gallery serves from these committed outputs. Nothing in the gallery is generated on the fly. It's the snapshot of what the engine produced on the day the strategy was added or last updated.

Why we published aggregates, not source

Until mid-May 2026 the gallery published trade counts, returns, Sharpe ratios and sparklines, but not the Pine source or the raw trade lists.

The reason for community scripts still holds: they are written by their original authors, and we don't have permission to redistribute their source. The strategies we wrote ourselves have since been published in full as the open pineforge-corpus: Pine source, generated C++, TradingView's export and the engine's trade list for each one. The gallery links all of them.

What the gallery enables

The gallery serves three audiences:

Solo quants browsing for ideas. The strategies span enough variation in entry logic, exit logic and indicator type that browsing the gallery gives a reasonable survey of what compiles and runs on the engine. Filter by category and look at the sparklines.

Engineers verifying parity claims. If you want to check a parity claim, the gallery is where you start: each card shows how many of its trades are identical in TradingView's and PineForge's books, and strategy pages show both trade lists. The rubric that assigns the tiers is on the methodology page.

CI baseline for engine releases. At the time the full 167-strategy sweep ran on maintainers' machines; the engine's CI did not run it. Today a corpus-parity workflow re-runs all 312 strategies of the open corpus on main every night, and a pull request merges only with a passing parity verdict from the maintainers' full run, so a change to any strategy's output is caught before it ships.

Where to go from here

• Browse the gallery: today's 312 open-corpus strategies, filterable by category.
• Backtest from Claude or Cursor: the free hosted MCP server, or the local Docker server on your own OHLCV.
• How we measure parity: the current results and their sources.