How CloddsBot Performs Real-Time Arbitrage Opportunity Scanning: A Technical Deep Dive

CloddsBot discovers cross-venue arbitrage opportunities by orchestrating parallel quote collection across Solana and EVM chains, measuring real-time latency for each venue, and feeding normalized data into a planning engine that ranks opportunities by net edge after accounting for fees, slippage, and latency penalties.

The open-source alsk1992/CloddsBot repository implements a high-frequency trading arbitrage scanner that continuously monitors decentralized exchanges for price disparities. This article examines the real-time opportunity scanning architecture implemented in src/trading/venue-arbitrage-scanner.ts and src/trading/venue-arbitrage.ts, detailing how the bot aggregates quotes from multiple DEX aggregators, captures precise latency metrics, and identifies profitable cross-venue trades.

Configuring the Scan Request

Every real-time arbitrage scan begins with a VenueArbitrageLiveScanRequest that defines the operational parameters. According to the source code in /src/trading/venue-arbitrage-scanner.ts (lines 70-85), the request specifies:

• Token pair (base and quote tokens)
• Quote size and slippage tolerance (in basis points)
• Maximum latency threshold (maxLatencyMs)
• Minimum net edge (minNetEdgeBps) to filter unprofitable opportunities
• Target venues (Solana-only, EVM-only, or cross-chain)

This configuration object allows operators to enforce strict latency limits and profitability thresholds before the scanner even initiates API calls.

Parallel Quote Collection Across Venues

Once the request is validated, the scanner launches asynchronous quote collection across all specified venues. The implementation uses Promise.allSettled to execute venue-specific quote functions concurrently without blocking on slow or failing sources.

In /src/trading/venue-arbitrage-scanner.ts (lines 84-99), the scanner maps each venue to its corresponding query function—such as quoteJupiterVenue for Solana or quoteUniswapVenue for EVM chains—and wraps each call with timeQuote. This parallel approach ensures that a failure or timeout in one DEX (e.g., Raydium or 1inch) does not prevent the collection of quotes from other venues.

// Parallel quote collection with fault isolation
const settled = await Promise.allSettled(
  venues.map(v => venueQuoteFnMap[v](ctx, deps))
);

settled.forEach((r, i) => 
  r.status === 'fulfilled'
    ? quotes.push(r.value)
    : skipped.push({ venue: venues[i], reason: String(r.reason) })
);

Latency Measurement and Penalty Application

Real-time opportunity scanning requires precise latency tracking to avoid stale data. The timeQuote utility (lines 105-111 in venue-arbitrage-scanner.ts) records the exact round-trip time for each API call, returning both the quote data and the measured latency in milliseconds.

This latency metric is stored in every ScannedVenueQuote object. When the planning stage evaluates arbitrage potential, it applies latency penalties to accounts with slower response times, ensuring that high-latency venues are deprioritized even if their raw prices appear favorable.

Normalizing Cross-Chain Quote Data

Raw responses from Jupiter, Uniswap, and other aggregators use disparate formats. The scanner normalizes these into uniform ScannedVenueQuote objects via the buildScannedQuote helper (lines 94-104). Each normalized quote contains:

• Ask/bid prices and available size
• Market identifiers and routing information
• Latency measurements captured during retrieval
• Venue descriptions for debugging

This normalization allows the downstream planner to treat Solana and EVM venues uniformly, abstracting away chain-specific implementation details.

The Arbitrage Planning Engine

After collection, the array of ScannedVenueQuote objects is converted to plain VenueQuote instances and passed to findVenueArbitragePlans in /src/trading/venue-arbitrage.ts (lines 28-55). This engine performs:

1. Instrument grouping – organizing quotes by token pair
2. Pairwise evaluation – generating every possible buy-sell venue combination
3. Cost accounting – calculating trading fees, latency penalties, stale-data penalties, and inventory constraints
4. Profit ranking – sorting plans by expected net profit and edge

The resulting VenueArbitragePlan objects include detailed fee breakdowns and adjusted profitability metrics, ensuring that only viable opportunities surface.

Result Formatting and User Interface Integration

The final VenueArbitrageScanResult encapsulates the original request, timestamp, sorted quotes, skipped venues with failure reasons, and the top-ranked arbitrage plans. The formatVenueArbitrageScanResult function (lines 126-144) renders a human-readable summary suitable for bot commands.

Users can trigger scans via the /opportunities scan command defined in /src/skills/bundled/rust-hft-arbitrage/index.ts (lines 7-15), integrating the scanner directly into the bot interface.

Summary

• CloddsBot initiates scans via VenueArbitrageLiveScanRequest with configurable latency and profitability thresholds.
• Parallel collection using Promise.allSettled queries Jupiter, Uniswap, and other DEXs simultaneously without single-point failures.
• timeQuote captures precise latency for every venue, enabling penalty adjustments during planning.
• Unified data models (ScannedVenueQuote, VenueQuote) normalize cross-chain responses for uniform processing.
• findVenueArbitragePlans evaluates all venue pairs, applies fee and latency penalties, and ranks opportunities by net edge.

Frequently Asked Questions

How does CloddsBot handle failures when querying individual DEXs?

The scanner wraps each venue query in Promise.allSettled, which isolates failures so that a timeout or error in one DEX (e.g., Raydium) does not block responses from others (e.g., Jupiter or Uniswap). Failed venues are logged in the skipped array with specific error reasons, allowing the scan to complete with partial data.

What latency thresholds does CloddsBot use for arbitrage scanning?

Latency limits are configurable per scan via the maxLatencyMs parameter in VenueArbitrageLiveScanRequest. The default implementation captures actual round-trip times using timeQuote and applies these measurements as penalties during the planning phase, effectively filtering out venues that exceed the operator's latency budget.

Which blockchain networks does the arbitrage scanner support?

According to the source code, the scanner supports Solana (via Jupiter and Raydium) and EVM-compatible chains (via Uniswap, 1inch, and other aggregators). The family field in the scan request allows operators to target Solana-only, EVM-only, or cross-chain opportunities.

How does the planner account for trading fees and slippage?

The findVenueArbitragePlans function in /src/trading/venue-arbitrage.ts builds each VenueArbitragePlan by deducting explicit trading fees, applying slippage adjustments based on the requested slippageBps, and adding latency penalties and stale-data penalties. This comprehensive cost accounting ensures that reported net edges reflect actual executable profit rather than gross price discrepancies.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}