Polymarket Bot Tutorial · Kabanata 30 ng 32

Production-grade risk management code para sa Polymarket bots: position caps, daily loss limits, halt sentinels, fill-rate watchdogs, reconcile-on-restart, idempotent retries. Code patterns mula sa tunay na production trader.

Ni Harley Young, pangunahing manunulat sa Polymarkets.co.il. Huling rebyu: Mayo 2026.

Ano ang sinasaklaw ng kabanatang ito

Ang risk code ay karamihan ng production trading bot. Ang strategy logic ay ang madaling bahagi; ang nakapaligid na caps, halts, watchdogs, at reconcilers ang tumutukoy kung mabubuhay ang bot sa unang masamang linggo. Ang kabanatang ito ay ang production-grade risk pattern.

  • Bakit ang risk code ay karamihan ng tunay na trading bot
  • Position caps (per-market, per-strategy, total)
  • Daily loss kill switch
  • Halt sentinels (file-based emergency stop)
  • Fill-rate watchdog
  • I-reconcile ang diary vs on-chain sa restart
  • Code: production-grade halt-aware loop

Bakit ang risk code ay karamihan ng tunay na trading bot

Sukat na ginawa namin sa aming sariling bot codebase: 60% ng LOC ay risk code (caps, halts, watchdogs, reconciliation). 30% ay strategy. 10% ay glue.

Ang ratio na iyon ay tama. Ang strategy ay ang madaling bahagi - ang paglalarawan kung kailan papasok at kailan lalabas ay umaakma sa ilang dosenang linya. Ang risk code ay ang lahat ng iba pa: ano ang gagawin kapag ang presyo ay gumagalaw laban sa iyo nang mas mabilis kaysa sa inaasahan, ano ang gagawin kapag huminto ang pag-fill ng mga order, ano ang gagawin kapag bumagsak ang WebSocket, ano ang gagawin kapag lumalabas ang strategy na hindi kumikita.

Karamihan sa mga kwento ng pagkabigo ng builder ay nagbabahagi ng parehong hugis: ang strategy ay gumana, ngunit ang bot ay patuloy na nag-trade sa pamamagitan ng regime change dahil walang halt na nag-fire. Isulat ang mga halt bago mo isulat ang strategy.

Position caps (per-market, per-strategy, total)

Tatlong caps, ipinapatupad sa code.

  • Per-market cap: max $X bawat market anuman ang edge confidence. Tipikal: $25-100 para sa maliit na bots, $200-500 para sa production. Binubukod ang blast radius ng single-market wrong call.
  • Per-strategy cap: kung nagpapatakbo ka ng maraming strategies, ang bawat isa ay nakakakuha ng hiwa ng total capital. Tipikal: 30-50% bawat strategy. Pinipigilan ang masamang araw ng isang strategy na ubusin ang kapital ng iba.
  • Total cap: max % ng wallet balance na deployed nang sabay-sabay. Tipikal: 50-70%. Nag-iiwan ng kapital para sa hindi inaasahang oportunidad o para sa paghuli sa sariling bookkeeping bugs ng bot.

Lahat ng tatlong caps ay dapat ipatupad sa loob ng order-placement function, hindi lamang sa strategy logic. Ang strategy ay maaaring magkaroon ng bug; ang order-placement gate ay ang huling linya ng pagtatanggol.

Daily loss kill switch

Ang pinakamahalagang single risk control: ang daily-loss kill switch.

Rule: kung ang realized + unrealized PnL mula hatinggabi UTC ay bumaba sa ibaba ng -X% ng starting daily balance, ang bot ay huminto sa pagbubukas ng mga bagong positions at (opsyonal) i-flatten ang mga umiiral. Tipikal na X: 5-10%.

Ang math: ang bot na may 60% inaasahang win rate ay may marahil 5% pagkakataon ng 10-trade losing streak. Kung walang kill switch, ang streak na iyon ay nag-co-compound: $200 loss → patuloy na nag-tra-trade ang bot → isa pang $200 loss → wallet bumaba ng 40%. Sa pag-fire ng switch sa -10%, ang masamang araw ay nag-cap sa $200, at bukas magsisimulang muli ang bot.

Ang switch ay ipinapatupad server-side: magsulat ng halt file o magtakda ng database flag na sinusuri ng trading loop bawat iteration. Mag-restart lamang pagkatapos ng manual review.

Halt sentinels (file-based emergency stop)

Ang pinakasimpleng posibleng halt mechanism: ang bot ay nag-che-check ng file (e.g. /opt/pmt/HALT) bawat loop iteration at humihinto sa pag-trade kung umiiral ang file.

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)

Upang mag-halt kaagad mula kahit saan (SSH, Telegram bot, monitoring system): touch /opt/pmt/HALT. Upang magpatuloy: rm /opt/pmt/HALT.

