Skip to main content

​
Overview

Portal integrates with Li.Fi so you can bridge and swap tokens across multiple chains through Portal APIs and SDKs. This page covers the one‑time setup in Li.Fi and the Portal Dashboard.

​
Steps to enable the Portal Li.Fi integration

​
1. Sign up for Li.Fi

  • Create or access your Li.Fi account here.
  • Generate a Li.Fi API key in your Li.Fi dashboard.
Keep your API keys secure. You’ll paste it into Portal in the next step.

​
2. Enable the Li.Fi integration in Portal

  1. Open the Portal Dashboard.
  2. Navigate to the Integrations page.
  3. Locate the Li.Fi integration and add it.
  4. Paste your Li.Fi API key for your selected Portal environment and save.
Once saved, Portal will proxy your SDK/API calls to Li.Fi using this key securely from Portal’s servers, so you won’t need to embed it in your application code.
Integrations are environment‑scoped. Repeat these steps per Portal environment.

​
Gas-sponsored Solana swaps

Some Solana routes create an intermediate token account partway through the swap (for example a WSOL account for a route that hops through a SOL pool). That account creation is funded by the sending wallet, so a gas-sponsored wallet holding 0 SOL would otherwise fail on the rent for it. Li.Fi exposes an svmSponsor field on the quote and routes requests: the account it names is used as the fee payer and the funder for any account creation in the route, so your sponsor covers that rent. When your Portal environment has a Solana gas sponsor enabled, Portal fills svmSponsor for you on Solana source routes, so no change is needed in your app. To use a different account, pass svmSponsor (a valid Solana address) on the request and Portal will use it instead. Invalid values are ignored and fall back to the environment gas sponsor. On /lifi/quote it is a top-level field (svmSponsor); on /lifi/routes it goes inside options (options.svmSponsor).
svmSponsor is Solana (SVM) only and applies when the source chain is Solana. It is available on /lifi/quote and /lifi/routes; routes bake it into the returned steps, so /lifi/route-step-details inherits it.

​
Selecting Solana swap routes

Li.Fi routes Solana swaps across several DEX aggregators, and the aggregator it picks (and how much compute the resulting transaction uses) can differ on each quote for the same request. Occasionally it returns a compute-heavy multi-hop route whose transaction exceeds Solana’s compute unit budget, so submitting it fails simulation with ComputationalBudgetExceeded. Because the route is chosen fresh per quote, re-requesting often returns a lighter route that succeeds. For more predictable routing, constrain which exchanges Li.Fi may use with allowExchanges (allowlist) or denyExchanges (blocklist). For Solana stablecoin swaps, limiting to lighter-compute routes like jupiter or fly is a good starting point:
The exchange keys are Li.Fi’s DEX aggregator identifiers (for example jupiter, fly, okx, titan). On /lifi/quote these are top-level fields (allowExchanges, denyExchanges, preferExchanges). On /lifi/routes they live under options.exchanges (allow, deny, prefer). Portal forwards them to Li.Fi unchanged.
These filters work on any chain, not just Solana. On Solana they are the simplest way to avoid the intermittent ComputationalBudgetExceeded failures that come from heavier multi-hop routes.

​
Next steps

Implement the flow in your app using our SDK guides for Li.Fi: