博客 · 2026年11月2日

五分钟还是一小时:怎么选 TRON 能量租期

我们卖 TRON 能量有两种租期,300 秒和 3,600 秒。两种租期为同一笔转账交付的能量相同,也都是按整个租期里每单位能量定价。一小时的租期让这些能量在地址上留得更久。五分钟适合按信号发送的软件;当有一个人或一大批转账隔在能量到账和转账发出之间时,多出来的这段时间才值得付钱。

一次租赁,就是一定量的能量加一段期限

一个订单要写明转账,如果想要默认的五分钟之外的租期,还要写一个 duration_s。能量由转账决定:收款方已经持有 USDT 时大约 65,000 单位,没有时大约 131,000 单位。租期不会改变这个量。价格由租期决定:current_price_sun 是一个单位在整个期限内的价格,所以一小时的价格就是一个单位持有一小时的价格,不用再乘以十二。

在一小时租期上,一笔转账的订单买到的是一笔转账的能量,外加一小时的时间去发送它。一笔转账在第二分钟花掉的单位数,和在第五十分钟花掉的一样多,而花掉的能量在租期内几乎不会回来:账户已用的能量要在接下来的一天里排回去,一小时大约只是那一天的二十四分之一。租来的能量能撑多久把这个每日周期,以及一笔代理上另外两个时钟,都讲了一遍。

窗口就是租期减去三秒

能量在发送地址上一被确认,订单就带上 send_before。五分钟租期上,它是确认之后 297 秒;一小时租期上是 3,597 秒。这三秒在每种租期上都一样,它的全部作用只是让窗口先于租期关闭。网络从承载那笔代理的区块开始计租期,我们则从看到那笔代理被确认时开始计窗口,两者之间的间隔通常比三秒长。在任何一个窗口的最后一刻发出的转账,都可能在能量已经回家之后才落到链上,并以 TRX 烧掉全额费用。

这个间隔在两种租期上一样大。五分钟租期里它从 297 秒中扣,一小时里从 3,597 秒中扣,而规则不变:收到 order.ready webhook 就发,或者在第一次轮询看到 send_before 时就发,并且远离截止时刻。

一个批量订单共用一个截止时刻。它从订单里最后一笔被确认的代理起算,而且不能晚于第一笔成功的采购所允许的时刻,因为能量不可能在被买下之前就开始。我们买一个条目大约要一秒,而轮到时窗口只剩不足三十秒的条目不会被买:它们以 failed 收场,带着 purchase_failed,预留退回。在五分钟租期上,一大批转账大约在第 269 笔处被截断。在一小时租期上,满额的 500 笔一批装得下,窗口还剩下大半。

一小时买到什么

最直白的用法,是一组您会在一小时内发出、但不是一次全发的转账。一轮随批准陆续放行的付款,或者一个由您自己的代码按自己节奏清空的队列,都可以在一小时租期上作为一个批量订单来下。每笔转账的能量一起落到发送钱包上,每笔转账准备好就发。只订您会发的。窗口关闭时仍未使用的条目以 expired 收场并且照常扣费,因为能量已经交付,并且在整个窗口里都留在那里。

一小时也兜得住要等人的发送。在 mode A 里,转账由您自己签名并广播,订单从来看不到它是怎么签的:硬件钱包和第二个审批人都装得下。五分钟给审批人留的余地很小,一小时则绰绰有余。mode B 带不动第二个审批人,因为它只接受 Permission_id 0 上的一个所有者签名,拒绝多重签名。

mode B 最不需要一小时,即使交易是提前很久签好的。在那里,您把一笔签好名的转账交给我们,我们在把能量标为就绪的同一轮处理里把它广播出去,所以单笔转账从更长的窗口里得不到任何好处。窗口还受交易自身过期时间所限,上限是该时间减去三十秒。因此,一小时只有在批量买下需要超过五分钟、并且其中的交易签出时的有效期也超过这个时间时,才对 mode B 订单有帮助。它们可以做到:我们接受的过期时间,最晚到交易到达我们之后的 23 小时 59 分钟。TRON 能量 API 到底做了什么从请求开始,把 mode B 走了一遍。

按数量(energy_units)下单、超过 131,000 单位的订单,只能选一小时。这样的条目是分成几块从多个卖方买下的,每一块的租期从它自己的代理起算,所以在五分钟租期上,第一块已经开始到期时,最后一块还没到。更短的租期会被拒绝,返回 400 invalid_request,details.reason 为 bulk_needs_longer_lease。

一小时和五分钟的价格对比

市场上大多数卖方卖的是一小时。我们的监测在 2026 年 9 月 7 日读到的十七份价目表里,十六份报的是一小时。我们的两种租期各有自己的价格,各自对着市场重新计算,所以谁也不是从另一个推出来的。GET /v1/tariff/history 每次请求画一种租期,带上 range=30d 时会返回 720 个按小时的点,即我们成交的价格。我们在 2026 年 10 月 27 日读了这两个序列,逐小时做了比较。

一小时租期在多数小时里更贵,在一些小时里更便宜,放到整个月来看,两者相差不大。溢价逐周变动,四个周里有一个周,一小时反而更便宜。那个月的大部分时间,价格是按此前每日的时段价目表卖的,10 月 26 日起每种租期换成了一个价格。最后一行从那天的 00:00 UTC 起,所以它最初几个小时可能还带着那套时段价目表,而两天太短,说不清这个差距能不能维持。

这份历史记录的是我们成交的价格,对下一个小时不作任何承诺。两种租期今天的价格都在价格页,products[] 里是同样的数字,由 GET /v1/tariff 返回。TRON 能量什么时候最便宜把同一份历史按一天中的各个小时读了一遍。

怎么选租期

按能量落地之后,您的发送最长要多久来选。如果是几秒,选五分钟。如果更长,选一小时,并且只订您会在这一小时内发出的转账。

让您的代码每次都从 products[] 读取租期。产品上架下架不需要发版:一天租期已于 2026 年 10 月 25 日停售,而指名一个未在售租期的订单或估价,会得到 400 invalid_request,在售的租期放在 details.allowed 里。租期是订单请求体的一部分,所以用同一个幂等键、换一个 duration_s 重试,会被拒绝,返回 409 idempotency_conflict,什么也不创建。

整天都在发送的钱包,两种租期都不合适,而且没有比一小时更长的租期在售。Auto-refill 规则正是为它设计的:您给一个地址和一个每日预算,钱包在每发一笔转账之后都会被补回能量。

我们没有量的东西

我们没有量过自家客户的一小时租期订单,从交付到发送之间要等多久,所以这里没有任何一句话说明一个典型订单会用掉一小时中的多少。网络开始计租期与我们开始计之间的间隔,是从窗口的算法推出来的,我们没有单独计时。价格比较只覆盖一个月,而且几乎全部处在此前的每日时段价目表之下。

选之前,先把同一批转账在两种租期上各估一次价,不预留任何东西:POST /v1/estimate 接受 duration_s →