#termmax @TermMax ...Saya sedang meninjau perbaikan V2 terbaru dari TermMax, dan satu hal terus mengganggu saya.
Dulu saya mengira sebagian besar bug DeFi bermuara pada matematika yang buruk.
Kali ini, matematikanya sebagian besar baik-baik saja.
Masalah besarnya adalah memakai representasi realitas yang salah.
Ambil contoh apr().
Logika lama melihat saldo XT mentah dari order.
Kedengarannya masuk akal, kan?
Tapi V2 tidak memakai saldo XT mentah sebagai keadaan penetapan harga.
Ia memakai virtualXtReserve.
Perbedaan itu penting...
Bayangkan sebuah toko di mana label harga dikendalikan oleh buku besar internal toko, tetapi Anda mulai menghitung harga dari berapa pun uang tunai yang tiba-tiba dijatuhkan seseorang secara acak di meja kas.
Uangnya berubah.
Model harganya tidak.
Itu kira-kira yang bisa dilakukan oleh transfer XT langsung terhadap perhitungan APR lama.
Saldonya bisa bergerak tanpa kurvanya ikut bergerak, namun apr() bisa memperlakukan saldo itu sebagai keadaan penetapan harga yang baru.
Perbaikannya membuat model akuntansi sesuai dengan model ekonomi.
Dan menurut saya ini pelajaran yang lebih menarik.
Dalam smart contract keuangan, pertanyaan yang berbahaya tidak selalu:
“Apakah formulanya benar?”
Kadang-kadang itu:
“Apakah kita memberi formulanya keadaan yang tepat?”
Tema yang sama muncul pada perbaikan liquidation.
Oracle utang dengan 18 desimal bisa membuat konversi desimal membuat perbandingan agunan runtuh, sehingga posisi yang seharusnya memungkinkan liquidation 50% menjadi liquidation penuh.
Sekali lagi, bukan masalah rumus yang rumit.
Itu masalah satuan.
Karena itu saya mulai lebih memperhatikan perubahan-perubahan yang terlihat membosankan ini.
Satu baris perbaikan akuntansi bisa lebih penting daripada fitur baru yang mencolok, karena ia menentukan apakah protokol menginterpretasikan pasar dengan benar.
Untuk TermMax, saya akan memperhatikan satu hal dari sini:
bukan hanya seberapa banyak likuiditas yang dimiliki sistem, tetapi apakah penetapan harga, valuasi agunan, dan logika liquidation semuanya membaca realitas ekonomi yang sama.....
Di situlah “kodenya bekerja” mulai berubah menjadi “infrastruktur keuangannya bekerja.”
Anda lebih suka mengaudit formulanya dulu, keadaan akuntansinya dulu, atau asumsi oracle/unitnya dulu?....
Dulu saya mengira sebagian besar bug DeFi bermuara pada matematika yang buruk.
Kali ini, matematikanya sebagian besar baik-baik saja.
Masalah besarnya adalah memakai representasi realitas yang salah.
Ambil contoh apr().
Logika lama melihat saldo XT mentah dari order.
Kedengarannya masuk akal, kan?
Tapi V2 tidak memakai saldo XT mentah sebagai keadaan penetapan harga.
Ia memakai virtualXtReserve.
Perbedaan itu penting...
Bayangkan sebuah toko di mana label harga dikendalikan oleh buku besar internal toko, tetapi Anda mulai menghitung harga dari berapa pun uang tunai yang tiba-tiba dijatuhkan seseorang secara acak di meja kas.
Uangnya berubah.
Model harganya tidak.
Itu kira-kira yang bisa dilakukan oleh transfer XT langsung terhadap perhitungan APR lama.
Saldonya bisa bergerak tanpa kurvanya ikut bergerak, namun apr() bisa memperlakukan saldo itu sebagai keadaan penetapan harga yang baru.
Perbaikannya membuat model akuntansi sesuai dengan model ekonomi.
Dan menurut saya ini pelajaran yang lebih menarik.
Dalam smart contract keuangan, pertanyaan yang berbahaya tidak selalu:
“Apakah formulanya benar?”
Kadang-kadang itu:
“Apakah kita memberi formulanya keadaan yang tepat?”
Tema yang sama muncul pada perbaikan liquidation.
Oracle utang dengan 18 desimal bisa membuat konversi desimal membuat perbandingan agunan runtuh, sehingga posisi yang seharusnya memungkinkan liquidation 50% menjadi liquidation penuh.
Sekali lagi, bukan masalah rumus yang rumit.
Itu masalah satuan.
Karena itu saya mulai lebih memperhatikan perubahan-perubahan yang terlihat membosankan ini.
Satu baris perbaikan akuntansi bisa lebih penting daripada fitur baru yang mencolok, karena ia menentukan apakah protokol menginterpretasikan pasar dengan benar.
Untuk TermMax, saya akan memperhatikan satu hal dari sini:
bukan hanya seberapa banyak likuiditas yang dimiliki sistem, tetapi apakah penetapan harga, valuasi agunan, dan logika liquidation semuanya membaca realitas ekonomi yang sama.....
Di situlah “kodenya bekerja” mulai berubah menjadi “infrastruktur keuangannya bekerja.”
Anda lebih suka mengaudit formulanya dulu, keadaan akuntansinya dulu, atau asumsi oracle/unitnya dulu?....
