GATEWAY VE OKUMA MODELİ
Gateway, her işlem istemcisi ile runtime arasındaki kamuya açık sınırdır. $49-$299 değerlendirme penceresindeki challenge emirleri, 90/10 bölünmesindeki fonlu gerçekleşmeler, lider tablosu okumaları, çekim talepleri — hepsi aynı giriş üzerinden geçer ve aynı persiste durumdan okur. Bir copy-trade botu, perakende mobil uygulama ve kurumsal bir API istemcisi aynı yüzeyi görür; bu yüzden üçüncü taraflar Dexter üzerinde izin istemeden panolar inşa edebilir ve kurallar tek bir tüketici için sessizce gevşetilemez.
Gateway, kalıcı runtime çıktısından stabil yanıtlar sunar, asla runtime in-memory işlem durumundan değil. Bu sayede cache'leyebilir, sürümleyebilir, fallback yapabilir ve yük altında deterministik kalabilir — runtime meşgul, boşta veya yeniden başlatılırken her okuma aynı kod yolundan geçer. Üretimde ayrıca imzalı işlem akışı için dar bir giriş sınırıdır: agent yetkilendirmesi, zamanlama kontrolleri, IOC uygulaması ve order-commit gönderimi, tek bir bayt eşleştirme döngüsü'a ulaşmadan burada gerçekleşir.
| Gateway tarafından açığa çıkarılan yüzey | Destekleyen kaynak |
|---|---|
| Market özetleri ve emir defterleri | Runtime snapshot'ları, emir defteri kayıtları, mark ve index durumu |
| Hesap, gerçekleşmeler, fonlama geçmişi | Kalıcı hesap özetleri, fill logları, fonlama uzlaşması kayıtları |
| Yayın ve canlılık | Root geçmişi, tazelik pencereleri, sequence ve yapılandırma commitment meta verisi |
| Platform duruş sinyalleri | Sağlık snapshot'ları, market-durum çıktıları, oracle kaynak sağlığı |
| İmzalı işlem girişi | POST /agent/authorize signer politikası; createdAtTs / goodTilTs pencereleri; IOC disiplini; gerekli order-commit gönderimi |
#Gateway'in asıl sahibi olduğu şey
Gateway, sunum, normalleştirme ve imzalı girişteki kabul politikasının sahibidir. Matching, mark oluşumu, saklama veya uzlaşma kesinliği onun sahibinde değildir — bunlar runtime ve Base kontratlarında yaşar. İşi, zaten kalıcılaştırılmış durum üzerinde tek stabil bir arayüz açığa çıkarmak ve işlem ön kapısını giriş kurallarının açık ve denetlenebilir kalacağı kadar dar tutmaktır.
Genel market okumaları, kimliği doğrulanmış hesap görünümleri ve kısıtlı servis rotaları arasındaki ayrım tek bir model olarak değil, üç farklı izin modeli olarak uygulanır. Kendi pozisyonlarını okuyabilen bir cüzdan başka bir cüzdanın pozisyonlarını okuyamaz; kimliği doğrulanmamış bir tüketici emir defterini okuyabilir ama fill geçmişini okuyamaz; dahili bir servis rotası kamuya açık girişten hiç çağrılamaz. Gateway bu nedenle yalnızca UI katmanı değil, güvenlik sınırının bir parçasıdır.
Üçüncü taraf yüzeyleri — copy-trade rayları, mobil istemciler, kurumsal API tüketicileri — kendi uygulamamızla aynı izin modeli altında aynı kayıtları okur. Paralel protokol katmanları değil, bir sınırın downstream tüketicileridir. Özel endpoint'lere sessiz erişimi olan bir "partner" kademesi yoktur.
#Kalıcı okuma modelinin rolü
Runtime sürekli olarak snapshot'lar, gerçekleşmeler, fonlama kayıtları, market özetleri, hesap özetleri ve sağlık sinyallerini kalıcı bir depoya yazar. Gateway o depodan okur, asla runtime işlem belleğinden değil. İki sonuç: her tüketici aynı sequence noktasında aynı durumu görür ve bir runtime yeniden başlatması asla stale veya split-brain okuma üretmez.
signed user flow
-> POST /agent/authorize sets signer policy
-> gateway checks createdAtTs / goodTilTs / IOC / sequence policy
-> gateway submits required order commitment
-> runtime updates exchange state
-> snapshots, gerçekleşmeler, fonlama, and health are persisted
-> gateway normalizes those records
-> every app and API consumer reads one stable surfaceHibrit platformlar, her ekran farklı görünmez bir kaynak tarafından desteklendiğinde denetlenemez hale gelir. Okuma modeli, Dexter'da bunu önleyen şeydir. Gateway platformu açıklar; platformu kararlaştırmaz. Bir trader'ın PnL'ini, bir lider tablosu sırasını veya bir sigorta bakiyesini yeniden üreten herkes bunu gateway'in sunduğu aynı kalıcı kayıtlardan yapabilir.