Polymarket Kar - Zarar Kesin Hesaplama: Neden Hesapladığınız Kar - Zarar Yanlış Olabilir?

Bu makaleyi okumak için 12 Dakika

Polymarket'da kantitatif analiz yaparken, ilk adım bir strateji bulmak değil, kendi getirisini doğru hesaplama olduğunu doğrulamaktır.

Orijinal Başlık: "Polymarket Kar/Zarar Kesin Hesaplama: Hesapladığınız Kar/Zararın Tamamen Yanlış Olma Nedeni"

Polymarket'te yarı otomatik alım satım yürütürken altı ay boyunca karşılaştığım en büyük sorun, stratejinin başarısız olması değil, kazandığım parayı bile doğru düzgün hesaplayamamamdı.

Sorun bende değil. PM'nin Kar/Zarar hesaplama süreci zaten bir kazançların ve zararların çıkmaz sokaklarından oluşuyor. Resmi API size yanlış rakamlar verir, üçüncü taraf analiz sitelerinde görünen sıralama da yanlıştır. Kendi betiğinizi yazarak hesaplama yapacak mısınız? Büyük ihtimalle yine yanlış olacaktır.

Ayrım ne kadar büyük? Sıralamada 3. sırada olan kch123, yanlış yöntemle hesapladığı kar zararını -$3.5 milyon olarak görmüşken, gerçekte $11.4 milyon kazanmış. Bu sadece birkaç yüzde noktası fark değil—kazanç ve zarar işaretleri bile ters dönmüş.

Bu yazıda, karşılaştığım her sorunu detaylarıyla anlatacağım. Alım satım yapanlar, araçlar yazanlar, sıralamalara bakanlar, er ya da geç bunlarla karşılaşacaklar.

Sorun 1: cashPnl İşlem Ücretini İçermez

En basit yaklaşım: /positions API'sını çek, cashPnl (nakit kar/zarar) alanını topla.

En üst 15 sıradaki üç adres için gerçekleştirilen test:

swisstony: cashPnl toplamı +$3.5 bin, sıralamada görülen kar/zarar +$5.6 milyon, fark 158 kat

kch123: cashPnl toplamı -$3.52 milyon, sıralamada görülen kar/zarar +$11.4 milyon, işaret ters

gmanas: cashPnl toplamı -$2.64 milyon, sıralamada görülen kar/zarar +$5.02 milyon, işaret ters

Üç adresin ikisinde kar/zarar işaretleri doğrudan çelişmektedir.

Nedeni: /positions API'sinden gelen cashPnl, kapatılmış gerçekleşen Kar/Zarar'ı içermez. Kazanç elde edilen pozisyonlar otomatik olarak USDC'ye çevrildikten sonra, bu işlem API yanıtından kaybolur. Geriye kalanlar ise gerçekleşmemiş pozisyonlardır—genellikle çoğunlukla zararlarla karakterize.

Sandığın gibi tüm kar/zararı hesaplıyorsun, aslında sadece hesaba katılmamış kısmı alıyorsun.

Tuzak 2: makerPnl Alanı ve On-Chain Nakit Akışı Tutarsız

İşlem verilerinde bir makerPnl (likidite sağlayıcı kar/zarar) alanı bulunmaktadır, isminden de anlaşılacağı üzere PnL hesaplamak için kullanılabilir gibi görünüyor. Ancak inanma.

Ben likidite sağlayıcı verilerinde gözlemledim ki, SUM(makerPnl) ile hesaplanan rakam, on-chain nakit akışı ile karşılaştırıldığında bir büyüklük farkına sahiptir. Özel bir duruma bağlı olarak farklı bir kat değeri olabilir, ancak genel olarak: makerPnl'in iç hesaplama mantığı gerçek USDC akışı ile uyuşmamaktadır.

Ne kadar sapma olursa olsun, sonuç aynıdır: Bu alanı PnL hesaplamak için kullanmayın.

Tuzak 3: txHash'a Göre Tek Başına Benzersizleştiremezsiniz

Bu en karşıt düşünceli olanı.

Aynı bir txHash (işlem karma değeri) birden fazla kayıtta bulunur, normal bir insanın ilk tepkisi: yinelenen verileri benzersizleştir.

Bunu yapamazsınız. PM'in CLOB'u (zincir üstü limit emir defteri) bir zincir üstü işlemde birden fazla maker emri eşleyebilir, aynı txHash altındaki birden fazla kayıt gerçek bağımsız fill'dir.

Daha önce txHash + varlık'a göre benzersizleştirmiştim, ALIŞ tarafını $133 eksik hesapladım. Polygon zincirinde doğruladım, bir işlem karma değerinde gerçekten birden fazla bağımsız USDC Transfer etkinliği vardı, her biri bir gerçek işlemi temsil ediyordu.

Sonuç: Yalnızca txHash'a göre benzersizleştiremezsiniz. PnL hesaplamak için, doğrudan /activity orijinal verilerinin toplamını alın.

Tuzak 4: offset Sayfalama Bir Tavana Sahip

