Grid Botun İç Mekanizması

Neden İç Mekanizmayı Bilmelisiniz?

Grid botu bir “kara kutu” olarak kullanabilirsiniz — parametreleri girin, botu başlatın, kâr gelsin. Ancak iç mekanizmayı anlamak size iki kritik avantaj sağlar: (1) bot beklenmedik davrandığında nedenini anlayabilirsiniz, (2) parametreleri daha bilinçli seçebilirsiniz. Bu yazıda Gridera grid botunun başlatmadan kapatmaya tüm yaşam döngüsünü inceliyoruz.

Faz 1: Başlangıç (Startup)

Bot başlatıldığında sırayla şu adımlar gerçekleşir:

1. Config Yükleme

YAML config dosyası okunur ve doğrulanır. Grid aralığı (grid_low, grid_high), seviye sayısı (grid_levels), emir büyüklüğü (order_usd), leverage ve diğer parametreler yüklenir. Eksik veya geçersiz parametre varsa bot başlamaz.

2. RunLock Kontrolü

Redis üzerinden aynı kullanıcı ve aynı sembol için başka bir bot instance’ı çalışıp çalışmadığını kontrol eder. Eğer çalışıyorsa yeni bot başlamaz. Bu, aynı grid’i iki botun aynı anda yönetmesini engeller — aksi halde duplicate emirler ve pozisyon karışıklığı oluşurdu.

3. Exchange Bağlantısı

Pacifica DEX API’sine bağlanılır. API anahtarı (Solana private key) ile kimlik doğrulanır. WebSocket bağlantıları kurulur: fiyat akışı, emir durum bildirimleri ve işlem geçmişi.

4. Bakiye Kontrolü

Hesaptaki mevcut bakiye kontrol edilir. Minimum gereksinim: order_usd x grid_levels x 1.2. Bu çarpandaki 1.2, ücretler ve küçük fiyat değişimleri için güvenlik tamponudur. Yetersiz bakiye durumunda bot başlamaz.

5. Leverage Senkronizasyonu

Config’deki leverage değeri ile borsadaki mevcut leverage değeri karşılaştırılır. Farklı ise borsadaki değer config’e göre güncellenir. Bu adım, yanlış leverage ile işlem yapılmasını engeller.

6. Başlangıç Snapshot

REST API üzerinden mevcut açık emirler ve işlem geçmişi cursor’u (trade_cursor) alınır. Bu snapshot, botun “neredeyiz?” sorusunun cevabını verir. Eğer önceki bir oturumdan kalan açık pozisyonlar varsa, bunların TP emirleri kontrol edilir ve eksik TP’ler gönderilir.

7. Ana Döngüye Giriş

Tüm hazırlıklar tamamlandıktan sonra bot run_forever() döngüsüne girer. Bu döngü, bot kapatılana kadar devam eder.

Faz 2: Ana Döngü (Her 15 Saniye)

Ana döngü, botun kalbidir. Varsayılan olarak her 15 saniyede bir çalışır (config ile ayarlanabilir). Her cycle’da şu adımlar sırayla gerçekleşir:

Adım 1-2: Fiyat ve Veri Kontrolü

Mark price (güncel fiyat) alınır. Öncelikle WebSocket’ten gelen fiyat kullanılır; WebSocket kapalıysa REST API’ye fallback yapılır. Fiyat alınamazsa cycle atlanır — fiyat olmadan emir göndermek tehlikelidir.

Adım 3-4: REST Snapshot

Borsadaki açık emirler REST API üzerinden çekilir. Bu “tek gerçek kaynak” (single source of truth) olarak kullanılır. Her cycle’da tek bir REST çağrısı yapılır ve tüm cycle boyunca bu snapshot kullanılır. REST çağrısı başarısız olursa cycle tamamen atlanır — boş snapshot geldiğinde “tüm emirler eksik” sanılıp gereksiz yeni emirler gönderilmesi önlenir.

