---
title: "กำหนดเวลา Slippage และ calldata ของสวอป: สิ่งที่ต้องตรวจสอบก่อนลงนาม"
description: "เรียนรู้วิธีถอดรหัสคำสั่งสวอปบน DEX และตรวจสอบเราเตอร์ ฟังก์ชัน ขอบเขตจำนวน เส้นทาง ผู้รับ และกำหนดเวลาก่อนลงนาม"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# กำหนดเวลา Slippage และ calldata ของสวอป: สิ่งที่ต้องตรวจสอบก่อนลงนาม

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

<a id="answer"></a>

## คำตอบโดยตรง

ก่อนลงนามในสวอปบน DEX ให้ตรวจสอบเครือข่าย สัญญาปลายทาง ฟังก์ชันที่ถอดรหัสแล้ว ที่อยู่โทเคน ขอบเขตอินพุตหรือเอาต์พุต เส้นทาง ผู้รับ และกำหนดเวลาทั้งหมด เปอร์เซ็นต์ที่ส่วนติดต่อแสดงว่าเป็น “slippage” ไม่ใช่คำสั่งบนเชนโดยตัวมันเอง โดยทั่วไปจะใช้คำนวณขอบเขต เช่น `amountOutMin` หรือ `amountOutMinimum` สำหรับสวอป exact-input หรือ `amountInMax` หรือ `amountInMaximum` สำหรับ exact-output

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

Calldata ไม่ได้อธิบายตัวเอง ต้องถอดรหัสด้วย ABI ที่ตรวจสอบแล้วของสัญญาที่ถูกต้องบนเครือข่ายที่เลือก รวมถึง multicall หรือคำสั่ง Universal Router ที่ซ้อนอยู่ หากกระเป๋าเงินไม่แสดงฟิลด์ที่ถอดรหัสอย่างน่าเชื่อถือ อย่าคาดเดาความหมายจากตำแหน่งไบต์หรือฐานข้อมูลชื่อฟังก์ชันเพียงอย่างเดียว

<a id="mechanism"></a>

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

### ถอดรหัสคำสั่งจริง

ตาม ABI ของ Solidity `4 bytes` แรกของ calldata คือ function selector และอาร์กิวเมนต์ที่เข้ารหัสเริ่มจากไบต์ที่ห้า Selector อาจชนกันหรือถูกติดป้ายผิด จึงต้องเทียบกับ ABI ของสัญญาปลายทางที่ตรวจสอบแล้ว พร็อกซี ตัวรวบรวม หรือเราเตอร์อาจห่อสวอปไว้ใน `multicall`, `execute` หรือฟังก์ชันอื่น ให้ถอดรหัส payload ที่ซ้อนทุกส่วนซึ่งสามารถโอนโทเคนหรือเปลี่ยนผู้รับสุดท้ายได้

ในสวอป exact-input อินพุตจะคงที่และฟิลด์ป้องกันกำหนดเอาต์พุตขั้นต่ำที่ยอมรับได้ ใน exact-output เอาต์พุตที่ต้องการจะคงที่และฟิลด์ป้องกันจำกัดอินพุต ขอบเขตเป็นศูนย์หรือกว้างผิดคาดอาจทำให้ไม่มีการป้องกันราคาที่มีความหมาย จำนวนทศนิยมของโทเคนสำคัญ: จับคู่ที่อยู่โทเคนแต่ละรายการกับจำนวนทศนิยมและสัญลักษณ์ที่ถูกต้องก่อนเปรียบเทียบจำนวนเต็มดิบ

### ตรวจสอบเส้นทาง ผู้รับ และ value

