В DeFi долгое время доминировала простая модель: пользователь сам выбирает протокол, сам нажимает нужные кнопки и сам несёт на себе почти всю операционную сложность. Нужно свапнуть токен, потом внести залог, потом занять стейбл, потом застейкать receipt-токен, потом перевести что-то в другой rollup — значит делаешь длинную цепочку ручных действий и надеешься, что нигде не переплатишь, не проскользнёшь и не поймаешь лишний риск.
Intent-based execution layer — это попытка перевернуть модель. Пользователь описывает не последовательность кликов, а желаемый результат: например, «получить лучший доступный fixed-income exposure на 30 дней в USDC с лимитом по slippage и только на whitelisted venues» или «обменять ETH на cbBTC и доставить актив в Base не хуже заданной цены». Дальше уже не пользователь вручную ищет маршрут, а сеть solver’ов, market maker’ов или routing-движок решает, как именно исполнить задачу.
Для технической аудитории это интересная тема не только как UX-улучшение. По сути intent-layer — это новый execution plane поверх DeFi: слой, который соединяет пользователя, ликвидность, solver economics, risk policy, bridges, RFQ, onchain settlement и automation. А значит это хорошая почва и для продукта, и для инфраструктурного MVP.
Из свежих инженерных сигналов вокруг Hacker News сейчас снова хорошо видно, что ценность часто смещается от «умного интерфейса» к правильной orchestration-модели. В DeFi это особенно заметно: проблема редко в том, что на рынке нет нужного примитива. Проблема обычно в том, что пользователь не хочет сам быть ручным оркестратором между DEX, bridge, vault, oracle-проверками и risk guardrails. Именно это и закрывают intents.
Что именно разбираем
Сегодняшний фокус такой:
- что такое intent-based execution в DeFi и чем он отличается от обычных транзакций;
- как это работает простыми словами;
- какие сущности участвуют: user, relayer, solver, RFQ maker, settlement contract, oracle и policy engine;
- где именно возникают fee flow, risk transfer и потенциальный MEV;
- какие реальные сценарии применения уже выглядят полезно;
- как собрать похожий MVP / prototype / automation layer без попытки построить «новый блокчейн».
Если коротко, intent-system — это не просто «ещё один роутер». Это способ вынести сложность исполнения в отдельный рынок исполнителей.
Как это работает простыми словами
Самая полезная модель мышления здесь такая:
- обычная транзакция — пользователь говорит: «сделай шаг 1, шаг 2, шаг 3»;
- intent — пользователь говорит: «вот мой желаемый итог и мои ограничения, добейтесь его оптимальным способом».
То есть intent описывает:
- что пользователь хочет получить;
- что он готов отдать;
- в каких пределах допустимы price impact, latency, venue selection и chain risk;
- когда intent истекает;
- кто имеет право его исполнить;
- какие условия считаются успешным settlement.
Пример без магии
Обычный подход:
- свапнуть USDC в ETH;
- перевести ETH в другую сеть;
- застейкать обёрнутый актив;
- положить receipt-токен в vault.
Intent-подход:
«Хочу превратить 100 000 USDC в работающую позицию в целевом vault на Arbitrum, не хуже заданной effective price, только через разрешённые venue, с дедлайном 3 минуты».
Для пользователя это одна задача. Для системы — потенциально много разных путей исполнения:
- через bridge + spot DEX + deposit;
- через solver, у которого уже есть инвентарь на нужной сети;
- через RFQ maker, который готов закрыть сделку целиком;
- через bundle из нескольких venue с внутренним netting.
Пользователь видит результат, а исполнители соревнуются за то, чтобы провести его дешевле, быстрее или надёжнее.
Почему это вообще нужно
1. Деньги в DeFi двигаются через слишком много шагов
Даже «простая» стратегия часто состоит из:
- обмена актива;
- перемещения между chain или rollup;
- входа в lending / vault / staking leg;
- последующего мониторинга и ребалансировки.
Когда всё это делает человек вручную, он платит не только комиссию, но и цену за:
- когнитивную перегрузку;
- операционные ошибки;
- плохой timing;
- неэффективный routing;
- неполный обзор ликвидности.
Intent-layer нужен, чтобы эту сложность взять на себя.
2. Ликвидность в реальности фрагментирована
Ликвидность сидит:
- на разных DEX;
- у RFQ maker’ов;
- у solver’ов с собственным inventory;
- в разных rollup;
- иногда вообще вне целевой chain до момента settlement.
Если пользователь сам ходит по рынку, он почти всегда видит только маленький кусок картины. Solver-сеть или routing layer может свести больше источников ликвидности в одно решение.
3. Появляется рынок исполнения
Это ключевой момент. Intent-система превращает execution в отдельный рынок:
- пользователь публикует задачу;
- solver’ы оценивают, как её закрыть;
- кто-то исполняет intent и получает fee / spread / solver reward.
То есть отдельную ценность начинает создавать не только протокол ликвидности, но и тот, кто умеет лучше всех её упаковать и провести сделку.
Кто участвует в intent-based системе
Чтобы не делать вид, что это абстрактная магия, полезно разложить архитектуру по ролям.
1. User / wallet
Пользователь подписывает intent-сообщение, а не обязательно сразу отправляет onchain-транзакцию со всеми шагами.
В intent обычно лежат:
- input asset и amount;
- target outcome;
- минимально приемлемый output;
- allowed venues / chains;
- deadline;
- nonce;
- policy flags.
2. Intent relay / order intake API
Это входной слой, который:
- принимает подписи;
- валидирует схему intent;
- проверяет дедлайны и nonce;
- рассылает intent solver’ам или maker’ам;
- логирует жизненный цикл исполнения.
Для MVP это может быть обычный backend API + message bus.
3. Solver network
Solver — это исполнитель, который решает, какой маршрут даёт лучший outcome.
У solver’а может быть доступ к:
- onchain DEX;
- offchain RFQ quoting;
- bridge inventory;
- собственному capital buffer;
- моделям оценки slippage и latency.
Хороший solver думает не только про цену. Он думает и про:
- gas cost;
- вероятность revert;
- bridge finality;
- inventory risk;
- time-to-completion;
- ожидаемый adverse selection.
4. RFQ makers / market makers
В некоторых системах intent вообще не обязан исполняться через публичный AMM-маршрут. Его может закрыть maker, который говорит:
- я даю такую-то котировку;
- держу цену N секунд;
- беру на себя часть execution risk;
- рассчитываю заработать на spread или внутреннем netting.
Это особенно полезно для больших ордеров, где публичный DEX даёт плохой slippage.
5. Settlement contract
Это onchain-компонент, который:
- проверяет право на исполнение;
- валидирует параметры intent;
- обеспечивает, что пользователь не получит хуже оговорённого результата;
- распределяет input/output assets;
- иногда забирает protocol fee.
На этом слое важно, чтобы система не требовала доверия к solver’у в стиле «честное слово, мы потом доведём активы». Settlement должен быть максимально проверяемым.
6. Policy / risk engine
Если intent-layer используется в treasury, managed vault или B2B-продукте, почти всегда нужен policy layer:
- разрешённые chain и venue;
- лимиты по активам;
- max slippage;
- max bridge exposure;
- запрет на low-liquidity route;
- ручное подтверждение выше определённого notional.
Без этого intent-продукт быстро превращается в красивый UX над плохо контролируемым execution risk.
Как именно двигаются деньги
Самый полезный способ объяснить intent-систему — показать, где реально происходят денежные потоки.
Базовый swap intent
- Пользователь подписывает intent: отдать 50 000 USDC, получить максимум ETH не хуже указанного минимума.
- Relay отправляет intent solver’ам.
- Solver находит лучший маршрут: например, часть через RFQ maker, часть через DEX.
- Solver вызывает settlement contract.
- Контракт забирает USDC пользователя по разрешению/permit.
- Контракт или solver доставляет ETH пользователю.
- Разница между gross execution value и user minimum outcome превращается в:
- solver edge;
- protocol fee;
- иногда rebate пользователю, если так устроен аукцион.
Cross-chain intent
Тут интереснее:
- Пользователь хочет результат на другой сети.
- Solver либо использует bridge, либо закрывает задачу за счёт своего inventory на целевой chain.
- Если у solver’а есть локальный inventory, он может отдать пользователю актив сразу, а потом уже отдельно ребалансировать свой баланс между сетями.
- Получается, что пользователь покупает не только swap, но и удобство мгновенного исполнения, а solver берёт на себя inventory / bridge / latency risk.
Это и есть важный economic shift: часть риска и сложности переносится с пользователя на исполнителя.
Где возникает yield, fee flow и risk transfer
Intent-layer сам по себе обычно не «печатает yield», как lending или staking. Его экономика чаще строится иначе.
Fee flow
Деньги приходят из:
- protocol fee за execution;
- solver spread;
- RFQ spread;
- subscription / B2B fee за premium routing или policy controls;
- ancillary services вроде analytics и monitoring.
Risk transfer
Risk transfer здесь более интересен, чем доходность:
- пользователь передаёт исполнителю часть routing complexity;
- solver принимает на себя риск инвентаря, проскальзывания и задержек;
- market maker принимает риск котировки;
- bridge/provider принимает settlement/finality risk.
То есть intent-layer — это рынок управления исполнением и упаковки риска, а не просто модный интерфейс.
Реальные сценарии применения
1. Smart order routing для больших трейдов
Самый очевидный use case:
- у пользователя крупный swap;
- публичный DEX даёт плохой execution;
- solver сравнивает AMM, RFQ и internal inventory;
- пользователь получает лучший net outcome.
Здесь intent-подход хорош тем, что можно сравнивать не только spot price, но и вероятность успешного выполнения.
2. Cross-chain treasury execution
Для treasury intent-модель особенно полезна.
Примеры задач:
- перевести резерв в другую сеть;
- купить нужный актив и разложить по нескольким venue;
- зайти в yield strategy только если итоговая effective yield выше порога;
- вывести позицию из risky venue и доставить средства в safe bucket.
Вручную такие операции шумные и error-prone. Intent-policy layer делает их более управляемыми.
3. Vault deposit as a single outcome
Пользователю не нужен маршрут. Ему нужен результат: «оказаться в vault».
Intent тут может звучать так:
- принять на вход USDC, ETH или cbBTC;
- провести нужные swap / wrap / bridge шаги;
- внести итоговый актив в vault;
- выдать receipt пользователю.
Это очень сильный продуктовый паттерн для DeFi-протоколов: продавать не транзакции, а готовое состояние портфеля.
4. Liquidation-safe rebalancing и defensive automation
Intent может инициироваться не только человеком, но и automation layer.
Например:
- health factor падает ниже порога;
- система публикует intent на частичное погашение долга и своп collateral;
- solver ищет лучший путь без ручного вмешательства оператора.
Для managed accounts и treasury automation это уже не просто UX-фича, а операционная необходимость.
Основные компоненты архитектуры
Если собирать такой продукт как инженерный MVP, я бы разложил его на следующие части.
1. Intent schema и signing layer
Нужно чётко описать:
- типы intent;
- поля ограничений;
- формат подписи;
- anti-replay механику;
- срок действия.
Для EVM-проекта логично использовать typed structured signing в духе EIP-712-подобного формата.
2. Intake API и state machine
На backend нужен слой, который хранит статусы:
- received;
- validated;
- quoted;
- executing;
- settled;
- failed;
- expired.
Без нормальной state machine невозможно потом строить аналитику, алерты и операторский UI.
3. Quoter / routing engine
Это мозг системы. Даже если на старте он очень простой, он должен уметь:
- получить котировки из 2–5 источников;
- посчитать net output после gas/fee;
- оценить latency penalty;
- отфильтровать запрещённые route;
- выбрать лучший candidate route.
Для MVP не нужно сразу строить глобальный solver auction. Достаточно deterministic routing engine + опционально один RFQ provider.
4. Settlement contracts
Минимальный набор:
- intent verification;
- nonce management;
- permit/allowance handling;
- min output checks;
- fee accounting;
- event emission.
Важный момент: контракты должны быть скучными. Чем меньше там «умной магии», тем лучше.
5. Market data и observability
Нужен индексер или polling layer, который собирает:
- котировки по venue;
- gas snapshots;
- bridge ETA;
- success/fail rates;
- execution slippage;
- solver win rate;
- user outcome vs benchmark.
Без этого intent-продукт слепой: кажется, что всё работает, пока не выясняется, что half of routes съедают edge на gas и latency.
6. Policy engine
Это особенно важно для B2B и treasury-сценариев. Политики должны задаваться не в коде фронтенда, а в отдельном конфигурируемом слое:
- allowed assets;
- allowed venue;
- max notional;
- route blacklist;
- bridge cooldowns;
- min liquidity score;
- escalation rules.
Риски и trade-offs
Intent-система выглядит красиво на схемах, но реальная поверхность риска у неё широкая.
1. Solver centralization
Если фактически все intents закрывает один игрок, у вас не рынок исполнения, а новый chokepoint.
Риски:
- ценовая власть;
- селективное исполнение;
- зависимость от одного участника;
- деградация качества при всплеске volatility.
2. Quote manipulation и скрытый spread
Пользователь может видеть красивую «оптимизацию», но не понимать, сколько solver на самом деле забирает себе.
Поэтому нужны:
- benchmark-метрики;
- post-trade analytics;
- понятный fee breakdown;
- сравнение quoted vs achieved outcome.
3. Bridge и cross-chain risk
Как только intent пересекает сети, появляются:
- bridge security risk;
- finality delays;
- liquidity exhaustion;
- inventory mismatch.
Система обязана явно показывать, когда результат достигается за счёт bridge, а когда — за счёт local inventory solver’а.
4. MEV и adversarial execution
Intent-система не устраняет MEV автоматически. Иногда она его даже перераспределяет:
- часть value достаётся solver’у;
- часть могут пытаться перехватить searcher’ы;
- публичное раскрытие intent может ухудшать execution.
Поэтому на практике важны:
- приватная доставка котировок;
- короткие дедлайны;
- правильный settlement design;
- защита от replay и partial fill abuse.
5. Слишком сложная продуктовая магия
Если система обещает «лучшую цену всегда и везде», это почти наверняка маркетинговая фантазия. Хороший intent-продукт должен честно говорить:
- что именно он оптимизирует;
- на каких venue он работает;
- какие риски остаются у пользователя;
- когда automation останавливается и зовёт человека.
Как сделать похожий MVP
Вот здесь уже начинается самое полезное для builder’а.
MVP-цель
Не пытаться сделать universal solver network. Намного практичнее собрать vertical slice:
- один класс intents;
- одна-две сети;
- 2–4 источника ликвидности;
- простой policy engine;
- нормальная observability.
Например:
MVP: сервис, который принимает intent на конвертацию USDC в позицию конкретного vault на Base или Arbitrum и выбирает лучший маршрут из 2 DEX + 1 RFQ maker.
Компоненты MVP
1. Контракты
Нужны:
IntentSettlement.sol;NonceManager.solили встроенный nonce registry;- модуль fee accounting;
- event’ы для lifecycle tracking.
2. Backend / solver service
Стек может быть очень приземлённым:
- Go или TypeScript/NestJS для API и routing engine;
- PostgreSQL для хранения intents, quotes, fills и audit trail;
- Redis для короткоживущих quote cache и job locks;
- отдельный worker для execution.
3. Quoters
Подключить:
- onchain quote adapters для Uniswap / 1inch-like venue / Aerodrome и т.п.;
- один RFQ adapter;
- gas estimator;
- bridge ETA adapter, если нужен cross-chain режим.
4. Indexer и analytics
Минимум:
- ingestion событий settlement contract;
- quote snapshots;
- execution latency;
- effective output vs benchmark route;
- error taxonomy.
5. UI / dashboard
Во фронте нужны не только кнопки, но и объяснимость:
- что хотел пользователь;
- какой маршрут выбран;
- сколько занял execution;
- какой fee breakdown;
- какой venue использовался;
- где сработали risk checks.
Что можно автоматизировать поверх
Вот здесь intent-layer становится особенно интересным для Sassoft-угла, потому что поверх него естественно строится automation-heavy control plane.
1. Monitoring и alerts
Нужны алерты на:
- рост fail rate;
- ухудшение median execution quality;
- bridge delays;
- отклонение solver outcome от benchmark;
- route concentration в одном venue;
- увеличение expired intents.
2. Rebalance и treasury actions
Если продукт обслуживает treasury или managed vault, automation может сама публиковать intents:
- перевести активы в другой chain;
- сократить exposure;
- разложить капитал по нескольким execution bucket;
- закрыть route при ухудшении ликвидности.
3. Keeper logic
Нужны фоновые задачи, которые:
- снимают протухшие intents;
- повторно котируют pending intents;
- переводят крупные failed cases в ручной review;
- обновляют venue score и route priority.
4. Anomaly detection
Даже простой detection layer уже даёт много пользы:
- solver suddenly wins too often against weak competition;
- один venue даёт систематически хуже post-trade price;
- bridge ETA резко вырос;
- effective slippage отклоняется от исторического baseline.
Не нужен «AI ради AI». Достаточно здравой статистики и честного операторского интерфейса.
5. Policy-as-code для execution
Отдельно сильная идея — хранить policy не как россыпь if в коде, а как конфигурируемый execution policy layer:
- какие активы разрешены;
- какие bridge допустимы;
- какой max slippage для разных notional;
- в какие часы можно делать крупные rebalances;
- какие intents требуют human approval.
Это уже очень близко к нормальному DeFi control plane, а не просто к красивому swap UI.
Где это особенно полезно на практике
Если смотреть прагматично, наибольшая ценность у intent-based систем сегодня обычно в четырёх местах:
- large-order execution с доступом к разным источникам ликвидности;
- cross-chain treasury operations;
- single-click vault onboarding;
- defensive automation вокруг lending, collateral и rebalances.
То есть выигрывает не абстрактная «децентрализация маршрута», а способность упаковать сложный набор шагов в понятный и управляемый outcome.
Что важно не перепутать
Есть популярная ошибка: думать, что intent-layer автоматически делает DeFi проще и безопаснее. На деле он:
- убирает часть ручной боли;
- улучшает routing;
- может снизить операционную нагрузку;
- но при этом создаёт новый рынок посредников и новый класс execution risk.
Поэтому сильный intent-продукт — это не тот, который громче всех обещает «best execution», а тот, который:
- честно ограничивает поле маршрутов;
- прозрачно показывает economics;
- строит нормальный monitoring layer;
- умеет вовремя сказать: здесь automation больше не должна действовать вслепую.
Итог
Intent-based execution layers — один из самых практичных паттернов в современной DeFi-инфраструктуре. Они полезны не потому, что звучат модно, а потому что переносят фокус с ручного набора транзакций на результат, policy и orchestration. Деньги при этом всё равно двигаются через знакомые примитивы — DEX, bridge, vault, lending, market makers, — но поверх них появляется слой, который умеет собирать это в нормальный продукт.
Для builder’а это отличный угол: не нужно строить новый базовый протокол, чтобы сделать ценный MVP. Можно взять узкий use case, собрать signing layer, routing engine, settlement contract, policy checks, индексер, dashboard и automation jobs — и уже получить систему, которая реально решает проблему fragmented execution.
А для технической или инвесторской аудитории главный вывод простой: если DeFi всё больше похож на набор composable execution blocks, то intent-layer становится тем местом, где решается не только куда положить деньги, но и кто, как и на каких условиях должен провести их по маршруту.