NEO Trading Engine — Micro-Live Deployment Spec¶

Framework for the first controlled live deployment of the NEO Trading Engine. This spec covers Session 1 only. Subsequent sessions may relax constraints as behavior is confirmed.

Status: Ready to execute pending Dataset #3 replay confirmation. Deployment gate: Dataset #3 must confirm consistent behavior across 3 replay datasets before Session 1 proceeds.

Objective¶

Session 1 is a behavioral validation, not a profit exercise.

Goals: - Confirm replay behavior translates to live execution - Validate the full execution path (order placement, fills, cancels) under real conditions - Observe early signals under strict containment - Identify any discrepancy between paper/replay behavior and live behavior

Success criterion: engine runs for 15–20 minutes without triggering any kill-switch, producing fills consistent with replay behavior. PnL is secondary.

Pre-Flight Checklist¶

Complete all items before starting the engine. Do not proceed if any item fails.

Capital Deployment¶

Parameter	Value
Starting capital	$100–150 RLUSD equivalent
Starting allocation	~50% XRP / ~50% RLUSD at entry
Per-order size	$3–5 RLUSD equivalent per side
Max capital at risk	Full starting amount (treat as committed)
Absolute loss cap — review	-$5 RLUSD
Absolute loss cap — hard stop	-$10 RLUSD

Rationale: Small per-order size prioritizes many cheap observations over capital efficiency. A single bad fill should be informative, not material.

Risk Controls (Hard Limits)¶

Inventory (Engine-Enforced)¶

Inventory drift control is enforced by the engine, not operator observation. Two independent layers:

Soft control (one-sided quoting gate):

Condition	Action	Re-entry
XRP share >60%	Disable buy-side quoting	Re-enable when XRP share <55%
XRP share <40%	Disable sell-side quoting	Re-enable when XRP share >45%

Hysteresis bands prevent oscillation around the threshold boundary.

Hard control (kill-switch):

Condition	Action
XRP share outside 30–70%	Kill switch — full stop

Independence note: Inventory gating and participation filter operate as independent layers. Inventory normalizing re-enables quoting regardless of participation filter state. Participation filter clearing re-enables quoting regardless of inventory state. No strategy logic changes — this is strictly execution gating.

Loss Limits¶

Condition	Threshold	Action
Portfolio loss — review	-5% of starting value OR -$5	Pause and assess
Portfolio loss — hard stop	-10% of starting value OR -$10	Kill switch
Portfolio loss — absolute stop	-15% of starting value	Kill switch, no same-day restart

Whichever trigger (percentage or absolute dollar) is hit first applies. The 85% portfolio value floor in the automatic kill-switch corresponds to the -15% absolute stop.

Fill Behavior¶

Condition	Threshold	Action
Fill burst — warning	>5 fills in 60 seconds	Pause and investigate
Fill burst — hard review	>8 fills in 60 seconds	Trigger immediate engine stop and manual review (treat as kill-switch event for Session 1)

Kill-Switch Criteria¶

Automatic (engine-enforced)¶

Total portfolio value drops below 85% of starting value
XRP inventory share outside 20–80% range
Ledger index stops advancing for >30 seconds (stale feed)

Operator-triggered (manual, immediate)¶

Consecutive toxic fills: 2 in a row → review; 3 in a row → kill switch
Rolling toxicity rate >20% over any 10–20 fill window (if fill count reaches that level)
Average buy markout drops below 0 bps sustained over the session
Spread PnL goes negative over any 15-minute window
Fill burst thresholds hit (see above)
Any unexpected execution engine error in logs
Engine connectivity lost (see Connectivity Loss procedure below)

Note on short sessions¶

For a 15–20 minute session, 10–20 fills may not accumulate. In that case, consecutive toxic fills is the primary early warning signal. Rolling toxicity rate becomes relevant only if fill count reaches threshold.

Monitoring Plan¶

Operator must be present and active throughout Session 1. Not passive monitoring.

Check cadence¶

Every 5 minutes minimum: - XRP balance - RLUSD balance - Total fill count - Any errors in engine logs - Ledger index advancing

Every 10 minutes (spot check)¶

Realized spread so far
Buy vs sell fill ratio
Participation filter activation count
Inventory drift from 50%
Recent buy markout trend (primary edge signal — fastest degradation indicator)

Immediate review conditions¶

Fill rate doubles or halves unexpectedly
XRP share moves >10% within any 5-minute window
Any execution engine error
Engine output becomes silent unexpectedly

Rollback Procedure¶

Planned stop (time limit or clean exit)¶

Trigger graceful engine shutdown
Confirm all open offers on XRPL are cancelled (check on-chain, not just engine output)
Record ending balances: XRP, RLUSD, total value, fill count
Log session result before closing anything

Kill-switch triggered (hard stop)¶

Stop engine process immediately
Manually verify and cancel all open offers on XRPL — do not rely on engine to clean up
Record state at time of stop: balances, fill count, what triggered the stop
Do not restart in live mode without written review of trigger cause
Revert to paper mode config before any further testing

Connectivity loss (mid-session)¶

Do not attempt reconnect or restart immediately
Do not assume engine state reflects on-chain state after disconnect — always trust XRPL, not local state
Manually verify and cancel all open offers on XRPL first
Confirm wallet state (balances, no orphaned offers)
Only then assess whether to reconnect
Treat connectivity loss as a kill-switch event for Session 1 — no same-session restart

Operational guardrail¶

No same-day restart after any kill-switch trigger without a written review. This prevents reactive redeployment under adverse conditions.

Session Parameters¶

Parameter	Value
Session duration	15–20 minutes maximum
Time of day	Mid-session (avoid weekend / low-liquidity windows)
Operator	Present in real-time throughout
Exit condition	Clean shutdown at time limit regardless of PnL

Strategy Config (Unchanged from Phase 4A Baseline)¶

anchor_mode: capped_amm
anchor_max_divergence_bps: 10.0
bid_spread_multiplier: 1.00
ask_spread_multiplier: 1.00
participation_filter_enabled: true
post_fill_markout_trigger_bps: -2.5
post_fill_pause_seconds: 8
enable_bid_ladder: false
directional_bid_protection_enabled: false
anchor_relative_bid_protection_enabled: false

No strategy or execution logic changes during this phase.

Post-Session Evaluation¶

After Session 1, compare against replay baseline on these metrics:

Metric	Replay avg	Session 1 result	Delta
total_fills	~82–189 (scaled)
toxic_fill_rate_pct	0.0%
avg_markout_buy_bps	+12.2–12.3
avg_realized_spread_bps	~14.8
buy/sell fill ratio	~1.0–1.1
participation filter activations	0 (both datasets)
ending XRP share	~51–55%

Decision gate for Session 2: - If metrics are consistent with replay → proceed to Session 2 (longer duration, same capital) - If meaningful degradation appears → investigate before any further live testing - If kill-switch triggered → written review required before any live restart

What This Session Does Not Validate¶

Be explicit about what remains unknown after Session 1:

Participation filter behavior under adverse conditions (no toxic events observed in replay)
Strategy behavior during volatile market regimes
Long-session inventory drift and management
PnL consistency over meaningful time periods

These are Session 2+ questions. Session 1 answers only: does the engine execute correctly in live conditions?

Spec authored: 2026-04-10. Deploy only after Dataset #3 replay confirms baseline consistency.