นักพัฒนาคนหนึ่งแบ่งปันวิธีสร้างบอทเทรด Polymarket โดยการจับความผันผวนของราคาตลาด BTC ในช่วง 15 นาที ภายในไม่กี่วันสามารถเปลี่ยน $1,000 ให้เป็น $1,869 ผลตอบแทนจากการทดสอบย้อนหลังอยู่ที่ 86% บทความนี้อธิบายรายละเอียดเกี่ยวกับตรรกะการสร้างบอท วิธีการทดสอบย้อนหลัง และข้อจำกัดต่างๆ
(ข้อมูลเบื้องต้น: ตลาดทำนายผลชั้นนำ Polymarket ประกาศสร้าง L2 เอง แล้วพลังของ Polygon หายไป?)
(ข้อมูลเสริม: วิธีทำกำไรด้วยกลยุทธ์ Arbitrage บน Polymarket ให้ผลตอบแทนต่อปี 40%?)

สารบัญบทความ

• ตรรกะการสร้างบอท
• การทดสอบย้อนหลัง
• ข้อจำกัดของการทดสอบย้อนหลัง
• โครงสร้างพื้นฐาน

ไม่กี่สัปดาห์ก่อน ผมตัดสินใจสร้างบอท Polymarket ของตัวเอง เวอร์ชันเต็มใช้เวลาหลายสัปดาห์ในการพัฒนา

ผมเต็มใจลงทุนพลังงานเหล่านี้ เพราะบน Polymarket มีช่องโหว่ด้านประสิทธิภาพอยู่จริง ถึงแม้จะมีบอทบางตัวที่ใช้ประโยชน์จากความไม่เต็มประสิทธิภาพเหล่านี้อยู่แล้ว แต่ยังไม่เพียงพอ ตลาดนี้ยังมีโอกาสอีกมากเมื่อเทียบกับจำนวนบอทที่มีอยู่

ตรรกะการสร้างบอท

ตรรกะของบอทนี้อิงจากกลยุทธ์ที่ผมเคยดำเนินการด้วยตนเอง เพื่อเพิ่มประสิทธิภาพ ผมจึงทำให้เป็นอัตโนมัติ บอทนี้ทำงานบนตลาด “BTC 15 นาที UP/DOWN”

บอทจะรันโปรแกรมตรวจสอบแบบเรียลไทม์ สามารถสลับไปยังรอบ BTC 15 นาทีปัจจุบันโดยอัตโนมัติ ผ่านการสตรีมข้อมูล WebSocket เพื่อรับราคาซื้อ/ขายที่ดีที่สุด (best bid/ask) แสดงผลบน UI แบบเทอร์มินัลคงที่ และสามารถควบคุมด้วยคำสั่งข้อความได้เต็มรูปแบบ

ในโหมดแมนนวล คุณสามารถสั่งซื้อขายได้โดยตรง

buy up / buy down ：ซื้อด้วยจำนวนเงินดอลลาร์ที่กำหนด

buyshares up / buyshares down ：ซื้อจำนวนหุ้นที่แม่นยำ โดยใช้คำสั่ง LIMIT (ราคาจำกัด) + GTC (คำสั่งคงอยู่จนกว่าจะยกเลิก) ซึ่งจะดำเนินการตามราคาขายที่ดีที่สุด (best ask) ปัจจุบัน

ในโหมดอัตโนมัติ จะรันวงจรแบบสองช่วง (two-leg) ซ้ำกัน

ขั้นแรก จะสังเกตความผันผวนของราคาในช่วงเวลาที่กำหนดหลังจากเริ่มรอบ ถ้าราคาในด้านใดร่วงเร็วเกินไป (ภายในประมาณ 3 วินาที มีการลดลงอย่างน้อย movePct) จะทำให้เกิด “ช่วงแรก (Leg 1)” โดยจะซื้อในด้านที่ร่วงแรงที่สุด

