冷热地址混合
一次工资或分润批次既会命中已持有 USDT 的地址，也会命中全新地址——按地址类型为每个收款方匹配合适的能量包。
API 文档维护在 docs.eopen.io
完整 endpoint、字段、鉴权、幂等键与 webhook 回调说明以外部文档为准。 打开 API 文档 →
EOPEN
出款/批量代付系统 TRON 能量 API
在大额 USDT 批量出款（工资发放、商户结算、联盟分润）开始前预置能量，支持幂等下单、可预测的单笔出款成本，以及 tx hash 加 webhook 对账。
规划出款批次面向大额批量出款的能量供给
为冷热地址混合的批量场景设计
EOPEN 让出款与代付平台为整批运行预置能量，使一次包含数千笔 USDT 转账的批次在其 P99 时延窗口内完成，而不会有任何钱包因手续费不足而中断。
批量
单批数千笔
幂等
安全重试
P99
结算时延
Webhook
对账回调
出款系统适配点
单笔成本可预测
在批次开始前锁定每个收款方的链上费用，财务可精确到分地核算批次成本，而无需为燃烧尖峰预留缓冲。
幂等且重试安全
为每笔能量订单绑定出款 ID，让重试或部分失败的批次绝不会重复委托或重复付款。
01
一个批次的速度取决于最慢的那笔出款
出款平台被考核的是 P99 结算时延，而非中位数。如果某个钱包在批次进行中耗尽能量，该笔出款就会重试，整批运行被拖偏，收款方随之提交工单。为整批预置能量，可把手续费这个变量从你的时延预算中剔除。
- 在批次开始前为完整收款名单预置能量。
- 每笔委托均可在 TRON 链上查验，便于对账。
- 通过 webhook 回调将每笔出款标记为已结算或失败。
02
失败出款的幂等与重试
在代付系统里，最危险的失败是含糊不清的失败：这笔转账到底成功了没有？EOPEN 的订单携带你的出款/批次 ID，重试时复用同一意图，而 tx hash 让财务在与账本核对时拥有唯一可信来源。
- 为每笔能量订单附上出款 ID / 幂等键。
- API Key 可按批次、地区或业务线拆分。
- 以 tx hash 与 webhook 对账，而非靠猜测。
03
出款批次的成本算例
以一批 10,000 个收款方的出款运行为例：70% 为热地址（已持有 USDT，每笔约 64,285 能量），30% 为冷地址（全新 / 零余额，每笔约 130,285 能量）。若直接燃烧 TRX，大致为 6.4 TRX × 7,000 加上 13 TRX × 3,000 ≈ 单批 83,800 TRX 手续费。改为租赁对应的 65,000 与 131,000 能量包，每笔分别压到约 1.5 TRX 与 3.5 TRX ≈ 21,000 TRX——最高可省 80%——并在批次发车前就已锁定。
- 热地址收款方（已持有 USDT）：65,000 能量（每笔约 6.4 → 1.5 TRX）。
- 冷地址收款方（全新 / 零余额）：131,000 能量（每笔约 13 → 3.5 TRX）。
- 准备一个 500,000 能量批量包覆盖整批，于运行开始前一次性委托。
下一步
为下一次运行规划合适的批量包，为每笔订单绑定出款 ID，把链上费用挡在你的 P99 结算预算之外。
API 接入核心
- 1用出款系统的 API 密钥认证，并为调用打上批次 ID。
- 2按收款方构成报价——热地址用 65,000 能量、冷地址用 131,000，或用一个 500,000 能量批量包覆盖整批。
- 3提交幂等订单（以出款 ID 为键），并在运行开始前把能量委托至出款钱包。
- 4在 P99 窗口内发车出款，随后按 tx hash 与 webhook 回调逐笔对账。
出款常见问题
冷热地址混合的批次该怎么处理？
按地址类型为每个收款方报价——已持有 USDT 的用约 65K 包，全新零余额的用约 131K 包；也可以用一个按整批容量定制的批量包。
出款失败后能量订单可以安全重试吗？
可以。把出款或批次 ID 作为幂等键，重试时复用同一意图。在重发前用 tx hash 与 webhook 回调确认是否已结算。
如何与财务对账一次运行？
每笔能量委托与转账都可在 TRON 链上查验。把 tx hash 与每条出款记录一起保存，并让 webhook 回调驱动账本中的已结算/失败状态。
迁移与可验证性
为什么旧 docs 和新 docs 字段名不一样？
字段命名、幂等键与 webhook 回调说明以 docs.eopen.io 为准。站内页面只保留出款场景概览。