OKX API otomatik işlem risk yönetimi: pozisyon, emir ve hata yönetimi

Çoğu kişi algonun riskini piyasadan sanır: yönü yanlış görürsen kaybedersin. Ama bir süre betik çalıştırmış biri sana şunu söyler: hesabı anında sıfırlayan şey çoğu zaman piyasa değil, senin kendi kodundur — ters yazılmış bir yön, durdurulamayan bir döngü, bağlantı koptuktan sonraki bir çift emir. Elle işlem yaparken onaya basmadan önce son bir bakışın vardır; betiğin bu bakışı yoktur, sadakatle, art arda hatayı uygular.

Bu yazıda biz (MeowQuant editör ekibi) özellikle algo risk yönetimini, hem de «kod düzeyinde nasıl önlenir» açısından ele alıyoruz; «pozisyonu kontrol et» gibi havada laflar etmiyoruz. API işlemine özgü birkaç risk türünü açacağız, kopyalayabileceğin zarar durdur, bölünmüş pozisyon, yeniden deneme kodları vereceğiz, sonra hesap güvenliğinin alt sınırını ve «küçük tutarla soğuk başlangıç» sahaya çıkış sırasını netleştireceğiz. Okuyunca betiğine birkaç fren takabilmelisin: tek emrin üst sınırı olur (toplam için yalnızca bir iskelet veriyoruz; eksik kalan kontroller metinde tek tek sayıldı, onları tamamlamak sana kalıyor), zarar durdur senin ekran başında beklemene bağlı olmaz, yeniden göndermeden önce durum sorgulanır, yetkiler asgariye indirilir. Frenlerin tamam olması «kaybetmeyeceksin» demek değildir; ama bir şey ters gittiğinde zararın sınırının nerede olduğunu bilirsin.

API işleminin özgün riskleri

Elle işlem ile API otomatik işlemin risk türleri farklıdır. Elle işlemin başlıca düşmanı duygu ve yargıdır; API işlemi bunun üstüne bir de «makineye özgü» bir risk türü ekler. Bunları tanımadan frenin nereye takılacağını bilemezsin.

Programın kaçması

En tipik olanı. Bir mantık yanlış yazıldı — alış-satış yönü ters, zarar durdur koşulu tersine yazılmış, döngünün çıkış koşulu eksik — program insan gibi durup «bir yanlışlık mı var» diye düşünmez, yanlış talimatı tekrar tekrar uygular. İnsan elle bir yanlış emir verince fark edebilir, betik saniyeler içinde onlarca yanlış emir verir. Kaçmanın yıkıcı gücü, tam da «sadakatinde»dir.

Çift emir

Ağ titremesi, istek zaman aşımı anında en sık çıkar. Bir emir isteği gönderdin, yanıt gelmedi, betik başarısız sandı ve yeniden gönderdi — ama aslında ilk emir gerçekleşmişti, sonuçta iki emir verdin. Bu çiftin/pozisyonun iki katına çıkması, riskin iki katına çıkması demektir. Çift emir genelde mantık hatası değil, «belirsiz ara durumun» kötü yönetilmesidir.

Bağlantı kopması ve düşme

Betik senin bilgisayarında ya da sunucunda çalışır, ağ koptuğu an borsayla bağlantısı kesilir. Kötü durum şudur: pozisyonun piyasada açıkta kalmışken, onu koruması gereken zarar durdur mantığı da betikle birlikte düşer. Sen yeniden bağlandığında durum çoktan değişmiş olabilir. Bağlantı kopması riskinin özü, tüm korumayı «betik hep çevrimiçi» varsayımına yüklememektir.

Pozisyon yönetimi ve bölünmüş pozisyon

Risk yönetiminin ilk duvarı, hiçbir tek hatanın tüm sermayene zarar verememesidir. Bu, pozisyon kurallarıyla sağlanır; üstelik bu kurallar koda gömülmeli, anlık iradene bırakılmamalıdır.

Bizim hep uyduğumuz birkaç ilke:

• Tek emir üst sınırı koy. Hiçbir emir toplam sermayenin belli bir sabit oranını (örneğin %1–%2) aşmasın. Böylece bu emrin yönü tamamen yanlış olsa bile zararın bir tavanı olur.
• Toplam pozisyon üst sınırı koy. Tüm açık pozisyonların toplamı bir üst tutarı aşmasın, programa tüm sermayeni bir kerede sokma fırsatı verme.
• Bölünmüş pozisyon, hepsini bir kerede koyma. Sermayeyi birkaç parçaya bölüp kademe kademe gir, tek bir giriş noktasının yargı hatasının etkisini düşür.
• Betiğe nakit bırak. Hesapta her zaman işleme katılmayan bir kısım sermaye tut; hem tampon hem de sorun çıktığında elle işlem yapabileceğin alan.

Bunları kodda sert kısıtlara dönüştür, emir vermeden önce kontrol et, sağlanmazsa emri reddet. Aşağıdaki parça bir iskelettir, olduğu gibi gerçek hesapta çalıştırılamaz — yalnızca «tek emir üst sınırı» maddesini uygular; eksikleri kodun hemen ardında tek tek sayıyoruz:

MAX_PER_ORDER_RATIO = 0.02   # Tek emir, sermaye tabanının %2'sini aşmasın
MAX_TOTAL_RATIO     = 0.30   # Toplam pozisyon tabanın %30'unu aşmasın (bu iskelette uygulanmadı)

def check_position_limit(okx, symbol, order_value_usdt):
    if not (order_value_usdt > 0):
        raise ValueError('Emir tutarı pozitif olmalı')

    bal = okx.fetch_balance()
    usdt_total = bal['USDT']['total']      # Dikkat: bu yalnızca USDT bakiyesidir, hesabın toplam özkaynağı değil

    # Tek emir üst sınırı: USDT bakiyesini taban almak, yalnızca
    # "spot hesap, neredeyse tamamı USDT" gibi basit durumda yaklaşık doğrudur
    if order_value_usdt > usdt_total * MAX_PER_ORDER_RATIO:
        raise ValueError('Tek emir pozisyon sınırı aşıldı, emir reddedildi')

    # TODO: Toplam pozisyon üst sınırı (MAX_TOTAL_RATIO) henüz yok;
    # bu haliyle kullanmak, hiç toplam hacim kısıtı olmaması demektir
    return True

Bunun neden yalnızca iskelet sayıldığı şurada: en az dört şey eksik ve her eksik, «üst sınırı» kâğıt üstünde bırakabilir:

• Sermaye tabanı nasıl hesaplanıyor. bal['USDT']['total'] tek bir varlığın, USDT'nin bakiyesidir. Elinde BTC, ETH de varsa ya da vadeli hesap çalıştırıyorsan, asıl taban tek bir değerleme ölçüsüyle çevrilmiş hesap özkaynağı olmalı, bu tek sayı değil.
• Mevcut pozisyon ve açık emirlerin riski. Toplam pozisyon üst sınırının anlamlı olması için hâlihazırdaki pozisyonu ve emir defterinde duran, her an gerçekleşebilecek emirleri de hesaba katman gerekir. Yalnızca «bu emir ne kadar» diye bakarsan, arka arkaya on emir yine sınırı aşar.
• Eşzamanlı emir. Birkaç strateji bu fonksiyonu aynı anda çağırırsa, her biri aynı bakiyeyi okuyup «aşmadı» diye karar verip hep birlikte emir verebilir. Ya emir yolunu kilitle ve sıraya sok, ya da yerelde «ayrılmış limit» defteri tut.
• Girdinin kendisinin geçerliliği. Tutar pozitif olmalı — yukarıdaki ilk satır tam da bunun için eklendi. Negatif ya da sıfır bir değer karşılaştırmayı anlamsız kılar.

İskelet iskelettir ama yönü doğrudur: «pozisyonu kontrol etmem lazım» iradesini, betiğin emir vermeden geçmesi zorunlu bir kapıya çevirir. İrade sallanır, kod sallanmaz. Sana düşen, yukarıdaki dört maddeyi tamamlayıp ondan sonra gerçek paraya çıkarmak.

Zarar durdur mutlaka programlı olmalı (kod)

Bu yazıdan tek bir cümle hatırlayacaksan, şunu hatırla: zarar durdur mutlaka programlı olmalı. Betik otomatik çalışır, ekranı 24 saat izleyemezsin; piyasa hızlı ters döndüğünde sen görüp elle kapatana kadar genelde birkaç fiyat kademesi geç kalmış olursun.

Programlı zarar durdurun iki yaklaşımı var, birlikte kullanmanı öneririz:

