TRON API：通过 REST 进行 USDT-TRC20 支付

截至 2026 年 4 月，Tether 已发行约 1900 亿美元的 USDT。TRON 承载了其中约 45%，大约 850 亿美元，以太坊紧随其后约占 40%；自 2025 年末以来，这两条链已多次互换领先位置。在 TRON 内部，情况非常明确：2026 年第一季度，USDT 占该链稳定币价值的 98.6%。可以说，只要提到 TRC-20，在实际意义上基本就等同于 USDT。

发行量只是故事的一半。转账量才能说明一条链实际被用来做什么，而 TRON 的 USDT 转账量在 2026 年第一季度接近 2 万亿美元。以太坊上的 USDT 更多倾向于 DeFi 抵押品和机构结算。TRON 上的 USDT 则是人们真正在移动的那部分：交易所存款、跨境汇款、支付给承包商——在那些美元余额胜过本地银行账户的国家。

对于集成决策而言，结论很直白。如果你的用户从下拉菜单中选择存款网络，TRC-20 会是被选择最多的选项，当你的默认网络与用户预期一致时，因网络选错而产生的支持工单就会减少。先构建 TRON；上面提到的共享请求结构让你之后可以在不写新代码的情况下添加其他链。

TRON 计量两种资源。Bandwidth 覆盖普通转账，每天 600 点以内免费。Energy 没有免费额度，只要执行智能合约就会用到，这也是为什么一笔 USDT 转账——一次 TRC-20 合约调用——总是比发送普通 TRX 更贵。

TRON 没有单一的 gas 价格。网络计量两种独立的资源，了解你的交易消耗的是哪一种，正是可预测手续费与意外支持工单之间的区别。

Bandwidth 在每笔交易上都会计费，并按字节大小计算。每个账户每天获得 600 点免费额度；一笔普通 TRX 转账大约占用 250 到 300 字节，因此偶尔的 TRX 转账完全不花钱。超出免费额度后，网络会燃烧 0.001 TRX 每点，一笔典型的 TRC-20 转账大约合 0.35 TRX。

Energy 只在执行智能合约时才会用到，且没有每日免费额度。一笔 USDT 转账是一次合约调用，TRC-20 合约要更新其内部余额表，因此除了 Bandwidth 外还需要 Energy。自 2025 年 8 月第 104 号治理提案生效以来，一单位 Energy 的价格为 100 Sun，比之前的 210 减半。发送给已经持有 USDT 的地址大约消耗 64,000 Energy，折合 6.4 TRX。发送给从未持有过 USDT 的地址会写入一条新的存储记录，而新状态所需的 Energy 大约是更新操作的两倍：约 134,000 单位，即 13.4 TRX。

在发送之前，有两个工具能把这些数字具体化。TRON 手续费计算器会为某一笔具体转账计算出 Bandwidth、Energy 以及以 TRX 计的总额，而 GET /api/v2/tron/chainparameters 返回实时单价，让你的代码永远不会把某个常量硬编码进去，等着下一次治理投票让它失效。手续费指南深入介绍了这些机制。

每一笔 TRC-20 转账都需要 Energy，而这些 Energy 必须有个来源。对大多数发送方来说，来源就是自己的 TRX 余额。这个假设在两种常见情况下会失效，而在你从结构上解决之前，这两种情况都会带来运维上的痛苦。

你自己的存款钱包群

每一个向热钱包转发资金的钱包都需要自己的 TRX 余额来支持清扫操作，而当钱包数量达到几千个时，充值本身就变成了一项工作，还带有充值转账本身的手续费成本。代付手续费消除了这项工作。目前推荐的搭建方式是 TronFuel，它从质押者那里批量租用 Energy——手续费指南将这一机制描述为相比按市场价燃烧 TRX 能降低多达 60% 的手续费成本。Chaingateway 的旧版 Paymaster 接口做的是同样的事，并继续为现有集成保留。

你的终端客户

