Orijinal Başlık: Bir Polymarket botu oluşturdum ve çeşitli parametre yapılandırmalarını test ettim, işte sonuçlar.

Orijinal Yazar: @the_smart_ape, Kripto Araştırmacısı

Orijinal Çeviri: Bitpush News

Birkaç hafta önce, kendi Polymarket botumu oluşturmaya karar verdim. Tam sürümüm oluşturmak bana birkaç haftaımı aldı.

Bu çabayı göstermeye istekliydim çünkü Polymarket'te gerçekten verimlilik açığı olduğunu gördüm; piyasada bu düşük verimlilikten kar elde eden bazı botlar olsa da, bu henüz yeterli değil ve bu pazardaki fırsat sayısı hala mevcut bot sayısından çok daha fazla.

Bot Oluşturma Mantığı

Bu botun mantığı, önceden manuel olarak uyguladığım bir stratejiye dayanmaktadır ve verimliliği artırmak için bu stratejiyi otomatik hale getirdim. Bot, "BTC 15 Dakika YUKARI/AŞAĞI (BTC 15-minute UP/DOWN)" pazarında çalışmaktadır.

Bot, gerçek zamanlı bir izleme programı çalıştırır ve mevcut BTC 15 dakikalık periyoda otomatik olarak geçebilir, WebSocket üzerinden en iyi alım/satım fiyatını aktarır, sabit bir terminal kullanıcı arayüzü gösterir ve metin komutlarıyla tam kontrol sağlar.

Manuel modda, doğrudan emir verebilirsiniz.

buy up <usd> / buy down <usd>: Belirli bir dolar tutarında alım yapar.

buyshares up <shares> / buyshares down <shares>: Belirli bir hisse senedi miktarı satın alır, kullanıcı dostu LIMIT + GTC emir türünü kullanır ve mevcut en iyi satış fiyatından işlem görür.

Otomatik mod, tekrarlayan iki aşamalı bir döngü çalıştırır.

İlk adımda, her döngü başlangıcında fiyat dalgalanmalarına gözlem yapar. Herhangi bir taraf yeterince hızlı düşerse (yaklaşık 3 saniye içinde fiyat değişimi oranı en az movePct kadar), "İlk Aşama (Leg 1)"'i tetikler ve düşüş yaşayan tarafa alım yapar.

Leg 1'i tamamladıktan sonra, bot bir daha aynı taraftan alım yapmayacaktır. İkinci bacak (Leg 2, yani hedge) bekleyecek ve yalnızca aşağıdaki koşullar sağlandığında tetiklenecektir: leg1EntryPrice + oppositeAsk <= sumTarget.

Bu koşul karşılandığında, zıt tarafı satın alacaktır. Leg 2 tamamlandıktan sonra döngü sona erer, bot gözlem durumuna döner ve aynı parametreleri kullanan bir sonraki düşüş sinyalini bekler.

Döngü süresince tur sayısı değişirse, bot açık döngüyü terk edecek ve bir sonraki turda aynı ayarlarla yeniden başlayacaktır.

Otomatik modun parametreleri şu şekildedir: auto on <shares> [sum=0.95] [move=0.15] [windowMin=2]

· shares: İki aşamalı işlem için pozisyon büyüklüğü.

· sum: Hedge eşiğine izin verilen değer.

· move (movePct): Düşük eşiğ (örneğin 0.15 = 15%).

· windowMin: Her turdan başlayarak, Leg 1'in gerçekleştirilmesine izin verilen süre.

Backtest

Botun mantığı oldukça basittir: Sert çöküşü bekler, az önce düşen tarafa alım yapar, ardından fiyatın istikrar kazanmasını bekler ve zıt tarafa alım yaparak hedge işlemi gerçekleştirir, aynı zamanda: priceUP + priceDOWN < 1.

