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
Quoting
Tron is served by the standard quote endpoint,POST /api/v1/integrator/quote/request. It accepts a CAIP-2 chain plus the native address, so you pass Tron addresses as base58 (T…) and get them back as base58. The full request reference and a Tron example are in Request a Quote.
The response renders Tron addresses back as base58. The origin transaction for a Tron-origin order is returned under order.openIntentTx:
outputs with chain: "tron:728126428" and base58 addresses.
If you instead use the legacy V0 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) — and supportedTypes there takes the settlement-type vocabulary (["oif-escrow-v0"] only on Tron), not oif-user-open-v0. Prefer the standard 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.
- Quote endpoint (V1): pass base58 (
T…).0x-prefixed 20-byte hex is also accepted. Responses always render base58. - Legacy V0 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.
bs58check:
Wire format is identical to EVM
Once an address is in 20-byte hex form, nothing downstream changes. TheStandardOrder 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 legacy V0
POST /quote/requestendpoint, request["oif-escrow-v0"]only — neveroif-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 theopenIntentTx 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 deterministic0x0000… addresses used on EVM chains. Tron has no keyless CREATE2 factory, so the deployments live at unique, Tron-specific addresses.
On-chain submission (TVM)
The quote’sopenIntentTx.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.tois the settler base58 address.openIntentTx.feeLimitis a cap on energy spend in SUN, not an estimate.- Token approvals use TRC-20 (not ERC-20).
Oracle
For cross-chain Tron outputs, the order uses Polymer;MandateOutput.oracle is the bytes32 of the Tron PolymerOracle (TPXQkHcGwEdH4Ss8kT4cDxgXt3L4n4zSHJ). For same-chain (Tron → Tron) intents, the OutputSettler acts as the oracle, 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: callfillOrderOutputs on the Tron OutputSettler. The one Tron-specific step is to submit through TronWeb, decoding addresses with the 20-byte rule above.
See Solving LI.FI Intents for the general fill flow.
Next Steps
Request a Quote
Exact-input/output quoting and the Tron request example
Create and Submit Orders
Construct a StandardOrder and open it on-chain
Oracle Systems
Polymer and the other verification systems
Solving LI.FI Intents
How solvers deliver outputs

