---
title: "Apa yang Terjadi Jika Keeper Likuidasi Gagal?"
description: "Bot likuidasi yang gagal biasanya dapat digantikan, tetapi keterlambatan eksekusi di seluruh pasar dapat mengubah pinjaman tidak sehat menjadi kredit macet. Pelajari alur kegagalan, aspek ekonomi, dan perlindungan protokolnya."
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.

# Apa yang Terjadi Jika Keeper Likuidasi Gagal?

> Hanya untuk tujuan edukasi; bukan nasihat investasi. Sistem pinjaman dan likuidasi DeFi dapat menimbulkan kerugian cepat yang tidak dapat dipulihkan.

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

## Jawaban langsung

Kegagalan satu keeper likuidasi biasanya menyebabkan transaksi terlewat atau dibatalkan, bukan kegagalan protokol secara langsung. Dalam banyak protokol pinjaman tidak ada keeper eksklusif: likuidasi bersifat permissionless, sehingga bot, kontrak, atau pengguna lain dapat mengirimkan transaksi tersebut. Aave, misalnya, menyatakan bahwa setiap peserta jaringan dapat melikuidasi posisi yang memenuhi syarat dan menggambarkan likuidasi sebagai proses yang sangat kompetitif.

Kasus yang serius adalah kegagalan kolektif: tidak ada peserta yang mampu atau bersedia mengeksekusi pada harga yang layak secara ekonomi. Posisi dapat tetap berada di bawah ambang likuidasi sementara bunga terus bertambah dan nilai agunan terus bergerak. Jika likuidasi kemudian memulihkan nilai yang lebih kecil daripada utang dan biaya yang dibebankan pada posisi tersebut, selisihnya menjadi defisit atau kredit macet menurut akuntansi protokol itu.

Pihak yang menanggung defisit bergantung pada protokol. Fungsi `absorb` Compound III memindahkan utang akun yang tenggelam kepada protokol dan menggunakan cadangan aset dasar, sedangkan protokol mengambil agunannya. Fungsi `Dog.bark` Maker memindahkan utang Vault yang tidak aman kepada protokol, memulai lelang agunan, dan mencatat utang dalam sistem akuntansinya. Sistem lain dapat menggunakan cadangan, dana asuransi atau stabilitas, rekapitalisasi oleh tata kelola, pembagian kerugian, atau kombinasinya.

Bagi peminjam, otomatisasi likuidasi bukanlah layanan stop-loss. Tindakan yang aman adalah memantau posisi serta melunasi utang atau menambah agunan sebelum ambang terlewati; likuidasi yang tertunda dapat memperbesar kehilangan agunan sekaligus kemungkinan terjadinya defisit yang tidak dapat dipulihkan.

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

## Cara kerjanya

Alur likuidator eksternal pada umumnya memiliki lima tahap:

1. **Kelayakan:** Protokol membaca oracle yang telah dikonfigurasi dan menentukan bahwa akun telah melewati ambang likuidasi. Oracle yang usang atau dijeda dapat menunda atau memblokir perubahan status itu meskipun harga pasar sudah bergerak.
2. **Deteksi dan penetapan harga:** Bot off-chain mengindeks posisi, menyimulasikan likuidasi, memperkirakan hasil agunan, dan memutuskan apakah peluang tersebut menguntungkan.
3. **Penyertaan transaksi:** Likuidator menyediakan aset utang yang diperlukan, mengirimkan transaksi, dan bersaing memperebutkan ruang blok. Kemacetan, biaya yang terlalu rendah, kegagalan RPC, konflik nonce, atau likuidator lain yang lebih dahulu menang dapat membuat transaksi tertunda atau dibatalkan.
4. **Eksekusi kontrak:** Kontrak memeriksa harga saat ini, status akun, faktor penutupan atau batas lelang, kontrol jeda, dan likuiditas yang tersedia. Transaksi yang valid ketika disimulasikan dapat gagal setelah salah satu masukan ini berubah.
5. **Pelepasan agunan:** Likuidator atau protokol harus menjual, melakukan lindung nilai, atau melelang agunan yang disita. Likuiditas tipis dan pasar yang menurun dapat mengubah bonus yang tampak menarik menjadi kerugian.

Keputusan sederhana likuidator adalah `expected profit = liquidation incentive - gas - price impact - hedge cost - expected revert loss`. Biaya modal dan biaya protokol juga dapat berlaku. Bonus tercantum yang besar tidak cukup jika agunan tidak dapat dijual mendekati harga oracle atau jika eksekusi kecil kemungkinannya berhasil.

Kegagalan sering kali bersifat sebagian, bukan mutlak. Satu akun, jenis agunan, chain, oracle, penyedia RPC, atau lelang dapat gagal sementara yang lain tetap berjalan. Dokumentasi Liquidation 2.0 Maker, misalnya, mencakup batas lelang per agunan dan global, pengaturan ulang lelang, insentif keeper, serta circuit breaker empat tahap. Kontrol ini mengubah cara keterlambatan eksekusi menyebar dalam sistem tersebut.

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

## Contoh perhitungan

Anggap sebuah akun yang memenuhi syarat memiliki utang `100,000 USDC` dan agunan senilai `103,000 USDC`. Protokol sederhana mengizinkan likuidator melunasi `50,000 USDC` dan mengambil agunan senilai `52,500 USDC`, yaitu insentif kotor `5%`.

- Penjualan agunan diperkirakan menimbulkan dampak harga sebesar `2,000 USDC`.
- Biaya gas dan prioritas adalah `700 USDC`.
- Perkiraan biaya transaksi yang dibatalkan atau dikalahkan pesaing adalah `300 USDC`.
- Dengan demikian, perkiraan laba adalah `52,500 - 50,000 - 2,000 - 700 - 300 = -500 USDC`.

