Penjelasan X402: Mikropembayaran Native HTTP untuk Agen AI

Spesifikasi X402 menggunakan kembali status standar HTTP 402 Payment Required untuk mengubah panggilan API biasa menjadi mikropembayaran on-chain. Agen AI kini dapat melunasi biaya untuk kueri LLM atau feed data tanpa campur tangan manusia, dan penyedia layanan dapat menagih per permintaan tanpa harus membangun sistem penagihan (invoicing) khusus.

Mengapa agen AI membutuhkan protokol pembayaran

Agen otonom merangkai model bahasa, alat pencarian web, dan sumber data milik sendiri. Setiap rangkaian membutuhkan biaya—biaya per token untuk sebuah model atau biaya per panggilan untuk API data pasar. Model bisnis saat ini bergantung pada kunci API yang terikat pada akun langganan, pengisian ulang kredit secara manual, atau penagihan pasca-kejadian (post-hoc billing). Metode-metode tersebut melanggar janji "tanpa manusia" dari agen otonom dan menambah beban operasional bagi penyedia layanan.

X402 menawarkan jalan tengah: alur request-response yang terlihat seperti panggilan HTTP lainnya, tetapi dengan langkah pembayaran terintegrasi yang dicatat pada blockchain publik. Satu-satunya persyaratan adalah klien harus dapat menandatangani dan menyiarkan (broadcast) transaksi pada chain yang ditentukan oleh server.

Detail jabat tangan (handshake) X402

  1. Permintaan awal – Agen mengirimkan GET atau POST normal ke endpoint berbayar. Tidak diperlukan header khusus.
  2. Server membalas dengan 402 – Respons membawa status 402 dan body JSON yang mencantumkan:
    • amount – biaya yang diharapkan server, dalam unit token terkecil;
    • token – alamat kontrak ERC-20 (atau setara);
    • chain – pengenal blockchain tempat pembayaran harus dicatat;
    • nonce opsional – nilai unik untuk mencegah serangan replay (replay attacks).
  3. Klien menyiapkan pembayaran – Agen memeriksa alamat token dan chain terhadap kebijakannya (misalnya, hanya chain yang tepercaya). Agen kemudian membuat transaksi yang mentransfer jumlah yang diperlukan ke alamat yang disediakan server, menandatanganinya dengan kunci privat, dan menyiarkannya.
  4. Pengiriman hash pembayaran – Setelah hash transaksi tersedia, klien mengulangi permintaan asli, kali ini dengan menambahkan header X-Payment yang berisi hash tersebut. Payload tetap tidak berubah.
  5. Server memverifikasi on-chain – Server memeriksa blockchain untuk mencari transfer terkonfirmasi yang cocok dengan jumlah, token, chain, dan nonce. Jika ditemukan kecocokan, server mengembalikan data yang diminta dengan status 200 OK.

Library klien HTTP apa pun yang mendukung header kustom dan dapat memanggil SDK blockchain dapat melakukan langkah-langkah ini. Tidak diperlukan protokol transport baru atau lapisan socket kustom.

Pertimbangan (trade-offs) yang perlu diperhatikan

  • Latensi – Konfirmasi chain publik menambah penundaan.
  • Biaya gas – Bahkan chain murah pun mengenakan biaya gas; pembayaran di bawah $0,001 mungkin tidak ekonomis.
  • Kompleksitas – Agen harus menangani transaksi yang gagal dan reorganisasi chain; logika percobaan ulang (retry logic) yang kuat sangatlah penting.
  • Keamanan – Nonce mencegah serangan replay, tetapi agen tetap perlu melindungi kunci privat dan menghindari penggunaan kembali kunci tersebut di berbagai layanan yang tidak terkait.