Разработка системы intent solvers

Разработка системы intent solvers

Традиционная модель DeFi: пользователь указывает точный маршрут исполнения — какой DEX, какой пул, какой slippage. Если за время ожидания транзакции в мемпуле цена сдвинулась — reverted, gas потрачен. Intent-based архитектура инвертирует это: пользователь говорит «хочу получить не менее X токенов B за Y токенов A», подписывает намерение, а solver сети соревнуются за право исполнить его наилучшим образом.

CoW Protocol (Coincidence of Wants), UniswapX, 1inch Fusion — это зрелые реализации intent-based исполнения. Но логика solver'а за ними — это конкурентная инфраструктура, которую можно строить под собственные протоколы.

Как работает система intent/solver

Жизненный цикл намерения (intent)

1. Пользователь формирует UserIntent — структуру с параметрами желаемого исполнения
2. Подписывает EIP-712 typed signature (off-chain, без gas)
3. Intent публикуется в p2p сеть или централизованный auction server
4. Solvers конкурируют за 30-60 секунд: каждый рассчитывает маршрут и подаёт bid
5. Settlement контракт верифицирует подпись, сравнивает bids, исполняет лучший
6. Solver получает часть surplus (разница между лучшей и заявленной ценой)

struct UserIntent {
    address sellToken;
    address buyToken;
    uint256 sellAmount;
    uint256 minBuyAmount;     // Minimum acceptable, solver должен дать >= этого
    uint256 deadline;
    address recipient;
    bytes32 nonce;            // Защита от replay
}

struct SolverBid {
    bytes32 intentHash;
    uint256 buyAmount;        // Сколько buyToken solver даёт
    bytes executionData;      // Encoded calldata для исполнения
    address solver;
    bytes signature;
}

Верификация и settlement

Settlement контракт — критическая часть. Он должен:

1. Верифицировать EIP-712 подпись пользователя
2. Выбрать лучший bid (максимальный buyAmount)
3. Исполнить executionData от solver'а
4. Проверить post-execution: пользователь получил >= minBuyAmount
5. Если нет — revert всей транзакции

Паттерн исполнения: solver вызывает settle() с pre-approved transfer. Settlement контракт:

• Забирает sellToken от пользователя (через pre-approval или permit)
• Выполняет arbitrary calldata solver'а (swap на DEX, цепочка свапов)
• Проверяет что buyToken баланс пользователя вырос на >= minBuyAmount

Arbitrary calldata от solver'а — это вектор атаки. Нужна whitelist разрешённых контрактов или строгий validation: calldata может вызывать только pre-approved DEX роутеры.

Архитектура solver'а

Маршрутизатор

Solver должен найти лучший маршрут исполнения за ~10-30 секунд. Это задача pathfinding по графу ликвидности:

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> {
    // Строим граф всех пулов
    const graph = buildLiquidityGraph(sources);
    
    // Ищем все пути длиной 1-3 hop
    const paths = findAllPaths(graph, sellToken, buyToken, maxHops=3);
    
    // Для каждого пути считаем expectedOutput с учётом price impact
    const quotes = await Promise.all(
        paths.map(path => simulatePath(path, sellAmount))
    );
    
    // Оптимальное разделение между несколькими путями (split routing)
    return optimizeSplit(paths, quotes, sellAmount);
}

Split routing — ключевое преимущество умного solver'а. Разделение ордера на несколько путей снижает price impact и даёт лучшую среднюю цену, чем один большой swap.

Real-time данные пулов

Solver должен иметь актуальное состояние пулов с минимальной latency. Варианты:

• WebSocket подписка на Swap события через Alchemy/Infura — latency ~500ms, достаточно для большинства случаев
• Собственная full node с IPC — latency ~50ms, для высокочастотного solver'а
• Mempool мониторинг — solver видит pending транзакции и учитывает их при расчёте цены

Для Uniswap v3: состояние пула (sqrtPriceX96, tick, liquidity) после каждого Swap события нужно обновлять инкрементально. Полный пересчёт через RPC — слишком медленно.

Работа с CoW (Coincidence of Wants)

Если два пользователя хотят обменяться противоположными токенами — solver может исполнить их между собой без DEX. Buyer A: 100 ETH → USDC. Buyer B: 200k USDC → ETH. Solver сматчивает 100 ETH ↔ 200k USDC, экономит gas и slippage обоим. Это уникальное преимущество batch settlement.

Защита от MEV

Intent-based архитектура по природе защищает от frontrunning: намерение подписано с minBuyAmount, sandwich атака невозможна — если итоговая цена хуже threshold, транзакция реверсируется. Но solver сам может быть фронтраннером по отношению к своим собственным сделкам. Решение: commit-reveal схема для аукциона bid'ов.

Стек

Solidity — settlement контракт, EIP-712 типы, whitelist DEX. TypeScript + viem — solver логика, pathfinding, DEX интеграции. Foundry — тестирование settlement контракта, особенно edge cases исполнения. Redis — кэш состояния пулов, очередь намерений. Hardhat fork tests — симуляция сложных multi-hop маршрутов на mainnet fork.

Процесс работы

Аналитика (3-5 дней). Определяем scope: какие токены, какие DEX, централизованный аукцион или p2p, модель монетизации solver'а.

Разработка settlement контракта (1-2 недели). EIP-712 подпись, аукционная логика, security checks. Особое внимание к arbitrary calldata execution.

Разработка solver'а (1-2 недели). Pathfinding, real-time state management, bid calculation.

Тестирование (1 неделя). Fork-тесты на mainnet, симуляция CoW сценариев, MEV resistance тесты.

Ориентиры по срокам

Базовая система для одного DEX и простого single-hop исполнения — 1-2 недели. Полноценная мульти-DEX система с split routing, CoW и аукционом — 4-6 недель. Стоимость рассчитывается индивидуально.