KABUL, İMZALAR VE EMİR COMMIT'LERİ

Altı gereksinim her emri kapatır. Sabit sırada çalışırlar ve herhangi bir başarısızlık, fiyatlama katmanı görmeden isteği iptal eder. İlk üçü imzacı-ve-yük kontrolleridir; son üçü zamanlama, commitment ve execution-şekil politikasıdır.

#Yetkili imzalı akış

Bir istemci bir emri imzalayıp platformun kabul etmesini umamaz. Hesap önce POST /agent/authorize aracılığıyla bir öz-politika kaydeder, bu da kendi adına eyleme yetkili belirli imzacı anahtarını kayıt altına alır. Bu ayrım pratikte önemlidir: hesabın çekim anahtarı, KYC bağlanması ve referans nakdi asla bir işlem seansına dokunmak zorunda kalmaz — bir hardware cüzdan, bir oturum anahtarı veya bir API istemcisi, cüzdanın geri kalanı asla açığa çıkmadan imzalama yüzeyini devralır.

Yetkilendirme var olduktan sonra, her emir imzasız bir talimat yerine bir EIP-712 tipli yük olarak gelir. İmzalı yapı marketi, yönü, boyutu, limit fiyatını, geçerlilik penceresini (createdAtTs, goodTilTs) ve hesabın monotonik seq'ini taşır. Engine, yetkisiz imzacıları, eksik seq'i, süresi dolmuş veya gelecek-eğimli zaman damgalarını ve IOC olmayan yükleri kapıda reddeder — bu başarısızlıkların hiçbiri fiyatlama veya risk katmanına ulaşmaz. Üretimde bu, gateway'de GATEWAY_REQUIRE_IOC tarafından ve runtime'ın payload doğrulayıcısı tarafından uygulanır, böylece aynı kural bağımsız kod yollarında iki kez kontrol edilir.

#Sıralama ve on-chain commit kanıtı

Monotonik sıralama runtime'a deterministik bir olay sırası verir. Her hesabın seq'i kesinlikle yukarı doğru ilerler, böylece aynı zinciri yeniden oynatan iki bağımsız gözlemci aynı gerçekleşmeler sırasını görür. Runtime, seq'i o hesap için önceden kabul edilen seq'ten büyük olmayan herhangi bir yükü reddeder — bir replay, bir ağ yeniden sıralaması veya bir yinelenen yeniden deneme, hepsi tek bir kabul edilen olaya çöker.

Üretimde commit guard aktifken, gateway, runtime'ın eşleştirmesine izin verilmeden önce commitOrder (tekil) veya commitOrders (toplu) aracılığıyla Base üzerindeki OrderCommitRegistry kontratında emir hash'ini sabitler. Bu tek bir adımda iki ayrı şey başarır. Kabulü daraltır: runtime, commit'i eksik olan bir emri fiyatlamaz. Ve emrin, herhangi bir fill üretilmeden önce imzacının onayladığı biçimde var olduğuna dair genel, zaman damgalı, on-chain bir kayıt üretir — bu, sonraki itiraz incelemelerinin karşı kontrol ettiği şeydir.

 POST /agent/authorize
   -> signer politikasi hesap icin aktif olur
   -> client EIP-712 IOC payload'unu imzalar (market, side, size, price, createdAtTs, goodTilTs, seq)
   -> gateway GATEWAY_REQUIRE_IOC uygular ve payload seklini dogrular
   -> commitOrder(orderHash) Base uzerindeki OrderCommitRegistry'ye iner
   -> runtime signer, seq monotonlugu, zaman damgalari ve commit varligini yeniden kontrol eder
   -> ancak bundan sonra vAMM fiyatlama ve fill mantigi calisir

#Kabul sınırını incelemek

Kabul stack'i bir tören değildir. Teknik bir incelemecinin üç soruyu yalnızca genel state'ten yanıtlayabilmesi için var: emir anında bu hesap için hangi imzacının eylem yapmasına izin verildi, isteklerin birbirine göre hangi sırada geldiği ve runtime'ın zaten on-chain sabitlenmiş bir yükü eşleştirip eşleştirmediği. Bu yanıtlardan herhangi biri "söyleyemeyiz" ise, platform kendi kabul sözleşmesinin dışında çalışıyor demektir. Agent yetkilendirmesi, monotonik seq ve OrderCommitRegistry anchor'ı ile üç yanıt da, incelemecinin platformun sözüne güvenmeden çekebileceği verilerden gelir.

#Bunun lider tablosu ve ödemeler için neden önemli olduğu

• İşlem geçmişi Base üzerinde sabitlenmiştir. Her emrin hash'i, runtime eşleştirmeden önce commitOrder aracılığıyla OrderCommitRegistry'ye çarpar. Bir podyum bitirmesi veya 90/10 fonlu ödeme zincirden yeniden üretilebilir — platform bir ödemenin karşı hesaplandığı geçmişi yeniden yazamaz çünkü her commit'in zaman damgası gerekçelendirdiği fill'den daha eskidir.
• Monotonik seq çift sayımı önler. Bir ağ yeniden denemesi, bir relayer yarışı veya bir yükü yeniden gönderen bir istemci hatasının hepsi tek bir kabul edilen olaya çöker çünkü seq zaten ilerlemiştir. Lider tablosu bir fill'i çift sayamaz ve bir kâr-paylaşımı çekimi daha sonra gelen yinelenen bir fill iddiasıyla itiraz edilemez.
• Agent yetkilendirmesi işlem yüzeyini izole eder. Challenge girişlerini, fonlu ödemeleri ve DXTR stake'ini tutan cüzdanın işlemleri imzalaması gerekmez. POST /agent/authorize ayrı bir imzacıyı — hardware cüzdan, oturum anahtarı, API istemcisi — hesap politikasına bağlar. İşlem anahtarı sızdırılırsa, çekimler, KYC bağlanması ve referans nakdi orijinal cüzdanda ve saldırganın erişiminin dışında kalır.
• createdAtTs / goodTilTs replay pencerelerini bloklar. Bir imza yalnızca beyan edilen geçerlilik penceresi içinde geçerlidir. 10 dakika önce yakalanan imzalı bir yük, imzacı anahtarı daha sonra ele geçirilse bile bugün replay edilemez — runtime, başka herhangi bir kontrolden önce zaman damgası koruyucusunda reddeder.
• Herkese aynı kapı. Bir copy-işlem istemcisi, bir kurumsal API entegrasyonu ve bir perakende cüzdanı, hepsi aynı sınırdan yetkilendirir, imzalar, commit eder ve gönderir. Platformun bir emir sınıfını farklı bir kural altında kabul etmesini sağlayan ayrıcalıklı bir şerit yok.