Makine yerel işlemleri: mevcut durum ve eksik altyapı

Bu makaleyi okumak için 59 Dakika

Makine ödeme raylarından otonom satın alma ağlarına, "alıcıyı kim donatacak" etrafında dönen bir altyapı göçü.

Orijinal başlık: "Makine Yerel İşlemler: Mevcut Durum ve Eksik Altyapı"

Orijinal kaynak: Waterdrop Capital

Özet

Büyük modeller, soruları yanıtlayan araçlardan planlama yapabilen, araçları çağırabilen ve sonuç teslim edebilen akıllı ajanlara dönüşüyor. Aynı zamanda, stablecoin mutabakatı, HTTP yerel ödeme protokolü (http 402) ve akıllı cüzdanlar da makinelere yönelik bir ödeme altyapısı oluşturacak şekilde birleşmeye başladı. Bir programın çalışma zamanında teklif alması, yetkilendirme imzalaması ve mikro ödemeleri tamamlaması, birkaç yıl önce yalnızca bir kavramken, bugün gerçekten kullanılabilir bir teknoloji yoluna dönüşmüş durumda.

Ancak "makinenin ödeme yapabilmesi", "makinenin işlemi tamamlayabilmesi" anlamına gelmez. Bir ajan arama, veri, hesaplama gücü, içerik üretimi veya profesyonel analiz hizmetleri satın alması gerektiğinde, hâlâ uç noktaları keşfetme, teklifleri karşılaştırma, protokoller arası ödeme, bütçe kontrolü, teslimat doğrulama ve birleşik mutabakat gibi sorunlarla karşılaşır. Ödeme rayları değerin nasıl hareket edeceğini çözer, ancak talebin arzı nasıl bulacağını ve ödeme sonrasında doğru hizmetin alınıp alınmadığını otomatik olarak çözmez.

Bu, Agent Payment'ın bir sonraki aşamasında rekabet odağının artık yalnızca protokol verimliliği, mutabakat hızı veya kaç zinciri desteklediği değil, gerçek bir makine alıcı altyapısı oluşturup oluşturamayacağı olabileceği anlamına gelir. Bu makale, talep yapısı, protokol evrimi, gerçek darboğazlar ve pazar iş bölümünden yola çıkarak Agent Payment'ın neden bağımsız bir alan haline geldiğini ve ölçekli benimsemeye ne kadar uzak olduğunu, hangi kilit halkaların eksik olduğunu tartışmaya çalışmaktadır.

Giriş: Ajanlar kısıtlı bir "harcanabilir bütçe" elde ediyor

Son iki yılda ajan yeteneklerindeki değişim çok hızlı oldu. Erken dönem büyük modeller ağırlıklı olarak bilgi üretimi üstleniyordu; kullanıcı soru soruyor, model metin veriyordu. Ardından araç çağırma, modelin web sayfalarını aramasını, veritabanlarını sorgulamasını, kod çalıştırmasını ve yazılımı işletmesini mümkün kıldı. Bir adım daha ileri gidildiğinde, ajanlar hedefleri parçalamaya, plan yapmaya ve çok turlu yürütme sırasında dış sonuçlara göre eylemlerini ayarlamaya başladı.

Yürütme nesnesi ücretsiz araçlarla veya kurum içi sistemlerle sınırlı olduğunda, çağrı izinleri geliştirici tarafından önceden yapılandırılabilir. Ancak açık pazardaki yüksek kaliteli yetenekler genellikle ücretlidir: gerçek zamanlı finansal veriler işlem başına fiyatlandırılır, web kazıma kota tüketir, çıkarım ve GPU hesaplama gücü kullanım başına ücretlendirilir, video üretimi ve profesyonel veritabanlarının da belirli fiyatları vardır. Bir ajanın bir görevi bağımsız olarak tamamlaması için, kaçınılmaz olarak çalışma sürecinde alıcı konumuna geçmesi gerekir.

Geleneksel API iş modeli bu tür bir alıcı için tasarlanmamıştır. Bir kişinin önce web sitesini ziyaret etmesini, hesap açmasını, banka kartı bağlamasını, paket seçmesini, API Key'i saklamasını ve ardından anahtarı program ortamına yerleştirmesini gerektirir. Satın alma kararı ve gerçek çağrı iki farklı zaman noktasına bölünmüştür: insan, görev gerçekleşmeden önce satın almayı tamamlar; yazılım yalnızca önceden satın alınmış kotayı tüketmekle sorumludur.

Ajan ise görevi yürütmenin bir adımına gelene kadar neye ihtiyacı olduğunu bilemeyebilir. Sonunda hangi veri kaynağını çağıracağını önceden tahmin edemez ve kullanıcıdan tüm potansiyel hizmetler için tek tek hesap açmasını isteyemez. Satın alımları anlık, düşük tutarlı, çok satıcılı, yüksek frekanslı ve sonuç odaklıdır. Onun için en doğal deneyim "önce abone ol, sonra çağır" değil, "hizmeti keşfet, teklif al, ödemeyi yetkilendir, sonucu elde et"tir.

Agent Payment bu nedenle bir sohbet robotuna ödeme düğmesi eklemek değildir. Yazılımın kısıtlı harcama yetkisine sahip olmaya başlaması ve makineye ait bir satın alma süreci oluşturması anlamına gelir. İnsan hedefi, bütçeyi ve risk sınırlarını belirler; ajan bu sınırlar içinde fonları tahsis eder. Ödeme böylece bir mutabakat eyleminden ajanın karar sisteminin bir parçasına dönüşür.

1. Agent Payment neden bağımsız bir kulvar haline geliyor

1.1 Araç çağrımından ekonomik eyleme

Ajan ile sıradan otomasyon betiği arasındaki fark yalnızca akıl yürütme yeteneği değildir. Betik önceden belirlenmiş bir akışı yürütür; gerekli kaynaklar ve tedarikçiler genellikle koda yazılmıştır; ajan ise ortama göre yol seçer. Aynı araştırma görevinde önce arama sonuçlarını satın alabilir, sonuca göre bir sektör veritabanına ihtiyaç olup olmadığına karar verebilir ve son olarak çapraz doğrulama için başka bir modeli çağırabilir. Her satın alma adımı sonraki kararları değiştirir.

