Skip to content

3. Deployed strategies and methodology

Dio separates capital decisions from order execution. The Capital Oracle resolves, per asset, whether to trade and with what parameters. The executor strategies place and manage orders from those parameters alone. Both strategies are pure executors: every sizing and activity value they consume arrives from the oracle's decision record, and there is deliberately no configuration fallback path. Before an oracle decision exists for an asset, the strategy places nothing.

3.1 The Capital Oracle

The oracle is the engine's sizing brain. Per venue, it decides order positioning and sizing for every configured strategy so that capital survives extreme drawdown while remaining maximally efficient. It is fully event-driven, and every emitted value has exactly one source of truth.

Inputs. Each asset's inputs are its all-time merged daily price series, built from the venue's own bars and extended backwards with deep-history data covering the period before the venue's first bar. There is no gap tolerance and no minimum length: short histories are valid as-is, and nothing is synthesized. Live prices come from the venue feed. Balances come from the exchange account as the source of truth, and reconciliation syncs in-process state to the exchange before the oracle reasons over it.

Reference quantities. From the merged series three references are derived. max_drawdown_pct is the single worst peak-to-trough percentage decline in the entire series, measured from a running peak of closes to the deepest subsequent low; recovery is irrelevant, so an unrecovered collapse counts at full depth. ath is the all-time high and atl the all-time low, both taken from intrabar extremes.

Runway math. With current the live price:

realized_dd    = (ath - current) / ath
runway_pct     = max_drawdown_pct * target_survival
floor_price    = ath * (1 - runway_pct)
remaining_drop = (current - floor_price) / current

Worked example: an asset with an all-time high of 100k whose worst historical decline is 92%, with target_survival 0.80, has a runway of 73.6% and a floor at 26.4k. At a current price of 70k the asset sits 30% below its peak, and the grid must fund a further fall of roughly 43.6% before reaching the floor.

Three regimes are evaluated in order. Normal, where price trades above the floor, funds the remaining drop. Floor extension, where price lives at or beyond the deepest drawdown ever recorded, extends the funding target down to the all-time low. Unprecedented lows, where price trades at the deepest drawdown and at or below the all-time low, apply maximum conservatism: minimum quantity, maximum spacing.

An aggressiveness factor, the ratio of realized decline to maximum drawdown, biases parameter selection toward tighter spacing and larger size the deeper an asset sits in its runway. Shallow positions resolve conservatively. The bias never overrides survival requirements or bounds.

Survival model. Survival is verified by replaying candidate parameters over the merged history. For each candidate pair of spacing and size, the replay walks the ladder through the funded depth, charging venue fees on both sides of every fill, including venues whose fees are taken in base currency on the buy side. The result, d_surv, is the fraction of that depth survived before the allocated quote would be exhausted. A value of 1.0 or above means the requirement is met.

Parameter search. Hardened bounds come from the strategy's own configuration entry: quantity within [qty, qty * qty_cap_mult] and spacing within [gi_min, gi_max]. Three branches are evaluated in order. Unreachable, where no candidate meets the funded-depth requirement, falls back to the conservative corner of minimum quantity and maximum spacing. Reachable selects the largest size at the tightest spacing that keeps d_surv at or above the survival target, biased by aggressiveness. Surplus, where the aggressive corner exceeds the target with quote left over, takes maximum quantity at minimum spacing. Branch flips are instant on recompute, with no hysteresis.

Decision records. Each pass emits one decision record per asset, active or not, containing exactly four values: active, grid_interval, buy_qty, and sell_qty. These values are generated by one code path and consumed everywhere; no second copy exists in the engine. Values are emitted for inactive strategies too, for visibility, pool accounting, and immediate reactivation eligibility. They are raw floats; all normalization, such as tick rounding, lot rounding, and minimum order size, happens at the exchange layer. Any diagnostics beyond these fields exist only in logs and in the standalone executable's output, never in the strategy-facing contract.

Pooling, priority, and cascades. Pools are per venue: one quote pool shared by that venue's strategies, never crossing venues. A pool equals the exchange balance, and quantities tied up in resting orders are part of the pool but unavailable for new allocation. Allocation walks strategies in configuration presentation order, first entry highest priority. Each strategy is sized against the entire remaining availability; unfundable strategies are skipped and capacity passes down, so a lower-priority strategy is never starved while quote for it exists. When a higher-priority need cannot fit available quote, the cancellation cascade cancels lower-priority resting buys until it fits, possibly many lesser orders to satisfy one greater. If no combination fits, resolution proceeds to the next-highest priority. Every cancelled strategy is re-evaluated on the same event and resumes only if quote covers its buy. Capital returning to the pool from any source triggers re-evaluation.

Runtime behavior. Decision computation is pure and in-memory, completing a full venue re-resolve in under ten milliseconds at the ninety-ninth percentile. The hot path performs no network input or output; history refreshes run in the background, and balances arrive over websocket feeds adjusted in process by fill and cancel events. Bursts coalesce into a single re-resolve. Inside the engine the oracle runs as a supervised module, heartbeated on every published pass and restarted automatically by the health monitor.

Configuration. An optional top-level oracle section exposes qty_cap_mult (default 1.5), target_survival (default 0.95), min_active_dsurv (default 0.0), refresh_seconds (default 300), and per-symbol overrides keyed by asset. Unknown keys are rejected at startup.

