Work

PhantomArbiter

Solana DEX arbitrage engine with multi-strategy detection and MEV protection

PythonTypeScriptRustFastAPISolana SDKWebSocket

The problem

Cryptocurrency arbitrage opportunities exist across Solana's decentralized exchanges (Jupiter, Raydium, Orca, Meteora), but MEV (Maximal Extractable Value) bots front-run profitable trades, capturing the arbitrage before it can be executed. Detection must happen in milliseconds across multiple DEX prices.

How it works

  • Real-time WebSocket feeds aggregating price data from 4+ DEX liquidity pools
  • Multi-strategy detection engine identifying cross-DEX, triangle, and statistical arbitrage
  • JITO bundle protection to atomically execute trades against MEV front-running
  • Python asyncio for high-throughput data processing
  • TypeScript DEX bridge implementations for Jupiter, Raydium, Orca, Meteora
  • Rust bindings for performance-critical path calculations

PhantomArbiter was a real-time trading system built for Solana’s blockchain at the millisecond scale required to compete with MEV bots. It is now semi-retired — the post-mortem explains why infrastructure cost, not code, ended it.

The Problem Domain

On Solana, liquidity is fragmented across 4+ major decentralized exchanges. When prices diverge, arbitrage opportunities arise—buy low on one DEX, sell high on another. But MEV bots watch the mempool, see your transaction, insert their own before it, and steal the profit.

PhantomArbiter solves this by:

  1. Detecting opportunities in milliseconds
  2. Using JITO bundles to atomically execute (front-running proof)
  3. Supporting multiple strategies (not just one-off opportunities)

Architecture

Price Aggregation Layer: WebSocket connections to each DEX’s liquidity pool contracts. Updates stream in real-time; latency matters.

Strategy Engine: Analyzes price vectors across pools. Detects:

  • Cross arbitrage: X → Y → Z at profit on single chain
  • Triangle arbitrage: ABC cycles with profit loop
  • Statistical: Mean reversion trades on stablecoin pairs

Execution Layer: Three modes:

  • Paper: Simulate trades without capital (learn the system)
  • Monitor: Detect opportunities but don’t execute (audit mode)
  • Live: Actually execute trades via JITO bundles

Tech Stack Breakdown

Python 3.12+: Async processing, real-time market data, strategy logic. Uses asyncio for concurrent pool monitoring.

TypeScript: DEX integrations (Jupiter, Raydium, Orca, Meteora). Each bridge implements the same interface, allowing hot-swapping strategies.

Rust: Performance-critical path calculations (price vectors, profit thresholds). Compiled to WebAssembly for browser compatibility (future).

FastAPI: Backend for the live dashboard, exposing monitoring endpoints for real-time opportunity tracking.

Why This Matters

This project demonstrates ability to:

  • Work with real financial systems (stakes are real)
  • Operate at trading bot performance scales (milliseconds)
  • Integrate multiple APIs and protocols coherently
  • Maintain code quality while moving fast
  • Understand blockchain and DeFi ecosystem deeply

Lessons Learned

The $4 loss on 400 trades wasn’t due to strategy flaws—it was execution. RPC latency and network conditions matter more than algorithm sophistication. Competing would have needed dedicated validator access and bundle relay redundancy — infrastructure spending the project could not justify. The code worked; the economics did not.

It never became profitable production infrastructure, but it traded against live markets, which taught more than any simulation would have.

Source on GitHub