Consolidated Production Trading System - Solo Developer Plan

Executive Summary

This is a realistic, achievable roadmap for building a production-ready multi-strategy Solana trading system as a solo developer working part-time (10-20 hrs/week) on a hobby project.

System Goals:

• Start with LST arbitrage (highest success rate: 60-75%)
• Extensible architecture for future strategies (DCA, grid trading, long/short)
• Rust for performance-critical paths (execution, arbitrage detection)
• TypeScript for rapid development (analytics, simple strategies)
• Sub-500ms execution latency
• Realistic profit target: $5k-12k/month baseline (9 months)
• Optimistic with scaling: $15k-25k/month (requires flash loans, multiple wallets)

Timeline: December 2025 - September 2026 (~9 months with breaks)

Timeline Overview

Available Working Periods

Phase 1: December 9-22, 2025 (2 weeks, 20-40 hours)

• Foundation & infrastructure setup
• ❌ Break: Dec 23 - Jan 5 (Christmas holiday)

Phase 2: January 6-25, 2026 (3 weeks, 30-60 hours)

• Market data layer & quote service
• ❌ Break: Jan 26 - Feb 20 (3 weeks off)

Phase 3: February 21 - March 31, 2026 (5-6 weeks, 50-120 hours)

• Arbitrage detection & execution
• First trade milestone

Phase 4: April - May 2026 (8 weeks, 80-160 hours)

• Optimization & additional strategies
• Production readiness

Phase 5: June - September 2026 (16 weeks, 160-320 hours)

• Advanced features & scaling
• Full multi-strategy platform

Total Timeline: ~34 working weeks = 340-680 hours over 9 months

System Architecture (High-Level)

┌─────────────────────────────────────────────────────────────────┐
│                     MARKET DATA LAYER (Rust)                     │
│  Shredstream Client → In-Memory Channel (HOT PATH) → Strategy   │
│                   └→ NATS JetStream (COLD PATH) → Analytics     │
│  Priority: HIGH | Language: Rust | Latency: 50ms                │
│  Note: NATS for analytics ONLY, not for trade triggers          │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│                    QUOTE ENGINE (Go - Existing)                  │
│  Your Go Service → Local Pool Math → Multi-DEX Quotes           │
│  Priority: HIGH | Language: Go | Latency: 2-10ms                │
│  Connection: HTTP Keep-Alive (persistent connection pooling)    │
│  + Dark Pool Simulation (on-chain)                              │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│              STRATEGY FRAMEWORK (Extensible - Rust)              │
│  Plugin System → Event Routing → Opportunity Generation         │
│  Priority: HIGH | Language: Rust | Latency: 5-20ms              │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│                STRATEGY IMPLEMENTATIONS (Mixed)                  │
│  ┌──────────────────┐  ┌──────────────────┐                   │
│  │ Arbitrage (Rust) │  │ DCA (TypeScript) │                   │
│  │ - LST 2-hop      │  │ - Time-based     │                   │
│  │ - LST 3-hop      │  │ - Price-based    │                   │
│  │ - USDC 2-hop     │  │                  │                   │
│  │ Priority: HIGH   │  │ Priority: MEDIUM │                   │
│  └──────────────────┘  └──────────────────┘                   │
│  ┌──────────────────┐  ┌──────────────────┐                   │
│  │ Grid (TypeScript)│  │ Long/Short (Rust)│                   │
│  │ Priority: LOW    │  │ Priority: LOW    │                   │
│  └──────────────────┘  └──────────────────┘                   │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│                 PLANNED LAYER (Rust - New)                     │
│  Universal Executor → TX Builder → Smart Validation → Jito      │
│  Priority: HIGH | Language: Rust | Latency: 100ms               │
│  Note: NO expensive RPC simulation, smart sanity checks only    │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│              ANALYTICS & MONITORING (TypeScript)                 │
│  PnL Calculator → Trade Analysis → Grafana Dashboards           │
│  Priority: MEDIUM | Language: TypeScript | Non-critical path    │
└─────────────────────────────────────────────────────────────────┘

Key Architectural Principles:

• Hot Path: Use in-memory channels (tokio::mpsc) for trade-critical data flow (< 0.05ms)
• Cold Path: Use NATS for analytics, monitoring, and non-critical events (2-5ms acceptable)
• HTTP Keep-Alive: Persistent connections to Go service save 5-15ms per quote
• Smart Validation: Skip expensive RPC simulation (150ms), use fast sanity checks (5ms)

Understanding the Competition: Pro HFT vs Solo Dev

The Institutional HFT Stack (What You’re Up Against)

Context: Professional MEV searchers and institutional HFT teams operate at a completely different scale. Understanding their infrastructure helps you find profitable niches they ignore.

Pro Infrastructure ($20k-100k/month operating costs)

1. Co-Location & Hardware

• Bare-metal servers in same datacenters as Solana validators (Latitude.sh Tokyo, Amsterdam, NY)
• Overclocked CPUs (i9-14900KS) liquid-cooled for single-core performance
• FPGAs for hardware-level packet filtering
• Kernel bypass networking (DPDK, Solarflare OpenOnload) - saves 5-10 microseconds

2. Market Data

• Custom Geyser plugins on their own validator nodes
• Direct TCP/UDP socket connections (no RPC)
• Zero-copy deserialization (rkyv/Zerocopy in Rust)
• Latency: <1ms (vs your 50-100ms)

3. State Management (The Real “Local SVM”)

• In-memory shadow validator running full Solana state
• Speculative execution on pending transactions
• Predicts future prices before blocks are produced
• This is what “local SVM” means at pro level (not worth it for solo dev)

4. Execution

• Stake-weighted QoS (own/lease staked SOL for priority lane)
• Dynamic Jito tip monitoring (bid $0.0001 higher than competition)
• Custom on-chain programs for instruction packing

5. Strategy

• Inventory arbitrage (hold $1M positions, CEX-DEX arb)
• Statistical arbitrage (not just atomic risk-free)
• Focus: Top 10 pairs (SOL/USDC, SOL/JUP) - highest volume

Why Solo Dev Can Still Win: The “Long Tail” Strategy

The Math of Competition:

Pro HFT Break-Even: $100k-300k/month profit (to cover $20k-100k/month costs)
Solo Dev Break-Even: $5k-15k/month profit (to cover $100-300/month costs)

Implication: You can profitably trade markets they can't afford to touch

Your Competitive Advantages:

Historical Parallel (Stock Market):

• HFT firms dominate stocks #1-100 (SPY, AAPL, TSLA)
• Retail algos profit on stocks #1,000-3,000 (small cap, low volume)
• Why? HFT infrastructure costs justify only high-volume targets
• Same principle applies to Solana DEX trading

