Dikembangkan bersama oleh Virtuals Protocol dan tim dAI dari Ethereum Foundation
Spesifikasi: https://eips.ethereum.org/EIPS/eip-8183
Diskusi: ethereum-magicians.org/t/erc-8183-agentic-commerce/27902
Bergabunglah dengan Komunitas Builder: https://t.me/erc8183
Perdagangan: Prasyarat untuk AI Terdesentralisasi
Jika kita ingin agen AI dapat diakses, terdesentralisasi, tidak dikendalikan oleh satu platform, tidak bergantung pada satu penyedia, dan tidak rentan terhadap satu titik kegagalan, maka perdagangan menjadi hal yang sangat penting. Perdagangan tidak bisa diperlakukan sebagai hal sekunder, melainkan harus menjadi infrastruktur fundamental. Per sopan perdagangan pun wajib selalu terbuka dan tanpa izin. Inilah 'ruang digital bersama tanpa pemilik' yang dibangun oleh @ethereum.
Mengapa demikian? Karena desentralisasi pada level AI dan agen membutuhkan banyak agen dan layanan independen. Misalnya, jika hanya satu agen yang dapat menghasilkan gambar dan layanan tersebut berhenti, maka pembuatan gambar menjadi terpusat, terlepas dari protokol apa yang digunakan. Jika hanya satu penyedia yang mengendalikan eksekusi perdagangan, pengelolaan dana bergantung pada satu pihak. Dan jika satu platform mengendalikan infrastruktur penyelesaian, maka seluruh penyedia dan klien tunduk pada aturan platform tersebut, meskipun ada ribuan agen di dalamnya.
Inilah mengapa perdagangan harus terbuka: setiap agen harus dapat membeli layanan, setiap agen harus dapat menawarkan layanan. Tidak ada gatekeeping, tidak ada walled garden. Tidak ada perantara yang wajib.
Mengapa Blockchain
Namun, yang sangat krusial, perdagangan hanya berjalan jika semua pihak dapat yakin distributing kesepakatan akan dipenuhi. Jika klien membayar di muka, bagaimana mereka tahu penyedia akan deliver? Jika provider deliver lebih dulu, bagaimana mereka tahu klien akan membayar? Harus ada pihak yang menahan dana, memantau later pekerjaan sudah selesai, dan menegakkan hasil: mencairkan pembayaran setelah selesai, refund jika gagal. Kepercayaan (atau ketiadaannya) inilah yang pada dasarnya melahirkan entitas terpusat atau gatekeeping.
Dalam arsitektur tradisional, pihak tersebut adalah platform. Perusahaan yang Second escrow, mengendalikan state machine, dan memutuskan siapa yang dibayar dan kapan. Itu berjalan hingga tidak lagi berjalan. Platform dapat mengubah aturan. Ia dapat membekukan dana. Ia dapat mendepak penyedia. Ia dapat menutup layanan. Setiap peserta bergantung pada perilaku baik platform. Ini adalah sentralisasi, bukan pada level protokol, melainkan pada level penegakan. Tidak salah, namun memang diperlukan pada sistem yang tidak memiliki trust. Tujuannya adalah de-totalisasi: mencegah satu entitas memiliki kendali penuh atas cara agen bertransaksi. Kami sudah melihat langsung: para builder menginginkan infrastruktur yang dapat diandalkan tanpa bergantung pada perilaku baik satu platform.
Smart contract di blockchain terdesentralisasi adalah solusi untuk masalah ini. Escrow, state machine, dan evaluator attestation dijalankan dalam kode yang publik, immutable, dan tidak dimiliki siapa pun. Kontrak menjadi penegak netral, menghasilkan sinyal bermakna bagi reput joining pihak yang terlibat.
Penyelesaian on-chain juga menghasilkan sesuatu yang tidak bisa dilakukan platform terpusat: catatan yang portabel, dapat diverifikasi, dan immutable. Setiap pekerjaan selesai, setiap evaluator attestation, setiap deliverable hash dicatat on-chain, dapat dilihat oleh agen mana pun, pada platform mana pun, melalui antarmuka apa pun. Catatan inilah yang menjadi fondasi sistem reputasi dan identitas agen. Tanpa settlement on-chain, tidak ada riwayat yang dapat diverifikasi. Tanpa riwayat yang dapat diverifikasi, tidak ada reputasi yang portabel. Tanpa reputasi portabel, setiap interaksi agen dimulai dari nol.
Inilah alasan mengapa dibutuhkan standar on-chain. Escrow, state transition, dan attestation. Inilah bagian yang harus netral, aman, dan dapat ditegakkan.
Penemuan, negosiasi, dan komunikasi dapat terjadi on-chain maupun off-chain, melalui antarmuka apa pun yang paling alami. Agen dapat berinteraksi melalui HTTP dengan protokol antarmuka x402, sehingga pengalaman terasa seperti API atau HTTP request standar. Agen tidak harus langsung berinteraksi dengan chain. Agen cukup menandatangani satu pesan, lalu fasilitator akan MB settlement on-chain dan standarnya. Atau agen dapat berinteraksi langsung melalui MCP atau A2A. Antarmuka fleksibel, namun settlement inti harus trustless, terprogram, dan on-chain. Infrastruktur seperti itu tidak akan disediakan oleh sistem terpusat, karena akan mengurangi kendali mereka.
Ekonomi Agen
Model AI dan agen berkembang pesat dan semakin canggih setiap liberal. Tugas yang intact tahun lalu membutuhkan keahlian manusia—menulis kode produksi, menghasilkan media profesional, menganalisis data keuangan, mengkoordinasikan workflow multi-langkah—sekarang dapat dilakukan agen dengan kualitas setara atau lebih baik. Dan kemampuannya masih terus meningkat. Perkembangan AI membuat ekonomi baru ini tak terelakkan.
Saat agen semakin mampu, mereka mengambil pekerjaan yang lebih bernilai. Agen yang dapat menghasilkan gambar setara fotografi profesional adalah layanan yang layak dibayar. Agen yang dapat menganalisis portofolio dan mengeksekusi perdagangan teroptimasi, mengelola uang nyata. Agen yang dapat meninjau dokumen hukum dan mengidentifikasi risiko, melakukan pekerjaan yang bernilai ratusan dolar per jam jika dilakukan manusia.
Inilah transisi utama: AI dan agen menjadi peserta ekonomi yang menghasilkan nilai dan layanan.
Dan ketika AI dapat diakses secara universal, setiap individu, organisasi, dan perangkat dapat beroperasi melalui agen. Ekonomi pun berubah. Agen tidak hanya melayani manusia; mereka juga saling berinteraksi dan melayani. Misalnya, agen yang mengkoordinasikan kampanye mengontrak agen konten, agen distribusi, dan agen analitik. Ekonomi menjadi jaringan agen yang bertransaksi dengan agen lain, dengan kecepatan mesin, dalam skala global.
Ketika agen mampu melakukan pekerjaan bernilai dan semua orang dapat mengakses agen, hasilnya adalah ekonomi di sopan mayoritas aktivitas komersial mengalir melalui sistem otonom. Inilah yang sedang kami bangun.
Masalah: Perdagangan Trustless Antar Agen
Ekonomi agen membutuhkan perdagangan antar agen. Dan perdagangan antar agen yang belum pernah berinteraksi, lintas organisasi dan chain, harus trustless.
Ketika manusia bertransaksi, mempekerjakan satu sama lain, atau bahkan layanan, kepercayaan adalah signal utama. Dalam kasus ini, trust dimediasi oleh platform, ulasan, sistem hukum, dan norma sosial. Ketika agen mempekerjakan agen lain, tidak ada mekanisme tersebut. Tidak ada reputasi sosial untuk diperiksa. Tidak ada jalur hukum atau reputasi yang beroperasi secepat transaksi mesin. Tidak ada platform atau regulator yang menegakkan Q.
Jadi pertanyaannya: bagaimana membuat perdagangan antar agen menjadi trustless?
Anda tidak bisa sekadar mengirim uang dan berharap yang terbaik. Transfer token bukanlah perdagangan. Itu hanyalah pembayaran tanpa tenur. Tidak ada catatan tentang apa yang disepakati. Tidak ada mekanisme untuk menahan dana hingga pekerjaan memuaskan. Tidak ada evaluasi yang menghasilkan sinyal yang dapat dirujuk agen lain. Tidak ada jalur jika penyedia tidak pernah deliver.
Diperlukan engagement yang terstruktur: dana ditahan dalam escrow terdesentralisasi yang dapat diprogram dan tidak bias, pekerjaan diajukan sebagai artefak yang dapat diverifikasi, evaluator yang menyatakan apakah deliverable memenuhi syarat, dan hasil deterministik. Mekanisme yang memastikan dana dilepas setelah selesai, dikembalikan jika ditolak, dan dapat diambil kembali jika kedaluwarsa. Semua ini berkontribusi pada identitas dan reputasi seluruh pihak yang terlibat.
ERC-8183: Job Primitive
Dalam kolaborasi erat dengan tim dAI @ethereumfndn, kami memformalkan hal ini sebagai standar. ERC-8183: Agentic Commerce, adalah standar terbuka dan tanpa izin untuk aplikasi perdagangan agen dengan escrow dan evaluator attestation yang diprogram sebagai smart contract on-chain.
ERC-8183 mendefinisikan satu inti: Job. Setiap Job terdiri dari tiga pihak, yaitu Client, Provider, dan Evaluator. Masing-masing pihak hanya didefinisikan oleh alamat wallet-nya, memungkinkan aplikasi dan penggunaan primitive ini secara luas.
Komponen kunci dan prinsip di pipeline Job primitive adalah: (i) spesifikasi dan deskripsi job—catatan jelas tentang tugas, layanan, atau pekerjaan yang terkait dengan pembayaran, (ii) pembayaran itu sendiri—yang diamankan dalam escrow yang diprogram secara netral hingga status akhir dan dilepaskan secara programatik, (iii) pengiriman deliverable yang dicatat, dapat diverifikasi, dan dapat dilacak untuk melindungi klien dan penyedia, dan (iv) evaluator attestation yang menghasilkan sinyal bermakna untuk jalur reputasi dan identitas pihak-pihak yang terlibat—memberikan insentif yang selaras untuk penyelesaian trustless.
Ini mendasari alur Job melalui empat status utama, memastikan transaksi trustless:
Open → Funded → Submitted → Terminal (Completed / Rejected / Expired)
Singkatnya, Job diinisialisasi saat Client membuat job dengan Provider, lalu mendanainya dan mengunci pembayaran dalam escrow. Provider mengerjakan dan memanggil
submit, menaruh deliverable (atau referensinya) di chain. Evaluator meninjau submission dan memanggil complete (mencairkan dana ke provider) atau reject (refund ke client). Jika baik provider maupun
evaluator tidak bertindak sebelum batas waktu (expiry time), job kedaluwarsa dan client mengambil kembali dana mereka.
Standar ini sengaja dibuat minimal, dan membentuk atomic primitive. Tidak mengatur alur negosiasi, struktur biaya, penyelesaian sengketa, protokol komunikasi, atau mekanisme penemuan. Standar ini hanya memastikan siklus hidup job inti, minimum viable surface untuk perdagangan agen trustless.
Evaluator
Salah satu konsep utama dan keputusan desain dalam ERC-8183 adalah konsep Evaluator, yang hanya didefinisikan sebagai sebuah alamat. Evaluator selalu merupakan agen, dalam makna paling luas.
Untuk tugas subjektif seperti menulis, desain, atau analisis, evaluator bisa berupa agen AI yang membaca submission, membandingkannya dengan permintaan, dan membuat keputusan. Untuk tugas deterministik seperti komputasi, pembuatan proof, atau transformasi data, evaluator adalah smart contract yang membungkus ZK verifier. Provider mengirimkan proof; evaluator memverifikasi on-chain dan memanggil complete atau reject secara otomatis. Untuk engagement bernilai tinggi, evaluator bisa berupa multi-sig, DAO, atau validator berbasis staking.
Standar tidak membedakan di antara ini. Sebuah alamat memanggil complete atau reject. Apakah alamat itu menjalankan agen berbasis LLM atau sirkuit ZK bukan urusan protokol. Ini memungkinkan antarmuka yang sama untuk job pembuatan gambar senilai $0,10 maupun pengelolaan dana $100.000.
Hooks: Modular Extensibility
Job primitive sengaja dibuat minimal. Namun perdagangan tidak demikian. Aplikasi nyata membutuhkan validasi khusus, pembaruan reputasi, distribusi biaya, transfer dana, mekanisme bidding, dan logika domain-spesifik yang berbeda untuk setiap use case. Job evaluasi konten, token swap, dan posisi prediction market masing-masing membutuhkan logika fundamental yang berbeda.
ERC-8183 mengatasi ini dengan hooks. Hook adalah smart contract opsional yang lamps pada Job saat dibuat. Hook menerima callback sebelum dan sesudah setiap aksi, memungkinkan logika khusus dijalankan di sekitar siklus hidup inti tanpa memodifikasinya. Hook diidentifikasi oleh satu function selector (transisi mana yang terjadi) dan menerima parameter relevan. Hook dapat menegakkan prasyarat, memblokir aksi tidak valid, memicu efek samping, atau mengeksekusi transfer token tambahan, semua dalam transaksi yang sama dengan perubahan status inti.
Jika tidak ada hook, kontrak berjalan normal. Implementasi tanpa hook sepenuhnya compliant dengan ERC-8183. Hook bersifat aditif, bukan wajib. Desain ini menjaga kontrak inti tetap kecil dan antarmuka stabil. Use case baru didukung melalui kontrak hook baru, menjaga logika ekstensi tetap on-chain, terprogram, dan trustless, sama seperti inti.
Contoh Aplikasi Perdagangan
Job inti mengelola perdagangan layanan sederhana: bayar, kirim, evaluasi. Namun ekonomi yang dijalani agen tidaklah sederhana. Beberapa job melibatkan pengelolaan modal klien, bukan sekadar menerima biaya. Beberapa membutuhkan harga kompetitif sebelum provider ditetapkan. Beberapa butuh pengecekan kepercayaan yang merujuk data reputasi eksternal. Ini adalah model ekonomi yang fundamentally berbeda, dan hooks memungkinkan antarmuka Job inti mendukung keragaman ini serta menjadikan ERC-8183 sebagai primitive perdagangan yang serbaguna.
- Service Job adalah baseline dan tidak membutuhkan hook. Klien membayar untuk pembuatan konten, analisis data, atau review kode. Alur escrow dan evaluasi inti sepenuhnya menangani.
- Fund Transfer Job lebih dari sekadar biaya layanan. Klien menyediakan modal (token untuk swap, dana untuk investasi), provider mentransformasinya, dan output harus kembali. Hook dapat mengelola aliran modal dua arah ini bersama escrow inti, memastikan provider mendepositkan output token sebelum job dapat selesai. Ini mencakup berbagai aplikasi seperti yield farming, token swap, rebalancing portofolio—job di mana provider mengelola uang klien atau membutuhkan modal di: awal untuk menjalankan tugas, bukan sekadar menerima biaya.
- Bidding Job membalik model penugasan. Alih-alih klien memilih provider di awal, provider bersaing pada harga. Hook memverifikasi bid yang ditandatangani secara kriptografi saat assignment, memastikan provider terpilih berkomitmen pada harga yang diklaim. Tidak ada pihak yang dapat memalsukan atau menyangkal syarat.
- Reputation-Gated Job menegakkan kepercayaan di level protokol. Hook melakukan query ke ERC-8004 sebelum mengizinkan aksi, menolak provider bereputasi rendah atau memberlakukan syarat lebih ketat untuk agen yang belum terbukti.
- Privacy-Preserving Job menggunakan hook untuk memungkinkan perdagangan tanpa eksposur data. Alih-alih memposting data tugas sensitif on-chain, Privacy Hook dapat menegakkan agar field 'Submission' berisi Zero-Knowledge Proof (ZKP) atau referensi ke lingkungan terenkripsi (seperti TEE). Ini memastikan pembayaran trustless dan publik, namun kekayaan intelektual atau data pribadi tetap 'sanctuary', hanya dapat diakses agen yang berwenang.
- Risk-Assessed atau Underwriting Job dapat menegakkan underwriting di level protokol melalui hooks. Hook dapat mensyaratkan jaminan dari Provider atau underwriter, memeriksa skor reputasi ERC-8004 dan metrik lain sebelum assignment, menegakkan bond yang dipotong jika gagal evaluasi, atau query external risk oracle. Proses persetujuan yang sebelumnya opaque menjadi transparan, terprogram, dan kompetitif. Misalnya, toleransi risiko berbeda dapat dilayani; satu untuk agen mapan membutuhkan sedikit pengecekan, yang lain di domain bernilai tinggi membutuhkan jaminan besar.
Setiap aplikasi ini dapat diimplementasikan sebagai kontrak hook berbeda, menjaga fungsionalitas inti dan standar Job primitive. Model ekonomi baru, aplikasi perdagangan, atau variasi logika khusus adalah tarikan hook baru. Kami telah memperkenalkan beberapa hook pertama sebagai contoh, namun kami yakin baru permukaan yang dijajaki dan hook paling menarik belum ditulis. Seperti apa agent commerce untuk asuransi, kolaborasi kreatif, koordinasi supply chain? Kami belum tahu, dan itulah intinya. Selain pipeline, agent commerce akan berkembang dengan cara yang tidak bisa kita prediksi, model ekonomi baru, mekanisme kepercayaan baru, bentuk kolaborasi baru antar mesin. Standar ini dirancang untuk tumbuh seiring evolusi itu, bukan membatasinya. Standar ini harus dibangun secara terbuka, dan memang layak demikian karena ide terbaik akan datang dari ekosistem, dan kami menantikan untuk menemukannya bersama.
Simbiosis dengan ERC-8004
ERC-8183 tidak berdiri sendiri. Standar ini bersimbiosis dengan ERC-8004 ("Trustless Agents"), standar Ethereum untuk identitas, reputasi, dan validasi agen.
ERC-8004 menyelesaikan discovery dan trust: bagaimana agen menemukan satu sama lain dan menilai keandalan. Namun registry hanya sebernilai aktivitas yang mereka catat. Identitas tanpa perdagangan atau aksi adalah steady kosong. Reputasi membutuhkan interaksi nyata untuk diukur. Validasi membutuhkan deliverable terdefinisi untuk pipeline.
ERC-8183 menyediakan perdagangan yang menjadi fondasi lapisan trust ERC-8004. Setiap job adalah sinyal reputasi. Setiap submission adalah deliverable yang dapat divalidasi oleh validator. Setiap evaluasi adalah attestation yang dapat dirujuk agent lain.
Kedua standar membentuk loop yang memungkinkan self-organization yang lebih besar dan kuat antar agen melalui interaksi trustless:
Discovery (8004) → Commerce (8183) → Reputation (8004) → Better Discovery → More Trustless Commerce
Tidak canon lengkap tanpa yang lain. Bersama, mereka membentuk fondasi perdagangan dan interaksi agen trustless.
Melampaui Pembayaran
ERC-8183 bukan protokol pembayaran. Ini adalah standar perdagangan.
Pembayaran hanya memindahkan dana. Namun perdagangan membutuhkan lebih dari sekadar memindahkan uang. Perdagangan adalah segala sesuatu di sekitar pembayaran yang membuatnya dapat dipercaya dan fungsional: apa yang pipeline, apakah pekerjaan selesai, siapa yang memverifikasi, dan apa yang terjadi jika tidak. Di dunia tradisional, perdagangan berjalan karena seluruh fungsi di sekitar pembayaran: penilaian risiko dan underwriting merchant sebelum dapat menerima pembayaran, perpanjangan kredit agar pembeli dapat bertransaksi sebelum dana tersedia, deteksi fraud di miliaran transaksi real time, mekanisme chargeback dan dispute yang melindungi pembeli saat layanan gagal, dan sistem reputasi yang mengakumulasi trust dari interaksi berulang. Fungsi-fungsi inilah yang membuat payment processor, card network, dan platform bernilai; bukan pergerakan dana itu sendiri, tapi infrastruktur kepercayaan di sekelilingnya.
Saat perdagangan bergerak on-chain, semua fungsi ini tidak hilang. Semuanya perlu dibangun ulang secara trustless, terprogram, dan terbuka. Inilah ERC-8183.
Model escrow dan evaluator attestation pada Job primitive mirip dengan mekanisme chargeback dengan settlement yang terprogram dan upfront. Menggunakan reputasi on-chain ERC-8004 dan metrik serta riwayat reputasi on-chain lainnya sebagai bagian dari ERC-8183 mirip dengan underwriting proprietary dengan contrasting yang portabel dan dapat diverifikasi.
Hooks menggantikan penilaian risiko terpusat dengan logika modular, kompetitif, dapat diaudit, yang dapat dideploy oleh fasilitator mana pun. Hasilnya bukan sekadar cara memindahkan dana on-chain, tetapi cara membangun ulang infrastruktur kepercayaan penuh perdagangan, secara terbuka dan tanpa izin.
Protokol pembayaran dan antarmuka yang ada, baik payment processor tradisional maupun protokol transfer stablecoin seperti x402 adalah pengalaman internet native yang mulus untuk memindahkan dana. ERC-8183 mengelola siklus penuh yang mengubah pembayaran menjadi transaksi trustless: spesifikasi, escrow, pengiriman deliverable, evaluator attestation, dan settlement deterministik. Agen dapat berinteraksi melalui x402 atau HTTP di layer antarmuka, sementara reportedly settlement berjalan melalui ERC-8183 on-chain. Keduanya saling melengkapi.
Irreversibilitas, Escrow, dan Masalah Chargeback
Kekhawatiran lain dengan pembayaran standalone adalah irreversibilitas. Saat kartu dibebankan dan layanan tidak memuaskan, konsumen mengajukan dispute dan membalikkan beban. Saat pembayaran ditransfer, dana hilang. Ini keberatan nyata dan valid untuk sopan pembayaran dan transfer mentah.
ERC-8183 menjaga konsep inti ini secara struktural dalam kontrak. Dana ditahan dalam escrow sampai evaluator menegaskan deliverable memenuhi syarat. Jalur reject mengembalikan dana ke klien. Jalur expiry otomatis reclaim. Ini adalah padanan trustless, terprogram untuk model authorization-and-capture yang membuat perdagangan kartu berjalan, kecuali syarat dikodekan upfront dan ditegakkan oleh kode, bukan diputuskan setelah kejadian oleh jaringan dengan insentif sendiri.
Untuk pra-otorisasi jumlah tidak pasti, hotel hold, layanan yang scope-nya bisa berkembang, fleksibilitas hooks dapat didesain untuk mengunci jumlah maksimum dan menyelesaikan jumlah final berdasarkan input yang dapat diverifikasi saat selesai. Arsitektur mendukung pola yang membuat perilaku kepercayaan dalam perdagangan kartu fleksibel, sambil menjaga settlement transparan, terbuka, trustless, dan on-chain.
Gelombang Baru Peserta Ekonomi
Gelombang AI menciptakan peserta ekonomi baru, baik pembeli maupun merchant, lebih cepat dari pergeseran sebelumnya. Jutaan developer dan non-developer membangun dan merilis micro-service, API, dan tools menggunakan AI coding assistant, banyak tanpa entitas hukum, website, atau riwayat transaksi. Agen dari perusahaan teknologi dan framework open source mengonboarding jutaan pengguna dengan agen dan asisten AI pribadi.
Sistem pembayaran tradisional akan kesulitan melayani merchant ini. Bukan karena teknologinya kurang, tapi karena ketika processor menyetujui Provider, ia menyerap risiko: penipuan, chargeback, dispute. Merchant tanpa rekam jejak, entitas, dan riwayat terlalu berisiko untuk di-underwrite.
ERC-8183 secara desain tanpa izin. Provider adalah alamat wallet. Tidak ada onboarding, tidak ada underwriting, tidak ada gatekeeper. Job primitive memberikan merchant ini bukan hanya cara dibayar, tetapi siklus perdagangan penuh: spesifikasi pekerjaan, pembayaran escrow, pengiriman deliverable yang dapat diverifikasi, dan evaluator attestation, memberikan fondasi transaksi yang dapat dipercaya.
Ketidakmampuan meng-underwrite provider baru mungkin dianggap celah sementara. Standar terbuka secara struktural mempercepat timeline ini. Fasilitator mana pun dapat mendeply ERC-8183 hari ini. Ekosistem berkembang melalui eksperimen, bukan konsensus institusional. Namun lebih fundamental, ERC-8183 bersama ERC-8004 tidak sekadar menjembatani gap underwriting, tapi menyelesaikan akar masalahnya. Penyebab processor tidak dapat meng-underwrite merchant baru adalah tidak adanya riwayat yang dapat diverifikasi. ERC-8183 menghasilkan riwayat tersebut. Setiap pekerjaan selesai dicatat on-chain: hash deliverable, evaluator attestation, hasilnya. Riwayat itu portabel, dapat diverifikasi, dan tidak dimiliki siapa pun.
Yang penting, track record tidak terkunci di satu platform. Saat ini, platform A tahu tingkat chargeback Anda, platform B tahu skor penjual Anda, tapi Anda tidak bisa membawa riwayat itu ke mana-mana. Di ERC-8183, reputasi adalah aset portabel milik merchant, dapat dibaca fasilitator mana pun, di chain mana pun, melalui antarmuka mana pun yang membaca standar. ERC-8183 memberi makan identitas dan reputasi on-chain (ERC-8004) dan menyediakan data untuk underwriting.
Membangun Masa Depan Agent Commerce dan AI Terdesentralisasi Bersama
ERC-8183 adalah standar terbuka untuk perdagangan agen trustless. Berikut cara Anda bisa terlibat:
Bangun dengan ERC-8183. Jadilah fasilitator! Deploy ERC-8183 di chain Anda. Bangun SDK. Bangun wrapper. Bangun scanner dan tracker. Bangun antarmuka dan pengalaman baru, dan biarkan settlement terjadi secara aman dan dapat diverifikasi on-chain dengan ERC-8183. Ciptakan framework agen yang berinteraksi native dengan standar.
Eksplorasi, Eksperimen, dan Bangun Hooks. Butuh pembayaran milestone atau penyelesaian dispute? Bangun sebagai hook. Inilah ruang kreativitas dan tape untuk keragaman aplikasi.
Bangun dan daftarkan Evaluator. Evaluator adalah kunci memastikan perdagangan agen aman dan trustless, namun sangat kurang. Bangun evaluator untuk domain spesifik, terutama untuk domain dan layanan yang sepenuhnya dapat diverifikasi. Daftarkan di ERC-8004. Berkontribusi nyata pada reputasi dan identitas agen.
Kontribusi dan beri umpan balik. Ini adalah standar kolektif. Standar ini hanya akan menjadi seperti yang dibutuhkan melalui eksperimen luas, penggunaan nyata, masukan jujur, dan iterasi. Jika ada yang kurang, usulkan. Jika ada yang salah, tantang. Spesifikasi terbuka, repo terbuka, diskusi terbuka. Standar ini berkembang bersama.
Ekonomi agen akan dibangun di atas standar terbuka atau di dalam walled garden. Kami memilih open standard. Ruang digital bersama.
ERC-8004 untuk trust. ERC-8183 untuk commerce. Sisanya Anda yang bangun.
Ingin Tahu Lebih Lanjut?
Spesifikasi ERC-8183: https://eips.ethereum.org/EIPS/eip-8183
Spesifikasi ERC-8004: eips.ethereum.org/EIPS/eip-8004
Diskusi ERC-8183: ethereum-magicians.org/t/erc-8183-agentic-commerce/27902
Gabung Komunitas Telegram: https://t.me/erc8183
Disclaimer:
-
Artikel ini diterbitkan ulang dari [virtuals_io]. Seluruh hak cipta milik penulis asli [virtuals_io]. Jika ada keberatan terkait penerbitan ulang ini, silakan hubungi tim Gate Learn, dan mereka akan menanganinya dengan segera.
-
Disclaimer Tanggung Jawab: Pandangan dan opini yang diungkapkan dalam artikel ini sepenuhnya milik penulis dan tidak merupakan compar saran investasi apa pun.
-
Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, dilarang menyalin, mendistribusikan, atau memplagiat artikel terjemahan.
