Skip to content

Atlas Alignment — Anchor Saturation + Wallet Skew Post-S40-Equivalent

To: Atlas From: Katja Date: 2026-04-19

Context

Both Phase 7.3 pre-gate branches merged and confirmed this morning. S40-equivalent re-run (30 min paper, 1800s) just completed. Checking the real wallet before starting Phase 7.3 revealed a significant inventory problem. Looping you in before Orion investigates or we proceed.

Phase 7.3 Gate Status

Gate Status Evidence
distance_to_touch non-NULL ✅ Confirmed bid=-1465.5 bps, ask=-1476.1 bps (paper session)
inventory_invariant.status = ok ✅ Confirmed ('ok',) returned from engine_state

Gate 1 is clear. Gate 2 result coming shortly.

Finding 1 — Wallet Skew

Real wallet checked post-S40-equivalent re-run (paper sessions do not touch the wallet — these numbers reflect live session history only):

Post-Injection Baseline Now
XRP 66.82 28.00
RLUSD 97.61 154.46
XRP share (approx) ~50% ~29%

Net change: −38.82 XRP / +56.85 RLUSD. The engine has been a systematic net seller of XRP across live sessions S36, S37, and S39. Total value at current market price (~0.65 RLUSD/XRP) is approximately $172 — down from $197 at injection. The XRP depreciation accounts for much of that gap (injection was at 1.48 RLUSD/XRP), but the directional drift is a separate concern.

Finding 2 — Anchor Saturation (Paper Session)

The S40-equivalent re-run summary included this:

Anchor: mean=-10.00bps | median=-10.00bps | range=[-10.0, -10.0]
bias=negative | |err|>5bps: 100.0%

Skew: +10.0 bps (at cap) => BUY intended 20.0 bps | SELL intended 4.0 bps
(base: BUY 10 / SELL 14)

The anchor_error was pinned at −10 bps (the cap) for every single tick — not drifting, not varying, constant. The AMM price was persistently more than 10 bps above the CLOB mid for the entire 30-minute session. The engine's response was to max out the +10 bps skew for 100% of ticks, resulting in:

  • SELL orders: 4 bps from mid — tight, gets crossed frequently by real market participants in live mode
  • BUY orders: 20 bps from mid — pushed back, rarely crosses in live mode

Hypothesis — What Drove the Live Wallet Drift

If the anchor was also saturated during live sessions S36, S37, S39 (which this paper session strongly suggests is a persistent market condition, not a transient event), then:

  1. SELL orders were placed 4 bps from mid every tick → high fill rate in live mode
  2. BUY orders were pushed to 20 bps → low fill rate in live mode
  3. Fill size asymmetry compounds this: in the paper session, SELL fills averaged ~13 RLUSD each while BUY fills averaged ~7 RLUSD each — meaning each SELL fill moves ~20 XRP vs ~11 XRP per BUY fill at current prices
  4. Result: even in sessions showing more buy fills by count (S37: buy=19, sell=10), the net XRP impact may still be negative once fill size asymmetry is factored in

This is a parameter × market condition interaction, not a code bug. The anchor logic and skew logic are working exactly as designed. The issue is that anchor_max_divergence_bps: 10.0 is being saturated constantly, which was not anticipated in the original parameter design.

Secondary hypothesis (from S39 anomaly, previously flagged, not yet investigated): The S39 terminal showed 112.56 XRP inventory when the wallet had 66.82 XRP. If get_snapshot() was inflating the tracked XRP balance, the engine would have believed it was XRP-heavy and applied additional sell pressure via skew. This may have compounded the anchor saturation effect.

What Was Not Caught in the Audit

The 7-branch audit plan covered code correctness of specific components. Anchor saturation as a market condition was not in scope — the code behaves exactly as designed. However, the S39 inventory anomaly (112.56 XRP terminal vs 66.82 actual) was flagged as an open audit item and was never investigated. That may be a related signal.

Questions for Atlas

  1. Is anchor saturation expected on this pair? AMM consistently >10 bps above CLOB mid — is this a known structural characteristic of XRPL RLUSD/XRP, or does it suggest a reference price issue?

  2. Does Phase 7.3 proceed? We have a 29% XRP / 71% RLUSD wallet and an anchor that appears to be permanently at cap. Running Phase 7.3 offset calibration in this condition may not produce reliable baselines. What's your call?

  3. Rebalance first? Should we manually rebalance the wallet (or run a targeted live session with modified parameters) before proceeding to Phase 7.3?

  4. Is the S39 inventory anomaly a blocker? If get_snapshot() is inflating inventory, the engine may have been making decisions on phantom XRP throughout S36–S39. This seems like it needs resolution before more live sessions.

  5. anchor_max_divergence_bps — reconsider? If 10 bps is the cap and it's saturating constantly, the parameter is effectively non-functional. Should this be increased, removed, or replaced with a different mechanism?

Proposed Orion Investigation (Pending Atlas Direction)

Once you've reviewed, I'd like to send Orion to query the live DB for:

  • Anchor error distribution (system_metrics) across S36, S37, S39
  • Fill count and RLUSD volume by side per session (fills table)
  • Net XRP/RLUSD change per session (inventory_ledger)
  • S39 inventory anomaly — reconcile get_snapshot() vs actual ledger

Holding Orion until I hear from you.

— Katja