Cross-DEX Spreads: Arcus vs Uniswap Stock Token Price Gaps

Five venues, one asset, day one

When Robinhood Chain went live on July 1, 2026, it didn't launch with one DEX and a waiting list. Uniswap, Arcus, Lighter, 1inch, and Rialto were all trading on day one. Arcus, the dYdX-incubated venue, came out of the gate as zero-fee spot trading across roughly 95 stock tokens. Uniswap showed up with its usual concentrated-liquidity pools, and its API now explicitly supports wiring Robinhood Chain assets — including stock tokens — into external apps and bots.

That's an unusual starting condition. Most new chains get one liquidity venue that slowly earns trust and volume, then a second one shows up months later fighting for scraps. Robinhood Chain shipped with five simultaneous order books for the same underlying assets, each with its own fee structure, its own LP composition, and — critically — no shared price oracle forcing them to agree with each other in real time. If you've built arbitrage infra between Uniswap and Sushiswap on mainnet, or across Arbitrum and Optimism, you already know what happens next: the same asset trades at different prices on different venues, and someone closes that gap for a living.

Why the gap exists at all

On a mature chain, cross-DEX spreads on a liquid pair are usually a few basis points, closed within one or two blocks by bots that have been running for years. Robinhood Chain is ten days old. Nothing about its arbitrage infrastructure is mature yet, which means the mechanics that normally compress spreads are still being built out:

• Liquidity is fragmented, not deep. Five venues splitting attention on ~95 stock tokens means each individual pool is thinner than it would be if all that capital sat in one place. Thin pools move more on a given trade size, which widens the price a large order pushes through relative to a competing venue.
• Fee structures differ by design. Arcus is zero-fee spot. Uniswap pools carry their normal tiered fees (and LPs price that into the spread they'll accept). A trade that's profitable net of fees on one venue may not be on the other, so the "fair" price isn't identical across them even before you account for inventory.
• No unified price oracle yet. Each pool's price is a function of its own reserves and recent flow. Nothing forces Arcus's NVDA token price and Uniswap's NVDA token price to converge instantly — that convergence is exactly the job arbitrage bots do, and on a ten-day-old chain the bot population doing that job is still small.
• Underlying market state matters more here than on typical crypto pairs. Stock tokens track NVDA, GOOG, AAPL and friends, and NASDAQ is closed nights and weekends. When the reference market is shut, on-chain price discovery runs purely on thin on-chain flow, and different venues can drift apart from each other in ways a liquid, always-open crypto pair wouldn't. If you're not already familiar with that mechanic, it's worth reading up on how the overnight and weekend dislocation on stock tokens plays out on its own, because it compounds directly with cross-venue spread.

None of that is a defect. It's just what a brand-new, fragmented-liquidity market looks like before arbitrage capital shows up in size. The spreads are a temporary symptom of immaturity, and they'll narrow as more bots and more liquidity arrive — which is exactly why the window to build this now, rather than in six months, matters.

What the arbitrage actually looks like

Mechanically this is a standard two-leg spatial arbitrage, the same shape as any cross-DEX bot on Arbitrum or Ethereum mainnet — buy the underpriced leg, sell the overpriced leg, capture the spread minus fees and slippage. The Arbitrum-stack EVM base means none of your tooling changes: viem or ethers, standard eth_call simulation, standard multicall for batched price reads.

A simplified price-check loop across two pools might look like this:

import { createPublicClient, http, parseAbi } from 'viem';

const client = createPublicClient({ transport: http(RPC_URL) });

const poolAbi = parseAbi([
 'function getReserves() view returns (uint112, uint112, uint32)'
]);

async function getSpotPrice(poolAddress) {
 const [reserve0, reserve1] = await client.readContract({
 address: poolAddress,
 abi: poolAbi,
 functionName: 'getReserves',
 });
 return Number(reserve1) / Number(reserve0);
}

async function checkSpread(arcusPool, uniswapPool, feeBps) {
 const [priceA, priceU] = await Promise.all([
 getSpotPrice(arcusPool),
 getSpotPrice(uniswapPool),
 ]);
 const spreadBps = Math.abs(priceA - priceU) / Math.min(priceA, priceU) * 10_000;
 return spreadBps > feeBps ? { direction: priceA < priceU ? 'buyArcus' : 'buyUniswap', spreadBps } : null;
}

The real system needs a lot more than this: simulated execution against actual pool depth (not just spot reserves, since a trade large enough to matter moves the price you're computing against), gas cost modeling on both legs, inventory management so you're not stuck holding a stock token overnight when the underlying market gaps at Monday's open, and a decision on whether you're routing atomically through a single contract or running two independent legs with execution risk between them. Atomic execution is safer where it's available — it eliminates the risk of one leg filling without the other — but not every venue on Robinhood Chain will support flash-style atomic routing on day ten, so plan for both paths.

Arcus vs Uniswap: the practical differences

	Arcus	Uniswap
Fee model	Zero-fee spot	Standard tiered pool fees
Origin	dYdX Labs incubated	Established AMM, ported to Robinhood Chain
Coverage	~95 stock tokens	Depends on pool deployment per asset
Automation	ArcusBot (native perp automation)	External bots via Uniswap API, built for this explicitly
Best fit for arbitrage	Lower-cost leg, good for high-frequency entries	Reliable liquidity leg, well-understood AMM math

Verdict: neither venue is strictly better — they're complementary legs. Arcus's zero fees make it attractive as the higher-frequency side of a spread trade, since fee drag doesn't eat your edge on smaller moves. Uniswap's AMM is a known quantity with well-documented slippage curves, which makes depth-aware sizing more predictable. A bot that treats this as a five-way (not just two-way) price-discovery problem across Arcus, Uniswap, Lighter, 1inch, and Rialto will find more opportunities than one hardcoded to a single pair of venues, though building and maintaining routing across five immature venues simultaneously is meaningfully more engineering than a single pair.

Where this goes from here

Cross-DEX spreads compress as markets mature — that's true on every chain that's ever launched multiple DEXes at once. The question isn't whether the opportunity shrinks, it's how fast, and nobody has ten-day-old-chain-to-mature-chain data for Robinhood Chain specifically yet. What history from other Arbitrum-stack rollouts suggests is that the compression happens in weeks, not months, once serious market-making capital notices. Robinhood's push toward agentic accounts — letting traders connect AI models directly to execute strategies — will likely accelerate that further by lowering the barrier to running exactly this kind of bot.

If you're weighing whether to build this yourself or want a second opinion on architecture before committing engineering time, our strategy consultation covers exactly this kind of pre-build tradeoff analysis. For teams that have already built cross-venue arbitrage on Ethereum or other EVM chains, see how the approach compares across ecosystems — the core logic transfers, but pool depth, fee tiers, and settlement timing on Robinhood Chain change the sizing and risk parameters meaningfully.

Want this running against your own capital? Our Robinhood Chain arbitrage bot build covers multi-venue price monitoring, atomic execution where available, and inventory risk controls tuned for stock tokens specifically.