---
title: "จะเกิดอะไรขึ้นหาก Keeper การชำระบัญชีล้มเหลว"
description: "โดยทั่วไปบอตชำระบัญชีที่ล้มเหลวสามารถถูกแทนที่ได้ แต่ความล่าช้าในการดำเนินการทั่วทั้งตลาดอาจทำให้เงินกู้ที่ไม่ปลอดภัยกลายเป็นหนี้เสีย เรียนรู้เส้นทางความล้มเหลว ปัจจัยทางเศรษฐกิจ และมาตรการป้องกันของโปรโตคอล"
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.

# จะเกิดอะไรขึ้นหาก Keeper การชำระบัญชีล้มเหลว

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

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

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

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

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

ผู้ที่รับภาระยอดขาดขึ้นอยู่กับแต่ละโปรโตคอล ฟังก์ชัน `absorb` ของ Compound III โอนหนี้ของบัญชีที่มีหนี้เกินสินทรัพย์ไปยังโปรโตคอลและใช้เงินสำรองของสินทรัพย์ฐาน ขณะที่โปรโตคอลรับหลักประกันไว้ ส่วน `Dog.bark` ของ Maker โอนหนี้ของ Vault ที่ไม่ปลอดภัยไปยังโปรโตคอล เริ่มการประมูลหลักประกัน และบันทึกหนี้ในระบบบัญชี ระบบอื่นอาจใช้เงินสำรอง กองทุนประกันหรือกองทุนรักษาเสถียรภาพ การเพิ่มทุนผ่านธรรมาภิบาล การกระจายผลขาดทุน หรือหลายวิธีร่วมกัน

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

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

## วิธีการทำงาน

เส้นทางทั่วไปของผู้ชำระบัญชีภายนอกมีห้าขั้นตอน:

1. **การเข้าเกณฑ์:** โปรโตคอลอ่าน oracle ที่กำหนดค่าไว้และพิจารณาว่าบัญชีข้ามเกณฑ์การชำระบัญชีแล้ว oracle ที่ล้าสมัยหรือหยุดทำงานอาจทำให้การเปลี่ยนสถานะนี้ล่าช้าหรือถูกบล็อก แม้ราคาตลาดจะเปลี่ยนไปแล้วก็ตาม
2. **การตรวจจับและกำหนดราคา:** บอตนอกเชนจัดทำดัชนีสถานะ จำลองการชำระบัญชี ประเมินมูลค่าที่จะได้รับจากหลักประกัน และตัดสินใจว่าโอกาสนั้นทำกำไรได้หรือไม่
3. **การบรรจุธุรกรรม:** ผู้ชำระบัญชีจัดหาเงินในสินทรัพย์หนี้ที่จำเป็น ส่งธุรกรรม และแข่งขันเพื่อพื้นที่ในบล็อก ความแออัด ค่าธรรมเนียมที่ต่ำเกินไป RPC ที่ล้มเหลว ความขัดแย้งของ nonce หรือการที่ผู้ชำระบัญชีรายอื่นชนะก่อน อาจทำให้ธุรกรรมค้างอยู่หรือถูกย้อนกลับ
4. **การดำเนินการของสัญญา:** สัญญาตรวจสอบราคาปัจจุบัน สถานะบัญชี close factor หรือขีดจำกัดการประมูล การควบคุมการหยุดชั่วคราว และสภาพคล่องที่มีอยู่ ธุรกรรมที่ใช้ได้ในระหว่างการจำลองอาจล้มเหลวหลังจากข้อมูลใดข้อมูลหนึ่งเปลี่ยนแปลง
5. **การจำหน่ายหลักประกัน:** ผู้ชำระบัญชีหรือโปรโตคอลต้องขาย ป้องกันความเสี่ยง หรือประมูลหลักประกันที่ยึดมา สภาพคล่องที่เบาบางและตลาดขาลงอาจเปลี่ยนโบนัสที่ดูน่าสนใจให้เป็นผลขาดทุน

การตัดสินใจอย่างง่ายของผู้ชำระบัญชีคือ `expected profit = liquidation incentive - gas - price impact - hedge cost - expected revert loss` และอาจมีต้นทุนเงินทุนกับค่าธรรมเนียมโปรโตคอลด้วย โบนัสที่ประกาศไว้สูงยังไม่เพียงพอ หากขายหลักประกันใกล้ราคา oracle ไม่ได้หรือมีโอกาสน้อยที่การดำเนินการจะสำเร็จ

ความล้มเหลวมักเกิดเพียงบางส่วน ไม่ใช่ทั้งหมด บัญชี ประเภทหลักประกัน เชน oracle ผู้ให้บริการ RPC หรือการประมูลรายการหนึ่งอาจล้มเหลว ขณะที่ส่วนอื่นยังทำงานต่อไป ตัวอย่างเช่น เอกสาร Liquidation 2.0 ของ Maker มีขีดจำกัดการประมูลทั้งรายหลักประกันและระดับรวม การเริ่มการประมูลใหม่ สิ่งจูงใจสำหรับ Keeper และ circuit breaker สี่ระดับ การควบคุมเหล่านี้เปลี่ยนวิธีที่ความล่าช้าในการดำเนินการแพร่กระจายภายในระบบนั้นโดยเฉพาะ

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

## ตัวอย่างการคำนวณ

