ข้ามไปยังเนื้อหา
Financial Context Wiki

คำสั่ง Post-only

คำสั่ง Post-only เป็นเงื่อนไขของ Limit Order ที่ขึ้นอยู่กับกฎของแพลตฟอร์ม โดยมุ่งให้คำสั่งเข้าพักในสมุดคำสั่งแทนการรับสภาพคล่องทันที ส่วนการปฏิเสธ การยกเลิก การปรับราคา ลำดับคิว และค่าธรรมเนียมขึ้นอยู่กับกฎจับคู่ที่ใช้จริง

อัปเดต

จัดทำขึ้นเพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำการลงทุน การลงทุนอาจทำให้สูญเสียเงินลงทุนได้

คำตอบโดยตรง

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

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

กลไกการทำงาน

ระบบประเมินว่าคำสั่งจับคู่ทันทีหรือไม่จากสถานะของระบบจับคู่ ไม่ใช่หน้าจอที่อาจล่าช้า Limit Buy ที่ราคาเท่ากับหรือสูงกว่า Ask ที่ดีที่สุด และ Limit Sell ที่ราคาเท่ากับหรือต่ำกว่า Bid ที่ดีที่สุดมักข้ามสมุดคำสั่ง ผลลัพธ์อาจเปลี่ยนจากการปัดตามช่วงราคา การประมูล สมุดที่ราคาชนหรือไขว้กัน สภาพคล่องที่ซ่อนอยู่ การคุ้มครองราคา และการป้องกันการซื้อขายกับตนเอง การปรับราคาอัตโนมัติยังเปลี่ยนราคาจำกัดที่ขอและตำแหน่งในคิว จึงควรยอมรับเฉพาะเมื่อเป็นกฎของแพลตฟอร์มที่ระบุไว้อย่างชัดเจน

Post-only แยกจากเงื่อนไขอื่น GTC, GTD, IOC และ FOK กำหนดอายุคำสั่ง และบางแพลตฟอร์มไม่อนุญาตให้ใช้ Post-only กับเงื่อนไขที่ต้องจับคู่ทันที ส่วน reduce-only, Close-only และช่องด้านของสถานะถือครองใช้ควบคุมความเสี่ยงของสถานะ คำสั่ง Stop หรือ Take-profit อาจยังไม่เข้าสมุดจนกว่าจะถูกกระตุ้น แล้วคำสั่งลูกที่สร้างขึ้นจึงถูกตรวจตามกฎ Post-only ปัจจุบันของแพลตฟอร์ม

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

ใช้กระบวนการต่อไปนี้:

  1. ระบุแพลตฟอร์ม นิติบุคคล ผลิตภัณฑ์ ช่วงการซื้อขาย และเวอร์ชัน API ให้แน่นอน บันทึกช่วงราคา ขนาดล็อต มูลค่าขั้นต่ำ ระดับค่าธรรมเนียม และกฎว่าคำสั่ง Post-only ที่จับคู่ได้ทันทีจะถูกปฏิเสธ ยกเลิก หรือปรับราคา
  2. เก็บ Bid ที่ดีที่สุด Ask ที่ดีที่สุด และความลึกของตลาดพร้อมเวลาและลำดับข้อมูลที่สอดคล้องกัน ระบุฝั่ง ราคา ขนาด อายุคำสั่ง โหมดสถานะ Post-only, Reduce-only, การป้องกันการซื้อขายกับตนเอง และช่องเงื่อนไขกระตุ้น
  3. ปัดราคาและขนาดอย่างแม่นยำ แล้วตรวจการข้ามสมุด กรอบราคา ยอดคงเหลือ มาร์จิ้น ขีดจำกัดคำสั่ง และโหมดที่ใช้ร่วมกันไม่ได้ โดยถือสถานะระบบเมื่อคำสั่งมาถึงเป็นข้อยุติ
  4. ส่งคำสั่งด้วย Client Order ID ที่ไม่ซ้ำ แยกความสำเร็จของการรับส่งออกจากสถานะรับคำสั่ง เข้าพัก หรือสิ้นสุด และบันทึก Server Order ID เวลา และคำตอบทั้งหมด
  5. รับเหตุการณ์คำสั่งและการจับคู่ตามลำดับ กระทบยอดปริมาณสะสม ปริมาณคงเหลือ Fill ID ราคา มูลค่า Flag สภาพคล่อง สกุลเงินของค่าธรรมเนียมหรือส่วนลด และการแก้ไขใดที่เปลี่ยนคิว
  6. ถือว่าการแก้ไข ยกเลิก และแทนที่เป็นการแข่งขันจนกว่าเหตุการณ์สิ้นสุดจะมาถึง ลองใหม่แบบ Idempotent หลังหมดเวลา และซิงค์ใหม่เมื่อข้อความซ้ำ สูญหาย หรือผิดลำดับ
  7. กระทบยอดปริมาณที่จับคู่ ยกเลิก ปฏิเสธ หรือหมดอายุกับสินทรัพย์ ยอดกันไว้ และยอดคงเหลือ จากนั้นประเมินค่าธรรมเนียม ส่วนลด Adverse Selection และการพลาดจับคู่จริง สำหรับแพลตฟอร์ม On-chain ให้ตรวจการรวมธุรกรรม การทำงานของโปรโตคอล และ Finality ที่ต้องการแยกกัน

