作者：Zack Pokorny，Galaxy Digital asisten peneliti; Sumber: Galaxy Digital; Terjemahan: Shaw Keuangan Emas Jinse

Pendahuluan

Skenario penerapan dan kapabilitas AI Agent (agen kecerdasan buatan) sudah mulai berevolusi secara bertahap. Mereka secara perlahan mewujudkan eksekusi tugas secara otonom, dan riset terkait juga sedang mendorong kemampuan agen untuk memegang serta mengonfigurasi dana, menemukan strategi transaksi dan pendapatan, dan fungsi-fungsi lain. Meski transformasi eksperimental ini masih berada pada tahap yang sangat awal, arah perkembangannya sudah sepenuhnya berbeda dengan masa lalu — selama ini, agen sebagian besar hanya digunakan sebagai alat sosial dan analisis.

Blockchain menyediakan arena uji yang alami untuk evolusi ini. Blockchain memiliki sifat tanpa izin, sifat komposabilitas (yakni kerangka eksekusi yang sama dapat menampung berbagai aplikasi komponen dasar keuangan), ekosistem aplikasi open-source, data yang terbuka secara setara bagi semua partisipan, serta semua aset di rantai secara default mendukung pemrograman.

Dari sinilah muncul pertanyaan struktural: jika blockchain bersifat dapat diprogram dan tanpa izin, mengapa agen otonom tetap menghadapi hambatan operasional? Jawabannya bukan terletak pada apakah eksekusi itu bisa dilakukan, melainkan pada besarnya biaya pemahaman semantik dan orkestrasi koordinasi yang harus ditanggung di atas lapisan eksekusi. Blockchain dapat memastikan akurasi transisi status, tetapi biasanya tidak menyediakan kemampuan abstrak seperti interpretasi ekonomi bawaan protokol, identitas standar, atau penjadwalan tingkat tujuan.

Sebagian hambatan tersebut berasal dari karakteristik arsitektur sistem tanpa izin, sementara sebagian lainnya berasal dari kondisi perkembangan alat, penyaringan informasi, dan infrastruktur pasar saat ini. Dalam praktiknya, banyak fungsi tingkat atas masih perlu bergantung pada perangkat lunak dan alur kerja yang dirancang dengan manusia sebagai inti pengoperasian.

Arsitektur blockchain dan AI Agent

Inti desain blockchain berpusat pada mekanisme konsensus dan eksekusi deterministik, bukan interpretasi semantik. Yang disediakannya untuk dunia luar adalah komponen dasar tingkat bawah seperti slot penyimpanan, log peristiwa, pelacakan pemanggilan, bukan objek ekonomi yang distandardisasi. Karena itu, konsep abstrak seperti posisi kepemilikan, pendapatan, koefisien kesehatan, kedalaman likuiditas, dan sebagainya, biasanya perlu direkonstruksi di luar rantai oleh indexer, lapisan analitik, antarmuka depan (frontend), dan API aplikasi, dengan mengubah status khusus setiap protokol menjadi bentuk yang lebih mudah digunakan.

Banyak alur operasi DeFi terdesentralisasi arus utama, terutama yang ditujukan untuk pengguna biasa dan operasi berbasis keputusan subjektif, masih mempertahankan pola inti: pengguna menegaskan inti eksekusi melalui interaksi antarmuka depan, menandatangani setiap transaksi. Pola yang berpusat pada antarmuka pengguna ini, bersama dengan meluasnya pengguna biasa, memungkinkan penerapan skala besar; meskipun sebagian aktivitas di rantai sudah digerakkan oleh mesin. Logika interaksi pengguna biasa yang dominan saat ini adalah: niat operasi → antarmuka pengguna → memulai transaksi → konfirmasi selesai. Walaupun operasi yang diprogram memiliki jalur yang berbeda, ia juga memiliki keterbatasannya sendiri: pada tahap pembangunan, pengembang harus memilih kontrak dan cakupan aset tertentu, lalu menjalankan algoritma berdasarkan cakupan yang tetap tersebut. Dua pola ini sama-sama tidak dapat beradaptasi dengan sistem yang memerlukan penemuan otonom, evaluasi, dan pengombinasian perilaku operasi berdasarkan tujuan dinamis selama waktu berjalan.

Ketika sistem yang dioptimalkan khusus untuk verifikasi transaksi digunakan oleh sistem yang juga perlu menafsirkan kondisi ekonomi, menilai kredit, dan mengoptimalkan perilaku berdasarkan tujuan yang jelas, hambatan mulai terlihat. Sebagian kesenjangan ini berasal dari sifat desain blockchain yang tanpa izin dan heterogen; sebagian lainnya karena alat yang ada masih membungkus proses interaksi blockchain dengan audit manusia dan perantara frontend.

Alur operasi agen dan strategi algoritmik tradisional

Sebelum menganalisis kesenjangan antara infrastruktur blockchain dan sistem agen, perlu memperjelas alur operasi agen yang lebih tinggi dan perbedaan utama dari sistem algoritma on-chain tradisional.

Perbedaannya bukan terletak pada tingkat otomatisasi, kompleksitas teknis, pengaturan parametrik, atau bahkan kemampuan adaptasi dinamis. Sistem algoritma tradisional dapat mencapai parametrasi yang sangat tinggi: ia bisa menemukan kontrak dan token baru secara otomatis, mengalokasikan dana di berbagai strategi, lalu melakukan rebalancing berdasarkan kinerja. Perbedaan intinya adalah apakah sistem mampu menangani skenario yang tidak dipra-konfigurasi pada tahap pembangunan.

Tidak peduli seberapa kompleks sistem algoritma tradisional, ia hanya bisa menjalankan logika yang telah ditetapkan untuk pola yang dipersiapkan saat riset dan pengembangan. Sistem seperti itu perlu mengonfigurasi parser antarmuka yang sudah diprediksi untuk setiap jenis protokol, menetapkan logika evaluasi yang telah ditentukan sebelumnya untuk mengubah status kontrak menjadi makna ekonomi, menentukan aturan penilaian kredit dan standar dengan jelas, dan semua cabang keputusan harus ditulis sebagai aturan hard-coded (apa pun seberapa dinamis atau fleksibel algoritmanya). Begitu muncul kondisi yang tidak sesuai dengan pola yang diprediksi, sistem akan melewati skenario tersebut atau langsung gagal berjalan. Sistem tidak dapat melakukan penalaran untuk skenario asing; ia hanya dapat memeriksa apakah skenario saat ini cocok dengan template yang diketahui.

