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

1. The user creates a UserIntent structure with execution parameters.
2. Signs an EIP-712 typed signature (off-chain, no gas).
3. The intent is published to a p2p network or a central auction server.
4. Solvers compete for 30-60 seconds: each calculates a route and submits a bid.
5. The settlement contract verifies the signature, compares bids, and executes the best one.
6. 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:

1. Verify the user's EIP-712 signature
2. Select the best bid (maximum buyAmount)
3. Execute the solver's executionData
4. Check post-execution: the user received >= minBuyAmount
5. If not, revert the entire transaction

Execution pattern: the solver calls settle() with a pre-approved transfer. The settlement contract:

• Takes sellToken from the user (via pre-approval or permit)
• Executes the solver's arbitrary calldata (swap on DEX, chain of swaps)
• Checks that the user's buyToken balance 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 Swap events 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.

What's Included

Centralized Auction vs. P2P Network

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.