博客 · 2026年11月7日

让付款钱包始终有能量:质押、每笔转账各租一次,或每笔之后都补能

TRON 上的付款钱包,每发一笔 USDT 转账都要花能量:收款方已经持有 USDT 时大约 65,000 单位,不持有时大约 131,000 单位。能量缺位时,网络改收 TRX,每单位 100 sun,每笔就是 6.5 TRX 或 13.1 TRX,而只要钱包里有这些 TRX、交易的 fee_limit 又允许这笔燃烧,这笔付款照样会确认(完整的计算)。所以热钱包要做的事,就是在每次发送之前把能量备好,而不用任何人手工去订。有三种模式能做这件事,而每一种都有自己的失败方式。

质押要按最忙的一天来定,而且每一天都要为它付出

为能量质押 TRX,买到的是一个固定每日池子里的一份。钱包的每日额度,是它的质押量乘以网络的 TotalEnergyLimit 除以 TotalEnergyWeight,而在 2026 年 9 月 3 日,这个比值是 180,000,000,000 比 18,770,236,993:每质押一个 TRX,每天略少于十个单位的能量。除数是网络为能量质押的全部数量,包括您自己的,所以这个数每个区块都在漂移(把公式算了一遍)。

花掉的能量会在接下来的 24 小时里逐渐恢复。一个把一天的大部分付款在中午一次发完的钱包,需要一份能盖住这一次的质押,而这份质押在清闲的时段和清闲的日子里也一直冻结着。退出也很慢。在主网上,今天解押的 TRX,要十四天之后才能提取。

付款量超过质押时,发现额度已经花完的转账会为缺口烧 TRX,而只要钱包里有 TRX、fee_limit 里还有余地,它们照样会确认。没有任何东西返回错误,第一个迹象是钱包历史里的一行燃烧记录(限额太低时会发生什么)。

每笔转账各租一次,会在每次发送前加一段等待

第二种模式是来一笔转账就为它买一次能量。订单写明发送钱包和收款方。API 答复 202,订单自己的地址在 Location 里,轮询间隔在 Retry-After 里,而我们去买能量,并在钱包上盯着它。代理一被确认,订单就带上 send_before,这就是您的代码该发送的信号。窗口是租期减去三秒:五分钟租期上 297 秒,一小时租期上 3,597 秒。

所以每一笔付款都要等一次采购和一个区块。我们在自己的订单上量过这段等待,范围是发送由客户代码来做的订单,从订单创建的那一刻算到链上确认最后一笔代理,覆盖截至 2026 年 9 月 8 日的六十天。

十三个订单是个很小的样本,而且大部分偏早。其中七个来自实盘订单的第一周,最慢的那一单也在其中,之后几周都是三到四秒。我们没有在更大的样本上重复过这次测量。

能量落地之前发出的转账,按全价烧;在 send_before 之后发出的,可能发现能量已经没了,同样去烧。烧掉的 TRX 不会回来。已经交付、却没在窗口内用掉的能量,以 expired 收场并且照常扣费,因为它已经交付(一次租赁的三个时钟)。按自己的时刻表发送的付款队列,必须围着这个信号重建。对于事先已知的一轮付款,一个最多 500 笔转账的批量订单把等待集中到一处:整轮的能量先买下,轮里的每笔转账共用一个 send_before(从里面看一个批量订单是什么样)。

每笔转账之后都给钱包补能的规则

第三种模式是挂在钱包上的一条规则,我们把它作为 Auto-refill 来卖,也就是不持有 TRX 也能发送 USDT在热钱包上的情形。它要两个字段,address 和 daily_budget_trx,一次调用 POST /v1/auto-refill-rules 即可。从那以后,钱包每发一笔转账,都会被补回到大约 131,000 单位能量。这足以应付下一笔转账,哪怕它转给一个不持有 USDT 的地址。这条规则不创建订单:GET /v1/orders 只列出您自己下的订单。

