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

# 报出你实际交付的金额

> 明确必须到账的金额，并让求解器承诺交付该金额，而不是报出一个估算值。

大多数路由方式要求你描述转账应如何进行，然后返回一个预计到账金额的估算值。意图则把这一点颠倒过来。你说明必须到账的金额，求解器承诺交付，而路径则成为求解器的问题。

## 这对你的产品意味着什么

> **报出你将交付的金额**
>
> 固定输出金额，响应会告诉你付款方需要支出多少。界面上没有区间，也没有需要你自行承担的差额。

> **更小的失败面**
>
> 未成交的订单会自动退款，状态最终归入一小组确定的状态，而不是一个开放式的状态集合。

> **执行不再是你的配置**
>
> 桥的选择和流动性深度都由求解器的承诺来兜底，而不是变成由你负责的设置和需要你解释的失败。

> **可以向合规部门说明的求解器网络**
>
> 求解器需要通过企业验证和筛查才能加入，而不是匿名加入。

![对比：经路由的转账产生一个估算输出，而意图订单的输出是固定的，并由求解器承诺完成填充](https://mintcdn.com/lifi/PmU0d85L8IwCXHK-/images/use-cases/intent-order-commitment.png?fit=max\&auto=format\&n=PmU0d85L8IwCXHK-\&q=85\&s=dfd6920e2fe4cbd629335e6132ac4456)

路由返回的是估算值。订单返回的是承诺。

## 为什么常规方式会陷入困境

估算值会让做出承诺的产品失灵。一个向客户报出某个数字、最终却交付略有不同金额的产品，只有两个选择，而且都不好：向客户展示一个区间，或者自己承担差额。区间报价会在它出现的每个界面上侵蚀信任。自行承担差额在一段时间内可行，直到交易量让它成为成本结构中最大的一项。

在这之下还有一个控制问题。传统路由会暴露执行的机制，这意味着你的产品也会继承这些机制。桥的选择、流动性深度，以及保护交易的滑点容差，全都变成了由你负责的配置，因此也成了需要你解释的失败。每增加一条新链都会扩大这个面，而这些都不是客户真正要购买的东西。

## 是订单，而不是路由

[LI.FI Intents](https://docs.li.fi/lifi-intents/introduction.md) 在单个报价请求背后运行一个求解器市场。你描述要支出的输入和希望交付的输出，相互竞争的求解器返回报价，胜出的报价附带一笔在链上开启订单的交易。此后，求解器的工作就是按其报价条款完成填充。

> **精确输出**
>
> 固定必须到账的金额，输入保持开放。适用于所有目标金额本身就是一项承诺的流程：结清发票、偿还持仓、满足合约的预期金额。

> **精确输入**
>
> 固定支出金额，由求解器确定输出。这是支出金额固定时的常见模式。

失败有确定的形态，而不是开放式的。未成交的订单会自动退款，状态接口只报告一小组状态，涵盖已签名、已交付、已结算和已退款，因此你的产品所依据的状态机足够简短，便于推理。

> [!NOTE]
>
> 报价带有有效期。其定价是为了立即开启订单，而不是缓存下来稍后重放。

## 属于策略而非底层管道的部分

有两项能力对受监管产品很重要，但由于看起来像配置项而容易被忽视。网络中的求解器需要通过企业验证和筛查才能加入，这决定了你拥有的是一个可以向合规部门说明的执行网络，还是一个无法说明的执行网络。此外，报价请求可以限定为指定的求解器地址，这让求解器的选择成为你可以按司法辖区或合作关系来设定的事项。

> [!WARNING]
>
> 限制求解器是一项真正的权衡，而不是一个没有代价的设置。缩小求解器集合会缩小竞争你订单的求解器池，从而降低成交可靠性，并可能拉大价差。请审慎地进行限制，并确保理由站得住脚。

不同链的覆盖情况存在差异，值得在设计定型前确认。链下订单提交（用户无需发送交易）在 EVM 链上可用，但在 Solana 或 Tron 上不可用，在这些链上订单总是由签名方在链上开启。资源锁定结算同样仅支持 EVM。围绕完全免 gas 开启订单而设计的产品，在不支持该方式的链上需要采用不同的流程。

## 上线前需要做出的决定

> **按流程选择精确输入或精确输出**
>
> 大多数产品两者都需要。那些为整个产品只选定单一模式的团队，通常选的是最适合他们构建的第一个功能的那种模式。

> **用你自己的语言，向客户说明退款意味着什么**
>
> 协议通过退还资金来处理失败的订单。这在界面上呈现为已取消、已退回还是请重试，是一个产品决策，而用错的措辞总会在最糟糕的时刻出现。

> **你的求解器限制策略及其理由**
>
> 如果限制是出于合规原因，这个理由应该经得起追问。如果限制只是因为感觉更安全，那它就是在白白牺牲成交可靠性。

> **如何在界面中处理报价过期**
>
> 报价在展示与确认之间过期是一种正常情况，而不是错误。把它当作错误处理的产品，会让客户学会不信任这个数字。

## 从哪里开始

针对你的产品已在运行的一条路由，以精确输出模式请求一次报价，并将它要求的输入与你当前路径交付相同金额的实际成本进行比较。这一次比较通常比一场架构讨论更快地得出结论。

> **[Intents 快速入门](https://docs.li.fi/lifi-intents/quickstart.md)**
>
> 从第一个请求一直到结算。

> **[请求报价](https://docs.li.fi/lifi-intents/intents-api/request-quote.md)**
>
> 交换模式、求解器限制以及各链的地址格式。

> **[追踪状态](https://docs.li.fi/lifi-intents/intents-api/track-status.md)**
>
> 状态值及其轮询方式。

> **[架构概览](https://docs.li.fi/lifi-intents/architecture/overview.md)**
>
> 输入结算、输出结算和预言机验证。

> **[联系 LI.FI 团队](https://docs.li.fi/introduction/integrating-lifi/partnership-opportunities.md)**
>
> 带上那些交付金额本身就是合约条款的流程。我们会与你一起确定适合的结算路径和链。


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