The “Guerrilla Warfare” Trading Philosophy

Pro HFT = Heavy Artillery
├─ Massive firepower (sub-ms latency)
├─ Expensive to operate ($20k-100k/month)
├─ Needs constant high-value targets
└─ Can't pivot quickly (infrastructure lock-in)

Solo Dev = Guerrilla Tactics
├─ Lightweight and agile (200-500ms is enough)
├─ Low operating costs ($100-300/month)
├─ Pick battles carefully (long-tail tokens)
└─ Adapt to changing landscape (new strategies in days)

Compete Where They Can’t:

• ❌ Don’t compete: SOL/USDC, top 10 pairs, raw speed
• ✅ Do compete: LST arbitrage, 3-hop routes, niche DEX combinations
• ✅ Win by: Lower costs, smarter route finding, risk-free atomicity

Example: Why LST Arbitrage is Perfect

Pro HFT View:
- jitoSOL ↔ mSOL pool: $500k daily volume
- Potential profit: $50-200/day
- Verdict: "Too small, ignore it" (doesn't justify $1k/day infra costs)

Solo Dev View:
- Same pool: $500k daily volume
- Potential profit: $50-200/day
- Verdict: "Perfect! That's $1,500-6,000/month" ✅

Reality Check: Transaction Simulation Approaches

The Three Types of “Simulation” (What’s Real vs Hype)

1. RPC Simulation (Built-in, but too slow)

// What connection.simulateTransaction() does
let result = rpc_client.simulate_transaction(&transaction).await?;
// Cost: 50-150ms
// Accuracy: 70-80% (state changes between simulation and execution)

What it does:

• ✅ Sends unsigned transaction to RPC node
• ✅ RPC node runs it against CURRENT blockchain state
• ✅ Returns: “Would this succeed right now?”

Why it’s unreliable for HFT:

T+0ms:   You simulate → "Pool has 1000 SOL, profit 0.5 SOL" ✅
T+150ms: You submit transaction
T+400ms: Transaction lands → Pool now has 800 SOL (someone swapped)
         Your tx fails or breaks even 💀

Verdict: Standard approach but NOT suitable for sub-500ms HFT.

2. Local SVM Simulation (Mythical - Don’t Build This)

// This is the mythical "local SVM"
let result = local_svm.simulate(transaction, cached_state);
// Cost: 5-20ms
// Accuracy: Same problem as RPC (state changes)
// Development time: 3-6 months

What it would do:

• Run SVM bytecode locally
• Simulate against cached pool states
• Faster than RPC (no network)

Why NOT to build this:

1. ❌ Complexity: Replicate Solana’s entire runtime (programs, compute budget, rent, etc.)
2. ❌ Maintenance: Solana upgrades break things monthly
3. ❌ Still inaccurate: Cached state is already stale by 100-400ms
4. ❌ Overkill: Cheaper sanity checks catch 90% of failures

Examples of “local SVM” projects:

• Mollusk - For program testing, NOT production HFT
• solana-bankrun - Python testing tool, too slow

Verdict: Possible in theory, NOT worth it for solo dev. Even large HFT firms often skip this.

3. Smart Sanity Checks (What We’re Building)

// Fast validation that catches 90% of failures
async fn should_execute_trade(trade: &Trade) -> Result<(), String> {
    // 1. Cached balance check (~0.1ms)
    if balance_cache.get(trade.wallet) < trade.amount {
        return Err("Insufficient balance"); // Catches 30% of failures
    }

    // 2. Stale quote check (~0.1ms)
    if trade.quote_age_ms > 200 {
        return Err("Quote too old"); // Catches 40% of failures
    }

    // 3. Profit threshold (~2ms - call Go service)
    let expected_out = quote_engine.quick_quote(trade)?;
    if expected_out < trade.min_profit {
        return Err("Below profit threshold"); // Catches 20% of failures
    }

    // 4. Hardcoded compute units (0ms)
    trade.compute_units = match trade.hops {
        1 => 100_000,
        2 => 150_000,
        3 => 200_000,
        _ => return Err("Too many hops"),
    };

    // Total: ~5ms, catches 90% of failures
    Ok(())
}

// Then submit immediately via Jito (no RPC simulation)
jito_client.send_bundle(&build_transaction(trade)).await?

What this achieves:

• ✅ 5ms validation (vs 150ms RPC simulation)
• ✅ Catches 90% of obvious failures
• ✅ Jito’s atomic execution catches remaining 10%
• ✅ Zero wasted gas fees (Jito drops failed bundles)

Expected Success Rates:

Verdict: Smart validation is the optimal balance of speed, accuracy, and development time.

Phase 1: Foundation (Dec 9-22, 2025)

Week 1 (Dec 9-15): Repository & Infrastructure

Time Budget: 10-20 hours

Tasks:

1. Repository Structure (2 hours)
   • Set up monorepo structure (Rust workspace + pnpm for TypeScript)
   • Initialize Cargo workspace for Rust components
   • Initialize pnpm workspace for TypeScript components
   • Set up .gitignore, .env.example
2. Docker Infrastructure (4 hours)
   • Docker Compose for local development
   • Services: Redis, PostgreSQL, NATS JetStream, Prometheus, Grafana
   • Initialize database schema (trades, opportunities, strategy_health)
   • Test all services start and communicate
3. Token & Pool Configuration (2 hours)
   • Define LST token mints (jitoSOL, mSOL, bSOL)
   • Configure priority token pairs
   • Document pool addresses for each DEX
4. Development Environment (2 hours)
   • Rust toolchain setup
   • TypeScript/Node.js setup
   • IDE configuration (VS Code recommended)
   • Install dependencies

Deliverable: ✅ Clean development environment with all infrastructure running

Week 2 (Dec 16-22): Core Framework

Time Budget: 10-20 hours

Tasks:

1. Generic Market Events (Rust) (6 hours)
   • Define MarketEvent enum (PriceUpdate, LiquidityUpdate, SpreadUpdate, etc.)
   • NATS subject routing logic
   • Event serialization/deserialization
   • Basic event publisher
2. Strategy Framework Traits (Rust) (6 hours)
   • Define TradingStrategy trait
   • Define TradeOpportunity struct
   • Define StrategyConfig struct
   • Strategy health monitoring types
3. Configuration System (4 hours)
   • TOML configuration parser
   • Strategy configuration schema
   • Environment variable handling

Deliverable: ✅ Core framework types and interfaces defined

Phase 2: Market Data & Quotes (Jan 6-25, 2026)

Week 3 (Jan 6-12): Shredstream Enhancement

Time Budget: 12-24 hours (increased to include state validation)

Tasks:

1. Enhance Your Shredstream Client (8 hours)
   • Add LST pool address monitoring
   • Implement generic event emission
   • Connect to NATS for publishing
   • Filter by priority pools (top 20 LST pools)
2. Pool State Cache (Rust) (4 hours)
   • In-memory pool state storage
   • Lock-free reads for concurrent access
   • Update from Shredstream events
3. Heartbeat Sync for State Validation (4 hours) ⭐ NEW - CRITICAL
   • Implement 60-second “lazy load” RPC verification
   • Compare local cache vs on-chain state for active pools
   • Auto-flush and resync on mismatch detection (state drift recovery)
   • Log drift events for monitoring (UDP/gRPC packet loss tracking)
   • Why: UDP packets WILL drop. Without this, missed “Liquidity Update” corrupts local state forever.
4. Testing (4 hours)
   • Verify events published to NATS
   • Verify pool state updates correctly
   • Test state drift recovery mechanism
   • Load test with historical data

Deliverable: ✅ Market data streaming to NATS with <100ms latency + automatic state drift recovery

Week 4-5 (Jan 13-25): Quote Service Integration

Time Budget: 22-42 hours (increased for circuit breaker)

Tasks:

1. Enhance Go Quote Service (12 hours)
   • Add LST pairs (jitoSOL, mSOL, bSOL)
   • Implement /lst/opportunities endpoint
   • Add round-trip profit calculation
   • Enable dark pool simulation (optional)
2. Rust HTTP Client for Quote Service (6 hours)
   • HTTP client with connection pooling (reqwest with Keep-Alive)
   • Persistent connections save 5-15ms per quote
   • Quote caching (10-second TTL)
   • Error handling and retries
   • Timeout set to 50ms for fail-fast behavior
3. Quote Service Circuit Breaker (2 hours) ⭐ NEW - CRITICAL
   • Detect 3 consecutive timeouts (>50ms) or connection failures
   • Fallback to Jupiter API when Go service is slow/down
   • Auto-recovery: retry Go service every 30 seconds after circuit break
   • Health check endpoint: verify quote cache freshness (<30s old)
   • Why: Prevents hot path blocking on single point of failure
4. Quote Service Deployment (2 hours)
   • Deploy Go service locally
   • Configure refresh intervals (20 seconds)
   • Set up health checks

Deliverable: ✅ Quote service providing LST quotes in 2-10ms with automatic failover

Phase 3: Arbitrage Strategy & Execution (Feb 21 - Mar 31, 2026)

Week 6-7 (Feb 21 - Mar 9): Arbitrage Detection

Time Budget: 20-40 hours

Tasks:

1. Arbitrage Strategy Implementation (Rust) (16 hours)
   • Implement TradingStrategy trait for arbitrage
   • LST two-hop detection (SOL → LST → SOL)
   • LST three-hop detection (SOL → LST1 → LST2 → SOL)
   • USDC two-hop detection (conservative, low priority)
   • Profit calculation with fees
   • Priority ranking
2. Strategy Manager (Rust) (8 hours)
   • Strategy registration system
   • Event routing to strategies
   • Opportunity aggregation
   • Strategy health monitoring
3. NATS Integration (4 hours)
   • Subscribe to market events
   • Publish trade opportunities
   • Consumer management

Deliverable: ✅ Arbitrage opportunities detected and published to NATS

Week 8-9 (Mar 10-23): Rust Executor

Time Budget: 20-40 hours

Tasks:

1. Transaction Builder (Rust) (12 hours)
   • Two-hop arbitrage transaction builder
   • Three-hop arbitrage transaction builder
   • Compute budget optimization
   • Jito tip instruction
2. Smart Trade Validator (Rust) (6 hours)
   • Fast sanity checks (~5ms total):
     • Cached balance verification (prevents insufficient funds)
     • Pool existence check (prevents invalid pool errors)
     • Profit threshold validation (local Go quote check)
     • Hardcoded compute unit estimates by hop count
   • NO expensive RPC simulation (saves 150ms)
   • Jito bundle atomicity handles edge cases
   • Per-Pool Circuit Breaker: ⭐ NEW - CRITICAL
     • Track Jito drop rate per pool (3 strikes in 5 minutes = blacklist pool for 5 min)
     • Force RPC state resync for blacklisted pools before re-enabling
     • Prevents Jito reputation damage from submitting spam bundles
     • Why: Jito monitors spam rate. Corrupted pool state → repeated failures → key blacklist.
   • Global circuit breaker for systemic issues (3 consecutive global failures)
3. Jito Executor (Rust) (6 hours)
   • Bundle submission with retry logic
   • Confirmation monitoring via WebSocket
   • Error handling and logging
   • Success/failure metrics

Deliverable: ✅ Executor can build, validate (fast), and submit transactions

Important Note: We skip expensive RPC simulation (150ms latency) in favor of 5ms sanity checks. Jito bundles provide atomic execution (all-or-nothing), so failed transactions cost $0 in gas fees. This “smart fire & forget” approach is essential for sub-500ms execution.

Week 10-11 (Mar 24-31): Integration, Testing & First Trade

Time Budget: 15-25 hours (increased to include replay testing)

Tasks:

1. Replay Testing Harness (5 hours) ⭐ NEW - CRITICAL
   • Record 1 hour of raw Shredstream events to file (JSON Lines format)
   • Build test harness that replays events at 10x speed into strategy engine
   • Verify bot WOULD have triggered trades at actual price moves
   • Backtesting for HFT without losing money or RPC costs
   • Debug logic errors in safe environment
   • Why: Since you removed RPC simulator, this is your ONLY way to validate arbitrage logic without real money.
2. End-to-End Integration (8 hours)
   • Connect all components
   • Test with devnet first
   • Dry run on mainnet (no execution)
   • Use replay test data to validate strategy logic
3. Risk Management (4 hours)
   • Per-pool circuit breakers (3 strikes in 5 min → 5 min timeout)
   • Global circuit breakers (3 consecutive systemic failures → halt system)
   • Position limits (max 10 SOL per trade)
   • Balance monitoring with alerts
4. First Live Trade (4 hours)
   • Start with 0.1 SOL trades
   • Monitor closely
   • Record results
   • Compare against replay test predictions

Milestone: 🎉 FIRST PROFITABLE TRADE EXECUTED!

Expected Results by End of Phase 3:

• 10-30 opportunities detected per day
• 50-60% success rate
• 5-15 profitable trades per day
• $5-20 profit per day

Phase 4: Optimization & Reliability (Apr - May 2026)

Week 12-13 (Apr 1-14): Performance Optimization

Time Budget: 24-44 hours (increased for latency profiling)

Tasks:

1. Latency Profiling & Monitoring (4 hours) ⭐ NEW - CRITICAL
   • Instrument hot path with timestamp checkpoints:
     • Event receipt → Quote fetch → Validation → TX submit → Confirmation
   • Log component-level latencies to Prometheus
   • Track 95th percentile (p95) and max latencies per component
   • Alert if any component exceeds budget:
     • Quote service >10ms
     • Validation >5ms
     • TX building >20ms
   • Why: “You can’t optimize what you don’t measure” - enables data-driven optimization
2. Latency Optimization (10 hours)
   • Profile all components with flamegraphs (cargo flamegraph)
   • Optimize hot paths (remove allocations in quote path)
   • Cache blockhash (20-second refresh, saves 50ms)
   • WebSocket confirmations instead of polling (2x faster)
   • Batch RPC calls with getMultipleAccounts (10x faster)
3. Quote Caching (6 hours)
   • Redis integration for quotes (sub-ms access)
   • Route template caching (avoid recomputation)
   • Opportunity deduplication (prevent duplicate submissions)
   • Stale quote detection (reject quotes >200ms old)
4. Parallel Processing (4 hours)
   • Concurrent opportunity evaluation with tokio::spawn
   • Parallel quote fetching (Promise.all equivalent)
   • Multi-RPC load balancing for redundancy

Target: 750ms → 300ms execution time (measured by latency profiling)

Key Optimizations:

• Blockhash caching: 50ms saved
• HTTP Keep-Alive: 5-15ms saved per quote
• WebSocket vs polling: 500ms → 200ms confirmation time
• Parallel quotes: 2x faster than sequential

Week 14-15 (Apr 15-28): Multi-Pair Support

Time Budget: 20-40 hours

Tasks:

1. Add mSOL and bSOL Pairs (8 hours)
   • Configure in Go quote service
   • Update Rust arbitrage detector
   • Test separately per pair
2. Pair-Specific Configuration (4 hours)
   • Different profit thresholds per pair
   • Different simulation requirements
   • Pair rotation to prevent over-trading
3. LST Triangular Logic (8 hours)
   • Implement LST pair scoring system
   • Configure jitoSOL ↔ mSOL route (highest score)
   • Add mSOL ↔ bSOL route

Expected Results:

• 100-200 opportunities per day (3 LST pairs)
• 60-65% success rate (conservative, accounts for competition)
• 60-130 profitable trades per day
• $30-80 profit per day ($900-2,400/month)

Week 16-19 (Apr 29 - May 26): Reliability & Monitoring

Time Budget: 44-84 hours (increased for production alerting)

Tasks:

1. Error Handling (12 hours)
   • Comprehensive error types
   • Retry logic for RPC failures
   • Transaction timeout handling
   • Dead letter queue for failed trades
2. Analytics Service (TypeScript) (16 hours)
   • PnL calculator
   • Trade analysis by strategy
   • Success rate tracking
   • Performance metrics
3. Monitoring Dashboards (12 hours)
   • Grafana dashboard setup
   • Prometheus metrics integration
   • Key metrics: opportunities, success rate, PnL
   • Alerts: circuit breaker, low balance, high error rate
4. Production Alerting (4 hours) ⭐ NEW - CRITICAL
   • Slack webhook integration for critical alerts
   • Email daily summary (PnL, success rate, top errors)
   • Alert thresholds:
     • Error rate >30% in last hour
     • No trades in 4 hours (system stalled?)
     • Pool blacklist rate >5 pools/hour (state drift issue)
     • Circuit breaker triggered (quote service or per-pool)
     • Wallet balance <0.5 SOL
   • Why: Part-time dev needs proactive notifications, not reactive 24/7 monitoring
5. Production Hardening (12 hours)
   • Graceful shutdown handling
   • State persistence
   • Log rotation
   • Health check endpoints

Expected Results:

• System runs 24/7 reliably with proactive alerts
• Full visibility into performance
• Quick detection of issues via Slack/email
• 70%+ success rate

Phase 5: Multi-Strategy Platform (Jun - Sep 2026)

Note on Strategy Priorities: DCA and Grid Trading are deprioritized (not canceled). These strategies run on the “cold path” with no latency requirements (can execute every 30-60 seconds). Focus on perfecting LST arbitrage HFT first, then add these as background revenue streams. They diversify income during low-volatility periods when arbitrage opportunities are scarce.

Week 20-23 (Jun 1-28): DCA Strategy

Time Budget: 44-84 hours (increased for strategy coordination)

Tasks:

1. DCA Strategy Implementation (TypeScript) (16 hours)
   • Interval-based buying
   • Price threshold checking
   • RSI-based filtering (optional)
   • Integration with strategy framework
2. Strategy Coordination Layer (4 hours) ⭐ NEW - CRITICAL
   • In-memory pool reservation system (500ms lock per pool)
   • Priority queue: Arbitrage (hot path) > Grid > DCA (cold path)
   • If arbitrage claims jitoSOL pool, DCA skips that pool for 500ms
   • Prevents duplicate bundle submissions to same pool
   • Coordination via shared state (Arc<RwLock<HashMap<Pubkey, Instant»>)
   • Why: Avoids Jito bundle failures from internal strategy competition
3. DCA Configuration (4 hours)
   • Configure DCA for SOL (hourly)
   • Configure DCA for jitoSOL (daily)
   • Set price limits
   • Integrate with pool reservation system
4. Testing & Deployment (8 hours)
   • Paper trading for 1 week
   • Deploy with small amounts
   • Monitor performance
   • Test cross-strategy contention handling

Expected Results:

• 24-48 DCA opportunities per day
• Passive accumulation of LSTs
• $20-50 profit per day (from DCA + arbitrage)
• Zero bundle conflicts between strategies

Week 24-27 (Jun 29 - Jul 26): Grid Trading Strategy

Time Budget: 40-80 hours

Tasks:

1. Grid Trading Implementation (TypeScript) (20 hours)
   • Grid level initialization
   • Price crossing detection
   • Buy/sell order generation
   • Rebalancing logic
2. Grid Configuration (4 hours)
   • Configure grid for JUP token
   • Set price range and grid levels
   • Set amount per level
3. Testing & Optimization (8 hours)
   • Backtest on historical data
   • Optimize grid parameters
   • Deploy and monitor

Expected Results:

• 20-50 grid opportunities per day
• Profit from range-bound volatility
• $30-80 profit per day (from all strategies)

Week 28-31 (Jul 27 - Aug 23): Long/Short Strategy

Time Budget: 40-80 hours

Tasks:

1. Long/Short Implementation (Rust) (24 hours)
   • Moving average calculations
   • Trend detection (golden cross, death cross)
   • Position management
   • Integration with lending protocols (Kamino/Drift)
2. Risk Management (8 hours)
   • Stop-loss logic
   • Take-profit logic
   • Position sizing
   • Leverage limits
3. Testing (8 hours)
   • Paper trading for 2 weeks
   • Start with small positions
   • Monitor closely

Expected Results:

• 5-15 long/short signals per day
• Higher risk, higher reward
• $50-150 profit per day (from all strategies)

Week 32-35 (Aug 24 - Sep 20): Production Scaling

Time Budget: 40-80 hours

Tasks:

1. Performance Tuning (16 hours)
   • Profile entire system
   • Optimize critical paths
   • Target: <200ms execution
   • Memory optimization
2. Flash Loan Integration (16 hours)
   • Kamino flash loan support
   • Zero-capital arbitrage
   • Larger position sizes (10-100 SOL)
3. Deployment to Production Server (8 hours)
   • Bare metal server setup (Hetzner/OVH)
   • Move from Docker Compose to production deployment
   • Set up monitoring and alerts
   • Optimize for latency

Expected Results (Conservative - Single Wallet):

• 200-400 opportunities per day (all strategies)
• 60-70% success rate (realistic with competition)
• 120-280 profitable trades per day
• $150-400 profit per day
• $4,500-12,000 profit per month (baseline)

Expected Results (Optimistic - With Scaling):

• Requires: Flash loans (10-100 SOL), 5-10 concurrent wallets, triangular arbitrage
• 800-1,500 opportunities per day
• 70-75% success rate
• 560-1,125 profitable trades per day
• $500-800 profit per day
• $15,000-25,000 profit per month (requires significant additional work)

Note: Profitability varies by market conditions. Low volatility weeks may yield 50% less. Competition entering your niche can reduce profits by 30-50%.

Technology Stack Summary

Rust Components (Performance-Critical)

• Shredstream client (market data)
• Arbitrage strategy (detection)
• Long/Short strategy (technical analysis)
• Universal executor (transaction building, simulation, submission)
• Strategy framework (plugin system, event routing)

Go Components (Existing)

• Quote service (local pool math, 2-10ms)
• Dark pool simulation

TypeScript Components (Rapid Development)

• DCA strategy
• Grid trading strategy
• Analytics & PnL calculation
• Monitoring dashboards
• Logging infrastructure

Infrastructure

• NATS JetStream (event bus)
• Redis (caching)
• PostgreSQL (trade history)
• Prometheus (metrics)
• Grafana (dashboards)

Optimization Insights from External Review

This plan was reviewed by Google Gemini (given only this document) to identify optimization opportunities. Here’s what we adopted and what we rejected:

✅ Adopted Recommendations

1. HTTP Keep-Alive Connection Pooling (Gemini)

• Problem: Opening new HTTP connection for every quote adds 5-15ms
• Solution: Use persistent connections with Keep-Alive (reqwest::Client in Rust)
• Impact: 5-15ms saved per quote, implemented in Phase 2 Week 4-5
• Status: ✅ Integrated into plan

2. Remove NATS from Hot Path (Gemini)

• Problem: NATS serialization adds 2-5ms to trade-critical path
• Solution: Use in-memory channels (tokio::mpsc) for trade triggers, NATS only for analytics
• Impact: 2-5ms saved on hot path
• Status: ✅ Architecture updated

3. “Smart Fire & Forget” with Sanity Checks (Gemini + Our Refinement)

• Problem: RPC simulation adds 150ms, local SVM is too complex
• Solution: Skip expensive simulation, use 5ms sanity checks, rely on Jito atomicity
• Impact: 150ms saved, 90% failure prevention
• Status: ✅ Implemented as “Smart Trade Validator” in Phase 3 Week 8-9

4. Code Freeze Before Breaks (Gemini)

• Recommendation: No new features 3 days before Jan/Feb break, 2-day revalidation on return
• Rationale: Solana ecosystem changes frequently, unmonitored systems are risky
• Status: ✅ Operational discipline adopted

⚠️ Refined Recommendations

5. Deprioritize (Not Cancel) DCA/Grid Trading (Gemini)

• Gemini’s claim: These distract from core profit engine
• Our refinement: Keep them, but build AFTER HFT arbitrage is profitable
• Rationale: DCA/Grid run on cold path (no latency impact), diversify revenue
• Status: ⚠️ Kept in Phase 5, clearly marked as deprioritized

❌ Rejected Recommendations

6. Pure “Fire and Forget” Without Validation (Gemini)

• Gemini’s proposal: Skip all validation, submit immediately, rely 100% on Jito
• Why rejected: Too risky, wastes Jito bundle submissions (they charge for spam)
• Our approach: Add 5ms sanity checks to catch 90% of failures
• Trade-off: 5ms overhead for 15-20% success rate improvement

7. Build Local SVM Simulator (Implied by some HFT docs)

• Proposal: Run Solana VM locally for fast transaction simulation
• Why rejected: 3-6 months development time, marginal benefit vs smart sanity checks
• Reality check: Even large HFT firms often skip this
• Our approach: Smart validation (1-2 days) achieves 90% of the benefit

Key Insight from External Review

The “Latency Budget” Principle:

Total 500ms budget:
- Market event: 50ms (Shredstream)
- Quote calc: 5ms (Go local math + HTTP Keep-Alive)
- Validation: 5ms (smart sanity checks, NOT 150ms RPC simulation)
- TX building: 20ms (Rust instruction assembly)
- Jito submit: 50ms (network)
- Confirmation: 400ms (Solana block time)
-----
Total: 530ms ✅ (under 500ms if we optimize confirmation polling)

Critical takeaway: Every millisecond counts. The difference between a 2-second bot (unprofitable) and a 200ms bot (profitable) is eliminating unnecessary work:

• ❌ RPC simulation (150ms) → ✅ Smart checks (5ms)
• ❌ New HTTP connections (15ms) → ✅ Keep-Alive (0ms)
• ❌ NATS hot path (5ms) → ✅ Memory channels (0.05ms)
• ❌ Sequential quotes (300ms) → ✅ Parallel (150ms)

Key Decision Points

Decision 0: Compete on Long-Tail Markets, Not Raw Speed (FOUNDATIONAL)

Rationale: Pro HFT teams ($20k-100k/month costs) ignore low-volume pairs because they need massive profit to justify infrastructure. Solo dev ($100-300/month costs) is profitable at 1/20th the volume. When: Phase 1 onwards (architectural decision) Impact:

• ✅ Enables sustainable profitability ($5k-15k/month achievable)
• ✅ Reduces competition (pros focus on top 10 pairs)
• ✅ Allows 200-500ms latency (Jito equalizes competition) Key Markets: LST pairs (jitoSOL ↔ mSOL), niche DEXes (Pump.fun, Meteora), complex 3-4 hop routes

Decision 1: Start with LST Arbitrage (High Priority)

Rationale: 60-75% success rate vs 15% on SOL/USDC, AND pros ignore this market When: Phase 3 (Feb-Mar 2026) Impact: Foundation for all other strategies, perfect “long tail” niche

Decision 2: Use Rust for Execution

Rationale: 2-10x faster than TypeScript, needed for sub-200ms execution When: Phase 3 (Feb-Mar 2026) Trade-off: Slower development but better performance

Decision 3: TypeScript for Simple Strategies

Rationale: 5x faster development for DCA, grid trading When: Phase 5 (Jun-Sep 2026) Trade-off: Slightly slower but much easier to develop

Decision 4: Extensible Architecture

Rationale: Easy to add new strategies without rewriting core When: Phase 1-2 (Dec 2025 - Jan 2026) Impact: Future-proof, scalable system

Decision 5: Deploy to Bare Metal

Rationale: Lower latency than cloud VMs When: Phase 5 (Aug-Sep 2026) Cost: $70-100/month (Hetzner AX52)

Performance Targets by Phase

Realistic Projections (Conservative)

Optimistic Projections (With Scaling)

Requires: Flash loans, 5-10 concurrent wallets, triangular arbitrage, constant optimization

Important: Optimistic targets require significant additional development (not in base plan) and perfect market conditions. Baseline conservative targets are more achievable for part-time solo developer.

Profit Reality Check ⚠️

Why Conservative Projections Are More Accurate

Factors That Reduce Profitability:

1. Market Volatility
   • Low volatility weeks: 30-50% fewer opportunities
   • High volatility: More competition from other bots
   • Some weeks may yield only $50-100/day instead of $150-400/day
2. Competition & Market Efficiency
   • Other bots discovering your LST pairs: -30-50% profit
   • Even 2-3 bots on same routes can halve your profits
   • Pros occasionally sweep long-tail markets during high volatility
3. Technical Issues
   • Network hiccups, dropped packets: -5-10% uptime
   • RPC rate limits, Jito congestion: -10-15% success rate
   • Solana network upgrades: potential 1-3 day outages
4. Liquidity Constraints
   • LST pools have low volume ($100k-$2M daily)
   • Limited to 0.1-10 SOL trades to avoid slippage
   • Large trades (50+ SOL) require flash loans (additional complexity)
5. Taxes & Fees
   • Solana transaction fees: ~$0.01 per trade (negligible)
   • Jito tips: $0.005-0.05 per bundle (5-10% of profit)
   • Capital gains taxes: 15-20% (US) - reduces net profit

Realistic Net Profit After Taxes/Fees:

Gross: $4,500-12,000/month
Jito tips (-8%): -$360-960
Taxes (-20%): -$830-2,200
───────────────────────────
Net: $3,300-8,800/month

Can You Retire on $3k-9k/Month Net?

Honest Assessment by Location:

Key Considerations:

• Healthcare: $500-1,500/month if US self-employed
• Sustainability: Can you maintain this for 5-10 years?
• Risk: Solana ecosystem changes, competition, regulation
• Income volatility: Some months $2k, some months $10k

More Realistic “Retirement” Strategy

Instead of full retirement, treat this as:

1. Supplement income while working part-time job
2. Geographic arbitrage (live in low-cost country)
3. Build multiple income streams (trading is one of 2-3)
4. Reinvest profits into other businesses/investments

Minimum “retirement” threshold:

• $8k-12k/month NET for US full retirement
• $4k-6k/month NET for low-cost country retirement
• This plan: $3k-9k/month NET = good supplemental income

What $5k-12k/Month Gross ($3k-9k Net) Actually Means

Realistic scenarios:

• ✅ Quit 9-5 job in Thailand/Portugal: Live comfortably, save 30%
• ✅ Work part-time + trading: $3k/month job + $5k trading = $8k total
• ✅ Digital nomad lifestyle: Travel while trading
• ⚠️ Full retirement in US: Possible but very tight budget
• ❌ Luxury lifestyle: Not enough for high expenses

Better mindset:

“This system generates $60k-$144k/year gross ($40k-$105k net), which is a solid side income or primary income in low-cost location. It’s not ‘retire rich’ money, but it’s ‘work optional’ money if you live strategically.”

Infrastructure Costs

Development Phase (Dec 2025 - May 2026)

Local Docker Compose: $0/month

• Redis, PostgreSQL, NATS on laptop
• No cloud costs during development

Early Production (Jun - Aug 2026)

Small Cloud VM: $20-40/month

• AWS t3.medium or similar
• For initial testing with real money

Production Scale (Sep 2026+)

Bare Metal Server: $70-100/month

• Hetzner AX52 or similar
• 16 cores, 128GB RAM, NVMe SSD
• Co-located near Solana validators

Total 9-Month Cost: $200-400

Risk Management Strategy

Circuit Breakers

• Stop after 3 consecutive failures
• Stop if daily loss > 1 SOL
• Stop if wallet balance < 0.5 SOL
• Stop if error rate > 50% in last 10 trades

Position Limits

• Min trade size: 0.1 SOL
• Max trade size: 10 SOL (phase 3-4), 100 SOL (phase 5)
• Max daily trades: 500
• Max exposure per LST: 50 SOL

Monitoring

• Real-time alerts (PagerDuty/Slack)
• Daily PnL reports (email)
• Weekly strategy review
• Monthly performance analysis

Success Milestones & Celebrations

Week 2 (Dec 22): ✅ Infrastructure running locally Week 5 (Jan 25): ✅ Market data streaming, quotes working Week 11 (Mar 31): 🎉 FIRST PROFITABLE TRADE! ($150-450/month) Week 19 (May 26): 🎉 60-65% SUCCESS RATE, $900-2,400/MONTH Week 27 (Jul 26): 🎉 3 STRATEGIES LIVE, $2,400-6,000/MONTH Week 35 (Sep 20): 🎉 PRODUCTION SYSTEM, $4,500-12,000/MONTH

Realistic Expectations

What Will Go Wrong (Plan for It)

• First few weeks: Infrastructure issues, configuration problems
• Phase 3: Many failed trades, learning what doesn’t work
• Phase 4: Performance not as expected, need more optimization
• Phase 5: Complex strategies need tuning and adjustment

What Will Go Right

• You have existing prototypes (60% done)
• LST arbitrage is proven profitable
• Community support (Solana Discord, Jito)
• Extensible architecture pays off over time

Part-Time Reality Check

• 10-20 hours/week = slow and steady progress
• Some weeks you’ll do 5 hours, some 25 hours
• Breaks are important (Christmas, vacation)
• This is a marathon, not a sprint
• Celebrate every small win

Weekly Commitment

Minimum Viable Effort

• 10 hours/week: Slow progress, 12-14 months to completion
• 2-3 hours weeknights (3 nights)
• 4-5 hours weekend

Recommended Effort

• 15-20 hours/week: Steady progress, 9-10 months to completion
• 2-3 hours weeknights (4-5 nights)
• 6-10 hours weekend

Maximum Sustainable

• 25-30 hours/week: Fast progress, but risky for hobby project
• Risk: Burnout, fatigue, mistakes
• Not recommended for long-term

Recommended: Start with 15-20 hrs/week, adjust based on energy and motivation

Final Timeline Summary

Dec 9-22 (2 weeks)         → Foundation
❌ Christmas Break
Jan 6-25 (3 weeks)         → Market Data
❌ 3-Week Break
Feb 21 - Mar 31 (5 weeks)  → Arbitrage + First Trade 🎉
Apr - May (8 weeks)        → Optimization + Reliability
Jun - Sep (16 weeks)       → Multi-Strategy Platform 🎉

Total: 34 working weeks = ~9 months calendar time
Effort: 364-714 hours total (includes 7 critical reliability/monitoring features)
Result: Production trading platform earning $5k-12k/month baseline
        With scaling: $15k-25k/month (flash loans, multiple wallets)

Next Steps (This Week)

1. Read this consolidated plan - Understand the full journey
2. Set up development environment (4-6 hours)
   • Install Rust, Go, Node.js
   • Clone repository
   • Initialize Docker Compose
3. Define token configurations (2 hours)
   • LST mint addresses
   • Pool addresses
   • Priority pairs
4. Start Phase 1, Week 1 tasks (Dec 9-15)

By December 22: Infrastructure running, ready to start building after Christmas.

Remember: This is a hobby project. Enjoy the journey, learn continuously, and celebrate every milestone! 🚀

Document Revision History

v2.3 (December 2, 2025) - Realistic Profit Projections ⚠️

What Changed: This version addresses overly optimistic profit expectations based on external review feedback (ChatGPT) and real-world HFT constraints.

1. Executive Summary: Updated Profit Targets
   • Original: “$5k-15k/month profit target”
   • Updated: “$5k-12k/month baseline, $15k-25k with scaling”
   • Why: $45k/month requires institutional-level infrastructure (flash loans, 5-10 wallets)
2. Performance Targets Table: Realistic Success Rates
   • Reduced success rates from 70-85% to 60-70% (accounts for competition)
   • Reduced daily profit estimates by ~40-60%
   • Phase 5 (Sep): $500-1,500/day → $150-400/day baseline
   • Why: Conservative estimate accounts for market volatility, competition, technical issues
3. Added “Profit Reality Check” Section
   • Factors reducing profitability (volatility, competition, liquidity, taxes)
   • Net profit after fees: $3,300-8,800/month (vs $4,500-12,000 gross)
   • Geographic arbitrage analysis (where you can “retire” on this income)
   • Realistic retirement scenarios by location
   • Why: Honest assessment prevents disappointment, sets proper expectations
4. Updated All Phase Expected Results
   • Phase 4 (May): $50-150/day → $30-80/day
   • Phase 5 (Sep): $500-1,500/day → $150-400/day
   • Success rates: 70-85% → 60-70%
   • Why: First-time solo dev likely won’t achieve institutional success rates
5. Clarified “Optimistic with Scaling” Path
   • Added separate table for optimistic projections ($15k-25k/month)
   • Clearly states requirements: flash loans, 5-10 wallets, triangular arbitrage
   • Notes this requires “significant additional work” beyond base plan
   • Why: Distinguishes achievable baseline from stretch goals

Source: External review by ChatGPT identified profit targets as “optimistic, should be treated as best-case scenario”

Key Realizations:

• $5k-12k/month ($60k-$144k/year) is a solid side income, not “retire rich” money
• Better framed as “work optional” income in low-cost location, not full US retirement
• Profitability is highly variable by market conditions (some weeks $100/day, some $500/day)
• Competition discovering your niche can reduce profits by 30-50% overnight
• This is supplemental income, not passive income (requires part-time monitoring)

Mindset Shift:

• From: “Retire on $45k/month passive income”
• To: “Generate $60k-$144k/year active income while working part-time or living abroad”

Success Probability: Still 90-95% for achieving baseline $5k-12k/month, but <10% probability for $45k/month without significant scaling

v2.2 (December 2, 2025) - ChatGPT Production Monitoring ⭐

What Changed:

1. Phase 2 Week 4-5: Added “Quote Service Circuit Breaker” (2 hours)
   • Detect 3 consecutive timeouts (>50ms) and fallback to Jupiter API
   • Auto-recovery every 30 seconds after circuit break
   • Health check endpoint for quote cache freshness
   • Why: Quote service is single point of failure for hot path
   • Impact: Prevents entire system blocking on quote service failure
2. Phase 4 Week 12-13: Added “Latency Profiling & Monitoring” (4 hours)
   • Instrument hot path with timestamp checkpoints per component
   • Log p95/max latencies to Prometheus
   • Alert if any component exceeds budget (quote >10ms, validation >5ms)
   • Why: “You can’t optimize what you don’t measure”
   • Impact: Enables data-driven performance optimization
3. Phase 4 Week 16-19: Added “Production Alerting” (4 hours)
   • Slack webhook for critical alerts (circuit breaker, stalled system, low balance)
   • Email daily summary (PnL, success rate, top errors)
   • Alert thresholds: error rate >30%, no trades in 4 hours, pool blacklist >5/hour
   • Why: Part-time dev needs proactive notifications, not 24/7 reactive monitoring
   • Impact: Know when system needs attention without constant watching
4. Phase 5 Week 20-23: Added “Strategy Coordination Layer” (4 hours)
   • In-memory pool reservation system (500ms lock per pool)
   • Priority queue: Arbitrage (hot) > Grid > DCA (cold)
   • Prevents duplicate bundle submissions from multiple strategies
   • Why: Multi-strategy system can compete for same pools
   • Impact: Avoids Jito bundle failures from internal competition
5. Updated Effort Estimates:
   • Phase 2: 32-64 hrs → 34-66 hrs (+2 hours for circuit breaker)
   • Phase 4: 80-160 hrs → 88-168 hrs (+8 hours for profiling + alerting)
   • Phase 5: 160-320 hrs → 164-324 hrs (+4 hours for coordination)
   • Total: 350-700 hrs → 364-714 hrs (+14 hours across 9 months)

Source: External review by ChatGPT identified these as “critical for production operations”

Verdict: These 4 additions increase operational reliability and success probability from 85-90% → 90-95%

Key Insight: Monitoring prevents silent failures. Without latency profiling and alerts, a degraded system (500ms → 2s) might run for days unnoticed, missing profitable opportunities.

v2.1 (December 2, 2025) - Gemini Critical Recommendations ⭐

What Changed:

1. Phase 2 Week 3: Added “Heartbeat Sync for State Validation” (4 hours)
   • 60-second RPC verification against local cache
   • Auto-flush and resync on state drift detection
   • Why: UDP/gRPC packet loss causes permanent state corruption without this
   • Impact: Prevents wrong quotes from stale pool data
2. Phase 3 Week 8-9: Enhanced Circuit Breaker to Per-Pool
   • Track Jito drop rate per pool (3 strikes = 5 min blacklist)
   • Force RPC state resync for failed pools before re-enabling
   • Prevents Jito reputation damage from spam submissions
   • Why: Jito monitors spam; repeated failures can blacklist your signer key
   • Impact: Isolates bad pools without stopping entire system
3. Phase 3 Week 10-11: Added “Replay Testing Harness” (5 hours)
   • Record and replay Shredstream events at 10x speed
   • Backtesting for HFT without real money or RPC costs
   • Why: Without RPC simulator, this is the ONLY safe way to validate logic
   • Impact: Debug arbitrage strategy without losing money
4. Updated Effort Estimates:
   • Phase 2: 30-60 hrs → 32-64 hrs (+4 hours for heartbeat sync)
   • Phase 3: 50-120 hrs → 55-125 hrs (+5 hours for replay testing)
   • Total: 340-680 hrs → 350-700 hrs (+10 hours across 9 months)

Source: External review by Google Gemini identified these as “critical for production reliability”

Verdict: These 3 additions increase success probability from 80% → 85-90%

v2.0 (December 2025) - Performance-Focused Update

What Changed:

1. Added “Understanding the Competition: Pro HFT vs Solo Dev” section
   • Detailed breakdown of institutional HFT infrastructure ($20k-100k/month)
   • “Long Tail” strategy explanation (why solo dev can win)
   • “Guerrilla Warfare” philosophy (compete where they can’t)
   • Competitive advantage analysis (lower costs, niche markets)
2. Added “Reality Check: Transaction Simulation” section
   • Clarified local SVM is a myth for solo devs
   • Explained what “shadow validator” means at pro level
   • Smart validation approach (5ms vs 150ms RPC simulation)
3. Updated Architecture
   • Hot Path (memory channels) vs Cold Path (NATS)
   • HTTP Keep-Alive connection pooling
   • Concrete latency targets per component
4. Replaced “Transaction Simulator” with “Smart Trade Validator” in Phase 3
   • Fast sanity checks instead of expensive simulation
   • Jito bundle atomicity as safety net
5. Enhanced Performance Optimization section (Phase 4)
   • Specific techniques with measured impact
   • Blockhash caching, WebSocket confirmations, parallel processing
6. Added “Optimization Insights from External Review”
   • Documented Gemini recommendations (adopted/refined/rejected)
   • Explained why certain approaches were chosen
7. Clarified DCA/Grid priorities in Phase 5
   • Deprioritized (not canceled)
   • Run on cold path, no latency impact

Why These Changes:

• External review (Google Gemini) provided institutional HFT context
• Understanding competition helps identify profitable niches
• Realistic vs overhyped approaches (local SVM, simulation)
• Emphasis on pragmatic “smart validation” over expensive simulation
• Clear separation of hot path (sub-500ms) vs cold path (seconds acceptable)
• Solo dev advantage: lower costs enable profitability at 1/20th the volume

Core Philosophy Unchanged:

• LST arbitrage first (highest success rate)
• Rust for performance-critical paths
• TypeScript for rapid development
• 9-month timeline with breaks
• Part-time solo developer focus

Performance Target Evolution:

• Original: 500-750ms execution (Phase 3 → 4)
• Updated: 300-500ms execution (with HTTP Keep-Alive, smart validation)
• Final: 100-200ms execution (Phase 5 with all optimizations)

Key Realization: The difference between profitable HFT (sub-500ms) and unprofitable bots (2s+) is eliminating unnecessary work. Every optimization in v2.0 removes milliseconds without adding complexity.

Version: 2.3 Last Updated: December 2, 2025 Next Review: After Phase 3 First Trade (March 31, 2026)

Quick Reference: Key Updates

Realistic Profit Expectations (v2.3)

• Baseline: $5k-12k/month ($3.3k-8.8k net after fees/taxes)
• With scaling: $15k-25k/month (requires flash loans, 5-10 wallets)
• Geographic arbitrage: Sufficient for “work optional” lifestyle in low-cost countries
• US retirement: Tight but possible in rural areas, not comfortable in major cities

The 7 Critical Production Features (v2.1 + v2.2)

If you’re reviewing this plan, these are the seven most important reliability/monitoring features added based on external reviews (Gemini + ChatGPT):

Data Integrity (v2.1 - Gemini)

1. Heartbeat Sync (Phase 2 Week 3) - Prevents state corruption from dropped UDP packets
2. Per-Pool Circuit Breaker (Phase 3 Week 8-9) - Protects Jito reputation from spam
3. Replay Testing (Phase 3 Week 10-11) - Safe backtesting without real money

Operational Monitoring (v2.2 - ChatGPT)

1. Quote Service Circuit Breaker (Phase 2 Week 4-5) - Prevents hot path blocking on quote failure
2. Latency Profiling (Phase 4 Week 12-13) - Enables data-driven optimization
3. Production Alerting (Phase 4 Week 16-19) - Proactive notifications for part-time dev
4. Strategy Coordination (Phase 5 Week 20-23) - Prevents internal resource competition

Total Impact: +23 hours (+3.2% effort), +10-15% success rate improvement (80% → 90-95%)