Polymarket Bot Tutorial · บทที่ 31 จาก 32
การนำ Polymarket bot ของคุณขึ้นใช้งานจริง: ฝากครั้งแรก 25-50 USD, กฎ take-profit และ stop-loss, เกณฑ์การแจ้งเตือน (Telegram/email), รอบการ reconciliation และแผนการขยายในสัปดาห์แรก
บทนี้ครอบคลุมอะไร
ช่วงเปลี่ยนจาก paper ไป live คือจุดที่ builder ส่วนใหญ่มักเผลอทำให้เงินฝากก้อนแรกหายไป บทนี้คือ checklist ก่อนบินขึ้นจริง พร้อมวินัยในสัปดาห์แรกที่ช่วยจับบั๊กได้ก่อนที่มันจะกลายเป็นความเสียหาย
- Pre-flight checklist
- เงินฝากครั้งแรก: 25-50 USD
- กฎ TP/SL จาก production
- Monitoring: Telegram, email, dashboards
- รอบ reconciliation: ทุก fire_exits cycle
- สัปดาห์แรก: อยู่ใกล้ ๆ, ลงทุนขนาดเล็ก
- การขยาย: เมื่อใดควรฝากเพิ่ม
Pre-flight checklist
รายการที่ต้องทำตามลำดับก่อนสลับ bot จาก paper ไป live
- ปิด paper trades ครบ 30 ครั้ง เกณฑ์ความสำเร็จตามที่เขียนไว้ต้องผ่านหรือทำได้ดีกว่า
- รูปแบบ diary ต้องเหมือนกันทั้ง paper และ live สคีมา JSONL ต้องเหมือนกัน
- deploy VPS แล้ว bot ต้องเป็น process เดียวที่ทำงานอยู่ และตั้งค่า systemd unit เรียบร้อย
- ทดสอบกลไกไฟล์ HALT แล้ว
touch /opt/pmt/HALTต้องหยุด bot ภายใน 30 วินาที - ตั้งค่า Telegram alerts แล้ว ทดสอบส่ง alert ผ่านสำเร็จ
- ทดสอบ daily-loss kill switch แล้ว จำลอง drawdown 10% และยืนยันว่า halt ทำงาน
- ทดสอบ on-chain reconciliation แล้ว ทำ diary ให้ mismatch แบบ manual และยืนยันว่า halt ทำงาน
- ยืนยันว่า deposit address คือ proxy wallet - กระเป๋าสัญญาอัจฉริยะที่ Polymarket ใช้เทรดแทนคุณ (POLY_FUNDER_ADDRESS) - ไม่ใช่บัญชีส่วนตัวของคุณ ซึ่งก็คือ externally-owned account หรือ EOA ตรวจสอบผ่าน SDK ด้วย
wallet show - ตั้งค่า USDC/pUSD approvals แล้ว ทั้ง standard exchange และ NegRisk exchange
- ตกลงจำนวนเงินฝากเริ่มต้นเป็นลายลักษณ์อักษร: $25-50 สำหรับ smoke test
ถ้ารายการใดรายการหนึ่งยังไม่ครบ อย่า go live เพราะแต่ละข้อเคยทำให้ builder เสียเงินจริงมาแล้วในเรื่องจริงของ production
เงินฝากครั้งแรก: 25-50 USD
เงินฝากสำหรับ smoke test ตั้งใจให้เล็กมาก เป้าหมายคือพิสูจน์ว่าเส้นทาง live ใช้งานได้ ไม่ใช่เพื่อทำกำไร
สิ่งที่คุณกำลังทดสอบคือ: การวาง order ของ bot ตรงกับมุมมอง trade ของ Polymarket หรือไม่ diary บันทึกถูกต้องหรือไม่ take-profit แบบ GTC โพสต์จริงหรือไม่ bot กู้คืนจาก API error ชั่วคราวได้ไหม และ daily-loss halt จะทำงานหรือไม่ถ้าจำลองขึ้นมา
ผลลัพธ์ที่คาดหวังคือ: 5-15 trades เล็ก ๆ ที่โดยคร่าว ๆ สอดคล้องกับ paper diary ให้มองความคลาดเคลื่อนใด ๆ เป็นบั๊ก ไม่ใช่คุณสมบัติของ "live ที่ noisy กว่า paper"
ถ้าคุณเสีย $25-50 นี้ไปเพราะกลยุทธ์จริงขาดทุน แปลว่ายังต้องรัน paper เพิ่มอีก ถ้าเสียไปเพราะบั๊ก ให้แก้บั๊กก่อนค่อยขยาย
กฎ TP/SL จาก production
ก่อนอื่นขอนิยามสั้น ๆ สองคำ เพราะหัวข้อนี้อ้างอิงถึงมัน take-profit (TP) คือคำสั่งขายที่ตั้งไว้ล่วงหน้าเพื่อล็อกกำไรทันทีที่ราคาขึ้นไปถึงเป้าของคุณ ส่วน stop-loss (SL) จะขายโพซิชันทันทีที่ราคาหลุดต่ำกว่าขีดจำกัด เพื่อไม่ให้เทรดที่แย่เพียงครั้งเดียวบานปลาย คำสั่งสองชนิดที่ใช้ด้านล่างคือ GTC (Good-Til-Cancelled - คำสั่งที่รออยู่ใน order book จนกว่าจะถูกจับคู่หรือคุณยกเลิก) และ FOK (Fill-Or-Kill - จับคู่ทั้งคำสั่งทันทีหรือยกเลิกทั้งหมด) อีกคำหนึ่งที่คุณจะเจอคือ mark ซึ่งไม่ใช่ชนิดคำสั่งเลย แต่หมายถึง mid-price ปัจจุบันที่คุณใช้วัดโพซิชันเทียบกับมัน ด้านล่างคือค่าเริ่มต้นจาก trader ของเรา ซึ่งผ่านการใช้งานจริงมาหลายพัน trades แล้ว
- Buy: FOK ที่ 1c เหนือ best ask ข้ามเทรดไปถ้า ask สูงกว่า 0.85 - นี่คือ «กับดัก 0.99»: ตลาดที่เกือบจะชี้ขาดแล้วและราคาอยู่ที่ 0.90+ ให้อัปไซด์เพียงเล็กน้อยแต่ร่วงแรงหากพลิกกลับ ดังนั้นอัตราส่วนความเสี่ยงต่อผลตอบแทนจึงกลับหัวกลับหาง
- Take-profit: GTC sell ที่ entry + 4-6c โพสต์ทันทีหลัง buy fill + รอ settlement 5 วินาที
- Stop-loss ผ่าน mark: เฝ้าดู mid; ถ้า mid ลดลงถึง entry - 8c ให้ FOK sell ที่ best bid (ไม่พัก order; mid blow-through เกิดเร็วมาก)
- Time exit: ถ้า position ยังไม่ปิดภายใน X ชั่วโมง และ PnL อยู่ระหว่าง -2c ถึง +2c ให้ FOK ออกจากตลาด
ตัวเลขจะเปลี่ยนไปตาม strategy แต่รูปแบบจะเหมือนเดิม: take-profit ต้องเป็น GTC เสมอ, stop-loss มักเป็น FOK (เพราะ GTC stops ไม่ fill ตอนที่ mid ทะลุผ่าน), และ time exits มีไว้เพื่อไม่ให้ถือสัญญาณเก่าเกินไป
Monitoring: Telegram, email, dashboards
bot ต้องสังเกตได้แบบ real time มี 3 ชั้น
- Telegram alerts: ทุก fill ทุก halt ทุก error ที่เกิน threshold ใช้ channel หรือ group เฉพาะ อย่าปนกับข้อความส่วนตัว
- Daily summary email: ตอนสิ้นวัน จำนวน trades ทั้งหมด win rate PnL และรายการ halts ที่ถูก trigger อ่านทุกเช้า
- Dashboard: เป็นตัวเลือกแต่มีประโยชน์ endpoint HTTP ง่าย ๆ ที่อ่าน diary และแสดง open positions + fills ล่าสุด + cumulative PnL
รูปแบบคือ: state change ใด ๆ ที่ควรรู้ → Telegram. สรุปท้ายวัน → email. สำรวจแบบ real-time → dashboard
รอบ reconciliation: ทุก fire_exits cycle
ต้องรัน reconciliation บ่อยพอที่จะจับ drift ได้ก่อนที่ trade ถัดไปจะซ้ำเติมมัน รอบความถี่ขึ้นอยู่กับความถี่ของการเทรด
- Strategies ที่มี < 10 trades/วัน: reconcile ทุกชั่วโมง
- Strategies ที่มี 10-100 trades/วัน: reconcile ทุก 15 นาที
- HFT strategies (100+ trades/วัน): reconcile ทุก cycle ของ exit-firing loop
ต้นทุนของ reconciliation คือ chain read 1 ครั้งต่อ token ที่ถืออยู่ ที่ 20 tokens เท่ากับ 20 RPC calls; ถ้าใช้ RPC ระดับ free-tier ก็ยังอยู่ในงบสบาย ๆ อย่า optimize ส่วนนี้เกินไป
สัปดาห์แรก: อยู่ใกล้ ๆ, ลงทุนขนาดเล็ก
สัปดาห์แรกของการ deploy live คือช่วงที่อันตรายที่สุด คุณกำลังค้นพบบั๊กของ live path ที่ paper run ไม่เจอ วินัยที่ควรทำคือ:
- อยู่ใกล้ ๆ-เช็ก Telegram channel ทุกชั่วโมงในช่วงที่ตื่นอยู่
- ลงทุนขนาดเล็ก-ใช้ position size ขั้นต่ำ (5 shares); บั๊กหนึ่งครั้งควรเสียเป็นดอลลาร์ ไม่ใช่หลักร้อย
- ทำ manual reconciliation ตอนสิ้นวันใน 3-5 วันแรก เปรียบเทียบ diary กับ Polymarket UI โดยตรง
- จดบันทึกทุกเรื่องที่ไม่คาดคิด แม้แต่ความสับสนเล็ก ๆ ก็กลายเป็นบั๊กได้ในที่สุด
เมื่อจบสัปดาห์แรก: ถ้าไม่มีบั๊กและ diary ตรงกับความจริง ให้ขยายไปขนาดปกติ ถ้าพบบั๊ก ให้แก้ แล้วรัน smoke-test week อีกครั้ง
การขยาย: เมื่อใดควรฝากเพิ่ม
สัญญาณสำหรับเพิ่มทุน แต่ละระดับมี threshold ต่างกัน
- เพิ่มเงินฝาก +50%: live trades 30 ครั้ง, win rate ต่างจาก paper ไม่เกิน 5 จุด, ไม่มี production halt เพราะบั๊ก
- เพิ่มเงินฝาก +100-200%: live trades 100+ ครั้ง, ทำกำไรสม่ำเสมอใน sample, โครงสร้างพื้นฐานผ่านการทดสอบด้วย outage เล็กน้อยอย่างน้อย 1 ครั้ง
- เพิ่มเงินฝาก +500%+: ทำได้ก็ต่อเมื่อมีกำไรสม่ำเสมอใน live มาแล้ว 6 เดือนขึ้นไป การเพิ่มทุนต้องช้ากว่าความสำเร็จ-คุณต้องมั่นใจว่า edge นี้มีอยู่จริง ไม่ใช่ regime ที่กำลังจะหายไป
ความเสี่ยงใหญ่ที่สุดของการขยายก่อนเวลา: strategy ที่ทำกำไรได้ใน market regime หนึ่งอาจไม่ทำกำไรใน regime ถัดไป ขนาดที่ใหญ่ขึ้นไม่ได้แก้ปัญหานั้น ความอดทนต่างหากที่ช่วยได้





