NEO Trading Engine — Intel Log¶
Intel from external sources, filtered for NEO relevance only. Each entry includes source, what was observed, what it means for NEO, and a verdict. Fluff and unverifiable claims are noted but not carried forward.
INTEL-001 — Titan Ghost Engine Architecture¶
Date: April 14, 2026 Source: Titan Ghost Engine (competitor, XRPL market maker) — architecture summary from operator exchange Trust level: Medium. Architecture description is plausible and internally consistent. Performance claims (fill counts, daily profit, scaling) are unverified and likely overstated. Metrics may not be session-scoped. No independent verification.
What Was Observed¶
Titan Ghost is a multi-wallet, multi-level grid market maker on XRPL. ~150 wallets each sit at a distinct price level, forming a continuous bid/ask corridor from tight to wide spreads. Zones are named Velocity (top-of-book), Bridge, Earn, Money, Deep, Ceiling.
Key design features: - No inventory control — accepts drift as a natural outcome of market behavior - Asymmetric cancel logic — Velocity zone cancels/reposts fast; Deep/Ceiling orders sit patiently for a long time - Presigned transaction blobs — enables fast repost after fill within the 3–4s XRPL ledger window - Explicit wick-capture design — deep orders stay resting during volatility, fill on dislocations, then re-enter fast at top-of-book
Architecture is non-modular (operator confirmed). Single codebase, not config-driven per layer.
What's Fluff / Unverified¶
- "$250K capital → $3-10K/day profit" — no methodology, no timeframe
- "96% routing concentration" — no market structure data attached
- "$300M → $500K/day" scaling claim — assumes no competition, stable spreads, linear fill rate
- "Spread income is certain" — not true
- "100x token appreciation returns the entire investment" — speculation, not strategy
- Multi-chain portability claims — unvalidated across non-XRPL chains
What Confirms NEO's Direction¶
- Titan has no inventory control and accepts drift. NEO's skew-based control loop is more sophisticated. This is a NEO advantage.
- Titan's architecture is non-modular. NEO's config-driven, session-scoped, modular design is operationally superior.
- Titan's fill-per-fill edge is thin (~0.0046 XRP/fill average from stated metrics). NEO's VW spread ~3 bps is competitive.
NEO-Relevant Insight (Actionable)¶
Depth-based TTL differentiation — Titan's asymmetric cancel logic is the one genuinely useful architectural concept. The principle: orders close to touch should requote aggressively (short TTL); orders far from touch or at a wide skew-adjusted offset should sit patiently (long TTL).
This directly maps to NEO's open issue (see FLAG-013): our uniform ~300s requote TTL causes the buy order to drift 9-10 bps from its skew-adjusted intended placement during the TTL window. In a skew-active environment, this means the engine is placing orders at the wrong position for up to 5 minutes at a stretch.
Proposed NEO adaptation: Instead of uniform TTL, apply offset-threshold-based requote trigger:
- If |actual_offset - skew_adjusted_intended| > X bps → force immediate requote regardless of TTL
- Keep TTL as the fallback for quiet/stable conditions
- Suggested threshold: 3-5 bps deviation triggers immediate requote
This is simpler than replicating Titan's zone system but captures the same core benefit.
Verdict¶
| Item | Verdict |
|---|---|
| Depth-based asymmetric cancel logic | Adopt (adapted) — apply as deviation-threshold requote trigger |
| Presigned blobs / fast repost | Monitor — relevant if fill rate becomes a priority later |
| Multi-level grid quoting | Defer — architecturally different, requires much more capital |
| No-inventory-control philosophy | Ignore — NEO's skew approach is better for capital efficiency |
| Performance / scaling claims | Ignore — unverified, likely overstated |
From Screenshots (33 images, Apr 13 2026, reviewed Apr 14)¶
Actual verified metrics (Section 5 slide): - 10 production sessions, 71,832 fills - Sell Spread P&L: +287.02 XRP, Buy Spread P&L: +41.73 XRP - Negative Spread Loss: -2.51 XRP (0.76% of gross) - Lifetime NET: +326.24 XRP (~$447 RLUSD at current price) - Current AUM: $565. Daily current: ~4.75 XRP ($6.41/day = ~1.1%/day on AUM) - Best session: +29.87 XRP in 6 hours - Infrastructure: $24/month VPS. Rust/Tokio. Dedicated rippled node.
Stale cancel thresholds by zone (specific, not in summary):
| Zone | Stale Threshold | Meaning |
|---|---|---|
| Velocity | 0.05% | Cancels fast — needs to stay near top |
| Bridge | 0.10% | Cancels fairly fast |
| Earn | 0.20% | Moderate patience |
| Money | 0.40% | Patient — waits for real moves |
| Deep | 0.80% | Very patient — only cancels on major shifts |
| Ceiling | 1.50% | Extremely patient — stays through almost everything |
These are percentage-based mid-movement thresholds, not time-based TTL. An order only cancels if mid moves more than the zone's threshold. This is fundamentally different from a time-based TTL — it's event-driven by price movement.
Critical finding — inventory controller failure (Section 2): "Previous attempts to force ratio through controllers caused -42 XRP loss in a single session. Every controller was removed. Natural cycling replaced all of them."
This is the most important data point in the entire document for NEO. He tried inventory control (directionally similar to NEO's skew), it produced a -42 XRP loss, and he removed it. Context matters: this was a global ratio controller, not a per-order skew mechanism. But it's worth understanding why it failed before assuming NEO's approach avoids the same trap.
The performance chart (last screenshot): Illustrative, not from real backtested data. Shows HODL -40% vs Engine +18% at peak crash, Engine +41% post-reversion. No methodology attached. Treat as narrative, not evidence.
Claude chat screenshots: He was asking Claude to explain/validate wick-catching logic. The responses are from Claude building on his own description. Not independent validation — self-referential.
Additional Notes (verbal, Apr 14)¶
- Rust + WebSocket listener: Sub-ms fill detection via WS vs polling. Real advantage at high fill rates. Not a bottleneck for NEO at current scale but relevant if fill rate scales up.
- AMM ceiling / routing play: Quotes just below AMM price so Pathfinder routes through him by default. NEO's
capped_ammanchor already references AMM price — conceptually similar but not identical. - XLS-81 Permissioned DEX: Plans to quote on both public XRPL DEX and permissioned DEX simultaneously. Forward-looking, requires credentials. NEO Phase 3+ consideration at most.
When to Revisit This Intel¶
- FLAG-013 resolved (requote TTL → percentage-based threshold): Cross-reference his stale cancel table for threshold values by offset distance
- Skew debate resolved: If NEO's skew approach proves unstable, revisit his -42 XRP controller failure for clues on what not to do
- NEO scales past ~500 fills/session: WebSocket listener becomes relevant
- Next intel exchange: If he shares updated performance data or post-XLS-81 deployment results, add INTEL-002
Next review trigger: FLAG-013 fix implementation, or next intel exchange with Titan Ghost.