pineforgeGet started
Marketplace design

Compiled-binary licensing for trading strategies: the design space

Selling a strategy as source is risky. Selling it as a hosted service is heavy. Selling it as a compiled binary with seller-defined license bounds is the path PineForge's marketplace is built around — here's the design exploration that got us there.

8 min read#marketplace#licensing#design

Strategy creators want to monetize without giving away source. Buyers want to backtest on their own data and run on their own broker. These two requirements are genuinely in tension, and most current solutions resolve the tension badly. This post describes the design space we explored before settling on compiled-binary licensing as the foundation of PineForge's marketplace.

The problem in plain terms

A strategy creator has built something that works. They've spent months tuning parameters, fixing edge cases, proving out of sample. They want to sell it. The buyer wants to run it on their own data, verify it backtests the way the creator claims, and plug it into their own execution pipeline.

The moment the creator hands over the source code, the monetization is over. The buyer can run it indefinitely, modify it freely, and resell it to others. The creator has captured exactly one sale. Every subsequent buyer is a lost potential customer.

The moment the creator withholds the source code, the buyer loses the ability to verify, tune, or trust the strategy. They're subscribing to a black box. If the creator's server goes down, their trading stops.

Two common solutions try to navigate this. Both have well-documented failure modes.

Pattern 1: sell source

The creator sells the Pine script directly. A one-time purchase gives the buyer the .pine file.

The upside for the buyer is real: full access, full verifiability, full control. They can backtest on any data, adjust parameters, and run it independently of the seller forever.

The downside for the seller is also real. Once the source is transferred, the seller has no ongoing leverage. Piracy protection is only as strong as the buyer's goodwill. The strategy can be re-listed on other platforms, modified and sold as a derivative, or simply shared freely. Revenue is capped at the number of honest, first-time buyers.

This model works for creators who want simplicity over ongoing revenue. It doesn't work for creators whose strategies are genuinely valuable enough that they want to protect them over a multi-year horizon.

Pattern 2: sell signals

The creator runs the strategy themselves and publishes signals — entry, exit, and position size — to a feed that subscribers consume. The source never leaves the creator's control.

The upside for the seller: complete source protection, ongoing subscription revenue, no single transaction that transfers all value.

The downside for the buyer is serious. They cannot backtest the strategy on their own data. They must trust the creator's claimed historical performance. They depend entirely on the creator's infrastructure — if the creator goes on vacation, has a server outage, or decides to shut down, the buyer has nothing. The buyer also cannot tune parameters; they receive what the creator configured.

Signal services work for buyers who have no technical capability to run strategies themselves. For technical buyers who want to understand what they're running and verify it independently, the model is a non-starter.

Pattern 3: sell the compiled binary

The third pattern is the one PineForge's marketplace is built around. The Pine strategy compiles to a shared library (.so on Linux, .dylib on macOS). The creator distributes the binary, not the source. The buyer runs the binary against their own OHLCV data on their own machine, through the open-source PineForge runtime.

This addresses both sides of the tension:

For the creator: source never leaves their machine. The binary is compiled from their Pine script, but reversing a compiled .so back to readable Pine requires significant effort — and even if reversed, the result is assembly-level output, not idiomatic Pine. The strategy's core logic is materially protected.

For the buyer: backtesting runs locally on their own data. Execution uses their own broker integration. The open-source runtime is auditable — a security- conscious buyer can read the code that runs their money, even if they can't read the strategy itself. There's no dependency on the seller's server for the backtest itself.

The pattern isn't novel to PineForge. The MetaTrader 4/5 ecosystem has operated this way since MQL5 Market launched around 2012. MetaTrader strategies compile to .ex5 binaries, which are distributed account-locked and time-limited through the marketplace. Buyers backtest locally in MetaTrader's strategy tester; the source stays with the developer. It's a proven model at scale.

We're applying the same playbook to Pine, with two additions: more license-knob granularity (below), and the runtime being open-source so anyone can audit the part that executes their trades.

The license dimensions

A compiled binary without a license framework is just a file anyone can copy. The license layer is what makes the business model work.

PineForge's seller tools expose six license dimensions:

Time-bound. The license has an expiry date — days, weeks, or months from purchase. When the license expires, the binary stops executing strategies. The buyer can renew. The seller gets ongoing revenue. This is the most common dimension; nearly every marketplace strategy will use it.

Machine-bound. The license is tied to a hardware fingerprint. The buyer can run the strategy on the machine they registered, but not on a second machine or on a cloud instance. This limits the value of sharing the binary — the recipient's machine won't have a valid license. Sellers who are more concerned with scale piracy than casual sharing can enable this.