Seperti perangkat mekanis otomatis “bebek pencerna” ini, ia dapat meniru perilaku yang tampak realistis, tetapi setiap gerakan telah ditetapkan sebelumnya. (《Scientific American》，Januari 1899)__

Ketika algoritma tradisional memindai pasar pinjam-meminjam baru, ia dapat mengidentifikasi kontrak yang menerbitkan peristiwa yang familiar atau yang sesuai dengan pola pabrik yang sudah dikenal. Namun jika muncul komponen dasar pinjam-meminjam baru dengan antarmuka yang asing, sistem tidak mampu mengevaluasinya. Diperlukan pengecekan manual terhadap kontrak, memahami mekanisme operasinya, menentukan apakah itu termasuk dalam kumpulan peluang, lalu menuliskan logika integrasi. Baru setelah langkah-langkah itu selesai, algoritma dapat berinteraksi dengannya. Manusia bertugas menafsirkan, sementara algoritma bertugas mengeksekusi. Sistem agen berbasis model dasar memecah batas itu. Mereka dapat mencapai ini melalui kemampuan penalaran yang dipelajari:

• Menafsirkan tujuan yang ambigu atau tidak ditentukan dengan jelas. Instruksi seperti “memaksimalkan pendapatan sambil menghindari risiko berlebihan” perlu ditafsirkan: seberapa besar yang disebut berlebihan? Bagaimana menyeimbangkan pendapatan dan risiko? Algoritma tradisional perlu mendefinisikan kondisi-kondisi tersebut secara presisi terlebih dahulu, sedangkan model dasar mampu menafsirkan niat, membuat penilaian, dan mengoptimalkan pemahamannya sendiri berdasarkan umpan balik.

• Generalisasi dan adaptasi terhadap antarmuka baru. Agen dapat membaca kode kontrak yang asing, mem-parsing dokumentasi, atau memeriksa antarmuka biner aplikasi (ABI) yang belum pernah terlihat, lalu menalar fungsi ekonomi sistem tersebut. Ia tidak perlu membangun parser untuk setiap jenis protokol secara terpisah sebelumnya. Saat ini kemampuan ini masih belum sempurna; agen bisa saja salah mengira, tetapi ia tetap dapat mencoba berinteraksi dengan sistem yang tidak dipra-prediksi pada tahap pengembangan.

• Penalaran tingkat kepercayaan dan kesesuaian (normativitas) di bawah ketidakpastian. Ketika sinyal kepercayaan samar atau tidak lengkap, model dasar dapat melakukan penilaian secara probabilistik, bukan sekadar menerapkan aturan biner. Apakah kontrak pintar ini versi resmi? Dengan bukti yang ada, apakah token ini kemungkinan besar sah? Algoritma tradisional hanya punya dua keadaan: “ada aturan” atau “tidak ada aturan”, sementara agen dapat menalar berdasarkan tingkat keyakinan.

• Menafsirkan kesalahan dan melakukan penyesuaian adaptif. Saat terjadi situasi yang tidak terduga (misalnya transaksi gagal, output tidak sesuai dengan harapan, status berubah antara simulasi dan eksekusi), agen dapat menyimpulkan penyebab masalah dan memutuskan cara menanganinya. Sebaliknya, algoritma tradisional hanya menjalankan kode penanganan pengecualian dan membagi alur untuk kasus abnormal, bukan menafsirkan pengecualian.

Kemampuan-kemampuan ini memang ada, tetapi saat ini masih belum sempurna. Model dasar dapat menghasilkan halusinasi, salah membaca informasi, dan membuat penilaian yang salah namun tampak sangat yakin. Di lingkungan yang adversarial dan melibatkan dana (yakni kode dapat dikendalikan atau menerima aset), “mencoba berinteraksi dengan sistem yang tidak dipra-prediksi” dapat berarti kerugian langsung. Poin inti artikel ini bukan bahwa agen saat ini sudah dapat menyelesaikan fungsi-fungsi tersebut secara andal, melainkan bahwa mereka dapat mencoba dengan cara yang tidak dapat dilakukan oleh sistem tradisional; dan infrastruktur di masa depan diharapkan membuat upaya tersebut lebih aman dan lebih andal. Memperlakukan keduanya sebagai spektrum kontinu, bukan kategori absolut, akan lebih mudah dipahami: sebagian sistem tradisional telah menyerap penalaran berbasis pembelajaran, dan sebagian agen juga mungkin bergantung pada aturan hard-coded pada jalur-jalur penting. Perbedaannya bersifat arah, bukan pertentangan biner. Sistem agen akan memindahkan lebih banyak pekerjaan interpretasi, evaluasi, dan adaptasi ke penalaran saat runtime, bukan menyiapkannya pada tahap pengembangan. Ini berkaitan erat dengan argumen hambatan sebelumnya, karena yang dicoba dilakukan oleh agen adalah persis hal yang sepenuhnya dihindari oleh algoritma tradisional. Algoritma tradisional menghindari biaya penemuan dengan cara menyaring kumpulan kontrak secara manual pada tahap pengembangan; menghindari biaya lapisan kontrol dengan memanfaatkan whitelist yang dipelihara oleh operator; menghindari biaya data dengan menyiapkan parser untuk protokol yang sudah dikenal; dan menghindari biaya eksekusi dengan menjalankan dalam batas keamanan yang sudah diprediksi. Manusia menyelesaikan pekerjaan semantik, kepercayaan, dan tingkat strategi terlebih dahulu, sementara algoritma hanya mengeksekusi di dalam batas yang telah digariskan. Versi awal alur operasi agen on-chain mungkin melanjutkan pola ini, tetapi logika intinya adalah memindahkan penemuan, penilaian kepercayaan, dan evaluasi strategi ke penalaran runtime, bukan memprakonfigurasinya pada tahap pengembangan.