ตัวอย่าง

  • พฤติกรรมเมื่อข้ามสมุดคำสั่ง Bid และ Ask ที่ดีที่สุดคือ 99.90 / 100.00 และช่วงราคาคือ 0.01 คำสั่ง Post-only Buy 2 BTC at 100.00 จะชน Ask ทันที แพลตฟอร์มแบบปฏิเสธจะปฏิเสธคำขอ ส่วนแพลตฟอร์มแบบยกเลิกจะบันทึกว่าไม่มีการจับคู่แล้วจึงยกเลิก แพลตฟอร์มแบบปรับราคาอาจเลื่อนไปที่ 99.99 แต่ต้องเป็นพฤติกรรมที่มีเอกสารและผู้ใช้เลือก คำสั่ง Buy ที่ 99.99 อาจเข้าพักได้หากสถานะระบบไม่เปลี่ยน แต่ไม่รับประกันว่าจะจับคู่
  • การจับคู่แบบ Maker หลังเข้าพักและค่าธรรมเนียม คำสั่ง Sell 3 ETH at 99.90 เข้าพักขณะ Bid และ Ask อยู่ที่ 99.80 / 100.00 แล้วถูกจับคู่โดยคำสั่ง Buy เชิงรุก มูลค่าคือ 3 x 99.90 = 299.70 เมื่ออัตรา Maker เป็น -1 bp ค่าธรรมเนียมคือ 299.70 x -0.0001 = -0.02997 ซึ่งเป็นส่วนลด หากจัดประเภทผิดเป็นอัตรา Taker 5 bp จะกลายเป็นค่าใช้จ่าย 0.14985 ต่างกัน 0.17982 ให้ใช้ Flag สภาพคล่องและบันทึกค่าธรรมเนียมจริง
  • การจับคู่บางส่วนและการแข่งขันกับการยกเลิก คำสั่ง Post-only Sell ที่พักอยู่มีขนาด 10 units at 100 จับคู่ไป 4 แล้วลูกค้าส่งคำขอยกเลิก ก่อนยกเลิกสำเร็จมีอีก 1 ถูกจับคู่ จึงเหลือ 5 ที่ถูกยกเลิก ปริมาณจับคู่รวมคือ 5 ไม่ใช่ 4 มูลค่าจับคู่คือ 500 และส่วนลด 2 bp เท่ากับ 0.10 การตอบรับคำขอยกเลิกไม่ใช่บันทึกสินทรัพย์ขั้นสุดท้าย
  • ค่าธรรมเนียมต่ำกว่าก็ยังอาจแพงกว่า การซื้อ 10 ทันทีที่ 100.00 ด้วยค่าธรรมเนียม Taker 8 bp มีต้นทุน 1,000.80 หากพลาดราคานั้นแล้วเข้าพักภายหลังที่ 100.20 ด้วยค่าธรรมเนียม Maker 2 bp ต้นทุนจะเป็น 1,002.2004 เส้นทาง Maker ประหยัดค่าธรรมเนียม 0.5996 แต่ต้นทุนรวมสูงขึ้น 1.4004 Post-only ควบคุมพฤติกรรมการจับคู่ ไม่ได้ปรับผลการซื้อขายทั้งหมดให้ดีที่สุดโดยอัตโนมัติ

