TL;DR: A trading bot should run one exact, immutable version of its strategy, so the rules that trade live are the same rules you backtested and forward-tested. When strategies can be edited in place, the backtest stops describing the bot, performance can no longer be attributed, and anyone copying the strategy can be changed without notice. On Trigr, publishing creates an immutable version, agents keep the version they were deployed with, and edits produce a new version instead of rewriting the old one.
What goes wrong when a bot runs a mutable strategy?
Imagine a bot that reads its rules from a strategy you can edit at any time. On Monday you tighten a stop from 4% to 3%. On Wednesday you add a volume filter. By Friday the bot has traded three different rule sets in one week, and the backtest you looked at last month describes none of them.
That is the core problem: the evidence and the thing being run drift apart. Several specific failures follow from it.
- The backtest no longer applies. Every statistic you relied on (Sharpe, drawdown, win rate) was computed for a rule set that is no longer trading.
- Attribution becomes impossible. If live performance drops, was it the market, or the edit? With rules changing mid-stream you cannot tell.
- The forward record is contaminated. A paper or live track is valuable because it cannot have been fitted. If the rules change during the track, the early part was produced by different logic, and the record quietly becomes a blend.
- Other people are affected. If a strategy is shared or sold, an in-place edit changes what every follower runs, without their consent.
- Concurrent edits collide. If two sessions, or you and an AI assistant, edit the same strategy at once, one change can silently overwrite the other.
How does software engineering solve the same problem?
Software teams faced this decades ago. A production service does not run "whatever is on a developer's laptop." It runs a specific release, built from a specific commit, with dependencies pinned in a lockfile. Conventions such as Semantic Versioning exist so that everyone knows when a change could break them.
The same principles map cleanly onto trading strategies:
| Software practice | Trading equivalent |
|---|---|
| Immutable release | A frozen strategy version: graph, parameters and risk settings |
| Lockfile pins dependencies | A bot pins the exact version it runs |
| Tests run against a specific commit | A backtest is attached to a specific version |
| New code means a new release | An edit means a new version, not a rewrite |
| Rollback to a known-good release | Restore an earlier version |
| Merge conflicts are detected | Concurrent edits fail instead of overwriting |
The analogy is not perfect. Code either passes its tests or it does not, while a strategy's statistics are noisy estimates. That makes versioning more important for trading, not less, because noisy evidence is only useful if you know exactly what it measured.
What should a strategy version capture?
A useful version freezes everything that decides a trade:
- The logic. Triggers, filters and signal direction, including any cross-asset inputs.
- The parameters. Every lookback, threshold and timeframe.
- The risk settings. Position size, leverage, max concurrent positions, stop-loss and take-profit, trailing stops and time stops.
- The evidence. The backtest and its assumptions (costs, fills, date range) computed for that exact version.
If any of those can change without creating a new version, the version is not really pinned.
How does Trigr version strategies?
Trigr treats versions as a first-class part of the product rather than an afterthought.
Published versions are immutable
A strategy moves from draft to running (its canonical paper track starts accruing a forward record) to published. Each publish snapshots the node graph and its statistics into an immutable version. Editing a published strategy creates a fresh draft, and republishing creates a new version rather than mutating the old one. Publishing also requires a stored, verified full-history backtest, so every public version carries evidence computed for it. The marketplace docs describe the lifecycle.
Agents and subscribers stay pinned
Agents keep the version selected when they were deployed. If the creator publishes version 3 while your agent runs version 2, your agent keeps running version 2. A version cannot be deleted or hard-edited while any agent uses it; a creator can unlist a strategy, and existing users stay pinned. The recipe itself stays private: the marketplace shows the verified record, never the node graph. (New strategy subscriptions are disabled during the beta.)
For AI assistants connected over MCP, the same rule is explicit: agent slots bind immutable logic, either the current recipe hash of an owned strategy or the pinned version ID returned by a marketplace search, as the agents and MCP API docs describe.
The public track hands over cleanly
Each running strategy keeps a canonical paper track, one system-run forward record used for its live performance figure. When a new version is published while the previous version still has an open trade on that track, the previous version finishes closing its trades before the new version takes over. A trade opened under one version is closed under that version's rules.
Edits are guarded against collisions
Drafts are saved with a recipe hash. A save or publish must present the current hash, so if the strategy changed since you (or your AI assistant) last read it, the write fails safely instead of overwriting someone else's change. Can you trust a strategy an LLM wrote? covers why this matters when an assistant is editing.
Iteration happens inside one strategy's history
When you iterate, the Copilot records labelled experiments (Experiment 1, 2, 3 and so on) inside one strategy's version history, and any version can be restored. Over MCP, a backtest with an experiment label is recorded in the version history without changing the saved recipe or its current verified statistics; only an explicit save promotes a winner. The workflow is described in iterating on a strategy with AI experiments.
Why does version history help against overfitting?
Versioning is usually sold as a safety feature, but it is also a research-hygiene feature. Every variant you test is a trial, and the more trials you run, the more likely your best result is luck. Bailey and López de Prado's Deflated Sharpe Ratio formalizes this by discounting a Sharpe ratio for the number of trials.
When experiments live inside one strategy's history, the count stays visible. When every variant becomes a separate strategy, the count disappears into a cluttered list, and it becomes tempting to publish the luckiest one. In Trigr, an ML optimization run reports DSR using its trial count; a plain backtest does not compute DSR, which is one more reason to keep an honest record of how many variants you tried.
How should you manage upgrades to a running bot?
Pinning does not mean never changing. It means changing deliberately.
- Iterate on the strategy, not the bot. Test changes as experiments while the agent keeps running its pinned version.
- Promote a winner only with evidence. Compare the new version net of slippage and funding, and against the number of variants you tried.
- Forward-test the new version. Run it on a paper agent alongside the live one for a meaningful number of trades.
- Switch as a discrete event. Note the date, so the live record has a clean boundary between versions.
- Keep the old version restorable. If the new one disappoints, you can go back to a known rule set rather than reconstructing it from memory.
The same discipline applies to marketplace strategies you run. A creator's new version is a new strategy as far as your evidence is concerned; judge it on its own record. Why verified, versioned backtests matter goes into how to evaluate marketplace listings.
What does pinning not protect you from?
Pinning fixes the rules, not the world. Live results can still diverge from the backtest because of:
- slippage and funding, which are opt-in and off by default in a Trigr backtest,
- regime changes that the historical sample did not contain,
- venue constraints such as minimum order sizes,
- simple bad luck over a short sample.
What pinning removes is one avoidable source of divergence: running rules that were never tested. Backtests are not guarantees, and leveraged perpetual futures can lose more than you expect.
Next steps
Deploy a pinned version as a paper agent first, then follow the path from backtest to a live Hyperliquid agent. To see immutable, versioned strategies with verified records, browse the strategy marketplace.