ERC-8211 спрямований на забезпечення динамічного виконання для AI-агентів у DeFi

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

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

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

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

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

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

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

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

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

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

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

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

Дефі саме по собі є наповненим невизначеністю. Реальний вихід при обміні залежить від прослизання та ліквідності в тому блоці; час надходження та кінцева сума при використанні мосту залежать від механізму та комісій самого мосту; співвідношення share-to-asset у протоколах позичання або Vault також постійно змінюється.

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

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

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

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

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

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

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

Звучить дійсно абстрактно, але це не складно зрозуміти; офіційно це описують одним реченням: From transactions to programs.

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

• Фетчері: визначають, звідки отримується цей параметр; вони можуть здійснювати запит до поточного балансу певної адреси, щоб параметр був не знімком на момент підпису, а реальним значенням, отриманим з ланцюга в момент виконання;
• Обмеження: після вилучення параметрів вони повинні пройти перевірку вбудованих обмежень — наприклад, «отримані USDC мають бути не менше 2500» або «коефіцієнт ковзання не повинен перевищувати 0,5%». Ці обмеження перевіряються до того, як значення будуть передані на наступний виклик; якщо хоча б одне з них не пройде, весь пакет негайно скасовується;
• Предикати (умови запуску): можна розуміти як воротарі між кроками, які не генерують значення, а лише визначають, чи продовжувати виконання. Наприклад, у сценарії міжланцюгової взаємодії, пакет з етіреумської сторони може чекати за допомогою предикату на умову «міжланцюговий WETH надійшов», і не підтверджувати його, доки кошти не надійдуть.

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

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

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

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

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

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

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

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

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

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

• AI-агент може відповідати за розуміння намірів користувача та генерацію шляхів;
• Гаманець відповідає за те, щоб показати цей шлях користувачеві для перевірки більш зрозумілим способом;
• А relayer відповідає лише за підтвердження за умови виконання, не маючи прав на зміну результатів;

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

Варто зазначити, що ERC-8211 повністю сумісний з такими фреймворками абстракції облікових записів, як ERC-4337, EIP-7702, ERC-7579; він не замінює абстракцію облікових записів, а додає додатковий рівень програмної семантики виконання для агентів.

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

Перегляньте еволюцію шаблонів взаємодії в ланцюжку Ethereum за останні 10 років:

• Етап 1: Один підпис = один виклик функції (епоха EOA)
• Другий етап: Один підпис = Набір статичних пакетних викликів (ERC-4337, EIP-5792)
• Третій етап: Один підпис = динамічно оцінювана програма намірів (епоха ERC-8211)

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

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