Agen mungkin mencoba menemukan dan mengevaluasi peluang yang asing, menilai kepatuhan (spec) kontrak tanpa aturan hard-coded, mem-parse status heterogen tanpa parser yang sudah dipasang sebelumnya, serta mengeksekusi strategi untuk tujuan yang mungkin ambigu. Dan justru pada tahapan-tahapan inilah kelemahan infrastruktur mulai menonjol. Hambatan ada bukan karena agen melakukan hal yang sama dengan algoritma namun menjadi lebih sulit, melainkan karena mereka mencoba melakukan hal yang benar-benar berbeda: beroperasi dalam ruang perilaku yang terbuka dan dinamis untuk interpretasi, bukan dalam ruang tertutup yang terintegrasi sebelumnya dan tetap.

Kekusutan di titik gesek (Merosotan/floor)

Secara struktural, kontradiksi ini bukan berasal dari kekurangan pada konsensus blockchain, melainkan dari cara evolusi “tumpukan” (stack) interaksi yang dibangun di atasnya.

Blockchain menjamin transisi status deterministik, konsensus terhadap status akhir, dan determinisme akhir. Tetapi ia tidak mengenkode interpretasi ekonomi, validasi niat, atau pelacakan tujuan dalam level protokol. Tanggung jawab itu selama ini dipikul oleh frontend, wallet, indexer, dan lapisan koordinasi off-chain lainnya, dan dalam prosesnya selalu ada partisipasi manusia.

Pola interaksi arus utama juga mencerminkan desain ini, bahkan untuk peserta profesional sekalipun: pengguna biasa menafsirkan status melalui panel, memilih operasi melalui antarmuka, menandatangani transaksi melalui wallet, bukan memverifikasi hasil secara formal; lembaga trading algoritmik mewujudkan otomatisasi eksekusi, tetapi tetap bergantung pada penyaringan manual kumpulan protokol, memverifikasi kondisi abnormal, serta memperbarui logika integrasi saat terjadi perubahan pada antarmuka. Dalam dua skenario ini, protokol hanya menjamin kebenaran eksekusi, sedangkan interpretasi niat, penanganan pengecualian, dan adaptasi ke peluang baru tetap dikerjakan oleh manusia.

Sistem agen justru mengompresi atau bahkan menghilangkan pembagian kerja ini. Mereka harus secara pemrograman merekonstruksi status yang bermakna ekonomi, menilai apakah tujuan bergerak ke arah yang benar, dan memverifikasi hasilnya di luar sekadar menuliskan transaksi sederhana ke rantai. Beban ini menjadi sangat menonjol di blockchain karena agen berjalan dalam lingkungan yang terbuka, adversarial, dan berubah cepat: kontrak, aset, dan jalur eksekusi baru dapat muncul tanpa audit terdesentralisasi. Protokol hanya menjamin eksekusi transaksi yang benar, tidak menjamin bahwa status ekonomi mudah ditafsirkan, kontrak adalah versi resmi, jalur eksekusi sesuai dengan niat pengguna, atau bahwa peluang terkait dapat ditemukan secara programatik.

Bab-bab berikutnya akan menganalisis hambatan-hambatan semacam ini di setiap tahap dari siklus operasi agen: menemukan kontrak dan peluang yang ada, memverifikasi legalitasnya, mendapatkan status yang bermakna ekonomi, serta mengeksekusikan berdasarkan tujuan.

Biaya penemuan

Biaya penemuan muncul karena ruang perilaku DeFi (keuangan terdesentralisasi) terus meluas dalam lingkungan yang terbuka dan tanpa izin, sementara relevansi dan legalitas perlu disaring oleh manusia melalui lapisan sosial on-chain, pasar, dan alat. Protokol baru disaring melalui pengumuman dan rilis riset, sekaligus disaring oleh lapisan integrasi seperti integrasi di frontend, daftar token, platform analitik, dan pembentukan likuiditas. Seiring waktu, sinyal-sinyal ini umumnya membentuk seperangkat kriteria penilaian yang dapat dioperasikan untuk mengidentifikasi bagian dari ruang perilaku yang memiliki nilai ekonomi dan cukup tepercaya, meskipun prosesnya sering tidak formal, tidak seimbang, dan sebagian bergantung pada penyaringan oleh pihak ketiga serta manusia.

Meskipun agen dapat mengambil data yang sudah disaring dan sinyal kepercayaan, ia tidak memiliki “jalan pintas alami” ketika manusia menafsirkan sinyal-sinyal itu. Dari sudut pandang on-chain, semua kontrak yang sudah dideploy memiliki ketercapaian yang setara. Protokol yang sah, fork yang berbahaya, deployment pengujian, dan proyek yang ditinggalkan semuanya ada dalam bentuk bytecode yang dapat dipanggil. On-chain tidak menandai mana yang penting dan mana yang aman.

Dari sudut pandang on-chain, semua kontrak yang sudah dideploy memiliki ketercapaian yang sama. Kontrak protokol yang sah, kontrak fork berbahaya, kontrak deployment pengujian, serta proyek yang ditinggalkan semuanya disajikan dalam bentuk bytecode yang dapat dipanggil.

Karena itu, agen harus membangun mekanisme penemuan sendiri: memindai peristiwa deployment, mengenali pola antarmuka, melacak kontrak pabrik (kontrak yang secara programatik mendeploy kontrak lainnya), serta memantau pembentukan likuiditas untuk menilai kontrak mana yang harus dimasukkan ke dalam ruang keputusan. Proses ini bukan hanya mencari kontrak, melainkan menilai apakah kontrak tersebut layak masuk ke ruang perilaku agen.

Mengidentifikasi kontrak kandidat hanyalah langkah pertama. Setelah lolos penyaringan penemuan awal, kontrak masih perlu melewati verifikasi normatif dan keaslian yang dibahas pada bagian berikutnya. Agen harus memastikan kontrak yang ditemukan konsisten dengan klaimnya sebelum memasukkannya ke dalam ruang keputusan.

Penemuan yang dibatasi oleh strategi berbeda dari penemuan terbuka

Biaya penemuan tidak merujuk pada mendeteksi deployment baru. Sistem algoritma yang matang sudah bisa melakukan itu dalam batas strategi mereka sendiri. Misalnya, searcher yang memantau event pabrik Uniswap dan otomatis memasukkan pool likuiditas baru adalah bentuk “penemuan dinamis”. Hambatan muncul pada dua tingkat lebih tinggi: menilai apakah kontrak yang ditemukan itu legal (masalah normativitas yang akan dibahas pada bagian berikutnya); serta menilai apakah ia melayani tujuan terbuka, bukan hanya menyesuaikan dengan tipe strategi yang diprediksi.

