ERC-7683 sedang berubah, dan banyak penjelasan masih menggambarkan versi lama dari standar ini. Draf ERC-7683 saat ini lebih berpusat pada resolver. Alih-alih memaksa setiap protokol niat lintas-rantai ke dalam satu kontrak penitipan bersama, satu sistem lelang, satu mekanisme penyelesaian, satu model otorisasi, atau satu fungsi pengisian tujuan, protokol dapat mempertahankan arsitektur eksekusi mereka sendiri sambil mengekspos pesanan kepada solver melalui lapisan resolusi umum. Perbedaan ini penting. Pesanan ERC-7683 pada dasarnya adalah penawaran pembayaran sebagai imbalan atas pemenuhan serangkaian persyaratan yang ditentukan. Solver, juga disebut filler, mengevaluasi persyaratan tersebut, menentukan eksekusi apa yang diperlukan, mengikat modal atau gas, dan mengharapkan pembayaran jika mereka memenuhi pesanan dengan benar. Desain saat ini memungkinkan protokol untuk mengekspos payload spesifik-protokol yang tidak transparan bersama dengan kontrak resolver. Resolver ini menerjemahkan payload menjadi representasi umum yang berisi: • langkah eksekusi • variabel • pembayaran • asumsi eksplisit Ini memberikan solver yang dapat diprogram cara standar untuk memahami apa yang sebenarnya dibutuhkan oleh pesanan tanpa setiap solver harus mengimplementasikan logika khusus sepenuhnya untuk setiap protokol niat. Model eksekusi yang telah diresolusi dapat mengekspos persyaratan pengeluaran token, kebutuhan gas, batasan waktu, ketergantungan, dan perilaku revert. Variabel dapat mewakili alamat pembayaran solver, rantai pembayaran, output eksekusi, pemanggil langkah, saksi off-chain, kueri kontrak, dan kueri event. ERC-7683 juga mengintegrasikan representasi alamat yang interoperabel melalui ERC-7930, mengikat konteks rantai ke alamat alih-alih hanya mengandalkan alamat EVM 20-byte konvensional. Namun, ada batas keamanan yang penting. Standardisasi ERC-7683 tidak secara otomatis membuat protokol niat dasar menjadi aman. Kontrak penyelesaian, jembatan, sistem pengiriman pesan, token, mekanisme lelang, layanan off-chain, oracle, kunci sumber daya, perlindungan replay, logika pembatalan, perilaku pengembalian dana, dan pengisian sebagian tetap menjadi risiko spesifik-protokol kecuali secara eksplisit direpresentasikan melalui persyaratan atau asumsi yang telah diresolusi. Keamanan resolver oleh karena itu sangat penting. Resolver harus secara benar memvalidasi payload spesifik-protokolnya dan mengekspos representasi yang memungkinkan solver yang bertindak dengan benar memahami apa yang harus terjadi dan di bawah asumsi apa pembayaran akan tersedia. Resolver yang benar tidak dapat membuat sistem penyelesaian yang tidak aman menjadi aman. Dan format pesanan yang sesuai tidak menghilangkan risiko solver. Filler menjadi terpapar secara ekonomi sejak ia mengikat persetujuan, gas, modal, atau transaksi hingga pembayaran yang diharapkan menjadi final dan dapat dihabiskan. Bagi pengguna, titik verifikasi utama tetap praktis: • rantai asal • aset masukan • rantai tujuan • penerima • output yang diharapkan • batas waktu • cakupan otorisasi • transaksi atau data bertipe yang ditandatangani ERC-7683 juga secara alami cocok dalam sistem niat yang lebih luas seperti Open Intents Framework, tetapi keduanya tidak dapat saling menggantikan. ERC-7683 terutama merupakan lapisan standardisasi untuk resolusi pesanan yang berfokus pada solver. OIF adalah kerangka infrastruktur yang lebih luas yang mencakup asal niat, solving, pemenuhan, penyelesaian, agregasi, dan komponen terkait. Penelitian TokenToolHub terbaru kami menguraikan desain ERC-7683 saat ini, bagaimana perbedaannya dengan draf sebelumnya, siklus hidup pesanan, filler, keamanan resolver, langkah eksekusi, pembayaran, asumsi, alamat interoperabel, dan risiko solver yang tetap berada di luar standar itu sendiri. Analisis lengkap: https://t.co/VK5Yb4wvJ3