Когда люди впервые слышат слово intent в DeFi, оно звучит слишком абстрактно. Кажется, будто это просто модный ребрендинг swap router’а.
На практике идея довольно приземлённая: пользователь или приложение формулирует что именно хочет получить, а не расписывает вручную каждый шаг исполнения.
Не «свапни USDC в ETH через конкретный пул и именно так проведи транзакцию», а скорее:
- я хочу обменять 10 000 USDC на ETH;
- меня устраивает исполнение не хуже заданной цены;
- средства должны прийти на этот адрес;
- сделка должна пройти в течение ограниченного времени;
- не используй маршруты, которые нарушают мои policy.
Дальше появляется отдельный слой исполнителей — solvers. Они соревнуются или по крайней мере выбирают, как лучше исполнить intent: через какой маршрут, в какой последовательности, с каким набором on-chain действий и где именно зафиксировать результат.
Именно поэтому intents важны не только для трейдинга. Это уже почти универсальная модель для wallet automation, treasury operations, DeFi execution и policy-driven money workflows.
Последние обсуждения на Hacker News снова крутились вокруг одной знакомой инженерной мысли: чем сложнее система автоматизации, тем важнее отделять декларацию цели от механики исполнения. В DeFi intents — как раз такой переход. Пользователь описывает цель, а execution layer решает, как безопасно и выгодно довести её до результата.
Ниже — разбор простыми словами: что такое intent, кто такие solvers, чем это отличается от обычного swap, где здесь риски и какой automation layer имеет смысл строить бизнесу или продуктовой команде.
Что такое intent простыми словами
Intent — это декларация желаемого результата.
Не пошаговый скрипт, а описание конечного состояния или допустимого диапазона результата.
Для DeFi это может выглядеть так:
- обменять один актив на другой не хуже минимального курса;
- перевести капитал из одной сети или протокола в другой;
- привести портфель обратно к целевой структуре;
- закрыть рискованную позицию, если метрика дошла до лимита;
- занять актив под залог, но только если ставка и LTV укладываются в policy.
То есть intent — это не обязательно про UI-кнопку Swap. Это более общая модель:
goal -> constraints -> eligible executors -> settlement
Пользователь или система задаёт цель и ограничения, а дальше кто-то должен найти способ исполнения.
Чем intent отличается от обычного swap router
В классическом DeFi-роутинге приложение часто само говорит контракту, что делать:
- взять токен A;
- пройти через пул 1;
- потом через пул 2;
- затем отправить результат пользователю.
Это работает, пока задача относительно простая.
Но чем сложнее становится среда, тем больше появляется нюансов:
- ликвидность размазана по разным DEX и сетям;
- часть исполнения может быть выгоднее сделать off-chain search’ом;
- пользователь хочет защиту от MEV и плохого маршрута;
- операции становятся многосоставными: swap + bridge + deposit + hedge;
- продукту нужны business rules, а не только best execution.
В intent-модели пользователь не диктует низкоуровневый маршрут. Он описывает рамки задачи, а solver уже ищет лучший путь.
Это очень похоже на разницу между:
- ручным управлением каждым вызовом API;
- и job-системой, где ты описываешь желаемый outcome, SLA и policy.
Кто участвует в intent-based исполнении
Упрощённо тут есть пять ролей.
1. Автор intent
Это тот, кто формулирует задачу:
- пользователь в кошельке;
- backend продукта;
- treasury bot;
- risk engine;
- rebalancer;
- AI-агент под жёсткими policy.
Важно, что intent может создаваться не только человеком, но и автоматикой.
2. Intent relay или order flow layer
Где-то intent нужно опубликовать или доставить до исполнителей. Это может быть:
- приватный relay;
- off-chain API;
- order flow network;
- собственный coordination service продукта.
Этот слой не обязательно исполняет сделку сам. Часто он просто раздаёт задачу тем, кто умеет её решить.
3. Solvers
Это исполнители, которые ищут способ удовлетворить intent.
Они могут:
- подобрать маршрут по нескольким DEX;
- заиспользовать собственный inventory;
- собрать батч из нескольких встречных намерений;
- включить bridge, swap, repay, borrow и deposit в одну цепочку;
- взять на себя часть рыночного риска до final settlement.
Если говорить совсем просто, solver — это оператор best execution для декларативной DeFi-задачи.
4. Verification / policy layer
Кто-то должен проверить, что предложенное исполнение действительно допустимо:
- не хуже минимальной цены;
- не нарушает лимиты;
- не использует запрещённые venue;
- укладывается по дедлайну;
- не превышает gas/risk budget.
Без этого intent быстро превращается в красивое название для передачи контроля неизвестно кому.
5. Settlement layer
В конце должен произойти факт расчёта:
- on-chain вызов контракта;
- набор транзакций;
- атомарная или квази-атомарная последовательность действий;
- финальная доставка результата на нужный адрес или счёт.
Именно здесь intent перестаёт быть обещанием и становится реальной денежной операцией.
Как это выглядит на примере swap
Возьмём простой пример.
Пользователь хочет обменять 50 000 USDC на ETH.
В обычной модели wallet или dApp могут сразу построить маршрут и послать транзакцию в конкретный router.
В intent-модели происходит другое.
Шаг 1. Формулируется намерение
Например:
- input: 50 000 USDC;
- output: ETH;
- минимальный acceptable output: 24.8 ETH;
- дедлайн: 90 секунд;
- settlement address: конкретный кошелёк;
- дополнительные ограничения: не использовать определённые пулы, не превышать gas budget, не маршрутизировать через сомнительные токены.
Шаг 2. Intent уходит в сеть исполнителей
Его получает relay или marketplace, где solvers могут предложить исполнение.
Шаг 3. Solvers считают варианты
Один solver может предложить:
- маршрут через несколько DEX;
- частичное исполнение через свой inventory;
- защиту от публичного mempool;
- лучший net output за счёт более умной сборки сделки.
Другой solver может посчитать, что сейчас рынок слишком тонкий, и вообще не участвовать.
Шаг 4. Выбирается лучшее допустимое исполнение
Побеждает не обязательно тот, кто обещает самый красивый gross price. Смотрят на итог после комиссий, вероятность исполнения, latency, риски и policy.
Шаг 5. Происходит settlement
Средства списываются, маршрут исполняется, пользователь получает ETH, а solver — свою экономику или fee.
Для пользователя это выглядит как один swap. Но под капотом это уже задача на поиск и исполнение, а не просто вызов одного AMM-контракта.
Почему intents стали важны именно сейчас
Потому что DeFi давно перестал быть миром из пары пулов и одного маршрутизатора.
Сегодня реальная execution-среда включает:
- десятки venue;
- fragmented liquidity;
- кроссчейн-переходы;
- приватные и публичные каналы доставки транзакций;
- защиту от MEV;
- policy и compliance-ограничения на уровне продукта;
- автоматические действия со стороны treasury, risk engine и wallet automation.
Чем больше таких факторов, тем менее удобно держать всю логику в UI или в одном on-chain router.
Intent-модель позволяет разделить систему на два слоя:
- что мы хотим получить;
- как именно этого добиться.
Для инженерных команд это почти всегда более здоровая архитектура.
Где тут реальный риск
У intent-based DeFi нет магии. Просто часть сложности уходит из пользовательского интерфейса в execution layer.
А значит, риски тоже никуда не исчезают.
1. Риск плохого или оппортунистического исполнения
Если solver формально удовлетворил минимум, но выбрал для себя заведомо выгодную схему с худшим результатом для пользователя, продукт может не заметить проблему сразу.
Поэтому важно контролировать:
- minimum acceptable output;
- reference pricing;
- max slippage;
- whitelist/blacklist venue;
- post-trade analytics по реальному качеству исполнения.
2. Риск непрозрачной логики маршрута
Чем больше off-chain магии, тем труднее команде понять, почему сделка прошла именно так.
Если нельзя объяснить маршрут, нельзя и нормально расследовать инцидент.
3. Риск зависания между intent и settlement
Intent может быть создан, но не исполнен:
- нет solver’ов;
- цена ушла;
- bridge задержался;
- gas слишком вырос;
- policy не пропустила финальный submit.
Значит, нужен хороший статусный автомат, а не бинарное мышление вида pending/completed.
4. Риск split responsibility
Когда relay, solver, wallet, product backend и on-chain settlement разделены между разными системами, легко потерять владельца инцидента.
В деньгах это очень плохая идея.
5. Риск слишком широкой автоматизации
Если intent может породить слишком много свободы исполнения, вы фактически выдаёте автоматике право принимать финансовые решения шире, чем планировали.
Поэтому intents без policy engine — слабая конструкция.
Где automation layer особенно полезен
Именно здесь intent-модель становится коммерчески интересной не как «фича протокола», а как инженерный слой вокруг денег.
1. Treasury rebalance
Компания держит ликвидность в нескольких сетях, на нескольких кошельках и в нескольких протоколах.
Проблема: нужно регулярно перемещать капитал туда, где он нужен продукту, не заставляя оператора вручную собирать маршрут.
Решение:
- формировать intents вида доведи баланс этого hot wallet до X,
- перенеси ликвидность из сети A в сеть B,
- обнови hedge до целевой пропорции.
Automation layer здесь даёт:
- policy-driven generation intent’ов;
- выбор допустимых solvers/venues;
- execution approval rules;
- reconciliation после settlement.
2. Wallet automation для продукта
У кошелька или embedded finance-продукта возникает задача: исполнять пользовательские операции лучше, чем «один публичный swap по рынку».
Здесь intent layer позволяет:
- описывать пользовательскую цель;
- прятать низкоуровневую механику;
- проверять policy на backend;
- подключать разные execution-источники без ломки UI.
3. Risk controls для lending и leveraged стратегий
Если health factor, oracle deviation или utilisation вышли за пределы, система может автоматически сгенерировать intent:
- частично погасить долг;
- довнести collateral;
- закрыть часть позиции;
- перевести ликвидность в safer venue.
То есть intent становится не интерфейсной, а операционной единицей реакции на риск.
4. Cross-chain user flows
Самые болезненные пользовательские сценарии обычно выглядят так:
- мост,
- потом swap,
- потом deposit,
- потом ещё approval,
- потом пользователь не понимает, на каком шаге всё зависло.
Intent-модель позволяет описать весь desired outcome целиком и завернуть его в единый orchestration pipeline.
Какую архитектуру имеет смысл строить бизнесу или тех-команде
Если смотреть практично, полезен не просто «доступ к intents», а контролируемый automation layer поверх intent execution.
Ниже — рабочий каркас.
1. Intent builder
Компонент, который создаёт стандартизированное намерение из:
- действий пользователя;
- treasury rules;
- risk triggers;
- внутренних задач ребалансировки.
Он же нормализует поля: input/output asset, size, deadline, slippage, approved venues, signer scope.
2. Policy engine
До отправки intent наружу нужно проверить:
- кто имеет право создать такой intent;
- какие суммы допустимы;
- какие сети и протоколы разрешены;
- нужен ли human approval;
- допустимо ли auto-submit без оператора.
Это особенно важно для B2B, custodial flows и AI-агентов.
3. Solver gateway
Вместо жёсткой привязки к одному исполнителю лучше иметь gateway-слой, который:
- рассылает intents в допустимые execution sources;
- собирает quotes или execution plans;
- применяет ranking;
- пишет audit trail.
Так продукт не запирается в одном solver-провайдере.
4. Execution state machine
Не храните такое как просто «транзакция в процессе».
Нужны явные состояния:
- intent_created;
- quoted;
- approved;
- submitted;
- partially_executed;
- settled;
- expired;
- failed;
- requires_operator_review.
Именно это делает операционную систему управляемой.
5. Monitoring и reconciliation
После исполнения нужно понимать:
- совпал ли фактический output с ожидаемым;
- где был slippage;
- был ли route drift;
- нет ли застрявших cross-chain legs;
- дошёл ли актив до нужного адреса;
- соответствует ли финальный баланс внутреннему учёту.
Без reconciliation intent layer становится источником скрытых денежных расхождений.
Практический блок: что можно внедрить как service / implementation layer
Если смотреть глазами бизнеса или продуктовой команды, картина обычно такая.
1. Какая проблема возникает
Команда хочет автоматизировать swaps, rebalances, cross-chain transfers или риск-реакции, но сталкивается с тем, что:
- ликвидность и маршруты постоянно меняются;
- ручная логика в backend быстро разрастается;
- нужно соблюдать внутренние policy;
- инциденты сложно расследовать;
- нельзя просто отдать всё внешнему исполнителю без контроля.
2. Какой архитектурный паттерн имеет смысл
Практичный паттерн — это intent control plane:
- единый формат intent’ов;
- policy engine перед execution;
- мульти-solver gateway;
- state machine по всем жизненным циклам;
- monitoring, audit trail и reconciliation;
- exception inbox для спорных или застрявших операций.
Это уже не «бот для свапа», а нормальная execution-платформа.
3. Что именно можно давать как сервис
Как service или внутренний tooling layer здесь можно предоставлять:
- intent API для wallet/app/treasury систем;
- policy-as-code для допустимых действий;
- solver routing и quote ranking;
- safe execution orchestration;
- post-trade analytics;
- incident review console;
- reconciliation и alerting для money flows.
Именно это делает DeFi automation коммерчески полезной: не красивый термин intent, а управляемое исполнение денежных задач с понятным контролем риска.
Где граница между хорошей абстракцией и опасной магией
Хороший intent layer делает систему проще для пользователя, но не скрывает правду от оператора и инженера.
Признаки здоровой реализации:
- можно объяснить, кто и как исполнил задачу;
- есть ограничение свободы solver’ов через policy;
- все шаги видны в audit trail;
- сбои не маскируются под «всё ещё pending»;
- есть fallback и operator review;
- фактический результат сравнивается с ожидаемым.
Плохая реализация выглядит наоборот:
- много маркетинговых слов про UX;
- мало прозрачности, кто контролирует execution;
- нет чёткой модели отказа;
- нет reconciliation;
- слишком много доверия к внешнему исполнителю;
- слишком широкие права у автоматики.
Для денег такая архитектура обычно заканчивается не катастрофой сразу, а медленным накоплением тихих ошибок. А это хуже, потому что замечают их поздно.
Итог
DeFi intents — это не модный синоним swap. Это переход от модели «пользователь вручную задаёт маршрут» к модели «система принимает цель, ограничения и подбирает исполнение».
За этим почти неизбежно следуют:
- solvers;
- policy engine;
- execution state machine;
- monitoring;
- reconciliation;
- operator tooling.
Именно поэтому intents интересны не только протоколам, но и бизнесам, которые хотят строить безопасный automation layer вокруг DeFi-операций.
Если сказать совсем просто, intent отвечает на вопрос «чего мы хотим достичь», а automation layer — на вопрос «как довести это до расчёта без тихого риска и операционного хаоса».
И в реальных системах второе почти важнее первого.