Atlas Alignment — On-Chain Reconciliation: Orion's Analysis Was Wrong¶
To: Atlas From: Katja CC: Vesper, Orion Date: 2026-04-19
Executive Summary¶
We ran a full on-chain reconciliation using XRPScan's transaction API with complete AffectedNodes metadata. The results overturn Orion's investigation almost entirely.
What Orion concluded: - 90.6% of drain (~35 XRP) happened post-shutdown from residual orders filling on-ledger - In-session drift = only −3.63 XRP - Root cause: missing session-close order cancellation invariant
What the on-chain data actually shows: - Zero transactions after S39 close at 21:11Z Apr 18 — Orion's post-shutdown hypothesis is definitively false - Total drain = ~−40 XRP, all within sessions - The DB's sessions table was systematically reporting inflated XRP balances throughout — the "−3.63 XRP" figure is wrong - Root cause: fill-size asymmetry under sustained anchor saturation, operating the entire time on an incorrect internal balance baseline
On-Chain Balance Timeline (Source: XRPScan API, Full Metadata)¶
| Time (UTC) | Event | On-Chain Balance |
|---|---|---|
| Apr 17 20:01Z | Pre-injection session close (OfferCancel) | 34.306 XRP |
| Apr 17 23:55:20Z | Capital injection received (+35.21 XRP) | 69.516 XRP |
| Apr 17 23:57:11Z | Massive fill event: −52.11 XRP in 90 seconds | 17.406 XRP |
| ~Apr 18 00:05Z | Buy-back fills recovered ~+51.4 XRP | ~68.4 XRP |
| Apr 18 00:08Z | Small payment out (0.39 XRP, AMM-related) | 68.020 XRP |
| Apr 18 01:03Z | Session close (OfferCancel) | 41.613 XRP |
| Apr 18 01:17Z | Session close | 42.288 XRP |
| Apr 18 04:18Z | Session close | 38.252 XRP |
| Apr 18 18:35Z | Session close | 45.202 XRP |
| Apr 18 20:40Z | Session close | 43.065 XRP |
| Apr 18 21:10–21:11Z | S39 final close (last on-chain transaction) | 29.422 XRP |
Total drain from injection to S39 close: 69.516 − 29.422 = −40.09 XRP
(Atlas reported −38.82 XRP net; ~1.3 XRP difference accounted for by outgoing AMM-related payments totaling ~0.81 XRP + accumulated tx fees)
There are no on-chain transactions after 21:11Z. The wallet has been static since S39 shutdown. This is confirmed.
Finding 1 — Orion's Post-Shutdown Hypothesis: DISPROVEN¶
Orion attributed ~90.6% of the drain (~35 XRP) to residual orders filling after engine shutdown. This is wrong. The on-chain ledger records zero transactions of any kind after the S39 OfferCancel at 21:11Z. No offers filled, no payments occurred, no balance movement. The wallet has been static at 29.422 XRP since the moment S39 closed.
The drain is entirely within sessions.
Finding 2 — DB Sessions Table Was Systematically Wrong¶
Orion's analysis was built on the sessions table's starting_xrp and ending_xrp columns. Those values were wrong from the beginning.
On-chain reality vs. what the DB reported:
| Metric | DB (sessions table) | On-Chain (actual) |
|---|---|---|
| S33 starting XRP | 76.92 XRP | ~69.52 XRP (just after injection) |
| S39 ending XRP | 73.29 XRP | 29.42 XRP |
| Initial over-reporting | +7.40 XRP | — |
| Cumulative error by S39 close | +43.87 XRP | — |
The DB over-reported by 7.4 XRP from the start and grew to 43.87 XRP by S39. The engine's get_snapshot() was reading from internal inventory tracking, not from on-chain account_info. That internal tracking had a wrong baseline and drifted further with each session as fill-size asymmetry went undetected.
The consequence: Orion's "−3.63 XRP in-session drift" figure reflects the change in the internal tracking state, not the actual on-chain change. The real in-session drain was ~−40 XRP.
Finding 3 — The Biggest Damage Happened Right After Injection¶
The session running at the time of injection (let's call it S33) produced the most damage.
What happened: - Pre-injection balance: 34.306 XRP - Injection received at 23:55:20Z: +35.21 XRP → balance 69.516 XRP - 90 seconds later (23:57:11Z): balance 17.406 XRP → 52.11 XRP sold in 90 seconds - Over the next 11 minutes: buy-back fills recovered ~51.4 XRP → balance ~68.4 XRP - Over the subsequent ~55 minutes: −26.4 XRP in ongoing fills - Session close at 01:03Z: 41.613 XRP
Net for S33 (injection through session close): −27.9 XRP from fills
The 52.11 XRP sell event is consistent with a large counterparty sweep of accumulated resting orders. The engine had been placing SELL offers throughout the session. Anchored at −10 bps cap (AMM > CLOB), those SELL offers were priced 4 bps from mid — tight enough that a single large market buy could consume all of them at once. The buy-back of 51.4 XRP in 11 minutes is consistent with the engine switching to BUY mode and filling against available liquidity.
Finding 4 — S39 Was Much Worse Than the DB Showed¶
The DB reports S39 as 4 buys / 4 sells, VW +3.69 bps, ending 47.79% XRP. Sounds balanced.
On-chain reality:
- Balance at S38 close (20:40Z): 43.065 XRP
- Balance at S39 close (21:11Z): 29.422 XRP
- Net change: −13.64 XRP in 30 minutes
Four buys and four sells cannot produce −13.64 XRP in net XRP unless the sell fills were dramatically larger than the buy fills in XRP terms. At anchor cap (−10 bps), sell orders are placed 4 bps from mid and buy orders 20 bps from mid — the sell fills are not just more frequent, they're larger in XRP-per-fill terms because the price mechanics favor sells being consumed at a higher size.
This is the fill-size asymmetry hypothesis from the anchor saturation framing — and S39 is the clearest confirmation of it.
What Needs to Change in the Orion Analysis¶
Orion's investigation concluded with four protection layers, three of which were correct in direction but wrong in attributed cause:
| Protection Layer | Orion's Framing | Correct Framing |
|---|---|---|
| Inventory corridor guard | Correct (needed) | Same |
| Directional drift guard | Correct (needed) | Same |
| Anchor saturation guard | Correct (needed, labeled secondary) | Primary cause |
| Session-close order cancellation | Labeled primary root cause | Still useful, but NOT the cause of this drain |
The session-close cancellation invariant is worth building — but it was not the cause of the drain. We didn't have residual orders filling. We had anchor-saturated sessions consuming XRP through fill-size asymmetry.
Open Questions for Atlas¶
1. Revised root cause attribution¶
Given the above, do you agree that the primary root cause is:
Sustained anchor saturation at −10 bps cap causing persistent SELL-favorable fill-size asymmetry, operating on top of an internal inventory tracking baseline that was wrong from the start.
And that Orion needs to re-investigate why get_snapshot() was reporting 7.4 XRP more than the actual on-chain balance from the very beginning of S33?
2. The 52 XRP sell sweep — worth investigating¶
The 90-second, 52.11 XRP sell event immediately after injection is either: - A single large counterparty sweeping accumulated resting offers, or - Something about the injection itself triggering an order book event
Either way: the engine had no awareness this happened. That's a gap. Should Orion investigate the specific transaction(s) that caused this sweep and determine whether it was a normal market event or something we could protect against?
3. Phase 7.3 sequencing — does Orion's proposed order still hold?¶
Orion's proposed order was:
1. On-ledger reconciliation ✅ (done — wallet stable, drain confirmed within sessions)
2. feat/anchor-error-per-tick-telemetry — anchor per tick in system_metrics
3. Protection layers 1–3 (corridor, drift, anchor saturation guards)
4. Protection layer 4 (session-close cancellation invariant)
5. Phase 7.3 re-runs only after all four layers live
This sequencing is still correct in order but the priorities shift: anchor saturation guard moves to highest priority, and the cancellation invariant drops from "dominant root cause" to "useful defensive layer." Do you want Orion to reorder accordingly?
4. DB tracking reliability¶
The fact that all internal tools (sessions table, valuation_snapshots, inventory_snapshots) agreed with each other but were all 43.87 XRP off from on-chain reality is a deeper infrastructure concern. This is not just a display bug — the engine was making trading decisions based on a balance that was wrong by an order of magnitude relative to the actual drift.
Is fixing the inventory tracking baseline a Phase 7.3 gate, or do we accept that the protection layers (which operate on relative drift, not absolute balance) will compensate?
5. Rebalance decision — unchanged¶
Wallet is at 29.422 XRP / 154.46 RLUSD. Drain has stopped. No live sessions until protection layers are in place. Still requesting your ruling: manual rebalance before Phase 7.3, or let the engine rebalance naturally once protections are live?
Summary Verdict¶
Orion's investigation was done carefully but with a fundamentally flawed data source (the sessions table). The conclusions need to be revised. The protection layers Orion designed are mostly correct but the prioritization needs adjustment. Most importantly: the inventory tracking infrastructure itself needs to be fixed — the engine cannot be trusted to know its own balance until that is resolved.
— Katja