Grid Botun Ic Mekanizmasi

Neden Ic Mekaizmayi Bilmelisiniz?

Grid botu bir “kara kutu” olarak kullanabilirsiniz — parametreleri girin, botu baslatin, kar gelsin. Ancak ic mekanizmayi anlamak size iki kritik avantaj saglar: (1) bot beklenmedik davrandiginda nedenini anlayabilirsiniz, (2) parametreleri daha bilinli secebilirsiniz. Bu yazida Gridera grid botunun baslatmadan kapatmaya tum yasam dongusunu inceliyoruz.

Faz 1: Baslangic (Startup)

Bot baslatildiginda sirayla su adimlar gerceklesir:

1. Config Yukleme

YAML config dosyasi okunur ve dogrulanir. Grid araligi (grid_low, grid_high), seviye sayisi (grid_levels), emir buyuklugu (order_usd), leverage ve diger parametreler yuklenir. Eksik veya gecersiz parametre varsa bot baslamaz.

2. RunLock Kontrolu

Redis uzerinden ayni kullanici ve ayni sembol icin baska bir bot instance’i calisip calismadigini kontrol eder. Eger calisiyorsa yeni bot baslamaz. Bu, ayni grid’i iki botun ayni anda yonetmesini engeller — aksi halde duplicate emirler ve pozisyon karitisikligi olusurdu.

3. Exchange Baglantisi

Pacifica DEX API’sine baglanilir. API anahtari (Solana private key) ile kimlik dogrulanir. WebSocket baglantilari kurulur: fiyat akisi, emir durum bildirimleri ve islem gecmisi.

4. Bakiye Kontrolu

Hesaptaki mevcut bakiye kontrol edilir. Minimum gereksinim: order_usd x grid_levels x 1.2. Bu carpaindaki 1.2, ucretler ve kucuk fiyat degisimleleri icin guvenlik tamponudur. Yetersiz bakiye durumunda bot baslamaz.

5. Leverage Senkronizasyonu

Config’deki leverage degeri ile borsadaki mevcut leverage degeri karsilastirilir. Farkli ise borsadaki deger config’e gore guncellenir. Bu adim, yanlis leverage ile islem yapilmasini engeller.

6. Baslangic Snapshot

REST API uzerinden mevcut acik emirler ve islem gecmisi cursor’u (trade_cursor) alinir. Bu snapshot, botun “neredeyiz?” sorusunun cevabini verir. Eger onceki bir oturumdan kalan acik pozisyonlar varsa, bunlarin TP emirleri kontrol edilir ve eksik TP’ler gonderilir.

7. Ana Donguye Giris

Tum hazirliklar tamamlandiktan sonra bot run_forever() dongusune girer. Bu dongu, bot kapatilana kadar devam eder.

Faz 2: Ana Dongu (Her 15 Saniye)

Ana dongu, botun kalbidir. Varsayilan olarak her 15 saniyede bir calisir (config ile ayarlanabilir). Her cycle’da su adimlar sirayla gerceklesir:

Adim 1-2: Fiyat ve Veri Kontrolu

Mark price (guncel fiyat) alinir. Oncelikle WebSocket’ten gelen fiyat kullanilir; WebSocket kapaliysa REST API’ye fallback yapilir. Fiyat alinamazsa cycle atlanir — fiyat olmadan emir gondermek tehlikelidir.

Adim 3-4: REST Snapshot

Borsadaki acik emirler REST API uzerinden cekilir. Bu “tek gercek kaynak” (single source of truth) olarak kullanilir. Her cycle’da tek bir REST cagrisi yapilir ve tum cycle boyunca bu snapshot kullanilir. REST cagrisi basarisiz olursa cycle tamamen atlanir — bos snapshot geldiginde “tum emirler eksik” sanilip gereksiz yeni emirler gonderilmesi onlenir.

Ayrica veri tazeligi (staleness) kontrol edilir: son basarili fiyat veya emir verisi 15 saniyeden eski ise emir gonderilmez.

Adim 5-6: Grid Break Kontrolu

Mark price, grid araliginin (grid_low, grid_high) disinda mi? Eger fiyat alt sinirin altina veya ust sinirin ustune ciktiysa grid break tetiklenir. Ancak anlik spike’lari onlemek icin iki guvenlik mekanizmasi vardir:

• Buffer: Sinirin %0.2 otesinde tampon bolge (ayarlanabilir)
• Zaman onay: Fiyatin belirli bir sure boyunca (varsayilan 30 saniye) surekli disarida kalmasi gerekir

Her iki kosul da saglanirsa bot clean shutdown ile guvenle kapanir.

Adim 7: Trade History Sync (Fill Tespiti)

Bu adim, botun envanter yonetiminin temelidir. Trade history WebSocket uzerinden gelen yeni islemler (fill’ler) islenir:

BUY Fill (open_long) geldiginde:

1. Hangi grid seviyesinde oldugu belirlenir
2. grid_state’te pozisyon acilir
3. Bu seviye icin TP emri gonderilir

TP Fill (close_long) geldiginde:

1. Hangi grid seviyesine ait oldugu belirlenir
2. grid_state’ten pozisyon kapatilir
3. Tum ilgili izleme verileri temizlenir (pending, lock, vb.)

Kritik kural: grid_state (envanter) YALNIZCA trade history uzerinden guncellenir. Baska hicbir mekanizma pozisyon acip kapatamaz. Bu kural, envanterin her zaman gercek islemlerle tutarli olmasini garanti eder.

Adim 8-9: TP Restore

Filled (alinmis) seviyelerde TP emri eksik mi? Bazi durumlarda TP emri basarisiz olabilir veya borsa tarafindan iptal edilmis olabilir. Bu adim eksik TP’leri tespit eder ve yeniden gonderir.

