Developing DEX Price Comparison System
Task arrives: find best rate for swapping 50 ETH to USDC. Uniswap v3 gives one price, Curve—another, Balancer—third. 0.3% difference on 50 ETH is already $150 per transaction. When trading volumes from 100k USD, spread between DEXs reaches 1-2%, and every swap without aggregation is direct losses.
Price comparison system task—give user or algorithm current picture across all relevant DEXs in single request, accounting for slippage, gas cost, and split routing.
Where Naive Implementation Usually Breaks
On-Chain Calls in Real Time—Slow and Expensive
First approach that comes to mind: call quoteExactInputSingle on Uniswap v3 Quoter, get_dy on Curve, queryBatchSwap on Balancer—compare. Problem is this is on-chain execution simulation via eth_call. On mainnet with 8-12 DEXs and 3-4 route variants, you get 30+ RPC calls per user request. At 200ms per call—6 seconds waiting. By then price already changed.
Real case from practice: aggregator with naive last-write-wins cache lost quote freshness over 3-5 blocks. User saw price X, clicked swap, got revert from slippage, paid gas for nothing. Conversion dropped 40%.
Stale Data and Block Drift
Price in Uniswap v3 pool changes with each swap. If cache updates once per 12 seconds (1 block on Ethereum), several large trades may pass between updates. Especially critical for low-liquidity pools—there 1-2% price shift per block isn't rare.
Curve uses different pricing model—StableSwap invariant. Formula A * n^n * sum(x_i) + D = A * D * n^n + D^(n+1) / (n^n * prod(x_i)) is sensitive to pool balances, which change their own way. Can't apply same slippage logic for Uniswap v3 concentrated liquidity and Curve stable pools.
System Architecture
Two Data Layers: Off-Chain Indexing + On-Chain Verification
Working scheme: The Graph subgraphs for pool state indexing—liquidity, current prices, volumes. Data updates per-block and accessible via GraphQL without RPC load. For Uniswap v3—official subgraph with pools, ticks, positions. For Curve—custom subgraph or event parsing TokenExchange.
On-chain verification needed only at moment of execution: final quoteExactInput before user transaction with actual block state.
| Source | Latency | Accuracy | RPC Load |
|---|---|---|---|
| The Graph subgraph | 2-5 sec (1 block) | High | Minimal |
| Multicall + Quoter | 200-500 ms | Precise | High |
| DEX SDK (off-chain math) | <10 ms | Calculated | None |
| WebSocket events | Real-time | Event-driven | Medium |
Off-Chain Math for Speed
Uniswap v3 provides @uniswap/v3-sdk and @uniswap/smart-order-router—full route calculation with split routing happens locally, without RPC, based on loaded pool state. Similarly for Curve—Python SDK or TypeScript port of StableSwap formula allows computing get_dy locally.
This approach reduces latency to 10-50 ms and removes RPC-provider dependency from hot path.
WebSocket for Streaming
For interfaces with real-time price updates—WebSocket subscription via ethers.js provider.on('block', ...) or viem watchBlocks. On each new block recalculate quotes only for active trading pairs in UI, not entire marketplace.
Workflow
Analytics (1-2 days). Determine DEX list for specific chain, needed trading pairs, required latency. Ethereum mainnet, Polygon, Arbitrum, Base—each has different active DEXs and liquidity structure.
Backend Development (3-5 days). Indexing service with The Graph + Multicall, pool state cache, REST/WebSocket API. Stack: Node.js + TypeScript, viem for on-chain interactions, Redis for cache.
Calculation Module Development (2-3 days). Off-chain math for each connected DEX, split routing algorithm, gas cost accounting in comparison.
Frontend Integration (1-2 days). wagmi hooks for quote fetching, comparison display, transaction flow integration.
Testing. Fork-tests on Hardhat/Foundry with real mainnet state—verify calculation accuracy against actual on-chain results.
Timeline Expectations
Basic comparison system for 3-5 DEXs on single chain—3-5 days. Full aggregator with multi-chain, split routing and real-time UI—from 2 weeks. Timelines depend on number of connected DEXs and latency requirements.
Cost calculated after clarifying chains, DEXs and performance requirements.