RX5Runtime Architecture
A proposed execution model for eligible Rust algorithms using the RTX5 SDK and RX5 package format. These requirements define what must be built and demonstrated before a broker enables hosted execution.
Proposed specification · Implementation and test evidence pending
From Authorized Source to a Broker-Approved Instance
Rust is the language, the RTX5 SDK supplies the proposed interfaces, and RX5 identifies the proposed package format. This architecture is a design requirement, not an available runtime or a claim of completed isolation testing.
- 01
Build in an isolated worker
Check source rights, lock dependencies and compile without broker secrets or unrestricted network access. Emit diagnostics and a traceable build manifest.
- 02
Validate and approve the package
Verify the signed artifact, permissions, version compatibility and desktop comparison results. Resolve blocking diagnostics before broker review.
- 03
Activate within account policy
Bind the approved version to one tenant/account and its risk limits. Record user consent, hosting terms, entitlement and a durable activation request.
- 04
Execute through controlled host APIs
A separate worker submits typed intent to broker-side risk and execution services. Mobile and web monitor authoritative server state and request explicit stop modes.
Package, Compiler and Runtime Isolation
RT01–RT05 define the proposed trust boundaries. Wasm isolation, host API controls and operating-system quotas must work together.
Swipe horizontally to view all columns.
| Control | Implementation requirement | Evidence required |
|---|---|---|
| RT01 · Package contract | Package a signed Wasm module or component with a manifest, requested permissions, SDK ABI version, strategy or indicator type, source and build hashes, dependency SBOM, licence and backtest compatibility metadata. | Signed example package, manifest schema, signature verification and compatibility rejection fixtures. |
| RT02 · Compiler isolation | Compile untrusted Rust and migrated source in disposable workers without broker credentials. Cargo build scripts and procedural macros require a locked dependency mirror, denied external network access and CPU, memory and elapsed-time limits. | Build-worker threat tests, dependency-lock record and worker termination logs. |
| RT03 · Runtime isolation | Separate tenant and account workers. Combine Wasm capability isolation with process and operating-system resource controls. Untrusted native dynamic libraries must never load into the trading engine. | Cross-tenant isolation tests and reviewed process/capability configuration. |
| RT04 · Capabilities | Deny filesystem, arbitrary network, process creation and environment access by default. Expose typed market-data and order APIs. Optional external data requires broker permission, a domain allowlist, timeouts, payload and rate limits, and retained provenance. | Permission schema and denied-access fixtures for each host API boundary. |
| RT05 · Resource budgets | Define fuel or epoch interruption, memory, table and instance limits, host-call deadlines, and separate log, storage, external-request and process quotas. Runtime limits must be supplemented by host and operating-system limits. | Loop, allocation, slow-host-call and handle-leak tests with other workloads measured. |
Trading Permissions, Recovery and Audit
RT06–RT11 place account authority, risk decisions and durable order state outside untrusted strategy code.
Swipe horizontally to view all columns.
| Control | Implementation requirement | Evidence required |
|---|---|---|
| RT06 · Trading permissions | Separate read-only indicators from trading strategies. Bind each deployment to a tenant, account, symbol list, permitted order types, maximum size/value and open-exposure allowance. Broker policy overrides strategy intent. | Permission-denial fixtures and a reviewed account-scoped deployment manifest. |
| RT07 · Risk controls | Enforce order rate, gross/net exposure, price deviation and daily-loss limits outside the bot. Check quote freshness and market hours, with kill switches at strategy, account, group and broker levels. | Risk rejection and concurrent-order tests, including each kill-switch scope. |
| RT08 · Idempotent lifecycle | Use request IDs, version preconditions and durable transitions for start, configure and stop. Permit one leader per bot instance and reconcile open orders and positions after a crash before resuming. | Repeated-request, leadership and crash-during-acknowledgement test traces. |
| RT09 · Failure contract | Define responses to traps, exhausted quotas, dependency failure, licence expiry, broker disconnection and missing data. Distinguish stopping new orders, cancelling pending orders and closing positions. | Failure matrix, stop-mode fixtures and trader-visible acknowledgements. |
| RT10 · Audit and replay | Retain package/configuration version, event sequence, data source and timestamp, order intent, risk decision, provider acknowledgement and execution. Give brokers audit access and traders readable explanations within tenant boundaries. | Redacted replay bundle and tenant-scoped audit access tests. |
| RT11 · Secrets and supply chain | Expose scoped opaque credentials through host APIs without embedding LP passwords in packages. Sign releases, scan dependencies, patch runtime vulnerabilities, quarantine revoked publishers and retain rollback paths. | Secret-leak checks, signature/revocation tests and rollback drill records. |
Desktop Parity, Marketplace and Operations
RT12–RT17 connect the runtime to reproducible tests, client controls, commercial consent and measured operational readiness.
Swipe horizontally to view all columns.
| Control | Implementation requirement | Evidence required |
|---|---|---|
| RT12 · Desktop test parity | Share strategy SDK and core semantics between desktop tests and server execution, while isolating deterministic simulation from live order APIs. Bind each report to data hashes, compiler/runtime versions, seed and fill model. | Matched desktop/server semantic fixtures and reproducible report manifests. |
| RT13 · Indicator scope | Define chart-only indicators separately from server indicators consumed by strategies. Mobile clients render typed plots and values through a documented protocol; an indicator must not deliver arbitrary native or UI code. | Typed rendering schema and indicator-versus-trading capability tests. |
| RT14 · Marketplace lifecycle | Define publisher verification, licence options, demo/live entitlements, trials, refunds, pinned versions, moderation, abuse reports, appeals and revocation. Security takedowns need controlled stop notifications and explicit open-position handling. | Reviewed publisher/entitlement rules and revocation incident fixtures. |
| RT15 · Hosting billing | Record the broker's price, currency, tax treatment, billing period, caps, cancellation, refunds and outage handling; obtain trader acceptance before activation. The report's US$10–20 monthly range and eligible waivers are proposals, not a published tariff. | Approved broker offer, consent record and duplicate-billing/eligibility tests. |
| RT16 · Client control | Show demo/live state, broker, account, bot version, permissions, charge, heartbeat, P&L, risk state and stop options on mobile/web. Confirm live activation and material risk increases. Authenticated notifications must not expose account secrets. | Client state/reconnect tests, activation consent and notification review. |
| RT17 · Service operations | Complete capacity and broker-isolation tests, backup/restore drills, incident response and support escalation. Establish a status dashboard and measured service objectives before publishing uptime or latency claims. | Dated load reports, restore drill, incident runbook and approved measurements. |
A Stop Request Must Explain Its Effect
Every failure and operator action needs an explicit order/position policy. A stopped strategy can still have exposure or an order awaiting provider confirmation.
Swipe horizontally to view all columns.
| Mode | Required behavior | State to show |
|---|---|---|
| Stop new orders | Block new strategy intents after the server confirms the stop; keep reconciliation and audit active. | Existing positions and pending orders remain visible. Do not imply either has been closed or cancelled. |
| Stop and cancel pending orders | Stop new intent and request cancellation of eligible outstanding orders. Reconcile fills that race with cancellation. | Show pending, confirmed and rejected cancellations until provider state is known. |
| Stop and close positions | With the required permission and confirmation, request closure according to broker execution policy. Closure can be rejected, delayed or partially filled. | Show remaining exposure and each execution result; never report flat before reconciliation confirms it. |
| Trap, quota, expiry or disconnect | Apply the documented failure policy and alert the responsible operator/trader. Resume only after reconciliation and any renewed approval. | Reason, timestamp, authoritative state, outstanding orders and the permitted next action. |
Release Only the Scope That Has Been Demonstrated
Attach the exact package, SDK, compiler, runtime, host API and broker configuration to the evidence record. Changed permissions or runtime behavior require another review.
Swipe horizontally to view all columns.
| Record | Required contents |
|---|---|
| Artifact identity | Source/build hashes, signed module/component, dependency SBOM and lock, manifest/SDK ABI, licence and requested capabilities. |
| Acceptance | Applicable AT01–AT19 results, raw fixtures, expected/actual comparisons, unresolved failures, reviewer and date. Proposed tests do not count as passes. |
| Operations | Agreed resource budgets, risk configuration, broker isolation/load evidence, rollback/restore procedure and accountable support owner. |
| User contract | Demo/live permission, accepted hosting offer, entitlement, version pin, stop policy and notifications for failure, expiry and revocation. |