Polymarket Bot Tutorial · Chapter 30 of 32
Polymarket bots کے لیے production-grade risk management code: position caps, daily loss limits, halt sentinels, fill-rate watchdogs, reconcile-on-restart, idempotent retries۔ حقیقی production trader سے code patterns۔
اس chapter میں کیا شامل ہے
Risk code ایک production trading bot کا زیادہ تر حصہ ہوتا ہے۔ Strategy logic آسان حصہ ہے؛ اس کے اردگرد لگے caps، halts، watchdogs، اور reconcilers یہ طے کرتے ہیں کہ bot اپنی پہلی خراب week میں survive کرے گا یا نہیں۔ یہ chapter production-grade risk pattern ہے۔
- Risk code ایک real trading bot کا زیادہ تر حصہ کیوں ہے
- Position caps (per-market, per-strategy, total)
- Daily loss kill switch
- Halt sentinels (file-based emergency stop)
- Fill-rate watchdog
- Restart پر diary vs on-chain reconcile کرنا
- Code: production-grade halt-aware loop
Risk code ایک real trading bot کا زیادہ تر حصہ کیوں ہے
ہم نے اپنے bot codebase پر ایک measurement کی: 60% LOC risk code ہے (caps, halts, watchdogs, reconciliation)۔ 30% strategy ہے۔ 10% glue ہے۔
یہ ratio درست ہے۔ Strategy آسان حصہ ہے - کب enter کرنا ہے اور کب exit کرنا ہے، یہ چند درجن lines میں fit ہو جاتا ہے۔ Risk code باقی سب کچھ ہے: جب price توقع سے تیزی سے آپ کے خلاف جائے تو کیا کرنا ہے، جب fills آنا بند ہو جائیں تو کیا کرنا ہے، جب WebSocket drop ہو جائے تو کیا کرنا ہے، جب strategy غیر منافع بخش ثابت ہو تو کیا کرنا ہے۔
زیادہ تر builder failure stories ایک ہی shape رکھتی ہیں: strategy کام کر رہی تھی، لیکن bot نے regime change کے دوران trading جاری رکھی کیونکہ کوئی halt fire نہیں ہوا۔ Strategy لکھنے سے پہلے halts لکھیں۔
Position caps (per-market, per-strategy, total)
تین caps، code میں enforce کیے گئے۔
- Per-market cap: edge confidence سے قطع نظر ہر market پر زیادہ سے زیادہ $X۔ عام طور پر: چھوٹے bots کے لیے $25-100، production کے لیے $200-500۔ یہ ایک single-market غلط call کے blast radius کو محدود کرتا ہے۔
- Per-strategy cap: اگر آپ multiple strategies چلاتے ہیں تو ہر strategy کو total capital کا ایک slice ملتا ہے۔ عام طور پر: ہر strategy کے لیے 30-50%۔ یہ ایک strategy کے خراب دن کو دوسروں کا capital کھانے سے روکتا ہے۔
- Total cap: wallet balance کا زیادہ سے زیادہ % جو بیک وقت deploy ہو۔ عام طور پر: 50-70%۔ یہ unexpected opportunities یا bot کی اپنی bookkeeping bugs کو catch کرنے کے لیے capital چھوڑتا ہے۔
تینوں caps order-placement function کے اندر enforce ہونے چاہئیں، صرف strategy logic میں نہیں۔ Strategy میں bug ہو سکتا ہے؛ order-placement gate آخری defense line ہے۔
Daily loss kill switch
سب سے اہم single risk control: daily-loss kill switch۔
Rule: اگر midnight UTC سے لے کر realized + unrealized PnL starting daily balance کے -X% سے نیچے چلا جائے، تو bot نئے positions کھولنا بند کر دیتا ہے اور (اختیاری طور پر) موجودہ positions flatten کر دیتا ہے۔ عام X: 5-10%۔
Math: 60% expected win rate والا bot شاید 10-trade losing streak کا 5% chance رکھتا ہے۔ Kill switch کے بغیر یہ streak compound ہوتی ہے: $200 loss → bot trading جاری رکھتا ہے → مزید $200 loss → wallet 40% down۔ Switch کے -10% پر fire ہونے کے ساتھ، خراب دن $200 پر cap ہو جاتا ہے، اور اگلے دن bot fresh start کرتا ہے۔
Switch server-side enforce ہوتا ہے: ایک halt file لکھیں یا database flag set کریں جسے trading loop ہر iteration میں check کرتا ہے۔ Restart صرف manual review کے بعد کریں۔
Halt sentinels (file-based emergency stop)
سب سے سادہ halt mechanism: bot ہر loop iteration میں ایک file check کرتا ہے (مثلاً /opt/pmt/HALT) اور اگر file موجود ہو تو trading روک دیتا ہے۔
def trading_loop():
while True:
if os.path.exists("/opt/pmt/HALT"):
log("HALT file detected, sleeping")
time.sleep(30)
continue
run_one_iteration()
time.sleep(5)کہیں سے بھی فوراً halt کرنے کے لیے (SSH, Telegram bot, یا monitoring system): touch /opt/pmt/HALT۔ Resume کرنے کے لیے: rm /opt/pmt/HALT۔
File-based approach جان بوجھ کر low-tech ہے کیونکہ یہ اُن حالات میں بھی کام کرتی ہے جہاں زیادہ sophisticated halt mechanisms fail ہو جاتے ہیں: جب bot جزوی طور پر crash ہو چکا ہو، جب database unreachable ہو، جب API key rate-limited ہو۔ File-system access ہمیشہ available ہوتا ہے۔
Fill-rate watchdog
Strategy یہ assume کرتی ہے کہ FOK orders کسی rate پر fill ہوں گی (اکثر 60-80%)۔ جب یہ rate نمایاں طور پر گر جائے تو کچھ بدل چکا ہوتا ہے: market makers ہٹ گئے، آپ کی strategy identify ہو گئی، کوئی API outage جاری ہے۔ وجہ کچھ بھی ہو، وہ assumption ٹوٹ گئی ہے جس پر strategy کی PnL math مبنی تھی۔
Watchdog logic: rolling 24-hour fill-rate count۔ اگر < 30% ہو (یا expected کا 50%) تو alert + auto-halt۔ Resume صرف manual review کے بعد۔
Watchdog diagnosis کے لیے بھی مفید ہے۔ Fill-rate میں اچانک drop عموماً کسی external event سے correlate کرتا ہے (Polymarket deploy, Polygon congestion, آپ کے IP کا rate-limited ہونا) جس کے بارے میں آپ جاننا چاہیں گے، trading impact سے قطع نظر۔
Restart پر diary vs on-chain reconcile کرنا
Bot ایک diary maintain کرتا ہے جس میں وہ positions درج ہوتی ہیں جو اس کے خیال میں اس کے پاس ہیں۔ Chain حقیقت maintain کرتی ہے۔ دونوں کو ہمیشہ agree کرنا چاہیے؛ جب ایسا نہ ہو تو bot غلط belief پر operate کر رہا ہوتا ہے اور غلط trade کرے گا۔
Reconciliation logic: ہر restart پر اور normal operation کے دوران ہر گھنٹے بعد، bot نے جن tokens کو touch کیا ہے ان سب کے on-chain balances fetch کریں۔ Diary سے compare کریں؛ اگر کسی token کا balance rounding tolerance سے زیادہ different ہو تو alert + halt کریں۔
Difference کی سب سے common وجہ ایک successful order ہوتا ہے جسے bot کی API call miss کر دیتی ہے (timeout، retry کبھی record نہیں ہوا)۔ Chain کے پاس position ہوتی ہے؛ bot سمجھتا ہے کہ نہیں ہے۔ Reconciliation کے بغیر bot take-profit exit post نہیں کرے گا اور position resolution تک ride کرتی رہے گی۔
Code: production-grade halt-aware loop
Reference: production trading loop جس میں تمام risk controls wired in ہیں۔
def production_loop():
while True:
# Halt checks
if os.path.exists("/opt/pmt/HALT"):
sleep_with_log(30); continue
if daily_pnl_below_threshold():
create_halt("daily PnL kill"); continue
# Reconcile every hour
if now() - last_reconcile > 3600:
ok = reconcile_diary_vs_chain()
last_reconcile = now()
if not ok: create_halt("reconciliation failed"); continue
# Fill-rate watchdog
if recent_fill_rate() < 0.30:
create_halt("fill rate collapse"); continue
# Strategy
try:
run_strategy_once()
except Exception as e:
log_exception(e)
if consecutive_exceptions >= 5:
create_halt(f"exceptions: {e}"); continue
time.sleep(5)Pattern یہ ہے: ہر iteration gate سے گزرتی ہے۔ Construction کے لحاظ سے strategy bugs controls کو bypass نہیں کر سکتیں۔