Standalone executable. dio-oracle runs this exact pipeline offline against configured assets and prints the decision surface, the four contract values plus internal diagnostics, without touching live balances. It is the configuration tuning entrypoint.

3.2 The Jacobs Ladder strategy

Jacobs Ladder is the primary executor. It buys price drops and sells the bought base to offset volatility drag, taking every sizing and activity value from the oracle's decision record. It retains the suicide grid risk posture described below: it knowingly removes traditional risk controls such as stop-losses, reactive hedging, and position exits, and replaces them with capital survivability constraints computed upstream by the oracle.

Core mechanism:

  • Buy placement. Exactly one resting buy sits below the current price and trails upward with it. The buy never crosses above the top bid, respects a minimum move of one tick, and moves down only to correct an actual violation of the restricted zone described next. While any sell is tracked by order management, the buy trails up only to one grid interval below the current price or two intervals below the closest sell, whichever is lower. This zone is price independent and releases only when the sell leaves tracking through fill or cancel. A fresh placement after a fill obeys the same clamp.
  • Sell placement. Every filled buy owes exactly one sell of what it bought, anchored at the fill price raised by one grid interval. Sells layer, one per filled buy, and once placed are never cancelled. Pending sells are never cancelled either; replacement applies only to previously existing levels, placed furthest out first.
  • Activity gating. When the oracle marks an asset inactive, the strategy places no new buys and amends no resting buys. The sell leg always runs, because a sell needs inventory, not quote. When inventory is first held while inactive, the leg checks whether a sell can be attempted and places it if the balance allows, so a cascading buy execution that consumed all quote resumes selling as quickly as possible. If sellable base sits below the venue minimum order size, the leg logs a warning and skips that sell; the strategy is not paused.

All orders are post-only limit orders where the venue supports the flag, with good-till-cancelled time in force stated honestly to the exchange. Orders that would cross the book are rejected rather than converted into market orders.

Why the suicide posture survives the refactor. The name describes where risk control lives, not whether it exists. A conventional grid hedges drawdowns with stop-losses or dynamic de-risking at the order level. Jacobs Ladder accepts unrestricted downside exposure at the order level while the oracle constrains aggregate risk structurally: capital is sized so the ladder cannot exhaust before funding a large fraction of the worst decline the asset has ever produced, spacing widens automatically in euphoric conditions where mean reversion weakens, and the ladder trails up resiliently on reversals, using existing sells as anchors.

Accumulation through reserved base. On profitable sell fills, the persistence layer reserves a slice of base into reserved_base. This reserve is excluded from future sell sizing, so the engine systematically grows its position in the traded asset through spread profits alone, a cost averaging mechanism funded entirely by trading gains. Because the reserve lives in a persistent store keyed by symbol and venue, accumulation survives engine restarts, and because it is applied at the persistence layer rather than through order sizing tricks, it works identically on venues with discrete lot sizing.

State persistence. Accumulation state and pending sell levels survive restarts, preventing loss of tracking during deployments or failures.

3.3 Fear & Greed adaptive threshold tuning

The accumulation_buffer is configured as a [min, max] range on every venue and resolved dynamically using linear interpolation against a sentiment index (the CoinMarketCap Crypto Fear & Greed index for digital assets, the CNN Fear & Greed index for US equities), scaled 0 to 100:

resolved_value = min + (index / 100) * (max - min)

Low sentiment trends the resolved value toward the minimum bound, lowering the accumulation threshold so the engine accumulates base more aggressively in fearful markets. High sentiment trends it toward the maximum bound, raising the threshold in euphoric markets.

Sentiment plays no other role in sizing. Grid spacing and order size are resolved exclusively by the oracle's parameter search from measured price history; there is no sentiment-derived and no configuration fallback path for either.

Runtime re-evaluation. The index is fetched at startup and cached atomically, and re-evaluated whenever the underlying asset moves a configured percentage from the baseline recorded at the last evaluation.

This produces a system whose accumulation appetite is automatically more aggressive in fearful markets and more conservative in euphoric ones, while its trading geometry remains anchored to each asset's measured history rather than to sentiment.

3.4 Adaptive Market Maker (MM)

The MM strategy serves assets with stable or pegged pricing, where the bid-ask spread provides consistent returns without directional exposure. Its activity verdict comes from the oracle: when the decision record marks the asset inactive, MM places nothing. Within an active verdict it sizes from its own configuration entry and prices from live fee data:

  • Order placement. Maintains exactly one buy order per asset. Sell orders are placed for held asset balance when exposure thresholds allow. Each order respects venue lot constraints.
  • Fee-aware pricing. The strategy computes the minimum profitable spread from the effective maker fee, fetched live through the fee cache, and compares it against the realized spread before quoting.
  • Post-only enforcement. All orders are GTC post-only limit orders. The engine only ever acts as a maker and never crosses the book as a taker.
  • Exposure limits. The strategy checks max_exposure (maximum asset balance) and min_usd_balance before placing buy orders. When either threshold is breached, quoting pauses.
  • Profitability guard. The strategy never places or amends an order if the calculated spread is less than twice the maker fee plus 0.01%. Combined with post-only enforcement, this ensures every fill is profitable.