Lima menit atau satu jam: memilih masa sewa energi TRON
Kami menjual energi TRON dalam dua masa sewa, 300 detik dan 3,600 detik. Keduanya mengantar energi yang sama untuk transfer yang sama, dan keduanya dihargai per unit energi untuk seluruh masa sewa. Satu jam membiarkan energi itu di alamat lebih lama. Lima menit cocok untuk perangkat lunak yang mengirim begitu ada sinyal, dan waktu tambahan itu layak dibayar ketika seseorang atau pesanan massal yang panjang berada di antara kedatangan energi dan keluarnya transfer.
Masa sewa adalah sejumlah energi dan sebuah jangka
Sebuah pesanan menyebut transfernya dan, bila menginginkan selain lima menit bawaan, sebuah duration_s. Energinya mengikuti transfernya: sekitar 65,000 unit bila penerima sudah memegang USDT, sekitar 131,000 bila ia tidak memegang. Masa sewa tidak mengubah jumlah itu. Harganya mengikuti masa sewa: current_price_sun adalah biaya satu unit untuk seluruh jangka, jadi harga satu jam adalah harga sebuah unit yang dipegang selama satu jam, tanpa ada yang perlu dikalikan dua belas.
Pada masa sewa satu jam, pesanan untuk satu transfer membeli energi untuk satu transfer dan satu jam untuk mengirimkannya. Sebuah transfer memakai unit yang sama pada menit kedua seperti pada menit kelima puluh, dan energi yang sudah terpakai nyaris tidak pulih selama masa sewa berjalan: energi terpakai milik sebuah akun surut kembali sepanjang hari berikutnya, dan satu jam adalah sekitar satu per dua puluh empat dari hari itu. Berapa lama energi sewaan bertahan menelusuri siklus harian itu dan dua hitungan waktu lain pada sebuah delegasi.
Jendelanya adalah masa sewa dikurangi tiga detik
Begitu energi terkonfirmasi di alamat pengirim, pesanan membawa send_before. Pada masa sewa lima menit itu 297 detik setelah konfirmasi, pada satu jam 3,597. Tiga detik itu sama di setiap masa sewa, dan satu-satunya yang dilakukannya adalah membuat jendela tertutup sebelum masa sewanya. Jaringan memulai masa sewa pada blok yang membawa delegasinya, kami memulai jendela ketika kami melihat delegasi itu terkonfirmasi, dan selisih antara keduanya biasanya lebih panjang dari tiga detik. Transfer yang dikirim tepat di ujung salah satu jendela bisa mendarat setelah energinya pulang dan membakar seluruh biaya dalam TRX.
Selisih itu sama besarnya pada kedua masa sewa. Pada lima menit ia diambil dari 297 detik, pada satu jam dari 3,597, dan aturannya tetap sama: kirim pada webhook order.ready atau pada polling pertama yang menampilkan send_before, dan jaga jarak yang lebar dari tenggatnya.
Sebuah pesanan massal berbagi satu tenggat. Ia dihitung dari delegasi terakhir yang terkonfirmasi dalam pesanan, dan tidak bisa lebih lambat dari yang diizinkan pembelian pertama yang berhasil, sebab energi tidak bisa mulai sebelum dibeli. Kami membeli sekitar satu posisi per detik, dan posisi yang kami capai dengan sisa jendela kurang dari tiga puluh detik tidak dibeli: posisi itu ditutup failed dengan purchase_failed, dan cadangannya kembali. Pada masa sewa lima menit itu memotong pesanan massal besar kira-kira pada transfer ke-269. Pada satu jam, pesanan massal penuh 500 muat dengan sebagian besar jendela masih tersisa.
Apa yang dibeli satu jam
Penggunaan yang paling lugas adalah sekumpulan transfer yang akan Anda kirim dalam satu jam, meski tidak sekaligus. Putaran pembayaran yang keluar seiring persetujuan datang, atau antrean yang dikuras kode Anda sendiri dengan lajunya sendiri, bisa dipesan sebagai satu pesanan massal pada masa sewa satu jam. Energi untuk setiap transfer mendarat bersama di dompet pengirim, dan tiap transfer keluar ketika ia siap. Pesan hanya apa yang akan Anda kirim. Posisi yang jendelanya tertutup tanpa terpakai berakhir expired dan ditagih, karena energinya sudah terkirim dan ditahan sepanjang jendelanya.
Satu jam juga menutup pengiriman yang menunggu seseorang. Di mode A Anda menandatangani dan menyiarkan transfernya sendiri, dan pesanan tidak pernah melihat bagaimana ia ditandatangani: dompet perangkat keras dan penyetuju kedua sama-sama cocok. Lima menit menyisakan sedikit ruang bagi seorang penyetuju, dan satu jam menyisakan banyak. Mode B tidak bisa membawa penyetuju kedua, karena ia menerima satu tanda tangan pemilik pada Permission_id 0 dan menolak multisignature.
Mode B adalah yang paling jarang membutuhkan masa sewa satu jam, bahkan untuk transaksi yang ditandatangani jauh sebelumnya. Di sana Anda menyerahkan transfer yang sudah ditandatangani kepada kami, dan kami menyiarkannya dalam satu proses yang sama yang menandai energinya siap, jadi satu transfer tidak mendapat apa-apa dari jendela yang lebih panjang. Jendelanya juga dibatasi oleh kedaluwarsa transaksi itu sendiri, dikurangi tiga puluh detik. Karena itu satu jam membantu pesanan mode B hanya bila pesanan massalnya butuh lebih dari lima menit untuk dibeli dan transaksinya ditandatangani agar hidup lebih lama dari itu. Itu mungkin: kami menerima kedaluwarsa hingga 23 jam 59 menit setelah transaksi sampai kepada kami. Apa yang sebenarnya dilakukan API energi TRON menelusuri mode B mulai dari permintaannya.
Pesanan untuk sebuah volume (energy_units) di atas 131,000 unit harus memakai satu jam. Posisi seperti itu dibeli dalam potongan dari beberapa penjual, dan masa sewa tiap potongan berjalan dari delegasinya sendiri, jadi pada lima menit potongan pertama akan mulai kedaluwarsa ketika yang terakhir masih berdatangan. Masa sewa yang lebih pendek ditolak dengan 400 invalid_request, details.reason bulk_needs_longer_lease.
Berapa biaya satu jam dibanding lima menit
Sebagian besar pasar menjual satu jam. Dari tujuh belas daftar harga yang dibaca pemantau kami pada 7 September 2026, enam belas mencantumkan satu jam. Tiap dari dua masa sewa kami punya harganya sendiri, dihitung ulang terhadap pasar, jadi tak satu pun diturunkan dari yang lain. GET /v1/tariff/history menggambar satu masa sewa per permintaan, dan dengan range=30d ia mengembalikan 720 titik per jam dari harga yang kami jual. Kami membaca kedua deret itu pada 27 Oktober 2026 dan membandingkannya jam demi jam.
| Satu jam dibanding lima menit, 30 hari dibaca 27 Oktober 2026 | Hasil |
|---|---|
| Titik per jam di tiap deret | 720 |
| Jam ketika masa sewa satu jam lebih mahal | 416 dari 720 |
| Jam ketika keduanya berbiaya sama | 116 dari 720 |
| Jam ketika masa sewa satu jam lebih murah | 188 dari 720 |
| Biaya satu jam untuk setiap 100 biaya lima menit, jam per jam | dari 71 sampai 122 |
| Sama, seluruh 30 hari digabung | 102 |
| Sama, tiap dari empat pekan penuh terakhir, dari yang tertua | 102, 101, 98, 106 |
| Sama, 46 jam sejak 00:00 UTC pada 26 Oktober | 108 |
Masa sewa satu jam lebih mahal pada sebagian besar jam dan lebih murah pada sebagian lainnya, dan sepanjang bulan keduanya berakhir berdekatan. Premi bergerak dari pekan ke pekan, dan pada satu dari empat pekan itu satu jam keluar lebih murah. Sebagian besar bulan itu dijual di bawah jadwal harga harian yang lama, dan satu harga per masa sewa menggantikannya pada 26 Oktober. Baris terakhir dimulai pukul 00:00 UTC pada hari itu, jadi jam-jam pertamanya mungkin masih membawa jadwal itu, dan dua hari terlalu sedikit untuk mengatakan apakah selisihnya akan bertahan.
Riwayat itu mencatat harga yang kami jual dan tidak menjanjikan apa pun tentang jam berikutnya. Harga hari ini untuk kedua masa sewa ada di halaman harga, dan products[] dari GET /v1/tariff mengembalikan angka yang sama. Kapan energi TRON paling murah membaca riwayat yang sama sepanjang jam-jam dalam sehari.
Memilih masa sewa
Pilihlah menurut waktu terlama yang bisa dibutuhkan pengiriman Anda setelah energi mendarat. Bila hitungannya detik, ambil lima menit. Bila lebih lama, ambil satu jam, dan pesan hanya transfer yang akan Anda lakukan di dalamnya.
Buat kode Anda membaca masa sewa dari products[] setiap kali. Produk bisa mulai dan berhenti dijual tanpa rilis: masa sewa satu hari berhenti dijual pada 25 Oktober 2026, dan pesanan atau estimasi yang menyebut masa sewa yang tidak dijual mendapat 400 invalid_request, dengan masa sewa yang dijual ada di details.allowed. Masa sewa adalah bagian dari body pesanan, jadi percobaan ulang dengan kunci idempotensi yang sama dan duration_s yang berbeda ditolak dengan 409 idempotency_conflict dan tidak membuat apa pun.
Dompet yang mengirim sepanjang hari tidak cocok dengan salah satu masa sewa itu, dan tidak ada yang lebih panjang dari satu jam yang dijual. Aturan Auto-refill dibuat untuknya: Anda memberi sebuah alamat dan batas harian, dan dompet itu diisi kembali sesudah setiap transfer yang dibuatnya.
Apa yang tidak kami ukur
Kami belum mengukur berapa lama pesanan masa sewa satu jam milik pelanggan kami sendiri menunggu antara energi terkirim dan transfer dikirim, jadi tidak ada di sini yang mengatakan berapa bagian dari satu jam yang dipakai pesanan tipikal. Selisih antara awal masa sewa menurut jaringan dan menurut kami dihitung dari cara jendelanya dihitung, dan belum kami ukur waktunya secara terpisah. Perbandingan harga mencakup satu bulan, hampir seluruhnya di bawah jadwal harian yang lama.
Hitung harga pesanan massal yang sama pada kedua masa sewa sebelum memilih, tanpa mencadangkan apa pun: POST /v1/estimate menerima duration_s →