Bu "yürütürken satın al" modeli, ekonomik seçimi yazılımın çalışma zamanına taşır. Ajan yalnızca bir aracın kullanılabilir olup olmadığını değil, satın almaya değip değmeyeceğini de değerlendirmelidir: fiyat bütçeyi aşıyor mu, yanıt hızı görevi karşılıyor mu, geçmiş performans güvenilir mi, alternatif hizmet daha uygun mu. Geleneksel araç yönlendirme yetenek eşleşmesine odaklanırken, makine satın alımı aynı anda fiyat ve karşı taraf riskini de ele almalıdır. Bu tür işlemlerde riski üstlenen taraf ajanın kendisidir: ödeme başarılı olmuş olabilir, ancak hizmet teslim edilmemiş olabilir.

Bu nedenle Agent Payment'ın temel ihtiyacı koşulsuz otomatik ödeme değil, satın alma hakkının yazılıma kontrol edilebilir şekilde devredilmesidir. Kullanıcılar tüm cüzdanlarını ajana kolayca teslim etmezler, ancak belirli bir görev için birkaç dolarlık bütçe belirleyip birkaç sentlik satın alma yapmasına izin vermeye isteklidirler. Büyük yetkilendirme uzun vadeli güven gerektirebilir, ancak küçük yetkilendirme şimdiden gerçek değer yaratabilir.

1.2 Mikro tutarlar, yüksek frekans ve çok satıcılı yapı ödeme ekonomisini değiştiriyor

İnsan internetinin ödeme altyapısı nispeten düşük frekanslı ve yüksek tutarlı işlemleri işlemede iyidir. Kredi kartı ağları, ödeme geçitleri ve abonelik sistemlerinin sabit maliyetleri vardır, bu nedenle satıcılar genellikle birçok çağrıyı aylık paketler halinde birleştirir. Her biri yalnızca birkaç sent değerinde olan API istekleri için geleneksel ödemenin işlem ücretleri, ters ibraz riski ve hesap bakım maliyetleri ürünün kendisinden daha yüksek olabilir.

Makine tüketimi tam tersidir. Bir ajan, bir teslimatı tamamlamak için dakikalar içinde birden fazla satıcıya çok sayıda satın alma başlatabilir. Tek işlem tutarı çok düşüktür, ancak çağrı sıklığı yüksektir ve işlem sayısı insan tüketicilerden çok daha fazla olabilir. Stablecoin'ler ve zincir üstü programlanabilir ödeme, bu tür senaryolar için yeni bir ekonomik temel sağlar: fonlar günün her saati akabilir, ödeme yetkilendirmesi yazılım tarafından imzalanabilir ve hizmetler doğrudan çağrı başına fiyatlandırılabilir.

Daha da önemlisi, çok satıcılı satın alma, API pazarındaki rekabet biçimini değiştirir. Abonelik modeli kullanıcıları uzun vadede tek bir sağlayıcıya bağlamayı teşvik ederken, kullanım başına satın alma, ajanların her görevde dinamik olarak seçim yapmasına olanak tanır. Hizmet sağlayıcılar artık yalnızca yıllık sözleşmeler için değil, aynı zamanda belirli bir anlık talep için de rekabet eder. Fiyat, performans ve yerine getirme kayıtları yönlendirme sonuçlarını gerçek zamanlı olarak etkileyebilir.

1.3 Stablecoin'ler işlem aracından ödeme altyapısına geçiyor

Kripto pazarının erken dönemlerinde stablecoin talebi esas olarak ticaret ve fon korumasından kaynaklanıyordu. İhracat, saklama, uyumluluk ve zincirler arası altyapı olgunlaştıkça, stablecoin'ler sınır ötesi ödeme, kurumsal nakit yönetimi ve internet yerel ödemelere girmeye başladı. Makine ödemeleri için stablecoin'lerin bir de özel avantajı vardır: hem para birimidir hem de programlar tarafından doğrudan işletilebilen bir dijital varlıktır.

Kredi kartı ödemeleri kart sahibinin kimliğine, banka hesabına ve coğrafi ağa bağlıdır. Ajanların kendileri doğal kişi kimliğine sahip değildir ve geleneksel hesap açma süreçlerinden bağımsız olarak geçemezler. Politika ile sınırlandırılmış bir cüzdan ise ajanın fon arayüzü olabilir: operatör sınırlı bir bakiye yükler, işlem başına ve oturum başına üst limitler belirler ve dondurma ile iptal yetkilerini saklı tutar; ajan yalnızca yetkilendirilmiş aralıkta ödeme imzalar.

Bu, zincir üstü ödemelerin doğal olarak tüm geleneksel ödemelerden üstün olduğu anlamına gelmez. Tüketici koruması, iade mekanizmaları, gizlilik, anahtar yönetimi ve düzenleyici sorumluluk hâlâ çözülmesi gereken konulardır. Ancak makineden makineye, düşük tutarlı kullanım başına ve küresel hizmet satın alımlarında programlanabilir stablecoin'ler belirgin bir uyumluluğa sahiptir. Bu, "arayüzü çağırma" ve "ödeme arayüzü"nün ilk kez aynı ağ etkileşimine sıkıştırılma fırsatını sunar.

2. Ödeme rayları zaten ortaya çıktı: x402, MPP ve HTTP yerel işlemler

2.1 402'yi durum kodundan ticari arayüze dönüştürmek

HTTP uzun zamandır 402 Payment Required durum kodunu ayırmıştı, ancak yaklaşık 30 yıl boyunca genel bir iş akışı oluşturamadı. Makine ödeme protokolleri bu anlamı yeniden etkinleştirdi: istemci ücretli bir uç noktaya istek gönderir, sunucu 402 ve makine tarafından okunabilir ödeme koşullarını döndürür; istemci kabul edilebilir bir seçenek seçer, imzalamayı veya ödemeyi tamamlar ve ardından kimlik bilgisiyle isteği yeniden dener.

Bu sürecin önemi, insan kayıt sayfasını ortadan kaldırmasıdır. Fiyat keşfi, ödeme gereksinimleri ve içerik teslimi, programların anlayabileceği protokol katmanında gerçekleşir. Geliştiriciler için ücretli API'ler artık hesap, paket ve anahtar etrafında eksiksiz bir SaaS portalı oluşturmak zorunda değildir; ajanlar için hizmetler sıradan bir web sayfası gibi keşfedilebilir ve gerçekten ihtiyaç duyulduğunda satın alınabilir.

