คำอธิบายการ resolution ของ Polymarket

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

ข้อสรุปสำคัญ

• การ resolution เริ่มจากการรายงานผลลัพธ์และอาจเข้าสู่ช่วงพิพาทแบบ optimistic ของ UMA ก่อนการชำระขั้นสุดท้าย
• ในขณะที่โทเค็นผลลัพธ์เป็นสินทรัพย์ ERC-1155 ภายใต้ CTF การ split/merge/redeem และการวางคำสั่งซื้อเป็นแบบ gasless สำหรับผู้ใช้ผ่าน Relayer
• การพิพาท ความล่าช้าใน oracle การถูกเติมคำสั่งบางส่วน และระยะเวลาการชำระสร้างความเสี่ยงจริงแม้ราคาแสดง edge ทางคณิตศาสตร์
• จงรู้ลำดับเหตุการณ์: report → dispute window (UMA) → finalization → ไถ่ถอนโทเค็นที่ชนะเป็น pUSD

ความหมายของ "resolution" บน Polymarket

บน Polymarket การ resolution คือกระบวนการที่เปลี่ยนโทเค็นผลลัพธ์ที่ซื้อขายได้ให้เป็นเงินที่สามารถไถ่ถอนได้ สำหรับตลาดแบบไบนารีและหลายผลลัพธ์ oracle จะเป็นผู้กำหนดในท้ายที่สุดว่า outcome ใด(หรือ outcomes ใด) จะ resolve เป็น YES เมื่อผลลัพธ์เป็นที่สิ้นสุด โทเค็นที่ชนะแต่ละชิ้นจะสามารถไถ่เป็น $1.00 ของ pUSD ได้ โทเค็นที่แพ้จะไม่มีมูลค่า

ตลาดใช้ Gnosis Conditional Token Framework (CTF) สำหรับโทเค็นผลลัพธ์ โทเค็นเหล่านี้ทำหน้าที่เหมือนการถือครอง ERC-1155 ใดๆ: คุณสามารถเทรดบน CLOB โอน หรือรวมด้วยการทำ split/merge ความแตกต่างสำคัญตอน resolution คือรายงานสุดท้ายจาก oracle จะปลดล็อก flow การ redeem ของ CTF ที่เปลี่ยนโทเค็นที่ชนะเป็น pUSD

ขั้นตอนการรายงาน: ใครเป็นคนรายงานและทำไมมันสำคัญ

การ resolution เริ่มเมื่อ reporter ยื่นรายงานผลลัพธ์ต่อระบบ oracle Polymarket ใช้ UMA optimistic oracle สำหรับการรายงาน รายงานที่ถูกส่งจะระบุ outcome ที่ reporter เชื่อว่าถูกต้องและเริ่มนับเวลาสำหรับขั้นตอนถัดไป

เหตุผลที่เรื่องนี้สำคัญ:

• รายงานเป็นสัญญาณสาธารณะแรกว่ากิจกรรมในตลาดถึงสภาวะที่สามารถตัดสินผลได้แล้ว ผู้เทรดที่เฝ้าดู order book สามารถตอบสนองทันที
• รายงานปรากฏใน UI ของ Polymarket และผ่าน Gamma API ดังนั้นบ็อต arbitrage และผู้เทรดสามารถตรวจจับแบบโปรแกรมได้

หน้าต่างพิพาทแบบ UMA optimistic (คืออะไร ไม่ใช่ความยาว)

หลังจากมีการโพสต์รายงาน โมเดล optimistic ของ UMA อนุญาตให้มีช่วงเวลาพิพาทที่ผู้ท้าทายสามารถยื่นหลักฐานคัดค้านได้ หากมีการยกคำพิพาท flow แบบ optimistic จะหยุดชั่วคราวและ UMA จะจัดการข้อพิพาทตามกระบวนการของตน

ข้อควรทราบเชิงปฏิบัติ:

• หน้าต่างพิพาทสร้างความไม่แน่นอน ตลาดที่ดูเหมือนว่า resolved แล้วอาจถูกเปิดใหม่เพื่อการตรวจสอบหาก UMA ได้รับการพิพาท
• เนื่องจากรายละเอียดเวลาและการปฏิบัติของ UMA อยู่ภายนอก Polymarket ผู้เทรดควรถือว่าตลาดที่อยู่ในหรือใกล้ช่วงพิพาทมีความเสี่ยงด้านการ resolution

หมายเหตุ: system prompt ระบุว่าใช้ UMA แต่ไม่ได้ให้ความยาวของ dispute-window ดูส่วน Notes สำหรับช่องว่างข้อมูลนั้น

การสรุปผลและการไถ่ถอนโทเค็น CTF

เมื่อกระบวนการของ oracle เสร็จสิ้นและผลลัพธ์เป็นที่สิ้นสุด ตลาดจะถูก finalized บนเชน ในจังหวะนั้นผู้ใช้สามารถไถ่ถอนโทเค็นผลลัพธ์ ERC-1155 ที่ชนะเป็น pUSD ผ่านการดำเนินการ redeem ของ CTF

