Why local charting is safer for proprietary indicators

If you have spent years refining an indicator that gives you an edge, the question is not whether your charting platform is trustworthy. It is how many parties, systems and future policy changes stand between your script and the world. With a cloud platform the answer is "several". With local software the answer is "your disk".

Where a "protected" script actually lives

Hosted Pine platforms offer three visibility levels for scripts: open source, protected (source hidden) and invite-only. Many analysts assume protected or invite-only means private. It means something narrower: other users cannot read the source. The script itself is stored on the platform's servers, compiled on their servers and executed on their servers every time a chart renders. It is subject to their terms of service, their staff access policies, their data-retention rules, their legal jurisdiction, and any breach of their infrastructure.

None of this is a criticism of any platform's security team. It is the architecture: a platform that renders charts in a browser tab has to have your code on its side of the wire. Protection is an access-control setting on someone else's database.

What local-first changes

IndicatorSmith's engine and UI run on your machine, or on a VPS you administer. Your scripts — original Pine files, converted Python modules, indicator templates — are files in a workspace folder you choose. Nothing in the licensing or update flow uploads them. Concretely:

• The converter runs offline. Parsing and code generation happen in the local engine. The browser-based demo on this site uses the same parser compiled to run in your tab; the script text is never sent to us.
• Licence checks send a hash, not content. Activation transmits your licence key and a device fingerprint. It does not transmit file names, script contents or symbol lists.
• Update checks are optional and content-free. A GET request for the latest version number. You can turn it off in Settings → Updates and check the changelog manually.
• Exchange keys are encrypted with your OS keychain (Windows Credential Manager, macOS Keychain, libsecret on Linux) and are only ever read by the local engine process.

Threats this actually mitigates

Being specific matters more than being reassuring. Local-first storage removes these failure modes:

1. Platform breach. A compromise of the vendor's script store exposes every protected script at once. Locally, an attacker needs your specific machine.
2. Policy change. Terms of service can change what the vendor may do with hosted content — training models on it, for instance. Files on your disk are governed by nothing but your own decisions.
3. Account action. A suspended or locked account on a cloud platform means no access to your scripts until it is resolved. A perpetual local licence has no account to suspend; even if you never renew updates, the software and files keep working.
4. Insider access. Support staff and engineers at any cloud platform can, by design, reach stored content under some procedure. There is no equivalent procedure for a folder on your laptop.
5. Legal discovery in a jurisdiction you do not operate in. Hosted content is subject to the host's legal environment. Yours is subject to yours.

The data side: bring your own keys

Privacy is not only about scripts. A cloud charting platform also sees which symbols you watch, when, at what timeframes, and which alerts you set. Aggregated, that is a fairly complete picture of your strategy. With BYOK data, the exchange sees a read-only API key requesting candles — the same thing it sees from any trading terminal — and no one else sees anything. IndicatorSmith caches historical bars locally in Parquet files, so repeat loads are offline and the exchange sees fewer requests, not more.

For the same reason, we recommend read-only keys for charting. IndicatorSmith never places orders and does not need trade permissions. If you later want automated execution, keep it in a separate tool with separately scoped trading keys and hard risk guards — a deliberate separation between the tool that looks and the tool that acts.

How to move an existing script library

1. In the Pine editor of the platform that hosts your scripts, open each script and copy the source (for your own protected scripts you have access). Save as .pine files in a folder.
2. Open IndicatorSmith → Converter → Import folder. Every file is parsed and converted; the report lists anything approximated or unsupported.
3. Run the regression test where you can export reference values. See our conversion guide for the exact tolerances.
4. Delete or unpublish the originals on the platform if you want them gone from the cloud. That step is yours to decide; the converter does not require it.

From then on, your indicators are Python files. Version them with git, diff them, share them with exactly the people you choose — or with nobody.

Trading involves risk. Nothing in this post is financial or legal advice. Security statements describe IndicatorSmith's design; no software can guarantee the security of your own device.