หลังจากเสร็จสิ้น Leg 1 แล้ว บอทจะไม่ซื้อในด้านเดิมอีกต่อไป มันจะรอ “ช่วงที่สอง (Leg 2 หรือการป้องกันความเสี่ยง)” และจะทำการซื้อในด้านตรงข้ามเมื่อเงื่อนไขต่อไปนี้เป็นจริง: leg1EntryPrice + oppositeAsk <= sumTarget

เมื่อเงื่อนไขนี้เป็นจริง มันจะซื้อในด้านตรงข้าม หลังจากเสร็จสิ้น Leg 2 แล้ว วงจรจะสิ้นสุด บอทจะกลับไปอยู่ในสถานะรอคอยสัญญาณร่วงในรอบถัดไปด้วยพารามิเตอร์เดียวกัน

หากระหว่างรอบมีการเปลี่ยนรอบ บอทจะยกเลิกวงจรนั้นและเริ่มใหม่ในรอบถัดไปด้วยการตั้งค่าที่เหมือนเดิม

พารามิเตอร์ของโหมดอัตโนมัติคือ: auto on [sum=0.95] [move=0.15] [windowMin=2]

• shares：ขนาดตำแหน่งสำหรับการเทรดสองช่วง
• sum：เกณฑ์สำหรับการป้องกันความเสี่ยง
• move (movePct)：เกณฑ์การร่วง (เช่น 0.15 = 15%)
• windowMin：ระยะเวลาที่อนุญาตให้ดำเนินการช่วงแรกหลังจากเริ่มรอบ

การทดสอบย้อนหลัง

ตรรกะของบอทง่ายมาก: รอให้เกิดการขายรุนแรง ซื้อในด้านที่ร่วงเสร็จแล้ว รอให้ราคาสงบและทำการป้องกันความเสี่ยงด้วยการซื้อในด้านตรงข้าม พร้อมกันนี้ต้องแน่ใจว่า: priceUP + priceDOWN < 1

แต่ตรรกะนี้ต้องได้รับการทดสอบ มันใช้ได้ผลในระยะยาวจริงหรือไม่? ที่สำคัญกว่านั้น บอทมีพารามิเตอร์จำนวนมาก (จำนวนหุ้น, ผลรวม, เปอร์เซ็นต์การเคลื่อนไหว, ระยะเวลาในนาที ฯลฯ) ชุดพารามิเตอร์ใดดีที่สุดและสามารถเพิ่มผลกำไรสูงสุด?

ความคิดแรกของผมคือให้บอททำงานจริงเป็นเวลาหนึ่งสัปดาห์และดูผลลัพธ์ ปัญหาคือใช้เวลานานเกินไป และสามารถทดสอบได้แค่ชุดเดียว ในขณะที่ผมต้องการทดสอบหลายชุด

ความคิดที่สองคือใช้ข้อมูลประวัติย้อนหลังจาก Polymarket CLOB API สำหรับการทดสอบย้อนหลัง แต่โชคร้ายที่ข้อมูลประวัติของตลาด BTC 15 นาที UP/DOWN กลับว่างเปล่า ไม่มีข้อมูลราคาในอดีต (ticks) ทำให้ไม่สามารถตรวจจับการร่วงในประมาณ 3 วินาทีได้ ไม่สามารถทดสอบช่วงแรก (Leg 1) ได้ ไม่ว่าจะตั้งค่าพารามิเตอร์อย่างไร ผลลัพธ์ก็จะเป็นศูนย์รอบและ ROI เท่ากับ 0%

หลังจากตรวจสอบเพิ่มเติม ผมพบว่าผู้ใช้อื่นก็เจอปัญหาเดียวกันในการดึงข้อมูลประวัติของบางตลาด ผมทดสอบตลาดอื่นที่มีข้อมูลประวัติจริง และสรุปได้ว่า: สำหรับตลาดนี้ ข้อมูลประวัติไม่ได้ถูกเก็บไว้เลย

