Намір (intent) — це заявка, у якій сказано, який результат ви хочете отримати, а не які транзакції треба надіслати. Ви її підписуєте, солвери конкурують за право доставити результат, а розрахунковий шар платить тому, хто це зробив. Маршрутизація, gas і очікування між мережами переходять від користувача до професійного контрагента, натомість з'являється інший набір питань: кому дозволено торгуватися, за якою міркою їх оцінюють, чим забезпечена їхня обіцянка і що станеться з вашими грішми, якщо заявку не візьме ніхто.
Декларативна заявка: що таке намір насправді
Звичайна транзакція імперативна. У ній названо контракт, функцію, аргументи та gas, і підпис дозволяє рівно один обчислювальний шлях на заданому стані. Усе вирішено до підпису, а все, чого не передбачили, — ваш клопіт.
Намір декларативний. Це підписаний набір обмежень, який описує прийнятний для вас результат і допускає будь-який шлях виконання, що ці обмеження задовольняє. Транзакція каже: «зроби A, потім B, заплати рівно C і отримай X»; намір каже: «мені потрібен X, і я готовий заплатити щонайбільше C». У такій оптиці транзакція — окремий випадок наміру, який допускає рівно один перехід стану.
Практичний наслідок такий: підписуючи й розсилаючи намір, ви даєте третій стороні дозвіл обрати обчислювальний шлях замість вас. Звідси береться зручність — і звідси ж береться кожен ризик, описаний далі.
За природою це не новина. Лімітні заявки, оплата комісії тим токеном, який у вас уже є, агрегатори, що обіцяють найкращий маршрут по кількох майданчиках, — усе це має форму наміру: користувач ставить умову, виконання добирає хтось інший. Новим є те, що з цього роблять загальну інфраструктуру і що одна заявка може охоплювати кілька мереж.
Чотири ролі в системі намірів
Якщо розписати як життєвий цикл, схема має чотири частини. Користувач висловлює намір застосунку; застосунок перетворює його на заявку конкретного протоколу; заявка потрапляє в потік заявок, де її бачать солвери; солвер оцінює її, виконує потрібні кроки, а розрахункова процедура платить солверу.
Цей словник варто вивчити, бо він уже записаний у стандарт. Заявка — це пропозиція оплати в обмін на виконання набору вимог. Солвер, якого називають також філером, — той, хто ці вимоги виконує. Оплата замикає коло: солвер спершу робить роботу і лише на розрахунку отримує гроші.
Ідеться про стандарт ERC-7683, міжмережеві наміри (Cross Chain Intents). Це ERC із гілки Standards Track, створений у квітні 2024 року, і на момент написання він досі має статус Draft, тобто чернетка. Його до того ж суттєво переробили: рання редакція стандартизувала кодування заявок, потік заявок у мережі, депонування та функцію виконання, а нинішній текст стандартизує лише інтерфейс, через який солвер читає заявку, залишаючи протоколам свободу у створенні заявок, авторизації, ціноутворенні та розрахунках. Він спирається на ERC-7930, формат сумісних адрес, який має статус Review.
Статус чернетки важить тут більше, ніж деінде, бо це не єдина пропозиція в цій темі: ERC-7521 описує загальні наміри для гаманців на смартконтрактах і теж лишається чернеткою. Не вважайте нічого з цього вирішеним. Поле статусу кожного ERC стоїть на початку його сторінки в репозиторії Ethereum ERCs, а жива дискусія — у гілці Ethereum Magicians, на яку він посилається, тож перевірте поточну стадію самі.
Чому гроші наперед вкладає солвер
Під міжмережевими намірами лежить незручний факт: дві мережі не розраховуються атомарно, хтось має рушити першим. У поширеній схемі кошти користувача блокуються в контракті вихідної мережі в момент створення заявки, щоб солвер мав певність, що гроші існують, перш ніж вкладати власний капітал з іншого боку.
Далі солвер видає результат із власних запасів: у нього є потрібний актив у мережі призначення, він надсилає його вам і лише згодом отримує відшкодування із заблокованих коштів через розрахункову процедуру. В одній робочій схемі виконання збирають у пакети й відшкодовують із періодичністю, що вимірюється годинами, а не секундами, — тому солверу потрібен обіговий капітал, а не лише швидкий бот.
Транзакції теж надсилає солвер, а отже, gas платить він. Саме так влаштовані сценарії з намірами, які рекламують як безкоштовні за gas: витрати не зникли, їх перенесли в ту ціну, яку солвер вам називає.
Розрив між витратою і оплатою — це якраз те місце, де живе ризик солвера. Розділ безпеки самого стандарту каже це прямо: солвер під ризиком від хвилини, коли він вклав капітал, видав дозволи чи надіслав транзакції, і доти, доки очікувана оплата не стане остаточною й доступною. Усе, що може піти не так у цьому вікні, — реорганізація мережі, доставка повідомлень, протокол, який змінює стан, — уже закладено в котирування, яке ви бачите.
Як конкуренція визначає вашу ціну
Оскільки користувач більше не задає маршрут, ціну має породжувати конкуренція. Схеми різняться тим, як саме: десь ідуть голландські аукціони, і планка, яку солвер має побити, рухається в часі; десь ціну беруть з оракула; десь комісію фіксують, і солвери змагаються лише у швидкості.
Пакетні аукціони — найвідвертіший варіант. Заявки збирають у короткому вікні, солвери подають цілі розв'язки, кожен розв'язок оцінюють приблизно за тим, скільки виграшу він дає користувачам пакета, і перемагає розв'язок із найвищою оцінкою. Переможцям платять за правилом другої ціни, тож винагорода прив'язана до відриву від наступної найкращої пропозиції, а не до того, що переможець сам собі нарахував.
Конкуренція допомагає лише за наявності мірки. Один оприлюднений звід правил вимагає, щоб ціни солвера були не гіршими за ті, які користувач отримав би на визначеному переліку базових джерел ліквідності, і вимагає єдиних розрахункових цін: дві заявки на одній парі та в одному напрямку мають отримати однакову ціну. Без чогось такого найкраще виконання означає те, що під ним розуміє переможець.
Це ж і чесна відповідь на питання, чому наміри можуть вигравати в ручної маршрутизації. Солвер може звести вашу заявку зі зустрічною заявкою іншого користувача, запакувати кілька виконань в одну транзакцію і обрати для відшкодування ту мережу, яка коштує йому найменше. Економія справжня, але до вас вона доходить рівно настільки, наскільки її видавлюють конкуренція і правило підрахунку.
Чим насправді забезпечена обіцянка солвера
Підписати намір означає дати комусь простір для маневру. Зловживання стримує не підпис, а шар підзвітності, збудований навколо множини солверів, — і він у кожній системі свій, що якраз і пропускає більшість пояснень.
Перший запобіжник — це допуск. В одному оприлюдненому зводі правил солвер має потрапити до білого списку, перш ніж узагалі зможе подати розрахунок; оператори тримають моніторинг, який перевіряє кожен розрахунок у мережі й позначає підозрілі; систематичні порушення карають аж до слешингу.
Другий запобіжник — перевірка з вікном оскарження. Замість доводити кожне виконання в мережі, одна розрахункова схема дозволяє учаснику подати пакет результатів разом із заставою, і пакет приймають, якщо ніхто не оскаржив його у визначений строк. Користувач отримує швидкість одразу, доказ приходить пізніше.
Третій запобіжник — сама межа довіри, і стандарт незвично прямо каже, де вона закінчується. ERC-7683 стандартизує те, як заявку описують солверам; він не стандартизує і не гарантує безпеку протоколу, який зрештою її розраховує. Від солверів очікують, що вони самі перевірять контракт, який перекладає їм заявки, і підтвердять припущення, які той перевірити не може. Користувачеві стандарт про розрахункову систему під низом не обіцяє нічого.
Концентрація, цензура і шлях, яким повертаються гроші
Структурний ризик моделі намірів у тому, що коло тих, хто бачить вашу заявку і може її виконати, звужується. Якщо доступ до потоку намірів дозвільний, а список складено недбало, потік заявок концентрується, і той, хто тримає його велику частку, дістає змогу стягувати ренту, а в межі — цензурувати.
Відкрите поширення це саме собою не лікує. Вузол, здатний вигідно виконати намір, не зацікавлений передавати його конкурентам, а цілком публічний пул намірів підставляє заявки під те саме вилучення, що й публічний мемпул. Тому багато систем зупиняються на дозвільних або гібридних схемах, і тому практичне питання полягає не в тому, чи це децентралізовано, а в тому, хто в списку і хто це вирішує.
Супутня ціна — непрозорість. У найгіршому варіанті ви щось підписали, воно зникло і повернулося транзакцією, з якої не видно, хто її склав і які варіанти відкинув. Якість виконання, яку не можна перевірити, — це якість виконання, прийнята на віру.
Далі йде найбуденніший збій, поширеніший за екзотичні: заявку не бере ніхто. Заявка має строк виконання. Якщо він минув без виконання і без часткового виконання, заявка спливає, а заблоковані кошти повертаються — зазвичай на адресу, вказану в заявці, і за замовчуванням у вихідній мережі. Причини нудні: завелика сума, рідкісна пара токенів або солвери, які ненадовго вимкнулися.
Тільки це повернення не миттєве. Гроші йдуть назад тією самою пакетною розрахунковою процедурою, яка платить солверам, тож звичайне виконання триває секунди, а спливання може розгортатися годинами. Коли ви добираєте розмір заявки або будуєте продукт поверх намірів, строк виконання і шлях повернення — ті два параметри, які варто прочитати раніше за комісію.
Підсумок
Наміри переносять роботу з виконання від користувача до того, хто торгується: ви підписуєте потрібний результат, солвери конкурують за право його доставити, вкладають наперед капітал і gas, а розрахунковий шар платить тому, хто впорався. Виграш в ефективності справжній, і розмін теж справжній, бо ви віддаєте третій стороні свободу вирішувати, як виконати вашу заявку, і захищає вас не підпис, а правила аукціону, мірка, за якою оцінюють ці пропозиції, умови допуску й моніторинг навколо множини солверів та строк, який повертає гроші, коли не відгукнувся ніхто. Стандарт міжмережевих заявок ERC-7683 досі лишається чернеткою і вже раз був перероблений, тож будь-який його опис, включно з цим, — це знімок на момент часу, і перш ніж на ньому будувати, перевірте поле статусу.
Схожі матеріали
Інші матеріали Bitbase на цю тему:
- Моделі мостів: блокування, спалення та нативна емісія
- Що таке Hyperlane? Міжланцюгова сумісність без дозволів
- Мости для стейблкоїнів: як переміщати долари між мережами
Застереження: Ця стаття є освітнім матеріалом Bitbase Academy і надається лише для інформації. Вона не є інвестиційною, торговою, податковою чи фінансовою порадою. Криптоактиви волатильні — оцінюйте ризики самостійно. Написано станом на серпень 2026 року; орієнтуйтеся на найновішу офіційну інформацію.
Джерела
[1] ERC-7683: Cross Chain Intents eips.ethereum.org
[2] ERC-7930: Interoperable Addresses eips.ethereum.org
[3] ERC-7521: General Intents for Smart Contract Wallets eips.ethereum.org
[4] Intent-Based Architecture and Their Risks paradigm.xyz
[5] What are Crosschain Intents? docs.across.to
[6] Intent Lifecycle in Across docs.across.to
[7] Refunds docs.across.to
[8] Solver competition rules docs.cow.fi