Logika penemuan searcher sangat terikat dengan strateginya: ia tahu antarmuka seperti apa yang harus dicari karena strateginya sudah ditetapkan terlebih dahulu. Sementara agen yang menjalankan tugas lebih luas seperti “peluang dengan penyesuaian risiko optimal setelah mempertimbangkan risiko” tidak bisa hanya mengandalkan filter yang diturunkan dari strategi. Ia harus menilai terhadap tujuan itu sendiri peluang yang baru ditemui: ini memerlukan parsing antarmuka yang asing, menyimpulkan fungsi ekonomi, dan menentukan apakah peluang tersebut harus dimasukkan ke dalam ruang keputusan. Bagian ini termasuk masalah otonomi umum, tetapi blockchain memperumitnya: kode yang asing dapat dieksekusi langsung, menampung dana, dan sinyal bawaan protokol saja tidak cukup untuk mengklasifikasikannya.

Gesekan pada lapisan kontrol

Biaya pada lapisan kontrol muncul karena identitas dan legalitas biasanya ditentukan di luar protokol melalui penyaringan, tata kelola, dokumentasi, antarmuka, dan penilaian operator. Dalam banyak alur kerja yang ada saat ini, kerja manusia masih menjadi bagian penting dari proses penetapan keputusan. Blockchain menjamin eksekusi deterministik dan determinasi akhir, tetapi tidak menjamin bahwa pemanggil sedang berinteraksi dengan kontrak target yang benar. Penetapan niat di-outsourcing ke konteks sosial, situs web, dan penyaringan manusia.

Dalam alur saat ini, manusia menjadikan lapisan kepercayaan web sebagai alat validasi informal: melalui platform agregator seperti DeFiLlama atau akun sosial terverifikasi proyek, mereka menemukan domain resmi, lalu menganggap situs tersebut sebagai pemetaan resmi antara konsep manusia dan alamat kontrak. Frontend kemudian akan mengenkode seperangkat sumber kebenaran yang valid, menandai alamat mana yang resmi, token apa yang digunakan, serta pintu masuk mana yang aman.

1789 Mechanical Turk: sebuah mesin bermain catur yang terlihat seperti berjalan secara mandiri, tetapi sebenarnya bergantung pada seorang operator manusia yang disembunyikan. (Perpustakaan Universitas Humboldt)

Agen secara default tidak menafsirkan merek, sinyal sosial yang terverifikasi, atau “ke-resmian” melalui konteks sosial. Kita bisa memberi agen input hasil penyaringan yang berasal dari sinyal-sinyal tersebut, tetapi untuk mengubahnya menjadi asumsi kepercayaan yang stabil dan dapat dieksekusi oleh mesin, perlu definisi registri, aturan strategi, atau logika verifikasi yang jelas. Operator dapat mengonfigurasi agen dengan whitelist pilihan, alamat terverifikasi, dan kebijakan kepercayaan. Masalahnya bukan karena konteks sosial sama sekali tidak dapat diakses, melainkan karena mempertahankan terus lapisan perlindungan itu dalam ruang perilaku yang berkembang secara dinamis menghasilkan beban operasional yang sangat besar, dan ketika lapisan perlindungan itu hilang atau tidak sempurna, agen kehilangan mekanisme verifikasi cadangan yang secara naluriah digunakan oleh manusia.

Dampak praktis dari kurangnya kemampuan penilaian kepercayaan itu sudah muncul dalam sistem yang digerakkan oleh agen on-chain. Influencer kripto dan YouTuber Orangie pernah mengalami kasus ketika agen memasukkan dana ke kontrak honeypot. Dalam satu peristiwa lain, agen bernama Lobstar Wilde karena gangguan status atau konteks, salah menafsirkan status alamat, lalu memindahkan saldo besar token ke “alamat meminta sedekah” di internet. Kasus-kasus ini bukan bukti inti artikel, tetapi secara intuitif menunjukkan bahwa kesalahan pada penilaian kepercayaan, interpretasi status, dan strategi eksekusi secara langsung dapat menyebabkan kerugian dana.

Identifikasi kontrak resmi bukan fitur asli protokol

Masalahnya bukan karena kontrak sulit ditemukan, melainkan karena di on-chain umumnya tidak ada konsep asli “ini adalah kontrak resmi aplikasi X”. Kekurangan ini sebagian tentu merupakan karakteristik sistem tanpa izin, bukan kekeliruan desain, namun tetap menghadirkan masalah koordinasi bagi sistem otonom. Sebagian masalah ini berasal dari arsitektur sistem terbuka dengan identitas normatif yang lemah, sebagian lainnya berasal dari registri, standar, dan mekanisme distribusi kepercayaan yang masih belum matang. Jika sebuah agen ingin berinteraksi dengan Aave v3, ia harus menentukan alamat mana yang versi resminya (pool dana, configurator, penyedia data, dll.), serta apakah alamat tersebut merupakan kontrak yang tidak dapat diubah, kontrak upgradeable yang dapat di-proxy, atau berada dalam status menunggu eksekusi dari perubahan proposal tata kelola.

Manusia memecahkan masalah ini melalui dokumentasi, antarmuka frontend, dan media sosial; sementara agen harus memverifikasi informasi berikut untuk menentukan:

• Mode proxy dan arah kontrak implementasi

• Hak administrasi dan kontrak time-lock

• Modul pembaruan parameter yang dikendalikan tata kelola

• Kecocokan bytecode / application binary interface (ABI) di antara kontrak deployment yang dikenal

Ketika tidak ada registri resmi, “ke-resmian” berubah menjadi masalah penalaran. Ini berarti agen tidak dapat memperlakukan alamat kontrak sebagai konfigurasi statis. Mereka harus:

1. terus memelihara whitelist yang sudah tervalidasi, atau
2. menurunkan kembali spesifikasi kontrak melalui pemeriksaan proxy dan pemantauan tata kelola saat runtime, atau
3. menanggung risiko berinteraksi dengan kontrak yang dibuang, diserang, atau dipalsukan.

