Ang ERC-8211 ay naglalayong magbigay-daan sa dinamikong pagsasagawa para sa mga AI Agent sa DeFi

Simula noong 2025, maaaring maging karaniwan na para sa marami ang isang bagong paraan ng interaksyon: sabihin sa GPT o Gemini ang “Tulongan mo akong i-plano ang aking biyahe sa Hong Kong sa susunod na linggo, at i-rekomenda ang mga angkop na tiket at hotel,” at sasagawa nito nang tahimik ang isang serye ng mga hakbang tulad ng paghahanap ng impormasyon, pagpili ng mga kundisyon, pagpili ng ruta, at paghahambing ng presyo, at sasagot lamang nito sa iyo ng resulta para sa pagpapatunay.

Ngunit kapag isinama ang parehong pag-asa sa chain, iba ang kuwento.

Halimbawa, binigyan mo ng utos ang isang DeFi Agent: “Palitan ang ETH sa wallet mo para maging USDC, i-transfer sa Base chain, at i-deposit ang buong halaga sa Aave.” Sa pananaw ng obhetibo, mula sa pag-unawa sa pangangailangan at pagpaplano ng path, hindi naman siguradong hindi kayang gawin ng Agent ngayon; ang tunay na pagkakaiba ay nangyayari sa pagsasagawa:

Patuloy kang malamang na kailangan mong sagutin ang mga hakbang sa pag-sign, pag-awtorisa, pagpalit, pag-cross-chain, at pag-deposito, at ang bawat hakbang ay nakalantad sa mga panganib ng pagbabago sa slippage, pagkakaiba sa Gas, pagkaantala sa pag-ugnay, at pagbabago sa estado ng chain. Ito ay nangangahulugan na kung anumang bahagi ay hindi sumunod sa inaasahan, ang mga nakaraang aksyon ay hindi laging maaring i-revoke, habang ang mga susunod na aksyon ay maaaring hindi makakonekta, at ang huling natitira sa chain ay karaniwang isang hindi tapos na kalahating proseso.

Hindi problema na hindi sapat na matalino ang AI, kundi ang kakulangan ng isang tunay na angkop na paraan ng pagpapahayag para sa Agent sa chain execution layer hanggang ngayon.

Dahil dito, noong unang bahagi ng Abril 2026, ang Biconomy at ang Ethereum Foundation ay naglabas ng ERC-8211 upang lutasin ang "static limitations" sa kasalukuyang pagpapatupad ng mga smart contract, at magbigay ng mas makapangyarihang execution layer para sa AI agents at mga kumplikadong DeFi workflows, na nagtatangkang punan ang nawawalang piraso ng puzzle.

Sa nakalipas na isang hanggang dalawang taon, ang pagkakababala ng industriya ng cryptocurrency ay direktang naglipat mula sa L2 scaling at RWA liquidity patungo sa mas makabagong paksa kung paano ang AI Agent ay maaaring talagang kunin ang kontrol sa on-chain operations.

Sa isang obhetibong pananaw, mula sa "pagbibigay ng maraming hakbang na DeFi strategy gamit ang natural na wika" hanggang sa "pagpapahintulot sa autonomous agent na pamahalaan ang buong cross-chain investment portfolio", nakita rin natin ang maraming praktikal na aplikasyon sa nakaraang panahon, at ang karamihan sa mga ideya ay nasa antas ng demo na matatag, kabilang ang natural language generation ng maraming hakbang na DeFi strategy, autonomous execution ng rebalance, automatic yield migration, cross-chain position adjustment, at kahit pa ang mas kumplikadong portfolio management.

Mula sa pananaw ng pag-iisip at pagpaplano, napakabilis na kakayahan ng AI, ngunit habang isinasama ito sa tunay na production environment, ang mga kahinaan sa antas ng pagpapatupad ay lalong nagiging malinaw.

Kapag talagang ipapasa sa production environment, ang kahinaang ito ay maaaring maipaliwanag sa isang pangungusap: ang DeFi ay dinamiko, ngunit ang karamihan sa mga batch ngayon ay patuloy pa ring static.

Malinaw na ipinapaliwanag ng opisyal na website at discussion thread ng ERC-8211 na ang mga umiiral na ERC-4337 at EIP-5792 ay nagsagawa na ng paglipat mula sa lumang modelo ng “isang lagda, isang pagtawag” patungo sa bagong yugto ng “isang lagda, maraming pagtawag na maipapakete”, ngunit ang mga parametrong ito sa loob ng mga pagtawag ay pangunahing nananatiling freeze sa oras ng paglagda.

