Skip to content

Orion Investigation Request — S40 Blockers

To: Orion CC: Katja, Atlas From: Vesper Date: 2026-04-19

Summary

S40 ran cleanly (1800s, 316 ticks, 84 fills, VW +12.47 bps, halt=duration_elapsed). Two blockers found on DB inspection that prevent the Phase 7.3 gate from clearing and the overnight sweep from running. Both require Orion investigation before Phase 7.3 can proceed.

Blocker 1 — inventory_invariant.status not written to engine_state

What the gate requires

Atlas locked a hard inventory invariant at shutdown (Pre-7.3 Audit Review). The S40 gate is: inventory_invariant.status=ok before Phase 7.3 unlocks.

What the DB shows

The key does not exist in engine_state at all after S40:

SELECT key FROM engine_state WHERE key LIKE '%invariant%';
→ (0 rows)

Full engine_state dump confirms no invariant-related keys were written. Session closed cleanly via duration_elapsed — so shutdown did execute. But the invariant status was never recorded.

What Orion needs to determine

  1. Is the hard inventory invariant check implemented? If so, where does it run and why isn't it writing to engine_state?
  2. If it's not implemented yet, this is a missing pre-7.3 gate item that needs a branch.
  3. What key name and table should the result land in so the gate can be verified programmatically?

Blocker 2 — distance_to_touch_bid/ask_bps always NULL in paper mode

What Phase 7.3 requires

Atlas declared distance_to_touch the primary Phase 7.3 metric. Branch #6 (feat/distance-to-touch-diagnostic) added distance_to_touch_bid_bps and distance_to_touch_ask_bps columns to system_metrics and wires per-tick computation from live resting orders.

What the DB shows

SELECT COUNT(*) FROM system_metrics
WHERE session_id=2 AND distance_to_touch_bid_bps IS NOT NULL;
→ 0 / 316 ticks

The columns exist and rows are present (316 rows for session 2). All NULL.

Root cause hypothesis

Paper mode (dry_run=true) does not place real orders on the XRPL CLOB. The Branch #6 implementation computes distance_to_touch from the engine's live resting order queue position. With no real orders on-chain, queue.bid.our_offer_found=false and queue.ask.our_offer_found=false on every tick → distance_to_touch is NULL every tick.

Confirmed from engine_state: 

queue.bid.our_offer_found: false
queue.ask.our_offer_found: false

What Orion needs to determine

  1. Confirm or refute the hypothesis: does the distance_to_touch computation path require our_offer_found=true? Show the code path.
  2. If confirmed: what are the options?
  3. Option A — Intended distance: compute distance_to_touch as (our_intended_price - best_bid/ask) / mid * 10000 on every tick, regardless of whether we're on-chain. Available in paper mode. Not a queue position metric.
  4. Option B — Live only: accept that distance_to_touch only populates in live sessions. Phase 7.3 offset calibration runs live (testnet or mainnet). Paper sweep is dropped.
  5. Option C — Hybrid: compute intended distance in paper mode, label it differently (e.g., intended_distance_to_touch_bid_bps), use it as proxy for paper sweeps with explicit caveat.
  6. Recommendation on which option to bring to Atlas.

Supporting context

Testnet market conditions during S40: 

market.best_bid:  0.5541
market.best_ask:  0.7475
market.clob_vs_amm_divergence_bps: 307.05
anchor.pct_cap_applied: 100.0  (cap fires every tick)

The CLOB spread is ~3000 bps on testnet right now. This is not representative of mainnet (4–8 bps). Even if distance_to_touch were populated, S40 testnet data would not be meaningful for mainnet offset calibration. Orion should note this in the investigation so Atlas can factor it into the Phase 7.3 design decision.

What Vesper needs back

  1. Confirmation or refutation of Blocker 1 (invariant status key): implemented or not?
  2. Confirmation or refutation of Blocker 2 root cause, with code path
  3. Recommended option for distance_to_touch in paper mode (A / B / C or something else)
  4. If any code changes are needed: branch name, scope, estimated complexity

Standing by.

— Vesper