Blog · 4 November 2026

Transaksi TRON pending, kedaluwarsa, atau tidak ditemukan: artinya bagi transfer USDT

TRON membuat satu blok setiap tiga detik, jadi lima menit di rantai adalah seratus blok. Transfer USDT yang masih tampil pending setelah itu berada di salah satu dari empat tempat: ditandatangani tetapi tidak pernah disiarkan, diterima sebuah node tetapi belum masuk blok, berada di blok yang masih bisa dibalik, atau sudah final di rantai dan menunggu platform penerima mengkreditkannya. Dua kata lain cenderung muncul di sepanjang jalan: explorer yang tidak bisa menemukan hash-nya, dan node yang menyebut transaksi itu kedaluwarsa. Masing-masing punya perbaikannya sendiri, dan salah satu perbaikan itu, bila diterapkan terlalu dini, membayar transfer yang sama dua kali.

Setiap transaksi membawa tenggatnya sendiri

Interval blok adalah konstanta protokol, 3,000 milidetik. Angka yang lain ada di dalam transaksi. Ketika sebuah dompet membangun transfer, ia menulis waktu expiration ke dalam raw_data, bagian yang ditandatangani, dan setiap node memeriksanya. Transaksi yang waktu kedaluwarsanya sudah lewat ditolak, begitu pula transaksi yang waktu kedaluwarsanya berada lebih dari sehari di depan blok ujung milik node. Kata node untuk keduanya adalah TRANSACTION_EXPIRATION_ERROR.

Sepasang field kedua mengikat transaksi ke sebuah blok terbaru. ref_block_bytes dan ref_block_hash menyebut blok yang masih dipegang jaringan, dan sebuah node mengingat 65,536 blok terakhir, sekitar 54 jam rantai. Referensi yang lebih tua dari itu, atau yang diambil dari jaringan uji, mendapat TAPOS_ERROR sebagai gantinya. Jam untuk keduanya mulai berdetak ketika transaksi dibangun.

Empat hal yang bisa berarti "pending"

Ditandatangani, tidak pernah disiarkan

Dompet atau skrip pembayaran bisa menandatangani sebuah transfer lalu tidak pernah menyerahkannya ke node, setelah timeout atau crash di antara penandatanganan dan pengiriman. Transfer itu tetap punya hash, karena hash dihitung dari byte transaksi itu sendiri. Ia adalah SHA-256 dari raw_data, dan ia ada sebelum node mana pun melihat apa pun. Hash di log Anda membuktikan bahwa transfer itu dibangun. Explorer yang menjawab "tidak ditemukan" untuknya benar: tidak ada node yang dibacanya yang memegang byte itu.

Diterima sebuah node, belum masuk blok

Node yang menerima sebuah transaksi menjawab seketika dan menyimpannya di pool transaksi pending miliknya sampai sebuah blok membawanya. Penerimaan dan pemasukan ke blok adalah dua peristiwa terpisah, dan status pesanan kami sendiri memisahkan keduanya: di mode B, tempat kami menyiarkan transfer yang ditandatangani klien, broadcasted berarti sebuah node menerima transaksinya dan belum mengatakan apa pun tentang sebuah blok. Pada rantai tiga detik, keadaan ini singkat. Sebuah node juga bisa menerima transaksi yang tidak pernah dibawa blok mana pun, biasanya karena ia dijatuhkan dari pool itu. Transfer seperti itu hilang untuk selamanya ketika waktu kedaluwarsanya lewat.

Di dalam blok, masih bisa dibalik

Blok-blok terbaru di ujung rantai masih bisa diganti. TRON menyimpan penunjuk kedua di belakang ujung rantai, blok tersolidifikasi terbaru, yaitu yang terbaru yang diperlakukan jaringan sebagai tidak dapat dibalik, dan sebuah node melayani keduanya. Jarak di antara keduanya adalah berapa lama sebuah transfer berada di dalam blok tanpa menjadi final. Kami membaca kedua penunjuk itu sekali dari sebuah full node publik, dengan dua panggilan yang dibuat pada saat yang sama.