Dalam perangkat lunak dan infrastruktur pasar tradisional, identitas layanan biasanya diikat oleh ruang nama, kredensial, dan kontrol akses yang dipelihara oleh institusi. Sebaliknya, di on-chain, sebuah kontrak mungkin dapat dipanggil dan fungsinya berjalan, tetapi dari sudut pandang pemanggil, kontrak tersebut tidak resmi secara ekonomi atau bisnis.

Masalah keaslian token dan metadata adalah hal yang sama secara esensial

Token tampaknya membawa informasi deskriptif sendiri, tetapi metadata-nya tidak memiliki otoritas; metadata hanya berupa data byte yang dikembalikan oleh kode kontrak. Contoh tipikal adalah Wrapped Ether (WETH). Di antara kontrak WETH yang digunakan secara luas, dijelaskan secara jelas:

Informasi ini tampak mewakili identitas, padahal tidak. Kontrak mana pun dapat mengembalikan hal berikut:

• symbol() = “WETH”

• decimals() = 18

• name() = “Wrapped Ether”

dan mengimplementasikan sepenuhnya antarmuka standar token ERC-20 yang sama. name(), symbol(), dan decimals() hanyalah fungsi publik read-only yang isinya sepenuhnya ditetapkan oleh pihak yang melakukan deployment. Faktanya, di Ethereum sudah ada hampir 200 jenis token, semuanya bernama “Wrapped Ether”, simbolnya semuanya “WETH”, dan presisinya semuanya 18 desimal. Jika Anda tidak memeriksa CoinGecko atau Etherscan, dapatkah Anda membedakan mana “WETH” yang resmi? (Jawabannya adalah item ke-78 dalam daftar)

Di Ethereum ada hampir 200 token dengan nama “Wrapped Ether” dan simbol “WETH”. Tanpa bantuan platform pihak ketiga, bisakah Anda menentukan mana yang WETH asli?

Inilah situasi yang dihadapi oleh agen. Blockchain tidak memvalidasi keunikan, tidak membandingkan terhadap registri mana pun, dan tidak peduli. Anda hari ini dapat mendeploy 500 kontrak; semuanya akan mengembalikan metadata yang identik. Di on-chain juga ada beberapa metode penilaian berbasis pengalaman (misalnya membandingkan saldo ETH dengan total supply, memeriksa kedalaman likuiditas di DEX utama, memverifikasi apakah ia tercantum sebagai aset jaminan dalam protokol pinjam-meminjam), tetapi tidak ada metode yang dapat memberikan bukti mutlak yang pasti. Setiap metode bergantung pada asumsi ambang (misalnya tidak ada yang bisa memalsukan pasangan likuiditas dengan skala miliaran), atau secara rekursif membutuhkan verifikasi dulu terhadap spesifikasi kontrak lain.

Seperti labirin, mengenali “jalur yang benar” di on-chain membutuhkan panduan eksternal; tidak ada sinyal standar yang disediakan. (Museum dan Galeri Birmingham)

Itulah alasan keberadaan daftar token (token list) dan registri sebagai lapisan penyaringan off-chain. Mereka menyediakan mekanisme untuk memetakan konsep “WETH” ke alamat tertentu—itulah sebabnya wallet dan frontend memelihara whitelist atau bergantung pada agregator yang tepercaya. Bagi agen, masalah utamanya bukan hanya metadata yang tidak dapat diandalkan, melainkan bahwa identitas normatif biasanya ditetapkan oleh lapisan sosial atau institusi, bukan oleh protokol secara native. Satu-satunya pengenal unik yang dapat diandalkan di on-chain adalah alamat kontrak; namun untuk memetakan niat yang mudah dipahami manusia (misalnya “tukar menjadi USDC”) ke alamat yang benar, tetap sangat bergantung pada penyaringan non-native, registri, whitelist, atau lapisan kepercayaan lainnya.

Gesekan data

Sebuah agen yang mengoptimalkan antar banyak protokol DeFi perlu mengabstraksikan setiap peluang menjadi objek ekonomi yang seragam: imbal hasil, kedalaman likuiditas, parameter risiko, struktur biaya (fee), sumber oracle, dan seterusnya. Dari satu sudut pandang, ini adalah masalah integrasi sistem yang umum. Tetapi di blockchain, karena heterogenitas protokol, risiko pendanaan langsung, penggabungan status lintas pemanggilan, serta ketiadaan “economic schema” yang seragam di lapisan dasar, beban ini menjadi jauh lebih besar. Dan semua itulah informasi yang diperlukan untuk membandingkan peluang, menyusun simulasi konfigurasi, serta memantau risiko.

Pada lapisan protokol, blockchain biasanya tidak mengekspos objek ekonomi yang distandardisasi; ia hanya mengekspos slot penyimpanan, log peristiwa, dan nilai yang dikembalikan oleh fungsi. Objek ekonomi harus disimpulkan atau direkonstruksi dari sana. Protokol menjamin bahwa nilai yang dikembalikan oleh pemanggilan kontrak adalah status yang benar, tetapi tidak menjamin bahwa nilai tersebut dapat dengan jelas dipetakan ke konsep ekonomi yang dapat dipahami, dan juga tidak menjamin bahwa konsep yang sama dapat diakses melalui antarmuka yang konsisten antar protokol.

Karena itu, abstraksi seperti pasar, posisi, koefisien kesehatan, dan sebagainya bukan komponen asli protokol; ia direkonstruksi di luar rantai oleh indexer, platform analitik, frontend, dan API untuk menormalisasi status protokol yang heterogen menjadi abstraksi yang dapat digunakan. Pengguna manusia biasanya hanya melihat lapisan data yang sudah dinormalisasi ini, dan agen juga dapat memakainya; tetapi dengan demikian ia juga mewarisi skema dari pihak ketiga, asumsi kepercayaan, dan latensi. Jika tidak, agen harus membangun ulang logika abstraksi tersebut.

Masalah ini makin diperburuk di berbagai jenis protokol. Harga token share di vault, rasio jaminan di pasar pinjam-meminjam, kedalaman likuiditas pool DEX, tingkat imbalan staking pada kontrak staking, semuanya adalah indikator dasar yang bermakna ekonomi, tetapi tidak ada satu pun yang diekspos melalui antarmuka distandardisasi. Setiap ekosistem protokol memiliki cara baca, format struct, dan kesepakatan unitnya sendiri; bahkan untuk kategori yang sama, implementasinya tetap berbeda.

