DeFi pinjaman bentuk akhir: Bagaimana mekanisme pinjaman PFund menjadikan “leverage” sebagai alat yang rasional

“Leverage” di pasar kripto selalu menjadi alat keuangan dengan risiko tinggi.

Sambil memberikan efek penggandaan dana, juga sering memicu risiko sistemik. Pada Mei 2022, badai likuidasi berantai akibat pelepasan UST dari patokan menyebabkan, protokol pinjaman utama (Aave, Compound, MakerDAO, dll) memicu penutupan paksa puluhan miliar dolar dalam 72 jam, jaminan pengguna dilikuidasi dengan harga rendah oleh sistem, menyebabkan posisi besar menjadi nol. Likuidasi ekstrem ini adalah konsekuensi sistemik dari semua protokol pinjaman yang menggunakan mekanisme likuidasi—ketika pasar bergejolak hebat, mekanisme likuidasi memperburuk kepanikan pasar, memicu “penurunan harga → likuidasi terpicu → penjualan jaminan → harga semakin jatuh” dalam spiral kematian.

PFund dari arsitektur protokol, memutus mekanisme terjadinya spiral likuidasi ini.

Logika dasar dan jalur implementasi tanpa likuidasi
Alasan utama protokol pinjaman DeFi tradisional bergantung pada mekanisme likuidasi adalah risiko ketidakcocokan harga antara jaminan dan pinjaman. Ketika harga pasar aset jaminan (seperti ETH) jatuh tajam, nilainya tidak mampu menutupi pinjaman (seperti USDC), protokol menghadapi kerugian buruk, harus melakukan likuidasi paksa untuk membatasi kerugian.

Desain pinjaman PFund secara fundamental menghindari risiko ini, berbasiskan dua aturan inti:

● Pertama: Jumlah pinjaman dan bagian dana PFund peminjam diikat ketat.
○ Jumlah pinjaman maksimum pengguna (quoteBorrowMax) dihitung dengan rumus berikut:
○ B0 = tokenStaked × tabungan / (saldoLunak + tokenStaked)
○ Jumlah pinjaman = B0 - pinjaman yang sudah ada (borrowed)
○ Esensi model ini adalah, pengguna menarik dana yang setara dengan bagian jaminan PFund yang dijamin. Pengguna menggunakan bagian jaminan sebagai agunan, dan nilai bagian ini terisolasi dari fluktuasi harga pasar AMM, hanya meningkat secara satu arah seiring akumulasi keuntungan protokol.
● Kedua: Batas jumlah pinjaman dibatasi oleh dua batas keras—batas kontribusi pribadi dan batas likuiditas yang tersedia di pool, mana yang lebih kecil.
○ Laporan audit mengonfirmasi: totalGrossBorrowed ≤ savingsQuote (jumlah pinjaman total tidak pernah melebihi likuiditas yang tersedia di dana), dan execBorrow sebelum eksekusi akan memeriksa secara paksa bahwa grossPreview > savingsQuote, memastikan setiap pinjaman tunggal tidak menyebabkan kekurangan likuiditas di pool.
Dalam arsitektur ini, fluktuasi harga token pasar AMM yang ekstrem tidak mempengaruhi keamanan sistem pinjaman, karena yang diikat adalah “bagian absolut dari pool dana”, bukan “harga pasar token”. Secara logika, mekanisme likuidasi tidak diperlukan lagi.

Verifikasi keamanan pinjaman di tingkat kode
Laporan audit memverifikasi keamanan pinjaman PFund berdasarkan 5 invariabel inti:

● I-1: Jumlah pinjaman pribadi tidak akan melebihi kontribusi jaminan PFund sendiri
○ Rumus menunjukkan, batas jumlah pinjaman pengguna secara ketat dihitung berdasarkan rasio antara savings (bagian jaminan) dan posisi yang sudah ada, sehingga tidak mungkin pinjaman mencuri bagian jaminan orang lain.
● I-2: Jumlah pinjaman total tidak pernah melebihi savingsQuote
○ savingsQuote mewakili likuiditas yang tersedia di dana PFund. Saat pinjaman terjadi, savingsQuote dikurangi secara sinkron, dan saat pelunasan dikembalikan secara setara. Likuiditas yang tersedia di pool menjadi batas keras untuk skala pinjaman.
● I-3: Pinjaman tidak mempengaruhi bagian jaminan dan indeks keuntungan PFund orang lain
○ Operasi pinjaman hanya mengubah savingsQuote (pencatatan likuiditas), tanpa menyentuh totalSavingsShares (jumlah bagian pokok) dan globalNVP (indeks keuntungan global), sehingga hak posisi lain tetap terlindungi.
● I-4: Simpanan dan nvp0 pengguna tetap tidak berubah selama proses pinjaman
○ Fungsi mFinalizeBorrow tidak mengubah savings atau nvp0. Hanya saat pengguna secara aktif menjual bagian, bagian jaminan dikurangi, dan pinjaman tidak menyebabkan kerugian.
● I-5: Setelah pelunasan, jumlah jaminan yang dilepaskan ≤ jumlah jaminan awal, dan sisa jaminan cukup menutup sisa utang
○ Algoritma _repayUnstakeTokens memastikan, baik pelunasan parsial maupun penuh, jumlah jaminan yang dilepaskan berada dalam batas aman, dan sisa jaminan menutupi eksposur utang.

Batas keamanan pinjaman berulang
Mengenai kekhawatiran bahwa pinjaman berulang dapat memperbesar leverage tanpa batas dan membebani protokol, struktur matematis PFund memberikan mekanisme pertahanan yang pasti.

Setelah pinjaman pertama, data borrowed pengguna meningkat, dan batas pinjaman berikutnya direset menjadi B0 - borrowed_prev, yang secara ketat menurun. Secara bersamaan, likuiditas global savingsQuote di pool juga berkurang karena pinjaman. Setiap siklus mengurangi leverage pribadi dan ruang leverage sistem secara internal. Sistem pinjaman memiliki sifat pembatasan diri yang melekat, tanpa perlu peringatan dari mekanisme pengelolaan eksternal. Karena batas leverage ditentukan oleh loop matematis internal protokol, risiko manipulasi oleh oracle eksternal dihindari, dan keandalan arsitektur tanpa likuidasi ini terjamin.

Aplikasi strategi pinjaman
Sebagai contoh alokasi aset tipikal: pengguna membeli suatu proyek dengan 2000 U, membentuk posisi token AMM sebesar 1000 U, dan menganggap 1000 U sebagai bagian dari dana PFund. Ketika harga posisi AMM naik 100%, pengguna dapat melakukan strategi berikut:
● Menyimpan token untuk mengaktifkan fungsi pinjaman.
● Meminjam hingga batas setara bagian jaminan PFund.
● Menggunakan dana yang dipinjam untuk membeli kembali proyek, memperbesar bagian dana PFund, dan meningkatkan hak dividen di masa depan.
● Seluruh proses tanpa bunga, tanpa risiko likuidasi, hanya membayar biaya pinjaman satu kali sebesar 3%.
Leverage biaya rendah ini menghindari risiko memperbesar spekulasi harga, dan justru memperbesar dasar memperoleh keuntungan stabil (hak dividen dana PFund). Mekanisme pinjaman menjadi alat dasar yang memberdayakan pengelolaan aset secara rasional.