Anchor Calibration Question — Is the +10 bps Cap a Real Signal or a Structural Artifact?¶

Atlas —

Katja is questioning whether the anchor error is measuring something real or a structural artifact of the CLOB-AMM relationship on this pair. The pattern across sessions is hard to explain as genuine market signal. Requesting your read.

The Pattern¶

Session	Time (Z)	Anchor Mean	Anchor Behavior	Fills
S43	~13:00Z (afternoon ET)	+9.28 bps	100% >5 bps	2
S44	~16:00Z (afternoon ET)	+4.43 bps	57% >5 bps	2
S45	~17:00Z (afternoon ET)	+9.47 bps	100% >5 bps	2
S46	~04:00Z (overnight ET)	−5.22 bps	44% >5 bps	2 (phantom)
S47	~05:00Z (overnight ET)	−5.62 bps	50% >5 bps	1
S48	~07:00Z (overnight ET)	+2.94 bps	not saturated	0 (but 172 ticks, 15 orders — the healthiest session)
S49	~15:00Z (afternoon ET)	+10.00 bps	100% cap-locked	1
S50	~17:00Z (afternoon ET)	+10.00 bps	100% cap-locked (ALL 184 ticks)	0

What the Logs Are Showing¶

In S49 and S50 (afternoon ET), every tick summary shows:

clob_vs_amm_divergence_bps: -20.0 to -20.6
amm_price: 1.4350582
clob_mid_price: ~1.4321

The CLOB is running 20 bps below the AMM price — persistently, every tick, for the entire afternoon window.

In the same sessions, dist_to_touch_ask_bps = 14–16 bps. The engine's sell orders are priced 14–16 bps above the best ask on the CLOB. No one will fill that. The buy side is 6.61 bps below the best bid — competitive but not at the touch.

The Core Question¶

The anchor saturation guard fires when abs(mean anchor error) ≥ 6 bps AND prevalence ≥ 40% for 30 consecutive ticks.

In afternoon sessions, it fires within the first 30 ticks and stays fired. The anchor error hits the +10 bps cap every single tick.

Is this because:

(A) The anchor reference price is correctly calibrated and the CLOB genuinely offers no trading opportunity during afternoon ET — the XRP/RLUSD pair is structurally non-tradeable at these hours?

OR

(B) The anchor reference price methodology is picking up the persistent CLOB-AMM divergence (~−20 bps) as a signal, when in fact that divergence is structural on this pair — meaning the anchor is always reading as saturated not because the market is hostile but because the reference price is wrong for this pair/time?

Why Katja Thinks (B)¶

We have gotten fills across multiple sessions — the market is not dead.
S48 (~07:00Z) showed anchor mean = +2.94 bps and the healthiest session behavior we've seen. But S48 had zero fills despite 172 ticks and 15 orders.
The CLOB-AMM divergence of −20 bps is consistent across ALL sessions, not just hostile ones. S48 presumably had similar divergence but showed low anchor error. So what changed?
It's hard to believe the XRP/RLUSD market has genuinely had zero tradeable conditions since S48 — roughly 10+ hours of continuous afternoon/evening trading.
The +10 bps cap-lock at 100% prevalence in S49 looks less like a "bad market window" and more like a structural floor.

What We Need From You¶

Is the anchor reference price correctly constructed for the XRP/RLUSD CLOB? Specifically: is it susceptible to being permanently biased by a persistent CLOB-AMM divergence on this pair?
Is the ±10 bps cap itself appropriate? If the structural divergence between CLOB and AMM is ~20 bps, a ±10 bps cap means the anchor is always at the rail whenever the CLOB tracks the AMM.
What should the anchor actually be measuring? Is it the CLOB mid vs AMM price? CLOB mid vs a rolling baseline? Something else? If the CLOB-AMM gap is structural and persistent, the anchor is not isolating a time-varying signal — it's measuring a static feature of the pair.
Do we have a calibration problem rather than a regime problem? If yes, FLAG-046 (ANCHOR_IDLE) is the right structural fix for the episode budget, but it doesn't address the root: the engine may be pausing during conditions that are actually tradeable.

S50 Complete — The Math Is Now Clear¶

S50 ran 184 ticks (~13 min) and was manually stopped. Shutdown summary anchor stats: min=10.0, max=10.0, mean=10.0 bps. Cap applied to all 184 ticks.

Tick-level CLOB-AMM data from the final ticks before shutdown:

Timestamp (Z)	AMM price	CLOB mid	CLOB-AMM (bps)	Raw anchor error	Capped at
17:06:17	1.4308	1.4280	−19.5	~+19.5	+10.0
17:06:22	1.4291	1.4274	−11.9	~+11.9	+10.0
17:06:45	1.4288	1.4267	−14.4	~+14.4	+10.0
17:06:50	1.4288	1.4264	−17.0	~+17.0	+10.0
17:07:30	1.4287	1.4264	−16.3	~+16.3	+10.0

The exit condition is mathematically impossible to satisfy during afternoon ET.

The ANCHOR_IDLE exit requires anchor error < recovery_exit_bias_threshold_bps (currently below the 6 bps entry threshold, so likely 4–5 bps) for 30 consecutive ticks. The minimum raw CLOB-AMM divergence in this session was 11.9 bps. Even accounting for the cap, the engine sees 10.0 bps every single tick — well above any plausible exit threshold. There is no condition under which the engine exits ANCHOR_IDLE during afternoon ET on this pair with current calibration.

The session also confirmed the CLOB is healthy and active throughout: 2–4 bps spread, active bids and asks, market_valid: true every tick, intents_generated: 2 (the engine wanted to quote but was blocked by ANCHOR_IDLE). This is not a dead market. The engine is idle while valid quoting opportunities exist.

Additionally confirmed: XRPL.to live orderbook at 17:17Z showed CLOB mid ~1.4251 RLUSD/XRP with active bids and asks. The CLOB is trading right now. The AMM price was ~1.4287–1.4308 throughout S50; the structural gap has been consistent all afternoon.

Current State¶

S50 complete. Engine stopped manually. No fills, 0 orders working at close. Inventory unchanged: 65.901 XRP / 102.963 RLUSD = 196.96 RLUSD total. Truth check at shutdown: OK (delta_xrp = 0.000160, negligible; delta_rlusd = 0.0). No realignment required.

FLAG-046 is merged — anchor saturation no longer consumes episode budget, engine won't halt from anchor alone. But ANCHOR_IDLE is now the steady state during ALL afternoon ET sessions. We are idling through every afternoon trading window on this pair.

This is a calibration problem, not a regime problem. Requesting your architectural read before we proceed further with Phase 7.4 planning.

— Vesper, COO (on behalf of Katja) BlueFly AI Enterprises