1/ Setiap arsitektur melibatkan pengorbanan. Desain yang baik memungkinkan Anda untuk merancang sistem di mana, untuk setiap unit risiko yang Anda ambil, Anda mendapatkan hadiah paling banyak, dan untuk setiap unit imbalan yang Anda ambil, Anda menanggung risiko paling sedikit. Dari PoV risiko likuiditas, model Morpho tidak optimal.

3/ Risiko penukaran dimanifestasikan ketika pengguna tidak dapat menarik jaminan. Morpho memasarkan dirinya sebagai alternatif pinjaman "terisolasi", di mana kurator mengelola brankas dan pengguna memilih di antara profil risiko yang berbeda. Tapi "isolasi" menyesatkan, seperti yang akan kita lihat; risiko likuiditas dibagikan.

5/ Ini penting untuk dipahami karena, sebagai pengguna, kemampuan Anda untuk menarik modal Anda bergantung padanya. Mari kita lihat contohnya: Mari kita bayangkan kurator yang sangat bijaksana dan bertanggung jawab di Morpho, Kurator A.

6/ Demikian pula, mari kita bayangkan kurator yang agresif, Kurator B. Bahkan jika Anda menyetor ke brankas "berisiko rendah", jika dialokasikan ke pasar yang juga digunakan kurator berisiko tinggi, kemampuan Anda untuk menebus bergantung pada kumpulan bersama yang sama di pasar itu, bukan hanya pada brankas Anda.

7/ Ketika pasar tumpang tindih yang berisiko depeg, penebusan melonjak, dan pemanfaatan dapat mencapai 100%. Akibatnya, penarikan menjadi perlombaan siapa cepat dia dapat dari kumpulan bersama itu, memungkinkan kurator yang bergerak cepat untuk mengonsumsi likuiditas dan membuat orang lain untuk sementara tidak dapat menghormati penarikan.

8/ Begitulah cara pengguna konservatif dapat bangun dengan penebusan yang dibekukan atau tertunda, bukan karena brankas mereka mengambil risiko kredit aset itu, tetapi karena yang lain menguras likuiditas pasar bersama.

9/ Ini adalah masalah inti: risiko likuiditas disosialisasikan, bukan terisolasi. Dan karena Morpho mengizinkan daftar aset tanpa izin, token baru, tanpa jaminan, atau eksperimental apa pun berpotensi mencemari kumpulan likuiditas bersama. Tetapi apakah ada tuas risiko lain?

10/ Setelah penebusan di Morpho dibatalkan, toolkit manajer risiko kosong. Biasanya, Anda ingin: - Menaikkan suku bunga untuk memberi insentif kepada pembayaran dan memulihkan likuiditas - Perbarui oracle untuk mencerminkan harga pasar riil selama peristiwa stres - Mengubah parameter risiko untuk meminimalkan paparan agunan

11/ Tetapi di Morpho, model suku bunga, konfigurasi risiko, dan oracle tidak dapat diubah. Mereka tidak dapat diubah setelah penerapan. Jadi ketika kondisi berubah, seperti yang terus-menerus terjadi di pasar keuangan, Anda tidak dapat beradaptasi: Anda hanya bisa menarik.

12/ Aave mengatasi ini dengan @chaoslabs Risk Oracles Berpotensi menyelami lebih dalam topik ini di utas yang berbeda.

13/ Di Aave: aset diizinkan, pencatatan diatur melalui tinjauan DAO yang ketat, dan parameter risiko dapat disesuaikan secara dinamis sebagai respons terhadap tekanan pasar.

14/ Begitulah cara sistem tetap pelarut dan cair melalui setiap guncangan DeFi besar. Selama setahun terakhir, Aave Core mempertahankan penyangga yang dalam, rata-rata sekitar $750 juta USDC dan $1,0 miliar USDT, sambil menangani arus keluar harian rata-rata $300-400 juta. Bahkan ketika arus keluar mencapai $2 miliar per hari, likuiditas rebound ke level tipikal dalam beberapa jam.

15/ Di Morpho, yang terjadi adalah sebaliknya: likuiditas bersama, daftar tanpa izin, dan parameter yang tidak dapat diubah membuat risiko penebusan secara inheren sulit untuk dijamin jaminan. Dan itulah poin mendasarnya: Ketika risiko penebusan tidak dapat diantisipasi, itu tidak dapat dihargai dengan andal. Jika harga tidak dapat dihargai secara akurat, itu tidak dapat dikelola secara bertanggung jawab.

16/ Ini tidak dimaksudkan untuk menjadi postingan malapetaka Morfo. Morpho mendorong perbatasan dalam banyak hal, dan timnya hebat. Tetapi kita harus menyadari bahwa ini adalah pembiayaan onchain paling sederhana yang pernah ada. Kita masih membutuhkan arsitektur yang lebih baik, infra risiko, oracle, dll.

17/ Di @chaoslabs, kami mencoba membuat versi berikutnya lebih cerdas. Beberapa masalah dapat diperbaiki dengan mengulangi arsitektur inti. Yang lain dapat diperbaiki dengan infra dan oracle risiko real-time yang dinamis. Keduanya diperlukan untuk berada di perbatasan efisien DeFi.