पॉलीमार्केट बॉट ट्यूटोरियल · अध्याय 30 / 32

पॉलीमार्केट बॉट के लिए प्रोडक्शन-ग्रेड रिस्क मैनेजमेंट कोड: पोज़ीशन कैप, रोज़ाना नुकसान की सीमाएँ, हॉल्ट सेंटिनल, फ़िल-रेट वॉचडॉग, restart-पर-रीकंसाइल, idempotent रीट्राई। एक असली प्रोडक्शन ट्रेडर से लिए गए कोड पैटर्न।

हार्ले यंग द्वारा, Polymarkets.co.il में मुख्य लेखिका। अंतिम समीक्षा: मई 2026।

यह अध्याय क्या कवर करता है

रिस्क कोड किसी प्रोडक्शन ट्रेडिंग बॉट का सबसे बड़ा हिस्सा है। स्ट्रैटेजी लॉजिक आसान हिस्सा है; उसके आसपास के कैप, हॉल्ट, वॉचडॉग, और रीकंसाइलर तय करते हैं कि बॉट अपने पहले खराब हफ़्ते में बचेगा या नहीं। यह अध्याय एक प्रोडक्शन-ग्रेड रिस्क पैटर्न है।

  • रिस्क कोड किसी असली ट्रेडिंग बॉट का सबसे बड़ा हिस्सा क्यों है
  • पोज़ीशन कैप (प्रति-मार्केट, प्रति-स्ट्रैटेजी, कुल)
  • रोज़ाना नुकसान का किल स्विच
  • हॉल्ट सेंटिनल (फ़ाइल-आधारित आपातकालीन रोक)
  • फ़िल-रेट वॉचडॉग
  • restart पर डायरी बनाम on-chain रीकंसाइल करना
  • कोड: प्रोडक्शन-ग्रेड हॉल्ट-अवेयर लूप

रिस्क कोड किसी असली ट्रेडिंग बॉट का सबसे बड़ा हिस्सा क्यों है

हमने अपने ही बॉट codebase पर एक माप लिया: LOC का 60% रिस्क कोड है (कैप, हॉल्ट, वॉचडॉग, रीकंसिलिएशन)। 30% स्ट्रैटेजी है। 10% जोड़ने वाला कोड (glue) है।

यह अनुपात सही है। स्ट्रैटेजी आसान हिस्सा है - कब एंट्री लेनी है और कब एग्ज़िट करना है, यह कुछ दर्जन लाइनों में समा जाता है। रिस्क कोड बाकी सब कुछ है: जब कीमत आपके खिलाफ उम्मीद से तेज़ चले तो क्या करना है, जब फ़िल रुक जाएँ तो क्या करना है, जब WebSocket टूट जाए तो क्या करना है, जब स्ट्रैटेजी घाटे वाली साबित हो तो क्या करना है।

ज़्यादातर बिल्डर की नाकामी की कहानियाँ एक जैसी होती हैं: स्ट्रैटेजी काम कर रही थी, लेकिन बॉट बाज़ार का मिज़ाज बदलने के दौरान ट्रेडिंग करता रहा क्योंकि कोई हॉल्ट नहीं लगा। स्ट्रैटेजी लिखने से पहले हॉल्ट लिखिए।

पोज़ीशन कैप (प्रति-मार्केट, प्रति-स्ट्रैटेजी, कुल)

तीन कैप, कोड में लागू।

  • प्रति-मार्केट कैप: बढ़त (edge) पर भरोसा चाहे जितना भी हो, प्रति मार्केट अधिकतम $X। सामान्य: छोटे बॉट के लिए $25-100, प्रोडक्शन के लिए $200-500। किसी एक मार्केट में गलत दांव के असर का दायरा सीमित करता है।
  • प्रति-स्ट्रैटेजी कैप: अगर आप कई स्ट्रैटेजी चलाते हैं, तो हर स्ट्रैटेजी को कुल कैपिटल का एक हिस्सा मिलता है। सामान्य: प्रति स्ट्रैटेजी 30-50%। एक स्ट्रैटेजी के खराब दिन को बाकी स्ट्रैटेजी की कैपिटल खा जाने से रोकता है।
  • कुल कैप: वॉलेट बैलेंस का अधिकतम % जो एक साथ लगाया जा सकता है। सामान्य: 50-70%। अप्रत्याशित मौकों के लिए या बॉट की अपनी हिसाब-किताब की गड़बड़ियाँ पकड़ने के लिए कुछ कैपिटल बचाकर रखता है।

