Runtime and strategies

Each strategy is an executable process built around dyson-runtime. The binary chooses strategy logic, market-data subjects, Kuru execution, and projection wiring; the shared runtime owns lifecycle and live dispatch.

Process startup

flowchart TD
    ID["Deployment ID"]
    LOAD["Load deployment and version<br/>from MongoDB"]
    VAL["Validate strategy configuration<br/>and provenance"]
    BUILD["Build strategy engine<br/>or custom backend"]
    CONN["Connect venues, NATS,<br/>health, and projections"]
    REC["Reconcile desired lifecycle state"]

    ID --> LOAD --> VAL --> BUILD --> CONN --> REC

    classDef gate fill:#2e7d32,stroke:#1b5e20,color:#fff
    class VAL gate

Invalid configuration fails before an execution-capable runtime is created.

Runtime lifecycle

stateDiagram-v2
    [*] --> loaded
    loaded --> running: Start
    running --> paused: Pause
    paused --> running: Resume
    running --> draining: Drain
    paused --> draining: Drain
    draining --> running: Resume
    loaded --> stopped: Stop / Shutdown
    running --> stopped: Stop / Shutdown
    paused --> stopped: Stop / Shutdown
    draining --> stopped: Stop / Shutdown
    stopped --> [*]

Two details the diagram cannot show:

• Pause and Drain are two-phase. The runtime quiesces the instance and, if orders are not yet clear, reports Pending and holds the transition until a later venue poll finds them clear. The state changes only then.
• UpdateParams is not a transition. It applies a live parameter update in Running or Paused and is rejected in Loaded, Draining, and Stopped.

Draining is reversible via Resume, and Stopped is terminal — a stopped runtime is not restarted in-process. See crates/runtime/src/supervisor.rs.

State	Meaning
loaded	Process and dependencies are ready; strategy is not trading
running	Market data and venue events may produce strategy actions
paused	Process remains live without normal strategy work
draining	Runtime is winding down active work
stopped	Strategy work is stopped but the process can still report state

The runtime accepts Start, Stop, Pause, Resume, Drain, Shutdown, and UpdateParams commands. Command IDs make repeated delivery idempotent. Market data, lifecycle commands, and venue polling are serialized through one supervisor so mutable strategy state has one owner.

Current strategy packages

Strategy	Role
example	Reference composition for a standard config-driven strategy
toxic-taker	Kuru taking strategy using the shared algo-trading runtime
kuru-quoter	Kuru vault market maker with custom quoting and persisted state
multi-venue	Shared quoter across Kuru and Lighter legs — see Multi-venue strategy

The shared runtime supports both the standard algo-trading engine and a custom backend for strategies that need their own state or execution model. For where each kind of state lives and what survives a restart, see State management.

Execution and outputs

Venue adapters translate canonical strategy actions into venue operations — Kuru orderbook or vault calls, Lighter API and WebSocket requests — and normalize private order and fill updates back into strategy state. A strategy with more than one leg routes through RoutedExecutionVenue, which dispatches each request to the adapter that owns its venue. The runtime publishes status and events to NATS and exposes liveness, readiness, and metrics. Strategy-specific sinks write structured state, decisions, actions, responses, fills, and venue health to InfluxDB.