Selisih nomor blok dan selisih cap waktu sesuai pada tiga detik per blok. Item mode B kami mencapai confirmed hanya setelah solidifikasi, yang menurut referensi API kami sekitar satu menit, dan pembacaan itu sejalan dengannya. Itu memberi jawaban lazim untuk berapa lama sebuah transfer USDT berlangsung di TRON: satu blok setiap tiga detik, dan finalitas sekitar satu menit kemudian. Ini satu pembacaan dari satu node. Kami belum mengukur bagaimana selisih itu bergerak sepanjang hari, atau waktu pesanan kami sendiri dari energi terkirim ke siaran ke blok.

Sudah final di rantai, belum dikreditkan

Bursa atau pemroses pembayaran mengkreditkan deposit setelah hitungan blok yang ia tetapkan sendiri. Kami tidak tahu hitungan platform mana pun dan tidak mengutip satu pun. Sebelum bertanya kepada platform, bacalah hasil yang tertulis di samping transfer. Sebuah transfer bisa berada di dalam blok dan tetap gagal, dengan biaya terpakai dan tidak ada token yang berpindah, dan apa pun selain SUCCESS di tempat itu adalah kegagalan (apa arti OUT_OF_ENERGY, dan cara-cara lain transfer USDT gagal). Transfer yang berhasil di dalam blok tersolidifikasi sudah sampai ke alamat penerima. Yang tersisa adalah pembukuan platform, dan tim dukungan platform bisa menelusurinya dari hash.

Arti kedaluwarsa, dan cara mengirim lagi

Lewat dari waktu kedaluwarsanya, sebuah transaksi tidak bisa masuk ke blok mana pun. Setiap node menolaknya, jadi menyiarkan byte tertandatangani yang sama lagi hanya mengumpulkan penolakan lain. Pemulihannya adalah transaksi baru: bangun transfernya lagi, dengan waktu kedaluwarsa baru dan referensi ke blok terbaru, lalu tandatangani.

Membangun ulang tidak membayar dua kali. Transaksi yang tidak dibawa blok mana pun tidak pernah dieksekusi: ia tidak memindahkan token dan tidak membakar apa pun, karena sebuah transfer memakai energi dan TRX-nya selagi ia berjalan di dalam blok. Begitu sebuah transaksi berada di dalam blok, tidak ada node yang akan menjalankannya untuk kedua kalinya. Satu-satunya cara mengirim uang dua kali adalah menandatangani pengganti selagi yang asli masih bisa mendarat. Sebuah node menilai waktu kedaluwarsa terhadap waktu blok ujungnya, yang bisa tertinggal dari jam Anda, jadi blok yang dibuat dalam detik-detik terakhir sebelum tenggat masih bisa membawa yang asli, dan node atau explorer yang tertinggal mungkin belum menampilkannya. Perangkat lunak yang membangun yang asli memegangnya dan bisa membaca raw_data.expiration, dalam milidetik sejak epoch. Tunggu sampai blok tersolidifikasi terbaru melewati saat itu, yang pada pembacaan kami memakan sekitar satu menit lebih lama, lalu tanyakan kepada sebuah node berdasarkan hash. Bila node itu tetap tidak mengenal transaksinya, yang asli tidak bisa lagi mendarat, dan transfer baru adalah satu-satunya.

Pending dan kedaluwarsa pada pesanan energi

Energi sewaan menambah jam kedua. Ketika energi untuk sebuah pesanan terkirim, pesanan membawa send_before, masa sewa dikurangi tiga detik: 297 detik pada masa sewa lima menit dan 3,597 pada satu jam. Jendelanya dihitung dari delegasi yang kami lihat terkonfirmasi, dan masa sewa di rantai dimulai satu blok dan satu siklus polling sebelum itu, jadi anggaplah detik-detik terakhir jendela sudah hilang (berapa lama energi sewaan bertahan). Transfer yang mencapai blok setelah energinya meninggalkan dompet membakar TRX pengirim pada tarif protokol 100 sun per unit, sekitar 6.5 TRX untuk transfer ke alamat yang memegang USDT.

