TRON 能量什么时候最便宜
TRON 能量什么时候最便宜,答案是一个钟点,不是一个数字。我们的售价费率按一天中的时段切开,而一个时段内部的价格每五分钟就跟着市场重算一次,所以任何单独一个小时值多少钱,都是在动的。动得少的是一天的形状:在截至 2026 年 9 月 7 日的三十天逐小时历史里,几乎每天便宜的都是同一段时间——UTC 01:00 到 12:00,其中 06:00 开始的那个小时最便宜。下面就是那张地图,以及一个付款团队拿它能做什么。
边界在 UTC 上落在哪里
GET /v1/tariff 是公开的,不要密钥,它的 reference_schedule 就是把一天切成的那些区段,按一天中的时间排好。按今天的切法:谷段从 01:00 到 12:00,平段占着两头的肩部,00:00 到 01:00 和 12:00 到 14:00,峰段从 14:00 到午夜。时段的名字是一个价格带,不是一段时间——standard 占着彼此分开的两个区段,所以一行是靠它的起止时刻来认的,不是靠它的 zone。
有两个字段能省掉您自己那边的钟表算术。有且只有一行带着 active: true,那就是此刻正在跑的区段;next_change_at 是它结束的时刻,而这个答复的缓存寿命绝不会长过到那一刻还剩的时间。请读这两个字段,而不是拿您自己的钟去对那张表。
时刻表其余的部分是一份记录,不是一份预报:每个区段,包括正在跑的那个,都带着它上一次跑完时实际算下来的数,而 avg_basis 会说到底有没有测到过东西——刚改过时刻表时它是 none,那时数字是 null,而不是编出来的。这里面没有一样是对以后的报价——唯一作数的价格,是订单创建时定进这个订单的那个。
三十天的历史看到了什么
GET /v1/tariff/history?range=30d 回的是 720 个点,每小时一个,没有缺口也不分页。把一天二十四个小时各自在截至 2026 年 9 月 7 日的三十天里取平均,就得到一份一目了然的排名。这个窗口的前一半在自动重定价之前,那时每个时段都停在一个固定的数上;后一半是重定价之后的,而那个形状两半都还在。
一天里最便宜的十一个小时,无一例外就是谷段窗口的那十一个小时。单独最便宜的是 UTC 06:00 开始的那个小时,05:00 紧随其后,05:00 到 09:00 这一整个早晨挤得很近。从那里价格一路爬过正午的肩部,而从 14:00 到午夜,它坐在一块平台上,每个小时和别的每个小时都只差一丝:最贵的单个小时是 15:00,晚间较晚的那几个小时和它齐平。异类是午夜之后的那个小时——名义上是 standard,平均下来却比正午两个小时都贵,而且离峰段近得多。
换成比例来说,这也是值得带走的那种形式:在那三十天里,谷段窗口平均下来大约是网络烧掉同样能量所收的四分之一,峰段窗口大约是三分之一。峰段比谷段大致是四比三,所以把一个批量从傍晚挪到早晨,大约能省下本来会被收走的四分之一。这是一个月量出来的;不是对明天的承诺。
同一批数据里还带出两条要当心的话。它是一种倾向,不是一张时刻表:在二十九个完整日里,有二十七天当天的最低价出现在谷段内部的某处,也就是说有两天不是。而且一天里的一个小时并不等于一个价格——最便宜那个小时的各次读数,散布的宽度超过谷段和峰段之间的平均差距。周末比工作日略低一点,但只低了昼夜差距的一个很小的零头,不足以拿来排班。
一天为什么是这个形状
只说能站得住的部分。边界是我们定的,它们移动是有明说的理由的:上一次重切是在 2026 年 8 月 17 日,把 UTC 20:00 到午夜那一段——也就是我们回退时会用到的那些卖方自己处在最贵档位的那些小时——从 standard 挪进了 peak。那是在我们这一侧量出来的供给成本,不是关于谁在哪里醒着的理论。一个时段值多少钱,和它什么时候跑,是两套不同的机制:时刻表回答的是什么时候,而它里面的价格每隔几分钟就跟着市场重算一次。
这个轮廓也不只是我们的,虽然这一点分量有限。我们盯着的卖方里,有一家公布的是一条价格曲线而不是单个数字,2026 年 9 月 3 日读到它时,它最便宜的那一档落在 UTC 的清晨,最贵的那一档从下午晚些时候一直到午夜——同样的形状,由别人得出。再往下我们就找不到可以引用的成因了,所以我们不下断言。
一个付款团队拿它做什么
能等的就挪。一个订单的价格在它被创建的那一刻就定死了,所以值得排的是那一刻。发薪、结算、给供应商打款、归集——凡是期限以小时而不是以秒计的,都是候选,而且最多 500 笔转账可以作为一个订单、按一个价格进去。
别去给一个热钱包排班。钱包整天都在发,就没有什么可挪的,这时候换成一条 Auto-refill 规则,每笔转账之后把它补回来。动手之前有一件事要知道:补能费率不是时段价格。它是一个单独的产品,有它自己的价格,完全不跟着这份时刻表走,所以把一个钱包的流量挪到早晨,对它的补能花多少钱毫无影响。
自己画一张。上面所有东西都出自两个不要密钥的公开请求。range 收 24h、7d 或 30d,而且只有它决定答复的大小——永远是 24、168 或 720 个点。
curl -s 'https://api.nrg.market/v1/tariff/history?range=30d' # 720 个逐小时的点:t、zone、price_sun、maintenance_price_trx
您自己的流量不是我们的平均值,而您自己一个月的那些小时,是比这张更好的地图。
盯边界,别盯钟。next_change_at 是正在跑的这个区段结束的时刻,该拿它来唤醒任务。一个钉死在某个小时上的任务,会在切法改掉的那天悄悄出错——时刻表是参考,它可以变,而 API 的版本不必跟着变。
这个页面没有说的
能量此刻在这里值多少钱。那个数字每隔几分钟就动一次,而打进一篇文章里的数字,在文章被读到之前就已经过期,所以本站没有哪个页面公布它。实时价格、此刻在跑的时段和历史图都在价格页上;我们的价格相对于别家卖方自己公布的数字站在哪里,在行情页上,每一行都盖着读到它的那一刻。比较的另一边不动:账户拿不出来的每一单位能量,网络都按 100 sun 烧掉,转给已经持有 USDT 的地址大约要 65,000 单位,也就是 6.5 TRX——上面每一个比例,量的都是它。