Intent-протокол предлагает пользователю описать желаемый результат, а поиск маршрута и исполнение оставить solver. Например, запрос может означать: отдать определённый токен в одной сети и получить не меньше заданной суммы другого токена на нужный адрес. Это упрощает операцию, но не отменяет проверку того, что именно подписывает кошелёк.
Solver конкурирует за право исполнить заявку и может использовать DEX, собственную ликвидность, мосты или несколько транзакций. Пользователь обычно не обязан доверять каждому промежуточному шагу, если settlement-контракт выдаёт входной актив только после выполнения условий. Безопасность зависит от самих условий intent, разрешений токена и кода расчёта.
Сначала сформулируйте проверяемый результат
До подключения кошелька запишите пять параметров: какой актив вы отдаёте, в какой сети, какой актив хотите получить, минимально допустимое количество и адрес получателя. Для межсетевой операции добавьте целевую сеть и срок исполнения. Эти сведения важнее красивого маршрута, показанного интерфейсом.
Intent должен ограничивать результат, а не просто давать solver право действовать от имени пользователя. Если заявка содержит только входную сумму без minimum output, неблагоприятное исполнение может формально соответствовать подписи. Для обмена проверяйте минимальный выход, для перевода – точного recipient, для сложного действия – конечный контракт и ожидаемый вызов.
Общая архитектура таких систем разобрана в статье об intents и solvers. Практическая разница в том, что пользователь проверяет обещанный итог и правила settlement, а solver берёт на себя поиск способа его получить.
Проверьте подпись и транзакцию открытия
Intent может открываться onchain-транзакцией или подписью структурированных данных. В обоих случаях сверяйте chain ID, verifying contract, nonce, deadline и адрес получателя. Подпись для одного домена не должна незаметно разрешать действие в другом контракте или сети.
Если кошелёк показывает EIP-712, прочитайте все поля, а не только название приложения. Непонятный Permit, Permit2 или approve способен дать spender право забрать токен позже. Ограничивайте сумму планируемой операцией и сроком, если формат это поддерживает. После исполнения удалите ненужное постоянное разрешение.
При onchain-вызове поле To должно вести на официальный settler или входной контракт протокола. Метод может называться open, deposit, settle или иначе, поэтому название само по себе ничего не доказывает. Адрес нужно получить из актуальной документации и сопоставить с сетью. Принципы чтения полей подробно объясняет инструкция по расшифровке calldata.
Отдельно проверьте value. Для операции с ERC-20 обычно передаётся токен через allowance, а нативная монета может находиться в value. Неожиданная сумма нативного актива или разрешение постороннему spender является причиной остановиться.
Оцените minimum output и deadline
Minimum output определяет худший приемлемый результат. Слишком низкое значение даёт solver широкую свободу и может ухудшить цену. Слишком жёсткое значение повышает вероятность, что заявка не будет исполнена при обычном движении рынка. Выбирайте границу по текущей котировке, ликвидности и размеру операции, а не по универсальному проценту.
Deadline ограничивает время действия заявки. Длинный срок оставляет intent открытым при изменившемся рынке, а короткий может не учитывать финальность исходной сети. Просроченная заявка не должна исполняться, но средства могут потребовать отдельного возврата по правилам конкретного протокола. До подписи выясните, где хранятся активы и кто может инициировать refund.
В межсетевой операции различайте быстрый fill и окончательный settlement. Solver может заранее выдать ликвидность в целевой сети, а затем получить компенсацию после подтверждения исходного сообщения. Пользователь должен проверять получение целевого актива, тогда как риск settlement несёт исполнитель в рамках правил системы. Связь этих этапов помогает понять материал о сообщениях и token bridge.
Не доверяйте маршруту только из-за симуляции
Симуляция способна показать списание входного актива, вызванные контракты и предполагаемый результат. Она полезна для обнаружения неожиданного approve, другого recipient или лишнего перевода. Но она воспроизводит одно состояние сети и не гарантирует, что solver выберет тот же путь после подписи.
Для intent важнее проверить инварианты: settlement не должен принять исполнение ниже minimum output, после deadline или на неправильный адрес. Обычный preview маршрута может измениться, а ограничивающие поля должны остаться прежними. Подробнее границы метода разобраны в статье о проверке симуляции.
Если intent допускает произвольный вызов в целевой сети, изучите target, calldata и сумму. Получение токена с последующим депозитом в неизвестный vault не равно простому переводу. Разрешение solver выбрать произвольный target значительно расширяет поверхность риска.
Как проверить исполнение
Сохраните хеш открытия или идентификатор ордера. После fill найдите транзакцию в целевой сети и проверьте адрес токена, recipient и фактически полученную сумму. Уведомление сайта не заменяет запись блокчейна. Для нестандартного токена учитывайте изменение баланса, а не только событие Transfer.
Сопоставьте статус settlement с условиями заявки. Filled может означать выдачу результата пользователю, но компенсация solver ещё обрабатывается. Для вас критично, что целевой актив доступен и последующие действия выполнены. Если результат не получен, не подписывайте «повторное подтверждение» из сообщения поддержки.
- Домен и адрес settler получены из официальной документации.
- Входной и выходной активы сверены по адресам, а не тикерам.
- Chain ID, recipient, minimum output и deadline соответствуют плану.
- Approve или Permit ограничены ожидаемым spender и суммой.
- Процедура отмены или возврата понятна до открытия заявки.
- Фактический результат проверен в целевой сети.
Для первого использования выберите небольшую сумму и простой результат без дополнительного calldata. Межсетевой маршрут также стоит сопоставить с чек-листом безопасного перевода через мост. Intent сокращает число ручных шагов, но ответственность пользователя концентрируется в одной подписи. Чем точнее ограничены итог, срок и получатель, тем меньше возможностей остаётся для неблагоприятного исполнения.