x402, bu yoldaki en dikkat çeken açık protokollerden biridir. Ödeme meydan okumalarını ve kimlik bilgilerini HTTP 402 etrafında düzenleyerek hizmet sağlayıcıların istek başına ödeme almasını sağlar. MPP ise başka bir ekosistemden yola çıkarak makinelere yönelik charge, session gibi ödeme yöntemlerini araştırır. İkisinin somut tasarımları farklı olsa da ortaklaşa bir yönü doğrular: makine ödemeleri, uygulama dışında ayrı bir manuel mutabakat süreci kurmak yerine uygulama protokolünün bir parçası haline gelebilir.

2.2 Ödeme raylarının çeşitlenmesinin uzun vadeli doğası

Sektör sıklıkla sonunda tek bir standart protokolün, tek bir mutabakat ağının ve tek bir ödeme çözümünün kalacağını bekler. Ancak satıcı perspektifinden bakıldığında çeşitlilik uzun vadede mantıklıdır. Tek seferlik veri sorguları kullanım başına ücretlendirmeye uygundur; sürekli çıkarım veya akış hizmetleri oturum bazlı faturalandırmaya daha uygun olabilir; yüksek değerli hizmetler daha güçlü teminat ve anlaşmazlık çözümü gerektirirken düşük değerli çağrılar hız ve maliyete daha fazla önem verir; farklı bölgeler ve işletmeler de farklı uyumluluk ve mutabakat ağları seçecektir.

Protokol katmanı yenilik üretmeye devam edecektir. Satıcılar doğrudan borçlandırma, ön yetkilendirme, emanet, akış ödemesi veya toplu mutabakat benimseyebilir; ağlar maliyet, kesinlik, likidite ve ekosistem araçları açısından farklı ödünleşimler yapabilir. Satıcı için bu özgür bir seçimdir. Alıcı için ise her yeni kombinasyon, yeni bir entegrasyon yüzeyi ekler.

Aşağıdaki şekildeki yapılandırma matrisi bu çeşitliliğin bir kesitidir: protokol/ödeme çözümü sütunları, zincir satırları oluşturur; her seçim ayrı ayrı entegre edilmesi gereken bir ödeme yapılandırmasıdır ve bu tablo daha da genişlemektedir.

Şekil 1: Parçalanma altında ödeme rayı yapılandırma matrisi

Dolayısıyla parçalanmanın piyasa olgunlaştıkça kendiliğinden ortadan kalkması beklenmemelidir. Banka kartı piyasası uzun süreli gelişim sonucunda tek bir kart kuruluşuna indirgenmemiştir; bulut bilişim de tek bir sağlayıcıya yakınsamamıştır. Olgun piyasalar genellikle farklılıkları ortadan kaldırmaz; farklılıkların üzerinde toplama, yönlendirme ve takas katmanları oluşturur. Agent Payment'ın da aynı evrim yolunu izlemesi muhtemeldir. Bu bölünme şimdiden ölçülebilir durumdadır. İki açık tarayıcının (x402scan ve mppscan) son 30 günlük verileri (3 Eylül 2026 itibarıyla) şunu göstermektedir: MPP protokolünün Tempo zincirinde 65.591 aktif alıcı cüzdanı, x402'nin Base zincirinde 19.472 aktif alıcı cüzdanı bulunmaktadır; her iki ray üzerinde aynı anda görünen cüzdan sayısı ise yalnızca 365'tir; bu, MPP protokolü alıcılarının %0,6'sından ve x402 Base alıcılarının %2'sinden azdır. Bunlardan her iki ray üzerinde on işlemden fazla gerçekleştiren yalnızca 112 cüzdan vardır ve bunların önemli bir kısmı ikinci ödeme rayını benimseyen alıcılar değil, aynı anahtarla ödeme yapan çift raylı toplayıcılardır. Alıcılar raylar arasında hareket etmemekte, her ray kendi bağımsız alıcı kitlesini biriktirmektedir.

2.3 Satıcı entegrasyonu işlemin yalnızca yarısıdır

Ödeme protokolleri öncelikle satıcıların tahsilat engelini düşürür. Bir uç nokta teklif yayınlayabiliyor, kimlik bilgilerini doğrulayabiliyor ve hizmet döndürebiliyorsa, makinelere yönelik ticaret için temel koşullara sahip demektir. Giderek daha fazla geliştirici aracı, veri hizmeti ve içerik arayüzü bu sayede makineler tarafından satın alınabilir duruma geliyor.

Ancak arzın ödenebilir olması talebin kendiliğinden geleceği anlamına gelmez. Satıcılar "makineden nasıl tahsilat yaparım" sorusunu çözerken, ajanlar hâlâ "kimden satın almalıyım, hangi yöntemle ödemeliyim, ödeme sonrası teslimatı nasıl doğrularım" sorularını yanıtlamak zorundadır. Her alıcının her protokolü ayrı ayrı entegre etmesi, farklı ağlarda fon bulundurması ve bağımsız defter tutması gerekirse, makine ödemeleri erken dönem API entegrasyonunun karmaşıklığını tekrarlar; yalnızca API Anahtarı yerini cüzdan ve protokol adaptörlerine bırakır.

Gerçek benimseme oranı, yalnızca mutabakat adımındaki sürtünmeye değil, işlemin toplam sürtünmesine bağlıdır.

3. Sektörün gerçek darboğazı: İşlem kapalı döngü oluşturmuyor

Şekil 2: Bir makine satın alımının tam süreci

3.1 İlk engel: Satın alınabilir hizmetleri keşfetmek

Ajanların makine tarafından okunabilir hizmet dizinlerine ihtiyacı vardır. Etkili bir dizin yalnızca ad ve URL içermemeli; uç nokta yeteneklerini, girdi-çıktıyı, fiyat birimini, kullanılabilir protokolleri, gecikmeyi, bölgesel kısıtlamaları ve güncelleme durumunu da tanımlamalıdır. Doğal dil niyeti ile API parametreleri arasında da eşleme gerekir; aksi halde ajan "makro veriye ihtiyacım var" bilse bile hangi uç noktanın görevi karşıladığını belirleyemez.

Açık pazarlardaki dizinler ayrıca tekrarlar, geçersiz kayıtlar ve yanlış beyanlarla karşı karşıyadır. Her satıcı yüksek kaliteli veri sunduğunu iddia edebilir, ancak ajanlar insan satın alma uzmanları gibi arka plan araştırması yapmak için günler harcayamaz. Keşif katmanı uç noktaların çağrılabilir olup olmadığını, tekliflerin gerçek olup olmadığını ve açıklamaların döndürülen içerikle tutarlı olup olmadığını sürekli doğrulamalıdır.

