Orbitra Prime
Trading intelligence
The Forge sits inside the Orbitra Prime workspace, so a strategy is researched, operated and monitored from the same account and risk view as manual trading. Published records feed the rankings in social trading.
Strategy ForgeOrbitra Prime
Reproducible strategy lifecycle
Research you can reproduce. Automation you can govern.
Strategy Forge is the pipeline that turns an idea into governed automation. Strategies are built in Python, Rust or no-code visual blocks, backtested on versioned data with explicit costs, stressed, paper traded, run under a Cortex policy and published. Every version accumulates a trust record that anyone it is shared with can verify. The creator’s view is on the Strategy Forge overview.
How it moves
The lifecycle and the record it writes
- 01IdeaNatural language or visual blocks
- 02BuildPython, Rust or no-code logic
- 03BacktestVersioned data and costs
- 04StressRegime and liquidity shocks
- 05PaperLive market simulation
- 06DeployPolicy-bound execution
- 07PublishPrivate, shared or marketplace
Trust record
- Version
- Code hash
- Data window
- Assumptions
- Costs
- Risk limits
- Approvals
- Execution receipts
- Realized behavior
Seven stages — Idea, Build, Backtest, Stress, Paper, Deploy and Publish — run in sequence along one path. Beneath them, a trust record fills in as the strategy advances: version and code hash at Build; data window, assumptions and costs at Backtest and Stress; risk limits and approvals at Deploy; then execution receipts and realized behavior once the strategy runs.
The problem
Why most strategy claims cannot be checked
Strategy research breaks at every hand-off. Backtests run on datasets nobody can reconstruct, trading costs are assumed away and parameters are tuned until the curve looks convincing. The code that reaches production is often not the code that was tested.
Buyers and followers inherit the problem. A marketplace listing shows a performance chart but not the data window behind it, the costs it assumed or how realized trading compares with the simulation. Reputation becomes marketing rather than evidence.
Strategy Forge binds each stage to a versioned artifact. A result can be re-derived from its inputs, a deployment is pinned to the exact code that was tested and realized behavior accumulates next to the original claims. Historical or simulated performance does not predict future results; the record makes the gap between them visible.
Operating sequence
Seven stages. One continuous record.
Each stage adds fields to the trust record. A stage that has not run stays visibly empty, so an untested strategy is never mistaken for a tested one.
- 01
Idea
Describe a hypothesis in natural language or arrange visual blocks. The Forge drafts explicit logic for review; nothing runs until the rules are explicit.
- 02
Build
Write in Python or Rust, or compose no-code blocks. The build is packaged with pinned dependencies and identified by its code hash.
- 03
Backtest
Replay the strategy over a versioned data window under a declared cost model. The same code hash, data window and assumptions always produce the same result.
- 04
Stress
Apply regime and liquidity shocks — volatility jumps, correlation breaks, depth withdrawal, price gaps — and record how drawdown and exposure respond.
- 05
Paper
Trade in live market simulation: current market data, simulated fills, no capital. Divergence from the backtest is flagged, not smoothed over.
- 06
Deploy
Run through Cortex under a policy covering capital, loss limits, leverage, markets, session, confirmation, data sources and kill. Approvals are recorded and the version is pinned by hash.
- 07
Publish
Keep the strategy private, share it with chosen accounts or list it on the marketplace. The trust record travels with every listing.
Architecture
Components of the pipeline
Every component produces or consumes versioned artifacts. That single discipline is what makes the pipeline reproducible end to end.
- 01
Authoring surfaces
A natural-language assistant, a visual block editor and Python and Rust SDKs. All three produce the same explicit strategy definition, so no authoring path is a black box.
- 02
Build packager
Freezes code and dependencies into an immutable artifact and computes its code hash. Any change, however small, produces a new version.
- 03
Versioned data catalog
Stores market data as immutable, point-in-time versions. A backtest cites the exact data window it read and cannot see information from after its simulated moment.
- 04
Simulation engine
Event-driven replay with explicit cost models for fees, spread, slippage, funding and financing. Randomized components are seeded, and the seeds are recorded.
- 05
Scenario library
Standard regime and liquidity shocks plus custom scenarios. Stress results are stored alongside the backtest rather than in a separate report.
- 06
Paper environment
Runs strategies against current market data using the same order primitives as ApexMatch, with simulated fills and no capital at risk.
- 07
Trust record store
Keeps append-only records per version, anchored by hash on Orbitra L1 and extended with Cortex execution receipts once the strategy runs.
Security and failure control
Integrity of evidence and capital
Strategy Forge protects two things: the integrity of the evidence and the capital a strategy is allowed to touch.
- Pinned versionsA running strategy is bound to one code hash. Editing it creates a new version with its own record; nothing changes silently in production.
- Isolated researchBuilds run in sandboxes with no access to signing keys and no network access beyond approved data. A strategy can place orders only through Cortex.
- Leakage guardsPoint-in-time data and recorded seeds prevent look-ahead bias and let a reviewer re-run any backtest and obtain the same result.
- Policy-bound executionRunning strategies inherit the Cortex policy engine and the Aegis gate. The one-command kill applies to them as to any other agent.
- Verifiable without disclosureA code hash proves which code ran without revealing it. Creators can publish a verifiable record while keeping their source private.
Across the three systems
How the Forge connects the three systems
Orbitra L1
Settlement and compute
Execution receipts and realized behavior come from ApexMatch evidence finalized on Orbitra L1, and each version’s record is anchored there by hash. A published record cannot be quietly rewritten.
Orbitra Realm
Applications and commerce
The marketplace in Orbitra Realm distributes strategies and bots under subscriptions and licenses. Strategy royalties and automation licenses are accounted in the AlphaStack value ledger, and approved data sources from Realm can feed research.
Value
What a verifiable record changes
- Traders and users
- Before following or subscribing to a strategy, you can inspect its data window, cost assumptions, stress results and approvals, and compare realized behavior with the simulation.
- Institutions
- Model governance is built in: reproducible research, versioned deployments, recorded approvals and a continuous trail from hypothesis to fill.
- Developers
- Build in the language you already use, publish a record that argues with evidence rather than screenshots and keep the source private if you choose. Royalty and license income varies with adoption and performance.
Specifications
Specifications
- Lifecycle
- Idea → Build → Backtest → Stress → Paper → Deploy → Publish
- Authoring
- Natural-language ideas, no-code visual blocks, Python, Rust
- Version identity
- Code hash over code and pinned dependencies
- Backtesting
- Versioned, point-in-time data windows with declared cost models for fees, spread, slippage, funding and financing
- Stress testing
- Regime and liquidity shocks, plus custom scenarios
- Paper trading
- Live market simulation with simulated fills and no capital at risk
- Deployment
- Policy-bound through Cortex, with the Aegis gate on every order
- Publishing
- Private, shared with chosen accounts or listed on the marketplace
- Trust record
- Version, code hash, data window, assumptions, costs, risk limits, approvals, execution receipts, realized behavior
Terminology
Terminology
- Trust record
- The append-only evidence attached to a strategy version, from code hash to realized behavior.
- Code hash
- A cryptographic fingerprint of a strategy’s code and dependencies. Any change produces a different hash.
- Data window
- The exact dataset version and time range that a backtest or stress test read.
- Look-ahead bias
- The error of letting a simulation use information that would not have been available at the simulated moment.
- Regime shock
- A scenario in which market behavior changes abruptly — in volatility, correlation or liquidity — instead of drifting within its historical range.