Intent Solvers System Development

Intent Solvers System Development

Traditional DeFi model: the user specifies an exact execution route — which DEX, which pool, what slippage. If the price moves while the transaction is in the mempool — reverted, gas spent. Intent-based architecture inverts this: the user says "I want to get at least X of token B for Y of token A", signs the intent, and a network of solvers compete to execute it optimally.

CoW Protocol (Coincidence of Wants), UniswapX, 1inch Fusion — these are mature implementations of intent-based execution. But the solver logic behind them is competitive infrastructure that can be built for proprietary protocols.

How the intent/solver system works

Intent lifecycle

1. User creates a UserIntent — a structure with desired execution parameters
2. Signs it with EIP-712 typed signature (off-chain, no gas)
3. Intent is published to a p2p network or centralized auction server
4. Solvers compete for 30-60 seconds: each calculates a route and submits a bid
5. Settlement contract verifies the signature, compares bids, executes the best one
6. Solver receives part of the surplus (difference between best and stated price)

struct UserIntent {
    address sellToken;
    address buyToken;
    uint256 sellAmount;
    uint256 minBuyAmount;     // Minimum acceptable, solver must give >= this
    uint256 deadline;
    address recipient;
    bytes32 nonce;            // Replay protection
}

struct SolverBid {
    bytes32 intentHash;
    uint256 buyAmount;        // How much buyToken solver provides
    bytes executionData;      // Encoded calldata for execution
    address solver;
    bytes signature;
}

Verification and settlement

Settlement contract is the critical part. It must:

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

Execution pattern: solver calls settle() with pre-approved transfer. Settlement contract:

• Withdraws sellToken from the user (via pre-approval or permit)
• Executes arbitrary calldata from the solver (swap on DEX, chain of swaps)
• Verifies that the user's buyToken balance increased by >= minBuyAmount

Arbitrary calldata from the solver is an attack vector. A whitelist of permitted contracts or strict validation is needed: calldata can only call pre-approved DEX routers.

Solver architecture

Router

Solver must find the best execution route in ~10-30 seconds. This is a pathfinding problem across liquidity:

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 expectedOutput with price impact
    const quotes = await Promise.all(
        paths.map(path => simulatePath(path, sellAmount))
    );
    
    // Optimal split across multiple paths (split routing)
    return optimizeSplit(paths, quotes, sellAmount);
}

Split routing — the key advantage of a smart solver. Splitting an order across multiple paths reduces price impact and gives better average price than a single large swap.

Real-time pool data

Solver must have current pool state 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 solver
• Mempool monitoring — solver sees pending transactions and factors them into price

For Uniswap v3: pool state (sqrtPriceX96, tick, liquidity) must be updated incrementally after each Swap event. Full recalculation via RPC is too slow.

Working with CoW (Coincidence of Wants)

If two users want to exchange opposite tokens — solver can match them against each other without DEX. Buyer A: 100 ETH → USDC. Buyer B: 200k USDC → ETH. Solver matches 100 ETH ↔ 200k USDC, saves gas and slippage for both. This is the unique advantage of batch settlement.

MEV protection

Intent-based architecture inherently protects against frontrunning: the intent is signed with minBuyAmount, sandwich attacks are impossible — if the final price is below the threshold, the transaction reverts. But the solver itself can frontrun its own trades. Solution: commit-reveal scheme for bid auctions.

Stack

Solidity — settlement contract, EIP-712 types, DEX whitelist. TypeScript + viem — solver logic, pathfinding, DEX integrations. Foundry — testing settlement contract, especially execution edge cases. Redis — pool state cache, intent queue. Hardhat fork tests — simulation of complex multi-hop routes on mainnet fork.

Working process

Analytics (3-5 days). Define scope: which tokens, which DEX, centralized auction or p2p, solver monetization model.

Settlement contract development (1-2 weeks). EIP-712 signature, 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, CoW scenario simulation, MEV resistance tests.

Timeline estimates

Basic system for one DEX and simple single-hop execution — 1-2 weeks. Full multi-DEX system with split routing, CoW, and auctions — 4-6 weeks. Cost is calculated individually.