สมมติว่าบัญชีที่เข้าเกณฑ์มีหนี้ `100,000 USDC` และหลักประกันมูลค่า `103,000 USDC` โปรโตคอลแบบง่ายอนุญาตให้ผู้ชำระบัญชีชำระคืน `50,000 USDC` และรับหลักประกันมูลค่า `52,500 USDC` ซึ่งเป็นสิ่งจูงใจก่อนหักต้นทุน `5%`

- คาดว่าการขายหลักประกันจะมีต้นทุนจากผลกระทบต่อราคา `2,000 USDC`
- ค่า gas และค่าธรรมเนียมลำดับความสำคัญเท่ากับ `700 USDC`
- ต้นทุนคาดหมายของธุรกรรมที่ถูกย้อนกลับหรือถูกคู่แข่งดำเนินการตัดหน้าเท่ากับ `300 USDC`
- ดังนั้นกำไรคาดหมายคือ `52,500 - 50,000 - 2,000 - 700 - 300 = -500 USDC`

ผู้ชำระบัญชีที่มีเหตุผลอาจรอหรือข้ามบัญชีนี้ หากไม่มีใครดำเนินการและหลักประกันลดลงอีก `5%` มูลค่าจะเหลือ `97,850 USDC` ทำให้เกิดยอดขาด `2,150 USDC` เมื่อเทียบกับหนี้เดิม ก่อนรวมดอกเบี้ยหรือค่าธรรมเนียมเพิ่มเติม การชำระบัญชีในภายหลังยังช่วยลดความเสียหายได้ แต่ไม่สามารถสร้างมูลค่าหลักประกันที่ไม่มีอยู่อีกแล้ว

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

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

## ความเสี่ยงและมาตรการป้องกัน

- **การควบคุมของผู้กู้:** รักษาส่วนเผื่อเหนือเกณฑ์การชำระบัญชีอย่างตั้งใจ ตั้งการแจ้งเตือนอิสระ และเตรียมวิธีที่ผ่านการทดสอบแล้วสำหรับชำระหนี้หรือเพิ่มหลักประกัน อย่าสันนิษฐานว่าส่วนหน้า ผู้ให้บริการระบบอัตโนมัติ หรือผู้ชำระบัญชีจะพร้อมใช้งานเสมอในช่วงที่เครือข่ายแออัด
- **การควบคุมของโปรโตคอล:** ระบบที่แข็งแกร่งกระจายโครงสร้างพื้นฐาน oracle และธุรกรรม ปรับโบนัสและขนาดสถานะขั้นต่ำ จำกัดปริมาณการชำระบัญชี รองรับการชำระบัญชีบางส่วนหรือแบบกลุ่มเมื่อเหมาะสม และกำหนดการหยุดชั่วคราว การเริ่มการประมูลใหม่ เงินสำรอง และการจัดการยอดขาดไว้ก่อนเกิดวิกฤต
- **การควบคุมของผู้ชำระบัญชี:** ผู้ดำเนินการควรใช้ endpoint RPC หลายแห่ง กระทบยอดสถานะบนเชนก่อนลงนาม จำลองกับสถานะที่รอดำเนินการ จัดการการแทนที่ nonce จำกัด slippage และหลีกเลี่ยงการพึ่งพาศูนย์ซื้อขายหรือแหล่งสภาพคล่องแบบ flash เพียงแห่งเดียว
- **การตรวจสอบของผู้ให้กู้และผู้ฝาก:** ระบุลำดับการรับภาระหนี้เสียที่แน่นอน ตรวจสอบว่าเงินสำรองใดครอบคลุมตลาดใด ใครเปลี่ยนพารามิเตอร์ได้ เงินสำรองมีสภาพคล่องและเข้าถึงได้หรือไม่ และจะเกิดอะไรขึ้นหลังเงินสำรองหมด

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

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

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

### ความเชื่อผิด 1: ทุกโปรโตคอลแต่งตั้ง Keeper ที่เชื่อถือได้หนึ่งราย

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

### ความเชื่อผิด 2: สถานะที่เข้าเกณฑ์ถูกชำระบัญชีแล้ว

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

### ความเชื่อผิด 3: การเพิ่ม gas แก้ไขความล้มเหลวได้เสมอ

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

### ความเชื่อผิด 4: หนี้เสียหมายความว่าผู้ให้กู้เสียเงินจำนวนเท่ากันทันที

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

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

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

- [การชำระบัญชีคริปโต](/th/crypto/liquidation/)
- [โบนัสการชำระบัญชี](/th/crypto/liquidation-bonus/)
- [Close factor ของการชำระบัญชี](/th/crypto/liquidation-close-factor/)
- [ราคา oracle ล้าสมัย](/th/crypto/oracle-price-staleness/)
- [กองทุนประกันคริปโต](/th/crypto/insurance-fund/)

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

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

- [Health Factor & Liquidations](https://aave.com/help/borrowing/liquidations) - Aave (เข้าถึงเมื่อ: 2026-08-21)
- [Compound III Docs: Liquidation](https://docs.compound.finance/liquidation/) - Compound (เข้าถึงเมื่อ: 2026-08-21)
- [Liquidation 2.0 Module](https://docs.makerdao.com/smart-contract-modules/dog-and-clipper-detailed-documentation) - Maker Protocol Technical Docs (เข้าถึงเมื่อ: 2026-08-21)

Source: https://wiki.fcontext.com/th/crypto/liquidation-keeper-failure/index.mdx