तीनों कैप को order-placement function के अंदर लागू किया जाना चाहिए, सिर्फ स्ट्रैटेजी लॉजिक में नहीं। स्ट्रैटेजी में बग हो सकता है; order-placement gate आख़िरी बचाव की कतार है।

रोज़ाना नुकसान का किल स्विच

सबसे महत्वपूर्ण अकेला रिस्क कंट्रोल: डेली-लॉस किल स्विच।

नियम: अगर midnight UTC के बाद से realized + unrealized PnL शुरुआती दैनिक बैलेंस के -X% से नीचे चला जाए, तो बॉट नई पोज़ीशन खोलना बंद कर देता है और (वैकल्पिक रूप से) मौजूदा पोज़ीशन को flatten कर देता है। सामान्य X: 5-10%।

गणित: 60% अपेक्षित win rate वाले बॉट के लिए शायद 10-ट्रेड की हारने वाली स्ट्रीक की 5% संभावना हो। किल स्विच के बिना, यह स्ट्रीक और बढ़ती जाती है: $200 का नुकसान → बॉट ट्रेडिंग जारी रखता है → फिर $200 का नुकसान → वॉलेट 40% नीचे। -10% पर स्विच लगने से बुरा दिन $200 पर सीमित हो जाता है, और कल बॉट नई शुरुआत करता है।

स्विच server-side लागू होना चाहिए: हॉल्ट फ़ाइल लिखिए या database फ़्लैग सेट कीजिए जिसे ट्रेडिंग लूप हर iteration में जाँचे। restart सिर्फ मैन्युअल समीक्षा के बाद।

हॉल्ट सेंटिनल (फ़ाइल-आधारित आपातकालीन रोक)

सबसे सरल हॉल्ट तंत्र: बॉट हर loop iteration में एक फ़ाइल (जैसे /opt/pmt/HALT) जाँचता है और फ़ाइल मौजूद होने पर ट्रेडिंग रोक देता है।

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)

कहीं से भी तुरंत हॉल्ट करने के लिए (SSH, Telegram बॉट, monitoring system): touch /opt/pmt/HALT। दोबारा शुरू करने के लिए: rm /opt/pmt/HALT।

फ़ाइल-आधारित तरीका जानबूझकर low-tech है क्योंकि यह उन हालात में काम करता है जहाँ ज़्यादा पेचीदा हॉल्ट तंत्र नाकाम हो जाते हैं: जब बॉट आंशिक रूप से क्रैश हो चुका हो, जब database तक पहुँच न हो, जब API key रेट-लिमिट हो। फ़ाइल-सिस्टम तक पहुँच हमेशा उपलब्ध रहती है।

फ़िल-रेट वॉचडॉग

स्ट्रैटेजी मानती है कि FOK ऑर्डर किसी दर पर फ़िल होंगे (अक्सर 60-80%)। जब यह दर काफ़ी गिर जाती है, तो कुछ बदल चुका है: market makers हट गए, आपकी स्ट्रैटेजी पहचान ली गई, या कोई API outage चल रही है। वजह चाहे जो भी हो, वह मान्यता टूट चुकी है जिस पर स्ट्रैटेजी का PnL गणित टिका था।

वॉचडॉग लॉजिक: rolling 24-घंटे का फ़िल-रेट काउंट। अगर < 30% (या अपेक्षित का 50%) हो, तो अलर्ट + ऑटो-हॉल्ट। दोबारा शुरू सिर्फ मैन्युअल समीक्षा के बाद।

वॉचडॉग एक निदान-उपकरण के रूप में भी उपयोगी है। फ़िल-रेट का अचानक गिरना आमतौर पर किसी बाहरी घटना (पॉलीमार्केट का deploy, Polygon की congestion, आपका IP रेट-लिमिट होना) से जुड़ा होता है, जिसके बारे में ट्रेडिंग पर असर से अलग भी आप जानना चाहेंगे।

restart पर डायरी बनाम on-chain रीकंसाइल करना

बॉट उन पोज़ीशन की एक डायरी रखता है जिन्हें वह मानता है कि उसके पास हैं। चेन सच्चाई रखती है। दोनों में हमेशा मेल होना चाहिए; जब नहीं होता, तो बॉट किसी गलत धारणा के आधार पर चल रहा होता है और गलत ट्रेड करेगा।

रीकंसिलिएशन लॉजिक: हर restart पर और सामान्य संचालन के दौरान हर एक घंटे में, बॉट द्वारा छुए गए हर टोकन के on-chain बैलेंस fetch कीजिए। डायरी से तुलना कीजिए; अगर किसी टोकन का बैलेंस rounding tolerance से ज़्यादा अलग हो, तो अलर्ट + हॉल्ट कीजिए।

