Skip to main content
LI.FI Composer API 让你将一个多步骤的 DeFi 操作描述为一份名为 Flow 的单一不可变文档，然后将其编译成在链上原子性执行的 EVM calldata。一个 Flow 可以将交换、存入、授权、奖励领取、金库 zap 以及跨协议移动串联起来，全部通过一笔签名交易完成。 Composer API 是显式的编写界面：@lifi/composer-sdk 包和 POST /compose 端点。

​
什么是 Flow？

一个 Flow 是一份不可变的 JSON 文档，描述：
  • Inputs。 你的 flow 所消费的资源（代币）和标量值。输入名称由你来选。
  • Calls。 对具名 op（lifi.swap、lifi.zap、core.call、core.add 等）的有序调用，带有带类型的输入和输出。每个 call 都有一个用户定义的 id，供下游 call 引用，从而将输出贯穿整个 flow。
  • Guards。 逐 call 的不变量 —— 滑点下限、相等性断言以及其他安全检查 —— 由 VM 在执行期间强制执行。Guard 在编译时被烘焙进 calldata；如果某个 guard 将会失败，模拟会在用户签名之前将其显现出来。
  • Refs。 call、input 和运行时上下文（sender、执行地址）之间的交叉引用。
你用 SDK 构建一个 Flow，将它传给 POST /compose，然后收到可供你的钱包签名的 calldata。

​
账户模型

Composer 从不将你的资金保管在一个共享合约中。相反，每个签名者都拥有自己的执行代理（execution proxy）：
  • 确定性。 代理地址由代理工厂根据签名者的地址派生（CreateX CREATE3），因此给定的签名者在给定链上始终映射到同一个代理。SDK 将其暴露为 builder.context.executionAddress，编译响应则将其作为 userProxy 返回。
  • 你与自己的代理交互，而非 VM。 已签名交易的 to 是你的代理（或在代理首次使用时是代理工厂，它会部署代理并原子性地运行 flow）。代理会 delegatecall 共享的 VM，因此 VM 的逻辑在你自己代理的存储和余额上下文中运行 —— 这正是资金存放在代理上的原因。
  • 访问受控。 只有签名者才能驱动自己的代理 —— 执行受 msg.sender 门控，因此没有其他人能针对你的代理运行 flow 或转移其余额。
  • 资金默认原地不动。 在一个 flow 期间，代理持有代币并在各步骤之间传递它们。资金可以离开代理 —— 设置 sweepTo 即可将终端余额发送给签名者（或任何地址）—— 但如果你不扫走，任何剩余余额都会留在代理上。这是有意为之：稍后的一个 flow 可以将其取用（例如使用 balanceOf materialiser），让你能够跨多次提交累积或暂存资金。
有关 sweepTo 如何决定什么离开代理，请参见 Terminal Resources；有关每条链上的代理工厂地址，请参见 Addresses。

​
机器可读文档

Composer 后端以两种对 LLM 友好的格式提供其自身的文档，以便 AI 智能体和编码助手能够直接加载该 API 界面。两者都相对于你的 Composer 基础 URL（默认 https://composer.li.quest）提供：

​
接下来去哪里

Quickstart

安装 SDK，并在五分钟内编译你的第一个 Flow。

Concepts

Flow 结构、引用、资源模型、执行模型。

Recipes

按集成方类型分组的可复制粘贴 flow。