X402 Açıklaması: Yapay Zeka Ajanları için HTTP Yerel Mikro Ödemeler

X402 spesifikasyonu, standart HTTP 402 Payment Required durumunu kullanarak normal bir API çağrısını zincir üstü (on-chain) bir mikro ödemeye dönüştürür. Yapay zeka ajanları artık LLM sorguları veya veri akışları için ücretleri bir insan müdahalesi olmadan ödeyebilir; sağlayıcılar ise özel bir faturalandırma sistemi kurmaya gerek kalmadan istek başına ücret alabilir.

Yapay zeka ajanlarının neden bir ödeme protokolüne ihtiyacı var?

Otonom ajanlar; dil modellerini, web arama araçlarını ve tescilli veri kaynaklarını bir araya getirir. Her bir birleştirme bir maliyet doğurur; bir model için token başına ücretler veya bir piyasa verisi API'si için çağrı başına ücretler gibi. Günümüzün iş modelleri, abonelik hesaplarına bağlı API anahtarlarına, manuel kredi yüklemelerine veya sonradan yapılan faturalandırmaya dayanmaktadır. Bu yöntemler, otonom ajanların "insansızlık" vaadini bozar ve sağlayıcılar için operasyonel yük oluşturur.

X402 orta bir yol sunar: Diğer tüm HTTP çağrılarına benzeyen ancak halka açık bir blokzinciri üzerinde kaydedilen yerleşik bir ödeme adımı içeren bir istek-yanıt akışı. Tek gereksinim, istemcinin sunucunun belirttiği zincir üzerinde bir işlemi imzalayabilmesi ve yayınlayabilmesidir.

Detaylı X402 el sıkışması (handshake)

  1. İlk istek – Ajan, ücretli bir uç noktaya (endpoint) normal bir GET veya POST gönderir. Özel bir başlığa gerek yoktur.
  2. Sunucu 402 ile yanıt verir – Yanıt, 402 durum kodunu ve şunları listeleyen bir JSON gövdesini taşır:
    • amount – sunucunun beklediği ücret, en küçük token birimi cinsinden;
    • token – ERC-20 (veya eşdeğeri) sözleşme adresi;
    • chain – ödemenin kaydedilmesi gereken blokzinciri tanımlayıcısı;
    • isteğe bağlı nonce – yinelenen saldırıları (replay attacks) engelleyen benzersiz bir değer.
  3. İstemci ödemeyi hazırlar – Ajan, token adresini ve zinciri kendi politikasına göre (örneğin, yalnızca güvenilir zincirler) kontrol eder. Ardından, gerekli tutarı sunucu tarafından sağlanan adrese transfer eden bir işlem oluşturur, bunu özel anahtarıyla imzalar ve yayınlar.
  4. Ödeme hash'inin gönderilmesi – İşlem hash'i hazır olduğunda, istemci orijinal isteği tekrarlar; bu kez hash'i içeren bir X-Payment başlığı ekler. Veri yükü (payload) değişmeden kalır.
  5. Sunucu zincir üstünde doğrular – Sunucu, blokzincirinde tutar, token, zincir ve nonce ile eşleşen onaylanmış bir transfer olup olmadığını kontrol eder. Bir eşleşme bulursa, istenen veriyi 200 OK durumuyla döndürür.

Özel başlıkları destekleyen ve bir blokzinciri SDK'sını çağırabilen herhangi bir HTTP istemci kütüphanesi bu adımları gerçekleştirebilir. Yeni bir taşıma protokolüne veya özel bir soket katmanına gerek yoktur.

Akılda tutulması gereken ödünleşimler

  • Gecikme (Latency) – Halka açık zincir onayı gecikmeye neden olur.
  • Gas maliyetleri – Ucuz zincirler bile gas ücreti alır; 0,001 doların altındaki ödemeler ekonomik olmayabilir.
  • Karmaşıklık – Ajanlar başarısız işlemleri ve zincir yeniden düzenlemelerini (chain reorganizations) yönetmelidir; sağlam bir yeniden deneme mantığı (retry logic) şarttır.
  • Güvenlik – Nonce, yinelenen saldırıları durdurur ancak ajanların yine de özel anahtarları koruması ve bunları birbiriyle ilgisiz hizmetlerde tekrar kullanmaktan kaçınması gerekir.