Ibig sabihin, ang halaga, target, at inaasahang output na nilagay ng user sa pag-sign ay hindi magkakaroon ng awtomatikong pag-aayos kapag tinutupad na dahil sa pagbabago ng estado sa chain.

Ang DeFi mismo ay puno ng kawalan ng katiyakan. Ang tunay na output ng isang Swap ay nakadepende sa slippage at liquidity sa loob ng bloke na ikinakasal; ang oras ng pagdating at kinalabasan na halaga ng isang Bridge ay nakadepende sa mekanismo at bayarin ng tulay mismo; ang ratio ng share-to-asset ng mga loan protocol o Vault ay patuloy ring nagbabago.

Sa katotohanan, ang halaga na nakikita ng user o Agent sa pag-sign ay madalas ay isang pansamantalang estima, hindi ang tunay na resulta sa oras ng pagpapatupad.

Upang maunawaan kung ano ang lutas ng ERC-8211, tingnan muna ang isang pinakakaraniwang halimbawa: ipagpalagay na nais ng Agent gawin ang isang simpleng gawain—palitan ang ETH sa account nito sa USDC, at ipapadala ang buong halaga sa Spark upang kumita ng interes.

Sa ilalim ng umiiral na static batch processing model, kailangan ng Agent na mag-estimate kung gaano karaming USDC ang makakatanggap pagkatapos ng Swap, na kadalasang nagpapakialam sa iyo na i-pre-set ang halaga ng input sa pangalawang hakbang bago mag-sign, at kung sobra ang estimate, hindi sapat ang totoong halagang matatanggap, at babalik ang buong batch; kung masyadong maliit ang estimate, mananatili ang ilang pera sa wallet nang walang ginagawa.

Sa ibang salita, nasa isang dilemma na kailangan mong piliin kung susubukan ang panganib ng pagkabigo o ang gastos ng pagkakaligtaan. Dito nagmumula ang dahilan kung bakit maraming on-chain process na tila hindi komplikado ay agad na naging mahina kapag tinatapos sa 5, 8, o higit pang mga hakbang, o kaya ay nagsasaklaw sa dalawang blockchain—hindi dahil ang estratehiya ay sobrang komplikado upang maipaliwanag, kundi dahil sa kasalukuyang pagpapatupad na sobrang nakadepende sa mga pre-set na parameter.

Sa madaling salita, ang limitasyon ng kapasidad ng static batch ang talagang nagtatakda sa pinakamataas na antas ng mga patakaran na maaaring ligtas na maisagawa ng Agent.

Sa pananaw na ito, ang ERC-8211 ay hindi tinutugunan kung paano gumagawa ng desisyon ang AI Agent, kundi kung mayroon bang mas natural, mas matatag, at mas ligtas na paraan sa blockchain upang maisagawa ito pagkatapos ng desisyon ng Agent. Upang maging una ang chain execution na may orihinal na anyo na disenyo para sa AI Agent.

Ang pangunahing pag-unlad ng ERC-8211 ay hindi nakabatay sa pagpapalalim ng higit pang mga hakbang sa isang pagsusulat, kundi sa pagpapabuti ng batch processing mula sa isang sequence ng transaksyon na may nakapirming mga parameter patungo sa isang “programa kung saan ang mga parameter ay dinamikong kinukwenta sa oras ng pagpapatupad.”

Totoo, medyo abstrak, ngunit hindi mahirap maintindihan; ginamit ng opisyal ang isang pangungusap upang ilarawan ito: From transactions to programs.

Ibig sabihin ng ERC-8211 na hindi na itinuturing ang batch bilang isang listahan ng mga aksyon na isasagawa nang sunod-sunod, kundi bilang isang programa na isasagawa sa runtime na may mga kondisyon sa kaligtasan; sa mas detalyadong paglilinaw, ito ay natutupad sa pamamagitan ng tatlong komposableng primitibo:

• Fetchers (Mga tagapagkuha): Tinitukoy kung saan kinukuha ang parameter na ito; maaari itong isang pagtanong sa kasalukuyang balanse ng isang address, na ginagawa ang parameter na hindi na isang snapshot sa panahon ng pag-sign, kundi isang real-time na pagbasa mula sa chain state sa oras ng pagpapatupad;
• Constraints: Pagkatapos malikha ang mga parameter, kailangan pa silang pasasabayan sa inline constraint check—halimbawa, “ang natanggap na USDC ay dapat ≥ 2500” o “hindi dapat lumampas sa 0.5% ang slippage,” at ang mga constraint na ito ay sinusuri bago ipapadala ang halaga sa susunod na pagtawag; anumang pagkabigo sa anumang isa ay agad magdudulot ng rollback sa buong batch;
• Mga predicate (mga kondisyon para sa pag-trigger): Maaaring maunawaan bilang mga tagapagpangalaga sa pagitan ng mga hakbang, hindi responsable sa pagbuo ng halaga, kundi responsable sa pagpapasya kung magpapatuloy o hindi, halimbawa sa isang cross-chain na sitwasyon, ang batch sa galing sa Ethereum ay maaaring maghintay sa kondisyon na “natanggap na ang WETH mula sa cross-chain” bago magsumite;

Sa这套设计中， bawat parameter ay dapat sagutin ang dalawang tanong: Una, kung saan dapat galing ang value nang isasagawa; Pangalawa, anong mga kondisyon ang dapat matupad bago ito gamitin sa tawag, upang ang kombinasyon ng tatlo ay hindi na lamang isang serye ng transaksyon, kundi isang programa na may nakapaloob na pagsusuri ng kaligtasan.

Sa huli, ang mental model ng static batch processing ay isang checklist—paggawin ang mga hakbang A, B, at C sa pagkakasunod-sunod; samantalang ang mental model ng ERC-8211 ay isang kondisyonal na programa—pagkatapos ng A, gamitin ang totoong output ng A bilang input ng B; magpapatuloy lang sa C kung natutugunan ng B ang mga constraint; kung anumang hakbang ay hindi makamit ang inaasahan, babalik ang buong batch.

Maaari nating i-interpret ito bilang isang 'smart batch' mechanism na espesyal na disenyo para sa AI Agent at mga kumplikadong DeFi operation, dahil sa tradisyonal na on-chain operation, ang pagkumpleto ng isang kumplikadong DeFi strategy ay kadalasang nangangailangan ng maraming hiwalay na transaksyon: pagkuha ng pondo mula sa lending protocol, pagpalit ng token, at pag-deposit muli sa isang ibang protocol (pananaw sa paglalawak: Ang Buong Larawan ng Crypto AI Protocol: Paano Magsimula mula sa Pangunahing Field ng Ethereum upang Buuin ang Isang Bagong Operating System para sa AI Agent?).

Bawat hakbang ay nangangailangan ng hiwalay na pagsasara at pagpapatotoo, na nakakapagod sa mga gumagamit na tao, at isang bottleneck para sa mga AI Agent na nangangailangan ng madalas na awtomatikong aksyon, samantalang ang solusyon ng ERC-8211 ay nagpapahintulot na i-combine ang maraming blockchain operation sa isang transaksyon, kung saan bawat hakbang ay dininamikong i-parse ang aktwal na halaga habang kinakailangan na matugunan ang mga nakaprehinig na kondisyon bago maaaring magpatuloy sa susunod na hakbang.

Halimbawa, maaaring tapusin ng isang Agent ang isang transaksyon na may lagda: mag-draw mula sa Aave → palitan ang tunay na natanggap na halaga sa Uniswap → i-deposito ang resulta ng pagpalit sa Compound—lahat ay ipinapatupad nang atomikong, nang walang pangangailangan na sumulat ng bagong smart contract.

Ang ERC-8211 ay值得 ang pagmamasid ng industriya ng wallet, hindi lamang dahil ito ay angkop para sa Agent, kundi dahil ito ay magrereporma sa posisyon ng wallet sa chain of interaction.

Noong nakaraan, ang wallet ay mas parang isang secure signer; ang kanyang tungkulin ay pangalagaan ang private key, ipakita ang transaksyon, hilingin sa user na i-confirm, at pagkatapos ay ipadala ang signature. Sapat na mahalaga ang papel na ito sa panahon ng EOA, at patuloy pa ring may kahalagahan sa panahon ng account abstraction. Ngunit kung sa hinaharap, lalong maraming on-chain na operasyon ang gagawin ng Agent, mas magiging sentral at mas mabigat ang papel ng wallet.