Bu, hizmet keşfini geleneksel aramadan farklı kılar. Arama motorları bilgi alaka düzeyini optimize ederken, makine satın alma dizinleri ayrıca işlem yapılabilirliği optimize etmelidir: yetenekler eşleşiyor mu, fiyat kabul edilebilir mi, ödeme uyumlu mu ve satıcı teslimat yapabiliyor mu.

3.2 İkinci engel: Teklifleri anlamak ve karşılaştırmak

Görünüşte benzer API'lerin tümü işlem başına fiyatlandırılabilir, ancak gerçekte tekliflerin karşılaştırılabilirliği zayıftır. Bir şirket istek başına ücret alırken, bir diğeri sonuç sayısına göre ücret alır; bir şirket model çıkarımını fiyata dahil ederken, bir diğeri ek ödeme gerektirir; başka hizmetler ise girdi uzunluğuna, çalışma süresine veya başarılı sonuçlara göre dinamik fiyatlandırma yapar.

Ajanlar yalnızca nominal fiyatı en düşük olan uç noktayı seçmemelidir. Toplam maliyeti, teslimat olasılığını, gecikmeyi ve sonuç kalitesini göz önünde bulundurması gerekir. Ucuz bir arayüz üst üste başarısız olursa, yeniden deneme maliyeti ve görev gecikmesi gerçek fiyatını daha yükseğe çıkarabilir. Bu nedenle teklifler hizmet seviyesi, geçmiş performans ve görev bağlamıyla birlikte değerlendirilmelidir.

Makine tarafından okunabilir tekliflerin ayrıca geçerlilik süresini ve nihai tutarı açıkça belirtmesi gerekir. Dinamik fiyatlandırma ortamlarında, ajanın imzaladığı şey belirsiz bir fiyat aralığı değil, kesin bir taahhüt olmalıdır. Operatörlerin de hizmet ücreti, ağ maliyeti ve yönlendirme ücreti dahil olmak üzere maliyet yapısını bilmesi gerekir ki güvenilir bir bütçe belirleyebilsinler.

3.3 Üçüncü Aşama: Fon Dağılımı ve Raylar Arası Likidite

Bir ajanın aynı anda birden fazla zincirde ve birden fazla protokolde hizmet satın alması gerekiyorsa, en basit yaklaşım her ağda önceden bakiye bulundurmaktır. Ancak bu, az miktardaki fonu birçok parçaya böler. Fon geçici olarak kullanılmayan ağlarda beklerken, popüler ağlarda bakiye yetersiz kalabilir; bakiye takviyesi köprüleme, takas, Gas ve güvenlik işlemlerini gerektirir.

Tek bir kullanıcı için bu zaten zahmetlidir. Çok sayıda ajan yöneten bir kuruluş için sorun daha da büyür: her ajan ne kadar bakiye tutmalı, takviyeden kim sorumlu, fonların yanlış harcanması nasıl önlenir, farklı ağlardaki varlıklar ve ücretler nasıl toplanır? Birleşik bir fon katmanı olmadan, ödeme rayı sayısı arttıkça finansal karmaşıklık da artar.

İdeal durumda, ajan birden fazla ağ bakiyesi yerine tek bir kullanılabilir bütçe görür. Altta yatan sistem takas yolunu seçmek, likiditeyi yönetmek ve şeffaf fiyat teklifi sunmakla sorumludur. İlke, bir gezginin farklı ülkelerde tek bir kart kullanmasına benzer: kullanıcı toplam limiti ve döviz kurunu önemser, her varış noktası için önceden yerel hesap açması gerekmez.

3.4 Dördüncü Aşama: Politika Tabanlı Yetkilendirme

Otonom ödemelerin en çok endişe yaratan yönü, ajanın kontrolden çıkıp harcama yapıp yapmayacağıdır. Çözüm, basitçe "tamamen yasak" ile "tamamen yetkilendirme" arasında bir seçim yapmak değil, çok katmanlı politikalar oluşturmaktır.

İşlem başına üst limit tek bir hatanın kaybını sınırlar, oturum bütçesi bir görevin toplam harcamasını kısıtlar, satıcı beyaz listesi veya kara listesi karşı tarafı kontrol eder, kategori kuralları satın alınabilecek içeriği sınırlar, hız limitleri kısa sürede anormal çağrıları engeller. Yüksek riskli veya yüksek tutarlı işlemler manuel onayı tetikleyebilir. Politikalar operatör tarafından belirlenmeli, ajan yalnızca sınırlar içinde hareket edebilmeli ve limitleri kendi başına artıramamalıdır.

Cüzdan da yalnızca imzalama işlevi üstlenmemelidir. Görev, kimlik ve denetim kayıtlarıyla birleşerek "hangi ajan, hangi görev için, hangi politikayla bu ödemeyi onayladı" sorusunu yanıtlaması gerekir. Aksi takdirde kuruluşun eline yalnızca bir dizi zincir üstü işlem hash'i geçer ve iç kontrol ile maliyet atıf gereksinimleri karşılanamaz.

3.5 Beşinci Aşama: Başarılı mutabakat, hizmet teslimi anlamına gelmez

Blok zinciri, fonların bir adresten diğerine aktarıldığını kanıtlamada ustadır, ancak bir API'nin doğru içerik döndürdüğünü doğal olarak kanıtlayamaz. Bir işlem mutabakatı tamamlayabilir, ancak sunucu tarafı zaman aşımına uğrayabilir, hata durumu döndürebilir veya teslim edilen veriler tanıtımla uyuşmayabilir. Ajanlar için bu, marjinal bir sorun değil, satın alma riskinin merkezidir.

Geleneksel e-ticaret, ödeme ile teslimatı lojistik, değerlendirme ve iade yoluyla birbirine bağlar; makine hizmetlerinde fiziksel lojistik yoktur, teslimat yalnızca anlık bir HTTP yanıtı olabilir. Ödeme sistemi yalnızca fon izini kaydederse, satıcı yalnızca kendi yanıtını kaydederse, piyasada satıcılar ve protokoller arası birleşik bir yükümlülük görünümü eksik kalır.

Dikkatli olunması gereken nokta şudur: Yanıtı kaydetmek, kaliteyi kanıtlamak anlamına gelmez. Ancak ödemeyi yanıtla ilişkilendirmek, en azından "ödendi ve sonuç alındı", "ödendi ancak hizmet başarısız oldu", "mutabakat yapılmadı" gibi temel durumları ayırt edebilir. Bu, makine işlem itibarını oluşturmanın ilk katmanıdır.