Yaklaşım bir: borsa tarafında koşullu emir / zarar durdur emri. Ana emri verirken aynı anda OKX'te bir zarar durdur emri as, borsa tetik fiyatında senin yerine pozisyonu otomatik kapatsın. En büyük faydası şu: betiğin düşse bile bu zarar durdur emri borsa tarafında çalışmaya devam eder. «Bağlantı kopunca pozisyon açıkta kalır» riskine karşı en güvenilir hamle budur.

Yaklaşım iki: betiğin yerel izleme + tetiklenince pozisyon kapatma. Betik döngüde pozisyonun zararını sürekli okur, koyduğun eşiği aşar aşmaz kendiliğinden pozisyon kapatma emri verir. Daha esnektir (takip eden zarar durdur, süreye dayalı zarar durdur vb. yapabilir) ama önkoşulu betiğin çevrimiçi olmasıdır.

Aşağıda yerel izlemeli zarar durdurun en yalın iskeleti, mantığı gösterir (gerçek hesap öncesi mutlaka demo hesapta doğrula):

import ccxt, time

# 🔴 Bu kod tetiklendiğinde «piyasa fiyatından satar» — anında gerçekleşen gerçek
#    bir işlemdir. Önce demo (Demo Trading) Key'iyle yeterince çalıştır, tetikleme
#    koşulunun ve miktarın doğru olduğunu gör, gerçek kimlik bilgilerini ondan
#    sonra düşün. Demo Key'i demo işlem ortamının içinde ayrıca oluşturulur;
#    gerçek hesabınkiyle aynı takım değildir.
okx = ccxt.okx({
    'apiKey':   'demo_apiKey',
    'secret':   'demo_secret',
    'password': 'demo_Passphrase',
    'enableRateLimit': True,
})

# Bu satır olmadan aşağıdaki zarar durdur, gerçek hesapta gerçek pozisyonu piyasadan kapatır
okx.set_sandbox_mode(True)

# Kendi kontrolün: 1 yazdırmak zorunda. None yazdırıyorsa devam etme
print(okx.headers.get('x-simulated-trading'))

symbol      = 'BTC/USDT'
entry_price = 60000      # Giriş ortalama fiyatın (örnek)
amount      = 0.001      # Pozisyon miktarı
stop_ratio  = 0.05       # %5 düşünce zarar durdur

while True:
    ticker = okx.fetch_ticker(symbol)
    last = ticker['last']
    drawdown = (entry_price - last) / entry_price

    if drawdown >= stop_ratio:
        okx.create_order(symbol, 'market', 'sell', amount)
        print(f'Zarar durdur tetiklendi, piyasa fiyatıyla kapatıldı @ {last}')
        break

    time.sleep(10)   # Yeterli aralık bırak, API'yi dövme

İki noktaya dikkat: bir, döngüde mutlaka sleep olmalı, yoksa istek sınırına çarparsın; iki, yerel zarar durdur yalnızca destektir, bağlantı kopunca son savunma hattı borsa tarafındaki zarar durdur emridir, ikisini birden yapmak en sağlamı.

Çift emir ve bağlantı kopmasını önleme

Çift emrin kökü, «önceki emir gerçekleşti mi emin değilim»dir. Önlemenin özü: kör kör yeniden gönderme, önce durumu doğrula.

İki yöntem birlikte kullanılır:

İstemci tarafı özel emir numarası (OKX belgelerinde adı clOrdId) kullan. Emir verirken kendi ürettiğin bir ID ekle. Borsa bunu mükerrerlik için kontrol eder, ama kontrolün kapsamı yalnızca hesabındaki henüz sonlanmamış emirlerdir — aynı ID hâlâ yaşayan (açık ya da kısmen gerçekleşmiş) bir emre denk gelirse istek reddedilir ve 51016 «istemci emir numarası zaten var» döner.

Sınır tam burada, iyi görmek gerekir: OKX belgelerine göre bir emir sonlanmış duruma geçtiğinde (tamamen gerçekleşti, iptal edildi), aynı clOrdId yeniden kullanılabilir. Yani «aynı anda iki kez gönderildi, ilki hâlâ emir defterinde duruyor» durumunu engeller; «önceki emir aslında gerçekleşmişti, yanıtı alamadın ve aynı ID ile bir kez daha gönderdin» durumunu engellemez — bu ikincisini borsa yepyeni bir emir olarak kabul eder. O yüzden clOrdId'yi bir idempotency garantisi sanma; o sadece bir tutamaktır.

