Skip to main content
A wallet’s job is to hold keys safely. Users judge it on something else entirely: whether they can get from the asset they’re holding to the one they want, without leaving. Closing that gap normally means integrating a swap venue, then a bridge, then a second bridge, then a gas solution. LI.FI collapses all of it into one quote.

What this changes for your product

A new chain costs a config change

Adding a chain doesn’t mean signing a new liquidity relationship, because the routing layer already has them.

Fewer failures reaching users

Routes that would revert can be filtered before they’re ever quoted, so what a user taps is what’s likely to execute.

Users land able to act

Part of an incoming transfer converts into destination gas in the same transaction, so a first arrival on a chain isn’t a dead end.

Swap volume becomes revenue

You set a fee on the quote and it’s forwarded to your wallet at execution, with no revenue share to negotiate.
A wallet's key custody and interface on one side, LI.FI's venue aggregation, routing, and gas provisioning on the other

What the wallet keeps, and what the routing layer absorbs.

Why the usual approach stalls

A customer with a balance on one chain and an intention on another expects the wallet to close the distance. Meeting that expectation means a venue integration, a bridge, a second bridge for the pairs the first doesn’t cover, and a gas answer for the chain they just arrived on. Each one carries its own liquidity relationships, status semantics, and failure modes, and every chain you add multiplies the set. The narrower problem is custody. A wallet doesn’t hold the funds, so it can’t absorb a bad outcome the way a custodial product can. When a route fails halfway, the customer’s own assets are sitting somewhere unexpected and you have to explain it. The integration decision is really a decision about how many distinct failure states your support team is willing to learn.

One routing surface, three ways to take it

LI.FI aggregates swap venues and transfer paths behind a single quote. You ask for an amount of one asset on one chain and an asset on another, and what comes back is a priced route with the execution data attached.

Widget

A styled, working swap interface you configure and drop in. Fastest path from decision to shipped.

SDK

Typed quotes and a ready transaction request, with every pixel left to you.

API

For wallets whose routing logic lives on a backend in a language that isn’t TypeScript.

Execution quality, because failures are somebody’s own money

Quote Simulation

Candidate routes are simulated before you see them, and the ones that would revert are dropped. A class of failure moves from your support queue into a route that was never offered.

Smart Slippage

Tolerance set per token from market data, replacing the flat percentage that’s either too tight for a thin pair or too loose for a stable one.
Both are available to every integrator without an access request. Each still applies only to eligible requests and covered chains and tokens, so read the returned fields rather than assuming every route was simulated or carries a recommendation.

The cold start, and getting paid

A customer arriving on a chain for the first time holds an asset and no native token, which means they hold nothing they can act on. Gas Fronting converts part of the incoming transfer into the destination chain’s native asset in the same transaction, so they land able to move.
Gas Fronting doesn’t apply to contract-call flows or Composer. A wallet building a compose-on-arrival feature needs a separate answer for gas there.
Volume through the wallet can be monetized without a separate business relationship. You set a fee percentage on the quote request and it’s forwarded to your fee wallet at execution, across EVM chains, Tron, Solana, Sui, Bitcoin, and Stellar. See monetizing the integration for the mechanics per chain family.

What to decide before launch

A team that adopts the Widget and later wants full control has a migration in front of it, because the two surfaces have different shapes. Neither answer is wrong. Choosing late is expensive.
A fee folded silently into the rate is a support conversation waiting for the user who compares your quote elsewhere. A fee shown as a line item is a conversation you have once, in your interface, on your terms.
Cross-chain transfers can settle at an intermediate token rather than forcing a bad final trade. That’s correct protocol behavior and a confusing wallet screen if nobody designed for it. See Intermediate tokens.
The user holds the keys, so every guard rail you build is a prompt they can dismiss rather than a policy you can enforce. Build them anyway, and be honest internally about what they’re worth.

Where to start

Point the Widget at a configuration for one cross-chain pair and run a swap end to end. An afternoon of that tells you more about where the integration sits in your product than a week of reading.

Widget overview

Configuration, theming, and wallet management.

SDK overview

Quoting, execution, and the ecosystem providers.

Monetizing the integration

Fee mechanics for EVM, Solana, Sui, and Bitcoin.

Gas Fronting

Converting part of a transfer into destination gas.

Talk to the LI.FI team

Bring the chains you support and the swap volume you expect. We scope an API key, the fee setup, and which execution-quality features fit.