---
title: "Bonus likuidasi"
description: "Bonus likuidasi adalah nilai agunan tambahan yang membuat likuidasi pinjaman DeFi kurang agunan layak secara ekonomi. Pelajari perhitungan, pembagian, dan dampak biaya eksekusi."
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.
# Bonus likuidasi
> Hanya untuk tujuan edukasi; bukan nasihat investasi. Investasi dapat mengakibatkan kerugian.
## Jawaban langsung
Bonus likuidasi adalah nilai agunan tambahan yang disediakan protokol pinjaman ketika seseorang membayar utang peminjam yang memenuhi syarat likuidasi. Bonus ini mengompensasi likuidator atas gas, slippage, pergerakan harga, transaksi gagal, dan persaingan. Bagi peminjam, jumlah yang sama merupakan penalti karena nilai agunan yang keluar melebihi nilai utang yang dibayar.
Tidak ada tarif universal. Nilainya dapat berbeda menurut protokol, deployment, aset agunan, mode pasar, dan konfigurasi tata kelola. Aave menjelaskan bahwa posisi dapat dilikuidasi ketika health factor turun di bawah `1`; likuidator membayar utang dan menerima agunan senilai utang ditambah bonus. Transaksi yang permissionless tetap tidak menjamin keuntungan.
Jangan samakan bonus yang ditampilkan dengan laba bersih. Protokol dapat menahan sebagian bonus, sedangkan likuidator membayar biaya eksekusi dan pendanaan. Beberapa sistem juga memakai arsitektur berbeda. Compound III, misalnya, lebih dahulu menggunakan cadangan protokol untuk menyerap akun yang insolven, kemudian menawarkan agunan milik protokol dengan harga diskon. Pemanggil `absorb` tidak langsung menerima agunan peminjam dalam transaksi yang sama.
## Cara kerja
Dalam model penyitaan langsung yang disederhanakan, `D` adalah nilai utang yang dibayar, `b` adalah tarif bonus, dan `C` adalah nilai agunan yang diambil dari peminjam menurut harga oracle protokol:
`C = D * (1 + b)`
Nilai bonus kotor adalah `D * b`. Jika `f` merupakan porsi bonus untuk protokol, pembagian sederhananya adalah:
`liquidator collateral value = D + D * b * (1 - f)`
`protocol collateral value = D * b * f`
Rumus ini untuk pembelajaran, bukan kuotasi transaksi. Desimal token, pembulatan, unit oracle, batas close factor, agunan tersedia, dan aturan khusus protokol memengaruhi jumlah aktual. Kode likuidasi Aave V3, misalnya, menghitung agunan dasar dari harga oracle, menerapkan bonus yang dikonfigurasi, lalu dapat memotong biaya protokol yang dikonfigurasi dari bagian bonus untuk kas protokol.
Insentif harus menyeimbangkan dua kerugian. Jika terlalu kecil, pendapatan yang diharapkan mungkin tidak menutup gas, slippage, pergerakan harga yang merugikan, atau tawaran gagal sehingga utang berisiko tetap tidak dilikuidasi. Jika terlalu besar, peminjam kehilangan lebih banyak agunan dan lonjakan harga oracle lebih cepat menghabiskan penyangga solvabilitas. Karena itu, tata kelola biasanya mengatur parameter likuidasi bersama faktor agunan, ambang likuidasi, close factor, dan desain oracle.
Istilah antarprotokol tidak dapat dipertukarkan. Compound v2 menyebut pengalinya insentif likuidasi dan dapat mengarahkan sebagian agunan sitaan ke cadangan. Compound III memisahkan `absorb` dan `buyCollateral`: cadangan lebih dahulu melunasi akun, protokol mengambil agunan, lalu pembeli dapat membeli persediaan itu dengan diskon jika kondisi cadangan mengizinkan. Selalu periksa aturan dan konfigurasi aktif pasar tertentu.
## Contoh perhitungan
Anggap pasar penyitaan langsung mengizinkan pelunasan `1,000` USDC dengan `b = 5%`. Menurut harga oracle, peminjam kehilangan agunan senilai `1,050` USDC. Jika `f = 10%` dari bonus masuk ke protokol, bonus kotor `50` USDC terbagi menjadi `45` USDC untuk likuidator dan `5` USDC untuk protokol.
Likuidator menerima agunan senilai `1,045` USDC setelah membayar `1,000` USDC. Jika gas dan biaya prioritas bernilai `12` USDC, sedangkan penjualan agunan menimbulkan slippage dan biaya `8` USDC, hasil bersih sederhana adalah `25` USDC:
`net result = 45 - 12 - 8 = 25`
Contoh mengasumsikan transaksi berhasil pada harga oracle dan eksekusi yang diperkirakan. Contoh tidak mencakup tawaran gagal, pendanaan, perubahan harga sebelum penjualan, pembatasan transfer, dan pajak. Jadi bonus nominal `5%` tidak menjamin imbal hasil `5%` dan belum tentu sama dengan porsi yang dipertahankan likuidator.
## Risiko
- **Risiko oracle dan kesenjangan harga:** Agunan dihitung pada harga yang diterima protokol, tetapi harga pasar yang dapat direalisasikan bisa berubah sebelum dijual.
- **Risiko eksekusi dan MEV:** Pesaing dapat mengungguli atau mendahului transaksi. Percobaan yang revert tetap menghabiskan gas, sementara aliran pesanan privat dan lelang dapat mengalihkan surplus.
- **Risiko likuiditas:** Bonus bisa lebih kecil daripada slippage jika agunan jarang diperdagangkan, dibatasi, berasal dari bridge, dijeda, atau sulit ditransfer.
- **Risiko parameter:** Tata kelola atau pengelola risiko berwenang dapat mengubah bonus, biaya, ambang, atau close factor. Antarmuka bisa tertinggal dari konfigurasi on-chain.
- **Risiko utang macet:** Bonus mendorong tindakan tetapi tidak menciptakan agunan. Kesenjangan harga, oracle usang, kemacetan, atau agunan tidak cukup dapat menyisakan defisit.
- **Kerugian peminjam:** Likuidasi yang final tidak dapat dibatalkan dan bisa mengambil agunan lebih besar daripada utang yang dibayar. Likuidasi parsial dapat diikuti likuidasi lain.
## Kesalahpahaman umum
### Mitos 1: Bonus adalah imbal hasil gratis buatan protokol
Bonus dibayar dari agunan peminjam. Ini kompensasi atas eksekusi yang berisiko dan kompetitif, bukan bunga yang dibuat tanpa pihak pembayar.
### Mitos 2: Bonus `5%` menjamin laba `5%`
Biaya protokol, gas, prioritas, slippage, lindung nilai, pendanaan, kegagalan, dan perubahan harga mengurangi hasil. Laba harus memakai nilai jual agunan yang dapat direalisasikan, bukan hanya nilai oracle.
### Mitos 3: Bonus lebih besar selalu membuat pasar lebih aman
Bonus dapat memperbaiki eksekusi, tetapi juga meningkatkan kerugian peminjam dan agunan yang digunakan per unit utang. Keamanan bergantung pada kualitas oracle, likuiditas, ambang, close factor, kapasitas transaksi, dan kalibrasi bersama-sama.
### Mitos 4: Setiap likuidator menerima agunan secara langsung
Itu berlaku pada beberapa protokol, termasuk alur dasar Aave, tetapi tidak semuanya. Compound III dapat menyerap posisi dan menjual agunan secara terpisah; pemicu likuidasi dan pembeli akhir tidak harus berupa alamat yang sama.
## Topik terkait
- [Health factor DeFi](/id/crypto/health-factor-defi/)
- [Likuidasi](/id/crypto/liquidation/)
- [Penyangga likuidasi DeFi](/id/crypto/defi-liquidation-buffer/)
- [Keusangan harga oracle](/id/crypto/oracle-price-staleness/)
- [MEV](/id/crypto/mev/)
## Sumber
- [Health Factor & Liquidations](https://aave.com/help/borrowing/liquidations) - Aave (diakses: 2026-08-21)
- [Aave V3 LiquidationLogic.sol](https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/libraries/logic/LiquidationLogic.sol) - Aave (diakses: 2026-08-21)
- [Compound v2 Docs: Comptroller](https://docs.compound.finance/v2/comptroller/) - Compound Finance (diakses: 2026-08-21)
- [Compound III Docs: Liquidation](https://docs.compound.finance/liquidation/) - Compound Finance (diakses: 2026-08-21)
Source: https://wiki.fcontext.com/id/crypto/liquidation-bonus/index.mdx