Чому новий парадигма взаємодії ERC-8211 заслуговує на увагу?

Автор: imToken

З 2025 року багато хто, можливо, поступово звикне до нового способу взаємодії: скажімо GPT або Gemini «Допоможи спланувати поїздку до Гонконгу наступного тижня та порекомендуй відповідні авіаквитки й готелі», — і він мовчки у фоновому режимі виконає пошук інформації, фільтрацію умов, вибір маршруту, порівняння цін тощо, і наприкінці просто передасть вам результат для підтвердження.

Однак, перенесення таких самих очікувань у блокчейн зовсім змінює картину.

Наприклад, ви даєте DeFi агенту команду: «Обміняй ETH у гаманці на USDC, перейдіть на базовий ланцюг, і повністю внесіть у Aave», — об’єктивно, з точки зору «розуміння потреб» і «планування маршруту», сучасний агент цілком може це зробити, але справжній розрив у можливостях виникає саме на етапі виконання:

Ви все ще ймовірно повинні послідовно підписувати, авторизовувати, обмінювати, здійснювати міжланцюгові перекази та депозити, і кожен крок піддається ризикам змін проскальзування, коливань Gas, затримок мостів і стану на ланцюгу, що означає: якщо будь-який із цих етапів відхилиться від очікуваного, попередні дії можливо не можна буде скасувати, а наступні — виконати, і в підсумку на ланцюгу залишиться лише незавершений напівготовий процес.

Проблема не в тому, що AI недостатньо розумний, а в тому, що рівень виконання на ланцюгу досі позбавлений справжнього способу вираження, який би підходив для Agent.

Саме тому, у квітні 2026 року, Biconomy у співпраці з Ethereum Foundation опублікували ERC-8211, який має вирішити проблему «статичних обмежень» у виконанні смарт-контрактів, і надати більш виразний рівень виконання для AI-агентів і складних DeFi робочих процесів, намагаючись заповнити цю прогалину.

I. Останній «розрив» у підключенні AI-агента до ланцюга

За останні один-два роки увага криптоіндустрії зосереджувалася не так на масштабуванні L2, RWA-ліквідності, а значно більше — на тому, як справді дозволити AI-агентам керувати ланцюговими операціями, що є досить революційною темою.

Об’єктивно, від «давання багатоступеневих DeFi стратегій у природній мові» до «автономний агент, який керує цим всім портфелем міжланцюгових інвестицій», ми вже бачили багато практичних реалізацій, і більшість з них на рівні демонстрацій вже зрілі: генерація багатоступеневих DeFi стратегій, автономне ребалансування, автоматичне перенесення доходів, міжланцюгове коригування позицій, і навіть більш складне управління портфелем.

З точки зору логіки і оркестрування, можливості AI вже досить швидко розвиваються, але коли його починаєш запускати у виробниче середовище, короткострокові обмеження стають все більш очевидними.

Якщо говорити про реальне виробництво, то ця проблема зводиться до однієї фрази: DeFi є динамічним, але більшість batch (пакетних) операцій досі статичні.

Офіційний сайт і дискусійні пости ERC-8211 чітко пояснюють цю проблему: існуючі стандарти ERC-4337 і EIP-5792 вже просунулися від старої моделі «один підпис — один виклик» до нової «один підпис — кілька пакованих викликів», але параметри цих викликів у більшості випадків залишаються зафіксованими на момент підпису.

Тобто, сума, цільове значення, очікуваний результат, які користувач вводить під час підпису, при виконанні не автоматично коригуються залежно від стану ланцюга.

Але DeFi саме по собі наповнене невизначеністю. Реальний результат Swap залежить від проскальзування і ліквідності у тому блоці, час зарахування і кінцева сума — від механізмів і комісій мосту, а співвідношення share-to-asset у протоколах позики або Vault постійно змінюється.

Зрештою, значення, яке бачить користувач або агент під час підпису, часто є лише приблизною оцінкою, а не реальним результатом виконання.

Щоб зрозуміти, що саме вирішує ERC-8211, розглянемо найтиповішій приклад: агент хоче зробити щось дуже просте — обміняти ETH у гаманці на USDC, а потім повністю внести їх у Spark для отримання відсотків.

За статичної моделі пакетної обробки агенту потрібно заздалегідь оцінити, скільки USDC він отримає після Swap, і часто доводиться зафіксувати цю суму ще до підпису, що може призвести до ситуації, коли реальна сума менша за очікувану, і весь пакет скасовується; або ж — якщо оцінка занизька — частина коштів залишається без дії.

Інакше кажучи, агент потрапляє у так званий «двохвірний» стан: або ризикує невдачею, або втрачає можливість. Саме тому, коли кілька кроків у ланцюгу розтягуються на 5, 8 або навіть перетинають кілька ланцюгів, вони стають дуже вразливими — не через складність стратегії, а через те, що існуюча модель виконання дуже залежна від заздалегідь зафіксованих параметрів.

Коротко кажучи, обмеження статичного batch визначає максимально можливу безпечну стратегію для агента.

З цієї точки зору, ERC-8211 прагне не до того, щоб агент приймав рішення, а до того, щоб після рішення існувала більш природна, стабільна і безпечна форма його виконання на ланцюгу. Це має надати перше вроджене вираження для виконання агентських стратегій.

II. Що саме змінює ERC-8211?

Головний прорив ERC-8211 полягає не у тому, щоб додати більше кроків у один підпис, а у тому, щоб перетворити пакетну обробку з фіксованої послідовності транзакцій у «програму, яка динамічно обчислює параметри під час виконання».

Звучить досить абстрактно, але зрозуміло: офіційно це описується фразою «Від транзакцій до програм».