Apa yang terjadi ketika jendela tertutup bergantung pada siapa yang mengirim. Di mode A Anda menyiarkan transfernya sendiri. Kami memantau jaringan, menandai item sent ketika transfer Anda muncul, dan mengirim webhook order.item.sent dengan hash-nya di data.txid. Bila tidak ada transfer yang muncul pada send_before, item itu menjadi expired dan ditagih, karena energinya sudah terkirim.

Di mode B Anda menyerahkan transaksi yang sudah ditandatangani kepada kami dan kami menyiarkannya begitu energinya mendarat (cara kerja mode B). Item bergerak melalui broadcasting dan broadcasted ke confirmed, yang terakhir hanya setelah solidifikasi. Kami tidak pernah menyiarkan setelah send_before: item yang tidak kami kirim tepat waktu ditutup sebagai failed dengan error: broadcast_window_missed, dan cadangannya kembali utuh. Jendelanya di sana juga dibatasi oleh waktu kedaluwarsa transaksi itu sendiri, dikurangi margin untuk siaran, jadi transaksi yang sampai kepada kami dengan sisa umur sedikit mendapat jendela yang pendek.

Mode B juga memeriksa waktu kedaluwarsa saat masuk. Ketika kami menerima transaksinya, ia membutuhkan sisa umur setidaknya 180 detik dan tidak lebih dari 23 jam 59 menit. Tenggat yang terlalu jauh ke depan kembali sebagai 400 invalid_request dengan details.reason diisi expiration_too_far, dan sisa umur yang terlalu sedikit sebagai 400 yang sama dengan details.index saja. Kedua jawaban datang sebelum energi apa pun dibeli.

Apa yang diperiksa, berurutan

1. Apakah sebuah node pernah menerima transaksinya. Perangkat lunak yang mengirimnya memegang jawaban node itu, atau tidak memegang apa pun karena siaran tidak pernah terjadi. Hash tidak menyelesaikan apa pun dengan sendirinya, sebab ia ada sebelum siaran apa pun.
2. Apakah hash-nya ditemukan, di explorer atau dari node yang ditanyai berdasarkan hash. Bila tidak ditemukan dan waktu kedaluwarsa masih di depan, siarkan byte tertandatangani yang sama lagi. Bila blok tersolidifikasi terbaru sudah melewati waktu kedaluwarsa dan hash tetap tidak ditemukan, bangun transaksi baru dan tandatangani.
3. Hasil di samping hash yang ditemukan. SUCCESS berarti transfernya berhasil. Selain itu berarti ia berjalan dan gagal, dan biayanya sudah terpakai.
4. Apakah bloknya sudah tersolidifikasi. Pada pembacaan kami, blok tidak dapat dibalik terbaru tertinggal dari ujung rantai sekitar satu menit, jadi transfer berhasil yang lebih muda dari itu masih dalam proses menjadi final.
5. Hitungan blok milik platform penerima sendiri, dan sesudah itu tim dukungannya, dengan hash.
6. Pada pesanan kami, itemnya: sent dengan txid-nya di mode A, confirmed di mode B. Bila jendela tertutup lebih dulu, mode A menampilkan expired dan mode B menampilkan failed dengan error: broadcast_window_missed. expired pada mode B berarti sebuah node menolak transaksinya karena transaksinya itu sendiri, atau transaksinya dibatalkan (revert) di dalam blok, dan ia ditagih.

Saksikan sebuah item berhenti di ready lalu berubah expired tanpa ada yang sungguhan dipertaruhkan: sandbox punya penerima yang transfernya tidak pernah datang →