Pasar pinjam-meminjam: contoh khas pembacaan yang terfragmentasi

Pasar pinjam-meminjam memperlihatkan masalah ini dengan jelas. Konsep ekonomi cenderung mirip dan umum, misalnya likuiditas supply dan pinjaman, suku bunga, koefisien jaminan, batas kredit (limit) maksimum, ambang likuidasi, dan sebagainya, tetapi jalur pengambilan datanya benar-benar berbeda.

Sebagai contoh Aave v3, enumerasi pasar dan pembacaan status aset cadangan (reserve assets) adalah langkah yang terpisah, dengan alur tipikal seperti berikut:

Dengan cara berikut untuk mencantumkan aset cadangan

Fungsi ini akan mengembalikan sebuah array alamat token.

Untuk setiap aset, dengan cara berikut untuk mendapatkan data dasar likuiditas dan suku bunga:

Pemanggilan ini mengembalikan sebuah struct, yang dalam satu kali panggilan saja dapat memperoleh data yang mencakup total likuiditas, indeks suku bunga, dan identifier konfigurasi, misalnya:

Sebaliknya, di Compound v3 (Comet), setiap deployment hanya terkait dengan satu pasar (misalnya USDC, USDT, ETH, dll.), dan tidak ada struct cadangan yang terintegrasi. Karena itu, perlu beberapa kali pemanggilan fungsi untuk menyusun snapshot pasar yang lengkap:

Utilization rate dasar

Total

Suku bunga

Konfigurasi aset jaminan

Parameter konfigurasi global

Setiap pemanggilan hanya mengembalikan fragmen status ekonomi yang berbeda. “Pasar” bukan objek kelas satu (first-class citizen); ia adalah struktur inferensial yang dirangkai sendiri oleh pihak yang memanggil.

Dari sudut pandang agen, kedua protokol ini sama-sama termasuk pasar pinjam-meminjam. Tetapi dari sudut pandang integrasi, keduanya memiliki sistem pengambilan data yang benar-benar berbeda. Tidak ada struktur data universal seperti berikut:

Sebaliknya, agen harus menggunakan cara enumerasi aset yang berbeda untuk tiap protokol, menggabungkan data status melalui banyak pemanggilan, menyatukan unit pengukuran dan aturan konversi, serta menyelaraskan perbedaan antara nilai yang diturunkan dan nilai dasar yang diekspos secara langsung.

Fragmentasi memunculkan risiko latensi dan konsistensi

Selain perbedaan struktur, fragmentasi juga memunculkan risiko latensi dan konsistensi. Karena status ekonomi tidak diekspos sebagai objek pasar atomik tunggal, agen harus melakukan banyak panggilan proses jarak jauh (RPC) ke berbagai kontrak untuk merekonstruksi satu snapshot status. Setiap tambahan panggilan meningkatkan latensi, memicu probabilitas rate-limit pada antarmuka, serta meningkatkan risiko ketidakkonsistenan blok. Dalam kondisi volatilitas pasar, saat perhitungan suku bunga sudah selesai, rasio pemanfaatan dana mungkin sudah berubah; jika tidak secara eksplisit mengunci tinggi blok (block height), parameter konfigurasi dan total likuiditas mungkin berasal dari blok yang berbeda. Pengguna manusia mengurangi masalah ini secara implisit melalui layer cache di frontend dan backend agregasi; sementara agen yang memanggil RPC mentah harus secara eksplisit menangani sinkronisasi data, permintaan batch, dan konsistensi waktu. Karena itu, pengambilan data yang tidak distandardisasi bukan hanya menyulitkan integrasi; ia juga menjadi batasan terhadap kinerja, mekanisme sinkronisasi, dan kebenaran eksekusi.

Ketiadaan spesifikasi baku untuk pengambilan data ekonomi berarti bahwa walaupun protokol-protokol berbeda mengimplementasikan fungsi finansial dasar yang hampir sama, cara mereka mengekspos status tetap khusus kontrak dan bergantung pada logika komposisi. Perbedaan struktur inilah penyebab utama gesekan data.

Potensi ketidakcocokan arus data

Akses terhadap status ekonomi di blockchain pada dasarnya adalah pola pull (tarik). Bahkan jika sinyal eksekusi bisa di-streaming (push), sistem eksternal tetap perlu secara aktif menanyakan node untuk status yang diperlukan, bukan menerima pembaruan terus-menerus yang terstruktur. Pola ini mencerminkan fungsi inti blockchain — verifikasi sesuai kebutuhan, bukan memelihara tampilan status aplikasi yang terus-menerus.

Komponen dasar untuk pola push juga ada di on-chain. Langganan WebSocket dapat mendorong secara real-time blok baru dan log peristiwa, tetapi ini tidak menyertakan status penyimpanan yang memuat sebagian besar makna ekonomi, kecuali protokol secara sengaja memilih untuk redundan mencatatnya sebagai log. Agen tidak bisa langsung mengetahui pemanfaatan pasar pinjam-meminjam, cadangan pool, atau koefisien kesehatan posisi melalui langganan on-chain. Nilai-nilai ini tersimpan dalam ruang penyimpanan kontrak, dan sebagian besar protokol tidak menyediakan mekanisme native untuk mendorong perubahan penyimpanan tersebut ke downstream. Cara paling masuk akal saat ini adalah berlangganan kepala blok baru (block header) lalu membaca ulang status penyimpanan pada setiap blok — sekalipun dipicu oleh event streaming, akses status pada dasarnya tetap pola pull. Log hanya memberi sinyal bahwa data mungkin berubah, tetapi tidak mengenkode status ekonomi final; rekonstruksi status tersebut tetap memerlukan pembacaan eksplisit dan akses ke status historis.

Sistem agen justru lebih cocok untuk arus data yang berlawanan arah (push). Agen tidak perlu polling perubahan status dari ratusan kontrak; ia dapat menerima pembaruan status yang terstruktur dan sudah dipra-kalkulasi, lalu langsung mendorongnya ke lingkungan runtime mereka (misalnya pembaruan pemanfaatan, koefisien kesehatan, atau perubahan posisi). Arsitektur push dapat mengurangi query yang redundan, menurunkan latensi antara perubahan status dan persepsi agen, serta memungkinkan lapisan tengah membungkus status sebagai pembaruan yang maknanya jelas, alih-alih membiarkan agen menafsirkan makna dari penyimpanan mentah.

