Arcus Explained: The Zero-Fee DEX Built by dYdX Labs
What is Arcus DEX? The zero-fee spot exchange dYdX Labs incubated on Robinhood Chain, covering ~95 Stock Tokens with ArcusBot's automated perp trading layer.
Arcus launched on Robinhood Chain's first day of public mainnet, July 1, 2026, and it did something none of the other four day-one venues did: it charged nothing to trade. No maker fee, no taker fee, on either side of the book. dYdX Labs incubated it, which is a useful signal if you're trying to guess at its design philosophy, but the thing that actually matters for a trading desk is simpler. Arcus is a zero-fee spot DEX carrying roughly 95 Stock Tokens, with a companion product, ArcusBot, that handles automated perpetual trading on top of it.
That's a narrow, specific product. Worth being precise about what it is and isn't before building anything against it.
What Arcus actually is
Arcus is a spot exchange for tokenized equities (NVDA, GOOG, AAPL and roughly 90 others) running on an Ethereum L2 that settles back to Ethereum for finality. It's not a synthetic derivatives platform pretending to be equities; the tokens give you economic exposure to the underlying stock's price, not a legal claim on shares, and they're not available to US persons. Outside the US, barring a handful of restricted jurisdictions including Canada, the UK, and Switzerland, anyone can hold and trade them. Because Robinhood Chain is permissionless, anyone can also build against the venue without asking for a listing or an API key from a gatekeeper.
Zero fees is the headline, and it's a real structural choice, not a promotional discount. On most AMM-style DEXes, the swap fee (typically 5-30bps depending on pool tier) is the mechanism that compensates liquidity providers for impermanent loss. Remove the fee and you need another way to pay LPs, or you accept thinner liquidity than a fee-bearing pool would attract at the same size. We don't know yet which path Arcus has taken; the pools are ten days old and there's no way to responsibly quote depth, spread, or realized LP returns this early. What you can reason about is the mechanics. A zero-fee venue is structurally cheaper to round-trip through, which makes it a natural first or last leg in any multi-hop arbitrage route, and structurally more attractive to a market maker optimizing for tight quotes over fee capture rather than fee revenue.
ArcusBot sits alongside the spot product as the perp layer, running automated perpetual trading on the same asset set. The exact mechanism, whether it's a vault-style strategy, a keeper-driven perp DEX, or something closer to dYdX's own v4 architecture ported over, isn't something worth guessing at publicly yet. What's fair to say: pairing a zero-fee spot venue with a perp product on the same tokens is the classic dYdX playbook. Basis trades, funding arbitrage, and hedged spot exposure all get cheaper to run when one leg of the trade costs nothing to execute.
Why the zero-fee spot leg changes bot design
Every arbitrage or market-making strategy has a fee floor, the minimum spread you need to capture before a trade is worth executing. Cut one leg's fee to zero and you lower that floor for any route that touches Arcus, which means smaller, more frequent dislocations become profitable to act on. That's a meaningful edge if your infrastructure can actually see and act on those dislocations fast enough. It's irrelevant if you're polling on a five-second interval and losing the race to someone who isn't.
The setup that matters most right now is the one described in our guide to building against Uniswap and Arcus on Robinhood Chain: five DEXes went live simultaneously on the same chain, trading overlapping sets of Stock Tokens, and Stock Tokens trade 24/7 while the underlying NASDAQ and NYSE listings close nights and weekends. During market hours, arbitrageurs working across venues, plus the ability to hedge on traditional exchanges, should keep Arcus, Uniswap, Lighter, 1inch, and Rialto reasonably in line with each other. Outside market hours, on-chain price discovery runs on thin, purely crypto-native order flow with no underlying market to anchor against. Now you have five separate venues, one of them fee-free, that can each drift independently until the open forces a reconciliation. That's the setup worth building for, and it's also the setup most likely to produce real losses if your bot isn't watching every venue at once.
A minimal cross-venue spread monitor, using viem against two Robinhood Chain pools, illustrates the shape of it. Plug in the actual Arcus and Uniswap pool addresses and ABIs once you've confirmed them:
import { createPublicClient, http } from "viem";
const client = createPublicClient({
chain: robinhoodChain, // Arbitrum-stack L2, custom chain config
transport: http(process.env.RH_CHAIN_RPC),
});
async function getSpotPrice(poolAddress, poolAbi) {
const slot0 = await client.readContract({
address: poolAddress,
abi: poolAbi,
functionName: "slot0",
});
// sqrtPriceX96 -> price, standard Uniswap-v3-style math
const sqrtPriceX96 = slot0[0];
const price = (Number(sqrtPriceX96) / 2 ** 96) ** 2;
return price;
}
async function checkSpread(arcusPool, uniswapPool, abi) {
const [arcusPrice, uniPrice] = await Promise.all([
getSpotPrice(arcusPool, abi),
getSpotPrice(uniswapPool, abi),
]);
const spreadBps = ((uniPrice - arcusPrice) / arcusPrice) * 10_000;
console.log(`NVDA spread: ${spreadBps.toFixed(1)} bps (Arcus vs Uniswap)`);
return spreadBps;
}
That's a read-only sketch, not a strategy. A real version needs gas-aware execution, slippage limits per pool, inventory tracking across venues, and a hard rule for what happens when the "spread" you just measured is a stale RPC read rather than a genuine dislocation. Because Robinhood Chain runs on the Arbitrum stack, all the usual EVM tooling applies: viem or ethers for the client layer, Foundry or Hardhat for testing routes against a fork, and the same MEV-awareness (public mempool exposure, sandwich risk) you'd bring to any Arbitrum deployment. If you've built cross-DEX arbitrage bots on Ethereum or Arbitrum before, the pattern transfers directly. The new variable is an equity-market schedule sitting behind a price that never actually closes.
Arcus vs. the other day-one venues
| Arcus | Uniswap (on RH Chain) | Lighter / 1inch / Rialto | |
|---|---|---|---|
| Fee model | Zero-fee spot | Standard tiered swap fees | Varies by venue |
| Incubated by | dYdX Labs | Uniswap Labs | Independent |
| Perp layer | ArcusBot | None (spot only) | Lighter is perp-focused |
| Stock Token coverage | ~95 | Broad, via Uniswap's API integration | Not yet well documented |
| Best fit for bots | Fee-sensitive routing, one leg of a cross-venue trade | Deep tooling support, an API built with bots in mind | Case by case |
Verdict: Arcus is the venue you route through, not necessarily the one you anchor to. Its zero-fee structure makes it the cheapest leg in a multi-hop or cross-venue trade, and ArcusBot is worth watching as a hedging tool once its mechanics are documented. But with the chain ten days old, there's no liquidity depth data anywhere that justifies treating any single venue as primary. Build for all five, and let the routing logic decide per trade.
Where this actually gets built
Reading a slot0 call is the easy 10% of a working strategy. The hard part is RPC infrastructure that doesn't fall over under load, execution logic that accounts for the fact that a zero-fee pool can still have terrible depth, and a deployment process that's been checked for reentrancy and oracle-manipulation risk before it touches real capital. If you're writing your own execution contracts rather than just calling existing pools, see our guide to deploying on Robinhood Chain and have the result put through a smart contract audit before it holds funds.
If you'd rather have a team that's already built this kind of cross-venue monitoring and execution layer do it for you, talk to us about a Robinhood Chain arbitrage bot built to watch Arcus, Uniswap, and the rest of the day-one venues in one place.
Need a bot like this built?
We design, build and run trading bots on Solana, Hyperliquid and Polymarket.
Start a projectMore from the blog
Public vs Paid RPC: How to Run a Fair Benchmark
A fair comparison of public and paid RPC endpoints must account for quotas, workload, freshness and support guarantees.
Read articleRPC Benchmark Percentiles Explained: p50, p95 and p99
Why averages hide the latency spikes that break trading bots, wallets and production blockchain applications.
Read articleHyperliquid REST vs WebSocket Benchmark: What to Measure
A benchmark plan for Hyperliquid market data that separates request latency from streaming freshness and recovery.
Read article