VerdiktaPartner
Our development team recently designed and launched an automated Solana cross-venue spread monitor written in TypeScript. The primary objective was to use the Jupiter Lite API (lite-api.jup.ag/swap/v1) for real-time price scanning across high-volume token pairs, specifically SOL/USDC, BONK/SOL and JUP/USDC. It covers major decentralized exchanges: Raydium, Orca, Meteora and Phoenix.
During our initial mainnet scans, the system pulled route quotes and mapped out cross-venue spreads. A noticeable data point emerged on the JUP/USDC pair: a persistent spread of 65 basis points (bps) and above. At first glance, a 0.65% discrepancy looks like a clear arbitrage window. However, closer analysis showed that the gap came from a single low-liquidity Raydium pool. Jupiter's own router already avoids that pool because its price is worse, so the spread is not exploitable. We also caught a pseudo-positive +7 bps round-trip return on JUP. It turned out to be a timing artifact: the two legs were quoted about a second apart, so it was not a genuine risk-free spread.
To analyze these logs properly, we outsourced a dedicated development task on Verdikta Bounties (Bounty #255). The brief was a Python Pandas script to collapse our raw multi-venue logs, exclude frozen quotes caused by stuck order books, and extract persistent spread runs. The submission arrived with 28 pytest tests and was accepted by the AI jury. On our real data, it correctly isolated Phoenix's frozen quote and identified Raydium as the persistent outlier. Our own checks found two gaps the jury missed. A 500,000-row file took 158 seconds against a 10-second requirement, and a row with an extra field crashed the parser. Next time we would require a benchmark output and a malformed-row fixture in the task.
Moving forward, a production-ready iteration of our system requires two structural changes. First, the infrastructure must move from public HTTP polling to dedicated, private gRPC nodes. This reduces the latency gaps that generate artificial pricing ghosts. Second, to safely capture real micro-spreads, the execution layer must implement atomic trade routing. Both legs would be submitted in a single transaction or a Jito bundle, so either both execute or the whole bundle reverts, with no one-sided market exposure.
Top comments (0)