Perubahan pola ini tidak mudah. Ia memerlukan infrastruktur subscription, logika penyaringan relevansi, dan spesifikasi peristiwa ekonomi yang mengubah perubahan penyimpanan menjadi tindakan yang dapat dieksekusi oleh agen. Namun ketika agen menjadi peserta yang selalu online, bukan pihak yang sesekali melakukan query, inefisiensi pola pull — rate-limit antarmuka, biaya sinkronisasi, dan query berulang oleh agen berbeda — akan makin menjadi masalah. Infrastruktur yang menganggap agen sebagai konsumen berkelanjutan ketimbang klien sesekali, mungkin lebih sesuai bagi cara kerja sistem otonom.

Apakah infrastruktur push benar-benar lebih unggul masih belum ada kesimpulan. Aliran data perubahan status penuh akan menimbulkan masalah penyaringan; agen tetap harus memutuskan informasi mana yang relevan, sehingga logika pull bisa muncul kembali di lapisan lain. Masalahnya bukan bahwa pola pull itu sendiri salah, melainkan arsitektur yang ada saat desainnya belum mempertimbangkan penggunaan mesin yang persisten. Seiring skala penggunaan agen membesar, opsi alternatif layak dieksplorasi.

Gesekan eksekusi

Gesekan eksekusi muncul karena banyak lapisan interaksi saat ini mengemas konversi niat, audit transaksi, dan validasi hasil ke dalam alur kerja yang berpusat pada frontend, wallet, dan pengawasan manusia. Dalam skenario pengguna biasa dan keputusan berbasis subyektif, pengawasan biasanya dilakukan oleh manusia. Namun bagi sistem otonom, fungsi-fungsi tersebut harus diformalkan dan diimplementasikan langsung. Blockchain dapat menjamin eksekusi deterministik berdasarkan logika kontrak, tetapi tidak menjamin bahwa transaksi sesuai dengan niat pengguna, memenuhi batasan risiko, atau menghasilkan outcome ekonomi yang diharapkan. Dalam alur yang ada sekarang, frontend dan manusia mengisi celah tersebut.

Frontend menyusun urutan operasi (tukar, otorisasi, setoran, pinjam), wallet menyediakan checkpoint terakhir “audit dan kirim”, sementara pengguna atau operator biasanya membuat penilaian strategi secara tidak formal pada langkah terakhir. Mereka sering menilai apakah transaksi aman dan apakah hasil kuotasi dapat diterima dalam kondisi informasi yang tidak lengkap. Jika transaksi gagal atau hasil tidak terduga muncul, pengguna akan mencoba lagi, menyesuaikan slippage, mengubah rute, atau bahkan menyerah dan membatalkan operasi. Sistem agen menghilangkan manusia dari siklus eksekusi ini, sehingga sistem harus menggantikan tiga fungsi manusia tersebut dengan logika native mesin:

1. Kompilasi niat. Tujuan manusia seperti “mengonfigurasi stablecoin saya ke jalur imbal hasil terbaik setelah penyesuaian risiko” harus dikompilasi menjadi rencana tindakan yang spesifik: memilih protokol mana, pasar mana, jalur token mana, skala operasi, metode otorisasi, serta urutan eksekusi. Bagi manusia, proses ini terselesaikan secara implisit oleh frontend; bagi agen, proses ini harus direalisasikan secara formal.

2. Eksekusi strategi. Menekan “kirim transaksi” bukan hanya aksi tanda tangan, tetapi juga validasi implisit bahwa transaksi sesuai dengan batasan: toleransi slippage, batas leverage, koefisien kesehatan minimum, kontrak dalam whitelist, atau “melarang kontrak yang bisa di-upgrade”. Agen perlu mengenkode batasan strategi eksplisit menjadi aturan yang dapat diverifikasi oleh mesin:

Sistem eksekusi harus memverifikasi bahwa graf relasi pemanggilan yang akan dieksekusi sesuai dengan aturan-aturan tersebut sebelum menyiarkan transaksi.

1. Validasi hasil. Meletakkan transaksi di rantai tidak sama dengan menyelesaikan tugas. Satu transaksi dapat berhasil dieksekusi tetapi tetap tidak mencapai tujuan: slippage mungkin melebihi toleransi, batas kuota dapat mencegah tercapainya skala posisi target, atau suku bunga dapat berubah di antara simulasi dan eksekusi on-chain. Manusia melakukan validasi informal setelah transaksi melalui antarmuka frontend; sementara agen harus menilai kondisi status setelah eksekusi secara programatik:

Ini menuntut validasi penyelesaian (completion) yang lebih tinggi: tidak cukup hanya memastikan transaksi berhasil diposting di rantai. Arsitektur yang berpusat pada niat mungkin menyediakan solusi sebagian, dengan memindahkan lebih banyak beban “bagaimana cara mengeksekusi” dari agen ke pemecah (solver) yang profesional. Agen tidak lagi menyiarkan data pemanggilan mentah, melainkan menyiarkan “niat eksekusi” yang sudah ditandatangani dan menyertakan constraint berbasis hasil; mekanisme solver atau protokol harus memenuhi constraint tersebut agar eksekusi dianggap valid.

Workflow multi-langkah dan model kegagalan

Sebagian besar proses eksekusi DeFi secara alami bersifat multi-langkah. Operasi konfigurasi untuk memperoleh pendapatan mungkin perlu menyelesaikan: otorisasi → pertukaran → setoran → pinjam → staking. Beberapa langkah dapat berupa transaksi terpisah, sementara yang lain bisa dijalankan melalui pemanggilan batch atau pengemasan oleh router contract. Manusia dapat menerima bahwa proses tidak sepenuhnya selesai dan kembali melanjutkan lewat antarmuka; namun agen membutuhkan orkestrasi proses yang deterministik: jika salah satu langkah gagal, agen harus memutuskan apakah akan melakukan retry, mengganti rute, melakukan rollback, atau menghentikan eksekusi.