Ayrıca veri tazeliği (staleness) kontrol edilir: son başarılı fiyat veya emir verisi 15 saniyeden eski ise emir gönderilmez.

Adım 5-6: Grid Break Kontrolü

Mark price, grid aralığının (grid_low, grid_high) dışında mı? Eğer fiyat alt sınırın altına veya üst sınırın üstüne çıktıysa grid break tetiklenir. Ancak anlık spike’ları önlemek için iki güvenlik mekanizması vardır:

• Buffer: Sınırın %0.2 ötesinde tampon bölge (ayarlanabilir)
• Zaman onayı: Fiyatın belirli bir süre boyunca (varsayılan 30 saniye) sürekli dışarıda kalması gerekir

Her iki koşul da sağlanırsa bot clean shutdown ile güvenle kapanır.

Adım 7: Trade History Sync (Fill Tespiti)

Bu adım, botun envanter yönetiminin temelidir. Trade history WebSocket üzerinden gelen yeni işlemler (fill’ler) işlenir:

BUY Fill (open_long) geldiğinde:

1. Hangi grid seviyesinde olduğu belirlenir
2. grid_state’te pozisyon açılır
3. Bu seviye için TP emri gönderilir

TP Fill (close_long) geldiğinde:

1. Hangi grid seviyesine ait olduğu belirlenir
2. grid_state’ten pozisyon kapatılır
3. Tüm ilgili izleme verileri temizlenir (pending, lock, vb.)

Kritik kural: grid_state (envanter) YALNIZCA trade history üzerinden güncellenir. Başka hiçbir mekanizma pozisyon açıp kapatamaz. Bu kural, envanterin her zaman gerçek işlemlerle tutarlı olmasını garanti eder.

Adım 8-9: TP Restore

Filled (alınmış) seviyelerde TP emri eksik mi? Bazı durumlarda TP emri başarısız olabilir veya borsa tarafından iptal edilmiş olabilir. Bu adım eksik TP’leri tespit eder ve yeniden gönderir.

Adım 10: Duplicate BUY Temizliği

Aynı grid seviyesinde birden fazla BUY emri mi var? Bu nadir bir durumdur ama oluşursa fazlalıklar iptal edilir. 60 saniyede bir çalışır.

Adım 11: Reconciliation (Uzlaştırma)

Botun en önemli güvenlik mekanizmasıdır. REST snapshot ile yerel state karşılaştırılır:

1. Eksik BUY tespiti: Grid seviyelerinden hangileri için emir olması gerekirken yok?
2. Eksik TP tespiti: Pozisyonu olan hangi seviyelerin TP emri eksik?
3. Orphan TP tespiti: Pozisyonu olmayan ama TP emri açık olan seviyeler var mı?

Bulunan eksiklikler hemen düzeltilmez. Bunun yerine bir confirm streak mekanizması vardır: aynı eksiklik 5 ardışık cycle boyunca tespit edilirse “gerçekten eksik” olarak onaylanır ve düzeltme işlemi başlatılır. Bu 5 cycle şarttır, geçici API gecikmelerinin yanlış alarm vermesini önler.

Adım 12-18: Grid Candidates ve Emir Gönderme

Mark price’ın altındaki tüm grid seviyeleri potansiyel BUY adaylarıdır. Her aday için güvenlik filtreleri uygulanır:

Tüm filtreleri geçen seviyeler için BUY emirleri gönderilir. Tek seferde maksimum 10 emir (Pacifica API batch limiti).

Faz 3: State Yönetimi

grid_state — Tek Gerçek Kaynak

grid_state, her grid seviyesinin durumunu tutan in-memory (bellekte) veri yapısıdır:

• Pozisyon: Seviyede açık pozisyon var mı? Ne kadar?
• TP: Seviye için TP emri gönderildi mi?
• Lock: Seviye kilitli mi? (emir gönderildi, sonuç bekleniyor)

