Saat ini masih ada sekitar 136 ribu dolar AS di kontrak eksekusi buyback $PONS
Aku sedang berpikir, dalam desain protokol yang benar-benar menjalankan buyback ini,
apakah menambahkan mekanisme buyback yang lebih fleksibel akan lebih baik daripada buyback otomatis yang mekanis @MEADGod
Misalnya, saat membaca tren historis, jika terdeteksi sedang berada dalam tren turun, buyback dilakukan dengan proporsi yang lebih besar.
Sebaliknya, jika terdeteksi sedang berada dalam tren naik, proporsinya dikurangi.
Sebagai contoh, saat ini sekitar 0.46e PONS dibeli kembali setiap jam. Ini adalah angka acuan per jam untuk siklus saat ini.
（1）Jika tren yang terbentuk dari 20 candle satu jam terakhir terdeteksi sebagai tren turun, jumlah buyback menjadi 0.6e/jam (1.3 kali angka acuan).
（2）Saat berada dalam tren naik, jumlah buyback disesuaikan menjadi 0.32e/jam (0.7 kali angka acuan).
（3）Jika pasar sedang netral, jumlah buyback mengikuti angka acuan.
Aku meminta AI membuat diagram sederhana agar lebih mudah dipahami semua orang.
Inti dari sini bukan agar protokol mengalokasikan dana melebihi batas, melainkan mengubah alokasi anggaran yang sama pada rentang harga yang berbeda.
Dana yang tidak digunakan saat harga naik masuk ke pool buyback lain, lalu digunakan untuk menambah pembelian dari pool itu saat harga turun. Dengan begitu, buyback tetap berlangsung secara berkelanjutan, sekaligus memungkinkan lebih banyak PONS dibeli kembali dengan dana yang sama dan dibakar saat harganya lebih rendah.
Membaca 20 candle satu jam terakhir hanya sebuah contoh. Mekanisme ini sendiri mudah diterapkan; aku bisa membuatnya dengan Codex (karena aku pernah menerapkan deteksi serupa saat membuat BOT pemantau pasar).
Cara yang lebih masuk akal adalah menganalisis pergerakan $PONS selama seminggu terakhir sebelum setiap siklus dijalankan.
Desain ini juga punya satu masalah: jika tren turun terus berlangsung selama periode tertentu, dana akan lebih cepat habis dalam kondisi pasar seperti ini.
Jadi, sebaiknya mekanisme fleksibel seperti ini diterapkan saat tren naik, dengan tetap menyisihkan dana sebesar 30% dari pool.
Kalaupun ingin diterapkan pada tahap sekarang, itu juga bisa. Berikan syarat pembatas pada kontrak: sebelum menjalankan siklus, periksa saldo di pool dana cadangan. Jika saldonya ＜ total dana siklus × 0.3, maka secara default buyback pada siklus saat ini dilakukan dengan angka acuan.
➠ Artinya, misalkan dana yang tersedia untuk buyback dalam satu siklus ini adalah 10E. Jika saldo pool dana cadangan dari siklus sebelumnya kurang dari 3E, maka secara default total dana buyback pada siklus ini adalah 10E, bukan 13E
Aku sedang berpikir, dalam desain protokol yang benar-benar menjalankan buyback ini,
apakah menambahkan mekanisme buyback yang lebih fleksibel akan lebih baik daripada buyback otomatis yang mekanis @MEADGod
Misalnya, saat membaca tren historis, jika terdeteksi sedang berada dalam tren turun, buyback dilakukan dengan proporsi yang lebih besar.
Sebaliknya, jika terdeteksi sedang berada dalam tren naik, proporsinya dikurangi.
Sebagai contoh, saat ini sekitar 0.46e PONS dibeli kembali setiap jam. Ini adalah angka acuan per jam untuk siklus saat ini.
（1）Jika tren yang terbentuk dari 20 candle satu jam terakhir terdeteksi sebagai tren turun, jumlah buyback menjadi 0.6e/jam (1.3 kali angka acuan).
（2）Saat berada dalam tren naik, jumlah buyback disesuaikan menjadi 0.32e/jam (0.7 kali angka acuan).
（3）Jika pasar sedang netral, jumlah buyback mengikuti angka acuan.
Aku meminta AI membuat diagram sederhana agar lebih mudah dipahami semua orang.
Inti dari sini bukan agar protokol mengalokasikan dana melebihi batas, melainkan mengubah alokasi anggaran yang sama pada rentang harga yang berbeda.
Dana yang tidak digunakan saat harga naik masuk ke pool buyback lain, lalu digunakan untuk menambah pembelian dari pool itu saat harga turun. Dengan begitu, buyback tetap berlangsung secara berkelanjutan, sekaligus memungkinkan lebih banyak PONS dibeli kembali dengan dana yang sama dan dibakar saat harganya lebih rendah.
Membaca 20 candle satu jam terakhir hanya sebuah contoh. Mekanisme ini sendiri mudah diterapkan; aku bisa membuatnya dengan Codex (karena aku pernah menerapkan deteksi serupa saat membuat BOT pemantau pasar).
Cara yang lebih masuk akal adalah menganalisis pergerakan $PONS selama seminggu terakhir sebelum setiap siklus dijalankan.
Desain ini juga punya satu masalah: jika tren turun terus berlangsung selama periode tertentu, dana akan lebih cepat habis dalam kondisi pasar seperti ini.
Jadi, sebaiknya mekanisme fleksibel seperti ini diterapkan saat tren naik, dengan tetap menyisihkan dana sebesar 30% dari pool.
Kalaupun ingin diterapkan pada tahap sekarang, itu juga bisa. Berikan syarat pembatas pada kontrak: sebelum menjalankan siklus, periksa saldo di pool dana cadangan. Jika saldonya ＜ total dana siklus × 0.3, maka secara default buyback pada siklus saat ini dilakukan dengan angka acuan.
➠ Artinya, misalkan dana yang tersedia untuk buyback dalam satu siklus ini adalah 10E. Jika saldo pool dana cadangan dari siklus sebelumnya kurang dari 3E, maka secara default total dana buyback pada siklus ini adalah 10E, bukan 13E