ด้วยข้อจำกัดนี้ วิธีเดียวที่จะทดสอบกลยุทธ์นี้ได้อย่างน่าเชื่อถือคือในขณะที่บอททำงานอยู่ ให้บันทึกภาพหน้าจอราคาขายดีที่สุด (best-ask) แบบเรียลไทม์ เพื่อสร้างชุดข้อมูลประวัติของตัวเอง

ตัวบันทึกจะเขียนภาพ snapshot ลงดิสก์ รวมข้อมูลดังนี้:

• เวลาที่บันทึก
• รหัสรอบ (round slug)
• เวลาที่เหลือในวินาที
• รหัสโทเคน UP/DOWN
• ราคาขายดีที่สุด (best ask)

จากนั้น “การบันทึกการทดสอบย้อนหลัง (recorded backtest)” จะทำการเล่นซ้ำภาพ snapshot เหล่านี้ และใช้ตรรกะอัตโนมัติเดียวกันอย่างแน่นอน เพื่อให้ได้ข้อมูลความถี่สูงที่จำเป็นในการตรวจจับการร่วงและเงื่อนไขการป้องกันความเสี่ยง

ผมรวบรวมข้อมูลได้ทั้งหมด 6 GB ภายใน 4 วัน ผมสามารถบันทึกได้มากกว่านี้ แต่คิดว่านี่ก็เพียงพอสำหรับการทดสอบชุดพารามิเตอร์ต่างๆ

ผมเริ่มทดสอบชุดพารามิเตอร์นี้:

• ยอดเงินเริ่มต้น: $1,000
• ซื้อขายครั้งละ 20 หุ้น
• sumTarget = 0.95
• เกณฑ์การร่วง = 15%
• windowMin = 2 นาที

ผมยังใช้ค่าค่าธรรมเนียมคงที่ 0.5% และ Spread 2% เพื่อความระมัดระวังในสถานการณ์อนุรักษ์

ผลการทดสอบย้อนหลังแสดง ROI อยู่ที่ 86% ภายในไม่กี่วัน เงิน $1,000 กลายเป็น $1,869

จากนั้นผมทดสอบพารามิเตอร์ที่ค่อนข้างเสี่ยงมากขึ้น:

• ยอดเงินเริ่มต้น: $1,000
• ซื้อขายครั้งละ 20 หุ้น
• sumTarget = 0.6
• เกณฑ์การร่วง = 1%
• windowMin = 15 นาที

ผลลัพธ์: หลัง 2 วัน ROI อยู่ที่ -50%

ชัดเจนว่าการเลือกพารามิเตอร์เป็นปัจจัยสำคัญมาก มันสามารถทำให้คุณทำกำไรได้มหาศาล หรือขาดทุนอย่างรุนแรง

ข้อจำกัดของการทดสอบย้อนหลัง

แม้จะรวมค่าธรรมเนียมและ Spread แล้ว การทดสอบย้อนหลังยังมีข้อจำกัดหลายด้าน:

• ข้อมูลใช้เวลาหลายวัน ซึ่งอาจไม่เพียงพอสำหรับภาพรวมตลาดที่แท้จริง
• ข้อมูลอ้างอิงจากภาพ snapshot ราคาขายดีที่สุดที่บันทึกไว้เท่านั้น ในความเป็นจริง คำสั่งอาจถูกดำเนินการบางส่วน หรือในราคาที่ต่างออกไป นอกจากนี้ยังไม่ได้จำลองความลึกของออเดอร์บุ๊คและปริมาณการเทรดที่สามารถทำได้
• ไม่จับความผันผวนระดับวินาที (ข้อมูลอัปเดตทุกวินาที) ถึงแม้จะมี time stamp ทุกวินาที แต่ระหว่างช่วงเวลานั้นอาจเกิดเหตุการณ์มากมาย
• ในการทดสอบ การลื่นไหลของราคา (slippage) ถูกสมมุติเป็นค่าคงที่ โดยไม่ได้จำลองความล่าช้าหลายระดับ (เช่น 200–1500 มิลลิวินาที) หรือ peak ของเครือข่าย
• การดำเนินการแต่ละครั้งถูกมองว่าเป็น “ทันที” (ไม่มีคำสั่งรอคิว ไม่มีคำสั่งรอการเติม)
• ค่าธรรมเนียมถูกคิดแบบคงที่ ในความเป็นจริง ค่าธรรมเนียมอาจแตกต่างกันตามตลาด / โทเคน ผู้ให้บริการคำสั่ง และระดับค่าธรรมเนียม