ในเชิงปฏิบัติตัวอย่างบน Polymarket:

• การดำเนินการ CTF (split / merge / redeem) ถูกจัดการผ่าน Polymarket Relayer ดังนั้นจึงเป็นแบบ gasless สำหรับคุณ
• การไถ่ถอนจะเปลี่ยนโทเค็นที่ชนะแต่ละชิ้นเป็น $1.00 ของ pUSD ซึ่งคุณสามารถถอนออกหรือใช้เพื่อ split เข้าเป็นตำแหน่งใหม่ได้

หากคุณถือ complete set ของโทเค็นผลลัพธ์ก่อน resolution การไถ่ถอนจะตรงไปตรงมา: คุณจะได้รับ pUSD เฉพาะสำหรับขา(leg)ที่ชนะเท่านั้น หากคุณถือพอร์ตไม่เต็มเพียงบางส่วน ก็จะไถ่ถอนเฉพาะโทเค็นที่ชนะที่สอดคล้องกับตำแหน่งของคุณ

กรณีขอบเขต (edge-cases) ที่ผู้เทรดพบบ่อย

• finalizations ที่ถูกพิพาท: พิพาทของ UMA อาจชะลอการชำระและชั่วคราวป้องกันการไถ่ถอน นั่นกระทบสภาพคล่องและอาจกักเงินทุนไว้
• การถูกเติมคำสั่งบางส่วนและการดำเนินคำสั่ง: คำสั่งที่ถูกเติมบางส่วนก่อน resolution อาจทำให้คุณยาวบางโทเค็นและขาด(หรือขาดความสมดุล) ในอีกขา ตรวจสอบการเติมคำสั่งเพื่อลดการเปิดรับความเสี่ยงที่ไม่คาดคิด
• การเปลี่ยน tick-size และการอัปเดตราคา: การเปลี่ยนขนาด tick ใกล้ช่วง resolution อาจเปลี่ยนออร์เดอร์ที่มีอยู่ WebSocket จะส่งเหตุการณ์ tick_size_change ซึ่งสำคัญสำหรับบ็อต
• ผลของค่าธรรมเนียมและรางวัล: maker fee เป็นศูนย์; taker fee แตกต่างตามหมวดหมู่ ค่าธรรมเนียมและการ attribution ของ Builder (ถ้าคุณ route ผ่าน Builder) ส่งผลต่อผลลัพธ์สุทธิแต่ไม่เปลี่ยนกระบวนการชำระของ oracle

อย่าเคยสมมติว่าตลาดที่ชำระแล้วจะไม่ถูกเปิดใหม่หาก UMA เริ่ม flow การพิพาท ยืนยันสถานะตลาดเสมอก่อนเริ่มการไถ่ถอน CTF หรือการโอนขนาดใหญ่

สิ่งนี้ส่งผลต่อกลยุทธ์ arbitrage และ endgame อย่างไร

สำหรับ intra-market arbitrage (การซื้อชุดเมื่อ Σ bestAsk < $1.00) กลไกการ resolution เป็นหัวใจสำคัญ: กำไรทฤษฎีของคุณจะเปลี่ยนเป็น pUSD ได้ก็ต่อเมื่อ finalized และไถ่ถอนแล้ว ซึ่งหมายความว่าเวลา ความเสี่ยงจากพิพาทของ oracle และความล่าช้าในการชำระมีความสำคัญเท่ากับการดำเนินคำสั่ง

กฎเชิงปฏิบัติ:

• ถือ spread เป็น mathematical edge ได้ก็ต่อเมื่อคุณคำนวณค่าธรรมเนียม สลิปเพจ และความเสี่ยงจากพิพาทเสร็จแล้ว ระบุความเสี่ยงเหล่านี้ก่อนเรียกการเทรดว่า arbitrage
• สำหรับกลยุทธ์ endgame (ราคาใกล้ resolution เช่น $0.95–$0.99) ให้ระมัดระวังเป็นพิเศษ: มาร์จิ้นเล็กและพิพาท UMA อาจแปลงการเล่นระยะสั้นให้เป็นขาดทุนได้
• ใช้ APIs ของ Polymarket และ Market WebSocket เพื่อติดตาม report, tick_size_change, best_bid_ask และ last_trade_price แบบเรียลไทม์

การติดตาม resolution โดยโปรแกรม

API และฟีดที่ควรเฝ้าดู:

