Tron vs EVM

Tron 是受支持的 Intents 链（链 ID 728126428，CAIP-2 tron:728126428）。Tron 运行与 EVM 兼容的 VM，因此 在协议内部，订单看起来与 EVM 完全相同——相同的 StandardOrder 和 MandateOutput 结构，相同的、左填充到 bytes32 的 20 字节地址。差异出现在边缘处：如何在 HTTP 边界处编码地址、你与哪些合约地址交互、存在哪些结算类型，以及如何提交源交易。本页是一份差异参考——对于每个关注点，说明 EVM 的做法以及 Tron 的替代做法。

关于 LI.FI 各产品对 Tron 的通用（非 Intents）支持，请参见 Tron 生态系统页面。

概览

关注点	EVM	Tron
推荐的报价端点	`POST /quote/request`（EIP-7930）	`POST /api/v1/integrator/quote/request`（原生地址）
地址格式——请求	`0x` 十六进制（或 EIP-7930）	base58 `T…`（CAIP-2 链）；也接受 `0x` 20 字节十六进制
地址格式——响应	`0x` 十六进制	base58 `T…`
结算类型	托管（Escrow）和 Compact	仅托管（Escrow）
订单开启路径	链上开启或无 gas 的 `POST /orders/submit`	仅限链上开启
合约地址	确定性的 `0x0000…`，在所有 EVM 链上一致	唯一的 base58，Tron 专用（见下文）
提交库	ethers / viem	TronWeb（`TriggerSmartContract` 信封）
源费用单位	gas（wei / gwei）	以 SUN 计的 `feeLimit`（1 TRX = 1e6 SUN）
跨链预言机	Polymer	Polymer（Tron PolymerOracle）

推荐路径：V1 报价端点

对于 Tron，请使用 V1 集成方报价端点。它接受 CAIP-2 链外加原生地址，因此你以 base58（T…）形式传入 Tron 地址，并以 base58 形式取回——无需手动进行 EIP-7930 编码。 POST /api/v1/integrator/quote/request（可选请求头 X-Integrator-Key）。

curl -X POST 'https://order.li.fi/api/v1/integrator/quote/request' \
  -H 'Content-Type: application/json' \
  -d '{
    "user": { "chain": "tron:728126428", "address": "TYYUrA6nV1EYxQqo7RiBJh6roFq4mtiBLT" },
    "intent": {
      "intentType": "oif-swap",
      "inputs": [{
        "chain": "tron:728126428",
        "user": "TYYUrA6nV1EYxQqo7RiBJh6roFq4mtiBLT",
        "asset": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t",
        "amount": "10000000"
      }],
      "outputs": [{
        "chain": "eip155:8453",
        "receiver": "0x841F63697cFa0e3B54c4D42b3d679F07F7F2485f",
        "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
        "amount": null
      }],
      "swapType": "exact-input"
    },
    "supportedTypes": ["oif-user-open-v0"]
  }'

const response = await fetch(
  'https://order.li.fi/api/v1/integrator/quote/request',
  {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      user: { chain: 'tron:728126428', address: 'TYYUrA6nV1EYxQqo7RiBJh6roFq4mtiBLT' },
      intent: {
        intentType: 'oif-swap',
        inputs: [{
          chain: 'tron:728126428',
          user: 'TYYUrA6nV1EYxQqo7RiBJh6roFq4mtiBLT',
          asset: 'TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t', // USDT (TRC-20)
          amount: '10000000',
        }],
        outputs: [{
          chain: 'eip155:8453',
          receiver: '0x841F63697cFa0e3B54c4D42b3d679F07F7F2485f',
          asset: '0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913', // USDC on Base
          amount: null,
        }],
        swapType: 'exact-input',
      },
      supportedTypes: ['oif-user-open-v0'],
    }),
  },
);

const { quotes } = await response.json();

