Разработка системы 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)
- Пользователь формирует
UserIntent— структуру с параметрами желаемого исполнения - Подписывает EIP-712 typed signature (off-chain, без gas)
- Intent публикуется в p2p сеть или централизованный auction server
- Solvers конкурируют за 30-60 секунд: каждый рассчитывает маршрут и подаёт bid
- Settlement контракт верифицирует подпись, сравнивает bids, исполняет лучший
- 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 контракт — критическая часть. Он должен:
- Верифицировать EIP-712 подпись пользователя
- Выбрать лучший bid (максимальный
buyAmount) - Исполнить
executionDataот solver'а - Проверить post-execution: пользователь получил
>= minBuyAmount - Если нет — 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'ов.
Подробнее о защите
Мы используем commit-reveal в аукционе: solver отправляет хеш своего bid, а затем раскрывает его. Это предотвращает копирование и манипуляции со стороны других участников.Что входит в работу
| Компонент | Описание | Срок |
|---|---|---|
| Settlement контракт | EIP-712, аукцион, верификация | 1-2 недели |
| Solver-сервер | Pathfinding, real-time данные, bid calculation | 1-2 недели |
| Тестирование | Fork-тесты, fuzzing, MEV resistance | 1 неделя |
| Документация | API, архитектура, деплой-скрипты | 3 дня |
| Поддержка | 2 месяца после релиза | — |
Сравнение подходов: централизованный аукцион vs p2p сеть
| Критерий | Централизованный аукцион | P2P сеть |
|---|---|---|
| Latency | Низкая (50-100ms) | Выше (200-500ms) |
| Децентрализация | Нет | Да |
| Сложность реализации | Средняя | Высокая |
| MEV-устойчивость | Ниже | Выше |
Стек
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.