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

> Discover how CloddsBot scans for real-time arbitrage opportunities across Solana and EVM chains. Learn about its technical approach to latency measurement, data normalization, and opportunity ranking for maximum profit.

- Repository: [AL/CloddsBot](https://github.com/alsk1992/CloddsBot)
- Tags: deep-dive
- Published: 2026-09-11

---

**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`](https://github.com/alsk1992/CloddsBot/blob/main/src/trading/venue-arbitrage-scanner.ts) and [`src/trading/venue-arbitrage.ts`](https://github.com/alsk1992/CloddsBot/blob/main/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`](https://github.com/alsk1992/CloddsBot/blob/main//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`](https://github.com/alsk1992/CloddsBot/blob/main//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.

```typescript
// 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`](https://github.com/alsk1992/CloddsBot/blob/main/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`](https://github.com/alsk1992/CloddsBot/blob/main//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`](https://github.com/alsk1992/CloddsBot/blob/main//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`](https://github.com/alsk1992/CloddsBot/blob/main//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.