ความเสี่ยง

  • นำกฎ Post-only ของแพลตฟอร์มหรือผลิตภัณฑ์อื่นมาใช้ผิด
  • คำสั่งที่จับคู่ได้ทันทีถูกปฏิเสธ ยกเลิก หรือปรับราคาโดยไม่คาดคิด
  • ความล่าช้าของราคาเปลี่ยนราคาที่ไม่ข้ามสมุดฝั่งลูกค้าให้ข้ามเมื่อถึงระบบ
  • การปัดตามช่วงราคาเปลี่ยนราคาที่ส่งหรือผลทดสอบการข้าม
  • การประมูล สมุดที่ราคาชนกัน หรือโหมดซื้อขายพิเศษเปลี่ยนพฤติกรรม
  • คำสั่งที่พักอยู่ไม่ถูกจับคู่เลย
  • Adverse Selection มีมูลค่าสูงกว่าส่วนลด Maker
  • ระดับ เครื่องหมาย หรือสกุลเงินค่าธรรมเนียมเปลี่ยน
  • อนุมานสถานะ Maker จากคำขอแทนที่จะดูแต่ละรายการจับคู่
  • ประเมินความลึกของคิวหรือสภาพคล่องที่ซ่อนอยู่ต่ำเกินไป
  • การแก้ไขคำสั่งทำให้เสียลำดับคิว
  • ไม่บันทึกการจับคู่บางส่วนในสินทรัพย์หรือเงินสด
  • การแข่งขันของการยกเลิกหรือแทนที่ทำให้เกิดการจับคู่เพิ่มหรือคำสั่งซ้อนกัน
  • การหมดเวลาหรือการลองใหม่ที่ไม่ Idempotent ทำให้สถานะไม่แน่นอนหรือซ้ำ
  • ช่องว่าง ข้อความซ้ำ หรือเหตุการณ์ WebSocket ผิดลำดับทำให้มุมมองภายในผิด
  • การป้องกันการซื้อขายกับตนเองยกเลิกหรือลดฝั่งที่ไม่คาดคิด
  • Post-only ขัดกับ IOC, FOK หรือกฎอายุคำสั่งอื่น
  • Reduce-only, Close-only หรือโหมดสถานะปฏิเสธ ลดขนาด หรือกลับเจตนา
  • คำสั่งลูกหลังถูกกระตุ้นกลายเป็นคำสั่งที่จับคู่ได้ทันทีแล้วถูกยกเลิกหรือปฏิเสธ
  • ความขัดข้องของแพลตฟอร์ม ผู้รับฝาก API หรือกฎ ตลอดจนการเรียงลำดับ On-chain ค่า Gas, Reorg หรือ Finality ทำให้กระทบยอดไม่ได้

ความเข้าใจผิดที่พบบ่อย

  • Post-only รับประกันว่าจะจับคู่ คำสั่งอาจถูกปฏิเสธ ยกเลิก พักโดยไม่จับคู่ หรือหมดอายุ
  • API ตอบว่าสำเร็จแปลว่าคำสั่งพักอยู่ในสมุดแล้ว การตอบรับระดับการรับส่งและสถานะระบบจับคู่เป็นคนละบันทึก
  • ทุกการจับคู่แบบ Post-only ได้ส่วนลด การจัดเป็น Maker ระดับค่าธรรมเนียม สกุลเงิน และอัตราขึ้นอยู่กับแต่ละรายการจับคู่และแพลตฟอร์ม
  • การแก้ไขหรือยกเลิกป้องกันการจับคู่ภายหลังทั้งหมด ลำดับอาจถูกตั้งใหม่ และการจับคู่อาจเกิดก่อนการยืนยันสิ้นสุด
  • Hash ธุรกรรมหรือการรวมในบล็อกพิสูจน์ว่าคำสั่ง On-chain เป็นสภาพคล่อง Maker และจับคู่เสร็จสมบูรณ์แล้ว การรวมธุรกรรม การทำงานของโปรโตคอล สถานะเข้าพัก การจับคู่ และ Finality ของเครือข่ายเป็นคนละเหตุการณ์

หัวข้อที่เกี่ยวข้อง

แหล่งข้อมูล

การนำทาง

ค้นหาในวิกิ...