Atlas Alignment — Wallet Skew Post-Live Runs: Investigation Direction + Missing Protection Layer¶

To: Vesper (she/her) From: Atlas CC: Katja (Captain), Orion (he/him) Date: 2026-04-19 Subject: Wallet Skew Post-Live Runs — Investigation Direction + Missing Protection Layer

Vesper —

I want to correct and sharpen my earlier read.

Katja is right to push back on the idea that this was simply the engine "always being a net seller." If the earlier live runs were balanced and the wallet only became materially skewed later, then this is not a timeless property of the engine. It is a new regime-specific or state-specific failure.

That distinction matters.

1. Revised framing¶

This should now be investigated as:

a new deviation from previously balanced live behavior

not:

a permanent engine trait we somehow missed from the beginning

That means the correct question is not "why does the engine always do this?"

The correct question is: What changed that allowed this to happen now?

2. Most likely change candidates¶

Persistent anchor saturation under the newer market regime
Post-injection parameter interaction (size / skew / cap)
Fill-size asymmetry overwhelming fill-count balance
S39 inventory anomaly causing the engine to perceive phantom XRP and apply additional sell pressure
Or a combination of the above

I do not want us to collapse these into one explanation prematurely.

3. Immediate conclusion¶

Phase 7.3 does NOT proceed yet.

Also: - No more live sessions - No overnight calibration - No manual rebalance tonight unless risk forces it

We need root cause first.

4. Investigation order (locked)¶

Please send Orion in this order:

A. Session-by-session wallet drift reconstruction¶

For S36, S37, and S39: - Starting wallet XRP / RLUSD - Ending wallet XRP / RLUSD - Net change in XRP - Net change in RLUSD - Total RLUSD-equivalent delta

Goal: Identify exactly which session(s) created the skew and by how much.

B. Fill count vs fill size asymmetry¶

Per live session: - Buy fills by count - Sell fills by count - Buy fills by RLUSD notional - Sell fills by RLUSD notional - Net XRP moved by side

Goal: Determine whether "balanced count" was hiding unbalanced notional flow.

C. Anchor saturation distribution¶

Across S36, S37, S39: - Mean anchor error - Median anchor error - % ticks at cap - % ticks beyond reliability threshold - Bias direction by session

Goal: Prove whether wallet drift correlates with persistent saturated regimes.

D. S39 inventory anomaly reconciliation¶

This is a blocker.

Compare for S39: - get_snapshot() inventory - Terminal/session summary inventory - inventory_ledger balance - Actual wallet balance

Goal: Determine whether the engine was making decisions on inflated / phantom XRP state.

If the anomaly is real, it is not cosmetic — it is causal until disproven.

5. Missing protection layer (this is important)¶

Katja is also right about this. We clearly do NOT have the right protection layer for this failure mode.

We had: - Exposure caps - Momentum filter - Risk halts - Inventory logic

But we did NOT have protection against:

slow, persistent one-direction wallet leakage under a saturated regime

That is a different class of failure.

6. What protection layer is missing¶

We need a dedicated wallet-state protection layer that sits above ordinary exposure caps. At minimum, I want the design work started for all three of these:

A. Inventory corridor guard¶

Halt or change regime if XRP share drops below a defined floor, or rises above a defined ceiling. This protects the actual wallet composition, not just absolute exposures.

B. Persistent directional drift guard¶

If the wallet moves in one direction for too long, stop. Examples: N consecutive sessions net-selling one asset; persistent net notional imbalance above threshold; monotonic movement away from target allocation.

C. Anchor saturation guard¶

If anchor is pinned at cap for too high a percentage of ticks, the engine must not continue normal quoting. Examples: reduce quoting, flip to a safer regime, or halt and alert.

This is the protection we thought we effectively had, but clearly did not.

7. Important distinction¶

The correct answer is NOT simply "raise or lower a parameter and continue." That would be too shallow.

We need: - Root cause trace - Exact session attribution - Proof of whether state mismatch was involved - Then a protection layer so this cannot silently happen again

8. Rebalance decision¶

Do NOT rebalance immediately unless we determine that continuing to hold the skew is itself unacceptable risk.

Reason: a manual swap right now may lock in damage before we understand whether the engine state was wrong, the drift was caused by a specific live bug, or the drift was purely market + parameter interaction.

We need facts first.

9. Final call¶

Please treat this as: - Investigation priority #1 - Production blocker - Architecture issue, not just a tuning issue

Frame the report back like this: 1. What changed 2. When it changed 3. How much it changed the wallet 4. Whether internal state matched reality 5. What exact protection layer would have stopped it

That last point matters most. Because I agree with Katja completely: we need to trace the cause, fix it, and make sure it never happens again.

— Atlas