/activity arayüzünde sayfalama yaparken, offset (kaydırma) kullanılır mı? 3000'den fazla kayıtta doğrudan 400 hatası alırsınız. Belgelerde yazmamışlar.

Yukarıdaki üç adresin tümünü doğruladım: GET /activity?offset=3100 HTTP 400 döndürür, hata mesajı max historical activity offset of 3000 exceeded. Başlıktaki oyuncular genellikle on binlerce işlem yaparlar, 3000 kayıt yetersizdir.

end parametresi kullanılarak (bir önceki sayfanın son zaman damgası - 1) imleçli sayfalama yapın, sınır yoktur.

Sorun 5: Sıralama Tablosu PnL Farklılığı

Bir adresin PnL'sini hesapladığınızda sıralama tablosuna baktığınızda hafif bir farklılık görürsünüz.

Çoğu durumda fark $10'un altındadır (pozisyon değeri tarafından sağlanan gerçek zamanlı dalgalanmadan kaynaklanır). Ancak fark belirgin bir şekilde daha büyükse, olası nedenler arasında: sıralama tablosunun birleştirme penceresi, önbellek yenileme gecikmesi veya kullanıcının birden fazla vekil cüzdanına bağlanmış olması bulunabilir.

Gerçek dünya testlerinde, tek bir adrese dayalı PnL'nin nakit akışı yöntemiyle hesaplanan değerler ile lb-api'nin döndüğü değerler oldukça tutarlıdır. Eğer sonuçlarınız arasında büyük farklar varsa, önce sayfalamanın tamamlandığından emin olun (Sorun 4), yanlış alan kullanıp kullanmadığınızı kontrol edin (Sorun 1-2).

Doğru Yaklaşım

Farklı yöntemleri denedikten sonra, en güvenilir yöntemin Veri API nakit akışı özeti olduğunu doğruladım. Herhangi bir önceden hesaplanmış alandan yararlanmaksızın, doğrudan ham işlem kayıtlarından fon akışını hesaplayın.

Formül:

PnL = SUM(TRADE where side=SELL) + SUM(REDEEM) + SUM(MERGE) + SUM(MAKER_REBATE) + SUM(REWARD) - SUM(TRADE where side=BUY) - SUM(SPLIT) + Pozisyon Değeri

· TRADE BUY: Token satın almak için USDC harca (çıkış)

· TRADE SELL: Token satıp USDC'yi geri al (giriş)

· REDEEM: Kazanılan pozisyonu USDC'ye çevir (giriş)

· SPLIT: USDC'yi token çiftine dönüştür (çıkış)

· MERGE: Token çiftini USDC'ye birleştir (giriş)

· MAKER_REBATE: Yapımcı iadesi (giriş)

· REWARD: Ödül/Havalesi (giriş)

· Veri Kaynağı:

GET /activity?user=<adres>&limit=500, end ile sayfalama yapılarak türlerine göre toplam sonuçlar alınır.

· Pozisyon Değeri:

GET /positions?user=<adres>, boyut × güncelFiyat.

· Çapraz Doğrulama:

Hesaplama sonuçlarını Polymarket liderlik tablosu API'siyle (<$10 fark hesaba katılır) karşılaştırın. Fark, pozisyon değerindeki anlık dalgalanmadan kaynaklanır.

Doğrulama: İlk 15 Sıra Denemesi

Nakit Akışı Yöntemiyle hesaplama yapıldıktan sonra, liderlik tablosu API'siyle çapraz doğrulama yapılır:

swisstony: Nakit Akışı Yöntemi +$560.1 milyon, liderlik tablosu +$560.1 milyon, fark < $10

kch123: Nakit Akışı Yöntemi +$1139.6 milyon, liderlik tablosu +$1139.6 milyon, fark < $10

gmanas: Nakit Akışı Yöntemi +$502.4 milyon, liderlik tablosu +$502.4 milyon, fark < $10

Üç adresin hata payı tümü $10'un altında, fark pozisyon değerindeki anlık dalgalanmadan kaynaklanır.

Yöntem başarıyla uygulandıktan sonra, yüzlerce önde gelen adresin gerçek kar/zarar durumunu analiz ettim. Bu başka bir şeydi.

Özet

/positions'dan SUM(nakPnL) → Geçerli değil, hesaplanmış karı içermez, işaret tersine dönebilir

makerPnL alanının toplamı → Geçerli değil, blokzincirindeki nakit akışıyla uyumsuz

txHash'e göre tekrarlayanları temizleyip hesaplama → Geçerli değil, $100+'dan sonrası, gerçek doldurmayı sildi

sayfa kaydırma + toplama ofseti → Olmaz, veri kesimi, >3000 hata

Veri API Nakit Akışı Metodu → Şu anda en güvenilir olanı, <$10

Quantitative yapmanın ilk adımı alfa bulmak değil. Doğru hesapladığından emin olmaktır.

Yukarıdakilerin tümü gerçek ticarette kazılan çukurlardan gelir, teorik türetilmiş değillerdir. PM'in API'sı her zaman davranışlarını ayarlayabilir, hesaplamalarınızı çapraz kontrol etmek için periyodik olarak sıralama API'sini kullanmanızı öneririz.