Prototype System Analysis

This document summarizes the analysis of two prototype Solana trading systems that inform the production architecture.

Overview

Three prototype systems have been analyzed:

1. references/apps - Polyglot arbitrage system (TypeScript, Go, Rust)
2. references/trading-bots - Mature TypeScript trading bot with multiple strategies
3. solana-playground - Full-stack Next.js web app with comprehensive CLI toolkit

References/Apps Prototype

Architecture

Polyglot System Design:

• TypeScript CLI tools for orchestration
• Go service for high-performance local DEX quoting (SolRoute)
• Rust services for RPC proxy and transaction planning
• Django API for analytics and data management
• Docker-based infrastructure (Redis, PostgreSQL, MongoDB)

Key Components

Bot Implementations:

1. sharedRouteArbitrageBot.ts - Flash loan arbitrage with shared routing
2. primitiveArbitrageBot.ts - Dynamic profit calculation, production-ready
3. primitiveArbitrageDFlowBot.ts - MEV-protected via DFlow

Core Services:

• jupiterSwapService.ts - Jupiter V6 API integration
• kaminoFlashloanService.ts - Kamino flash loan wrapping
• quotingEngine.ts - Hybrid SolRoute/Jupiter quoting (2-10ms local, 100-300ms API)
• jito/jitoJsonRpcClient.ts - Jito bundle submission
• solanaRpcService.ts - RPC load balancing across 95+ endpoints
• ioRedisService.ts - Route template caching with hash-based deduplication

Trading Flow:

Market Event (Shredstream slot notification)
    ↓
Get signatures for account changes
    ↓
Process transactions → Identify opportunity
    ↓
Get quote (SolRoute 2-10ms OR Jupiter 100-300ms)
    ↓
Check Redis template cache
    ↓
Build transaction:
    - Flash loan borrow
    - Swap instructions
    - Flash loan repay
    - Compute budget + priority fees
    ↓
Sign → Submit via Jito bundle → Monitor confirmation

Technical Highlights

Hybrid Quoting Strategy:

• Primary: SolRoute Go service for local pool math (Raydium, Meteora, PumpSwap)
• Fallback: Jupiter API for complex routes
• Health monitoring with automatic failover after 3 consecutive failures

Transaction Optimization:

• Address Lookup Tables (ALT) for 30-40% size reduction
• Route template caching (Redis or in-memory)
• Placeholder system for dynamic address resolution

MEV Protection:

• Jito bundle submission (primary)
• TPU client for direct submission
• Solayer RPC as alternative
• Tip strategy: 5,000 + random(0, count) * 100 lamports

Rate Limiting:

• Token bucket limiter: 60 Jupiter API calls/minute
• Concurrent arbitrage: 10 parallel attempts (primitiveBot)
• Round-robin RPC failover across 95+ endpoints

Performance Characteristics

• SolRoute quoting: 2-10ms for known pools
• Jupiter quoting: 100-300ms for any route
• Transaction confirmation: 10-30s via Jito
• Shredstream latency: 100-200ms (vs 500-1000ms websockets)

Limitations Identified

1. Jupiter API rate limiting (60 req/min)
2. SolRoute service single point of failure
3. Transaction size limits (1,280 bytes)
4. Hardcoded ALT addresses
5. Manual RPC endpoint configuration

Trading-Bots Prototype

Architecture

Monolithic TypeScript Application:

• 666 TypeScript files across 18+ modules
• Single Node.js application (not Nx-based)
• Redis-backed queue system for distributed execution
• MySQL for historical data persistence
• Mature CLI-based operational tooling

Key Features Not in References/Apps

1. Multiple Trading Strategies:

• Arbitrage (rate-limited, flash loan wrapped)
• Grid Trading (mechanical buy/sell at price levels)
• Limit Order Grid Trading (Jupiter limit orders)
• DCA/Recurring Orders (systematic accumulation)
• AI-Powered Chart Analysis (ChatGPT + TradingView)

2. Internal Order Book System:

• Queue-based order management (Bee-queue)
• Grid trading order automation
• Order TTL management
• Split order creation for volume limits

3. Sophisticated Wallet Management:

• Proxy wallets - External communication, masks source
• Worker wallets - Actual trading execution
• Controller wallets - Management operations
• Treasure wallet - Centralized funding source
• Expected balance tracking with automatic rebalancing
• Mask transfers for anonymity (multi-hop)

4. ChatGPT Integration:

• TradingView chart screenshot analysis
• Base64 image conversion and caching
• Multi-language support (Chinese/English)
• Queue-based async processing
• Follow-up analysis capabilities

5. Data Persistence:

• MySQL tables for trade history, volumes, balances, claims
• CSV export for P&L analysis
• Redis caching: prices (5min TTL), volumes (12hr TTL)
• Historical performance tracking

6. Operational Tooling (42 CLI commands):

• Balance management and wallet rebalancing
• Token price/volume collection
• Claims & rewards (Jupiter referrals, Meteora fees)
• Wallet operations (create ATAs, wrap/unwrap SOL)
• Analysis & reporting (P&L, performance evaluation)

Technical Patterns

Queue-Based Execution:

Bee-queue (Redis-backed)
    ↓
Order creation → Queue → Processing
    ↓
Decouples generation from execution
    ↓
Enables distributed processing

Expected Balance Pattern:

• Pre-calculated wallet balances cached in Redis
• Validation: expected vs. actual
• Automatic rebalancing triggers when threshold exceeded

Application Naming:

• Random app IDs for anonymity
• UUID tracking for queue operations
• Client ID linking for state management

Performance Optimizations

Caching:

• Token prices: 5-minute TTL
• Oracle prices: separate cache
• Route templates: permanent with hash keys
• Balance data: configurable refresh