Ancak bu mantığın test edilmesi gerekmektedir. Uzun vadede gerçekten etkili mi? Daha da önemlisi, botun birçok parametresi bulunmaktadır (pay miktarı, toplam, hareket yüzdesi, pencere dakika sayısı vb.). En iyi hangi parametre seti ve hangisi karı en üst düzeye çıkarır?

İlk düşüncem, botun canlı olarak bir hafta çalışmasını sağlamak ve sonuçları gözlemlemektir. Ancak bu çok uzun sürer ve yalnızca bir parametre setini test edebilirim, halbuki birçok farklı seti test etmem gerekiyor.

İkinci düşüncem, Polymarket CLOB API'dan çevrimiçi tarih öncesini kullanarak geri test yapmaktı. Ne yazık ki, BTC'nin 15 dakikalık yükseliş/düşüş piyasası için, tarih öncesi uç noktaları sürekli boş veri kümesi döndürdü. Tarih öncesinde fiyat hareketlerini (tick'leri) algılayamadığından, "yaklaşık 3 saniye içindeki sert düşüşü" tespit edemez, Leg 1'i tetikleyemez ve hangi parametreler kullanılırsa kullanılsın, 0 döngü ve %0 yatırım getirisi oranı (ROI) elde eder.

Daha fazla araştırma yaptıktan sonra, diğer kullanıcıların belirli bir pazarın geçmiş verilerine erişmeye çalışırken aynı sorunla karşılaştığını tespit ettim. Diğer gerçekten geçmiş verileri döndüren pazarları test ettim ve şu sonuca vardım: Bu belirli pazarda, geçmiş veriler hiç kaydedilmemiş.

Bu kısıtlama nedeniyle, bu stratejiyi geri test etmenin tek güvenilir yolu, bot çalıştırılırken gerçek zamanlı en iyi satış fiyatını (best-ask) kaydederek kendi geçmiş veri setimi oluşturmaktır.

Kaydedici disk üzerine anlık görüntü yazacak ve aşağıdakileri içerecektir:

· Zaman damgası

· Tur kimliği (round slug)

· Kalan saniye

· UP/DOWN jeton kimliği

· UP/DOWN en iyi satış fiyatı

Daha sonra, "kaydedilmiş geri test (recorded backtest)" bu anlık görüntüleri yeniden oynatacak ve aynı otomatik mantığı belirli olarak uygulayacaktır. Bu, flash crash'leri tespit etmek ve hedge koşullarını sağlamak için gereken yüksek frekanslı verileri elde etmenin garantisini sağlar.

Toplamda 4 gün içinde 6 GB veri topladım. Daha fazlasını kaydedebilirdim ama farklı parametre setlerini test etmek için yeterli olduğunu düşündüm.

Bu parametre setini test etmeye başladım:

· Başlangıç bakiyesi: $1,000

· Her işlemde 20 hisse

· sumTarget = 0.95

· Flash crash eşiği = 15%

· windowMin = 2 dakika

Ayrıca, muhafazakar bir senaryoda kalmak için sabit 0.5% komisyon ve %2 fark uyguladım.

Geri test, ROI'nin %86 olduğunu gösterdi, sadece birkaç gün içinde $1,000 $1,869'a dönüştü.

Daha sonra daha agresif bir parametre setini test ettim:

· Başlangıç bakiyesi: $1,000

· Her işlemde 20 hisse

· sumTarget = 0.6

· Flash crash eşiği = 1%

· windowMin = 15 dakika

Sonuç: Yatırımın ROI'si -50% oldu ve 2 gün sonra gerçekleşti.

Bu, parametre seçiminin en önemli faktör olduğunu açıkça göstermektedir. Sizi çok para kazandırabilir veya önemli ölçüde kayıplara yol açabilir.

Backtesting'in Sınırlamaları

Ücret ve fark dahil edilmiş olsa bile, backtesting'in bazı sınırlamaları vardır.

· İlk olarak, yalnızca birkaç gün veri kullanır, bu da kapsamlı bir piyasa görüşü elde etmek için yetersiz olabilir.

· Backtest, kaydedilen en iyi satış fiyatı anlık görüntüsüne dayanır; gerçekte, emirler kısmen gerçekleşebilir veya farklı fiyatlardan gerçekleşebilir. Ayrıca, emir defteri derinliği ve mevcut işlem hacmi modellenmemiştir.

· Mikrosaniye düzeyinin altındaki dalgalanmaları yakalayamaz (veri her saniyede bir örneklendirilir). Backtest, 1 saniyelik bir zaman damgasına sahip olsa da, her saniye arasında birçok şey olabilir.

· Backtest'te slippage sabittir, değişken gecikmeyi (örneğin 200–1500 milisaniye) veya ağ zirvelerini simüle etmez.

· Her işlem parçası "anlık" yürütüldü olarak kabul edilir (sıra yok, bekleyen emir yok).

· Ücretler standart olarak alınırken, gerçekte ücretler pazardan / tokena, emir veren ve emir kullanan arasındaki ilişkiye, ücret seviyesine veya koşullara bağlı olabilir.

Daha temkinli olmak için, bir kural uyguladım: Eğer İşlem 2 pazara kapanmadan yürütülemezse, İşlem 1 tam bir kayıp olarak kabul edilir.

Bu kasıtlı olarak muhafazakar bir yaklaşımdır, ancak her zaman gerçeği yansıtmayabilir:

· Bazı durumlarda İşlem 1 önceden kapanabilir,

· Bazı durumlarda sonunda para içinde olabilir ve kazanabilir,

· Bazı durumlarda zarar kısmi olabilir, tam değil.

Zarar belki abartılmış olabilir, ancak bu size kullanışlı bir "en kötü senaryo" senaryosu sağlar.

En önemlisi, backtest, büyük emrinizin emir defterine yaptığı etkiyi simüle edemez veya diğer işlemcilerin sizi avlamasına yol açan davranışları çekemez. Gerçekte, emriniz:

· Emir defterini bozabilir,

· Diğer işlemcileri çekebilir veya itebilir,

· Doğrusal olmayan slippage'a neden olabilir.

Backtest, sizi saf likidite çeken (price taker) saf bir varlık olarak varsayar.

Son olarak, frekans sınırlamalarını, API hatalarını, reddedilen emirleri, askıya almayı, zaman aşımını, yeniden bağlantıyı veya robotun sinyali kaçırmasını simüle etmez.

Backtesting, iyi bir parametre aralığını belirlemek için son derece değerli olsa da, bazı gerçek dünya etkileri modelleme ile ele alınamaz.

Altyapı

Robotu Raspberry Pi üzerinde çalıştırmayı planlıyorum, böylece ana bilgisayarımın kaynaklarını tüketmekten kaçınabilir ve 7/24 çalışmasını sağlayabilirim.

Ancak hâlâ önemli iyileştirme alanları bulunmaktadır:

· JavaScript yerine Rust kullanmak çok daha iyi performans ve işleme süresi sağlayacaktır.

· Özel Polygon RPC düğümünü çalıştırmak gecikmeyi daha da azaltacaktır.

· Polymarket sunucularına yakın bir VPS'de dağıtım yapmak da gecikmeyi önemli ölçüde azaltacaktır.

Kesinlikle henüz keşfetmediğim diğer optimizasyon yöntemleri de mevcut. Şu anda Rust öğreniyorum, çünkü Web3 geliştirme sürecinde vazgeçilmez bir dil haline geliyor.

Orjinal Makale Bağlantısı

BlockBeats Resmi Topluluğuna Katılın:

Telegram Abonelik Grubu: https://t.me/theblockbeats

Telegram Sohbet Grubu: https://t.me/BlockBeats_App

Twitter Resmi Hesabı: https://twitter.com/BlockBeatsAsia