Це означає, що ERC-8211 більше не розглядає batch як набір дій, що виконуються послідовно, а як програму, яка під час виконання динамічно обчислює параметри і має вбудовані умови безпеки. Для цього воно використовує три основні компоненти:

• Fetchers (зчитувачі): визначають, звідки брати значення параметра — наприклад, запит балансу на конкретній адресі у реальному часі, що дозволяє отримувати актуальні дані з стану ланцюга під час виконання, а не використовувати зафіксовану на підписі «знімок»;

• Constraints (обмежувачі): після отримання значення параметра, його перевіряють на відповідність умовам — наприклад, «отриманий USDC має бути не менше 2500», або «проскальзування не більше 0.5%» — і якщо умова не виконується, весь пакет скасовується;

• Predicates (умови-претенденти): виступають як «сторожові собаки» між кроками, визначаючи, чи можна продовжувати — наприклад, у міжланцюгових сценаріях, коли транзакція на Ethereum очікує підтвердження, що WETH вже зараховано, і не далі, поки ця умова не виконається.

У цій системі кожен параметр відповідає двом питанням: звідки він береться під час виконання і які умови мають бути виконані перед його використанням. В результаті, пакет стає не просто списком транзакцій, а програмою з внутрішніми перевірками безпеки.

Загалом, статичний batch — це список, де виконується A, потім B, потім C; а ERC-8211 — це програма з умовами: після виконання A, беремо його реальний результат для B; B має пройти обмеження, щоб перейти до C; і будь-який з кроків, що не виконується, призводить до скасування всього.

Можна уявити це як «інтелектуальний пакет», створений спеціально для AI-агентів і складних DeFi операцій, оскільки у традиційних ланцюгових операціях для реалізації складної стратегії потрібно багато окремих транзакцій: зняття коштів із позикових протоколів, обмін токенів, повторне внесення — і все це вимагає підпису і підтвердження кожного кроку, що є складним і для людини, і для AI-агента.

ERC-8211 дозволяє об’єднати кілька дій у один атомарний виклик, де кожен крок виконується динамічно, з урахуванням актуальних значень і умов.

Наприклад, агент може у одному підписі зробити: взяти кошти з Aave → обміняти їх на Uniswap → внести у Compound — і все це атомарно, без створення нових смарт-контрактів.

III. Чому це важливо для гаманців, особливо для «розумних гаманців»

ERC-8211 важливий не лише тому, що він підходить для агентів, а й тому, що він може кардинально змінити роль гаманця у взаємодії з ланцюгом.

Раніше гаманці були швидше схожі на безпечні підписувачі: вони зберігали приватні ключі, показували транзакції, підтверджували їх і відправляли. У епоху EOA ця роль була цілком достатньою, і у епоху account abstraction вона зберігає свою актуальність. Але якщо у майбутньому все більше операцій виконуватимуться агентами, роль гаманця стане ще більш центральною.

Чому? Тому що, коли користувач перестане керувати кожним окремим кроком у ланцюгу і почне делегувати цю функцію агенту, гаманець має бути здатним підтримувати цю більш складну взаємодію. Він повинен показувати не просто адресу контракту і calldata, а цілісну «програму — намір, логіку отримання значень, умови і кінцевий результат».

Отже, майбутній гаманець має розуміти не просто транзакції, а програми. ERC-8211 надає цьому механізму більш чітке і зрозуміле представлення, оскільки він явно закладає ці логіки у структуру коду: звідки брати параметри, які умови мають бути виконані, коли продовжувати, коли скасовувати — все це стає відкритим і можливою для інтерпретації, моделювання і демонстрації.

З точки зору гаманця, ця система спрямована до однієї мети: користувач більше не підписує довгі і важко зрозумілі низькорівневі виклики, а підписує результат, орієнтований на ціль, з чіткими межами і перевіркою умов:

• AI-агент може аналізувати намір користувача і генерувати маршрут;

• гаманець може показати цей маршрут у зрозумілій формі для підтвердження;

• relayer — лише виконає транзакцію, коли умови виконані, і не матиме права змінювати результат.

Це і є причина, чому безпосередня автономна реалізація (Agentic DeFi) вважається такою перспективною: агент може брати участь, але суверенітет, обмеження і остаточне розрахунки залишаються на ланцюгу. Саме тому ERC-8211 ідеально поєднується з концепцією «розумних гаманців», оскільки він закладає «безпечне вираження складних намірів» у стандарт протоколу.

Варто зазначити, що ERC-8211 сумісний із ERC-4337, EIP-7702, ERC-7579 — він не замінює account abstraction, а додає ще один рівень — програмне вираження для агентів.

Якщо ERC-4337 вирішує питання «хто може ініціювати транзакцію», а EIP-7702 — «як тимчасово надати EOA можливість працювати з контрактами», то ERC-8211 вирішує питання: коли агент починає діяти від мого імені, чи може він зробити цю всю ланцюгову логіку у один підпис?

Розглянемо еволюцію взаємодій у Ethereum за останні 10 років:

• Перша фаза: один підпис — один виклик функції (епоха EOA)

• Друга фаза: один підпис — набір статичних пакованих викликів (ERC-4337, EIP-5792)

• Третя фаза: один підпис — динамічно обчислювана програма намірів (ERC-8211)

Кожен перехід дозволяє користувачу (або агенту від його імені) виражати більш складні цілі з меншими зусиллями.

Хоча ERC-8211 ще перебуває на стадії проекту і потребує доопрацювання, його напрямок вже цілком зрозумілий: коли AI-агенти почнуть автоматично приймати рішення у ланцюгу, потрібен стандарт, що дозволить виразити ці рішення у природній і безпечній формі.