这对你的产品意味着什么
报出你将交付的金额
固定输出金额，响应会告诉你付款方需要支出多少。界面上没有区间，也没有需要你自行承担的差额。
更小的失败面
未成交的订单会自动退款，状态最终归入一小组确定的状态，而不是一个开放式的状态集合。
执行不再是你的配置
桥的选择和流动性深度都由求解器的承诺来兜底，而不是变成由你负责的设置和需要你解释的失败。
可以向合规部门说明的求解器网络
求解器需要通过企业验证和筛查才能加入，而不是匿名加入。
路由返回的是估算值。订单返回的是承诺。
为什么常规方式会陷入困境
估算值会让做出承诺的产品失灵。一个向客户报出某个数字、最终却交付略有不同金额的产品，只有两个选择，而且都不好：向客户展示一个区间，或者自己承担差额。区间报价会在它出现的每个界面上侵蚀信任。自行承担差额在一段时间内可行，直到交易量让它成为成本结构中最大的一项。 在这之下还有一个控制问题。传统路由会暴露执行的机制，这意味着你的产品也会继承这些机制。桥的选择、流动性深度，以及保护交易的滑点容差，全都变成了由你负责的配置，因此也成了需要你解释的失败。每增加一条新链都会扩大这个面，而这些都不是客户真正要购买的东西。是订单，而不是路由
LI.FI Intents 在单个报价请求背后运行一个求解器市场。你描述要支出的输入和希望交付的输出，相互竞争的求解器返回报价，胜出的报价附带一笔在链上开启订单的交易。此后，求解器的工作就是按其报价条款完成填充。精确输出
固定必须到账的金额，输入保持开放。适用于所有目标金额本身就是一项承诺的流程：结清发票、偿还持仓、满足合约的预期金额。
精确输入
固定支出金额，由求解器确定输出。这是支出金额固定时的常见模式。
报价带有有效期。其定价是为了立即开启订单，而不是缓存下来稍后重放。
属于策略而非底层管道的部分
有两项能力对受监管产品很重要，但由于看起来像配置项而容易被忽视。网络中的求解器需要通过企业验证和筛查才能加入，这决定了你拥有的是一个可以向合规部门说明的执行网络，还是一个无法说明的执行网络。此外，报价请求可以限定为指定的求解器地址，这让求解器的选择成为你可以按司法辖区或合作关系来设定的事项。 不同链的覆盖情况存在差异，值得在设计定型前确认。链下订单提交（用户无需发送交易）在 EVM 链上可用，但在 Solana 或 Tron 上不可用，在这些链上订单总是由签名方在链上开启。资源锁定结算同样仅支持 EVM。围绕完全免 gas 开启订单而设计的产品，在不支持该方式的链上需要采用不同的流程。上线前需要做出的决定
按流程选择精确输入或精确输出
按流程选择精确输入或精确输出
大多数产品两者都需要。那些为整个产品只选定单一模式的团队，通常选的是最适合他们构建的第一个功能的那种模式。
用你自己的语言，向客户说明退款意味着什么
用你自己的语言，向客户说明退款意味着什么
协议通过退还资金来处理失败的订单。这在界面上呈现为已取消、已退回还是请重试，是一个产品决策，而用错的措辞总会在最糟糕的时刻出现。
你的求解器限制策略及其理由
你的求解器限制策略及其理由
如果限制是出于合规原因，这个理由应该经得起追问。如果限制只是因为感觉更安全，那它就是在白白牺牲成交可靠性。
如何在界面中处理报价过期
如何在界面中处理报价过期
报价在展示与确认之间过期是一种正常情况，而不是错误。把它当作错误处理的产品，会让客户学会不信任这个数字。
从哪里开始
针对你的产品已在运行的一条路由，以精确输出模式请求一次报价，并将它要求的输入与你当前路径交付相同金额的实际成本进行比较。这一次比较通常比一场架构讨论更快地得出结论。Intents 快速入门
从第一个请求一直到结算。
请求报价
交换模式、求解器限制以及各链的地址格式。
追踪状态
状态值及其轮询方式。
架构概览
输入结算、输出结算和预言机验证。
联系 LI.FI 团队
带上那些交付金额本身就是合约条款的流程。我们会与你一起确定适合的结算路径和链。