3.6 Altıncı Aşama: Birleşik mutabakat ve sorumluluk tanımı

Bir görev onlarca mikro satın alma içerebilir. Her işlem farklı cüzdanlara, protokollere ve satıcı arka uçlarına dağılmışsa, kullanıcının nihai teslimatın neden bu kadar maliyetli olduğunu bilmesi zordur. İşletmeler ayrıca harcamaları projelere, ekiplere, müşterilere ve maliyet merkezlerine atfetmeli ve denetlenebilir kanıtları saklamalıdır.

Birleşik defter, satın alma niyetini, satıcıyı, teklifi, yetkilendirme politikasını, mutabakat sonucunu, yanıt durumunu ve başarısızlık nedenini aynı anda kaydetmelidir. Yalnızca finansa değil, aynı zamanda ajan optimizasyonuna da hizmet eder. Sistem hangi veri kaynaklarının sık sık başarısız olduğunu, hangi rotaların daha maliyetli olduğunu ve belirli bir görev türünün tipik satın alma kombinasyonunu analiz edebilir.

Ödeme akıl yürütme zincirine gömüldüğünde, maliyet model kararının geri bildirim sinyali haline gelir. Birleşik mutabakat olmadan, ajan yalnızca yanıtı optimize edebilir, yanıtı elde etmenin ekonomik sürecini optimize edemez. Agent Payment'ın uzun vadeli değerinin büyük bir kısmı tam da bu gözlemlenebilirlikten gelir.

4. Ödeme protokolünden makine satın alma katmanına

4.1 Geleceğin temel soyutlaması "Pay" değil, "Buy"dur

Ödeme, nesne ve fiyat netleştikten sonraki eylemdir; satın alma ise ihtiyaçtan kabul sürecine kadar tüm süreci kapsar. Ajana bir pay() fonksiyonu sunmak, yalnızca bilinen bir adrese transfer yapmasını sağlar; bir buy() yeteneği sunmak ise sistemin ihtiyacı alabileceği, hizmeti keşfedebileceği, seçenekleri karşılaştırabileceği, ödemeyi gerçekleştirebileceği ve doğrulanabilir sonuç döndürebileceği anlamına gelir.

Bu ayrım, endüstri iş bölümünü belirler. Protokoller standartlaştırılmış ödeme mesajları sağlar, cüzdanlar imzaları ve varlıkları yönetir, mutabakat ağları değeri taşır, dizinler arzı toplar ve satın alma katmanı bu bileşenleri bir göreve dönüştürür. Her bir bileşen önemlidir, ancak hiçbiri tek başına tam işlemi temsil edemez.

Makine tedarik katmanı açık kalmalıdır. Tüm satıcıların aynı protokole geçmesini gerektirmemeli ve kimin satın alınabileceğine kapalı bir dizin aracılığıyla karar vermemelidir. Daha sürdürülebilir model, birden fazla ödeme kanalıyla uyumlu olmak, tekliflerde yönlendirme maliyetlerini açıklamak ve ajanların politikaya göre özerk seçim yapmasına izin vermektir.

4.2 Alıcı tarafı birleşmesi, satıcı tarafı birleşmesinden daha önemli olabilir

İnternet platformları genellikle önce arzı birleştirir, sonra tüketicileri çeker. Makine pazarlarında arz zaten API biçiminde yaygın olarak mevcuttur; eksik olan, sürekli satın alma yapabilen standartlaştırılmış alıcıdır. Donanımlı bir ajan, dağınık ve arızi talebi istikrarlı bir işlem akışına dönüştürebilir.

Alıcı tarafı birleşmesi ayrıca uzun kuyruk hizmetlerin görünürlüğünü artırır. İnsan geliştiriciler, yeni tedarikçileri değerlendirmenin zaman maliyeti yüksek olduğu için tanıdık büyük markaları kullanma eğilimindedir; ajanlar standartlaştırılmış yetenek, fiyat ve performans sinyallerini okuyabiliyorsa, her görevde daha uygun hizmeti seçebilir. Bu, yeni satıcıların müşteri edinme maliyetini düşürebilir ve yerleşik satıcıları gerçek performans üzerinden rekabet etmeye zorlayabilir.

Ancak alıcı giriş noktaları da yeni bir platform gücü oluşturur. Varsayılan dizini, sıralamayı ve ödeme yollarını kim kontrol ederse, trafik dağılımını etkileyebilir. Bu nedenle sektörün şeffaf sıralama kurallarına, açıklanabilir ücretlere ve taşınabilir işlem kayıtlarına ihtiyacı vardır. Birleşme sürtünmeyi azaltabilir, ancak açık protokolleri kapalı kanallar olarak yeniden paketlememelidir.

4.3 Gerçek işlem verilerine dayalı itibar oluşturma

Makine alıcılarının karar hızı yüksektir ve uzun süreli durum tespitine güvenemezler. Teklif ortaya çıktığında karşı taraf sinyalini aynı anda almaları gerekir. Geleneksel puanlama ve kullanıcı değerlendirmeleri referans sağlayabilir, ancak sahte hacim, sybil hesapları ve çıkar ilişkili taraflarca manipüle edilmeye açıktır. Değerlendirmeler gerçek ödeme gerektirmiyorsa, saldırı maliyeti özellikle düşüktür. Ajanlara yönelik ilk izinsiz zincir üstü güven katmanı olan ERC-8004 üzerine yakın zamanda yapılan ampirik araştırma bunu doğrulamaktadır [6]. Protokolün spesifikasyon metni açıkça "Payments are orthogonal to this protocol" (Ödemeler bu protokole diktir) yazmaktadır — değerlendirmeler varsayılan olarak herhangi bir gerçek ücretli işleme bağlı olmak zorunda değildir, ödeme kanıtı yalnızca isteğe bağlı bir alandır. Sonuç: Ethereum, BSC ve Base zincirlerinde (13 Mayıs 2026 itibarıyla), değerlendiricilerin sırasıyla %73,5'i, %59,2'si ve %90,6'sı koordineli sybil davranışı sergilemiştir.

