Skip to main content
Portal’s Web SDK provides comprehensive cross-chain bridging and swapping capabilities through the 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 pollStatus when 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:
  1. Discover routes (getRoutes)
  2. Select a route (routeIndex, default 0)
  3. Build each step (getRouteStep)
  4. Sign and broadcast each step transaction
  5. Wait for on-chain confirmation for that step
  6. Poll Li.Fi status until terminal for that step
  7. Continue to the next step
Steps are executed sequentially (in order), not in parallel.

Strict Confirmation Contract

Li.Fi enforces a strict confirmation contract. Each step MUST be confirmed on-chain before proceeding to the next step:
  • Success: waitForConfirmation returns true or void
  • Failure: Any other value (false, undefined), timeout, unsupported network, or thrown error
When confirmation fails, the entire 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)
There is no optimistic fallback.

Signature

Essential parameters Second argument LifiTradeAssetOptions:
tradeAsset requires at least one confirmation mechanism. If neither waitForConfirmation nor evmRequestFn is available (from instance defaults or per-call options), the method throws immediately:[LiFi] tradeAsset requires waitForConfirmation or evmRequestFn fallback.When you construct Portal with an rpcConfig, evmRequestFn is wired automatically — no extra setup needed. This requirement only surfaces when using LiFi standalone or without Portal’s default wiring.On non-EVM networks (for example Solana), evmRequestFn is never used for confirmation — only waitForConfirmation applies. Use the standard Portal instance (which sets both the signer and waitForConfirmation), or pass waitForConfirmation in options for those routes.Receipt-polling timeouts are strict: if confirmation times out, the entire tradeAsset call throws and does not continue to bridge-status polling or subsequent steps.
Return value Example (progress + per-call confirmation options)
Example (default confirmation behavior) When you construct 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.
Wrap 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_routes
  • route_selected
  • preparing_step
  • signing
  • submitted
  • confirming
  • lifi_pending
  • step_done
  • complete
  • failed

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

The routeOptions 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 calling tradeAsset.

Getting a Quote

Use the getQuote method to get a quote for bridging or swapping tokens across chains.
The response includes a transactionRequest object with the transaction details you’ll need to sign and submit.

Finding Routes

Use the getRoutes method to discover available routes for your cross-chain transfer.
The response includes an array of routes with estimates, fees, and gas costs. Routes may be tagged as RECOMMENDED, CHEAPEST, or FASTEST.

Getting Route Step Details

Use the getRouteStep 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).
The response includes a 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 the transactionRequest object and sign the transaction. Extract the from, to, value, and data fields to sign and submit the transaction.

Approving ERC-20 Tokens

If your fromToken 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 the getStatus 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

  1. Compare quotes/routes before signing and submitting the transaction(s) to find the best option for your use case
  2. Process steps sequentially for multi-step routes, ensuring each step completes before starting the next
  3. Handle network errors gracefully and provide user feedback
  4. Monitor transaction status for cross-chain transfers, as they may take longer than single-chain transactions
  5. 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)
For the complete list of networks Li.Fi supports across its ecosystem, refer to the Li.Fi documentation. If you need a chain that isn’t listed above, contact Portal support.
Testnets are not supported.

Next Steps