Likuidator yang rasional dapat menunggu atau melewati akun tersebut. Jika tidak ada yang mengeksekusi dan nilai agunan turun lagi sebesar `5%`, nilainya menjadi `97,850 USDC`, sehingga terdapat defisit `2,150 USDC` terhadap utang awal sebelum bunga atau biaya tambahan. Likuidasi yang dilakukan kemudian masih dapat mengurangi kerugian, tetapi tidak dapat menciptakan kembali nilai agunan yang sudah tidak ada.

Ini adalah ilustrasi, bukan model suatu pasar yang telah diterapkan. Faktor penutupan, bonus, harga oracle, biaya protokol, aturan cadangan, dan biaya transaksi yang sebenarnya harus dibaca dari kontrak terkini dan dokumentasi resmi. Aturan Aave yang dipublikasikan, misalnya, membedakan porsi maksimum yang dapat dilikuidasi berdasarkan faktor kesehatan dan ukuran posisi.

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

## Risiko dan perlindungan

- **Kontrol peminjam:** Pertahankan margin yang disengaja di atas ambang likuidasi, pasang peringatan independen, dan miliki cara teruji untuk melunasi utang atau menambah agunan. Jangan berasumsi bahwa front end, penyedia otomatisasi, atau likuidator akan tetap tersedia selama kemacetan.
- **Kontrol protokol:** Sistem yang kuat mendiversifikasi infrastruktur oracle dan transaksi, mengkalibrasi bonus serta ukuran posisi minimum, membatasi volume likuidasi, mendukung likuidasi sebagian atau massal bila sesuai, dan menetapkan jeda, pengaturan ulang lelang, cadangan, serta penanganan defisit sebelum krisis.
- **Kontrol likuidator:** Operator sebaiknya menggunakan beberapa endpoint RPC, merekonsiliasi status on-chain sebelum menandatangani, menyimulasikan berdasarkan status tertunda, mengelola penggantian nonce, membatasi slippage, serta tidak bergantung pada satu bursa atau sumber likuiditas kilat.
- **Pemeriksaan pemberi pinjaman dan deposan:** Identifikasi urutan penyerapan kredit macet yang tepat. Pastikan cadangan mana yang menanggung pasar tertentu, siapa yang dapat mengubah parameter, apakah cadangan itu likuid dan dapat diakses, serta apa yang terjadi setelah cadangan habis.

Tidak ada perlindungan yang menjamin eksekusi. Insentif dapat terlalu kecil di pasar tenang, tetapi terlalu murah hati atau dapat dieksploitasi setelah parameter berubah. Jeda dan circuit breaker dapat membatasi kerusakan akibat oracle atau kontrak yang rusak, tetapi keduanya juga dapat sengaja menghentikan likuidasi dan membiarkan risiko harga menumpuk. Pertanyaan yang relevan adalah bagaimana seluruh sistem berperilaku ketika tekanan harga, likuiditas, jaringan, dan infrastruktur terjadi secara bersamaan.

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

## Kesalahpahaman umum

### Mitos 1: Setiap protokol menunjuk satu keeper tepercaya

Banyak protokol mengizinkan alamat mana pun melakukan likuidasi. Bot bernama mungkin hanya salah satu peserta atau penyedia antarmuka. Gangguannya hanya penting jika tidak ada pengganti yang dapat mengeksekusi.

### Mitos 2: Posisi yang memenuhi syarat sudah dilikuidasi

Kelayakan adalah status kontrak; likuidasi merupakan transaksi atau lelang yang terpisah. Eksposur pasar tetap ada sampai eksekusi tersebut berhasil dan utang serta agunan yang dihasilkan telah dicatat.

### Mitos 3: Menaikkan gas selalu memperbaiki kegagalan

Biaya transaksi yang lebih tinggi dapat meningkatkan prioritas penyertaan, tetapi tidak dapat memperbaiki oracle yang usang, pasar yang dijeda, modal yang tidak cukup, allowance yang tidak tersedia, status akun yang berubah, penjualan agunan yang merugi, atau pembatalan oleh kontrak.

### Mitos 4: Kredit macet berarti pemberi pinjaman langsung kehilangan jumlah yang sama

Kredit macet pertama-tama masuk ke urutan kerugian yang ditetapkan protokol. Cadangan atau penyangga lain dapat menyerapnya. Pemberi pinjaman atau pemegang token tata kelola hanya terdampak sesuai aturan yang berlaku dan sumber daya yang tersedia, dan waktunya dapat berbeda dari saat defisit muncul.

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

## Topik terkait

- [Likuidasi kripto](/id/crypto/liquidation/)
- [Bonus likuidasi](/id/crypto/liquidation-bonus/)
- [Faktor penutupan likuidasi](/id/crypto/liquidation-close-factor/)
- [Keusangan harga oracle](/id/crypto/oracle-price-staleness/)
- [Dana asuransi kripto](/id/crypto/insurance-fund/)

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

## Sumber

- [Health Factor & Liquidations](https://aave.com/help/borrowing/liquidations) - Aave (diakses: 2026-08-21)
- [Compound III Docs: Liquidation](https://docs.compound.finance/liquidation/) - Compound (diakses: 2026-08-21)
- [Liquidation 2.0 Module](https://docs.makerdao.com/smart-contract-modules/dog-and-clipper-detailed-documentation) - Maker Protocol Technical Docs (diakses: 2026-08-21)

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