跳转到主要内容
Tron 是受支持的 Intents 链(链 ID 728126428,CAIP-2 tron:728126428)。Tron 运行与 EVM 兼容的 VM,因此 在协议内部,订单看起来与 EVM 完全相同——相同的 StandardOrder 和 MandateOutput 结构,相同的、左填充到 bytes32 的 20 字节地址。 差异出现在边缘处:如何在 HTTP 边界处编码地址、你与哪些合约地址交互、存在哪些结算类型,以及如何提交源交易。本页是一份差异参考——对于每个关注点,说明 EVM 的做法以及 Tron 的替代做法。
关于 LI.FI 各产品对 Tron 的通用(非 Intents)支持,请参见 Tron 生态系统页面。

概览


报价

Tron 由标准报价端点 POST /api/v1/integrator/quote/request 提供服务。它接受 CAIP-2 链外加 原生 地址,因此你以 base58(T…)形式传入 Tron 地址,并以 base58 形式取回。完整的请求参考和一个 Tron 示例见请求报价。 响应会将 Tron 地址以 base58 形式渲染返回。对于源链在 Tron 的订单,其源交易在 order.openIntentTx 下返回:
反方向(EVM → Tron)的做法相同——把 Tron 这一端放在 outputs 中,使用 chain: "tron:728126428" 和 base58 地址。 如果你改用旧版 V0 的 POST /quote/request 端点(EIP-7930),那么可互操作地址必须编码 tron CAIP-2 命名空间,并嵌入 Tron 地址的 20 字节 形式(见边界处的地址格式)——并且该端点的 supportedTypes 采用的是结算类型词汇(在 Tron 上仅为 ["oif-escrow-v0"]),而不是 oif-user-open-v0。更推荐使用标准端点,或使用 interoperable-addresses 库构建 EIP-7930,而不是手动编码。

边界处的地址格式

一个 Tron base58 地址(T…)由一个 0x41 版本字节加上 20 字节账户组成,并包裹在 base58check 中。协议只会看到那 20 字节账户——0x41 版本字节和 base58 校验和只存在于面向人类的封装中。
  • 报价端点(V1): 传入 base58(T…)。也接受带 0x 前缀的 20 字节十六进制。响应始终渲染为 base58。
  • 旧版 V0 端点(EIP-7930): 嵌入的地址是 20 字节形式(base58 解码后,去掉 0x41 和校验和)。
  • 链上 / 订单结构中: 20 字节十六进制,左填充到 bytes32——与 EVM 完全相同。
使用 bs58check 在两种形式之间转换:

传输格式与 EVM 相同

一旦地址处于 20 字节十六进制形式,下游的任何环节都不会改变。StandardOrder 和 MandateOutput 结构、bytes32 左填充(tokenId/oracle/settler/token/recipient)以及 calldata 编码,在 Tron 上与在 EVM 上完全相同。0x41 版本字节永远不会出现在链上。如果你的 EVM 订单构造代码已经能够生成正确的结构,那么在 Tron 上唯一需要改动的就是在边界处转换地址,并通过 TronWeb 提交。

结算:仅托管(Escrow)

Tron 仅支持 托管(Escrow) 输入结算器。Tron 上 没有 Compact / The Compact / 资源锁 流程。相应后果:
  • 在旧版 V0 的 POST /quote/request 端点上,只请求 ["oif-escrow-v0"]——绝不要用 oif-resource-lock-v0。
  • Compact 订单指南不适用于 Tron。

开启订单:仅限链上

Tron 订单通过使用报价中的 openIntentTx 直接调用托管输入结算器来 在链上 开启。订单服务器和求解器会自动检测由此产生的链上事件。 POST /orders/submit(链下 / 无 gas 提交)仅限 EVM——不存在 Tron 的无 gas 路径。

合约地址

这些 不是 EVM 链上使用的确定性 0x0000… 地址。Tron 没有无密钥的 CREATE2 工厂,因此这些部署位于唯一的、Tron 专用的地址上。
本文档其他地方所述的”在所有受支持链上使用相同地址”仅适用于 EVM 链。不要在 Tron 上向 EVM 的 0x0000… 地址发送资金——它们在那里并不存在。

链上提交(TVM)

报价的 openIntentTx.data 是完整的 ABI calldata(函数选择器 + 参数),以 0x 十六进制字符串形式给出——它 不是 一笔可直接广播的 EVM 交易。Tron 客户端必须将其包裹在 TriggerSmartContract 信封中,该信封受 TAPOS 约束(它通过 ref_block_* / expiration 引用一个近期区块),然后对其签名并广播。
  • openIntentTx.to 是结算器的 base58 地址。
  • openIntentTx.feeLimit 是 以 SUN 计的能量花费上限,而非估算值。
  • 代币授权使用 TRC-20(而非 ERC-20)。
订单开启后,通过订单状态 API 以与 EVM 订单相同的方式追踪它。

预言机

对于 跨链 Tron 输出,订单使用 Polymer;MandateOutput.oracle 是 Tron PolymerOracle(TPXQkHcGwEdH4Ss8kT4cDxgXt3L4n4zSHJ)的 bytes32。对于 同链(Tron → Tron)意图,OutputSettler 充当预言机,如同链意图所述。有关 Polymer 证明的工作原理,请参见预言机系统。

面向求解器

填充一个 Tron 输出的方式与 EVM 交付相同:在 Tron OutputSettler 上调用 fillOrderOutputs。唯一 Tron 特有的一步是通过 TronWeb 提交,并使用上文的 20 字节规则解码地址。 关于通用的填充流程,请参见求解 LI.FI Intents。

后续步骤

请求报价

Exact-input/output 报价以及 Tron 请求示例

创建并提交订单

构造 StandardOrder 并在链上开启它

预言机系统

Polymer 及其他验证系统

求解 LI.FI Intents

求解器如何交付输出