> ## Documentation Index > Fetch the complete documentation index at: https://docs.li.fi/llms.txt > Use this file to discover all available pages before exploring further. # One Swap Surface for Every Chain You Support > Give users one swap surface across every chain you support, without integrating a venue per chain. 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](https://mintcdn.com/lifi/PmU0d85L8IwCXHK-/images/use-cases/wallet-surface-boundary.png?fit=max\&auto=format\&n=PmU0d85L8IwCXHK-\&q=85\&s=805d1dd58b804e1e207660dcf84a896d) 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](https://docs.li.fi/widget/overview.md)** > > A styled, working swap interface you configure and drop in. Fastest path from decision to shipped. > **[SDK](https://docs.li.fi/sdk/overview.md)** > > Typed quotes and a ready transaction request, with every pixel left to you. > **[API](https://docs.li.fi/api-reference/introduction.md)** > > 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](https://docs.li.fi/enterprise/quote-simulation.md)** > > 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](https://docs.li.fi/enterprise/smart-slippage.md)** > > 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. > [!NOTE] > > 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](https://docs.li.fi/guides/gas-subsidy.md) converts part of the incoming transfer into the destination chain's native asset in the same transaction, so they land able to move. > [!WARNING] > > 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](https://docs.li.fi/introduction/integrating-lifi/monetizing-integration.md) for the mechanics per chain family. ## What to decide before launch > **Whether the swap interface is yours or configured** > > 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. > **Where the fee sits, and whether the user sees it** > > 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. > **What your interface does when a different asset arrives** > > 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](https://docs.li.fi/guides/intermediate-tokens.md). > **How much you're willing to constrain signing** > > 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](https://docs.li.fi/widget/overview.md)** > > Configuration, theming, and wallet management. > **[SDK overview](https://docs.li.fi/sdk/overview.md)** > > Quoting, execution, and the ecosystem providers. > **[Monetizing the integration](https://docs.li.fi/introduction/integrating-lifi/monetizing-integration.md)** > > Fee mechanics for EVM, Solana, Sui, and Bitcoin. > **[Gas Fronting](https://docs.li.fi/guides/gas-subsidy.md)** > > Converting part of a transfer into destination gas. > **[Talk to the LI.FI team](https://docs.li.fi/introduction/integrating-lifi/partnership-opportunities.md)** > > 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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.