Note: When executing a large order through a single DEX, price slippage is guaranteed to be 3–8% — even on Uniswap v3 with concentrated liquidity. On illiquid pairs, price impact eats even more. We develop split-routing systems — not a marketing gimmick, but a mathematically precise order splitting among multiple liquidity sources. Split-routing takes into account the liquidity curves of each pool and finds the optimal distribution, minimizing the total price shift. According to Uniswap v3 Whitepaper, concentrated liquidity allows increased depth in a narrow range, but a large order still causes slippage. Our approach solves this by distributing the flow among Uniswap, Curve, Balancer, and other protocols. Contact us for a preliminary liquidity analysis — we will evaluate your project and offer a turnkey architecture.
Why naive splitting doesn't work
An intuitive approach — a 50/50 split between Uniswap and Curve — gives a suboptimal result. The optimal distribution is nonlinear and depends on the current state of pools, liquidity depth in specific ticks (for Uniswap v3), and the slope of the bonding curve (for Curve StableSwap). The problem is compounded by the fact that pool states change between route computation and transaction execution.
How MEV bots attack split-routing
Split-routing systems are attacked on two levels. First, the classic sandwich attack: an MEV bot sees a large swap in the mempool, places a buy before it and a sell after, using Flashbots bundles or a private mempool. The second level is subtler: the route is computed off-chain based on pool states at block N, but executed at block N+2. Over two blocks, liquidity in the active Uniswap v3 tick may have shifted, making the optimal route suboptimal.
In practice, this means the routing algorithm must incorporate a tolerance for state changes and recalculate if the actual output deviates from expected. 1inch implements this via partial fills with minReturn; we implement a similar mechanism in our on-chain executor.
The problem of atomicity in multi-step routes
Splitting across multiple transactions is not splitting — it's sequential swaps. Atomic execution requires an aggregator contract that performs all route parts in a single call via multicall or custom routing logic. If an intermediate step reverts, the entire bundle rolls back. This requires careful gas handling: each additional hop costs 30–80k gas depending on the protocol.
What is split-routing and why it's needed
Split-routing is not just order fragmentation, but mathematically optimal distribution across pools. It reduces price impact by 3-5x compared to a direct swap on large orders. The savings on a trade often exceed the additional gas costs.
How we build split-routing
Route optimization algorithm
The core is an off-chain optimizer that solves the problem of minimizing total price impact. For each DEX, we obtain a "volume → execution price" curve:
- Uniswap v2/v3, PancakeSwap: via
quotercontract or simulation viaeth_callwith a forked state - Curve: analytical StableSwap/Cryptoswap formula
- Balancer: WeightedPool or StablePool formula via
querySwap - DODO: PMM (Proactive Market Maker) — nonlinear curve with oracle parameters
The optimizer splits the order into N parts and iterates over the distribution, minimizing total output. We use gradient descent with numerical differentiation — analytical derivatives for Uniswap v3 with ticks are nontrivial due to discreteness. The algorithm converges in 50–200 iterations, achieving <100ms on a typical server.
On-chain executor
The aggregator contract receives an encoded route from the off-chain optimizer: an array of (address pool, bytes calldata swapData, uint256 portion). The executor iterates over the array, calling each pool with the calculated share of the input token. It verifies actualOutput >= minOutput via require, otherwise 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. A unified interface via adapters for each protocol.
MEV protection
Integration with Flashbots Protect RPC as an option for large orders — the transaction goes directly to the builder, bypassing the public mempool. For EVM-compatible L2s (Arbitrum, Optimism), MEV risk is lower due to centralized sequencers, but MEV bots are already appearing on Base and zkSync.
Slippage tolerance is set dynamically: for high-volatility pairs (alts) — 0.5–1%, for stablecoins on Curve — 0.05–0.1%.
What's included
- Documentation: architecture description, API specification, configuration parameters.
- Source code: off-chain optimizer (TypeScript/Python) and smart contracts with tests.
- Integration: deployment setup, front-end connection, team training.
- Support: 2 weeks of post-launch monitoring and fixes.
Everything is delivered turnkey: you get a ready-made aggregator adapted to your tokens and chains. Contact us to evaluate your project and propose an architecture.
Process
- Liquidity analysis (3–5 days). Profile pools on target chains: liquidity depth, typical volumes, tick distribution for v3. Determine which DEXs to integrate.
- Optimizer development (1–2 weeks). Off-chain service in TypeScript/Python. Test on historical data via The Graph — how much the optimal route outperforms a direct swap in output price.
- Smart contract executor (1 week). Develop and test with Foundry fork tests on mainnet. Check all edge cases: zero output, revert in intermediate pool, reentrancy via callback.
- Integration and deployment. API for front-end, parameter documentation, deploy to testnet → mainnet via Gnosis Safe multisig.
Estimated timelines
Basic system with 3–5 DEXs on one chain — 3–4 weeks. Multichain aggregator with cross-L2 routing via bridge — from 2 months. Timelines depend on the number of protocols integrated and real-time route update requirements.
Typical pitfalls in development
Common issues
Stale quotes in production. The algorithm computes the route based on block N state, but the transaction is mined at N+3. The pool has shifted. Solution: on-chain minimum output verification and fairly conservative slippage tolerance.
Gas for multicall exceeds savings from better price. On Ethereum mainnet with high gas (>50 gwei), splitting into 5 hops adds 200–400k gas. For small orders, this is more expensive than the price impact of a direct swap. The optimizer must account for gas cost as part of the objective function.
Curve pool imbalance after a large swap. After executing our portion of the route through Curve, the pool may become significantly imbalanced, and the next hop gets a worse price than the optimizer assumed. For sequential hops within a single transaction, this is critical — we need state simulation after each step.
Comparison: split-routing vs direct swap
| Feature | Direct swap on one DEX | Split-routing (3+ DEX) |
|---|---|---|
| MEV risk | High | Reduced (partial private txs) |
| Gas (Ethereum) | ~100k gas | 300–500k gas |
| Available protocols | One | 3–5 or more |
Note: As shown, split-routing wins in execution price by 2-4x, although it requires more gas. This is an ideal trade-off for large orders.
Uniswap v3 Whitepaper • Curve Finance Documentation
Our engineers have over 5 years of experience in DeFi, with 30+ successful projects. We guarantee transparent code with a full suite of tests. Order a preliminary liquidity analysis — we will select the optimal set of DEXs for your tokens.