Biçim tarafında da sert bir kural var: yalnızca harf ve rakam, en fazla 32 karakter. Yani str(uuid.uuid4()) gibi tireli, 36 karakterlik bir dize uygun değildir; .hex almak gerekir.

Mükerrerliği asıl önleyen aşağıdaki akıştır; clOrdId bu akışın elinde tuttuğu tutamaktan ibarettir:

1. Emir vermeden önce, «bu işin niyeti → clOrdId → durum» kaydını yerelde tut ve diske yaz; yalnızca bellekte tutma — süreç çökünce bellekteki her şey gider.
2. İstek zaman aşımına uğradığında ya da hiç yanıt gelmediğinde yeniden gönderme, önce bu clOrdId ile borsaya sor.
3. «Açık emirlerde yok» ile «gerçekleşmedi» aynı şey değildir. Emir gerçekleşip geçmişe düşmüş olabilir, bu yüzden sonlanmış durumları da kapsayan bir sorgu gerekir: clOrdId'yi emir detayı ucuna götür (açık emir listesi ucu bu filtreyi zaten tanımaz), gerekiyorsa gerçekleşme kayıtlarını da bir tur gez. Yalnızca açık emirlere bakıp karar vermek, bu adımın en sık yapılan hatasıdır.
4. Bu clOrdId'nin gerçekten var olmadığını doğruladıktan sonra yeniden gönderebilirsin.
5. Süreç yeniden başladığında ilk iş, yereldeki kayıttan durumu askıda kalmış niyetleri çıkarmak, hepsinin durumunu tek tek eşleştirmek, ancak ondan sonra stratejiyi çalıştırmaktır.

import ccxt, uuid

# clOrdId yalnızca harf ve rakam olabilir, en fazla 32 karakter.
# uuid4() dizeye çevrilince tireli ve 36 karakterdir, uygun değil; .hex 32 karakterlik saf harf-rakam verir.
def new_cid():
    return 'meow' + uuid.uuid4().hex[:16]     # 4 + 16 = 20 karakter, hepsi harf ve rakam


def save_intent(cid, **fields):
    """«Niyet → clOrdId → durum» kaydını diske yaz. SQLite de olur, düz dosya da;
    önemli olan süreç yeniden başlayınca geri okunabilmesi. Burası yalnızca örnek,
    kendin uygula."""
    ...


def find_order_by_cid(okx, symbol, cid):
    """Emri clOrdId ile sorgular. Bu, «emir detayı» ucundan geçer
    (GET /api/v5/trade/order) ve hem açık hem sonlanmış emirlere erişir.

    Dikkat: açık emir ve geçmiş listelerinin (orders-pending /
    orders-history) istek parametrelerinde clOrdId diye bir alan yoktur;
    params içine koyarsan sessizce yok sayılır — uç yine bir sayfa dolusu
    emir döndürür, sen yerelde filtrelersin, sayfalarda bulamayınca da
    «emir hiç girmemiş» sanırsın. Bu yüzden cid ile emir ararken o iki
    liste ucunu kullanma."""
    try:
        # ordId yerine None ver; ccxt bu kez params içindeki clOrdId ile sorgular
        return okx.fetch_order(None, symbol, params={'clOrdId': cid})
    except ccxt.OrderNotFound:
        return None


symbol = 'BTC/USDT'
cid = new_cid()

# 1) Önce diske yaz, sonra isteği gönder
save_intent(cid, symbol=symbol, side='buy', amount=0.001, price=50000, state='sending')

try:
    order = okx.create_order(
        symbol, 'limit', 'buy', 0.001, 50000,
        params={'clientOrderId': cid},        # ccxt bunu OKX'in clOrdId alanına eşler
    )
    save_intent(cid, state='placed')
except Exception as e:
    # 2) Zaman aşımı ya da yanıtsızlık: bu emrin girip girmediği şu an bilinmiyor, doğrudan yeniden gönderilmez
    print('Emrin sonucu bilinmiyor, önce sorgula:', e)
    found = find_order_by_cid(okx, symbol, cid)
    if found is None:
        # 3) Açık emirlere de geçmişe de bakıldı, yok olduğu doğrulandı — ancak şimdi yeniden gönderilir
        save_intent(cid, state='not_found_retry')
    else:
        # Girmiş; gerçek durumu kaydet, ikinci kez gönderme
        save_intent(cid, state=found['status'])

