Binabago ang ERC-7683, at maraming paliwanag ay naglalarawan pa rin ng mas lumang bersyon ng pamantayan. Ang kasalukuyang draft ng ERC-7683 ay mas resolver-centric. Sa halip na pilitin ang bawat cross-chain intent protocol na gamitin ang iisang shared escrow contract, iisang sistema ng auksiyon, iisang mekanismo ng pag-settle, iisang modelo ng pagsasang-ayon o iisang destination fill function, ang mga protocol ay maaaring panatilihin ang kanilang sariling execution architecture habang ipinapakita ang mga order sa mga solver sa pamamagitan ng isang karaniwang resolution layer. Mahalaga ang pagkakaiba na ito. Ang isang ERC-7683 order ay sa pangkabuuan ay isang alok ng bayad sa palitan ng pagtugon sa isang tukoy na hanay ng mga kahilingan. Ang mga solver, na tinatawag ding fillers, ay binabasa ang mga kahilingang ito, tinutukoy kung ano ang kinakailangang pagpapatupad, binabayaran ang kapital o gas, at inaasahan ang bayad kung matupad nang tama ang order. Ang kasalukuyang disenyo ay nagpapahintulot sa isang protocol na ipakita ang isang opaque, protocol-specific payload kasama ang resolver contract. Ang resolver na ito ay binabago ang payload sa isang karaniwang representasyon na naglalaman ng: • mga hakbang sa pagpapatupad • mga baryable • mga bayad • mga eksplisitong aksiyon Ito ay nagbibigay sa mga programmable solver ng isang standardisadong paraan upang maunawaan kung ano talaga ang kailangan ng order nang hindi kinakailangan ng bawat solver na mag-implement ng ganap na bespoke na lohika para sa bawat intent protocol. Ang resolved execution model ay maaaring ipakita ang mga kahilingan sa paggastus ng token, mga kahilingan sa gas, mga limitasyon sa oras, mga dependensya at pagbabalik na pag-uugali. Ang mga baryable ay maaaring kumatawan sa mga address ng bayad ng solver, mga chain ng bayad, mga output sa pagpapatupad, mga caller ng hakbang, mga off-chain witness, mga query sa contract at mga query sa event. Ang ERC-7683 ay naglalaman din ng interoperable na representasyon ng address sa pamamagitan ng ERC-7930, na nag-uugnay sa chain context sa address sa halip na magbatay lamay sa karaniwang 20-byte EVM address. Ngunit may mahalagang seguridad na hangganan. Ang standardisasyon ng ERC-7683 ay hindi awtomatikong ginagawang ligtas ang nakapalibot na intent protocol. Ang mga settlement contract, bridges, message-passing systems, tokens, mekanismo ng auksiyon, off-chain services, oracles, resource locks, replay protection, cancellation logic, refund behavior at partial filling ay nananatiling protocol-specific na panganib maliban kung eksplisitong ipinapakita sa pamamagitan ng resolved requirements o assumptions. Kaya mahalaga ang resolver security. Dapat tama at maayos na i-validate ng resolver ang protocol-specific nito payload at ipakita ang isang representasyon na nagpapahintulot sa isang tamang gumagana na solver na maunawaan kung ano ang dapat gawin at ilalabas kung anong assumptions magiging available ang bayad. Hindi makakapagbigay ng ligtas na settlement system ang isang tama at wastong resolver kung ito ay hindi ligtas. At hindi alisin ng tugma sa order format ang solver risk. Naging eksposado sa ekonomikong panganib ang filler mula sa sandaling pinapayagan nito ang approvals, gas, kapital o transaksyon hanggang sa maging final at spendable ang inaasahang bayad. Para sa mga user, nananatiling praktikal ang mga pangunahing puntos ng pagsusuri: • origin chain • input asset • destination chain • recipient • inaasahang output • deadline • sakop ng awtorisasyon • transaksyon o typed data na sinasignahan Ang ERC-7683 ay natural ding nasa loob ng mas malawak na intent systems tulad ng Open Intents Framework, ngunit hindi ito magkakaibigan. Ang ERC-7683 ay pangunahin ay isang standardisasyon layer para sa solver-facing order resolution. Ang OIF naman ay mas malawak na infrastructure framework na sumasakop sa intent origination, solving, fulfillment, settlement, aggregation at kaugnay na mga komponente. Ang aming pinakabagong pananaliksik sa TokenToolHub ay binubuksan ang kasalukuyang disenyo ng ERC-7683, kung paano ito nagkakaiba sa mas lumang draft, ang order lifecycle, ang fillers, resolver security, execution steps, payments, assumptions, interoperable addresses at ang solver risks na nananatiling labas sa sariling standard. Buong pagsusuri: https://t.co/VK5Yb4wvJ3