---
title: "วิธีกำหนด Buffer ป้องกันการ Liquidate ใน DeFi"
description: "สร้าง Buffer ป้องกันการ Liquidate ใน DeFi จากราคาหลักประกันภายใต้ภาวะกดดัน การเพิ่มขึ้นของหนี้ พฤติกรรม Oracle และความล่าช้าของธุรกรรม แล้วกำหนดระดับดำเนินการสำหรับชำระหนี้และลด Leverage"
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.

# วิธีกำหนด Buffer ป้องกันการ Liquidate ใน DeFi

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

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

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

Buffer ป้องกันการ Liquidate คือระยะห่างระหว่าง Health Factor ของสถานะภายใต้ภาวะกดดันกับเกณฑ์ Liquidation ของโปรโตคอล การกำหนด Buffer ต้องคำนวณสถานะทั้งหมดใหม่โดยให้ราคาหลักประกันลดลง ราคาสินทรัพย์หนี้เพิ่มขึ้น ดอกเบี้ยสะสม และเกิดความล่าช้านานพอสำหรับการชำระหนี้บน Chain พร้อมกัน อย่าถือว่า Health Factor ที่แสดงสูงกว่า `1` เป็นขีดจำกัดความเสี่ยงที่สมบูรณ์

ควรกำหนดระดับดำเนินการสามระดับ แทนการตั้ง Alert เดียวที่แจ้งเตือนในนาทีสุดท้าย:

- **ระดับเป้าหมาย:** Health Factor ที่ต้องฟื้นกลับมาในภาวะปกติ โดยเลือกให้ Stress Scenario ที่กำหนดยังคงเหลือระยะสำหรับดำเนินการ
- **ระดับเตือน:** จุดที่หยุดกู้เพิ่ม และผู้ดำเนินการตรวจสอบว่าสินทรัพย์ชำระหนี้และ Gas ที่เตรียมไว้พร้อมใช้ทันทีใน Wallet และ Chain ที่มีหนี้
- **ระดับบังคับลด Leverage:** ระดับที่สูงกว่าเกณฑ์ Liquidation ของโปรโตคอล ซึ่งต้องชำระหนี้ทันทีโดยไม่พึ่งการโอนหลักประกัน Bridge การถอนจาก Exchange หรือการคาดหวังให้ราคาฟื้นตามดุลยพินิจ

แต่ละระดับต้องกำหนดให้เหมาะกับสถานะนั้นโดยเฉพาะ ความผันผวน สหสัมพันธ์ระหว่างหลักประกันกับหนี้ สภาพคล่อง การออกแบบ Oracle ความผันผวนของอัตราดอกเบี้ย พารามิเตอร์โปรโตคอล และเวลาที่ใช้ทำธุรกรรม ล้วนมีผล เอกสารของ Aave ระบุเช่นกันว่าไม่มี Health Factor ใดที่ปลอดภัยสำหรับทุกกรณี

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

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

สำหรับสถานะที่มีหลักประกันและสินทรัพย์หนี้หลายชนิด Health Factor รูปแบบหนึ่งที่ใช้ทั่วไปคือ:

`HF = Σ(q_i × P_i × LT_i) ÷ Σ(D_j)`

ในที่นี้ `q_i` คือจำนวนหลักประกัน `P_i` คือราคา Oracle ของโปรโตคอล `LT_i` คือ Liquidation Threshold ของสินทรัพย์นั้น และ `D_j` คือมูลค่าตาม Oracle ของหนี้แต่ละรายการซึ่งรวมดอกเบี้ยสะสมแล้ว หลักประกันแต่ละชนิดต้องใช้ Threshold ของตัวเอง ห้ามนำ Threshold ที่สูงที่สุดไปใช้กับ Portfolio ทั้งหมด

บน Aave เมื่อ Health Factor ต่ำกว่า `1` สถานะจะเปิดให้บุคคลใดก็ได้ Liquidate ผู้ Liquidate จะชำระหนี้และรับหลักประกันพร้อม Liquidation Bonus เอกสารปัจจุบันของ Aave ยังระบุว่าจำนวนที่ Liquidate ได้ขึ้นอยู่กับ Health Factor และขนาดสถานะ โปรโตคอลอื่นอาจใช้เกณฑ์กระตุ้น Close Factor Bonus กฎ Isolation หรือกลไก Auction ที่ต่างกัน จึงต้องตรวจพารามิเตอร์ปัจจุบันของตลาดและ Deployment ที่ใช้งานจริง

สำหรับสถานะที่มีหลักประกันชนิดเดียว โดยหนี้ Threshold และความสัมพันธ์กับ Oracle ไม่เปลี่ยนแปลง อัตราที่ราคาหลักประกันต้องลดลงเพื่อให้สถานะถึง `HF = 1` คือ:

`d_liq = 1 - 1 ÷ HF_current`

