portal.trading.lifi API. This guide covers high-level end-to-end trades, getting quotes, finding routes, executing swaps and bridges manually, and tracking transaction status.
Overview
The Li.Fi functionality allows you to:- Run an end-to-end trade with
tradeAsset(routes, steps, signing, confirmation, and Li.Fi status polling) - Get quotes for bridging or swapping tokens across chains
- Find routes to discover the best paths for your cross-chain transfers
- Execute swaps and bridges by signing and submitting transactions
- Track transaction status for cross-chain transfers
- Poll Li.Fi status with
pollStatuswhen you already have a transaction hash
Prerequisites
Before using Li.Fi operations, ensure you have:- A properly initialized Portal client
- An active wallet with the required token(s) on the source network (see Create a wallet)
- Li.Fi integration enabled in your Portal Dashboard (see Li.Fi Integration)
Supported Chains: Li.Fi integration currently supports EVM-compatible chains (Ethereum, Base, Arbitrum, Polygon, etc.) and Solana. Other non-EVM chains may not be supported for Li.Fi operations.Solana vs
evmRequestFn: The built-in fallback that watches EVM receipts (evmRequestFn + receipt polling) only runs when the step’s network is an eip155:* chain. For Solana (or any non-EVM) step, that path does not apply — you must have waitForConfirmation (the default when using the standard Portal client is enough). If you use LiFi without Portal’s defaults, supply waitForConfirmation yourself for those steps; relying on evmRequestFn alone will throw once a non-EVM step needs confirmation.High-Level Methods
tradeAsset
Runs the end-to-end Li.Fi flow in one call:
- Discover routes (
getRoutes) - Select a route (
routeIndex, default0) - Build each step (
getRouteStep) - Sign and broadcast each step transaction
- Wait for on-chain confirmation for that step
- Poll Li.Fi status until terminal for that step
- Continue to the next step
Strict Confirmation Contract
Li.Fi enforces a strict confirmation contract. Each step MUST be confirmed on-chain before proceeding to the next step:- Success:
waitForConfirmationreturnstrueorvoid - Failure: Any other value (
false,undefined), timeout, unsupported network, or thrown error
tradeAsset call throws and no further steps are executed. This ensures no silent failures or partial execution.
Default timeout behavior:
- Timeout:
900_000ms(15 minutes) - Poll interval:
4_000ms - Unsupported networks return
false(treated as failure)
Signature
Second argument
LifiTradeAssetOptions:
Return value
Example (progress + per-call confirmation options)
Portal, Li.Fi receives the same default signAndSendTransaction, waitForConfirmation, and evmRequestFn as other trading helpers — you can call tradeAsset with only params if that wiring is sufficient for your chain and RPC setup.
tradeAsset in try/catch; failures (no route, step error, receipt timeout, Li.Fi terminal FAILED, …) throw after onProgress may report 'failed'.
Progress lifecycle
onProgress can emit statuses such as:
fetching_routesroute_selectedpreparing_stepsigningsubmittedconfirminglifi_pendingstep_donecompletefailed
pollStatus
Built-in Li.Fi status polling with retries and backoff. Use when you already have a tx hash (for example from a manual flow) and want the same polling behavior as inside tradeAsset, without implementing the loop yourself.
On Web, pass the update callback as onUpdate inside the second-argument options object (React Native passes it as a separate argument).
pollStatus options
Return
false from onUpdate to stop early; return true (or nothing) to continue.
Route options
TherouteOptions parameter on tradeAsset (and the options field on LifiRoutesRequest) accepts a LifiRoutesRequestOptions object:
Low-level methods
Use these methods when you want full control over quotes, route selection, signing, and status polling instead of callingtradeAsset.
Getting a Quote
Use thegetQuote method to get a quote for bridging or swapping tokens across chains.
transactionRequest object with the transaction details you’ll need to sign and submit.
Finding Routes
Use thegetRoutes method to discover available routes for your cross-chain transfer.
RECOMMENDED, CHEAPEST, or FASTEST.
Getting Route Step Details
Use thegetRouteStep method to get detailed transaction information for a specific route step, including an unsigned transaction that you can then sign and submit to an RPC provider (the transactionRequest field).
transactionRequest object with the unsigned transaction that you can sign and submit.
Executing Swaps and Bridges
After getting a quote or route step details, extract the transaction details from thetransactionRequest object and sign the transaction. Extract the from, to, value, and data fields to sign and submit the transaction.
Approving ERC-20 Tokens
If yourfromToken is an ERC-20, the Li.Fi router cannot move it on your behalf until you grant an on-chain allowance. Skip this step when the fromToken is the chain’s native asset (its address is 0x0000000000000000000000000000000000000000).
Build the approval transaction with the portal.delegations.approve method, then sign each transaction it returns with the same eth_sendTransaction flow used to sign the swap. Call this helper after obtaining a quote and before calling executeTransaction:
This step only applies when the
fromToken is an ERC-20. Native-asset swaps (ETH, MATIC, etc.) skip it. For more on the delegations API, see the Manage Token Delegations guide.Signing and Submitting Transactions
The
transactionRequest from Li.Fi may include gasPrice and gasLimit fields. You can remove these if
you want Portal to estimate the gas for you, or include them if you want to use Li.Fi’s estimates.Processing Multiple Route Steps
For routes with multiple steps, process them sequentially:Waiting for Transaction Confirmation
The example below is for educational purposes showing low-level receipt polling. When using
tradeAsset, confirmation failures automatically throw and abort the entire operation. The strict confirmation contract ensures no silent failures.Tracking Transaction Status
Use thegetStatus method to track the status of your cross-chain transfer.
Polling for Cross-Chain Completion
For cross-chain transfers, poll the status endpoint until the transfer completes:Example Flow
Here’s a complete example of executing a cross-chain bridge:Best Practices
- Compare quotes/routes before signing and submitting the transaction(s) to find the best option for your use case
- Process steps sequentially for multi-step routes, ensuring each step completes before starting the next
- Handle network errors gracefully and provide user feedback
- Monitor transaction status for cross-chain transfers, as they may take longer than single-chain transactions
- Validate user balances before initiating swaps or bridges
Supported Networks
Portal’s Li.Fi integration supports the following mainnet networks:- Monad (
eip155:143) - Ethereum (
eip155:1) - Optimism (
eip155:10) - BSC (
eip155:56) - Gnosis (
eip155:100) - Unichain (
eip155:130) - Polygon (
eip155:137) - Sonic (
eip155:146) - Mantle (
eip155:5000) - Base (
eip155:8453) - Arbitrum (
eip155:42161) - Celo (
eip155:42220) - Avalanche (
eip155:43114) - Linea (
eip155:59144) - Berachain (
eip155:80094) - Katana (
eip155:747474) - Solana (
solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp) - Bitcoin (
bip122:000000000019d6689c085ae165831e93-p2wpkh)
Testnets are not supported.
Next Steps
- Learn about signing transactions
- Explore sending tokens
- Check out Portal API methods
- See the Client API Li.Fi endpoints