DEX Aggregator Development with Swap Routing

A developer integrates a swap into a dApp, directly into a single Uniswap v3 pool — and users complain about poor rates. The reason: for large swaps ($50K+), the liquidity of a single pool is not optimal. Splitting across multiple sources (split routing) can yield a 0.3–0.8% price improvement. On a $100K swap, that's $300–800 difference. That's exactly what a DEX aggregator does — it finds the optimal route across multiple DEXes simultaneously.

We develop a DEX aggregator from scratch: from routing engine design to smart contract deployment (Aggregator Router, SwapStep). Our engineers have experience with 10+ protocols and thousands of pools. The aggregator provides users with better prices, reduces slippage, and saves gas compared to manual pool hunting. Get a consultation — we will assess your project. Our portfolio includes 10+ DeFi projects, with a guarantee of code transparency and on-time delivery.

Technical complexity: routing algorithm

DEX liquidity graph and pathfinding

The routing problem is finding the optimal path in a directed graph where:

• Nodes = tokens
• Edges = pools (each pool creates two edges: token0→token1 and vice versa)
• Edge weight = output amount for a given input

For a simple swap A→B, we need the shortest path (maximizing output). For split routing, we split the input into K parts and find K paths that together give the maximum output.

The naive approach — brute-force all paths of length 1–3 hops, compare outputs — works for a small number of pools. With 10,000+ pools (Uniswap v3 on mainnet has >8,000 active pools), optimization is needed.

Practical approach:

1. Pre-filter: only pools with TVL > $100K and volume > $10K in 24h
2. Bellman-Ford to find all paths up to 3 hops
3. For split routing: simulate several proportions (100/0, 80/20, 60/40, 50/50) through each route, pick the maximum

For EVM chains with high gas (Ethereum mainnet), a 3-way split is already suboptimal: the savings from a better price can be offset by additional gas. On Arbitrum/Optimism (gas ~$0.01–0.05), split routing is beneficial even for small swaps.

How split routing improves swap price

Key requirement: calculate amountOut for each route quickly and accurately without on-chain calls (expensive and slow).

Uniswap v2 (x*y=k): analytical formula:

amountOut = (amountIn * 997 * reserveOut) / (reserveIn * 1000 + amountIn * 997) 

Reserves data via getReserves() — one RPC call per pool.

Uniswap v3 (concentrated liquidity): no analytical formula for arbitrary amounts. Need to simulate tick-by-tick. QuoterV2.quoteExactInputSingle does this on-chain but is an RPC call with gas simulation. For fast routing — use off-chain tick math (@uniswap/v3-sdk) with cached tick data from subgraph.

Curve: get_dy(i, j, dx) — a view function, static call. Each Curve pool requires a separate RPC call, but they can be batched via Multicall3.

Data staleness and solution

Reserve and tick data become stale with each block. In volatile markets, the price can shift significantly in 1–2 blocks. Update strategies:

• Subscription to events: Sync (Uniswap v2), Swap (Uniswap v3/Curve) via WebSocket. On each event, update the cache for that specific pool.
• Periodic polling: every 5–10 seconds for less liquid pools.
• On-demand refresh: when a quote is requested, update data for the top 10 pools in the route via Multicall.

Our approach: WebSocket events for the top 100 pools by TVL, polling every 15 seconds for the rest.

Aggregator architecture

On-chain vs Off-chain routing

Fully off-chain: the routing Engine calculates the route and returns ready calldata for the swap router. The smart contract is just an executor, with no path selection logic. This is the 1inch v5 Aggregation Router approach. Minimal on-chain gas, but trust in the backend.

Hybrid: routing off-chain, on-chain verification of minimum output. The contract receives path + amountOutMinimum, executes via Uniswap/Curve routers, and checks require(amountOut >= amountOutMinimum). If not satisfied, revert. This is our recommended approach.

Aggregator Router contract

contract AggregatorRouter { function swap( SwapParams calldata params ) external payable returns (uint256 amountOut) { // For each step of the route for (uint i = 0; i < params.steps.length; i++) { amountOut = _executeStep(params.steps[i], amountOut); } require(amountOut >= params.minAmountOut, "Insufficient output"); // Transfer output tokens to recipient IERC20(params.tokenOut).safeTransfer(params.recipient, amountOut); } } 

SwapStep contains: protocol (uniswap_v2/v3/curve/balancer), poolAddress, tokenIn, tokenOut, portion (for split routing — how much goes through this step).

Aggregator fee

Aggregators charge fees in two ways:

• Spread: show the user a quote slightly worse than the real one, keeping the difference. Opaque.
• Explicit fee: charge N bps (basis points) on the output. Transparent, better for reputation.

Typical: 5–30 bps (0.05–0.30%) depending on swap size. Implemented in the contract as feeAmount = amountOut * feeBps / 10000.

Multichain and bridging

Extending the aggregator to cross-chain swap: user sends USDC on Ethereum, receives MATIC on Polygon. Under the hood: swap USDC→bridgeToken on Ethereum, bridge via Across/Stargate, swap bridgeToken→MATIC on Polygon.

Integration with Across Protocol v3: SpokePool.deposit() with destination calldata for the final swap. Bridge latency: 1–5 minutes. Gas: significantly higher than a single swap, feasible from $1000+ amount.

Technology stack

Backend routing engine: TypeScript, viem for RPC calls, Redis for pool data caching, WebSocket for event subscriptions. Smart contracts: Solidity 0.8.x + Foundry. Frontend: React + wagmi + token import via Uniswap Token Lists standard.

For subgraph data (TVL, volume, Uniswap v3 ticks): The Graph hosted service or a custom subgraph on Graph Node.

What's included

• Architecture documentation for routing engine and smart contracts
• Source code with full commit history (Git)
• Integration with DEX pools: Uniswap v2/v3, Curve, Balancer, Sushiswap
• Deployment of smart contracts on mainnet/testnet
• API for quote retrieval and swap execution
• Frontend interface showing routes and fee details
• Monitoring access (Tenderly, Grafana)
• Client team training (2-hour workshop)
• 1 month post-launch support

Process

Routing engine (1-2 weeks). Pool graph, pathfinding algorithm, output simulation, caching. Smart contract (1 week). Aggregator router + fork mainnet tests.

API and frontend (1-2 weeks). Quote API, swap UI with route display. Testing. Compare quotes with benchmarks (1inch, Paraswap) across thousands of transactions.

Timeline estimates

Final timeline: from 2–3 weeks for an MVP to 2–3 months for a full product. Contact us — get a detailed estimate for your project. Our team's experience: 5+ years in DeFi, 10+ implemented aggregators. Order an engineer consultation.