Simpleng dahilan: kapag ang mga gumagamit ay hindi na nagpapatakbo ng bawat aksyon sa chain nang manual, kundi nagsisimula na magbigay ng awtorisasyon sa isang Agent upang isagawa ang buong hanay ng layunin, kailangan ng wallet ang kakayahang tanggapin ang mas mataas na antas ng interaksyon—hindi na lang ipapakita nito ang isang address ng contract at isang calldata, kundi isang buong programa ng pagsasagawa na binubuo ng “intensyon—lohika ng pagkuha—pagsusuri ng kondisyon—huling resulta”.

Kaya ang mga wallet sa hinaharap ay kailangang maunawaan hindi lang ang mga transaksyon, kundi ang mga programa. Ang ERC-8211 ay nagbibigay ng mas malinaw na pagkakataon sa mga wallet sa antas na ito, dahil ipinapakita nito ang mga pagsasagawa ng semantika sa loob ng estruktura ng code, kabilang ang kung saan galing ang mga parameter, anong mga kondisyon ang kailangang matugunan, kailan magpapatuloy, at kailan magkakaroon ng rollback — lahat ay hindi nakatago sa likod ng backend logic bilang isang black box, kundi mga bagay na maaaring i-interpret, i-simulate, at i-display ng wallet.

Mula sa pananaw ng wallet, ang buong mekanismo na ito ay nagtatapos sa iisang bagay: ang mga user ay hindi na nagpapakita ng isang serye ng mga pangunahing pagtawag na mahirap nilang maintindihan nang buo, kundi nagpapakita ng isang programa ng pagpapatupad na may direksyon sa resulta, malinaw na hangganan, at mga kondisyon na maaaring i-verify:

• Ang AI Agent ay maaaring magtrabaho sa pag-unawa sa intensyon ng user, pagbuo ng path;
• Ang wallet ang responsable na ipakita sa user ang path na ito sa mas malinaw para sa pagrereview;
• Ang relayer ay naglalayong sumubmit lamang kapag natutupad ang mga kondisyon, at walang kapangyarihan na baguhin ang resulta;

Ito ang eksaktong dahilan kung bakit ang non-custodial execution ay itinuturing na pangunahing kondisyon ng Agentic DeFi, dahil ang mga agent ay maaaring makilahok, ngunit ang soberanya, mga limitasyon, at huling pagkakasundo ay nananatili sa chain — at dito talaga nagkakatugma ang ERC-8211 sa mga smart wallet, dahil isinulat nito sa antas ng protokolo ang pagsasalaysay ng “mga komplikadong intensyon nang ligtas”.

Mahalagang banggitin na ang ERC-8211 ay fully compatible sa mga account abstraction framework tulad ng ERC-4337, EIP-7702, at ERC-7579; hindi ito nagpapalit sa account abstraction, kundi nagdaragdag ng isang bagong layer ng programmatic execution semantics para sa Agent.

Kung ang ERC-4337 ay naglutas ng "Sino ang maaaring kumatawan sa akin para mag-initiate ng transaksyon", at ang EIP-7702 ay naglutas ng "Paano ang EOA ay maaaring pansamantalang magkaroon ng kakayahan ng smart contract", ang ERC-8211 ay naglutas ng kung maaari bang tapusin ng Agent ang buong chain ng desisyon sa isang pag-sign lamang kung sakaling magsimula itong kumatawan sa akin.

Tingnan ang pag-unlad ng mga pattern ng interaksyon sa chain ng Ethereum sa nakalipas na 10 taon:

• Unang yugto: Isang pag-sign = Isang pagtawag sa function (panahon ng EOA)
• Pangalawang yugto: Isang pag-sign = isang grupo ng static batch calls (panahon ng ERC-4337, EIP-5792)
• Saklaw 3: Isang pagsuporta = isang dinamikong pagsusuri ng isang programa ng intensyon (Panahon ng ERC-8211)

Bawat paglipat ay nangangahulugan na ang user (o ang Agent na kumakatawan sa user) ay makakapagpahayag ng mas kumplikadong layunin gamit ang mas kaunting pagkakaiba.

Bagaman ang ERC-8211 ay kasalukuyang nasa pagsusulat pa lamang at patuloy pa ang teknikal na pag-uusap, at kailangan pa ng panahon para sa malawakang pagtanggap ng protokolo, ang direksyon na itinuturo nito ay sapat na malinaw: kapag ang AI Agent ay talagang nagsisimula na gumawa ng mga desisyon sa chain para sa mga tao, kailangan ng chain ng isang katugmang, native na sintaksis para sa pagpapatupad.