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

Розробка системи Intent Solvers

Традиційна модель DeFi: користувач вказує точний маршрут виконання — який DEX, який пул, який slippage. Якщо цена змінилася під час перебування транзакції в mempool — revert, газ витрачений. Intent-based архітектура інвертує це: користувач каже «хочу отримати щонайменше X токенів B за Y токенів A», підписує намір, а мережа solver-ів змагаються виконати це оптимально.

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

Як працює система intent/solver

Життєвий цикл намірів

1. Користувач формує UserIntent — структуру з параметрами бажаного виконання
2. Підписує її EIP-712 типізованою підписом (off-chain, без газу)
3. Намір публікується в p2p мережу або централізований сервер аукціону
4. Solver-и змагаються 30-60 секунд: кожен розраховує маршрут і подає bid
5. Settlement контракт верифікує підпис, порівнює bid-и, виконує найкращий
6. Solver отримує частину surplus (різниця між найкращою та заявленою ціною)

struct UserIntent {
    address sellToken;
    address buyToken;
    uint256 sellAmount;
    uint256 minBuyAmount;     // Мінімально прийнятне, solver повинен дати >= цього
    uint256 deadline;
    address recipient;
    bytes32 nonce;            // Захист від replay
}

struct SolverBid {
    bytes32 intentHash;
    uint256 buyAmount;        // Скільки buyToken надає solver
    bytes executionData;      // Кодований calldata для виконання
    address solver;
    bytes signature;
}

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

Settlement контракт — критична частина. Він повинен:

1. Верифікувати EIP-712 підпис користувача
2. Вибрати найкращий bid (максимальний buyAmount)
3. Виконати executionData від solver
4. Перевірити після виконання: користувач отримав >= minBuyAmount
5. Якщо ні — revert всієї транзакції

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

• Забирає sellToken від користувача (через pre-approval або permit)
• Виконує довільний calldata від solver (swap на DEX, ланцюг swap-ів)
• Перевіряє що баланс buyToken користувача виріс на >= minBuyAmount

Довільний calldata від solver — це вектор атаки. Потрібна whitelist дозволених контрактів або строга валідація: calldata може викликати тільки pre-approved DEX router-и.

Архітектура 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, економить газ і slippage обом. Це унікальна перевага batch settlement.

Захист від MEV

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

Стек

Solidity — settlement контракт, EIP-712 типи, DEX whitelist. 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. Особлива увага довільному calldata виконанню.

Розробка solver (1-2 тижні). Pathfinding, real-time управління станом, розрахунок bid.

Тестування (1 тиждень). Fork-тести на mainnet, симуляція CoW сценаріїв, тести резистентності до MEV.

Орієнтири по термінам

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