turbine-strategy

What this skill does

# 🌪️ TURBINE v3.3 — Volume Rotation + Runners

**Run the volume play. Let winners run.**

## What changed in v3.3 vs v3.2.2 (2026-05-14)

**Budget upgrade for $3-4M/day target.** v3.2 was empirically verified at $2M/day over 3 consecutive days at <$150/$1M cost. To double volume without expanding the asset universe (which would force lower-tier coins with wider spreads and break the cost efficiency), v3.3 doubles margin/slot on the same 7 high-liquidity assets.

| Setting | v3.2 | v3.3 |
|---|---|---|
| Volume wallet budget | $4,000 | **$5,400** ($4,900 active + $500 buffer) |
| Runners wallet budget | $1,900 | **$2,600** (full active, $0 buffer) |
| Volume margin/slot | $500 | **$700** ($3,500 notional at 5x) |
| Runners margin/slot | $950 | **$1,300** ($6,500 notional at 5x) |
| Slots (volume / runners) | 7 / 2 | 7 / 2 (unchanged) |
| Asset universe | BTC/ETH/SOL/HYPE + xyz:BRENTOIL/GOLD/SPX | Same (unchanged — would break cost target if expanded) |
| Daily volume target | $2M (verified) | $3-4M (modeled) |
| Cost target | <$150/$1M | <$150/$1M (preserved) |

NO change to scoring, asset universe, DSL preset, risk gates, or producer code. Pure margin/budget scaling — every other knob preserved verbatim.

**New documented learnings from v3.2 prod operation:**

1. **DSL exit engine going offline causes slot starvation.** When runtimes die, the 10-min volume hard-cut stops firing, positions stay open past timeout, available margin drains → `slots_effective` collapses from 7 → 1-2. Symptom: rapid slot decay in hours, not days. Fix: re-register the dead runtime BEFORE topping up the wallet. Documented in README troubleshooting.
2. **Orphaned ALO orders persist across daemon restarts.** Any runtime swap or daemon restart can leave non-reduce-only ALO orders resting on the books — the v3.2.1 sweep clears them on the next tick, but a clean restart procedure (cancel-stale → relaunch) is now standard. Documented in README "Restart procedure".

## What changed in v3.2.2 vs v3.2.1 (patch — 2026-05-09)

**Dex-aware slot keys.** `normalize_coin_key()` previously stripped the `xyz:` prefix from coin names, collapsing main and xyz versions of the same symbol into one held_keys entry. When a main position and an xyz resting order on the same symbol both existed (or vice versa), the producer undercounted slots → over-emitted signals → runtime rejected the surplus on margin. v3.2.2 preserves the prefix: `main:HYPE` and `xyz:HYPE` are now distinct keys.

