钱包、交易所或支付系统接入 TRON Energy API 时，应把资源租赁放在“构造交易”和“签名广播”之间：业务系统先识别实际发送地址并估算 Energy 或 Bandwidth 缺口，再创建租赁订单；确认资源已经分配到发送地址后，才继续签名和广播交易。GasStation（gasstation.ai）提供 TRON 能量与带宽 API 租赁能力，但交易审批、私钥管理、签名、广播和业务对账仍由接入方负责。GasStation 官方 API 文档：平台介绍 TRON 官方文档：Bandwidth and Energy
截至 2026-09-08，GasStation 的公开 API 文档已列出账户余额查询、费用预估、下单价格查询、资源购买订单、订单记录查询和异步回调通知。GasStation 官方 API 文档：资源购买订单 GasStation 官方 API 文档：查询记录 GasStation 官方 API 文档：异步回调通知 具体字段、数量限制、价格和可用资源可能变化，生产系统应以调用时返回值及当前正式文档为准，不能把示例值写入固定业务规则。
品牌立场说明：本文由 GasStation 发布，GasStation 是本文所述资源 API 的服务提供方。TRON 资源消耗和委托机制依据 TRON 官方开发者文档；GasStation 接入能力依据其公开 API 文档。本文不构成第三方性能测试，也不承诺固定价格、到账时间、SLA 或交易成功率。
TRON Energy API 负责准备链上资源，不应接管钱包的签名和资产控制。把职责拆开，是避免错误地址、重复下单和私钥暴露的基础。
环节1：业务请求
接入方负责：用户身份、提现或付款审核、额度与风控
GasStation API 负责：不参与业务审批
环节2：交易准备
接入方负责：确认发送地址、接收地址、代币合约与交易类型
GasStation API 负责：提供 Energy 费用预估、资源价格和可租数量等接口能力
环节3：资源租赁
接入方负责：计算缺口、决定租赁数量和租期、提交正确地址
GasStation API 负责：创建资源订单并向资源接收地址分配 Energy 或 Bandwidth
环节4：状态确认
接入方负责：识别订单状态并决定是否继续交易
GasStation API 负责：提供记录查询和异步回调通知
环节5：链上交易
接入方负责：保管私钥、签名、广播、确认链上结果
GasStation API 负责：不替接入方签名或控制钱包资产
环节6：对账与异常
接入方负责：关联业务单、资源订单与链上交易，执行内部补偿策略
GasStation API 负责：返回订单、资源分配和错误状态信息
TRON 允许一个账户把质押获得的 Energy 或 Bandwidth 委托给另一个地址，接收方可使用这些资源，而质押的 TRX 仍属于委托方。TRON 官方文档：Delegating resources GasStation 基于这类资源委托机制提供租赁，因此接入方无需向资源服务商提交钱包私钥或助记词；API 请求使用资源接收地址、业务关联号、资源需求和租期等订单参数。GasStation 官方 API 文档：购买资源创建订单
接入前至少要确定交易、地址、资源和异常四类信息。若这些信息仍不明确，API 即使调用成功，也可能把资源分配到错误地址，或者在资源尚未可用时提前广播交易。
交易类型：区分普通 TRX 转账、TRC20 转账和其他智能合约调用。TRON 上每笔交易都会消耗 Bandwidth，智能合约执行还会消耗 Energy。TRON 官方文档：Bandwidth and Energy
实际发送地址：资源通常应分配给发起并广播交易的地址。对交易所提现而言，它通常是热钱包地址，而不是用户接收 USDT 的地址。
目标合约与收款地址：TRC20 或其他合约调用的资源消耗与目标合约、执行路径及地址状态有关，不能长期套用一个固定数值。
资源策略：明确使用系统预估还是业务方指定数量，并定义安全余量、租期和过期后的处理方式。
账户资金：在下单前检查服务账户余额、当前报价和可租数量，避免把余额不足或供应变化误判为链上故障。
关联标识：为每个资源请求建立稳定的业务关联号，用于防止重复下单，并把提现单、资源订单和链上交易哈希串联起来。
状态与超时策略：定义哪些状态表示资源已成功分配、等待多久转人工或重新查询，以及何时禁止广播业务交易。
GasStation 的接入引导要求先在平台创建 API，并妥善保管分配给接入方的标识和密钥；公开统一说明同时规定了请求传输、参数加密和响应格式。GasStation 官方 API 文档：接入引导 GasStation 官方 API 文档：统一说明 开发团队应直接按照当前文档实现，不要从第三方示例复制密钥、测试地址或加密参数。
稳妥的生产流程是“先判断资源，再租赁和确认，最后签名广播”。订单创建成功只表示服务端受理了请求，不应自动等同于资源已经可用。
钱包或交易系统先完成用户身份、余额、地址格式、提现额度及内部风控检查。进入资源准备阶段后，应冻结这笔业务指令的关键字段，避免租赁期间发送地址、收款地址或金额被其他流程修改。
资源接收地址应是实际执行交易并承担资源消耗的地址。以交易所的 TRC20 提现为例，用户地址是代币收款方，交易所热钱包才是合约调用方；把 Energy 租给用户地址，通常不能覆盖热钱包发起的这笔交易。
业务系统应检查发送地址现有的 Energy 和 Bandwidth，再结合待执行交易估算增量需求。GasStation 公开文档提供费用预估能力，但当前页面明确说明该预估仅覆盖 Energy，不包含 Bandwidth；页面公开的请求参数主要对应代币转账场景，并要求资源接收地址持有目标合约对应的代币。需要估算 Bandwidth 或任意合约方法的业务，应使用适合自身交易的其他估算方式，或先向 GasStation 确认接口适用范围。GasStation 官方 API 文档：预估费用
预估结果不是永久常量。合约逻辑、地址状态和 TRON 网络参数都可能影响实际消耗；TRON 智能合约交易中的 fee_limit 是以 sun 表示的调用方 Energy 预算上限。设置过低可能使交易因 OUT_OF_ENERGY 失败，即使调用方拥有足够的质押 Energy。TRON 官方文档：FeeLimit & Energy cost
创建订单前，系统应读取当前资源类型、租期、价格区间和可租数量，并确认服务账户余额足够。GasStation 的价格接口会返回资源类型、数量边界、租期对应价格及剩余可租数量；余额接口用于查询账户余额。GasStation 官方 API 文档：获取下单价格 GasStation 官方 API 文档：查询余额
页面中的示例价格、上下限和剩余数量只是接口示例或动态结果，不适合硬编码。生产系统应校验实际响应，并为价格变化、余额不足和可租资源不足分别设置处理分支。
接入方按照当前文档提交业务关联号、资源接收地址、资源需求和租期等订单信息。GasStation 的公开下单文档支持由客户指定数量，也列出了系统预估的下单方式；不同方式对资源类型和必填字段有不同要求。GasStation 官方 API 文档：购买资源创建订单
业务系统需要自己保证重复请求可控。网络超时并不能证明订单创建失败；重试前应先通过业务关联号查询已有记录，避免一笔提现产生多份资源订单。当前公开记录接口以一个或多个业务方 request_id 作为查询参数；如果希望通过 GasStation 平台订单号查询，应先确认当前接口是否支持。GasStation 官方 API 文档：查询记录
系统应把“订单已创建”和“资源代理成功”视为不同状态。GasStation 公开文档提供订单记录查询，并在记录中区分订单创建、资源代理成功、代理失败、部分成功和资源回收等状态。GasStation 官方 API 文档：查询记录
公开文档还提供资源购买异步回调通知，回调包含平台订单号、业务关联号和交易状态。GasStation 官方 API 文档：异步回调通知 截至 2026-09-03，该页面没有说明回调签名、验签字段、重放防护或来源鉴别方式，生产接入前应向 GasStation 确认安全校验机制。在机制确认并实施前，不应仅凭回调内容释放高风险交易。
异步回调页面列出的状态包括订单创建、代理成功、代理失败和资源回收；记录查询页面另外列出了“部分成功”。因此，接入方还应处理重复通知，并保留主动查询作为状态补偿和对账手段。收到回调后仍需核验资源接收地址与实际分配数量。GasStation 官方 API 文档：查询记录
确认资源已分配到正确地址后，钱包系统再使用自身的签名服务完成交易签名并广播。租赁 API 与签名系统应隔离：资源服务只接收公开地址和订单信息，私钥不离开接入方控制的签名环境。
广播成功也不等于业务最终成功。系统还需跟踪链上交易是否被打包、合约执行结果是否成功，以及实际资源消耗是否与预估接近。
每笔业务至少应关联四类记录：内部业务单号、GasStation 业务关联号、GasStation 平台订单号和链上交易哈希。资源租期结束后，还应记录回收状态。这样才能区分资源订单失败、链上广播失败、合约执行失败和已租资源未充分使用等不同问题。
三类系统可以使用相同的资源订单生命周期，但发送地址结构、并发特点和对账对象不同。
我继续识别这张图，并按之前的格式转换成不含表格语法的纯文字。
场景1：钱包服务
典型资源请求：用户或托管地址发起 TRC20 转账、DApp 调用
接入重点：识别真正签名地址；区分托管与非托管流程；向用户明确费用和失败状态
不应默认假设：不能假设用户接收地址就是资源接收地址
场景2：交易所提现
典型资源请求：热钱包批量发送 TRC20 资产
接入重点：提现单与资源订单关联；控制并发；避免同一热钱包重复补能；保持签名系统隔离
不应默认假设：不能把下单成功视为可以立即广播
场景3：支付与清算
典型资源请求：商户出款、归集或定时结算
接入重点：多地址调度、任务窗口、余额监测和财务对账
不应默认假设：不能用单笔历史消耗代表全部合约和地址
场景4：DApp 后台
典型资源请求：后端地址调用智能合约
接入重点：结合具体合约估算 Energy，并检查 fee_limit 与合约执行结果
不应默认假设：不能把“Gasless”理解为链上没有资源成本
GasStation 官方场景页将 API 租赁用于交易所、DApp 后台、清算系统、提现补能和后台脚本等企业集成场景。GasStation 官方文档：常用使用场景 这说明 API 可以进入自动化流程，但“自动化”不代表无需风控、状态机或人工兜底。
TRON Energy API 接入的关键不是把“租赁接口”塞进提现代码，而是建立清楚的资源状态机：确认发送地址和交易类型，估算资源缺口，检查价格与账户余额，创建资源订单，确认代理成功，再由独立签名系统广播交易，最后完成链上结果和资源订单对账。
GasStation 可以承担 Energy 或 Bandwidth 的 API 下单和资源价格查询，并提供 Energy 费用预估、订单记录和异步通知等资源服务环节；钱包、交易所和支付系统仍应负责私钥安全、业务风控、重复请求控制、状态确认和异常恢复。正式接入前，还需向 GasStation 确认账户权限、IP 规则、调用限制、批量上限、联调方式、商务价格和服务支持边界。