#termmax @TermMax Kicauan kemarin mengingatkanku pada satu pengalaman sebelumnya saat aku menjalankan tugas sebagai promotor. Waktu itu ada dua proyek sekaligus. Aku menulis kicauan, selesai mengirim, baru sadar bahwa kicauannya nyasar—kicauan proyek A terkirim ke proyek B. Nggak ada cara lain, aku harus menulis ulang kicauan proyek A dan mengirim lagi. Kenapa aku membahas ini? Karena kicauan yang aku kirim kemarin, banyak orang membalasnya dengan topik proyek A seolah-olah itu kicauan proyek B. Akhirnya aku menatap cukup lama, dan baru sadar: ternyata tidak salah kirim.
Dalam dua hari ini aku sedang mempelajari mekanisme penyelesaian (liquidation) dalam perjanjian pinjam-meminjam, dan menemukan satu poin yang mudah terabaikan: banyak pengguna hanya melihat tinggi-rendahnya suku bunga ketika memilih protokol, dan jarang memikirkan apakah langkah penyelesaian ini benar-benar dapat diandalkan.
Aku sudah pernah melihat kondisi seperti ini lebih dari sekali—ketika pasar berfluktuasi hebat, likuiditas dari aset jaminan tertentu tiba-tiba mengering. Proses penyelesaian jadi tidak bisa berjalan, akhirnya pemberi pinjaman tidak bisa menarik kembali pokoknya, dan platform pun tidak punya banyak pilihan selain menunggu atau menanggung kerugian. Kejadian seperti ini biasanya bukan masalah desain suku bunga, melainkan cacat desain pada bagian mekanisme penyelesaian. Tapi mayoritas orang saat meneliti protokol, umumnya tidak melihat bagian ini.
Dalam beberapa hari terakhir, aku menelusuri pemikiran tersebut lalu mempelajari TermMax, dan aku mendapati bahwa pendekatan desainnya pada bagian ini agak berbeda dari kebanyakan protokol pinjam-meminjam.
Pertama, ada isolasi pasar: setiap pasar pinjam-meminjam bersifat independen. Jika ada masalah pada suatu aset jaminan, risikonya tidak menular ke pasar lain. Desain ini saat ini memang bukan hal yang sepenuhnya baru, tapi tetap merupakan garis batas yang diperlukan. Yang benar-benar membuatku lebih memperhatikan adalah bagian penyelesaian: jika di pasar tidak ada likuiditas yang cukup untuk menyelesaikan proses penyelesaian secara normal, pemberi pinjaman akan langsung menerima aset jaminan fisik sesuai proporsi, bukan memaksa protokol melakukan matching yang tidak sehat hingga menimbulkan piutang macet, atau membiarkan penyelesaian gagal sehingga pemberi pinjaman harus menanggung semuanya sendiri.
Pada dasarnya, desain ini berarti 'kegagalan penyelesaian'—sebagai skenario terburuk—dipikirkan lebih dulu, alih-alih berasumsi bahwa penyelesaian akan selalu berjalan lancar.
Tentu saja, ini tidak berarti tidak ada risiko. Ketergantungan pada oracle, kedalaman likuiditas aset jaminan itu sendiri—masalah-masalah klasik ini tetap ada. Penyerahan aset secara fisik hanya menurunkan kerugian ke batas yang relatif lebih terkontrol, bukan menghapus risiko. Selain itu, ukuran TVL protokol saat ini masih belum besar; sebaik apa pun desain mekanismenya, pada akhirnya tetap harus dibuktikan oleh kebutuhan pinjam-meminjam yang nyata dan kedalaman transaksi.
Menurut penilaianku sendiri, desain seperti ini mungkin dalam jangka pendek tidak se-atraktif produk dengan leverage tinggi untuk menarik perhatian.
Dalam dua hari ini aku sedang mempelajari mekanisme penyelesaian (liquidation) dalam perjanjian pinjam-meminjam, dan menemukan satu poin yang mudah terabaikan: banyak pengguna hanya melihat tinggi-rendahnya suku bunga ketika memilih protokol, dan jarang memikirkan apakah langkah penyelesaian ini benar-benar dapat diandalkan.
Aku sudah pernah melihat kondisi seperti ini lebih dari sekali—ketika pasar berfluktuasi hebat, likuiditas dari aset jaminan tertentu tiba-tiba mengering. Proses penyelesaian jadi tidak bisa berjalan, akhirnya pemberi pinjaman tidak bisa menarik kembali pokoknya, dan platform pun tidak punya banyak pilihan selain menunggu atau menanggung kerugian. Kejadian seperti ini biasanya bukan masalah desain suku bunga, melainkan cacat desain pada bagian mekanisme penyelesaian. Tapi mayoritas orang saat meneliti protokol, umumnya tidak melihat bagian ini.
Dalam beberapa hari terakhir, aku menelusuri pemikiran tersebut lalu mempelajari TermMax, dan aku mendapati bahwa pendekatan desainnya pada bagian ini agak berbeda dari kebanyakan protokol pinjam-meminjam.
Pertama, ada isolasi pasar: setiap pasar pinjam-meminjam bersifat independen. Jika ada masalah pada suatu aset jaminan, risikonya tidak menular ke pasar lain. Desain ini saat ini memang bukan hal yang sepenuhnya baru, tapi tetap merupakan garis batas yang diperlukan. Yang benar-benar membuatku lebih memperhatikan adalah bagian penyelesaian: jika di pasar tidak ada likuiditas yang cukup untuk menyelesaikan proses penyelesaian secara normal, pemberi pinjaman akan langsung menerima aset jaminan fisik sesuai proporsi, bukan memaksa protokol melakukan matching yang tidak sehat hingga menimbulkan piutang macet, atau membiarkan penyelesaian gagal sehingga pemberi pinjaman harus menanggung semuanya sendiri.
Pada dasarnya, desain ini berarti 'kegagalan penyelesaian'—sebagai skenario terburuk—dipikirkan lebih dulu, alih-alih berasumsi bahwa penyelesaian akan selalu berjalan lancar.
Tentu saja, ini tidak berarti tidak ada risiko. Ketergantungan pada oracle, kedalaman likuiditas aset jaminan itu sendiri—masalah-masalah klasik ini tetap ada. Penyerahan aset secara fisik hanya menurunkan kerugian ke batas yang relatif lebih terkontrol, bukan menghapus risiko. Selain itu, ukuran TVL protokol saat ini masih belum besar; sebaik apa pun desain mekanismenya, pada akhirnya tetap harus dibuktikan oleh kebutuhan pinjam-meminjam yang nyata dan kedalaman transaksi.
Menurut penilaianku sendiri, desain seperti ini mungkin dalam jangka pendek tidak se-atraktif produk dengan leverage tinggi untuk menarik perhatian.