Strategies

Every Dyson strategy is its own executable process built on dyson-runtime. The binary owns concrete wiring — which venue, which subjects, which sinks — while lifecycle, serialized dispatch, health, and shutdown stay in the shared runtime.

There are four strategy packages today.

Strategy	Style	Venues	Persists state
Example	Template, not a live strategy	Kuru	No
Toxic taker	Cross-venue taker (IOC)	Binance data, Kuru execution	No
Kuru quoter	Single-venue vault market maker	Kuru	Yes — position bias
Multi-venue	Shared quoter across legs	Kuru + Lighter	No

flowchart TB
    RT["dyson-runtime<br/>lifecycle, dispatch, health, shutdown"]
    EX["example<br/>reference bootstrap"]
    TT["toxic-taker<br/>signal on one venue, take on another"]
    KQ["kuru-quoter<br/>vault quoting + learned bias"]
    MV["multi-venue<br/>one actor, two legs"]

    RT --> EX
    RT --> TT
    RT --> KQ
    RT --> MV

    classDef shared fill:#2e7d32,stroke:#1b5e20,color:#fff
    class RT shared

What they share

Regardless of style, every strategy:

• Takes a deployment ID as its only argument and loads its immutable configuration version from MongoDB.
• Starts in Loaded and does not trade until a Start command arrives on strategy.commands.<deployment_id>.
• Publishes status and events to NATS, and post-trade records to InfluxDB.
• Uses the shared lifecycle — Start, Stop, Pause, Resume, Drain, Shutdown, and UpdateParams.

Any change that can alter trading behavior creates a new immutable StrategyVersion. A rollout changes the selected version_id; a restart only creates a new run_id.

What differs

The interesting differences are execution model and state:

	Whole-book replace	Per-order convergence	Takes liquidity
Kuru quoter	Yes	—	No
Multi-venue, Kuru leg	Yes	—	No
Multi-venue, Lighter leg	—	Yes	No
Toxic taker	—	—	Yes (IOC)

See State management for what each keeps across a restart.