Batas Waktu Transaksi STON.fi V2: Penandatanganan Wallet Bukanlah Batas Kedaluwarsa DEX
Swap STON.fi V2 masih bisa kedaluwarsa setelah wallet sudah mengotorisasi pesan pertama. TON memproses operasinya melalui kontrak-kontrak terpisah, dan STON.fi menyimpan tx_deadline di payload DEX sehingga eksekusi yang sudah basi dapat ditolak di kemudian hari.
🔥 Waktu wallet vs waktu DEX
- validUntil di TonConnect hanya mengatur apakah wallet menerima permintaan.
- valid_until pada pesan wallet hanya membatasi penerimaan pesan yang ditandatangani.
- tx_deadline milik payload STON.fi V2 dan melindungi eksekusi selanjutnya.
🚀 Jalur pesan yang membawa kedaluwarsa
1. Wallet pengguna memulai transfer Jetton dari penawaran.
2. Wallet Jetton Router mengirimkan transfer_notification ke Router STON.fi.
3. Router menerima data swap termasuk tx_deadline, alamat refund, dan min_out.
4. Router mengirim pesan swap ke Pool yang sesuai.
5. Pool masih memiliki tx_deadline saat menerapkan kondisi swap.
🧠 Mengapa pemisahan ini ada
Penandatanganan, transfer token, pemrosesan Router, dan eksekusi Pool bukanlah satu kejadian tunggal di TON. Saat terjadi beban, waktu bisa berlalu setelah transaksi pertama sudah mendarat. STON.fi menambahkan deadline V2 opsional setelah jeda-jeda tersebut. min_out dan tx_deadline tetap menyelesaikan masalah yang berbeda.
⚡ Yang perlu diperiksa setelah kedaluwarsa
- Transaksi wallet lebih awal dan transfer token bisa saja sudah ada.
- Ikuti notifikasi Router, lalu timing Pool, kemudian perhatikan output pay_to atau refund.
- Jangan menganggap hash wallet pertama sebagai penyelesaian.
- Jika kuotanya sudah basi, lakukan resimulasikan, bukan hanya menyegarkan deadline.
Kedaluwarsa STON.fi diberlakukan saat Pool mengeksekusi, bukan saat wallet menandatangani.
Apakah Anda akan menetapkan tx_deadline STON.fi yang lebih pendek saat beban tinggi, atau memberi ruang lebih untuk keterlambatan pesan? 👇
Hapus langkah trace yang paling membingungkan Anda saat swap V2 terlihat sudah kedaluwarsa.
Bukan nasihat investasi - teliti sendiri! 🚀
$GRAM @STONfi DEX
Swap STON.fi V2 masih bisa kedaluwarsa setelah wallet sudah mengotorisasi pesan pertama. TON memproses operasinya melalui kontrak-kontrak terpisah, dan STON.fi menyimpan tx_deadline di payload DEX sehingga eksekusi yang sudah basi dapat ditolak di kemudian hari.
🔥 Waktu wallet vs waktu DEX
- validUntil di TonConnect hanya mengatur apakah wallet menerima permintaan.
- valid_until pada pesan wallet hanya membatasi penerimaan pesan yang ditandatangani.
- tx_deadline milik payload STON.fi V2 dan melindungi eksekusi selanjutnya.
🚀 Jalur pesan yang membawa kedaluwarsa
1. Wallet pengguna memulai transfer Jetton dari penawaran.
2. Wallet Jetton Router mengirimkan transfer_notification ke Router STON.fi.
3. Router menerima data swap termasuk tx_deadline, alamat refund, dan min_out.
4. Router mengirim pesan swap ke Pool yang sesuai.
5. Pool masih memiliki tx_deadline saat menerapkan kondisi swap.
🧠 Mengapa pemisahan ini ada
Penandatanganan, transfer token, pemrosesan Router, dan eksekusi Pool bukanlah satu kejadian tunggal di TON. Saat terjadi beban, waktu bisa berlalu setelah transaksi pertama sudah mendarat. STON.fi menambahkan deadline V2 opsional setelah jeda-jeda tersebut. min_out dan tx_deadline tetap menyelesaikan masalah yang berbeda.
⚡ Yang perlu diperiksa setelah kedaluwarsa
- Transaksi wallet lebih awal dan transfer token bisa saja sudah ada.
- Ikuti notifikasi Router, lalu timing Pool, kemudian perhatikan output pay_to atau refund.
- Jangan menganggap hash wallet pertama sebagai penyelesaian.
- Jika kuotanya sudah basi, lakukan resimulasikan, bukan hanya menyegarkan deadline.
Kedaluwarsa STON.fi diberlakukan saat Pool mengeksekusi, bukan saat wallet menandatangani.
Apakah Anda akan menetapkan tx_deadline STON.fi yang lebih pendek saat beban tinggi, atau memberi ruang lebih untuk keterlambatan pesan? 👇
Hapus langkah trace yang paling membingungkan Anda saat swap V2 terlihat sudah kedaluwarsa.
Bukan nasihat investasi - teliti sendiri! 🚀
$GRAM @STONfi DEX
