Skip to main content
Portal’s iOS SDK provides comprehensive cross-chain bridging and swapping capabilities through the portal.trading.lifi API. This guide covers getting quotes, finding routes, executing swaps and bridges, and tracking transaction status.

Overview

The Li.Fi functionality allows you to:
  • 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

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)

High-Level Methods

tradeAsset runs the entire bridge or swap in one call. pollStatus exposes the same Li.Fi status poller tradeAsset uses internally, for manual flows where you already have a transaction hash. If you only need to move tokens, use tradeAsset. Reach for the low-level methods when you need to inspect routes before committing, run your own signing, or drive a custom UI.

tradeAsset

Runs the end-to-end Li.Fi flow:
  1. Discover routes (getRoutes)
  2. Select a route (routeIndex, default 0)
  3. Build each step (getRouteStep)
  4. Sign and broadcast that step’s transaction
  5. Wait for on-chain confirmation of that step
  6. Poll Li.Fi status until the step reaches a terminal state
  7. Continue to the next step
Steps execute sequentially, never in parallel. Signing and confirmation for each step happen on that step’s own chain, which the SDK resolves from the step itself — so a multi-chain route signs on each chain in turn without you managing it. Confirmation is strict. Every step must confirm on-chain before the next begins. There is no optimistic fallback: a revert or a confirmation timeout aborts the whole trade and throws.

Signature

Essential parameters
fromAddress is optional in the type system but the SDK does not fill it in for you — it is forwarded to Li.Fi exactly as given. Omitting it means routes are quoted without a sender, while the transaction is still signed by your Portal wallet, so the quote may not match what actually executes. Pass try await portal.getAddress("eip155:8453") explicitly.
Configuring the signer and confirmation Unlike the React Native and Web SDKs, tradeAsset takes no second options argument. The signing and confirmation hooks are injected once, when the Lifi instance is constructed:
Portal wires both automatically, so portal.trading.lifi.tradeAsset(params:) works with no setup. The default confirmation poller retries 30 times at 2-second intervals. Overriding the defaults. portal.trading is built lazily by Portal with its own closures already supplied, so the instance at portal.trading.lifi cannot be reconfigured after the fact, and there is no per-call override. Trading has an internal initializer, so you cannot construct one yourself either — build a Lifi directly and call tradeAsset on it:
stepPollOptions controls the per-step Li.Fi polling inside tradeAsset and is only reachable this way. waitForConfirmation returns a three-state enum rather than a boolean, so a revert and a timeout stay distinguishable: Return value

Example (progress reporting)

Example (minimal)

Errors

tradeAsset and pollStatus throw LifiTradeAssetError: All cases conform to LocalizedError, so error.localizedDescription gives a readable message.
If the surrounding Task is cancelled, tradeAsset throws CancellationError and does not emit a .failed progress event. A UI that only dismisses its progress state on .failed or .complete will hang on cancellation — handle CancellationError separately.

Progress lifecycle

onProgress receives a LifiTradeAssetProgressStatus and a LifiTradeAssetProgressData. Every field on the data struct is optional; which ones are populated depends on the stage: txHash is nil until .submitted. errorMessage is only ever set on .failed.

pollStatus

Polls Li.Fi for the status of a transfer until it reaches a terminal state. Use it when you have submitted a transaction yourself and want the same polling behavior tradeAsset uses internally. The protocol requirement takes three arguments, and three convenience overloads cover the common cases:
Returning false from onUpdate stops polling early and returns the last status received — it is not an error. Returning true continues.

pollStatus options


Low-level methods

The rest of this guide covers the individual Li.Fi methods. Use them when you need control over route selection, signing, or status tracking that tradeAsset does not expose.

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(request:) 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

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