Development of Intent Solver Systems for DeFi
Users lose up to 3% in slippage (on large orders, that's thousands of dollars) due to delays between signing and execution. Intent solvers solve this problem. Recent case: a client with a large order was experiencing significant slippage. After implementing split routing across multiple pools, losses dropped dramatically. We design and build complete solver systems for DeFi protocols. Our engineers are experienced Solidity developers with 5+ years in blockchain and 15+ projects in their portfolio.
The Problem: Traditional DeFi Execution
The traditional DeFi model: the user specifies an exact execution route—which DEX, which pool, which slippage. If the price moves while the transaction is in the mempool, it reverts and gas is wasted. Intent-based architecture inverts this: the user says "I want at least X tokens B for Y tokens A," signs the intent, and a network of solvers competes to execute it optimally.
CoW Protocol, UniswapX, and 1inch Fusion are mature implementations of intent-based execution. But the solver logic behind them is competitive infrastructure that can be built for your own protocols. We guarantee contract audits and MEV protection at the architecture level.
How Intent/Solver Systems Work
The Intent Lifecycle
- The user creates a
UserIntentstructure with execution parameters. - Signs an EIP-712 typed signature (off-chain, no gas).
- The intent is published to a p2p network or a central auction server.
- Solvers compete for 30-60 seconds: each calculates a route and submits a bid.
- The settlement contract verifies the signature, compares bids, and executes the best one.
- The solver receives a share of the surplus (difference between the best and advertised price).
struct UserIntent {
address sellToken;
address buyToken;
uint256 sellAmount;
uint256 minBuyAmount; // Minimum acceptable, solver must provide at least this
uint256 deadline;
address recipient;
bytes32 nonce; // Replay protection
}
struct SolverBid {
bytes32 intentHash;
uint256 buyAmount; // How much buyToken the solver provides
bytes executionData; // Encoded calldata for execution
address solver;
bytes signature;
}
Specification: EIP-712
How the Settlement Contract Works
The settlement contract is critical. It must:
- Verify the user's EIP-712 signature
- Select the best bid (maximum
buyAmount) - Execute the solver's
executionData - Check post-execution: the user received
>= minBuyAmount - If not, revert the entire transaction
Execution pattern: the solver calls settle() with a pre-approved transfer. The settlement contract:
- Takes
sellTokenfrom the user (via pre-approval or permit) - Executes the solver's arbitrary calldata (swap on DEX, chain of swaps)
- Checks that the user's
buyTokenbalance increased by>= minBuyAmount
Arbitrary calldata from the solver is an attack vector. We implement a whitelist of allowed contracts or strict validation: calldata may only call pre-approved DEX routers.
Solver Architecture
Router
The solver must find the best execution route in ~10-30 seconds. This is a pathfinding problem on a liquidity graph:
interface LiquiditySource {
type: 'uniswapV3' | 'curve' | 'balancer' | 'uniswapV2';
address: string;
fee: number;
token0: string;
token1: string;
liquidity: bigint;
sqrtPriceX96: bigint;
}
async function findOptimalRoute(
sellToken: string,
buyToken: string,
sellAmount: bigint,
sources: LiquiditySource[]
): Promise<Route> {
// Build graph of all pools
const graph = buildLiquidityGraph(sources);
// Find all paths of length 1-3 hops
const paths = findAllPaths(graph, sellToken, buyToken, maxHops=3);
// For each path, calculate expected output considering price impact
const quotes = await Promise.all(
paths.map(path => simulatePath(path, sellAmount))
);
// Optimal split between multiple paths (split routing)
return optimizeSplit(paths, quotes, sellAmount);
}
Split routing is the key advantage of a smart solver. Splitting an order across multiple paths reduces price impact and yields a better average price than a single large swap. Our solvers handle up to 100 intents per second—3x faster than typical implementations.
Why Split Routing Improves Efficiency
For large orders, a direct swap on one pool causes significant price impact. Split routing breaks the order into parts and executes them through different pools, preserving liquidity and minimizing slippage. This is especially beneficial in congested markets.
Real-Time Pool Data
The solver must have up-to-date pool states with minimal latency. Options:
- WebSocket subscription to
Swapevents via Alchemy/Infura—latency ~500ms, sufficient for most cases - Own full node with IPC—latency ~50ms, for high-frequency solvers
- Mempool monitoring—solver sees pending transactions and accounts for them in price calculation
For Uniswap V3: pool state (sqrtPriceX96, tick, liquidity) must be updated incrementally after each Swap event. Full recalculation via RPC is too slow.
Coincidence of Wants (CoW)
If two users want to exchange opposite tokens, the solver can match them directly without a DEX. Buyer A wants to swap ETH for USDC. Buyer B wants to swap USDC for ETH. The solver matches them directly, saving both gas and slippage. This is a unique advantage of batch settlement.
MEV Protection
Intent-based architecture inherently protects against frontrunning: the intent is signed with minBuyAmount, so sandwich attacks are impossible—if the final price is worse than the threshold, the transaction reverts. However, the solver itself could be frontrun on its own trades. Solution: a commit-reveal scheme for the auction bids.
More on protection
We use commit-reveal in the auction: the solver submits a hash of its bid, then reveals it. This prevents copying and manipulation by other participants.What's Included
| Component | Description | Timeline |
|---|---|---|
| Settlement contract | EIP-712, auction, verification | 1-2 weeks |
| Solver server | Pathfinding, real-time data, bid calculation | 1-2 weeks |
| Testing | Fork tests, fuzzing, MEV resistance | 1 week |
| Documentation | API, architecture, deployment scripts | 3 days |
| Support | 2 months post-release | — |
Centralized Auction vs. P2P Network
| Criteria | Centralized Auction | P2P Network |
|---|---|---|
| Latency | Low (50-100ms) | Higher (200-500ms) |
| Decentralization | No | Yes |
| Implementation complexity | Medium | High |
| MEV resistance | Lower | Higher |
Tech Stack
- Solidity — settlement contract, EIP-712 types, DEX whitelist
- TypeScript + viem — solver logic, pathfinding, DEX integrations
- Foundry — testing settlement contract, especially edge cases
- Redis — pool state cache, intent queue
- Hardhat fork tests — simulation of complex multi-hop routes on mainnet fork
Our Process
Analysis (3-5 days). Define scope: which tokens, which DEXs, centralized auction or p2p, solver monetization model.
Settlement contract development (1-2 weeks). EIP-712 signing, auction logic, security checks. Special attention to arbitrary calldata execution.
Solver development (1-2 weeks). Pathfinding, real-time state management, bid calculation.
Testing (1 week). Fork tests on mainnet, simulation of CoW scenarios, MEV resistance tests.
Timeline and Cost
A basic system for a single DEX with simple single-hop execution: 1-2 weeks, cost starting from $15,000. A full multi-DEX system with split routing, CoW, and an auction: 4-6 weeks, cost typically $40,000-$60,000. Cost is determined after analysis. Contact us—we'll estimate your project in 1 day. Get a consultation on architecture and gas optimization.
Savings from reduced slippage can amount to thousands of dollars on large orders, often recouping development costs quickly.