How to protect a NinjaTrader strategy from sharing

Every NinjaTrader vendor faces the same problem: a strategy file can be copied in seconds. This guide explains the protection layers that actually work — written by a vendor who ships with them — and is honest about what none of them can do.

Layer 1: never ship source code

Raw .cs files can be read, edited, and re-shared by anyone. Export the strategy as a compiled assembly instead. Buyers get a finished product they can import and run, not the recipe. On its own this stops casual copying from becoming casual editing — but a compiled file can still be forwarded as-is, which is why the next layers exist.

Layer 2: licence keys tied to the Machine ID

NinjaTrader gives every computer a unique Machine ID. The robust pattern is a key derived from that ID with a one-way cryptographic function (for example, an HMAC over the machine fingerprint, keyed with a vendor-only secret). The strategy verifies the key locally, on the buyer's machine:

The key unlocks the strategy on exactly one computer.
The same key pasted into a friend's NinjaTrader simply fails — nothing to "crack" in the file, because the valid key for that machine was never issued.
Verification is offline, so legitimate buyers are never locked out by a server outage.

Layer 3: bind the order, not just the buyer

Keys alone don't stop a buyer from requesting a second key "for my other PC" and handing it to someone else. The fix is to bind each order number to one machine in the vendor's system:

A first activation binds the order to that machine, permanently and visibly.
A request from a different machine on the same order is flagged, never auto-approved — the vendor sees the original machine, the new machine, and decides.
Genuine computer changes are approved as a licence move, and every move is logged (old machine, new machine, timestamp).
Denying a move restores the buyer's original licence untouched, so a refused request costs the real buyer nothing.

This turns sharing from an invisible act into a visible, attributable one — which is what actually deters it.

Layer 4 (optional): code protection tools

.NET protection tools (obfuscators and packers such as Agile.NET) raise the cost of reverse-engineering a compiled assembly. They are a real layer, but understand the trade: they add build complexity and occasional false-positive friction with antivirus tools, and they do nothing by themselves to stop file sharing — a protected file forwards just as easily as an unprotected one. Obfuscation protects the code; licensing protects the sale. Confusing the two is the most common vendor mistake.

The honest limits

No protection is absolute. A determined reverse-engineer with time can attack almost any client-side lock, and an offline key cannot be remotely revoked once issued. What the layers above do is remove every casual path: the file alone is useless, the key alone is useless, and a second machine is visible. For a commercial strategy, that is the difference between a product and a donation. Vendors who promise "unbreakable" protection are selling you the same fiction some buyers sell themselves about returns.

How SI-Trader ships

SI-Trader uses the compiled-export + Machine ID key + order-binding layers described here: buyers activate through a portal with their order number and Machine ID, one order binds to one machine, and licence moves are explicit and logged. If you are a buyer, the practical side of all this is on the activation guide. If you are a vendor, steal this playbook — it is the one that works.