Zaman aşımı / bağlantı kopmasından sonra önce sorgula sonra tamamla. Yukarıdaki except dalı, bu kuralın kod hâlidir: isteğin zaman aşımına uğraması emrin başarısız olduğu anlamına gelmez, yalnızca sonucu bilmediğin anlamına gelir. Yeniden bağlanınca da aynı — önce fetch_open_orders, fetch_positions, gerekirse geçmiş emirler ve gerçekleşme kayıtlarıyla hesabın mevcut gerçek durumunu net gör, sonra stratejiyi sürdür. «Önce durumu sorgula, sonra eyleme geç»i yeniden bağlanmanın sabit ilk adımı yap, bağlantı kaybından doğan mükerrer işlemlerin çoğunu engellersin.

İstek sınırı, zaman aşımı ve yeniden deneme

Risk yönetimi yalnızca para kaybını önlemek değil, betiğin «kendi kendini çökertmesini» önlemeyi de kapsar. İstek sınırı ve zaman aşımı kötü ele alınırsa stratejin kritik anda işlevsiz kalır.

İstek sınırı: Başlatırken 'enableRateLimit': True aç, ccxt istekler arasına otomatik aralık koyar. Yüksek frekanslı döngüde ayrıca üstel geri çekilme ekle (bir çarpışta 1 saniye, sonra 2, 4 saniye bekle). Bu kısmı API yaygın hataları yazımızda daha ince anlattık, burada sadece vurguluyoruz: döngüde API dövüyorsan hız sınırı standart donanımdır.

Zaman aşımı: İsteğe net bir zaman aşımı süresi koy, betiğin bir istek yüzünden takılıp tamamen donmasına izin verme. ccxt'te 'timeout' (milisaniye) ayarlanabilir:

okx = ccxt.okx({
    'apiKey':   'senin_apiKey',
    'secret':   'senin_secret',
    'password': 'senin_Passphrase',
    'enableRateLimit': True,
    'timeout': 10000,     # Tek istek 10 saniye zaman aşımı, donmayı önler
})

Yeniden denemenin üst sınırı olsun. Ağ titremesinde yeniden deneyebilirsin ama bir maksimum sayı koy, yeterince çarpınca uyarı ver/dur, sonsuz yeniden deneme yapma. Sonsuz yeniden deneme zaten bir tür «programın kaçması»dır — sen fark etmeden istekleri tüketmeye, hatta tekrar tekrar işlem yapmaya devam eder.

Yetki ve IP beyaz listesi: güvenlik alt sınırı

Risk yönetiminin en alt katmanı hesap güvenliğidir. Betiği ne kadar sağlam yazarsan yaz, bilgiler sızarsa her şey biter. Burada neredeyse istisnasız iki alt sınır var:

Sadece «Okuma» ve «İşlem»i işaretle, «Çekim»i asla. Algo çalıştırmak çekim eylemine hiç ihtiyaç duymaz. Key'in çekim yetkisi yoksa, apiKey, secret, Passphrase üçlüsü bir gün sızsa bile kimse coin'lerini zincir üstündeki bir adrese çıkaramaz; çekimi bir kez işaretlersen, sızıntı kasanın anahtarını teslim etmek olur. Ama «çekimi işaretlememek» bir sigorta değil, üstelik tuttuğu alan çoğu kişinin sandığından dar: OKX belgelerindeki tanıma göre işlem yetkisinin kendisi zaten fon transferini (fon hesabı ↔ işlem hesabı, ana hesap ↔ alt hesaplar) ve bir kısım hesap ayarını kapsar, yani karşı taraf hesapların arasında parayı yine de gezdirebilir. Zarara gelince: yalnızca işlem yetkisi olan bir Key de seni sıfırlayabilir — Key'i ele geçiren kişi emir defteri sığ, işlem hacmi düşük bir işlem çiftinde kendi emrini girip karşı tarafta yine kendisi durabilir, ana paran «işlem zararı» olarak akıp gider ve dökümde her satır sıradan bir eşleşme gibi görünür. Yukarıdaki pozisyon ve zarar durdur kısıtları hasarı sınırlar, ama asıl ikinci savunma hattı IP beyaz listesidir — «çekimi işaretlememek»in yerine değil, onunla birlikte yapılmalı.