Broker-bound. The license specifies which broker integrations the strategy is allowed to execute against. A seller who has partnered with specific broker APIs can limit execution to those integrations, preventing the strategy from being used with an unsupported or undesirable execution venue.

Symbol-bound. The license restricts which ticker symbols the strategy can trade. A creator who built and validated their strategy on BTC/USDT can distribute a license that only permits that symbol. This prevents buyers from using a strategy that was optimized for one asset on a completely different asset and getting unexpected results — and blaming the creator.

Input-range-bound. The buyer can tune strategy parameters, but only within ranges the seller permits. A strategy with a lookback window parameter might allow buyers to set it between 10 and 50 bars, but not below 10 (where the creator knows it overfit heavily) or above 50 (where it becomes meaningless). The seller publishes the ranges; the runtime enforces them.

Revocable. The license server can return a 403 on the next periodic license check, at which point the binary stops executing. If a buyer is found to be violating terms — sharing the binary, running it on unauthorized hardware — the creator can revoke without issuing a refund or going through a legal process. Revocation is the nuclear option; sellers should use it only for clear violations.

What we're deliberately not doing

No DRM-style obfuscation theater. The .so is a real compiled binary. With enough time and the right tools, a skilled engineer can reverse-engineer its logic. We're not claiming otherwise. The license is the contract, not the binary format. The protection comes from the terms the buyer agreed to and the runtime's license enforcement, not from the impossibility of disassembly. Pretending the binary is unbreakable would be dishonest.

No phone-home on every backtest. License checking is periodic, not per-call. The runtime caches a valid license locally and checks the license server on a schedule (configurable per license, defaulting to daily). Backtests work offline during the license window. We don't phone home on every bar calculation. That would make backtests dependent on network availability and introduce latency for no real security benefit — an attacker who can intercept one license check can intercept a hundred.

No surprise revenue splits. The marketplace take rate is a fixed percentage published before launch. Sellers who join the waitlist know the terms before they list. We've seen marketplaces that reveal their commission structure only after a product is live — we consider that bad faith and won't do it.

Open questions we're still working through

License-key compromise. If a buyer's machine is compromised and their license key is extracted, what happens? The options are: (a) revoke and re-issue to the legitimate buyer, causing disruption; (b) maintain a per-buyer key rotation scheme where each machine instance has a distinct derived key, so compromising one machine doesn't compromise all buyers. We're leaning toward (b) but the implementation has non-trivial key management requirements.

Seller-defined input defaults alongside ranges. The input-range-bound dimension lets sellers publish the bounds for each parameter. Should sellers also be able to publish defaults — the starting value the buyer sees when they first configure the strategy? Likely yes: a seller who knows their strategy works best with a 20-bar lookback shouldn't force buyers to discover that through trial and error. The defaults would be advisory, not enforced.

Seller-published "demo backtest" reports. Before purchasing, buyers should be able to see evidence that the strategy works — not just the seller's claims. Our current plan is to allow sellers to publish a gallery-format backtest report (same schema as the gallery at /gallery) using their own data and OHLCV window. The report would be verified as produced by the PineForge engine on the stated inputs. Buyers see real trade lists, real Sharpe ratios, real sparklines — not a marketing screenshot. This is the honest version of "see it before you buy it."

The open-core alignment

One concern with compiled-binary marketplaces is that the security of the buyer's money depends entirely on the binary executor — which in most implementations is a proprietary black box. If you're running a .ex5 file in MetaTrader, you're trusting MetaQuotes' runtime and their assurance that it won't execute undisclosed behavior.

PineForge's runtime is Apache-2.0 licensed and publicly available at ghcr.io/fullpass-4pass/pineforge-engine:latest. The codegen (the part that compiles Pine to C++) is proprietary — that's where the business lives. But the executor — the code that actually runs the compiled binary against your OHLCV and produces trade lists — is open source.

This means a security-conscious buyer can audit the executor before trusting it with their backtesting. They can't audit the strategy source (that's the point), but they can audit the container that runs it. The split is deliberate: keep the part that touches real money open; keep the part that's the business moat closed.

Marketplace timeline

Beta launches Q4 2026 with manual seller onboarding — a small cohort of vetted creators, strategy listings reviewed by the team, and a streamlined purchase flow for buyers. We'll run the beta on real transactions but with a limited catalog to catch integration issues before scale.

Full self-serve marketplace opens 2027. At that point sellers can list independently, set their own license dimensions, publish demo backtest reports, and manage their catalog without team involvement.

These are honest dates, not aspirational ones. The engine and codegen exist today. The license server, seller dashboard, and buyer purchase flow are 2026 buildout.

Where to go next