Batch Processing:

• Configurable batch sizes (default 15 for arbitrage)
• Thread pooling (4-20 threads for wallet ops)
• Volume collection: 100 parallel threads

Load Balancing:

• Round-robin RPC selection
• Shard-based routing by method type
• Failover on errors
• Multiple Jito URL selection

Comparison Matrix

Strengths to Incorporate

From references/apps:

1. Microservice architecture - Scalability via Go/Rust services
2. High-performance quoting - SolRoute Go service (2-10ms)
3. Infrastructure as code - Docker Compose, monitoring stack
4. REST API layer - Django for analytics
5. Modern build tools - Nx monorepo, Turborepo

From trading-bots:

1. Multiple strategies - Arbitrage, grid, DCA, AI analysis
2. Wallet segregation - Risk management via proxy/worker/controller
3. Historical tracking - Performance analysis and optimization
4. Queue-based execution - Reliability and distributed processing
5. Operational tooling - 42 CLI commands for operations
6. Custom order book - Advanced trading patterns

From solana-playground:

1. Transaction retry patterns - Timeout-based with multi-RPC fallback
2. Wallet abstraction - Clean KeypairWallet pattern
3. RPC redundancy - 7+ Helius endpoints with rotation
4. CLI structure - 150+ modular command files
5. Utility helpers - BigNumber math, encryption, date formatting
6. Caching layer - Redis with 10-minute TTL for balances
7. React components - 40+ reusable UI components (optional for dashboard)

Pain Points Identified

references/apps:

• Single strategy focus (arbitrage only)
• No historical performance tracking
• Limited operational tooling
• Hardcoded configuration values
• No wallet risk management

trading-bots:

• Monolithic architecture (scaling challenges)
• No high-performance local quoting
• Limited monitoring/observability
• Single-language stack (TypeScript only)
• No REST API layer

Solana Playground Prototype

Architecture

Full-Stack Application:

• Next.js 14 web application with React 18
• Comprehensive CLI toolkit (150+ TypeScript files)
• Firebase backend for data persistence
• Multi-chain integration (Jupiter, OpenBook, various protocols)

Key Features

1. CLI Trading System:

• Automated Jupiter swaps, arbitrage, limit orders, DCA, long/short strategies
• OpenBook market maker implementation
• Comprehensive wallet management (generation, seeding, balance tracking)
• Token claim automation (Jupiter airdrops, ASR rewards, referral fees)
• Governance voting system

2. Transaction Management:

// Priority fee pattern: 200,000 microLamports default
// Timeout-based retry logic with multiple RPC fallbacks
// Explicit confirmation status checks

3. Wallet Abstraction:

class KeypairWallet implements WalletSigner {
  // Clean separation: keypair + connection
  // Transaction signing with recent blockhash fetching
  // Extensible for multi-sig support
}

4. RPC Redundancy:

• 7+ Helius endpoints for Jupiter swaps
• Round-robin selection with fallback
• Connection pooling per endpoint

5. Caching Strategy:

• Redis-backed balance caching (10-minute TTL)
• Firebase for persistent user data
• In-memory caching for hot paths

6. React Web Application:

• 40+ reusable UI components (MUI + Tailwind)
• Custom React hooks for async operations
• Redux + Context for state management
• Auto-generated API clients (OpenAPI specs)

Technical Highlights

Transaction Helper Pattern:

async sendAndConfirmTransactionUntilTimeout(
  connection, transaction, wallet, timeout
) {
  // Retry logic with exponential backoff
  // Multiple RPC endpoint fallback
  // Confirmation polling with status checks
}

Utility Helpers:

• BigNumber arithmetic helpers
• Decimal precision formatting
• AES encryption/decryption
• Date formatting utilities
• Array manipulation (chunks, weighted random)

CLI Structure:

• Modular command organization (150+ files)
• Helper utilities for common operations
• Market/token configuration files
• Batch operation support

Deployment

Firebase Hosting:

• SPA routing with rewrite rules
• Build optimization for Next.js + MUI
• Environment variable management

Build Configuration:

• TypeScript strict mode
• Webpack SVG loader integration
• Module transpilation optimization

Strengths

1. Proven transaction patterns - Timeout-based retry, multi-RPC fallback
2. Clean wallet abstraction - Easy to extend for hardware wallets, multi-sig
3. Comprehensive CLI toolkit - 150+ operational commands
4. RPC redundancy - 7+ endpoints with automatic failover
5. React component library - 40+ reusable components
6. API integration - Auto-generated clients from OpenAPI specs

Limitations

1. Next.js overhead for simple trading system
2. Firebase dependency (could be PostgreSQL)
3. Redux complexity for simpler state needs
4. Monolithic CLI structure (could be modular services)

Recommendations for Production

Architecture Foundation:

• Use references/apps polyglot microservice design
• Incorporate trading-bots strategy implementations
• Add distributed queue system from trading-bots
• Implement wallet segregation pattern

Technology Stack:

• TypeScript: Strategy orchestration and business logic
• Go: High-performance services (quoting, routing)
• Rust: Performance-critical paths (RPC proxy, transaction building)
• PostgreSQL: Primary data store
• Redis: Caching + queue system
• NATS: Event streaming for real-time coordination

Key Capabilities:

• Multiple concurrent strategies with conflict resolution
• Hybrid local/API quoting with automatic failover
• Sophisticated wallet management for risk control
• Historical performance tracking and analysis
• AI-powered decision support layer
• Comprehensive operational tooling
• Production monitoring (Prometheus + Grafana + custom metrics)

Next Steps

See 02-production-architecture-plan.md for the detailed production system design.