Разработка системы intent solvers для DeFi

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

Пользователь теряет на slippage до 3% из-за задержек между подписанием и исполнением. Intent solvers решают эту проблему. Недавний кейс: клиент с ордером в 500 ETH на обмен USDC терял около $10 000 на проскальзывании при прямом свопе. После внедрения split routing с тремя пулами потери снизились до $500. Мы проектируем и разрабатываем системы солверов под ключ для DeFi-протоколов. Наши инженеры — опытные Solidity-разработчики с 5+ лет в блокчейне и 15+ проектов в портфолио.

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

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

Как работает система 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; } 

Спецификация EIP-712 (Ethereum Improvement Proposal)

Как работает 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. Наши solver'ы обрабатывают до 100 intent'ов в секунду — в 3 раза быстрее типовых реализаций.

Почему split routing повышает эффективность?

При работе с крупными ордерами прямой swap на одном пуле вызывает значительный price impact. Split routing разбивает ордер на части и исполняет их через разные пулы, сохраняя ликвидность и минимизируя проскальзывание. Это особенно выгодно на загруженных рынках. В одном из проектов экономия составила до 2.5% от объёма сделки — для ордера в 100 ETH это $5000.

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'ов.

Что входит в работу

Сравнение подходов: централизованный аукцион vs p2p сеть

Стек

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 недель. Стоимость рассчитывается индивидуально. Свяжитесь с нами — оценим проект за 1 день. Получите консультацию по архитектуре и оптимизации gas.