ยืนยันว่าเส้นทางเริ่มด้วยโทเคนที่ใช้จ่ายและจบด้วยโทเคนที่คาดว่าจะได้รับ ตรวจสอบโทเคนตัวกลาง ค่าธรรมเนียมพูล และคำสั่งที่ห่อ แกะห่อ กวาด หรือโอนยอดคงเหลือ ผู้รับควรเป็นกระเป๋าเงินที่ตั้งใจไว้หรือสัญญาที่เข้าใจพฤติกรรมแล้ว ตรวจสอบ `value` ดั้งเดิมของธุรกรรมด้วย เพราะอาจแยกจากจำนวน ERC-20 ที่เข้ารหัสใน calldata

### ค้นหากำหนดเวลา

ตำแหน่งกำหนดเวลาขึ้นอยู่กับรุ่นของเราเตอร์ ฟังก์ชันเราเตอร์แบบ Uniswap V2 มีอาร์กิวเมนต์ `deadline` และโครงสร้าง `ISwapRouter` ดั้งเดิมของ Uniswap V3 ก็มีเช่นกัน Universal Router มีทั้ง `execute(commands, inputs, deadline)` และ overload ที่ไม่มีกำหนดเวลา ดังนั้นอย่าสันนิษฐานว่าทุกสวอปมีกำหนดเวลา หรือกำหนดเวลาอยู่ในพารามิเตอร์สวอปที่ซ้อนแบบเดียวกันเสมอ

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

<a id="example"></a>

## ตัวอย่างโดยละเอียด

ราคาประเมินคาดว่าจะได้รับ `10,000 USDC` จากสวอป exact-input และผู้ใช้เลือก slippage `1%` หากไม่นับค่าธรรมเนียมที่รวมในราคาแล้ว เอาต์พุตขั้นต่ำที่คาดหวังคือ `9,900 USDC` เนื่องจาก USDC ใช้ `6 decimals` จำนวนเต็มดิบของขอบเขตนี้คือ `9900000000`

แต่คำสั่งที่ถอดรหัสมี `amountOutMinimum = 9000000000` หรือ `9,000 USDC` ซึ่งอนุญาตให้ได้น้อยกว่าราคาประเมินถึง `10%` ไม่ใช่ `1%` ผู้รับยังเป็นที่อยู่ที่ไม่คุ้นเคย และกำหนดเวลาอยู่ห่างออกไปหลายชั่วโมง ความไม่ตรงกันเพียงข้อใดข้อหนึ่งก็เพียงพอให้ปฏิเสธคำขอและสร้างใหม่ผ่านส่วนติดต่อที่เชื่อถือได้ หลังสร้างใหม่ ให้จำลองธุรกรรมที่ยังไม่ลงนามรายการเดียวกันกับสถานะล่าสุด และตรวจ payload ที่ถอดรหัสอีกครั้งก่อนลงนาม

<a id="risks"></a>

## รายการตรวจสอบและความเสี่ยง

- เทียบเครือข่ายที่เลือกและที่อยู่เราเตอร์หรือพร็อกซีกับบันทึกการติดตั้งอย่างเป็นทางการของโปรโตคอล
- ถอดรหัสด้วย ABI ของสัญญาที่ตรวจสอบแล้ว เปิดคำสั่งซ้อนและคำสั่งเราเตอร์แทนการตรวจเฉพาะฟังก์ชันชั้นนอก
- เทียบที่อยู่โทเคน ทิศทาง ทศนิยม จำนวนคงที่ ขอบเขตป้องกัน เส้นทาง ระดับค่าธรรมเนียม ผู้รับ และ `value` ดั้งเดิม
- แปลงกำหนดเวลาเป็นเวลาที่แน่นอนและตัดสินว่าช่วงเวลาที่เหลือเป็นไปตามเจตนาหรือไม่ ให้ถือว่าการไม่มีกำหนดเวลาเป็นตัวเลือกการออกแบบที่ต้องตรวจแยก
- จำลองธุรกรรมเดียวกันจากที่อยู่ผู้ลงนามเทียบกับสถานะล่าสุด การจำลองสำเร็จเป็นหลักฐานเฉพาะสถานะนั้น ไม่ใช่การรับประกันการรวมหรือผลสุดท้าย
- ตรวจการอนุมัติหรือสิทธิ์ Permit2 แยกต่างหาก ขอบเขตสวอปที่ดีไม่ได้ทำให้การอนุญาตโทเคนแบบไม่จำกัดหรือประสงค์ร้ายปลอดภัย
- ขอบเขตแคบอาจ revert จากการเคลื่อนไหวราคาปกติ ส่วนขอบเขตกว้างเพิ่มความเสี่ยงด้านราคาดำเนินการและการโจมตี sandwich ธุรกรรมบนเชนที่ revert แล้วยังอาจใช้ gas