Bu state geçicidir — bot yeniden başladığında sıfırlanır ve trade history sync ile yeniden inşa edilir.

trade_cursor — Dedup Mekanizması

trade_cursor, işlenmiş son işlemin ID’sidir. Her yeni fill geldiğinde, fill’in ID’si cursor ile karşılaştırılır. Eğer fill ID’si cursor’dan küçük veya eşitse, bu fill zaten işlenmiştir ve atlanır. Bu mekanizma aynı fill’in iki kez işlenmesini önler.

Kritik: trade_cursor asla sıfırlanmaz. Bot yeniden başladığında bile korunur. Sıfırlanırsa tüm geçmiş fill’ler tekrar işlenir ve envanter bozulur.

Çoklu Koruma Katmanları

Grid bot, aynı seviyede duplicate emir gönderimini önlemek için birçok koruma katmanı kullanır:

grid_locks (TTL: 180s) ──┐
pending_levels (TTL: 15s)─┤── Hepsi aynı seviyeyi farklı
in_flight_orders (TTL: 20s)┤   zaman pencerelerinde korur
REST snapshot kontrolü ───┘

Bu katmanlar birbirini tamamlar. Biri başarısız olsa bile diğerleri devreye girer.

Faz 4: Kapanış (Clean Shutdown)

Bot kapanışı tetiklendiğinde (shutdown.flag, grid break, TP/SL) sırayla şu adımlar gerçekleşir:

Bu sıralama kasıtlıdır. Örneğin adım 2’den önce adım 1 yapılmazsa, WebSocket’ten gelen yeni bir fill, iptal edilen emrin yerine yeni emir tetikleyebilir. Adım 4’ten önce adım 3 yapılmazsa, pozisyon kapatılırken TP emri de tetiklenebilir.

Clean shutdown idempotent’tır: iki kez çağrılsa bile sadece bir kez çalışır (_gridera_shutdown_done flag’i ile).

WebSocket Rolleri

Bot üç farklı WebSocket bağlantısı kullanır:

Önemli ayrım: OrderWS bir emrin “filled” olduğunu bildirir ama envanter güncellemez. Envanter YALNIZCA TradeHistoryWS üzerinden güncellenir. Bu ayrım, fill verilerinin tek ve tutarlı bir kaynaktan gelmesini garanti eder.

Botun Karar Ağacı Özeti

Her cycle’da botun karar süreci şu şekilde özetlenebilir:

Fiyat var mı? ─── Hayır → Atla
    │ Evet
REST başarılı mı? ─── Hayır → Atla
    │ Evet
Veri taze mi? ─── Hayır → Atla
    │ Evet
Grid break mi? ─── Evet → Clean Shutdown
    │ Hayır
Fill var mı? → İşleme (pozisyon aç/kapat, TP gönder)
    │
Reconciliation zamanı mı? → Eksik tespit et, streak say
    │
Grid candidates → Filtreleri uygula → Safe buys
    │
Emir gönder (max 10)

Özet

• Bot yaşam döngüsü: Startup (config, lock, bağlantı, bakiye) → Ana Döngü (15s cycle) → Shutdown (6 adımlı temiz kapanış).
• Her cycle: fiyat al → REST snapshot → grid break kontrol → fill işle → reconciliation → emir gönder.
• grid_state yalnızca trade history fill’leri ile güncellenir. Başka hiçbir mekanizma envanter değiştirmez.
• trade_cursor, fill dedup mekanizmasıdır ve asla sıfırlanmaz.
• Reconciliation, 5 ardışık cycle onayı gerektirir (false positive önlemi).
• Clean shutdown 6 adımlı, sıralı ve idempotent bir süreçtir.
• Çoklu koruma katmanları (grid_locks, pending, in_flight, REST) duplicate emirleri önler.

Sonraki Adım

Botun iç mekanizmasını anladıktan sonra, grid trading terimlerini hatırlamak için sözlüğe göz atın:

Grid Trading Sözlüğü →