V1 端点上的 supportedTypes 是订单类型字符串 ["oif-user-open-v0"]（EVM 和 Tron 相同）。这不是主 POST /quote/request 端点所使用的结算类型词汇（oif-escrow-v0 / oif-resource-lock-v0）——不要把它们混用。

响应会将 Tron 地址以 base58 形式渲染返回。对于源链在 Tron 的订单，其源交易在 order.openIntentTx 下返回：

{
  "quotes": [{
    "order": {
      "openIntentTx": {
        "chain": "tron:728126428",
        "to": "TXmVLCXzrhzmeCfchDPTmFF6Qe7rg3H7Kk", // InputSettler (base58)
        "data": "0x7515fd56…",                       // ABI calldata (selector + args)
        "feeLimit": "150000000"                       // SUN cap (≈150 TRX)
      }
    },
    "preview": {
      "inputs":  [{ "user": "TYYUrA6nV1EYxQqo7RiBJh6roFq4mtiBLT", "asset": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t", "amount": "10000000" }],
      "outputs": [{ "receiver": "0x841F63697cFa0e3B54c4D42b3d679F07F7F2485f", "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", "amount": "9986765" }]
    }
  }]
}

反方向（EVM → Tron）的做法相同——把 Tron 这一端放在 outputs 中，使用 chain: "tron:728126428" 和 base58 地址。如果你改用主 POST /quote/request 端点（EIP-7930），那么可互操作地址必须编码 tron CAIP-2 命名空间，并嵌入 Tron 地址的 20 字节 形式（见边界处的地址格式）。相比手动编码，更推荐使用 V1 端点，或使用 interoperable-addresses 库构建 EIP-7930。

边界处的地址格式

一个 Tron base58 地址（T…）由一个 0x41 版本字节加上 20 字节账户组成，并包裹在 base58check 中。协议只会看到那 20 字节账户——0x41 版本字节和 base58 校验和只存在于面向人类的封装中。

V1 端点： 传入 base58（T…）。也接受带 0x 前缀的 20 字节十六进制。响应始终渲染为 base58。
主端点（EIP-7930）： 嵌入的地址是 20 字节形式（base58 解码后，去掉 0x41 和校验和）。
链上 / 订单结构中： 20 字节十六进制，左填充到 bytes32——与 EVM 完全相同。

使用 bs58check 在两种形式之间转换：

import bs58check from 'bs58check';

const TRON_VERSION_BYTE = 0x41;

// Tron base58 (T…) -> 20-byte hex used in the protocol / order struct
function tronBase58ToHex20(address: string): `0x${string}` {
  const decoded = bs58check.decode(address); // 21 bytes: 0x41 + 20-byte account
  const body = decoded.slice(1);             // drop the 0x41 version byte
  return ('0x' +
    Array.from(body, (b) => b.toString(16).padStart(2, '0')).join('')
  ) as `0x${string}`;
}

// 20-byte hex -> Tron base58 (T…)
function hex20ToTronBase58(hex: string): string {
  const body = Uint8Array.from(
    hex.replace(/^0x/, '').match(/.{1,2}/g)!.map((b) => parseInt(b, 16)),
  );
  const payload = new Uint8Array(21);
  payload[0] = TRON_VERSION_BYTE;
  payload.set(body, 1);
  return bs58check.encode(payload);
}

// TXmVLCXzrhzmeCfchDPTmFF6Qe7rg3H7Kk <-> 0xef1b684567bfcbabb19d01a84bc3f218081b1536

传输格式与 EVM 相同

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

结算：仅托管（Escrow）

Tron 仅支持 托管（Escrow） 输入结算器。Tron 上 没有 Compact / The Compact / 资源锁 流程。相应后果：

在主 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… 地址发送资金——它们在那里并不存在。

合约	Base58 (Tron)	Hex (20-byte)
InputSettler (Escrow)	`TXmVLCXzrhzmeCfchDPTmFF6Qe7rg3H7Kk`	`0xef1b684567bfcbabb19d01a84bc3f218081b1536`
OutputSettler	`THWDD3umarircbqo8jXxVazbpJnE25VjhN`	`0x52a5f2a94125ef11673f86104e2ce3f86ece2c25`
PolymerOracle	`TCeNWukZUoTSrgWZEMpn9X8C5NtV8Rsy6c`	`0x1d586aa1bd8ea3fda890057bad5a7d373886dbc1`

链上提交（TVM）

报价的 openIntentTx.data 是完整的 ABI calldata（函数选择器 + 参数），以 0x 十六进制字符串形式给出——它不是一笔可直接广播的 EVM 交易。Tron 客户端必须将其包裹在 TriggerSmartContract 信封中，该信封受 TAPOS 约束（它通过 ref_block_* / expiration 引用一个近期区块），然后对其签名并广播。

openIntentTx.to 是结算器的 base58 地址。
openIntentTx.feeLimit 是 以 SUN 计的能量花费上限，而非估算值。
代币授权使用 TRC-20（而非 ERC-20）。

import { TronWeb } from 'tronweb';

const tronWeb = new TronWeb({ fullHost: 'https://api.trongrid.io' /*, privateKey */ });
const { to, data, feeLimit } = quote.order.openIntentTx;

// 1. Approve the InputSettler to pull the TRC-20 input (e.g. USDT)
//    via the token contract's `approve(spender, amount)`.

// 2. Submit the open() calldata wrapped in a TriggerSmartContract envelope.
const tx = await tronWeb.transactionBuilder.triggerSmartContract(
  to,                       // settler (base58)
  '',                       // selector empty: full calldata is supplied via `input`
  { feeLimit, input: data.replace(/^0x/, '') },
  [],
  tronWeb.defaultAddress.base58,
);
const signed = await tronWeb.trx.sign(tx.transaction);
await tronWeb.trx.sendRawTransaction(signed);

订单开启后，通过订单状态 API 以与 EVM 订单相同的方式追踪它。

预言机

对于跨链 Tron 输出，订单使用 Polymer；MandateOutput.oracle 是 Tron PolymerOracle（TCeNWukZUoTSrgWZEMpn9X8C5NtV8Rsy6c）的 bytes32。对于同链（Tron → Tron）意图，OutputSettler 充当预言机路径，如同链意图所述。有关 Polymer 证明的工作原理，请参见预言机系统。

面向解算器

履行一个 Tron 输出的方式与 EVM 交付相同——在 Tron OutputSettler 上调用 fillOrderOutputs——只有一处 Tron 特有之处：

通过 TronWeb 提交，并使用上文的 20 字节规则解码地址。

关于通用的交付流程，请参见履行订单。

后续步骤

请求报价

报价端点、exact-input/output 以及可互操作地址

创建并提交订单

构造 StandardOrder 并在链上开启它

预言机系统

Polymer 及其他验证系统

履行订单

解算器如何交付输出

入门

Intents API

Solver API

MCP Server

架构

知识库

概览

推荐路径：V1 报价端点

边界处的地址格式

传输格式与 EVM 相同

结算：仅托管（Escrow）

开启订单：仅限链上

合约地址

链上提交（TVM）

预言机

面向解算器

后续步骤

请求报价

创建并提交订单

预言机系统

履行订单

​概览

​推荐路径：V1 报价端点

​边界处的地址格式

​传输格式与 EVM 相同

​结算：仅托管（Escrow）

​开启订单：仅限链上

​合约地址

​链上提交（TVM）

​预言机

​面向解算器

​后续步骤

请求报价

创建并提交订单

预言机系统

履行订单

概览

推荐路径：V1 报价端点

边界处的地址格式

传输格式与 EVM 相同

结算：仅托管（Escrow）

开启订单：仅限链上

合约地址

链上提交（TVM）

预言机

面向解算器

后续步骤