某个用户的自托管钱包中持有 200 USDT，TRX 余额为零；这些 USDT 来自交易所或另一个人，没有人告诉过他移动这笔钱还需要第二种货币。当他试图向你付款或提现时，转账失败。从用户的角度看，钱被卡住了。从你的支持队列角度看，这是一张任何 FAQ 条目都无法彻底解决的重复工单，因为解决方案——「先去交易所买点 TRX」——恰恰是客户使用稳定币想要避免的那种摩擦。代付转账终结了这个问题：你提交转账，代付方承担 Energy 和 Bandwidth，成本计入你的账户，客户永远不需要知道 TRX 是什么。对收银和提现流程而言，这一项改动就能消除 TRC-20 支付中最常见的失败模式。

估价并创建一笔代付转账

先为一笔代付交易估价，再创建它：

# 1. 估算手续费
curl -X POST https://app.chaingateway.io/api/v2/tron/paymaster/estimate \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"type": "TRC20", "contractaddress": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t", "from": "TDepositWallet", "to": "THotWallet", "amount": "500"}'

# 2. 创建 Paymaster 请求
curl -X POST https://app.chaingateway.io/api/v2/tron/paymaster \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"type": "TRC20", "contractaddress": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t", "from": "TDepositWallet", "to": "THotWallet", "amount": "500", "password": "YourWalletPassword"}'

GET /api/v2/tron/paymaster 列出你创建的每一个请求，并报告其状态（从 pending 到 completed 或 failed），GET /api/v2/tron/paymaster/balance 显示你剩余的代付额度——两者结合即可完成对账。

导入私钥是通往生产环境最快的路径，但有些团队完全无法把密钥材料发送给第三方。原因可能是内部政策、监管要求，或者硬件安全模块本身在物理上就无法导出密钥。TRON API 有第二种模式，正是为这种约束而设计。

该流程分三步。使用你原本用于普通发送的相同字段，调用 POST /api/v2/tron/transactions/trc20/build（普通 TRX 则调用 /api/v2/tron/transactions/build）。API 返回未签名的原始交易。在你密钥所在的地方对这份 payload 进行签名：HSM、隔离机器，或部署在你自己防火墙后的签名服务。然后通过 POST /api/v2/tron/transactions/broadcast 提交签名结果，它会把交易推送到网络并返回交易哈希。

# 1. 构建未签名交易
curl -X POST https://app.chaingateway.io/api/v2/tron/transactions/trc20/build \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"contractaddress": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t", "from": "TColdWallet", "to": "TRecipient", "amount": 1000}'

# 2. 用自己的工具本地签名，然后广播
curl -X POST https://app.chaingateway.io/api/v2/tron/transactions/broadcast \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"signed_transaction": "<以 JSON 字符串形式的已签名交易>"}'

选择这种模式前有两点需要了解。构建好的 TRON 交易会在一个较短的窗口后过期，因此签名和广播这一步需要及时完成，而不能放在队列里过夜。运维责任也会随之转移：签名库及其更新由你自己负责。你换来的是 Chaingateway 永远不会看到你的密钥。存款监控在两种模式下都不受影响，因为监控地址本来就不需要密钥。许多生产环境会混合使用两种模式：低价值运营钱包用导入密钥，资金库路径用自签名。

轮询区块浏览器来查找传入转账既浪费请求，时机也总是不准。Chaingateway 改为主动推送。注册一个 Webhook，你的后端就会收到关于交易状态、确认数和余额变化的 POST 请求。在你的账户中设置一个私密密钥后，每次投递都会携带一个 X-Signature 请求头——对 payload 中的 txid 做 HMAC-SHA256 并以 base64 编码——让你可以验证发送方。投递失败的会进入失败通知列表，POST /api/v2/tron/webhooks/notifications/{id}/retry 可以重新发送其中任意一条。

GET /api/v2/tron/webhooks/notifications 返回历史通知，在部署失败后需要重放事件时很有用。参照 Webhook 指南，几分钟即可完成设置。

高交易量的发送方不应该永远燃烧 TRX。通过 POST /api/v2/tron/freeze 冻结 TRX，网络会返还相应的 Bandwidth 或 Energy；再通过 POST /api/v2/tron/delegate 把这些资源分配给你的热钱包。当你想要收回资金时，解冻和取消委托会逆转这两个步骤。

当前的资源价格来自 GET /api/v2/tron/chainparameters。自第 104 号提案生效后，Energy 单价为 100 Sun，从之前的 210 降低，这改变了质押与燃烧之间的收支平衡点。在你确定质押规模之前，请先查看实时数值。

