Split-Routing System for Price Optimization

Developing a Split-Routing System for Price Optimization

A 500K USDC order through a single DEX guarantees slippage of 3-8% depending on pool depth. On Uniswap v3 with concentrated liquidity, the situation is better, but on illiquid pairs, price impact still consumes a significant portion of the trade. Split-routing is not marketing—it's mathematics: optimal order division among multiple liquidity sources reduces cumulative price impact by operating on different portions of curves.

Why Naive Division Doesn't Work

The intuitive approach—50/50 split between Uniswap and Curve—produces suboptimal results. Optimal distribution is nonlinear and depends on current pool state, liquidity depth in specific ticks (for Uniswap v3), and bonding curve slope (for Curve StableSwap). The problem worsens because pool state changes between route computation and transaction execution.

Front-running via MEV and Route Staleness

Split-routing systems are attacked on two levels. First—classic sandwich attack: MEV-bot sees large swap in mempool, inserts buy before it and sell after, using flashbots bundle or private mempool. Second level is subtler: route is computed off-chain by pool state at block N, executed at block N+2. Over two blocks, liquidity in active Uniswap v3 ticks could shift, making the optimal route suboptimal.

In practice, this means the routing algorithm must budget for state changes and recalculate when output diverges from expectation. 1inch implements this via "partial fill" with minReturn; we implement similar mechanism in on-chain executor.

Atomicity Problem of Multi-Step Route

Split across multiple transactions isn't a split—it's sequential swaps. For atomic execution, we need an aggregator contract that performs all route parts in one call via multicall or custom routing logic. If an intermediate step reverts—entire bundle reverts. This requires careful gas handling: each additional hop costs 30-80k gas depending on protocol.

How We Build Split-Routing

Route Optimization Algorithm

Core of the system—off-chain optimizer solving cumulative price impact minimization problem. For each DEX, we obtain curve "volume → execution price":

• Uniswap v2/v3, PancakeSwap: via quoter contract or simulation via eth_call with state fork
• Curve: analytical StableSwap/Cryptoswap formula
• Balancer: WeightedPool or StablePool formula via querySwap
• DODO: PMM (Proactive Market Maker) with oracle-driven parameters

Optimizer divides order into N parts and iterates distribution, minimizing cumulative output. Uses gradient descent with numerical differentiation—analytical derivatives for Uniswap v3 ticks are nontrivial due to discreteness. Algorithm converges in 50-200 iterations, fitting within <100ms on typical server.

On-chain Executor

Aggregator contract receives encoded route from off-chain optimizer: array of (address pool, bytes calldata swapData, uint256 portion). Executor iterates array, calling each pool with calculated input token portion. Verifies actualOutput >= minOutput via require, else reverts.

struct SwapStep {
    address pool;
    address tokenIn;
    address tokenOut;
    uint256 amountIn;
    bytes data; // ABI-encoded call to pool
}

For Uniswap v3, data contains encoded exactInputSingle with parameters. For Curve—exchange with i, j, dx. Unified interface through protocol-specific adapters.

MEV Protection

Flashbots Protect RPC integration as option for large orders—transaction goes directly to builder, bypassing public mempool. On EVM-compatible L2s (Arbitrum, Optimism), MEV risk is lower due to centralized sequencer, but MEV-bots already exist on Base and zkSync.

Slippage tolerance configured dynamically: for high-volatility pairs (alts)—0.5-1%, for stablecoins on Curve—0.05-0.1%.

Workflow

Liquidity Analysis (3-5 days). Profile pools on target chains: liquidity depth, typical volumes, tick distribution for v3. Determine DEX list for integration.

Optimizer Development (1-2 weeks). Off-chain service in TypeScript/Python. Test on historical data via The Graph—how much optimal route outperforms direct swap on output price.

Smart Contract Executor (1 week). Development and testing in Foundry with mainnet fork-tests. Check all edge cases: zero output, revert in intermediate pool, reentrancy via callback.

Integration and Deployment. API for front-end, parameter documentation, testnet → mainnet deployment via Gnosis Safe multisig.

Timeline Expectations

Basic system with 3-5 DEXs on single chain—3-4 weeks. Multi-chain aggregator with cross-L2 routing via bridge—from 2 months. Timelines depend on number of integrated protocols and real-time route update requirements.

Common Pitfalls in Development

Stale Quotes in Production. Algorithm computes route by block N state, transaction mines at N+3. Pool shifted. Solution—on-chain minimum output verification and sufficiently conservative slippage tolerance.

Gas on Multicall Exceeds Savings from Better Price. On Ethereum mainnet at high gas (>50 gwei), 5-hop division adds 200-400k gas. For small orders, this costs more than direct swap price impact. Optimizer must account for gas as part of objective function.

Curve Pool Imbalance After Large Swap. After route part execution through Curve, pool may become severely imbalanced, and next hop gets worse price than optimizer predicted. For sequential hops within single transaction, this is critical—need state simulation after each step.