Skip to main content
Tron is a supported Intents chain (chain ID 728126428, CAIP-2 tron:728126428). Tron runs an EVM-compatible VM, so inside the protocol the order looks identical to EVM — the same StandardOrder and MandateOutput structs, the same 20-byte addresses left-padded to bytes32. The differences are at the edges: how you encode addresses at the HTTP boundary, which contract addresses you talk to, which settlement types exist, and how you submit the origin transaction. This page is a delta reference — for each concern, what EVM does and what Tron does instead.
For general (non-Intents) Tron support across LI.FI products, see the Tron ecosystem page.

At a glance


For Tron, use the V1 integrator quote endpoint. It accepts a CAIP-2 chain plus the native address, so you pass Tron addresses as base58 (T…) and get them back as base58 — no EIP-7930 hand-encoding. POST /api/v1/integrator/quote/request (optional header X-Integrator-Key).
supportedTypes on the V1 endpoint is the order-type string ["oif-user-open-v0"] (the same for EVM and Tron). This is not the settlement-type vocabulary (oif-escrow-v0 / oif-resource-lock-v0) used by the main POST /quote/request endpoint — don’t mix them.
The response renders Tron addresses back as base58. The origin transaction for a Tron-origin order is returned under order.openIntentTx:
The reverse direction (EVM → Tron) works the same way — put the Tron leg in outputs with chain: "tron:728126428" and base58 addresses. If you instead use the main POST /quote/request endpoint (EIP-7930), the interoperable address must encode the tron CAIP-2 namespace and embed the 20-byte form of the Tron address (see Address format). Prefer the V1 endpoint or build EIP-7930 with the interoperable-addresses library rather than hand-encoding it.

Address format at the boundary

A Tron base58 address (T…) is a 0x41 version byte plus the 20-byte account, wrapped in base58check. The protocol only ever sees the 20-byte account — the 0x41 version byte and the base58 checksum exist only in the human-facing envelope.
  • V1 endpoint: pass base58 (T…). 0x-prefixed 20-byte hex is also accepted. Responses always render base58.
  • Main endpoint (EIP-7930): the embedded address is the 20-byte form (base58 decoded, 0x41 + checksum stripped).
  • On-chain / in the order struct: 20-byte hex, left-padded to bytes32 — exactly like EVM.
Convert between the two forms with bs58check:

Wire format is identical to EVM

Once an address is in 20-byte hex form, nothing downstream changes. The StandardOrder and MandateOutput structs, the bytes32 left-padding (tokenId/oracle/settler/token/recipient), and the calldata encoding are the same on Tron as on EVM. The 0x41 version byte never appears on-chain. If your EVM order-construction code already produces the correct struct, the only change for Tron is converting addresses at the boundary and submitting via TronWeb.

Settlement: Escrow only

Tron supports only the Escrow input settler. There is no Compact / The Compact / resource-lock flow on Tron. Consequences:
  • On the main POST /quote/request endpoint, request ["oif-escrow-v0"] only — never oif-resource-lock-v0.
  • The Compact Orders guide does not apply to Tron.

Opening orders: on-chain only

Tron orders are opened on-chain by calling the Escrow input settler directly with the openIntentTx from the quote. The order server and solvers detect the resulting on-chain event automatically. POST /orders/submit (off-chain / gasless submission) is EVM-only — there is no gasless Tron path.

Contract addresses

These are not the deterministic 0x0000… addresses used on EVM chains. Tron has no keyless CREATE2 factory, so the deployments live at unique, Tron-specific addresses.
The “same address across all supported chains” statement elsewhere in these docs applies to EVM chains only. Do not send funds to the EVM 0x0000… addresses on Tron — they do not exist there.

On-chain submission (TVM)

The quote’s openIntentTx.data is full ABI calldata (function selector + arguments) as a 0x-hex string — it is not a ready-to-broadcast EVM transaction. A Tron client must wrap it in a TriggerSmartContract envelope, which is TAPOS-bound (it references a recent block via ref_block_* / expiration), then sign and broadcast it.
  • openIntentTx.to is the settler base58 address.
  • openIntentTx.feeLimit is a cap on energy spend in SUN, not an estimate.
  • Token approvals use TRC-20 (not ERC-20).
After the order opens, track it the same way as an EVM order via the order status API.

Oracle

For cross-chain Tron outputs, the order uses Polymer; MandateOutput.oracle is the bytes32 of the Tron PolymerOracle (TCeNWukZUoTSrgWZEMpn9X8C5NtV8Rsy6c). For same-chain (Tron → Tron) intents, the OutputSettler acts as the oracle path, as described in Same-chain intents. See Oracle Systems for how Polymer proofs work.

For solvers

Filling a Tron output works like an EVM fill — call fillOrderOutputs on the Tron OutputSettler — with one Tron specifics:
  • Submit via TronWeb, decoding addresses with the 20-byte rule above.
See Filling Orders for the general fill flow.

Next Steps

Request a Quote

Quote endpoints, exact-input/output, and interoperable addresses

Create and Submit Orders

Construct a StandardOrder and open it on-chain

Oracle Systems

Polymer and the other verification systems

Filling Orders

How solvers deliver outputs