Skip to content

High Performance Solving and Market Making Infrastructure

The DeFi Arbitrage Solver is a Rust-based system designed to detect and execute arbitrage opportunities across multiple blockchain networks. The system follows a modular collector-strategy-executor architecture with real-time streaming capabilities.

Key Features

  • Multi-chain Support: Base, Ethereum, Unichain networks
  • Real-time Processing: WebSocket connections to Tycho APIs for live data
  • Strategy-Based Execution: CARB (Cyclical Arbitrage) and TOKEN (Token-Based Arbitrage) strategies
  • Flash Loan Integration: Automated flash loan execution for arbitrage
  • Route Blacklisting: Intelligent route management to prevent repeated failures
  • Performance Optimization: Sub-millisecond route calculations with in-memory caching

The architecture follows the principle: Collectors → Strategies → Execution and layers on route evaluation and liquidity mapping.

Liquidity Mapping

Conceptually this was fairly straight forward, create a graph with Tokens as Nodes, Pools as edges and then create routes for that graph. With the protocol abstraction offered by Tycho's component and state model. A pool is a pool is a pool regardless of what the underlying protocol is. This simplified the implementation considerably

Route Evaluation

Collectors: Continuously stream on-chain data

The bedrock of the collection architecture is the Tycho Indexer built on substreams. It provides real time state updates for multiple protocols filtered by TVL values for those protocols.

On top of this we build a graph manager and a route manager using Depth First Search of the graph to create the routes with a little flash_loan_manager to determine the optimal flash loan available. This includes choosing the flash loan with the lowest fee which does not have any locking conflicts with the route.

The key point for collection, once again enabled by Tycho streaming technology, is that on a state change to any of the protocols which I am monitoring. I trigger route evaluations for all routes that contain that pool. Evaluating whether a positive arbitrage cycle exists or not. I must admit its tireless work for the route evaluate and its queue manager, evaluating hundreds or even thousands of routes per block, but occasionally, just occasionally an opportunity will be found, which makes it all worthwhile.

Strategies: Analyze and simulate opportunities

The system implements two primary strategies for arbitrage execution:

CARB Strategy (Cyclical Arbitrage)

  • Traditional Approach: Evaluates all profitable routes independently
  • Execution Model: Multiple routes can be executed per arbitrage cycle
  • Use Case: General-purpose arbitrage detection with profit optimization
  • Algorithm: Bellman-Ford cycle detection for negative cycles

TOKEN Strategy (Token-Based Arbitrage)

  • Grouped Execution: Routes are grouped by input token
  • Selection Logic: Only the best route per token group is executed
  • Risk Management: Prevents duplicate execution of similar opportunities
  • Testing Mode: Supports forced execution of even negative profit routes for validation

The TOKEN strategy addresses two critical issues:

  1. Duplicate Execution Risk: Multiple routes executing for the same opportunity
  2. Repeated Failing Transactions: Same failed routes being retried continuously

Profitability Calculation

Each route evaluation includes:

  • Base Profit: Output amount minus input amount
  • Flash Loan Fees: Calculated based on flash loan provider (typically 30 bps for Uniswap V3)
  • Gas Costs: Dynamic gas estimation with current network conditions
  • Net Profit: Base profit minus all fees and costs

Execution: Executing the transactions

The execution layer provides robust transaction execution with comprehensive validation and error handling.

Execution Pipeline

  1. Route Validation: Structural validation of route components
  2. Pre-flight Simulation: On-chain simulation to verify profitability
  3. Transaction Building: EIP-1559 compliant transaction construction
  4. Gas Optimization: Dynamic gas parameter adjustment
  5. Transaction Submission: Retry logic with nonce synchronization
  6. Result Monitoring: Transaction confirmation and result logging

Flash Loan Integration

The system supports multiple flash loan providers:

  • Uniswap V3: Primary provider (30 bps fee)
  • Uniswap V4: With overflow protection
  • Balancer V2: 0 bps fee option
  • Aave V3: Variable fee structure

Flash loan selection criteria:

  • Must contain the starting token for the route
  • Flash token must NOT be in the route path
  • Lowest fee provider is automatically selected

Error Handling & Blacklisting

Failed routes are automatically blacklisted based on:

  • Pre-flight Failures: Invalid route structure, missing components
  • Simulation Failures: Routes that would revert on-chain
  • Validation Errors: Protocol compatibility issues

Note: Post-flight transaction reverts are logged but NOT automatically blacklisted to avoid removing routes that fail due to temporary conditions (MEV, slippage, etc.).