Hal ini melahirkan model kegagalan baru yang biasanya tertutup dalam alur operasi manusia:

• Perbedaan status antara keputusan dan penulisan di rantai: selama simulasi eksekusi dan saat transaksi benar-benar dieksekusi di rantai, suku bunga, rasio pemanfaatan, atau likuiditas dapat berubah. Manusia dapat menerima fluktuasi ini, sedangkan agen harus menetapkan rentang yang dapat diterima dan menegakkannya secara ketat.

• Eksekusi non-atomik dan eksekusi sebagian: sebagian operasi mungkin dieksekusi melalui beberapa transaksi, atau hanya menghasilkan sebagian dari hasil yang diharapkan. Agen harus melacak status antara dan memastikan status final sesuai dengan tujuan.

• Risiko otorisasi limit dan persetujuan (approval): manusia biasanya menyelesaikan approval sign secara kebiasaan melalui antarmuka, sementara agen harus memasukkan cakupan otorisasi (limit, pihak pembelanja, masa berlaku) ke dalam strategi keamanan, bukan memperlakukannya hanya sebagai langkah antarmuka.

• Pemilihan jalur dan biaya eksekusi implisit: manusia mengandalkan tool routing dan konfigurasi default di antarmuka, sedangkan agen harus memodelkan risiko slippage, risiko MEV (nilai yang dapat diekstrak oleh miner), biaya Gas, dan price impact ke dalam fungsi tujuan.

Eksekusi: masalah kontrol yang native untuk mesin

Inti dari gesekan eksekusi adalah: lapisan interaksi DeFi menjadikan tanda tangan wallet manusia sebagai loop kontrol terakhir. Saat ini, validasi niat, penilaian toleransi risiko, dan pemeriksaan “apakah ini terlihat masuk akal” yang informal semuanya terkonsentrasi pada langkah ini. Setelah partisipasi manusia dihilangkan, eksekusi berubah menjadi masalah kontrol: agen harus mengubah tujuan menjadi tindakan rantai, mengeksekusi constraints strategi secara otomatis, serta memverifikasi hasil di bawah ketidakpastian. Tantangan ini ada dalam banyak sistem otonom, tetapi lingkungan blockchain jauh lebih ketat karena eksekusi melibatkan dana secara langsung, bisa memanggil kontrak asing secara komposabel, serta menghadapi perubahan status yang adversarial. Manusia menggunakan pengalaman untuk mengambil keputusan dan memperbaiki kesalahan melalui trial-and-error; sementara agen harus menyelesaikan pekerjaan serupa secara terprogram dengan kecepatan mesin, sering menghadapi ruang operasi yang berubah dinamis. Maka, anggapan bahwa agen “hanya perlu mengirim transaksi” sangat meremehkan kesulitannya. Mengirim transaksi itu sendiri adalah bagian yang mudah; yang hilang sesungguhnya adalah seluruh pekerjaan yang ditanggung antarmuka dan manusia: kompilasi niat, pengamanan, serta validasi completion terhadap tujuan.

Kesimpulan

Blockchain sejak awal tidak secara native menyediakan lapisan semantik dan lapisan koordinasi yang dibutuhkan oleh agen otonom. Tujuan desainnya adalah menjamin eksekusi deterministik dan konsensus transisi status dalam lingkungan adversarial. Lapisan interaksi yang tumbuh di atasnya selalu berfokus pada pengguna manusia: menafsirkan status melalui antarmuka, memilih operasi melalui frontend, serta memvalidasi hasil melalui audit manual.

Sistem agen membalikkan arsitektur ini. Agen menghapus manusia sebagai penafsir, pemberi persetujuan, dan verifikator dari proses, serta menuntut fungsi-fungsi tersebut untuk diubah menjadi sesuatu yang native untuk mesin. Perubahan ini memperlihatkan hambatan struktural dalam empat dimensi: penemuan, penilaian kepercayaan, pengambilan data, dan orkestrasi eksekusi. Hambatan-hambatan itu muncul bukan karena eksekusi tidak mungkin, melainkan karena pada sebagian besar skenario infrastruktur di sekitar blockchain masih secara default mengandalkan partisipasi manusia pada tahap interpretasi status dan pengiriman transaksi.

Menjembatani celah-celah itu mungkin memerlukan pembangunan infrastruktur baru pada beberapa lapisan stack teknologi: middleware yang menormalkan status ekonomi lintas protokol menjadi spesifikasi yang dapat dibaca mesin; layanan index atau ekstensi RPC yang mengekspos komponen semantik seperti posisi, koefisien kesehatan, dan kumpulan peluang alih-alih data penyimpanan mentah; registri yang menyediakan pemetaan kontrak resmi dan validasi keaslian token; serta kerangka eksekusi yang dapat mengenkode constraint strategi, menangani workflow multi-langkah, dan memverifikasi completion tujuan secara programatik. Sebagian celah berasal dari karakteristik struktural sistem tanpa izin: deployment terbuka, identitas normatif yang lemah, dan antarmuka yang heterogen; sebagian lainnya dibatasi oleh alat yang ada, standar, dan desain insentif. Namun seiring skala penggunaan agen membesar dan protokol bersaing untuk mengoptimalkan kemudahan integrasi sistem otonom, masalah-masalah ini diharapkan dapat tereduksi.

Seiring sistem otonom mulai mengelola dana, mengeksekusi strategi, dan berinteraksi langsung dengan aplikasi on-chain, asumsi arsitektur yang tertanam dalam lapisan interaksi saat ini semakin terlihat jelas. Sebagian besar gesekan yang dibahas dalam artikel ini berasal dari perkembangan alat blockchain dan pola interaksi yang berfokus pada workflow perantara manusia; sebagian lainnya adalah hasil alami dari keterbukaan, heterogenitas, dan lingkungan adversarial pada sistem tanpa izin; sementara sisanya adalah masalah umum yang dihadapi sistem otonom di lingkungan yang kompleks.

Tantangan inti bukan membuat agen menyelesaikan penandatanganan transaksi, melainkan menyediakan jalur yang dapat diandalkan: untuk menyediakan fungsi terkait semantik, kepercayaan, dan strategi yang saat ini bersama-sama diselesaikan oleh perangkat lunak dan penilaian manusia antara status blockchain mentah dan operasi nyata.