> ## 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.

# 为你支持的每条链提供统一的交换入口

> 在你支持的每条链上为用户提供统一的交换入口，无需逐链对接交易场所。

钱包的职责是安全地保管密钥。但用户评判钱包的标准完全是另一回事：能否在不离开钱包的情况下，把手里持有的资产换成想要的资产。要弥合这一差距，通常需要先对接一个交换场所，再接入一个 bridge，然后是第二个 bridge，最后还要解决 gas 问题。LI.FI 把这一切整合进一个报价。

## 这会为你的产品带来什么改变

> **新增一条链只需改一下配置**
>
> 新增链并不意味着要签订新的流动性合作，因为路由层已经具备这些资源。

> **触达用户的失败更少**
>
> 会回滚的路由可以在报价之前就被过滤掉，因此用户点击的就是大概率能够执行的路由。

> **用户到账即可操作**
>
> 转入资金的一部分会在同一笔交易中兑换为目标链 gas，因此首次到达某条链不会陷入无法操作的困境。

> **交换量转化为收入**
>
> 你在报价上设置费用，执行时费用会转入你的钱包，无需协商收入分成。

![一侧是钱包的密钥托管与界面，另一侧是 LI.FI 的交易场所聚合、路由与 gas 供给](https://mintcdn.com/lifi/PmU0d85L8IwCXHK-/images/use-cases/wallet-surface-boundary.png?fit=max\&auto=format\&n=PmU0d85L8IwCXHK-\&q=85\&s=805d1dd58b804e1e207660dcf84a896d)

钱包保留什么，路由层承接什么。

## 常规做法为何难以推进

用户在一条链上有余额，却想在另一条链上进行操作，他们期望钱包来弥合这段距离。要满足这一期望，需要对接一个交易场所、一个 bridge、为第一个 bridge 未覆盖的交易对再接入第二个 bridge，还要为用户刚到达的链提供 gas 方案。每一项都有各自的流动性合作关系、状态语义和失败模式，而你每新增一条链，这些组合都会成倍增长。

更具体的问题在于托管。钱包并不持有资金，因此无法像托管类产品那样消化不良结果。当一条路由中途失败时，用户自己的资产会停留在意料之外的地方，而你需要向用户解释清楚。因此，集成决策实际上是在决定：你的支持团队愿意去了解多少种不同的失败状态。

## 一个路由层，三种接入方式

LI.FI 将各类交换场所和转账路径聚合在一个报价之后。你请求将某条链上一定数量的某种资产兑换为另一条链上的某种资产，返回的是一条附带执行数据、已定价的路由。

> **[Widget](https://docs.li.fi/widget/overview.md)**
>
> 一个带样式、开箱即用的交换界面，配置后即可嵌入。从决策到上线的最快路径。

> **[SDK](https://docs.li.fi/sdk/overview.md)**
>
> 类型化的报价和现成的交易请求，界面的每个像素都由你掌控。

> **[API](https://docs.li.fi/api-reference/introduction.md)**
>
> 适用于路由逻辑运行在后端、且使用 TypeScript 以外语言的钱包。

## 执行质量至关重要，因为失败损失的是用户自己的钱

> **[Quote Simulation](https://docs.li.fi/enterprise/quote-simulation.md)**
>
> 候选路由在你看到之前就会经过模拟，会回滚的路由会被剔除。一类失败从你的支持工单队列中消失，变成一条从未被提供的路由。

> **[Smart Slippage](https://docs.li.fi/enterprise/smart-slippage.md)**
>
> 根据市场数据为每个代币设置容差，取代固定百分比——固定值对于流动性稀薄的交易对往往过紧，对于稳定交易对又往往过松。

> [!NOTE]
>
> 两者均对所有集成商开放，无需申请权限。但每项功能仍仅适用于符合条件的请求以及覆盖范围内的链和代币，因此请读取返回字段，而不要假定每条路由都经过了模拟或带有推荐值。

## 冷启动问题，以及如何获得收入

首次到达某条链的用户持有资产却没有原生代币，这意味着他们手里没有任何可以操作的东西。[Gas Fronting](https://docs.li.fi/guides/gas-subsidy.md) 会在同一笔交易中将转入资金的一部分兑换为目标链的原生资产，让用户到账即可操作。

> [!WARNING]
>
> Gas Fronting 不适用于合约调用流程或 Composer。如果钱包要构建到账即组合（compose-on-arrival）的功能，需要为该场景单独解决 gas 问题。

通过钱包产生的交易量无需额外建立商业合作关系即可变现。你在报价请求中设置费用百分比，执行时费用会转入你的费用钱包，支持 EVM 链、Tron、Solana、Sui、Bitcoin 和 Stellar。各链系的具体机制请参阅[集成变现](https://docs.li.fi/introduction/integrating-lifi/monetizing-integration.md)。

## 上线前需要决定的事项

> **交换界面是自建还是基于配置**
>
> 采用 Widget 的团队如果之后想要完全掌控，就要面对一次迁移，因为两种方式的形态不同。两种选择都没有错。但决定得太晚，代价会很高。

> **费用放在哪里，以及用户能否看到**
>
> 把费用悄悄计入汇率，等于在等待某位拿你的报价去别处比价的用户找上门来。把费用作为单独一项展示，则是一次性的沟通，在你的界面中、按你的方式完成。

> **到账资产不同时，你的界面如何处理**
>
> 跨链转账可能以中间代币结算，而不是强行完成一笔不划算的最终交易。这是正确的协议行为，但如果没人为此做设计，钱包界面就会让人困惑。请参阅[中间代币](https://docs.li.fi/guides/intermediate-tokens.md)。

> **你愿意在多大程度上约束签名**
>
> 密钥由用户持有，因此你构建的每一道防护都只是用户可以忽略的提示，而不是你能强制执行的策略。尽管如此仍要构建，同时在内部对它们的实际价值保持清醒。

## 从哪里开始

为 Widget 配置一个跨链交易对，并端到端跑通一次交换。花一个下午做这件事，比读一周文档更能让你了解这次集成在产品中的位置。

> **[Widget 概览](https://docs.li.fi/widget/overview.md)**
>
> 配置、主题定制和钱包管理。

> **[SDK 概览](https://docs.li.fi/sdk/overview.md)**
>
> 报价、执行以及各生态的 provider。

> **[集成变现](https://docs.li.fi/introduction/integrating-lifi/monetizing-integration.md)**
>
> EVM、Solana、Sui 和 Bitcoin 的费用机制。

> **[Gas Fronting](https://docs.li.fi/guides/gas-subsidy.md)**
>
> 将转账的一部分兑换为目标链 gas。

> **[联系 LI.FI 团队](https://docs.li.fi/introduction/integrating-lifi/partnership-opportunities.md)**
>
> 告诉我们你支持的链和预期的交换量。我们会为你确定 API 密钥、费用设置，以及适合的执行质量功能。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.