ดังนั้นภายใต้สมมติฐานที่จำกัดนี้ `HF_current = 1.20` หมายความว่าราคาหลักประกันลดลงเพียง `16.67%` ก็ถึงเกณฑ์ ไม่ใช่ `20%` สูตรลัดนี้ใช้ไม่ได้เมื่อราคาหนี้ ดอกเบี้ย องค์ประกอบหลักประกัน หรือพารามิเตอร์โปรโตคอลเปลี่ยนไปด้วย

สร้าง Buffer ที่แท้จริงด้วย Health Factor ภายใต้ภาวะกดดัน:

`HF_stress = Σ[q_i × P_i × (1 - s_i) × LT_i] ÷ Σ[D_j × (1 + u_j) × (1 + r_j × t)]`

ในการประมาณเพื่อวางแผนนี้ `s_i` คือ Shock ของราคาหลักประกัน `u_j` คือ Shock ของราคาหนี้ `r_j` คือสมมติฐานอัตราดอกเบี้ยเงินกู้ต่อปี และ `t` คือระยะเวลาล่าช้าในหน่วยปี หากโปรโตคอลมีการคาดการณ์หนี้จริง ให้ใช้ค่านั้น เพราะอัตรากู้ที่เปลี่ยนแปลงและดอกเบี้ยทบต้นอาจทำให้การประมาณอย่างง่ายมองโลกในแง่ดีเกินไป

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

## ตัวอย่าง

สมมติว่าสถานะมีหลักประกัน `10 ETH` ราคา ETH ตาม Oracle เท่ากับ `$2,000` มี Liquidation Threshold `80%` และมีหนี้ Stablecoin `12,000` หน่วยที่ราคา `$1` Health Factor ปัจจุบันคือ:

`HF_current = (10 × 2,000 × 0.80) ÷ 12,000 = 1.333`

จากนั้นรวมภาวะกดดันสามรายการเข้าด้วยกันแทนการทดสอบแยกกัน:

- ETH ลดลง `20%` ทำให้ราคา Oracle ภายใต้ภาวะกดดันเป็น `$1,600`
- สินทรัพย์หนี้ซื้อขายสูงกว่ามูลค่าอ้างอิง `5%`
- หนี้สะสมดอกเบี้ยเป็นเวลา `30 days` ที่สมมติอัตราต่อปี `30%` ก่อนดำเนินการชำระคืน

หนี้ภายใต้ภาวะกดดันโดยประมาณคือ `12,000 × 1.05 × (1 + 0.30 × 30 ÷ 365) = 12,910.68` มูลค่าหลักประกันหลังปรับด้วย Threshold คือ `10 × 1,600 × 0.80 = 12,800` ทำให้ได้ `HF_stress ≈ 0.991` ดังนั้นสถานะที่เริ่มต้นที่ `1.333` จะข้ามเกณฑ์ Liquidation ในสถานการณ์ผสมนี้

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

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

## ความเสี่ยง

### ความเสี่ยงด้านราคาและสหสัมพันธ์

ทำ Stress Test หลักประกันและหนี้ทุกส่วนพร้อมกัน ราคาหลักประกันที่ลดลงอาจเกิดพร้อม Premium ของสินทรัพย์หนี้ และสหสัมพันธ์ที่พบในตลาดสงบอาจใช้ไม่ได้ระหว่างการเทขาย ใช้ Shock ที่มากขึ้นกับสินทรัพย์ที่ซื้อขายเบาบาง ผ่าน Bridge ถูก Wrap หรือเพิ่งเปิดตัว และอย่าถือว่า Stablecoin จะรักษาราคาไว้ที่ `$1` ได้อย่างแม่นยำเสมอ

### ความเสี่ยงจาก Oracle และพารามิเตอร์

การ Liquidate ใช้ราคาและกฎที่โปรโตคอลอ่าน ไม่จำเป็นต้องเป็นราคาล่าสุดใน Exchange ที่ติดตาม Feed ของ Oracle แตกต่างกันทั้งแหล่งข้อมูล ความครอบคลุมสภาพคล่อง พฤติกรรมการอัปเดต และหมวดความเสี่ยงตลาด เอกสารของ Chainlink แนะนำให้ผู้เชื่อมต่อประเมินความแม่นยำ ความพร้อมใช้งาน สภาพคล่องตลาด และการควบคุมความเสี่ยงของ Feed ตรวจสอบ Feed ที่โปรโตคอลใช้จริง และรวมการเปลี่ยนแปลงผ่าน Governance ต่อ `LT_i` เพดาน การตั้งค่า Mode และกฎ Liquidation ไว้ในกระบวนการทบทวน

### ความเสี่ยงด้านดอกเบี้ยและสภาพคล่อง