फ़र्क का सबसे आम कारण वह सफल ऑर्डर होता है जिसे बॉट की API कॉल चूक जाती है (टाइमआउट, रीट्राई रिकॉर्ड नहीं हुआ)। चेन के पास पोज़ीशन होती है; बॉट को लगता है कि नहीं है। रीकंसिलिएशन के बिना, बॉट take-profit एग्ज़िट पोस्ट नहीं करेगा और पोज़ीशन रिज़ॉल्यूशन तक चली जाएगी।

कोड: प्रोडक्शन-ग्रेड हॉल्ट-अवेयर लूप

संदर्भ: एक प्रोडक्शन ट्रेडिंग लूप जिसमें सभी रिस्क कंट्रोल जोड़े गए हैं।

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)

पैटर्न: हर iteration इन gate से होकर गुज़रती है। बनावट के हिसाब से स्ट्रैटेजी के बग इन कंट्रोल को bypass नहीं कर सकते।

अक्सर पूछे जाने वाले प्रश्न

हॉल्ट सेंटिनल क्या है?
एक फ़ाइल (जैसे, data/halt_autobuy) जिसे बॉट हर ऑर्डर से पहले जाँचता है। अगर फ़ाइल मौजूद हो, तो स्ट्रैटेजी कुछ भी कहे, बॉट ऑर्डर लगाने से मना कर देता है। यह एक अकेली touch कमांड से घटना के बीचोंबीच बॉट रोकने देता है। अप्रैल 2026 में एक wedged-fill घटना के बाद हमने यही सटीक पैटर्न अपने प्रोडक्शन ट्रेडर में जोड़ा।
मुझे कौन-से पोज़ीशन कैप सेट करने चाहिए?
प्रति-मार्केट: बैंकरोल का 1-5%। प्रति-स्ट्रैटेजी: 10-20%। कुल खुला एक्सपोज़र: बैंकरोल का 50-70% (नकद बफ़र रखें)। स्ट्रैटेजी चाहे कोई भी हो, किसी एक अकेले ऑर्डर को बैंकरोल के 1-2% पर सीमित कीजिए - एक भी गलती से लगा बड़ा ऑर्डर पूरे खाते के आकार का नहीं होना चाहिए।
मैं रोज़ाना नुकसान का किल स्विच कैसे लागू करूँ?
हर UTC दिन के लिए realized + unrealized PnL ट्रैक कीजिए। अगर दैनिक PnL बैंकरोल के -3 से -5% से नीचे जाए, तो हॉल्ट सेंटिनल सेट कीजिए और खुद को सूचित कीजिए। बॉट नए ऑर्डर रोक देता है; मौजूदा पोज़ीशन को हाथ से संभाला जाता है। रोज़ 00:00 UTC पर रीसेट कीजिए।
क्रैश के बाद restart पर बॉट को क्या करना चाहिए?
तीन चरण: (1) SDK के ज़रिए खुले ऑर्डर को स्थानीय डायरी से रीकंसाइल कीजिए। (2) खुली पोज़ीशन को on-chain अपने स्थानीय स्टेट से जाँचिए। (3) अगर कुछ भी अलग निकले, तो बॉट हॉल्ट कीजिए और मैन्युअल समीक्षा ज़रूरी रखिए। कभी भी बेमेल स्टेट में अपने-आप दोबारा शुरू (auto-resume) मत होने दीजिए।
किसी एक अकेले बग को मेरा खाता खाली करने से कैसे रोकूँ?
परतदार सीमाएँ: code-level पोज़ीशन कैप, code-level order-size कैप, file-level हॉल्ट सेंटिनल, exchange-level (पॉलीमार्केट) निहित न्यूनतम/अधिकतम, और ऐसे monitoring अलर्ट जो असामान्य ऑर्डर दर पर आपको page करें। कोई एक अकेली परत पर्याप्त नहीं है - ये मिलकर कई गुना असर करती हैं।
अगर logging नाकाम हो जाए तो क्या बॉट ट्रेड करे?
नहीं। अगर बॉट अपनी डायरी में लिख नहीं सकता, तो restart पर रीकंसिलिएशन नहीं कर पाएगा, जिसका मतलब है कि क्रैश बेमेल स्टेट में ले जाएगा। logging नाकाम होने पर बॉट को hard-fail होना चाहिए। स्वस्थ प्रोडक्शन बॉट अपनी observability को लेकर बेहद सतर्क होते हैं।