一次补能按它前面那笔转账用掉的量定价。如果那笔转账花了大约 65,000 单位,这次补能就按 single 费率计费;如果花了大约 131,000,就按 double。两个费率都在 GET /v1/tariff 的 maintenance_price_trx 下。它们是自成一体的价格,与租期的价格各动各的,收取的费率是这次补能被确认时生效的那个。新规则的第一次补能始终是 double:前面没有可供参照的转账,钱包一次性拿到完整的 131,000。

计费要等到能量在链上的钱包上可见;供应方说一声它交付了,不算数。每笔扣费都以一个 maintenance.topup 事件的形式到达,里面带着 rule_id、address、units 和 charged_trx,同时也作为一行 charge 出现在 GET /v1/ledger 里。什么也不发的钱包得不到补能,也不为任何补能付费。

补能怎样停下,以及那时钱包会怎样

每日预算 daily_budget_trx,在规则启动时、以及之后每个 UTC 日开始时,从您的可用余额中预留,它就是规则当天最多能花的数额。补能从这份预留里扣,剩下的在 UTC 午夜回到余额。规则的 spent_today_trx 显示这一天已经花了多少。中午提高预算,会把差额加进预留,并不会因此另开一天。

预算花完时,补能停到下一个 UTC 日。您会收到一个 maintenance.budget_exhausted 事件,里面有 spent_today_trx 和 daily_budget_trx,规则仍保持 active。从那时起到午夜,钱包用能量付不起的每一笔转账,都会为缺口按每单位 100 sun 烧 TRX。按平均一天定的预算,遇到忙的一天就会用光。

您的余额盖不住下一天的预留时,规则会停下。它的 status 变成 paused,paused_reason 为 insufficient_balance,并发出一个 maintenance.paused 事件。暂停的规则永远不会自行恢复,充值也不会把它重新启动:它要等 PATCH /v1/auto-refill-rules/{rule_id} 带上 {"status": "active"},而余额仍盖不住的恢复,会得到 402。您自己设的暂停不带原因,所以 paused_reason 能区分一条在等钱的规则和一条在等您决定的规则。

低于 double 费率的预算会被拒绝,返回 422,details.reason 为 budget_below_topup_price,最低额放在 details.min_daily_budget_trx 里:第一次补能是 double,预算更小的规则会上线,却永远付不起它。

钱包上大约 131,000 单位,够两笔转给持有 USDT 地址的转账,或者一笔转给不持有的。在上一笔转账的补能落地之前就发出的转账,可能发现能量不够,于是有一部分、甚至几乎全部要用 TRX 来付。补能在一笔转账之后多快落地,我们没有量过。在一条规则的补能还没有抵偿我们为那个钱包预付的部分之前就删除它,要付未抵偿的那一部分,预付和扣费从 2026 年 11 月 6 日起算;暂停永远不会为此收费。

一个示例日,三种做法

把三种做法并排摆出来,取一个钱包、一天:三十笔付给已经持有 USDT 的地址,十笔付给不持有的地址。燃烧和质押是网络的算术。订单价格和补能费率是我们的,于 2026 年 10 月 27 日 21:46 UTC 从 GET /v1/tariff 读取;今天的在价格页上。

在那个钟点,订单合计比补能便宜,而这是常见的情形。截至同一个晚上的三十天按小时历史里,补能费率一次也没有变过,而同一笔转账的五分钟订单,在大多数小时里比它的补能便宜。

补能比订单多花的那部分,买到的是:每笔转账发出时钱包上已经有能量,以及一天最多能花多少的一个硬上限。预算和质押一样,要盖住忙的那一天,但清闲的一天剩下的部分会在 UTC 午夜回到余额。一条规则一天会补能多少次,我们没有生产环境的数字。

一次请求加上您自己定的每日预算,就能让一个付款钱包自己补能:API 参考文档里的 POST /v1/auto-refill-rules →