ดอกเบี้ยเงินกู้เริ่มสะสมทันทีและอาจเปลี่ยนตาม Utilization และพารามิเตอร์ Governance คาดการณ์หนี้ตลอดช่วงเวลาตอบสนองทั้งหมด ไม่ใช่เพียงถึง Alert ถัดไป และทดสอบด้วยว่าสามารถซื้อและ Swap จำนวนที่ตั้งใจชำระคืนโดยไม่เกิด Slippage ที่ยอมรับไม่ได้หรือไม่ เมื่อสภาพคล่องตลาดเสียหาย

### ความเสี่ยงด้านการดำเนินการ

สมมติว่า Frontend ปกติ RPC Endpoint หรือเส้นทาง Hardware Wallet อาจล้มเหลว ทดสอบ Interface สำรองหรือการส่งธุรกรรมตรงไปยังโปรโตคอลล่วงหน้า เตรียมรับค่า Gas ที่เพิ่มขึ้นมาก เก็บ Native Fee Token ไว้นอกสถานะหลักประกัน และเผื่อการแทนที่ nonce การ Approve ที่ล้มเหลว ความแออัดของ Chain รวมถึงความล่าช้าของ L2 Sequencer หรือ Bridge แผนฉุกเฉินที่ต้องโอนต่อเนื่องหลายครั้งไม่ใช่ Buffer ที่ใช้ได้ทันที

### ความสูญเสียจาก Liquidation

Liquidation ไม่ใช่คำสั่ง Stop Loss ที่เป็นกลางต่อมูลค่า ผู้กู้สูญเสียมูลค่าหลักประกันผ่าน Liquidation Bonus และอาจเสียค่าธรรมเนียมโปรโตคอล เผชิญราคาที่เสียเปรียบ และมี Portfolio ที่เหลือเปลี่ยนไป Close Factor อาจจำกัดการ Liquidate หนึ่งครั้ง แต่ป้องกันครั้งต่อไปไม่ได้หากสถานะยังไม่แข็งแรง

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

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

### ความเชื่อที่ 1: `HF = 1.20` หมายถึงมีระยะปลอดภัย `20%`

ในกรณีหลักประกันชนิดเดียวแบบง่าย อัตราลดลงจนถึงเกณฑ์คือ `1 - 1 ÷ 1.20 = 16.67%` สถานะที่มีหลายสินทรัพย์ต้องใช้การคำนวณภายใต้ภาวะกดดันเต็มรูปแบบ

### ความเชื่อที่ 2: การเพิ่มหลักประกันชนิดเดิมทำให้สถานะปลอดภัยขึ้นเสมอ

วิธีนี้เพิ่ม Health Factor ปัจจุบัน แต่เพิ่ม Exposure ต่อ Shock ราคาเดียวกันด้วย การชำระหนี้ลดตัวส่วนโดยตรงและมักเป็นวิธีลด Leverage ฉุกเฉินที่ชัดเจนกว่า

### ความเชื่อที่ 3: หนี้ Stablecoin คงที่ที่ `$1`

Token ที่เป็นหนี้อาจซื้อขายสูงกว่ามูลค่าอ้างอิง ขณะที่ดอกเบี้ยเงินกู้เพิ่มจำนวน Token ที่ต้องชำระ ผลทั้งสองอย่างทำให้ Buffer ลดลง

### ความเชื่อที่ 4: เวลาได้รับ Alert คือเวลาเดียวกับที่ลงมือได้

Alert อาจมาถึงหลัง Oracle เคลื่อนไหวแล้ว และการชำระหนี้ยังอาจต้องเข้าถึง Wallet ทำ Approval รอให้รวมใน Block และรอ Finality ระดับเตือนต้องรวมความล่าช้าเหล่านี้

### ความเชื่อที่ 5: เงินบน Chain อื่นหรือ Exchange คือสภาพคล่องที่พร้อมใช้

การถอน Bridge ขีดจำกัด การบำรุงรักษา และ Finality สร้างการพึ่งพา สินทรัพย์ชำระหนี้ฉุกเฉินควรอยู่บน Chain ของหนี้และอยู่ภายใต้การควบคุมของผู้กู้แล้ว

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

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

- [อัตราส่วนหลักประกัน](/th/crypto/collateral-ratio/)
- [Bridge ข้าม Chain](/th/crypto/cross-chain-bridge/)
- [Finality](/th/crypto/finality/)
- [Health Factor ใน DeFi](/th/crypto/health-factor-defi/)
- [Liquidation Bonus](/th/crypto/liquidation-bonus/)

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

## แหล่งที่มา

- [Health Factor & Liquidations](https://aave.com/help/borrowing/liquidations) - Aave (เข้าถึงเมื่อ: 2026-08-20)
- [Borrow Tokens](https://aave.com/help/borrowing/borrow-tokens) - Aave (เข้าถึงเมื่อ: 2026-08-20)
- [Selecting Quality Data Feeds](https://docs.chain.link/data-feeds/selecting-data-feeds) - Chainlink (เข้าถึงเมื่อ: 2026-08-20)

Source: https://wiki.fcontext.com/th/crypto/defi-liquidation-buffer/index.mdx