Ini mungkin kontroversial, tetapi transaksi Anda harus dapat melawan validator sandwiching berbahaya. Saya membangun program sederhana untuk melakukan hal itu. Anda tidak dapat mengetahui pada runtime apakah slippage adalah pergerakan pasar alami atau serangan sandwich. Tetapi jika swap Anda mendarat di validator berbahaya yang dikenal, Anda praktis dijamin akan terjepit hingga slippage maksimum Anda. Ini memungkinkan Anda melawan. ✅ Pada validator tepercaya? Transaksi Anda dilanjutkan dengan slippage yang Anda inginkan (x%). ❌ Pada validator berbahaya? Slippage transaksi Anda disesuaikan (0%, sebagian kecil dari x%, apa pun yang Anda inginkan) Alih-alih hanya mengembalikan, transaksi Anda dapat berhasil dengan batasan yang lebih ketat saat berjalan di hutan yang lebih gelap. Saat Anda membuat dan menandatangani transaksi, Anda tidak tahu persis validator apa yang akan mendarat sehingga logika bahwa mengubah perilaku harus onchain. Jadi bagaimana cara kerjanya? Program Solana tidak dapat mengakses validator saat ini, tetapi dapat mengakses slot saat ini. Program ini mengambil representasi yang ringkas (14 byte tetapi dapat dikurangi lebih lanjut) untuk memungkinkan program memeriksa apakah pemimpin slot ditandai sebagai berbahaya. Beberapa cara untuk menggunakannya: (1) Anda dapat memasukkannya secara langsung sebagai instruksi sederhana (<260 CU, yang sebagian besar mengakses sistem Jam). Mengembalikan seluruh tx saat mendarat di validator berbahaya (2) Anda dapat menggunakannya untuk membungkus router Jupiter v6. Ini akan memanggil program Jupiter dan secara dinamis mengganti nilai 'slippage' tetapi hanya ketika berjalan pada validator berbahaya (3) Hubungi langsung melalui CPI dari program Anda sendiri Daftar validator jahat dan slot mereka yang akan datang dapat bersumber dari Sandwiched[dot]me API kami yang akan datang atau dari data Anda sendiri. Perlu diingat bahwa prototipe ini bersifat eksperimental. Itu tidak disebarkan secara onchain. Ingin mendapatkan umpan balik Anda dan PR dipersilakan