Sweep USDT dari alamat deposit di TRON: aktivasi, energi, dan bandwidth per sweep
Gerbang pembayaran atau bursa yang memberi setiap pelanggan alamat deposit tersendiri harus mengumpulkan USDT TRC-20 di alamat-alamat itu ke satu dompet utama, dompet panas, sebelum bisa membayarkan sebagian darinya. Di TRON, tiap perpindahan itu adalah transfer USDT biasa, yang ditandatangani oleh alamat deposit. Ia membutuhkan akun di rantai, energi untuk panggilan kontrak, dan bandwidth untuk byte-nya, dan alamat deposit yang hanya pernah dibayar dengan USDT tidak punya satu pun dari ketiganya.
Menerima USDT tidak membuat akun
Saldo USDT adalah satu entri di penyimpanan milik kontrak token itu sendiri. Transfer masuk menulis entri itu dan tidak membuat akun, jadi sebuah alamat bisa memegang USDT sementara jaringan sama sekali tidak punya akun untuknya. Pengukuran kami pada 7 September 2026 menemukan dua alamat seperti itu di mainnet: masing-masing memegang USDT, dan node yang kami baca mengembalikan objek kosong ketika ditanya akun di baliknya, baik sebelum maupun sesudah panggilan uji kami. Pada 27 Oktober keduanya masih memegang persis saldo yang mereka pegang pada 7 September.
Energi didelegasikan ke sebuah akun, dan kami tidak mengantarkannya ke alamat yang tidak punya: pesanan di mode A atau mode C yang menyebut alamat seperti itu sebagai from kembali dengan 422 invalid_address dan details.reason diisi inactive_wallet. Apakah rantai sendiri akan menerima delegasi ke alamat seperti itu belum kami uji, karena penolakan kami datang lebih dulu. Catatan operasi kami juga mencatat jawaban node untuk pengiriman dari dompet yang belum pernah menerima apa pun, no OwnerAccount. Catatan itu tentang TRX yang dikirim dari dompet panas kami sendiri; kami belum mencoba transfer USDT keluar dari alamat dalam keadaan ini. Cerita yang lebih luas tentang keadaan itu ada di tulisan tentang akun yang belum aktif.
Mengaktifkan alamat butuh satu transfer TRX, dibayar pengirimnya
Transfer TRX masuk apa pun membuat akunnya, sekecil apa pun, dan sejak itu alamat tersebut adalah akun seperti yang lain. Percobaan pertama pengukuran itu salah persis di situ, dan kami membuangnya: sebuah alamat terbaca tanpa akun, dan 22 detik kemudian seseorang mengirimkan satu sun kepadanya, yang membuat sebuah akun. Waktu pembuatannya sendiri mengatakan demikian.
Biaya pembuatannya jatuh pada siapa pun yang mengirim TRX: dalam susunan sweep, dompet yang mendanai aktivasi. Dua parameter rantai menetapkannya. Kami membacanya pada 3 September 2026, dan jaringan bisa mengubahnya, jadi bacalah lagi sebelum Anda menganggarkan dengannya.
| Parameter rantai | Nilai, dibaca 3 September 2026 |
|---|---|
getCreateAccountFee | 0.1 TRX |
getCreateNewAccountFeeInSystemContract | 1 TRX |
Bagaimana keduanya bergabung pada transfer TRX biasa belum kami ukur dengan pengiriman kami sendiri: itu membutuhkan transfer sungguhan ke alamat baru, dan kami belum membuatnya. Bagaimanapun, biayanya dibayar sekali per alamat. Meja yang mengaktifkan setiap alamat ketika ia dibuat membayarnya pada alamat yang mungkin tidak pernah menerima deposit, dan yang mengaktifkan pada deposit pertama membayarnya hanya di tempat ada sesuatu untuk di-sweep.
Setiap sweep memakai angka energi yang lebih rendah
Energi yang dipakai sebuah transfer USDT bergantung pada penerimanya. Bila penerima sudah memegang USDT, transfer memakai sekitar 65,000 unit; bila saldo USDT-nya nol, memakai sekitar 131,000. Punya akun atau tidaknya penerima tidak ikut menentukan. Pengukuran yang menemukan kedua alamat itu menaruh keempat kombinasi berdampingan, dan saldo yang menentukan setiap kali (mengapa ada dua angka).
Sebuah sweep selalu membayar penerima yang sama, dompet panas, dan dompet panas memegang USDT. Jadi setiap sweep adalah jenis yang lebih murah, single, apa pun keadaan alamat deposit. Panggilan 7 September memindahkan satu unit dari dompet yang menyimpan sisanya, sedangkan sweep memindahkan semuanya dan meninggalkan alamat deposit di nol. Pada 27 Oktober kami meminta node mensimulasikan keduanya pada dua alamat yang sama, dengan dompet yang memegang USDT sebagai penerima.
| Transfer simulasi ke dompet yang memegang USDT, 27 Oktober 2026 | Energi terpakai |
|---|---|
| Alamat pertama, satu unit | 64,285 |
| Alamat pertama, seluruh saldonya | 64,285 |
| Alamat kedua, satu unit | 64,285 |
| Alamat kedua, seluruh saldonya | 64,285 |
Mengosongkan alamat deposit tidak mengubah apa pun, dan angkanya adalah angka yang diberikan pengukuran itu untuk setiap transfer ke pemegang. Ini simulasi node, dan tak satu pun darinya adalah receipt dari sweep yang disiarkan; angka 7 September membawa catatan yang sama. Apakah kedua alamat itu punya akun hari ini tidak kami baca ulang.
Satu-satunya cara kehilangan jenis yang lebih murah adalah mengosongkan dompet panas. Satu unit USDT pada penerima sudah cukup untuk angka yang lebih rendah, tetapi pada nol, sweep berikutnya ke dalamnya memakai sekitar 131,000 unit, yaitu 13.1 TRX bila dibakar. Dibakar, sweep normal berbiaya 6.5 TRX pada tarif protokol 100 sun per unit, dan berapa biaya menyewa energi yang sama bergerak bersama pasar.
Bandwidth gratis menutup sekitar satu sweep per alamat per hari
Bandwidth mengukur byte sebuah transaksi, sedangkan energi mengukur komputasinya (kedua meteran berdampingan). Setiap akun mendapat jatah harian gratis darinya. Transfer USDT yang kami kirim dan ukur di mainnet pada 2 September 2026 membayar bandwidth-nya dengan TRX, dan itu memberi persis berapa bandwidth yang ditagihkan kepadanya.
| Bandwidth satu transfer USDT | Nilai | Dibaca pada |
|---|---|---|
Dibakar untuk byte (net_fee) | 0.345 TRX | 2 September 2026 |
Harga bakar satu byte (getTransactionFee) | 1,000 sun | 3 September 2026 |
| Bandwidth yang ditagihkan, dengan pembagian | 345 byte | dihitung |
Jatah gratis per akun per hari (getFreeNetLimit) | 600 | 3 September 2026 |
Terhadap 600 per hari, satu sweep yang ditagih sebesar itu muat dan dua berturut-turut tidak. Lewat dari jatah, jaringan membakar TRX pengirim untuk byte-nya. Jadi sweep pertama sebuah alamat dalam sehari tidak berbiaya bandwidth, dan alamat deposit yang juga menerima energinya lewat delegasi tidak butuh TRX sendiri untuk mengirimkannya. Sweep kedua tak lama setelah yang pertama membayar byte-nya dari TRX milik alamat deposit. Seberapa cepat jatah itu pulih di antara keduanya belum kami ukur; sweep kami sendiri merencanakan sekitar satu transfer per hari per alamat dari jatah gratis. Bila sebuah alamat akan di-sweep lebih sering dari itu, transfer aktivasi bisa meninggalkan TRX untuk byte-byte itu padanya pada saat yang sama.
Memesan energi untuk satu putaran sweep
Mode A menyebut kedua ujung tiap transfer, alamat deposit sebagai from dan dompet panas sebagai to, dan kami sendiri yang membaca jenisnya dari dompet panas. Mode C hanya menyebut dompet yang akan diberi energi dan mengambil jenisnya dari Anda, yang cocok untuk sistem kustodi yang menandatangani sweep-nya sesuai jadwalnya sendiri dan menginginkan energinya sudah tersedia di sana lebih dulu (mode C secara rinci). Untuk sweep, jenis itu selalu single, selama dompet panas memegang USDT. Kedua mode menerima hingga 500 transfer dalam satu pesanan, plafon yang sama dengan putaran pembayaran. Masa sewanya lima menit atau satu jam, dan send_before jatuh tiga detik sebelum akhirnya.
Satu alamat deposit tanpa akun menolak seluruh pesanan. 422 menyebutnya di details.index dan details.address, dan tidak ada yang dibeli. Jadi saring putaran itu lebih dulu. POST /v1/estimate menerima 500 transfer yang sama dan tidak mencadangkan apa pun, dan ia memperingatkan di mana pesanan akan ditolak: beri ia from pada tiap item, dan setiap alamat deposit tanpa akun kembali ditandai inactive_sender. Aktifkan alamat-alamat itu, biarkan aktivasinya terkonfirmasi, lalu kirim pesanannya. Penolakan itu tidak menghabiskan Idempotency-Key, dan kami membaca ulang aktivasi tanpa melalui cache kami sebelum menolak pesanan karenanya, jadi kunci yang sama dan body yang sama berfungsi begitu transfer aktivasi terkonfirmasi.
Aturan yang layak diambil dari sweep kami sendiri
Kami menjalankan sweep sendiri. Klien membayar ke alamat deposit yang kami pegang untuk mereka, dan sebuah proses latar belakang memindahkan koin-koin itu ke satu dompet panas yang membayar pembelian. Ia memindahkan TRX, jadi ia memakai bandwidth dan tidak memakai energi, dan catatannya tidak mengatakan apa pun tentang sisi energi sebuah sweep USDT.
Sweep kami membaca jumlahnya dari rantai pada saat ia memutuskan. Catatan kami sendiri tidak tahu tentang biaya yang dibakar, atau tentang sweep yang baris database-nya tidak selamat dari proses yang crash, dan rantai tahu. Aturan yang sama membuat percobaan ulang aman: bila koin sudah pergi, tidak ada yang perlu dikirim.
Kami membiarkan sweep yang sudah disiarkan tetap terbuka sampai transaksinya muncul di sebuah blok, dan kami menghapusnya sebagai gagal hanya setelah jendela yang tidak lebih pendek dari kedaluwarsa terpanjang yang diberikan signer kami pada sebuah transaksi. Tutup lebih cepat dan transfer yang masih bisa mendarat dihitung sebagai hilang, dan proses berikutnya bisa menandatangani transfer kedua dari saldo yang sama. Selama sebuah sweep belum terkonfirmasi, alamatnya tetap di luar proses berikutnya.
Sweep TRX kami mengirim paling banyak saldo dikurangi cadangan biaya, dan menyimpan cadangan itu hanya bila bandwidth gratis alamatnya sudah habis. Sweep USDT membayar biayanya dengan koin yang berbeda dari yang dipindahkannya, jadi seluruh saldo USDT berangkat setiap kali, dan cadangan itu menjadi TRX yang dibutuhkan alamat deposit untuk byte sweep kedua dalam sehari.
Temukan setiap alamat deposit yang masih perlu diaktifkan sebelum sweep dihargai, lima ratus per permintaan: POST /v1/estimate dengan from pada tiap item →