Daha güvenilir temel, gerçek ücretli çağrılarla ilişkilendirilmiş sonuç kayıtlarıdır: bir hizmet uç noktası kaç ödeme tamamlamıştır, yanıt başarı oranı nedir, yaygın gecikme ne kadardır, ödeme sonrası yanıt vermeme oranı ne kadar yüksektir. Bu göstergeler içerik kalitesini tam olarak temsil edemese de, öz beyandan doğrulanabilir gerçeğe daha yakındır.

Veri biriktikçe piyasada katmanlı itibar oluşabilir. Birinci katman nesnel işlem durumu, ikinci katman yeniden üretilebilir hizmet göstergeleri, üçüncü katman ise belirli görevlere yönelik kalite değerlendirmesidir. Ajanlar, tutar ve riske göre gerekli kanıt gücünü seçebilir: birkaç sentlik veri sorguları için istatistiksel sinyaller yeterliyken, yüksek değerli satın alımlar için garanti, denetim veya uyuşmazlık çözümü gerekir.

4.4 Bütçe stratejisi ajanların önemli bir yeteneği haline gelecek

Bugün ajanlar esas olarak yanıt kalitesi, görev tamamlama oranı ve araç çağrı doğruluğuna göre değerlendiriliyor. Ücretli ortama girildiğinde ekonomik göstergeler de eklenir: aynı kaliteye ulaşmak için ne kadar harcandığı, bütçe içinde tamamlanıp tamamlanmadığı, daha pahalı verinin ne zaman satın alınmaya değer olduğu ve hız, maliyet ile güvenilirlik arasında nasıl denge kurulacağı.

Bu, yeni eğitim ve değerlendirme yönleri doğuracaktır. Ajanlar yalnızca "hangi aracın soruyu yanıtlayabileceğini" değil, aynı zamanda "mevcut görev değeri altında bu aracı satın almanın kârlı olup olmadığını" da öğrenir. Önce düşük maliyetli hizmetlerle filtreleme yapıp kritik sonuçlar için yüksek kaliteli doğrulama satın alabilir; bütçe tükenmek üzereyken çağrı sıklığını azaltabilir veya kullanıcıdan ek yetki talep edebilir.

Bu anlamda Agent Payment, model yeteneklerinin dışında bir finansal eklenti değil, karar zekâsının bir parçasıdır. Gerçekten olgun bir ajan, kaynakları kullanmayı da kaynakları fiyatlandırmayı da bilmelidir.

5. Agent Payment'ın olası evrim yolu

5.1 Birinci aşama: Geliştirici araçları ve dijital hizmetler öncülük eder

En erken ölçeklenen senaryo büyük olasılıkla yine tamamen dijital teslimat olacaktır: arama, veri, vekil kazıma, model çıkarımı, kod yürütme, depolama ve içerik üretimi gibi. Bu hizmetler doğrudan API üzerinden sunulur, marjinal teslimat maliyeti düşüktür, ödeme ve yanıt aynı ağ oturumunda tamamlanabilir ve karmaşık lojistik içermez.

Bu aşamadaki tipik tutarlar çok küçüktür ve kullanıcılar geliştirme kolaylığı ile görev tamamlama oranına odaklanır. Piyasa protokolleri hızla doğrular, ancak işlem hacmi son derece dağınık olabilir. Birçok çağrı hâlâ geleneksel API Key ve aboneliklerle karşılanacak, makine ödemeleri daha çok geçici ihtiyaçlar, satıcılar arası satın alımlar ve önceden hesap açılamayan uzun kuyruk hizmetler için kullanılacaktır.

5.2 İkinci aşama: Kurumsal bütçeler ve çoklu ajan işbirliği

İşletmeler birden fazla ajan konuşlandırmaya başladığında, fon yönetimi kişisel cüzdandan kurumsal düzeyde hesap sistemine yükselecektir. İşletmelerin farklı rollere bütçe tahsis etmesi, satın alınabilecek kategorileri kontrol etmesi, onay eşikleri belirlemesi ve harcamaları finansal sistemlere kaydetmesi gerekecektir. Ajanlar arasında iç mutabakat da oluşabilir: araştırma ajanı veri satın alır, analiz ajanı hesaplama gücü satın alır, yürütme ajanı harici hizmetleri çağırır.

Bu noktada güvenlik ve uyumluluk, ödeme yeniliğinden daha önemli hale gelir. İşletmeler anahtar saklama, yetki izolasyonu, işlem izleme, tedarikçi denetimi ve denetim kaydı konularıyla ilgilenir. Mevcut finansal süreçlerle uyumlu altyapı, ancak denemeden üretime geçebilir.

5.3 Üçüncü Aşama: Dijital hizmetlerden gerçek ekonomiye uzanmak

Uçak biletleri, oteller, lojistik, reklam ve profesyonel hizmetler ajan satın alma nesneleri haline gelebilir, ancak gerçek dünya işlemleri daha karmaşık kimlik, iade, vergi ve anlaşmazlık çözümü gerektirir. Stablecoin'ler yalnızca takas sorununun bir kısmını çözebilir; tüketici haklarının ve ticari sözleşmelerin yerini alamaz.

Bu nedenle sektör, "otonom ödemeyi" tüm aracıların ortadan kaldırılması olarak yorumlamamalıdır. Aksine, işlem değeri arttıkça teminat, sigorta, kredi ve tahkim yeniden ortaya çıkar; ancak bunların makine tarafından çağrılabilir hizmetlere dönüştürülmesi gerekir. Gelecekteki Agent Payment yığını, tek bir rotanın diğerinin yerini alması yerine, açık ödeme protokolleri ile geleneksel finans bağlantılarını aynı anda içerebilir.

5.4 Dördüncü Aşama: Protokoller arası yönlendirmeden pazarlar arası yürütmeye

Uzun vadede ajanlar yalnızca bir API yanıtı değil, bir sonuç satın alır. Kullanıcı "güvenilir bir sektör raporu oluştur" talebinde bulunabilir ve sistem arama, veritabanı, çeviri, model ve doğrulama hizmetlerini kendi başına birleştirir. Arka planda birden fazla işlem gerçekleşir; kullanıcı yalnızca toplam bütçeyi, kanıt kaynaklarını ve nihai teslimatı görür.

Bu, ödeme yönlendirmesini pazar yürütmesine yükseltir. Sistemin karmaşık hedefleri satın alma kombinasyonlarına ayırması, başarısız tedarikçileri dinamik olarak değiştirmesi ve toplam maliyet ile kalite arasında optimizasyon yapması gerekir. Protokol uyumluluğu yalnızca temeldir; gerçek bariyer talep anlayışı, işlem verileri ve yürütme geri bildiriminden gelir.