• Gamma API (https://gamma-api.polymarket.com): เมตาดาต้าตลาดและเหตุการณ์ รวมถึงฟิลด์ที่เกี่ยวกับการ resolution ใช้ endpoint /markets กับการแบ่งหน้าแบบ cursor-based
• Data API (https://data-api.polymarket.com): ตำแหน่ง การเทรด และ open interest สำหรับติดตามการเติมคำสั่งและการรับความเสี่ยง
• Market WebSocket (wss://ws-subscriptions-clob.polymarket.com/ws/market): หนังสือคำสั่งแบบเรียลไทม์, price_change, best_bid_ask, last_trade_price และ tick_size_change PING ทุก 10s; สมัครรับด้วย custom_feature_enabled เพื่อรับ best_bid_ask

รวมฟีดเหล่านี้เพื่อจับสัญญาณการรายงาน เฝ้าติดตามสัญญาณพิพาทจาก UI หรือฟีดข้อมูล และรอการบัญชีขั้นสุดท้ายจนกว่าสถานะตลาดจะเป็น final

เช็คลิสต์: ควรทำอะไรเมื่อมีการรายงานตลาด

• ยืนยัน outcome ที่ถูกรายงานใน Gamma และ UI ของ Polymarket
• หยุดการทำงานอัตโนมัติที่สมมติความเป็น final ทันทีจนกว่าจะผ่านช่วงพิพาทของ UMA
• ติดตามคำสั่งที่เปิดอยู่และการเติมคำสั่ง; ยกเลิกหรือปรับหากจำเป็นเพื่อหลีกเลี่ยงการเปิดรับที่ไม่ตั้งใจ
• หลังการ finalization ให้ไถ่ถอนโทเค็นที่ชนะผ่าน UI, SDK หรือ flow ที่เชื่อมกับ Relayer ของคุณ

สิ่งนี้ส่งผลต่อการเทรดของคุณอย่างไร

การ resolution เป็นคอขวดสุดท้ายระหว่างการดำเนินการเทรดและ pUSD ที่เกิดขึ้นจริง สำหรับผู้เทรดและ arbitrageurs ที่กระฉับกระเฉง หมายความว่าคุณต้องจัดการความเสี่ยงสามด้านที่เชื่อมโยงกัน: การดำเนินการ (การเติมคำสั่งและสลิปเพจ), การ resolution ของ oracle (การรายงานและการพิพาท) และระยะเวลาการชำระ (การไถ่ถอนและการถอนเงิน) การดำเนินงานที่ประสบความสำเร็จต้องมีเครื่องมือฝั่งตลาดที่รวดเร็วและสมมติฐานที่ระมัดระวังเกี่ยวกับความเสี่ยงจากพิพาท

หากคุณสร้างระบบอัตโนมัติ ให้บันทึกการเติมทุกครั้งและเฝ้าดูช่อง WebSocket ที่ระบุข้างต้น ถือว่าตลาดที่อยู่ในหรือใกล้สถานะรายงานมีความเสี่ยงสูงขึ้นจนกว่า UMA จะเคลียร์

ข้อสรุปปิด: คำอธิบายการ resolution ของ Polymarket ควรให้เช็คลิสต์ปฏิบัติการและโมเดลความคิดเพื่อจัดการความเสี่ยงการชำระ ใช้ APIs และ WebSocket เพื่อติดตามเหตุการณ์ จำไว้ว่า CTF redeem เป็นแบบ gasless ผ่าน Relayer และนับช่วงพิพาทก่อนสมมติว่าการเทรดได้กลายเป็น pUSD แล้ว

คำถามที่พบบ่อย

ใครเป็นผู้รายงานผลบน Polymarket?

Polymarket ใช้ UMA optimistic oracle สำหรับการรายงานผล รายงานถูกยื่นไปยัง UMA และแสดงใน UI และ APIs ของ Polymarket; UMA จะจัดการการพิพาทที่ตามมาตามกระบวนการของมัน

เกิดอะไรขึ้นระหว่างหน้าต่างพิพาทของ UMA?

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

การดำเนินการ CTF เป็นแบบ gasless บน Polymarket หรือไม่?

ใช่ Polymarket สนับสนุนค่าแก๊สผ่าน Relayer ของตน การทำ split, merge, redeem, การโอน และการวางคำสั่งถูกทำแบบ gasless ให้กับผู้ใช้ปลายทางเพราะถูก route ผ่าน Relayer

ตลาดสามารถถูกเปิดใหม่หลังจากดูเหมือน resolved ได้หรือไม่?

ได้ หาก UMA ได้รับการพิพาท ตลาดที่ดูเหมือน resolved แล้วอาจถูกเปิดใหม่หรือเลื่อนจนกว่า UMA จะตัดสิน ยึดถือว่าตลาดที่อยู่ในหรือใกล้ช่วงพิพาทมีความเสี่ยงด้านการ resolution

ฉันจะตรวจจับการรายงานหรือการพิพาทโดยโปรแกรมได้อย่างไร?

ใช้ Gamma API สำหรับเมตาดาต้าตลาด และ Market WebSocket (wss://ws-subscriptions-clob.polymarket.com/ws/market) สำหรับเหตุการณ์แบบเรียลไทม์เช่น price_change, best_bid_ask, last_trade_price และ tick_size_change รวมฟีดเหล่านี้กับ Data API เพื่อเฝ้าดูตำแหน่งและการเติมคำสั่ง