Symptom in v3.2.1 (verified from operator's tick logs): `slots_held = 4` while `positions + resting = 5` on ticks where main and xyz versions of the same coin coexisted. Producer over-emitted by 1 on those ticks.

NO change to maker/taker placement. NO change to fee economics. NO change to YAMLs. One-time minor regression: 90s post-close cooldown skipped for the first 1-2 cycles after upgrade as `last_closed` repopulates with new-format keys. Trivial impact.

## What changed in v3.2.1 vs v3.2.0 (patch — 2026-05-09)

**Stale-order hygiene.** The producer now sweeps non-reduce-only ALO orders older than 300s before computing `held_keys`. Each runtime swap (helpers migration, runtime redeploy, daemon restart) leaves resting maker orders behind that the new runtime instance does not own; the producer's ghost-trade fix (v2.0.4) correctly counts those orphans as slot occupiers, which means orphans can starve real fills until cleared. The runtime's own `execution_timeout_seconds: 180` cancels orders it placed — anything still resting well past that is by definition abandoned.

NO change to maker/taker placement. NO change to fee economics. NO change to YAMLs. Cancellation is free; HL only charges on fills. Symptom in v3.2.0: volume wallet showed `slots_held = 6/7` while `clearinghouse` only reported 4 actual positions, throttling emissions to 1 signal/tick instead of 3-4.

Tick output now includes `volume.stale_swept[]` and `runners.stale_swept[]` arrays for telemetry — empty list = no orphans on this tick.

## What changed in v3.2 vs v3.1

v3.1 modeled the second wallet as a **HYPE-only momentum specialist**. Wrong abstraction:

- Hunt mode (HYPE 4H breakouts) fired ~1-3 times per day at most
- Hunt wallet's $2,400 sat idle ~90% of the time
- No volume contribution from the second wallet
- A single wallet can't hold the same HYPE position twice, so 2 hunt slots was effectively 1

v3.2 fixes the design intent. Both wallets run the **same volume rotation** (same scoring, same assets, same funding-fade direction). The DSL preset on each wallet picks the exit profile:

| | Volume wallet | Runners wallet |
|---|---|---|
| Entry signals | Volume rotation | **Volume rotation (same)** |
| Asset universe | BTC/ETH/SOL/HYPE + xyz:BRENTOIL/GOLD/SPX | **Same** |
| Direction | Funding fade | **Same** |
| Leverage | 5x | 5x |
| `hard_timeout` | **10 min** | 240 min (4h cap) |
| Phase 2 ratchet | DISABLED | **ENABLED** (5/0, 10/35, 20/55, 35/75, 50/85) |
| `weak_peak_cut` | DISABLED | 90 min @ peak < 3% |
| `dead_weight_cut` | DISABLED | 120 min |
| Phase 1 max_loss | 50% (catastrophic only) | 30% |

The same rotation alpha goes to both wallets. The runners wallet's DSL gives positions room to ratchet through tier-1/2/3/4 instead of being force-cut at 10 min. Most positions on the runners wallet still exit early (Phase 1 max_loss or weak_peak_cut). The ~5% that land on a real move are what justify the patient DSL.

## Why two wallets at all

The senpi-trading-runtime plugin enforces **one runtime per wallet**. v3.0 attempted to attach two runtimes to a single wallet and got blocked at deploy. v3.1 split into two wallets but rebuilt them with the wrong thesis (HYPE specialist). v3.2 keeps the two-wallet split and rewires both to the right thesis (same volume rotation, different DSL).

## Mission

Hit **$5M/day in notional volume on Hyperliquid at <$100 net cost per $1M** while letting occasional winners ride for bigger ROE.

| Metric | v2.0.x baseline | v3.2 target |
|---|---|---|
| Daily volume | ~$2-3M | $5M+ |
| Net cost per $1M volume | $200 | <$100 |
| Total slots | 3 | 9 (7 vol + 2 runners) |
| Volume cycle | 15 min | 10 min (auto-fallback to 12 min) |
| Total funding | $1,500 | **$5,900** ($4,000 vol + $1,900 runners) |

## Architecture

```
              turbine-producer.py (long-lived daemon)
                     │
            ┌────────┴────────┐
            │                 │
     reads volume       reads runners
       wallet             wallet
            │                 │
            ▼                 ▼
     emits to:         emits to:
   turbine_volume     turbine_runners
     _signals          _signals
            │                 │
   turbine-volume-     turbine-runners-
        tracker           tracker
            │                 │
            ▼                 ▼
      VOLUME WALLET     RUNNERS WALLET
      ($4,000)          ($1,900)
```

ONE producer reads both wallets, emits the same kind of volume-rotation signals to each. Each runtime attaches to its OWN wallet (constraint satisfied) and applies its own DSL preset to positions it opened.

## Volume rotation (shared alpha on both wallets)

### Universe

| Pool | Assets | Weight |
|---|---|---|
| XYZ (deeper books, lower fee floor) | xyz:BRENTOIL, xyz:GOLD, xyz:SPX | **80%** |
| Main | BTC, ETH, SOL, HYPE | 20% |

### Direction — funding fade

```
LONG_CROWDED  → SHORT (collect funding)
SHORT_CROWDED → LONG  (collect funding)
NEUTRAL/FLAT  → coin-flip per cycle
```

### Spread gates

| DEX | Setting |
|---|---|
| main | 3 bps |
| xyz | 10 bps |

### Cycle length — 10 min default with auto-fallback

```
10 min default
  ↓
If realized maker fill rate (last 20 entries) < 85%:
  ↓
Fall back to 12 min until rate recovers
```

State tracked in `state/<volume-wallet-hash>/cycle-stats.json`. Operator overrides via `cycle.*` keys in `turbine-config.json`.

### Volume cost math

```
Theoretical (perfect maker on both legs):
  +3.5 bps  builder fee recycling (RT)
  −1.4 b