การเทรดผ่าน API ของ Polymarket เชื่อมการตัดสินใจซื้อขายเข้ากับลำดับคำขอ สถานะคำสั่ง ระเบียนการซื้อขาย และการเปลี่ยนแปลงบัญชี หน่วยที่ควรทำความเข้าใจคือวงจรคำสั่งที่ยืนยันตัวตนแล้ว โปรแกรมที่ส่งคำขอสำเร็จทำงานเสร็จเพียงส่วนเดียว ยังต้องยืนยันว่าเกิดอะไรขึ้นและเหลือความเสี่ยงเท่าใด
คู่มือนี้กล่าวถึงบริบท API ของ International Polymarket ส่วน Polymarket US เป็นอีกตลาดและอีกบริบทบัญชี จึงควรตรวจอินเทอร์เฟซและสิทธิ์แยกกัน เอกสารปัจจุบันก็สำคัญ เพราะรูปแบบกระเป๋า ไลบรารีไคลเอนต์ และรายละเอียดหลักประกันอาจเปลี่ยน ทำให้ตัวอย่างเก่าไม่ใช่ข้อกำหนดที่เชื่อถือได้สำหรับการเชื่อมต่อใหม่
สถานการณ์ด้านล่างใช้ราคา ปริมาณ และค่าธรรมเนียมสมมติเพื่ออธิบายวงจร ไม่ได้ดำเนินการซื้อขายหรือกำหนดการลงทุน หลักออกแบบใช้ได้กับการตรวจด้วยตนเอง เครื่องมือที่มีผู้กำกับ และขั้นตอนอัตโนมัติที่ได้รับอนุญาต โดยเจ้าของบัญชียังคงควบคุมว่าโปรแกรมทำอะไรได้บ้าง
เริ่มเทรดผ่าน API ของ Polymarket ด้วยระเบียนสัญญา
ระเบียนแรกควรระบุตราสารจริง เก็บตลาด โทเคนผลลัพธ์ ฝั่งที่เลือก กฎฉบับเต็ม และเส้นตายที่เกี่ยวข้อง ชื่ออย่างเดียวแยกสัญญาชื่อคล้ายกันได้ไม่แน่นอน ส่วนตัวระบุโทเคนที่ไม่มีความหมายประกอบก็ยากให้ผู้ตรวจที่เป็นมนุษย์ยืนยัน
สมมติตลาดทวิภาคถามว่าจะออกใบอนุญาตภายในวันที่กำหนดหรือไม่ สิ่งที่ตั้งใจซื้อคือผลลัพธ์ Yes ของคำถามนั้นโดยเฉพาะ ตลาดที่เกี่ยวกับการเริ่มก่อสร้างภายหลังเป็นคนละตราสาร แม้พาดหัวจะมีคำส่วนใหญ่เหมือนกัน
คู่มือเดิมเรื่อง API เทรด Polymarket แยกข้อมูลตลาด คำสั่ง และข้อมูลบัญชี การค้นหาสัญญาอยู่ในส่วนแรก ก่อนส่งคำขอส่วนตัวใด ๆ ระบบควรแสดงให้ผู้อ่านเห็นได้ว่าตั้งใจซื้อขายผลลัพธ์ใด และทำไมตัวระบุนั้นจึงตรงกับการตัดสินใจวิจัย
ใช้ช่องทางเชื่อมต่อฉบับปัจจุบัน
ไคลเอนต์ API ควรผูกกับเวอร์ชันที่มีเอกสารและชุดการดำเนินการที่ทราบว่ารองรับ อย่าสมมติว่าชื่อแพ็กเกจ ตัวอย่างกระเป๋า หรือรูปแบบคำขอเก่ายังเป็นปัจจุบันเพียงเพราะปรากฏในบทสอน ตรวจเอกสารทางการควบคู่กับไลบรารีที่ติดตั้ง
ภาพรวมการเทรด ปัจจุบันของ Polymarket อธิบายการชำระที่เกี่ยวข้องกับ pUSD และโทเคนผลลัพธ์ ระบบจึงควรหลีกเลี่ยงการฝังสมมติฐานหลักประกันแบบเก่าไว้ในทุกการดำเนินการบัญชี การเติมเงิน การอนุมัติ การเทรด และการไถ่ถอนอาจเกี่ยวกับคนละระเบียนที่ต้องตรวจข้อมูลปัจจุบันของตัวเอง
บันทึกวันที่ตรวจเอกสารและเวอร์ชันไคลเอนต์ที่แอปใช้ เมื่อสิ่งใดเปลี่ยน ให้ทำกรณีตรวจรับที่ขึ้นกับลายเซ็น การเข้ารหัสจำนวน และการตีความสถานะใหม่ คำขอข้อมูลตลาดที่สำเร็จไม่ได้ยืนยันว่าเส้นทางเทรดที่ยืนยันตัวตนแล้วเข้ากันได้กับเวอร์ชันเดียวกัน
ระบุผู้ลงนามและกระเป๋าบัญชี
ที่อยู่ที่ลงนามคำขอกับกระเป๋าบัญชีที่ถือเงินหรือสถานะไม่ได้สับเปลี่ยนกันได้ในทุกรูปแบบกระเป๋า ระบบต้องยืนยันความสัมพันธ์ตามการตั้งค่าบัญชีปัจจุบัน การอนุมานจากรูปแบบที่อยู่ที่คุ้นเคยอาจทำให้การอนุญาตล้มเหลวหรือสับสนบัญชี
แสดงบริบทบัญชีที่คาดไว้ก่อนเปิดให้เทรด การตรวจที่มีประโยชน์รวมถึงตลาด ตัวตนกระเป๋า สิทธิ์ที่รองรับ และข้อมูลส่วนตัวที่อ่านอยู่ตรงกับบัญชีที่ต้องการหรือไม่ ผู้ปฏิบัติงานจึงตรวจพบการตั้งค่าที่ถูกต้องทางเทคนิคแต่เชื่อมผิดบัญชีได้
คู่มือกระเป๋าและการยืนยันตัวตน ทางการเป็นจุดเริ่มต้นที่เหมาะสมสำหรับการตั้งค่าเฉพาะกระเป๋าในปัจจุบัน อย่าใส่ข้อมูลลับในล็อกทั่วไปหรือระเบียนที่ผู้ใช้เห็น สมุดบันทึกวงจรต้องการตัวระบุและหลักฐานการอนุญาต ไม่ใช่สำเนาคีย์ส่วนตัวหรือข้อมูลรับรองที่นำกลับมาใช้ได้
แยกการยืนยันคำขอจากการอนุญาตคำสั่ง
การยืนยันตัวตนระบุว่าบัญชีหรือข้อมูลรับรองใดเป็นผู้ส่งคำขอส่วนตัว การอนุญาตคำสั่งระบุคำสั่งซื้อขายที่ลงนามเอง ความต่างนี้สำคัญเพราะซองคำขอที่ถูกต้องไม่ได้ให้เหตุผลในการเปลี่ยนเงื่อนไขทางเศรษฐกิจภายในคำสั่ง
เอกสาร API ของ Polymarket อธิบายการตั้งค่าข้อมูลรับรองผ่านกระเป๋าและคำขอ CLOB ที่ยืนยันตัวตน โดยมีลายเซ็นกระเป๋าอีกส่วนอนุญาตคำสั่ง ระบบควรทำตามข้อกำหนดลงนามปัจจุบัน แทนการถือว่าทุกลายเซ็นเป็นโทเคนทั่วไปแบบเดียว
ในระดับแอป ให้เก็บราคา ปริมาณ ฝั่ง และอายุคำสั่งที่อนุมัติไว้ก่อนลงนาม หากเงื่อนไขใดเปลี่ยน โปรแกรมควรถือว่าเป็นคำสั่งที่เปลี่ยนและต้องผ่านการตรวจอนุญาตที่เกี่ยวข้อง ตัวช่วยลองส่งเครือข่ายใหม่ต้องไม่ขยายขีดจำกัดราคาหรือเพิ่มปริมาณอย่างเงียบ ๆ เพื่อให้ได้คำตอบสำเร็จ
อ่านข้อจำกัดตลาดก่อนสร้างคำสั่ง
คำสั่งที่ใช้ได้ต้องตรงข้อจำกัดปัจจุบันของตลาด รวมถึงช่วงขั้นราคาและข้อกำหนดปริมาณ สิ่งเหล่านี้ต้องอ่านและตรวจ ไม่ใช่คัดลอกจากตัวอย่างอื่นมาใช้ถาวร การเปลี่ยนข้อจำกัดอาจทำให้คำสั่งที่สมเหตุสมผลใช้ไม่ได้
ใช้เลขคณิตทศนิยมและหน่วยชัดเจนเมื่อแปลงการตัดสินใจของมนุษย์เป็นจำนวนในคำขอ ราคาต่อหน่วย จำนวนหน่วย และต้นทุนหลักประกันรวมเป็นคนละปริมาณ ไม่ควรรับฟิลด์ที่เก็บอย่างหนึ่งไปใส่ฟิลด์ที่ต้องการอีกอย่างเพียงเพราะทั้งคู่เป็นตัวเลขหรือสตริง
คู่มือส่งคำสั่ง ทางการบันทึกวิธีสร้างปัจจุบัน สำหรับขั้นตอนทั่วไป การตรวจรับสำคัญคือคำสั่งที่เข้ารหัสต้องถอดกลับเป็นเงื่อนไขทางเศรษฐกิจเดียวกับที่ผู้ใช้อนุมัติได้อย่างตรงตัว หลังแสดงและตรวจทานการปัดเศษที่จำเป็นแล้ว
ตรวจสมุดคำสั่งตามขนาดที่ต้องการ
ขีดจำกัดราคากำหนดว่าบัญชียอมจ่ายหรือรับเท่าใด ไม่ได้รับรองว่าจะซื้อขายได้ครบ ก่อนสร้างคำสั่งทันที ให้ตรวจความลึกที่มีภายในขีดจำกัดและเก็บเวลาสังเกตที่ใช้ตัดสินใจ
สมมติสมุดมีสิบหน่วยที่ $0.41 และยี่สิบหน่วยที่ $0.44 ซื้อสามสิบหน่วยจะเสีย $4.10 บวก $8.80 หรือ $12.90 ก่อนค่าธรรมเนียมหากราคาเหล่านั้นยังอยู่ คำสั่งจำกัดซื้อสามสิบหน่วยที่ $0.44 อนุญาตราคาซื้อสูงสุด $13.20 ไม่รวมค่าธรรมเนียมที่เกี่ยวข้อง
ความต่างระหว่างต้นทุนตามสมุดที่คาดกับต้นทุนสูงสุดที่อนุญาตมีประโยชน์ อย่างแรกอธิบายโอกาสที่สังเกต อย่างหลังจำกัดคำสั่ง ทั้งคู่ไม่รับรองการจับคู่สุดท้าย ราคาเสนอเปลี่ยนหลังตรวจได้ และคำสั่งอาจถูกปฏิเสธหรือดำเนินการบางส่วนตามประเภทและภาวะตลาดปัจจุบัน
เลือกนโยบายส่วนที่เหลืออย่างตั้งใจ
ประเภทคำสั่งกำหนดว่าจะเกิดอะไรหากดำเนินการครบปริมาณทันทีไม่ได้ คำสั่งตั้งรออาจเหลือภาระที่ยังไม่จับคู่ในสมุด คำสั่งที่ยอมจับคู่ทันทีบางส่วนอาจจบด้วยสถานะถือครองและไม่มีส่วนเหลือที่ยังมีผล นี่เป็นคนละสถานะบัญชี
เอกสาร Polymarket ปัจจุบันแยก FOK ซึ่งต้องจับคู่ครบทันทีหรือยกเลิก ออกจาก FAK ซึ่งจับคู่ปริมาณที่มีและยกเลิกส่วนที่เหลือ ดังนั้น FAK ที่จับคู่บางส่วนไม่ทิ้งส่วนที่ยังไม่จับคู่ตั้งรอ ส่วน GTC และ GTD มีพฤติกรรมคงอยู่หรือหมดอายุของตน
คู่มือเดิมเรื่อง คำสั่งจำกัดราคาอัตโนมัติบน Polymarket อธิบายว่าทำไมต้องพิจารณาอายุและการจับคู่ร่วมกัน ระบุนโยบายส่วนเหลือที่ตั้งใจในระเบียนเจตนาคำสั่ง เพื่อให้การกระทบยอดภายหลังเทียบพฤติกรรมจริงกับคำสั่งที่อนุมัติได้
กันวงเงินก่อนส่ง
บัญชีควรกันวงเงินที่คำสั่งที่อนุญาตต้องใช้ก่อนส่ง เพื่อป้องกันการตัดสินใจพร้อมกันสองรายการต่างอาศัยเงินพร้อมใช้หรือขีดจำกัดเหตุการณ์เดียวกัน การกันนี้เป็นตัวควบคุมของแอปและควรกระทบยอดกับความหมายบัญชีจริงของตลาด
สำหรับคำสั่งสามสิบหน่วยที่ $0.44 นโยบายท้องถิ่นสมมติอาจกัน $13.20 บวกเผื่อค่าธรรมเนียม $0.30 รวม $13.50 เงินเผื่อนี้สมมติขึ้นเพื่อเป็นตัวอย่าง ไม่ควรถือเป็นค่าธรรมเนียมปัจจุบันของตลาด การจัดการค่าธรรมเนียมจริงควรใช้ข้อมูลปัจจุบันที่เกี่ยวข้อง
กันครั้งเดียวต่อเจตนาทางเศรษฐกิจ ไม่ใช่กันใหม่ทุกครั้งที่ลองส่งเครือข่าย หากไม่ทราบคำตอบ การคงเงินกันไว้ช่วยป้องกันบัญชีใช้วงเงินที่คำขอเดิมอาจผูกพันแล้ว ปล่อยหรือปรับเมื่อหลักฐานคำสั่งและการซื้อขายรองรับสถานะใหม่เท่านั้น
บันทึกเจตนาคำสั่งอย่างคงทน
ระเบียนเจตนาคำสั่งเชื่อมการตัดสินใจวิจัย การอนุมัติความเสี่ยง และคำขอในที่สุด ควรมีตัวระบุท้องถิ่นที่คงที่ บริบทบัญชี สัญญา ฝั่ง ปริมาณ ราคาจำกัด อายุ และฉบับข้อมูลที่ใช้อนุมัติ บันทึกอย่างคงทนก่อนการกระทำออกจากกระบวนการได้
ระเบียนนี้ช่วยฟื้นตัวหลังโปรแกรมล่ม หากไม่มี โปรแกรมอาจเห็นคำสั่งที่ยังมีผลแต่ไม่คุ้นเคยเมื่อเริ่มใหม่และเชื่อมกับการกระทำเดิมของตัวเองไม่ได้ อีกทั้งช่วยให้มนุษย์ตรวจเมื่อส่งคำขอแล้วแต่คำตอบสูญหาย
คู่มือ บอต API ของ Polymarket เน้นพฤติกรรมที่มีขอบเขตเมื่อไม่แน่ใจผลการส่ง แม้เครื่องมือ API ที่คนใช้งานเองก็ได้ประโยชน์จากสมุดบันทึกเดียวกัน จุดประสงค์คือเก็บความหมายการกระทำแยกจากว่าการสื่อสารเครือข่ายจบเรียบร้อยหรือไม่
แนะนำและรับ USDC
แนะนำและรับ USDCโปรแกรมพันธมิตรของเราจ่ายเงินแบบเรียลไทม์
ถือคำตอบการส่งเป็นหลักฐาน
คำตอบส่งสำเร็จให้หลักฐานว่าตลาดรับคำขอในสถานะหนึ่ง ไม่ใช่คำยืนยันสากลว่าทุกหน่วยที่ขอกลายเป็นสถานะที่ชำระสุดท้ายแล้ว อ่านสถานะและตัวระบุที่ส่งกลับตามความหมายในเอกสาร
เก็บคำตอบคู่เจตนาเดิมและเวลาคำขอ รักษาเหตุผลปฏิเสธแทนการเปลี่ยนเป็นป้ายล้มเหลวทั่วไป การถูกปฏิเสธเพราะขั้นราคา วงเงินอนุมัติไม่พอ และการหมดเวลาเครือข่ายต้องติดตามต่างกัน มีเพียงอย่างหลังที่อาจทำให้ผลการดำเนินการยังไม่ทราบจากมุมมองท้องถิ่น
อย่าใช้การตอบรับเป็นหลักฐานเดียวในการแสดงสถานะถือครองสุดท้าย แอปควรบอกได้ตามเหมาะสมว่าส่งแล้ว ยังมีผล ดำเนินการบางส่วน ยกเลิก รอยืนยัน หรือยังสรุปไม่ได้ สถานะระหว่างทางที่ชัดให้ข้อมูลมากกว่าตัวแสดงสำเร็จสีเขียวเพียงอย่างเดียว
ติดตามคำสั่งและรายการซื้อขายแยกกัน
คำสั่งเป็นคำสั่งการที่อาจสร้างรายการซื้อขายหนึ่งรายการหรือหลายรายการ ปริมาณคงเหลือกับระเบียนซื้อขายที่เกี่ยวข้องตอบคำถามที่เกี่ยวกันแต่ต่างกัน คำสั่งที่จับคู่ครบอาจยังมีข้อมูลชำระรายการที่ต้องติดตาม ขณะที่คำสั่งตั้งรอที่จับคู่บางส่วนอาจเหลือปริมาณที่ยังมีผล
วงจรคำสั่งของ Polymarket แยกการจับคู่ออกจากการยืนยันสุดท้าย ระบบที่จัดการวงจรควรรักษาความต่างนี้เมื่อปรับมุมมองบัญชี ไม่ควรรวมสถานะการซื้อขายทุกแบบเป็นสถานะเสร็จสมบูรณ์เดียวกัน
ตัวอย่างสมมติให้จับคู่สิบสองจากสามสิบหน่วย สมุดบัญชีควรระบุสิบสองหน่วยนั้นและสถานะรายการซื้อขาย แล้วหาว่าเกิดอะไรกับอีกสิบแปดหน่วยตามประเภทคำสั่ง การลบปริมาณที่จับคู่จากปริมาณที่ขอมีประโยชน์ แต่ไม่ได้ยืนยันด้วยตัวเองว่าส่วนเหลือยังมีผลหรือไม่
กระทบยอดการจับคู่บางส่วนกับส่วนเหลือ
ต่อจากคำสั่งสามสิบหน่วยสมมติ แต่ให้ดำเนินการเพียงสิบสองหน่วยที่ $0.44 ราคาซื้อเป็น $5.28 หากเป็น FAK และคำตอบสุดท้ายยืนยันว่ายกเลิกส่วนที่เหลือ บัญชีจะได้สิบสองหน่วยและไม่มีภาระคำสั่งค้างจากอีกสิบแปดหน่วย
หากเป็นคำสั่งตั้งรอและอีกสิบแปดหน่วยยังมีผลที่ $0.44 หน่วยเหล่านั้นเป็นภาระราคาซื้อเพิ่มได้ถึง $7.92 รวมการจัดการค่าธรรมเนียมตามนโยบายบัญชีจริง ทั้งสองกรณีมีปริมาณจับคู่เท่ากันแต่เหลือวงเงินต่างกัน
คำขอยกเลิกภายหลังกระทบเฉพาะส่วนที่ยังยกเลิกได้ ไม่ได้ย้อนคืนหน่วยที่ดำเนินการแล้ว ระเบียนบัญชีสุดท้ายจึงควรเชื่อมรายการที่จับคู่ สถานะส่วนเหลือสุดท้าย และค่าธรรมเนียม แทนการถือว่าการยกเลิกทำให้คำสั่งเดิมทั้งชุดไม่เคยมีอยู่
จัดการการยกเลิกเสมือนแข่งกับการจับคู่
ระหว่างตัดสินใจยกเลิกกับได้รับผล คำสั่งอาจดำเนินการเพิ่ม โปรแกรมต้องกระทบยอดทั้งคำตอบยกเลิกและการจับคู่ที่เกี่ยวข้อง การกดปุ่มท้องถิ่นไม่ได้ยืนยันว่าส่วนเหลือถูกนำออกก่อนจับคู่อีก
สมมติบัญชีเชื่อว่าเหลือสิบแปดหน่วย แต่มีอีกห้าหน่วยดำเนินการขณะประมวลผลยกเลิก สถานะสุดท้ายเป็นสิบเจ็ดหน่วย และนำออกสิบสามหน่วยหากยกเลิกส่วนที่เหลือสำเร็จ สมุดบันทึกควรอธิบายการจับคู่เพิ่ม แทนระบุว่าเป็นไปไม่ได้เพราะขอยกเลิกแล้ว
หลีกเลี่ยงการส่งปริมาณเดิมเต็มจำนวนทดแทนทันทีหลังพยายามยกเลิก ต้องยืนยันความเสี่ยงที่เหลือจริงก่อน การทดแทนเป็นการตัดสินใจทางเศรษฐกิจใหม่ ซึ่งควรใช้ราคาปัจจุบัน สถานะบัญชีปัจจุบัน และขีดจำกัดกลยุทธ์เดิม รวมเส้นตายที่อาจผ่านไประหว่างยกเลิก
ฟื้นตัวเมื่อไม่ทราบผลการส่ง
หากการเชื่อมต่อล้มเหลวหลังส่ง คำสั่งเดิมอาจถูกรับแล้ว ขั้นถัดไปคือสืบหาเจตนานั้นจากหลักฐานคำสั่ง รายการซื้อขาย และบัญชีที่มี การสร้างคำสั่งใหม่ที่ไม่เชื่อมกันอาจเพิ่มความเสี่ยงซ้ำ แม้ความพยายามแรกดูไม่สำเร็จในระบบท้องถิ่น
เก็บตัวระบุเดิมและวงเงินที่กันไว้ระหว่างตรวจสอบ ใช้การสอบถามข้อมูลที่มีขอบเขตและวิธีกู้คืนตามเอกสาร หากยืนยันสถานะบัญชีไม่ได้ ให้พักการส่งคำสั่งใหม่ที่เกี่ยวข้องและแจ้งความไม่แน่นอนแก่ผู้ดำเนินการที่รับผิดชอบ การหมดเวลารอควรกลายเป็นสถานะยังไม่มีข้อยุติที่ระบุชัด ไม่ใช่การปฏิเสธที่แต่งขึ้น
การเปรียบเทียบกับ การเทรดผ่าน API ของ Kalshi ช่วยแยกปัญหาระบบกระจายทั่วไปนี้จากอินเทอร์เฟซเฉพาะตลาด ทั้งสองต้องกระทบยอด แต่ตัวระบุ การยืนยันตัวตน สคีมา และความหมายคำสั่งต้องจัดการตามเอกสารปัจจุบันของแต่ละตลาด ไม่ใช่คัดลอกข้ามตัวเชื่อมต่อ
สร้างสถานะใหม่หลังหลุดการเชื่อมต่อ
อัปเดตสตรีมช่วยสังเกตได้รวดเร็ว แต่ไคลเอนต์ที่หลุดต้องมีแผนฟื้นตัว ดึงข้อมูลบัญชีปัจจุบัน กระทบยอดคำสั่งเปิด และเรียกรายการซื้อขายที่เกี่ยวข้องผ่านอินเทอร์เฟซตามเอกสาร จากนั้นเทียบสถานะที่กู้กับสมุดบันทึกท้องถิ่นก่อนอนุญาตความเสี่ยงใหม่
อย่าสมมติว่าข้อความที่เล่นซ้ำเป็นเหตุการณ์ทางเศรษฐกิจใหม่ รายการซื้อขายที่เห็นก่อนและหลังเชื่อมใหม่ควรถูกนับในสถานะครั้งเดียว ตัวระบุคงที่และการจัดการฉบับช่วยให้ทำได้ เหตุการณ์เครือข่ายซ้ำไม่ควรเพิ่มปริมาณจับคู่หรือค่าธรรมเนียมเป็นสองเท่า
บันทึกช่วงที่ไม่แน่นอนและหลักฐานที่ใช้ปิดช่วงนั้น หากยืนยันความครอบคลุมทั้งหมดไม่ได้ ให้รักษาข้อจำกัดนั้นไว้ หน้าบัญชีอาจแสดงการถือครองที่ยืนยันแล้วควบคู่กับปัญหากระทบยอดที่ยังไม่จบ แทนยอดรวมที่ดูแม่นยำเกินจริงจากสตรีมไม่ครบ
แยกการชำระรายการจากการตัดสินเหตุการณ์
การชำระรายการซื้อขายโอนสินทรัพย์ที่เกี่ยวกับการซื้อหรือขาย ส่วนการตัดสินเหตุการณ์ระบุผลสัญญาคาดการณ์ตามกฎ ทั้งสองเป็นคนละระยะ การซื้อที่ยืนยันแล้วไม่ได้หมายความว่าเหตุการณ์ตัดสินแล้ว และผลเหตุการณ์ที่ดูชัดไม่ได้พิสูจน์ว่าบัญชีได้รับเงินจ่ายสุดท้าย
เก็บระเบียนแยกสำหรับสถานะที่ได้มา การตัดสินตลาด และขั้นตอนไถ่ถอนหรือจ่ายเงินที่ใช้กับบัญชี ตัวระบุและหลักฐานที่เกี่ยวข้องอาจต่างกัน การแยกนี้ช่วยมากเมื่อสถานะค้างเป็นเวลานานหลังคำสั่งแรก
คู่มือ ระบบอัตโนมัติ Polymarket จัดระยะเหล่านี้ไว้ในขั้นตอนแบบทำเอง มีผู้กำกับ และมอบหมาย ตัดสินว่าแอปทำระยะใดได้และระยะใดต้องตรวจทาน การอนุญาตส่งการซื้อขายที่มีขอบเขตไม่ควรถูกตีความเป็นอำนาจไม่จำกัดเหนือทุกการดำเนินการกระเป๋าภายหลัง
ทำให้การกระทบยอดบัญชี Polymarket อธิบายได้
การกระทบยอดบัญชี Polymarket เทียบระเบียนแอปกับหลักฐานบัญชีที่เชื่อถือเป็นหลัก ผลควรอธิบายสถานะ ภาระเปิด ปริมาณที่ดำเนินการ ค่าธรรมเนียม และรายการที่ยังไม่คลี่คลาย ยอดคงเหลือต่างกันเป็นอาการที่ต้องตรวจ ไม่ใช่ตัวเลขให้ซ่อนด้วยรายการปรับที่ไม่มีคำอธิบาย
ในตัวอย่างจับคู่บางส่วน ผู้ตรวจควรตามเจตนาเดิมสามสิบหน่วยไปถึงการดำเนินการสิบสองหน่วยและสถานะสุดท้ายของส่วนเหลือได้ หากรายการภายหลังเปลี่ยนสถานะ ควรแสดงแยกพร้อมที่มาของตัวเอง ยอดสุดท้ายควรคำนวณซ้ำจากองค์ประกอบเหล่านั้นได้
ให้การกระทบยอดเป็นอิสระพอจะพบข้อผิดพลาดในเส้นทางส่ง หากเพียงเชื่อสมมติฐานท้องถิ่นเดียวกับที่สร้างคำสั่ง ก็อาจทำผิดซ้ำแทนพบข้อผิดพลาด คำอธิบายที่อ่านเข้าใจมีคุณค่า เพราะผู้ปฏิบัติงานมักพบสัญญาหรือความเชื่อมโยงบัญชีผิดได้เร็วกว่ารหัสไม่ตรงกันทั่วไป
ตรวจรับการเทรดผ่าน API ของ Polymarket ด้วยกรณีครบวงจร
การตรวจรับควรครอบคลุมจับคู่ครบ จับคู่บางส่วนและมีส่วนเหลือค้าง จับคู่ทันทีบางส่วนและยกเลิกส่วนเหลือ การปฏิเสธ การยกเลิกที่แข่งกับการจับคู่ และการส่งที่ไม่ทราบผล แต่ละกรณีควรจบด้วยสถานะบัญชีที่อธิบายได้ หรือเงื่อนไขยังไม่คลี่คลายที่ชัดเจนและขัดขวางการดำเนินต่อที่ไม่เหมาะสม
คู่มือเดิมเรื่อง บอตเทรดผ่าน API ของ Polymarket ให้มุมมองไคลเอนต์ที่ตรวจสอบได้ในภาพกว้าง ใช้บันทึกวงจรประเมินพฤติกรรมของระบบที่พัฒนาขึ้น รวมถึงการเริ่มใหม่และการกู้คืน แทนการทดสอบเพียงว่าปลายทางส่งคำสั่งตอบกลับว่าสำเร็จหรือไม่
ระบบที่สมบูรณ์ทำให้ทุกการเปลี่ยนสำคัญมองเห็นได้ ได้แก่ ตั้งใจอะไร อนุญาตอะไร ส่งอะไร ดำเนินการอะไร และตอนนี้บัญชีถืออะไร ระเบียนนี้ช่วยปฏิบัติงานอย่างรอบคอบเมื่อเอกสารเปลี่ยน และวินิจฉัยความล้มเหลวได้โดยไม่สับสนคำตอบเครือข่าย รายการที่จับคู่ และสถานะสุดท้ายที่กระทบยอดแล้ว