6. Riskler ve Çözülmemiş Sorunlar

Agent Payment'ın hayal gücü geniştir, ancak gerçek kısıtlamalar göz ardı edilemez. Birincisi güvenliktir. Prompt enjeksiyonu ajanları kötü niyetli hizmetler satın almaya yönlendirebilir, tedarik zinciri saldırıları alıcı adreslerini değiştirebilir ve hatalı politikalar çok sayıda tekrarlanan ödemeye neden olabilir. Ödeme eylemleri güvenilmez içerikten izole edilmeli ve limitler, simülasyon, iptal ve anormallik tespiti içermelidir.

İkincisi gizliliktir. Satın alma kayıtları ajanın hangi görevi yürüttüğünü açığa çıkarır ve zincir üstü açık veriler kullanıcı kimliğini ticari niyetlerle ilişkilendirebilir. Sistem hassas meta veri sızıntısını en aza indirmeli ve denetim ihtiyaçları ile gizlilik arasında denge kurmalıdır.

Üçüncüsü sorumluluktur. Ajan yanlış satın alma yaptığında, satıcı teslimatı gerçekleştirmediğinde veya protokol dönüşümü başarısız olduğunda zararı kim üstlenmelidir? Düşük tutarlı işlemler otomasyon riskini kabul edebilir; yüksek tutarlı işlemler ise net sorumluluk sınırları gerektirir. Anlaşmazlık mekanizması olmayan bir ödeme ağının yüksek değerli ticarete doğrudan girmesi zordur.

Dördüncüsü düzenleme. Stablecoin ihracı, cüzdan kontrolü, sınır ötesi transferler ve satıcı tahsilatları farklı yargı alanlarının kurallarından etkilenir. Makineler uygulayıcıdır, yasal sorumluluk öznesi değildir. Altyapı, her otonom işlemi net bir operatöre, yetkilendirme politikasına ve fon kaynağına kadar izleyebilmelidir.

Beşincisi ticari sürdürülebilirlik. Mikro ödeme gelirleri ağ maliyetleri, likidite ve risk kontrolü ücretleri tarafından kolayca yutulur. Platform deneyimi gizli fiyat artışlarıyla sübvanse ederse, bu alıcı güvenine zarar verir. Ücretler şeffaf olmalı ve ölçek, yönlendirme verimliliği ve katma değerli hizmetler yoluyla makul bir iş modeli oluşturulmalıdır.

Bu sorunlar sektörü reddetmez; aksine Agent Payment'ın yalnızca tek bir protokolle tamamlanmayacağını gösterir. Nihayetinde ödeme, kimlik, yetki, keşif, itibar ve mutabakatın birleşik altyapısı haline gelecektir.

7. SELAT: Makine-doğal ticaret için alıcı tarafı yeteneklerini donatmak

「SELAT」Malayca'da 「boğaz」 anlamına gelir, örneğin Malakka Boğazı (Selat Melaka). Yüzyıllar boyunca, mallar hangi limandan gelirse gelsin, hangi pazara giderse gitsin, Doğu-Batı ticaretinin ana akışı bu su yolundan geçmiştir. SELAT, makine-doğal ticarette o boğaz olmayı hedefler: Satıcı hangi ray üzerinde karaya çıkarsa çıksın, ajanların talebi buradan akabilmelidir.

SELAT, makine ödemelerine alıcı tarafından giren AI-doğal bir şirkettir. SELAT, makine-doğal ticaretin alıcı katmanıdır; temel amacı satıcıların geçiş yapmasını gerektiren yeni bir ödeme rayı yaratmak değil, ajanların mevcut raylar arasında satın alma işlemlerini gerçekleştirmesini sağlamaktır. İki temel soruna odaklanır: Birincisi, ödeme yapılandırmasının parçalanmışlığı; raylar, protokoller, zincirler ve kimlik bilgileri birbirinden farklıdır ve her satıcı yeni bir entegrasyon yapmak zorundadır. İkincisi, karşı taraf riskinin ölçülememesi; mutabakatın başarılı olması hizmetin teslim edildiği anlamına gelmez.

Şekil 3: SELAT alıcı katmanı şeması

Parçalanmışlık sorununa karşı SELAT CLI, protokol, ödeme planı ve mutabakat ağı farklılıklarını altyapı katmanında bırakarak ajanların tek bir komutla raylar arası satın alma yapmasını sağlar. Keşif, teklif, yetkilendirme, ödeme, teslimat durumu kaydı ve mutabakat aynı satın alma sürecine dahil edilir ve her çağrı aynı defterde kaydedilir.

• Tek bir fon havuzu, N sayıda ödeme rayı kullanımı

Ajan, kendi sakladığı bir USDC bakiyesine sahiptir; zincir başına önceden fon ayırması veya farklı protokoller için farklı istemciler bulundurması gerekmez.

• Birleşik uç nokta dizini

SELAT CLI, Circle, MPP, Apify ve pay.sh olmak üzere dört üçüncü taraf hizmet kayıt defterini ve SELAT'ın kendi dizinini bir araya getirerek ajanların gerçek zamanlı niyete göre 4.000'den fazla hizmet uç noktasını keşfetmesini ve karşılaştırmasını sağlar.

• Katı harcama üst sınırı

Operatörler işlem başına üst sınır ve oturum bütçesi belirleyebilir ve harcama yetkisini istedikleri zaman dondurabilir; ajanlar limitleri kendi başlarına artıramaz.

• Satıcılar için sıfır geçiş

Satıcılar kendi seçtikleri ödeme kanallarını koruyabilir; SELAT'a yeniden kaydolmadan ajanlar tarafından keşfedilebilir ve satın alınabilir.

Fon tarafında SELAT, Circle ve MetaMask'in ajan cüzdanları dahil olmak üzere herhangi bir ajan cüzdanıyla birlikte kullanılabilir. SELAT, her satın alımı x402 ve MPP gibi ödeme kanalları arasında yönlendirir ve gerçek zamanlı fiyat tekliflerini esas alır.

7.1 ERC-8004: İlkeler doğru, sinyaller şüpheli

ERC-8004; kimlik, itibar ve doğrulama olmak üzere üç tür kayıt defteri tanımlar ve alıcıların satıcılara değerlendirme göndermesine olanak tanır. Yön doğrudur, ancak ödeme ile itibarı açıkça birbirinden ayırır: geri bildirimin gerçek bir işlemden gelmesi gerekmez ve ödeme kanıtı eklemek isteğe bağlıdır.