IP beyaz listesi kur. Betiğin sabit IP'li bir makinede çalışıyorsa (bulut sunucu, sabit genel IP'li ev interneti), o IP'yi Key'in beyaz listesine ekle, yalnızca ondan gelen isteği kabul et, güvenlik bir kademe daha yükselir. OKX'te her Key'e en fazla 20 IP bağlanabilir, IPv4/IPv6 ve ağ bloğu da desteklenir; yani «çıkış IP'si arada bir değişiyor» olması beyaz listeden vazgeçmeyi gerektirmez. Çıkış IP'si gerçekten oynaksa yön, bağlamamak değil çıkışı sabitlemektir (stratejiyi sabit IP'li bir makineye taşı) — bir de gözden kaçması kolay bir kural var: IP bağlanmamış, üstelik işlem ya da çekim yetkisi taşıyan bir Key, 14 gün hareketsiz kalırsa süresi dolar. Bağlasan da bağlamasan da, bilgileri yüklenebilecek koda gömme; ortam değişkeni ya da senkronize edilmeyen bir yapılandırma dosyası kullan.

Bu iki madde, önceki pozisyon ve zarar durdurla birlikte «en kötü durum gerçekleşse bile zararın bir sınırı olur» korumasını oluşturur. Key oluşturmanın somut adımları API'ye giriş yazımızda; Key açmadan önce bir de API yetki öz-kontrol listesiyle gözden geçirebilirsin.

Küçük tutarla soğuk başlangıç: gerçek para öncesi liste

Tüm kod düzeyi risk yönetimi kuruldu, gerçek hesaba çıkmadan son bir adım kaldı: baştan büyük pozisyon basma. Yeni strateji gerçek paraya çıktığında biz hep «küçük tutarla soğuk başlangıç» yaparız, sıra şöyle:

• Önce demo hesapta kesintisiz çalıştır. Birkaç tur iniş çıkışı kapsa, emir, iptal, zarar durdur, geri çağrının hepsinin beklendiği gibi olduğunu doğrula. Bu adım sıfır maliyetlidir, atlamak gerçek parayı test ortamı yapmaktır.
• Sonra çok küçük gerçek parayla soğuk başlat. Tutar, tamamı gitse bile üzülmeyeceğin kadar küçük olsun, onu eğitim parası say. Demo hesabın kopyalayamadığı kayma ve derinlik, ancak o zaman ortaya çıkar.
• İlk birkaç gün başında dur. Gerçekten elini çekme, gerçek davranışın demo hesapla aynı olduğunu, zarar durdurun gerçekten tetiklendiğini, çift emir olmadığını doğrula, sonra kademe kademe artır.
• Vadeli işlem ve kaldıraç en sona kalsın. Spot oturmadan kaldıraca dokunma. Kaldıraç yukarıdaki her risk türünü kat kat büyütür; yeni başlangıç aşamasında yalnızca spot yapmanı şiddetle öneririz.

Bu listeyi önceki kod kısıtlarıyla birleştirince betiğine taktığın yalnızca bir fren değil, birkaç fren olur: pozisyonun üst sınırı var, zarar durdur otomatik tetiklenir, yeniden göndermeden önce durum sorgulanır, bilgiler sızsa bile coin'ler zincir üstüne çıkarılamaz (yine de hesaplar arası transfer yapılabilir, kasıtlı kendi kendine işlemlerle bakiye eritilebilir, bu yüzden IP beyaz listesi hep yanında durur), sahaya çıkarken de önce küçük parayla denenir. Tek başına hiçbiri yeterli değil, birlikte «hata» ile «batma» arasına yeterli tampon koyar.

Sık düşülen bir risk kontrolü tuzağı

Sık sorulan sorular

Risk yönetimi kodu bir kez yazınca bitmiş olmaz, stratejinle birlikte büyür. Bu yazının listesini kaydet, her yeni strateji çıkışında bir kez gözden geçir. Sonra betiğin kararlılığını tamamlamak için API yaygın hataları yazısına bakabilirsin, yeni kodu da hep önce demo hesapta doğrula. Şu eski sözü unutma: önce ayakta kal, sonra kazancı konuş.