Năm phút hay một giờ: chọn một thời hạn thuê năng lượng TRON
Chúng tôi bán năng lượng TRON theo hai thời hạn thuê, 300 giây và 3,600 giây. Cả hai giao cùng một lượng năng lượng cho cùng một lần chuyển, và cả hai đều được tính giá theo từng đơn vị năng lượng cho trọn thời hạn thuê. Thời hạn một giờ để lượng năng lượng đó nằm trên địa chỉ lâu hơn. Năm phút hợp với phần mềm gửi ngay khi có tín hiệu, còn thời gian dôi ra đáng trả tiền khi có một con người hoặc một lô dài đứng giữa lúc năng lượng tới và lúc lần chuyển đi ra.
Thuê năng lượng là mua một lượng năng lượng trong một kỳ hạn
Một đơn hàng nêu lần chuyển và, nếu muốn khác mức mặc định là năm phút, thì nêu thêm duration_s. Lượng năng lượng phụ thuộc vào lần chuyển: khoảng 65,000 đơn vị khi người nhận đã giữ USDT, khoảng 131,000 khi nó không giữ chút nào. Thời hạn thuê không làm đổi lượng đó. Giá phụ thuộc vào thời hạn thuê: current_price_sun là giá của một đơn vị cho trọn kỳ hạn, nên giá của thời hạn một giờ là giá của một đơn vị được giữ trong một giờ, không có gì để nhân với mười hai.
Ở thời hạn thuê một giờ, một đơn hàng cho một lần chuyển mua năng lượng cho một lần chuyển và một giờ để gửi nó. Một lần chuyển tiêu cùng số đơn vị ở phút thứ hai cũng như ở phút thứ năm mươi, và năng lượng đã tiêu hầu như không hồi lại trong lúc thời hạn thuê chạy: năng lượng đã dùng của một tài khoản hồi dần trong 24 giờ tiếp theo, và một giờ chỉ bằng khoảng một phần hai mươi bốn của ngày đó. Năng lượng TRON thuê thực sự kéo dài bao lâu đi qua chu kỳ theo ngày ấy cùng hai chiếc đồng hồ còn lại của một lần ủy quyền.
Cửa sổ là thời hạn thuê trừ đi ba giây
Khi năng lượng đã được xác nhận trên địa chỉ gửi, đơn hàng mang theo send_before. Ở thời hạn thuê năm phút, đó là 297 giây sau khi xác nhận, ở thời hạn một giờ là 3,597. Ba giây ấy giống nhau ở mọi thời hạn thuê, và tất cả những gì chúng làm là khiến cửa sổ đóng lại trước khi thời hạn thuê đóng. Mạng lưới bắt đầu thời hạn thuê ở khối mang lần ủy quyền, chúng tôi bắt đầu cửa sổ khi thấy lần ủy quyền đó được xác nhận, và khoảng cách giữa hai mốc ấy thường dài hơn ba giây. Một lần chuyển gửi ngay cuối cửa sổ nào cũng có thể tới nơi sau khi năng lượng đã bị thu hồi và đốt trọn khoản phí bằng TRX.
Khoảng cách đó có cùng cỡ ở cả hai thời hạn thuê. Ở thời hạn năm phút nó bị trừ vào 297 giây, ở thời hạn một giờ vào 3,597, và quy tắc vẫn y nguyên: hãy gửi ngay khi có webhook order.ready hoặc ở lần hỏi lại đầu tiên cho thấy send_before, và giữ khoảng cách thật xa với hạn chót.
Một lô dùng chung một hạn chót. Hạn đó tính từ lần ủy quyền cuối cùng được xác nhận trong đơn hàng, và không thể muộn hơn mức mà lần mua thành công đầu tiên cho phép, vì năng lượng không thể bắt đầu trước khi nó được mua. Chúng tôi mua với tốc độ khoảng một giây mỗi vị trí, và những vị trí mà chúng tôi tới được khi cửa sổ còn dưới ba mươi giây thì không được mua: chúng đóng ở trạng thái failed với purchase_failed, và phần giữ lại cho chúng được nhả ra. Ở thời hạn năm phút, điều đó cắt một lô lớn ở khoảng lần chuyển thứ 269 của nó. Ở thời hạn một giờ, một lô đầy đủ 500 lần chuyển vừa vặn mà vẫn còn dư phần lớn cửa sổ.
Một giờ mua được gì
Cách dùng đơn giản nhất là một tập các lần chuyển mà bạn sẽ gửi trong vòng một giờ, dù không phải tất cả cùng một lúc. Một đợt chi trả đi ra khi các phê duyệt lần lượt tới, hoặc một hàng đợi mà chính mã của bạn xả theo nhịp riêng, có thể được đặt thành một lô ở thời hạn thuê một giờ. Năng lượng cho mọi lần chuyển đáp xuống ví gửi cùng lúc, và mỗi lần chuyển đi ra khi nó sẵn sàng. Chỉ đặt những gì bạn sẽ gửi. Một vị trí có cửa sổ đóng lại mà không được dùng sẽ kết thúc ở trạng thái expired và bị tính tiền, vì năng lượng đã được giao và giữ suốt cả cửa sổ.
Thời hạn một giờ cũng phủ trường hợp một lần gửi phải chờ một con người. Ở mode A, bạn tự ký và tự phát lần chuyển, và đơn hàng không bao giờ thấy nó được ký thế nào: một ví phần cứng và một người phê duyệt thứ hai đều phù hợp. Năm phút chừa rất ít chỗ cho một người phê duyệt, còn một giờ chừa rất nhiều. Mode B không thể mang người phê duyệt thứ hai, vì nó chỉ nhận một chữ ký của chủ sở hữu ở Permission_id 0 và từ chối đa chữ ký.
Mode B cần thời hạn một giờ ít nhất, kể cả với một giao dịch được ký từ rất sớm. Ở đó bạn trao cho chúng tôi một lần chuyển đã ký, và chúng tôi phát nó ngay trong cùng lượt đánh dấu năng lượng đã sẵn sàng, nên một lần chuyển đơn lẻ chẳng được gì từ một cửa sổ dài hơn. Cửa sổ còn bị chặn trên bởi thời điểm hết hạn của chính giao dịch, trừ ba mươi giây. Vì vậy thời hạn một giờ chỉ giúp một đơn hàng mode B khi lô cần hơn năm phút để mua và các giao dịch của nó được ký để sống lâu hơn thế. Chúng có thể như vậy: chúng tôi chấp nhận thời điểm hết hạn tối đa 23 giờ 59 phút sau khi giao dịch tới chỗ chúng tôi. API năng lượng TRON thực sự làm gì đi qua mode B từ yêu cầu trở lên.
Một đơn hàng theo khối lượng (energy_units) trên 131,000 đơn vị buộc phải lấy thời hạn một giờ. Một vị trí như vậy được mua thành nhiều mảnh từ nhiều người bán, và thời hạn thuê của mỗi mảnh chạy từ lần ủy quyền riêng của nó, nên ở thời hạn năm phút mảnh đầu sẽ bắt đầu hết hạn khi mảnh cuối còn đang tới. Một thời hạn thuê ngắn hơn bị từ chối với 400 invalid_request, details.reason là bulk_needs_longer_lease.
Thời hạn một giờ tốn bao nhiêu so với năm phút
Phần lớn thị trường bán thời hạn một giờ. Trong mười bảy bảng giá mà trình theo dõi của chúng tôi đọc ngày 7 tháng 9 năm 2026, mười sáu bảng chào một giờ. Mỗi thời hạn thuê trong hai thời hạn của chúng tôi có giá riêng, được tính lại theo thị trường, nên không thời hạn nào suy ra từ thời hạn kia. GET /v1/tariff/history vẽ biểu đồ một thời hạn thuê cho mỗi yêu cầu, và với range=30d nó trả về 720 điểm theo giờ về mức giá chúng tôi đã bán. Chúng tôi đọc cả hai chuỗi ngày 27 tháng 10 năm 2026 và so sánh chúng từng giờ một.
| Thời hạn một giờ so với năm phút, 30 ngày đọc ngày 27 tháng 10 năm 2026 | Kết quả |
|---|---|
| Số điểm theo giờ trong mỗi chuỗi | 720 |
| Số giờ thời hạn một giờ tốn hơn | 416 trên 720 |
| Số giờ hai thời hạn tốn bằng nhau | 116 trên 720 |
| Số giờ thời hạn một giờ tốn ít hơn | 188 trên 720 |
| Thời hạn một giờ tốn bao nhiêu cho mỗi 100 mà thời hạn năm phút tốn, từng giờ riêng lẻ | từ 71 tới 122 |
| Tương tự, cả 30 ngày gộp lại | 102 |
| Tương tự, mỗi tuần trong bốn tuần trọn vẹn gần nhất, cũ nhất trước | 102, 101, 98, 106 |
| Tương tự, 46 giờ kể từ 00:00 UTC ngày 26 tháng 10 | 108 |
Thời hạn một giờ tốn hơn ở phần lớn các giờ và rẻ hơn ở một số giờ, và tính chung cả tháng thì hai thời hạn ra sát nhau. Khoản chênh thay đổi từ tuần này sang tuần khác, và trong một trong bốn tuần thì thời hạn một giờ ra rẻ hơn. Phần lớn tháng đó được bán theo biểu giá hằng ngày trước đây, và một mức giá cho mỗi thời hạn thuê đã thay thế nó ngày 26 tháng 10. Hàng cuối bắt đầu từ 00:00 UTC của ngày ấy, nên những giờ đầu của nó có thể vẫn mang biểu giá cũ, và hai ngày là quá ít để nói khoảng chênh có giữ được hay không.
Lịch sử ghi lại mức giá chúng tôi đã bán và không hứa gì về giờ tiếp theo. Giá hôm nay của cả hai thời hạn thuê nằm ở trang bảng giá, và products[] của GET /v1/tariff trả về cùng các con số đó. Năng lượng TRON rẻ nhất khi nào đọc cùng lịch sử này theo các giờ trong ngày.
Chọn một thời hạn thuê
Hãy chọn theo khoảng dài nhất mà việc gửi của bạn có thể mất sau khi năng lượng đáp xuống. Nếu là vài giây, hãy lấy năm phút. Nếu lâu hơn, hãy lấy một giờ, và chỉ đặt những lần chuyển bạn sẽ thực hiện bên trong nó.
Hãy để mã của bạn đọc các thời hạn thuê từ products[] mỗi lần. Sản phẩm được mở và ngừng bán mà không cần một bản phát hành: thời hạn thuê một ngày đã ngừng bán ngày 25 tháng 10 năm 2026, và một đơn hàng hoặc một ước tính nêu tên một thời hạn thuê không còn bán sẽ nhận 400 invalid_request, kèm các thời hạn thuê đang bán trong details.allowed. Thời hạn thuê là một phần của phần thân đơn hàng, nên một lần thử lại dưới cùng khóa idempotency với duration_s khác sẽ bị từ chối với 409 idempotency_conflict và không tạo ra gì.
Một chiếc ví gửi suốt cả ngày không hợp với thời hạn thuê nào, và không có gì dài hơn một giờ đang được bán. Một quy tắc Auto-refill được dựng cho trường hợp đó: bạn đưa một địa chỉ và một ngân sách mỗi ngày, và ví được nạp lại sau mỗi lần chuyển nó thực hiện.
Những gì chúng tôi không đo
Chúng tôi chưa đo các đơn hàng thời hạn một giờ của chính khách hàng mình chờ bao lâu giữa lúc giao và lúc gửi, nên không có gì ở đây nói một đơn hàng điển hình dùng bao nhiêu phần của giờ ấy. Khoảng cách giữa lúc mạng lưới bắt đầu một thời hạn thuê và lúc chúng tôi bắt đầu được suy ra từ cách cửa sổ được tính, và chúng tôi chưa bấm giờ riêng nó. Phần so sánh giá bao trùm một tháng, gần như toàn bộ nằm dưới biểu giá hằng ngày trước đây.
Hãy tính giá cùng một lô trên cả hai thời hạn thuê trước khi chọn, mà không có gì bị giữ lại: POST /v1/estimate nhận duration_s →