เพื่อความระมัดระวัง ผมใช้กฎว่า: หาก Leg 2 ไม่สามารถดำเนินการก่อนปิดตลาดได้ จะถือว่า Leg 1 ขาดทุนทั้งหมด (total loss)

ซึ่งเป็นการสมมุติที่ระมัดระวังมาก แต่ก็ไม่เสมอไปในความเป็นจริง:

• บางครั้ง Leg 1 อาจปิดก่อนเวลา
• บางครั้งมันอาจเข้า ITM (ในเงิน) และชนะ
• บางครั้งก็อาจขาดทุนเพียงบางส่วน ไม่ใช่ทั้งหมด

แม้จะประเมินความเสียหายสูงเกินจริง แต่ก็เป็นการจำลองสถานการณ์ worst-case ที่เป็นประโยชน์

สิ่งสำคัญคือ การทดสอบย้อนหลังไม่สามารถจำลองผลกระทบของคำสั่งขนาดใหญ่ที่มีต่อออเดอร์บุ๊ค หรือการดึงดูดนักเทรดรายอื่นให้เข้ามาโจมตีคำสั่งของคุณ ในความเป็นจริง คำสั่งของคุณอาจ:

• ทำให้เกิดการเคลื่อนไหวของออเดอร์บุ๊ค
• ดึงดูดหรือขับไล่นักเทรดรายอื่น
• ส่งผลต่อ Slippage แบบไม่เชิงเส้น

การทดสอบย้อนหลังสมมุติว่าคุณเป็นเพียงผู้รับช่วงราคา (price taker) ที่ไม่มีผลกระทบใดๆ

สุดท้ายนี้ ยังไม่ได้จำลองข้อจำกัดด้านอัตราการส่งคำสั่ง (rate limits) ข้อผิดพลาดของ API คำสั่งถูกปฏิเสธ การหยุดชะงัก การหมดเวลา การเชื่อมต่อใหม่ หรือบอทที่ยุ่งจนพลาดสัญญาณ

การทดสอบย้อนหลังมีค่าสำหรับการระบุช่วงพารามิเตอร์ที่ดี แต่ไม่ได้รับประกัน 100% เพราะบางผลลัพธ์ในโลกจริงไม่สามารถจำลองได้

โครงสร้างพื้นฐาน

ผมวางแผนให้บอททำงานบน Raspberry Pi เพื่อหลีกเลี่ยงการใช้ทรัพยากรจากเครื่องหลัก และให้ทำงานตลอด 24/7

แต่ก็ยังมีแนวทางปรับปรุงได้อีกมาก:

• การใช้ Rust แทน JavaScript จะให้ประสิทธิภาพและเวลาในการประมวลผลที่ดีกว่าอย่างมาก
• การรันโหนด RPC ของ Polygon โดยเฉพาะจะลดความหน่วงได้อีก
• การวางเซิร์ฟเวอร์ใน VPS ใกล้กับเซิร์ฟเวอร์ของ Polymarket ก็จะลดความหน่วงได้เช่นกัน

แน่นอนว่ายังมีเทคนิคปรับแต่งอื่นๆ ที่ผมอาจยังไม่รู้จัก ตอนนี้ผมกำลังเรียนรู้ Rust เพราะมันกลายเป็นภาษาที่ขาดไม่ได้ในงาน Web3