Adim 10: Duplicate BUY Temizligi

Ayni grid seviyesinde birden fazla BUY emri mi var? Bu nadir bir durumdur ama olusursa fazlaliklar iptal edilir. 60 saniyede bir calisir.

Adim 11: Reconciliation (Uzlastirma)

Botun en onemli guvenlik mekanizmasidir. REST snapshot ile yerel state karsilastirilir:

1. Eksik BUY tespiti: Grid seviyelerinden hangileri icin emir olmasi gerekirken yok?
2. Eksik TP tespiti: Pozisyonu olan hangi seviyelerin TP emri eksik?
3. Orphan TP tespiti: Pozisyonu olmayan ama TP emri acik olan seviyeler var mi?

Bulunan eksiklikler hemen duzeltilmez. Bunun yerine bir confirm streak mekanizmasi vardir: ayni eksiklik 5 ardisik cycle boyunca tespit edilirse “gercekten eksik” olarak onaylanir ve duzeltme islemi baslatilir. Bu 5 cycle sartir, gecici API gecikmelerinin yanlis alarm vermesini onler.

Adim 12-18: Grid Candidates ve Emir Gonderme

Mark price’in altindaki tum grid seviyeleri potansiyel BUY adaylaridir. Her aday icin guvenlik filtreleri uygulanir:

Tum filtreleri gecen seviyeler icin BUY emirleri gonderilir. Tek seferde maksimum 10 emir (Pacifica API batch limiti).

Faz 3: State Yonetimi

grid_state — Tek Gercek Kaynak

grid_state, her grid seviyesinin durumunu tutan in-memory (bellekte) veri yapiisidir:

• Pozisyon: Seviyede acik pozisyon var mi? Ne kadar?
• TP: Seviye icin TP emri gonderildi mi?
• Lock: Seviye kilitli mi? (emir gonderildi, sonuc bekleniyor)

Bu state gecicidir — bot yeniden basladiginda sifirlanir ve trade history sync ile yeniden insa edilir.

trade_cursor — Dedup Mekanizmasi

trade_cursor, islenmis son islemin ID’sidir. Her yeni fill geldiginde, fill’in ID’si cursor ile karsilastirilir. Eger fill ID’si cursor’dan kucuk veya esitse, bu fill zaten islenmistir ve atlanir. Bu mekanizma ayni fill’in iki kez islenmesini onler.

Kritik: trade_cursor asla sifirlanmaz. Bot yeniden basladiginda bile korunur. Sifirlanirsa tum gecmis fill’ler tekrar islenir ve envanter bozulur.

Coklu Koruma Katmanlari

Grid bot, ayni seviyede duplicate emir gonderimini onlemek icin bircok koruma katmani kullanir:

grid_locks (TTL: 180s) ──┐
pending_levels (TTL: 15s)─┤── Hepsi ayni seviyeyi farkli
in_flight_orders (TTL: 20s)┤   zaman pencerelerinde korur
REST snapshot kontrolu ───┘

Bu katmanlar birbirini tamamlar. Biri basarisiz olsa bile digerleri devreye girer.

Faz 4: Kapanis (Clean Shutdown)

Bot kapanisi tetiklendiginde (shutdown.flag, grid break, TP/SL) sirayla su adimlar gerceklesir:

Bu siralama kasitlidir. Ornegin adim 2’den once adim 1 yapilmazsa, WebSocket’ten gelen yeni bir fill, iptal edilen emrin yerine yeni emir tetikleyebilir. Adim 4’ten once adim 3 yapilmazsa, pozisyon kapatilirken TP emri de tetiklenebilir.

Clean shutdown idempotent’tir: iki kez cagirilsa bile sadece bir kez calisir (_gridera_shutdown_done flag’i ile).

WebSocket Rolleri

Bot uc farkli WebSocket baglantisi kullanir:

Onemli ayrim: OrderWS bir emrin “filled” oldugunu bildirir ama envanter guncellemez. Envanter YALNIZCA TradeHistoryWS uzerinden guncellenir. Bu ayrim, fill verilerinin tek ve tutarli bir kaynaktan gelmesini garanti eder.

Botun Karar Agaci Ozeti

Her cycle’da botun karar sureci su sekilde ozetlenebilir:

Fiyat var mi? ─── Hayir → Atla
    │ Evet
REST basarili mi? ─── Hayir → Atla
    │ Evet
Veri taze mi? ─── Hayir → Atla
    │ Evet
Grid break mi? ─── Evet → Clean Shutdown
    │ Hayir
Fill var mi? → Isleme (pozisyon ac/kapat, TP gonder)
    │
Reconciliation zamani mi? → Eksik tespit et, streak say
    │
Grid candidates → Filtreleri uygula → Safe buys
    │
Emir gonder (max 10)

Ozet

• Bot yasam dongusu: Startup (config, lock, baglanti, bakiye) → Ana Dongu (15s cycle) → Shutdown (6 adimli temiz kapanis).
• Her cycle: fiyat al → REST snapshot → grid break kontrol → fill isle → reconciliation → emir gonder.
• grid_state yalnizca trade history fill’leri ile guncellenir. Baska hicbir mekanizma envanter degistirmez.
• trade_cursor, fill dedup mekanizmasidir ve asla sifirlanmaz.
• Reconciliation, 5 ardisik cycle onay gerektirir (false positive onlemi).
• Clean shutdown 6 adimli, sirali ve idempotent bir surecti.
• Coklu koruma katmanlari (grid_locks, pending, in_flight, REST) duplicate emirleri onler.

Sonraki Adim

Botun ic mekanizmasini anladiktan sonra, grid trading terimlerini hatirlmak icin sozluge goz atin:

Grid Trading Sozlugu →