<a id="misconceptions"></a>

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

### ความเชื่อผิด: เปอร์เซ็นต์ slippage ที่แสดงคือสิ่งที่ลงนาม

โดยทั่วไป payload ที่ลงนามมีขอบเขตจำนวนซึ่งคำนวณจากการตั้งค่านั้น ตรวจสอบจำนวนเต็มจริงและทศนิยมของโทเคน ป้ายในส่วนติดต่อที่ดูถูกต้องไม่ได้พิสูจน์ว่า calldata ใช้ค่าความคลาดเคลื่อนเดียวกัน

### ความเชื่อผิด: ทุกสวอปใช้ `amountOutMin` และ `deadline`

ชื่อและตำแหน่งต่างกันตามเราเตอร์และฟังก์ชัน สวอป exact-output ป้องกันด้านอินพุต และจุดเข้าใช้งานบางแบบไม่มีกำหนดเวลาหรือวางไว้ในคำสั่งชั้นนอก

### ความเชื่อผิด: กำหนดเวลาป้องกันราคาที่ไม่ดี

มันจำกัดเวลาให้ทำงานได้ก็ต่อเมื่อโค้ดที่เรียกบังคับใช้ การป้องกันราคามาจากขอบเขตจำนวน ซึ่งยังอนุญาตการทำงานทุกแบบภายในขอบเขตนั้น

### ความเชื่อผิด: ถอดรหัสฟังก์ชันชั้นนอกก็เพียงพอ

ตัวรวบรวมและ universal router อาจมีหลายคำสั่ง สิทธิ์โทเคน การโอน และคำสั่งเก็บกวาด ผู้รับหรือจำนวนที่สำคัญต่อความปลอดภัยอาจอยู่ใน payload ที่ซ้อน

<a id="related"></a>

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

- [ถอดรหัส calldata ในกระเป๋าเงิน](/th/crypto/calldata-decoding-wallet/)
- [รายการตรวจสอบ slippage และเส้นทาง DEX](/th/crypto/dex-slippage-route-checklist/)
- [การโจมตี sandwich](/th/crypto/sandwich-attack/)
- [Slippage ในการซื้อขายคริปโต](/th/crypto/slippage-crypto/)
- [การจำลองธุรกรรม](/th/crypto/transaction-simulation/)

<a id="sources"></a>

## แหล่งข้อมูล

- [Contract ABI Specification](https://docs.soliditylang.org/en/latest/abi-spec.html) - Solidity Documentation (เข้าถึงเมื่อ: 2026-08-21)
- [IUniswapV2Router01.sol](https://github.com/Uniswap/v2-periphery/blob/master/contracts/interfaces/IUniswapV2Router01.sol) - Uniswap (เข้าถึงเมื่อ: 2026-08-21)
- [ISwapRouter.sol](https://github.com/Uniswap/v3-periphery/blob/main/contracts/interfaces/ISwapRouter.sol) - Uniswap (เข้าถึงเมื่อ: 2026-08-21)
- [Universal Router Commands](https://developers.uniswap.org/docs/protocols/universal-router/concepts/commands) - Uniswap (เข้าถึงเมื่อ: 2026-08-21)

Source: https://wiki.fcontext.com/th/crypto/swap-deadline-slippage-calldata/index.mdx