> ## 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.
# Composer 101
> LI.FI Composer 如何将合作伙伴的请求转化为单笔链上交易 —— 架构、流水线与各个组件。
LI.FI **Composer** 是面向多步骤 DeFi flow 的链上执行引擎。它让你的用户能够在单笔已签名交易中完成一系列交换、存入、校验和协议调用 —— 在任何受支持的 EVM 链上。
在幕后，Composer 是一个类型化的 VM（虚拟机）。从合作伙伴的角度看，它的区别在于：要么让你的用户签署三到五笔交易才能存入一个收益策略，要么让他们只签一次。
## 架构
Composer 将合作伙伴的请求 —— *"将 USDC 存入 Base 上的 Aave"*（通过 LI.FI API）或一份类型化的 Flow 文档（通过 Composer API）—— 转化为单笔可执行的链上交易。整个系统由三个模块化层组成：
### 1. 链上 VM
一份部署在每条受支持 EVM 链上的智能合约，持有共享的执行逻辑。每个用户都拥有自己的确定性 **proxy**，用来持有其代币并对 VM 执行 `delegatecall`，因此 flow 会在用户自己的余额和存储上下文中运行。以这种方式被调用时，VM 可以：
* 调用任何其他链上协议或一系列协议。
* 将某一步的输出作为下一步的输入传递。
* 在各步骤之间处理代币授权、转账和余额检查。
* 在单条链内以原子方式执行整个序列。
用户签署**一笔**指向其 proxy 的交易（或者，在 proxy 首次使用时，指向 proxy 工厂，由工厂部署 proxy 并原子化地运行 flow）。随后 proxy 会以编译后的 flow 作为 calldata 对 VM 执行 `delegatecall`。关于 proxy 如何派生以及访问控制方式，参见 [Account model](/composer/composer-api/overview#account-model)。
**VM 合约：** [`0xb57Ce43Be47DF611C98EB0943e5D36EBDb36cc6D`](https://etherscan.io/address/0xb57Ce43Be47DF611C98EB0943e5D36EBDb36cc6D) —— proxy delegatecall 所调用的共享逻辑，*而不是*交易的 `to`。在每条受支持的链上地址相同。完整的部署列表参见 [Addresses](/composer/composer-api/reference/addresses)。
### 2. eDSL 与编译器
一个用于表达合约交互的类型化嵌入式 DSL（TypeScript）。当 Composer 被调用时：
1. 路由引擎识别出需要哪些协议和操作。
2. eDSL 将这些交互表达为一个类型化程序。
3. 编译器将该程序转换为 VM 可执行的字节码。
这提供了类型安全性、可组合性，以及在编译期优化执行路径的能力。校验、降级（lowering）和策略检查都在返回任何 calldata 之前，在这一层完成。
### 3. 运行时值传递
许多 DeFi 操作需要一个在前一步运行之前无法得知的值 —— 例如，存入从前一步交换中收到的\_确切\_数量的代币。Composer 不会在链下预先计算中间数量，而是将一步的输出传入下一步：
* Flow 记录了每次调用的输出如何馈送到后续调用的输入（通过 refs）。
* VM 会**在运行时对每次调用的 calldata 进行编码**，读取由前面步骤产生的具体值，并将它们写入后续步骤的参数中。
* 这一切完全在链上、在同一笔交易内完成。
这正是让链式 `swap → deposit` 无需集成方预先计算中间数量即可实现原子性的原因。
## 交易生命周期
Composer API（由你编写 Flow）和 LI.FI API 集成（由后端构建 Flow）共享同一条执行路径：
| 步骤 | 发生了什么 | 位置 |
| ------------ | ----------------------------------------------------------------------------------------- | -------------- |
| **1. 请求** | 你的应用提交一个 Flow（通过 Composer API），或提交将 `toToken` 设置为某个 vault 的 `/v1/quote`（通过 LI.FI API）。 | Client → API |
| **2. 路由优化** | LI.FI 的路由引擎在各个 DEX 与协议之间找到最优路径。 | API |
| **3. 编译** | 编译器根据解析后的 Flow 生成 VM 字节码。 | API |
| **4. 执行前模拟** | 对编译后的 flow 进行模拟以验证执行；失败会在返回 calldata *之前* 以结构化错误的形式暴露出来。 | API |
| **5. 响应** | API 返回 `transactionRequest`（calldata）、`producedResources`（模拟输出），以及签名者必须授予的任何 `approvals`。 | API → Client |
| **6. 提交** | 你的用户签名一次并广播该交易。 | Client → Chain |
| **7. 链上执行** | VM 以原子方式执行字节码。所有步骤要么全部成功，要么全部不执行。 | Chain |
| **8. 确认** | 交易被确认；产生的仓位落入用户的钱包。 | Chain → Client |
## 执行前模拟
每个 Compose 请求都会在向客户端返回 calldata *之前*，针对当前链状态进行端到端模拟。模拟器以被覆盖的余额和授权来运行（因此缺失的用户授权不会导致模拟失败），从而让它专注于链上实际会出错的地方。这可以捕获：
* 会超出容差滑动的代币交换。
* 会回滚的 vault 交互（已暂停、达到上限、被列入黑名单）。
* 池中流动性不足以完成该交换规模。
如果模拟失败，API 会返回结构化错误，而不是一笔会在链上回滚的交易。合作伙伴省下了原本会浪费在失败交易上的 gas；用户也避免签署注定失败的东西。
关于模拟步骤在流水线中的确切位置，参见 [Execution Model](/composer/composer-api/concepts/execution-model)；关于观测到的值如何变成链上断言，参见 [Guards](/composer/composer-api/concepts/simulation-and-guards)；关于各种失败模式，参见 [Error codes](/composer/composer-api/reference/error-codes)。
## 同链与跨链
Composer 的行为会因源端和目标端是否在同一条链上而有所不同：
* **同链。** 所有步骤在一笔交易内以原子方式执行。模拟保证：如果模拟通过，执行将会成功（除极端边缘情况外，例如激进的内存池抢跑）。一次签名、一次 gas 支付、一个区块。
* **跨链（目前仅限 LI.FI API 集成）。** 源链交易触发桥接；随后目标链的操作再执行。每个阶段在其所在链内是原子的，但整个 flow 是最终一致的。总耗时取决于桥接延迟。跨链进度通过 LI.FI 的 `/status` 端点进行跟踪。
目前，Composer API Flow 的作用域限定在每个 Flow 单个 `chainId`；多链 Flow 尚未通过 Composer API 开放。如果你需要跨链组合，参见 [Integrate via LI.FI API](/composer/lifi-api/overview)。
## 接下来去哪里
Composer 面向谁、你能构建什么，以及 Composer API 与 LI.FI API 的对比。
五分钟内编写你的第一个 Flow。
将 Composer 添加到你现有的 LI.FI 集成中。