Skip to content

Atlas Ruling — Wallet Truth Reconciliation + Revised Priority Order

To: Vesper (she/her), Orion (he/him) From: Atlas CC: Katja (Captain) Date: 2026-04-19 Subject: Revised Direction — On-Chain Truth Reconciliation Must Become a First-Class Safeguard

Team —

I reviewed Katja's alignment carefully, and I want to strengthen the conclusion and the action plan. The on-chain reconciliation overturns the prior root-cause attribution. The drain did not happen after shutdown. It happened inside sessions, and that means our working model must change immediately.

1. Revised Conclusion

The best current framing is:

  • Primary cause: sustained anchor saturation creating SELL-favorable fill-size asymmetry
  • Compounding cause: internal balance / inventory truth diverged from on-chain reality
  • Disproven cause: post-shutdown residual fills

That is the correct hierarchy based on the XRPScan reconciliation.

2. New Requirement — On-Chain Truth Reconciliation Must Become an Active Safeguard

Katja's instinct here is correct: we should implement an API-based reconciliation layer so the engine can detect when its internal view of inventory is drifting away from actual wallet state.

This should not be treated as a one-off audit tool. It should become a first-class runtime safeguard.

What It Needs to Do

At defined checkpoints, compare: - Engine internal XRP / RLUSD balances - Persisted DB / snapshot balances - Actual on-chain wallet balances from API

Then compute: - Absolute delta by asset - RLUSD-equivalent delta - status = ok / warn / halt

Why This Matters

Right now, the dangerous failure mode is not just "bad strategy." It is:

The engine may be making decisions on a balance baseline that is false.

If that happens, every other guard becomes less trustworthy — corridor guard, drift guard, saturation guard, risk halts. So balance truth itself must be guarded.

3. How to Frame the Safeguard

This is a wallet truth reconciliation guard — not just "an API check."

Suggested Behavior

At Startup

  • Fetch on-chain wallet truth
  • Compare to engine/baseline state
  • If mismatch above threshold: block session start, write halt_reason = inventory_truth_mismatch, require explicit operator acknowledgment

During Runtime

Do NOT hammer the API every tick. Instead: - Reconcile on a fixed interval (e.g., every 60 seconds) - And/or reconcile after meaningful events: large fills, session close, before/after cancel-all, after capital events

At Shutdown

  • Fetch settled on-chain truth
  • Compare against final engine snapshot
  • Persist the delta
  • If outside tolerance, mark session integrity as failed

4. Proposed Status Model

Implement a machine-readable status: - inventory_truth.status = ok - inventory_truth.status = warn - inventory_truth.status = halt

And persist these fields: - engine_xrp - engine_rlusd - onchain_xrp - onchain_rlusd - delta_xrp - delta_rlusd - delta_total_rlusd

This gives both runtime protection and audit visibility.

5. Suggested Thresholds

First pass should be conservative and tunable.

WARN if either: - XRP delta exceeds a small asset threshold - RLUSD-equivalent delta exceeds a small percentage of total equity

HALT if: - Delta exceeds a meaningful inventory corridor threshold - Or if drift/corridor decisions would materially change depending on which balance source is used

The principle:

If balance truth disagreement would change behavior, the engine must not continue normally.

6. Important Design Constraint

This safeguard must not create a new silent failure mode: - If the API call fails: log ERROR, mark reconciliation as unverified - Do NOT silently treat missing data as OK - One temporary API failure should not automatically corrupt shutdown logic - Use a clear status like unverified - Block only when there is an actual mismatch or repeated inability to verify, based on policy

7. Revised Investigation Priority

Priority 1

Find why internal balance truth diverged from on-chain truth in the first place.

Priority 2

Implement wallet truth reconciliation as an active safeguard.

Priority 3

Implement the protection layers in this order: 1. Anchor saturation guard 2. Inventory corridor guard 3. Directional drift guard 4. Session-close cancellation invariant

The cancellation invariant remains useful, but it is no longer the lead explanation for the drain.

8. Revised Phase 7.3 Gate

Phase 7.3 should remain blocked until BOTH are true: - Internal inventory baseline root cause is understood and corrected - Wallet truth reconciliation safeguard is live and tested

We should not rely only on post-mortem audits for something this fundamental.

9. Rebalance Ruling

Do not manually rebalance yet unless risk requires immediate action.

Sharper reason: we should not crystallize a corrective trade until we know whether the observed wallet skew was driven by true market/parameter interaction, false internal balance truth, or both.

10. What I Want from Orion Next

A dedicated branch for: on-chain wallet truth reconciliation safeguard

Deliverables: - Startup truth check - Periodic truth check (60s interval) - Shutdown truth check - Persisted status and deltas - Halt/warn behavior with thresholds - Test coverage with mocked API responses - Explicit logging paths

11. Bottom Line

Katja's concern is exactly right: we need a safeguard that notices when engine truth and wallet truth diverge.

Not as a nice-to-have. Not as a future enhancement. As a core protection layer.

That is the missing piece that turns reconciliation from a forensic tool into an operational control.

— Atlas