LI.FI: cross-chain liquidity routing with one API

LI.FI: cross-chain liquidity routing with one API. li.fi is the commercial face of a routing and orchestration stack that quotes and executes same-chain swaps and cross-chain transfers across bridges, DEX aggregators, intent solvers, and yield venues — so apps do not maintain every bridge and router themselves.

Click to zoom

Problem it solves

Multichain product work usually explodes into: many chains, many bridges, per-ecosystem DEX aggregators, wrapped vs native stablecoins, intent networks, and status UX when a transfer is stuck mid-route. LI.FI's pitch is one integration that selects and monitors routes across that mesh — marketing cites large partner counts and cumulative transfer volume; treat headline stats as product claims and verify current figures on partner materials when you need them for diligence.

What you get

Minimal agent / backend endpoint set

Docs center agents on a small surface. Base: https://li.quest/v1.

# Discover chains (EVM | SVM | UTXO | MVM)
curl -s "https://li.quest/v1/chains?chainTypes=SVM" | head

# Quote a transfer (example shape — use real addresses + decimals)
curl -sG "https://li.quest/v1/quote" \
  --data-urlencode "fromChain=1" \
  --data-urlencode "toChain=1151111081099710" \
  --data-urlencode "fromToken=USDC" \
  --data-urlencode "toToken=USDC" \
  --data-urlencode "fromAmount=1000000" \
  --data-urlencode "fromAddress=0xYourEvmAddress"

# Track after broadcast
curl -sG "https://li.quest/v1/status" \
  --data-urlencode "txHash=0x..." \
  --data-urlencode "bridge=..." \
  --data-urlencode "fromChain=1" \
  --data-urlencode "toChain=..."

A successful quote typically includes execution payload (transactionRequest or chain-specific instruction data) ready for wallet signing. Always confirm Solana chain IDs and token addresses from /chains and /tokens — IDs are not always EVM-shaped integers in every client wrapper.

Quote vs route

Docs distinguish a single quote (ready-to-sign path) from multi-step routes (composed steps across bridges and DEXs). Status tracking walks substatuses until DONE / FAILED / pending states — build product UX on the status API rather than guessing confirmation depth per bridge.

Solana angle

Solana appears in LI.FI's multi-ecosystem coverage (SVM chain type alongside EVM, Bitcoin UTXO, Sui). For Solana apps this usually means:

• On-ramp liquidity from EVM L2s into SOL / SPL without a custom bridge stack
• Exit paths from Solana to other ecosystems in one partner integration
• Competing with pure Solana DEX aggregators only for cross-ecosystem flows — for SOL↔SPL same-chain, Jupiter-class routers still dominate mindshare

Related: Jupiter for Solana-native aggregation; LI.FI when the path must leave or enter other ecosystems.

Integration checklist

1. Read docs.li.fi + OpenAPI; request partner access if you need production keys/limits.
2. Enumerate chains/tokens for your corridors; hard-fail unsupported pairs in UI before quote.
3. Implement quote → user review (fees, ETA, steps) → sign → poll /status.
4. Map error codes and stuck transfers to support runbooks (bridge finality is not uniform).
5. Optional: Widget for speed; Composer/Earn if you need deposit+yield composition; MCP/CLI if agents execute transfers.
6. Security: never blind-sign; show route steps; treat quote expiry; monitor LI.FI + underlying bridge incident channels.

When not to use it

• Pure Solana spot routing with no cross-chain need
• You require a single specific bridge only (compliance / direct integration)
• Latency-critical HFT-style paths where aggregator hops add cost

People and links

Resources

• LI.FI documentation
• docs llms.txt (agent index)
• OpenAPI
• li.fi