Konuşlandırılmış ekosistem üzerine yapılan ampirik araştırmalar, Base'de değerlendiricilerin %93,8'inin hiç x402 ödemesi yapmadığını, ancak geri bildirimin %94,9'una katkıda bulunduğunu göstermektedir; geri bildirimlerin büyük bir kısmı ayrıca koordineli sybil davranışı sergilemektedir [6]. Kayıt defterleri beyanları kaydeder, oysa alıcıların gerçekte ihtiyaç duyduğu şey sonuçlardır.

7.2 Alıcıların ihtiyaç duyduğu şey, gerçek işlem verileriyle ilişkilendirilmiş itibardır

Ödeme kanalları fonların takas edilip edilmediğini doğrulayabilir, ancak hizmetin ne döndürdüğünü göremez; satıcılar kendi yanıtlarını görebilir, ancak tüm pazarı göremez; kayıt defterleri uç noktaları listeleyebilir, ancak değerlendirmelerin gerçek satın alımlardan geldiğini kanıtlayamaz.

Satın alımı gerçekleştiren alıcı katmanı, işlemin her iki ucunu birbirine bağlamak için en iyi fırsata sahiptir: SELAT üzerinden tamamlanan her satın alım, hangi uç noktanın ödendiğini, ne kadar takas edildiğini ve ödeme sonrası teslimat durumu meta verilerini (2xx, 4xx, 5xx) kaydeder. Bu kayıtlar satıcı ve ödeme kanalı bazında sürekli birikerek "Takas–Teslimat Grafiği"nin (Settlement–Delivery Graph) veri temelini oluşturur.

Doğru bir şekilde ayırt etmek gerekir: ödeme ve teslimat durumuyla ilişkilendirilmiş kayıtlar, teslimat kalitesinin veya fiyat teklifi doğruluğunun bağımsız kanıtıyla eşdeğer değildir. Ancak kayıt defteri tabanlı itibarın eksik bıraktığı temeli sağlar: gerçek ücretli çağrılarla ilişkilendirilmiş sonuç verileri.

7.3 İşlem öncesinde karşı tarafın itibarını edinme

İnsanlar X'te dördüncü nesil internet için Google PageRank benzeri bir Trust mekanizmasının nasıl tasarlanacağını tartışırken, SELAT mutabakat—teslimat grafiği üzerinde "İşlem Yapılabilirlik Endeksi"ni (Transactability Index) hayata geçirip yayına aldı; amaç, ajanların çalışma zamanında gerçek işlem sonuçlarıyla desteklenen karşı taraf itibar verisine erişmesini sağlamaktı.

Endeks, teklifle birlikte döndürülür; ajanın görevini duraklatıp satıcıyı ayrıca araştırması gerekmez. Riski işaretler ama piyasa adına engel koymaz: uç noktalar hâlâ keşfedilebilir ve satın alınabilir; ajan bütçesine, görevin önemine ve risk tercihine göre karar verir.

Ajanın marka hikâyesini okuyacak zamanı yoktur. Ödeme yapmadan önce şunu bilmesi gerekir: bu uç nokta gerçek işlemlerde nasıl performans gösteriyor? Makine-doğal ticaretin itibarı beyanlardan değil, sonuçlardan gelmelidir.

Şekil 3: Teklif aşamasında işlem yapılabilirlik sinyali

Şu anda SELAT CLI, Claude Code, Codex, Cursor, Gemini CLI, OpenClaw, Hermes ve Grok Bot gibi ajan çalışma ortamlarına uyarlanmıştır.

8. Özet: Makine ekonomisinin ihtiyacı yalnızca daha hızlı ödeme rayları değil

Agent Payment, hem olduğundan fazla hem de olduğundan az değer görülmeye açık bir aşamada. Olduğundan fazla değer görmeye açık, çünkü teknik olarak bir stablecoin ödemesini tamamlamak, ajanın olgun ticari özerkliğe sahip olduğu anlamına gelmez; olduğundan az değer görmeye açık, çünkü yazılım belirli kısıtlar altında dış yetenekler satın alabildiğinde, makine ekonomisinin örgütlenme biçimi, fiyatlama biçimi ve rekabet sınırları değişir.

Ödeme protokolleri, makinelerin teklif alıp mutabakatı tamamlayabildiğini zaten kanıtladı. Bundan sonraki kilit nokta, izole bir ödemeyi eksiksiz bir satın almaya dönüştürmektir: ajanın uygun hizmeti bulmasını, gerçek maliyeti anlamasını, bütçe dahilinde raylar arası ödeme yapmasını, teslimatı doğrulamasını ve her işlemi denetlenebilir, öğrenilebilir bir kayda dönüştürmesini sağlamak.

Geleceğin makine ekonomisi tek bir zincirden, tek bir protokolden veya tek bir cüzdandan oluşmayacak. Çoklu arz uzun süre var olacak ve gerçek değer taşıyan altyapı, alıcının bu karmaşıklığı aşmasına yardımcı olacak. Agent Payment'ın teknik kapasiteyi gerçek talebe dönüştürebilmesi için rayları, arzı, varsayılan ödemeyi ve güven mekanizmalarını bir araya getirmesi gerekir.

Yazılım alıcı olmaya başladığında, ödeme sadece attığı ilk adımdır. Daha önemli soru her zaman şudur: Gerçekten faydalı bir işlemi kontrol edilebilir, şeffaf ve doğrulanabilir bir şekilde tamamlayabilir mi?

Referanslar

[1] Circle, "Building the Open Agentic Economy", 2026. https://www.circle.com/blog/building-the-open-agentic-economy

[2] SELAT, "Counterparty Risk in Agentic Payments: The Unmeasured Half", 2026. https://selat.ai/insights/counterparty-risk-agentic-payments

[3] Google Cloud, "Powering AI commerce with the new Agent Payments Protocol (AP2)", 2025. https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol

[4] x402 Foundation, "x402: Açık internet yerel ödeme standardı". https://github.com/x402-foundation/x402

[5] Machine Payments Protocol, "MPP: HTTP 402 tabanlı makine ödeme protokolü". https://mpp.dev/

[6] Xiong ve diğerleri, "Can Trustless Agents Be Trusted? An Empirical Study of the ERC-8004 Decentralized AI Agent Ecosystem", arXiv, 2026. https://arxiv.org/abs/2606.26028