随着交易量增长，算账会更倾向于质押，因为被燃烧的 TRX 消失了，而被质押的 TRX 只是被暂时搁置。按 2026 年年中的粗略数字，大约 5,000 TRX 的质押量每天能产生大约一笔 USDT 转账所需的 Energy。一家每天发送 50 笔转账的企业，需要几十万 TRX 量级的质押才能完全靠质押覆盖其 Energy 需求。请把这些当作数量级参考而非精确报价：你每日的收益取决于整个网络已质押的 TRX 总量，而这个比例会漂移。手续费计算器和链参数接口能为这个计算提供当下的输入数据。

委托机制是让质押在运维上保持整洁的关键。把质押放在一个从不接触客户流量的资金库地址上，然后用 delegate 把它的 Energy 分配给真正执行发送操作的热钱包。当某个钱包被淘汰时，取消委托并把资源指向它的继任者；被质押的 TRX 本身从不移动。资金库规划中有一个注意事项：解冻后，TRX 会被锁定大约两周的等待期才能重新使用，因此质押并不是可即时取用的储备。按稳态交易量确定质押规模，用租用的 Energy 来覆盖突发峰值。

Chaingateway 支持 TRON 上的标准代币类型。USDT、USDC 和 DAI 开箱即用，自动处理小数位。对于你自己发行的代币，传入其合约地址，API 会像对待其他任意 TRC-20 代币一样对待它。请求结构在各链之间是共享的，因此以太坊、BNB Smart Chain、Polygon 或 Arbitrum 上的 ERC-20 调用，看起来和你的 TRC-20 调用完全一样，只是路径段不同。

该网络的设计目标是大约每秒 2,000 笔交易，非常适合由大量小额转账组成的支付负载。手续费足够低，使得微支付依然可行——每笔代币转账只需几个 TRX，而不是让手续费吃掉整笔支付。TRON 持有的流通中 USDT 份额高于任何其他链，因此你的用户所对接的交易对手大多已经在那里，围绕 TRC-20 的钱包生态也足够成熟，工具链很少成为阻碍。

典型的集成场景是这样的：接受 USDT 并在确认后为订单入账的收银流程；监控数千个存款地址并从热钱包处理提现的交易所后端；执行空投或归属计划的付款系统；每月以稳定币计费的订阅账单；在数分钟内实现跨境价值转移的汇款服务。同一个 API 覆盖每一种模式。变化的只是你组合使用哪些接口。

本页每一个接口都接受 X-Network: testnet 请求头。加上它，完全相同的请求会运行在 TRON 测试网上：相同的路径、相同的 payload、相同的响应结构。测试用 TRX 可以从公共水龙头免费获取，因此一次完整的演练不花任何成本——创建一个存款地址，向它发送一笔 TRC-20 转账，接收 Webhook，验证 HMAC 签名，清扫进热钱包。

至少完整走一遍 Webhook 路径。典型的集成错误——针对错误的 payload 编码做签名校验，或者防火墙悄悄丢弃了投递——在测试网上的表现和在生产环境中完全一样，只是在生产环境中它们的代价是真实存款而不是测试代币。之后上线只需删除一个请求头；快速入门展示了完整的周期。

两类失败需要相反的处理方式。4xx 响应意味着请求本身有问题：Bearer 令牌缺失或过期、地址格式错误、发送钱包无法覆盖的金额。记录并修正原因，但不要原样重试，因为相同的输入会得到相同的拒绝。5xx 响应或网络超时并不能说明你的输入有任何问题；用指数退避和上限对它们进行重试。

值得专门为之设计的边界情形，是发送之后出现的超时。你的 HTTP 客户端放弃了，但交易可能其实已经被广播出去。凭直觉再发一次相同的转账，正是重复付款的成因。先检查实际发生了什么：GET /api/v2/tron/transactions 列出了通过你的账户创建的转账。只有在能确认第一次尝试确实失败时，才重新发送。对于与手续费相关的失败，还有一种更省事的模式：在发送前检查 GET /api/v2/tron/chainparameters 和钱包的资源，把一个运行时错误变成一次预检查。