Ang file-based approach ay sinadyang low-tech dahil ito ay gumagana sa mga kondisyon kung saan nabibigo ang mas sopistikadong halt mechanisms: kapag ang bot ay bahagyang nag-crash, kapag ang database ay hindi maabot, kapag ang API key ay rate-limited. Ang file-system access ay palaging available.

Fill-rate watchdog

Ang strategy ay nag-aakala na ang FOK orders ay nag-fi-fill sa ilang rate (madalas 60-80%). Kapag bumaba nang malaki ang rate, may nagbago: ang market makers ay humila, ang iyong strategy ay nakilala, isang API outage ay nagaganap. Anuman ang dahilan, ang pag-aakala na nagtulak sa PnL math ng strategy ay nasira.

Watchdog logic: rolling 24-oras na fill-rate count. Kung < 30% (o 50% ng inaasahan), alert + auto-halt. Magpatuloy lamang pagkatapos ng manual review.

Ang watchdog ay kapaki-pakinabang din bilang diagnostic. Ang biglaang pagbaba ng fill-rate ay karaniwang nag-co-correlate sa external event (Polymarket deploy, Polygon congestion, ang iyong IP na nagiging rate-limited) na gugustuhin mong malaman anuman ang trading impact.

I-reconcile ang diary vs on-chain sa restart

Ang bot ay nagpapanatili ng diary ng positions na sa tingin nito ay hawak nito. Ang chain ay nagpapanatili ng katotohanan. Sila ay dapat palaging sumang-ayon; kapag hindi, ang bot ay nagpapatakbo sa maling paniniwala at mag-tra-trade nang mali.

Reconciliation logic: sa bawat restart at minsan bawat oras sa normal operation, kunin ang on-chain balances para sa bawat token na hinawakan ng bot. Ihambing sa diary; alert + halt kung ang balance ng anumang token ay naiiba mula sa diary nang higit sa rounding tolerance.

Ang pinakakaraniwang sanhi ng divergence ay matagumpay na order na napalampas ng API call ng bot (timeout, retry na hindi naka-record). Ang chain ay may position; sa tingin ng bot ay wala ito. Kung walang reconciliation, ang bot ay hindi mag-po-post ng take-profit exit at ang position ay sumasakay sa resolution.

Code: production-grade halt-aware loop

Reference: ang production trading loop kasama ang lahat ng risk controls na naka-wire 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)

Ang pattern: bawat iteration ay dumadaan sa gate. Hindi maaaring lampasan ng strategy bugs ang controls, sa konstruksyon.

Mga madalas na tanong

Ano ang halt sentinel?
Ang file (e.g., data/halt_autobuy) na sinusuri ng bot bago ang bawat order. Kung umiiral ang file, ang bot ay tumatanggi na maglagay ng orders kahit sabihin ng strategy. Pinapayagan ka nitong huminto sa bot sa gitna ng insidente sa isang touch command. Idinagdag namin ang eksaktong pattern na ito sa aming production trader pagkatapos ng wedged-fill incident noong Abril 2026.
Anong position caps ang dapat kong itakda?
Per-market: 1-5% ng bankroll. Per-strategy: 10-20%. Total open exposure: 50-70% ng bankroll (panatilihin ang cash buffer). Cap ang IISANG order sa 1-2% ng bankroll anuman ang strategy - isang fat-fingered order ay hindi kailanman dapat maging account-sized.
Paano ako mag-implement ng daily loss kill switch?
Subaybayan ang realized + unrealized PnL bawat UTC day. Kung ang daily PnL ay bumaba sa ibaba ng -3 hanggang -5% ng bankroll, i-set ang halt sentinel at abisuhan ang iyong sarili. Ang bot ay humihinto sa bagong orders; ang existing positions ay pinamamahalaan nang manu-mano. I-reset sa 00:00 UTC araw-araw.
Ano ang dapat gawin ng bot sa restart pagkatapos ng crash?
Tatlong hakbang: (1) I-reconcile ang open orders sa pamamagitan ng SDK laban sa iyong lokal na diary. (2) Suriin ang open positions on-chain laban sa iyong lokal na state. (3) Kung may divergence, i-halt ang bot at mangailangan ng manual review. Huwag kailanman mag-auto-resume sa inconsistent state.
Paano ko mapipigilan ang isang bug mula sa pag-empty ng aking account?
Layered limits: code-level position cap, code-level order-size cap, file-level halt sentinel, exchange-level (Polymarket) implicit minimum/maximum, monitoring alerts na nagpe-page sa iyo sa unusual order rate. Walang single layer na sapat - sila ay nagpaparami.
Dapat bang mag-trade ang bot kung nabigo ang aking logging?
Hindi. Kung hindi maaaring magsulat ang bot sa diary nito, hindi ito maaaring mag-reconcile sa restart, na nangangahulugang ang crash ay humahantong sa inconsistent state. Hard-fail ang bot kung mabibigo ang logging. Ang mga malusog na production bots ay paranoid sa sarili nilang observability.
Nakuha mo? Isabuhay na
Mag-practice nang libre gamit ang $1,000 virtualO mag-trade nang live sa Polymarket