How OwlSight Works

Cross-chain arbitrage is opaque. A visible price gap between two chains does not tell a trader whether the trade is worth making after bridge fees, slippage, and latency are accounted for. Most tooling stops at the surface spread — OwlSight starts there.

OwlSight is an execution intelligence layer that sits above a trading engine. It detects route candidates, scores them against real cost models, runs probabilistic simulation, and only hands approved trades to the execution layer.

The pipeline has four distinct stages: detect (find price dislocations), score (run feasibility simulation), decide (apply guardrails), and execute (hand off to Hummingbot). Each stage is a hard gate — a route that fails scoring never reaches execution.

OwlSight ingests prices from one of three providers, selected at startup via the MARKET_DATA_PROVIDER environment variable. Each provider is an interchangeable adapter — the opportunity engine receives a normalised quote regardless of source.

Four chains are supported: Solana, Base, Ethereum, and Arbitrum. Venues covered include Jupiter (Solana), Aerodrome (Base), Uniswap V3 (Ethereum / Base), and Camelot (Arbitrum). Assets tracked: SOL, ETH, WBTC.

A raw price gap between two chains is necessary but not sufficient for a profitable trade. The feasibility engine deducts trading fees, bridge fees, slippage, and a latency penalty from the gross spread to produce an expected net profit.

Bridge cost profiles

Monte Carlo simulation

For every candidate route, the engine runs 500 simulated execution paths. Each path samples from a slippage distribution (seeded from the route's liquidity depth), applies bridge latency variance, and models price drift over the expected execution window. The output is a profit distribution with three key percentiles:

Confidence score

The confidence score (0–1) is a composite of three factors: the probability that net profit exceeds the minimum threshold (P(profit)), the bridge reliability score for the route's bridge pair, and a slippage penalty that reduces confidence as estimated slippage rises. A score of 0.68 or above is required for approval.

Hummingbot is the executor, not the strategist. OwlSight's adapter converts an approved opportunity into a TradeExecutionRequest — a structured payload that contains everything Hummingbot needs to act, along with guardrail constraints it must respect.

The handoff contract

TradeExecutionRequest {
  request_id          // unique ID written to hummingbot/requests/
  opportunity_id      // links back to the scored route
  asset_symbol        // SOL | ETH | WBTC
  symbol              // trading pair, e.g. "SOL-USDT"
  side                // "buy_then_bridge_then_sell"
  source_chain        // where the buy happens
  source_venue        // DEX on source chain
  destination_chain   // where the sell happens
  destination_venue   // DEX on destination chain
  bridge_name         // Wormhole | Across
  notional_usd        // trade size in USD
  asset_amount        // asset quantity
  paper_trade         // always true in current deployment
  guardrails {
    max_slippage_bps       // hard cap on acceptable slippage
    min_net_profit_usd     // reject if expected profit below this
    min_confidence_score   // reject if confidence below this
  }
}

Three mandatory guardrails are evaluated before any route reaches the execution adapter. A route that fails any single guardrail is marked rejected— it appears in the UI with a rejection reason but is never submitted to Hummingbot.

Paper-trade-first policy

All executions in the current deployment use binance_paper_trade as the Hummingbot connector. This means no real capital is ever at risk. The full execution stack — intent, simulation, decision, handoff — runs as a credible, safe demonstration of what live trading would look like.

The configuration flag HUMMINGBOT_PAPER_TRADE=true must be set for execution to proceed. The backend refuses to submit to a live connector unless paper-trade mode is explicitly disabled by an operator.

OwlSight persists every execution automatically. When a trade reaches a terminal state — approved, rejected, or fallback — the frontend saves both the opportunity snapshot and the execution record to a local database via Prisma. No backend changes are required; the Next.js layer handles all persistence.

Auto-save on execution

The runtime hook monitors execution state. The moment terminal: true is received from the backend, two records are written:

Bookmarking from Mission Control

In addition to auto-save, traders can bookmark any opportunity card manually using the Save Simulation button in the right panel. The button confirms with a green checkmark and the simulation appears immediately in the Simulation Library.

Dashboard overview

The dashboard at /dashboard renders a command-center summary:

Execution History

The full history at /dashboard/history provides a filterable table with progressive disclosure — rows are collapsed by default. Clicking any row expands a detail panel showing the full timeline, cost breakdown, and rejection or fallback reason.

Filters are all client-side for instant feedback: status (completed / rejected / fallback), asset symbol, date range, and sort order. An Export CSV button downloads the visible rows as owlsight-executions.csv for tax or P&L analysis.

Simulation Library

The library at /dashboard/simulations shows all saved route snapshots as cards. Each card shows a confidence bar, color-coded net P&L, slippage, fees, bridge latency, and approval status.