Skip to main content
The LI.FI Composer API lets you describe a multi-step DeFi operation as a single immutable document called a Flow, then compile it into EVM calldata that executes atomically on-chain. A Flow can chain swaps, deposits, approvals, rewards claims, vault zaps, and cross-protocol moves, all through one signed transaction. The Composer API is the explicit authoring surface: the @lifi/composer-sdk package and the POST /compose endpoint.

​
What is a Flow?

A Flow is an immutable JSON document describing:
  • Inputs. The resources (tokens) and scalar values your flow consumes. You pick the input names.
  • Calls. Ordered invocations of named ops (lifi.swap, lifi.zap, core.call, core.add, and so on) with typed inputs and outputs. Each call has a user-defined id that downstream calls reference to thread outputs through the flow.
  • Guards. Per-call invariants — slippage floors, equality assertions, and other safety checks — that the VM enforces during execution. Guards are baked into the calldata at compile time; if a guard would fail, the simulation surfaces it before the user signs.
  • Refs. Cross-references between calls, inputs, and runtime context (sender, execution address).
You build a Flow with the SDK, pass it to POST /compose, and receive calldata ready for your wallet to sign.

​
Account model

Composer never holds your funds in a shared contract. Instead, each signer gets their own execution proxy:
  • Deterministic. The proxy address is derived by the proxy factory from the signer’s address (CreateX CREATE3), so a given signer always maps to the same proxy on a given chain. The SDK exposes it as builder.context.executionAddress, and the compile response returns it as userProxy.
  • You transact with your proxy, not the VM. The signed transaction’s to is your proxy (or the proxy factory on the proxy’s first use, which deploys it and runs the flow atomically). The proxy delegatecalls the shared VM, so the VM’s logic runs in your proxy’s own storage and balance context — which is exactly why the funds live on the proxy.
  • Access-controlled. Only the signer can drive their own proxy — execution is gated on msg.sender, so no one else can run a flow against your proxy or move its balances.
  • Funds stay put by default. During a flow the proxy holds tokens and passes them between steps. Funds can leave the proxy — set sweepTo to send terminal balances to the signer (or any address) — but if you don’t sweep, any remaining balance stays on the proxy. That’s deliberate: a later flow can pick it up (e.g. with the balanceOf materialiser), letting you accumulate or stage funds across submissions.
See Terminal Resources for how sweepTo decides what leaves the proxy, and Addresses for the proxy factory address per chain.

​
Machine-readable docs

The Composer backend serves its own documentation in two LLM-friendly formats, so AI agents and coding assistants can load the API surface directly. Both are served relative to your Composer base URL (default https://composer.li.quest):
ResourcePathDescription
llms.txt/llms.txtA structured index of the Composer API — sections and links, curated for LLM consumption.
llms-full.txt/llms-full.txtThe full documentation content expanded into a single file.

​
Where to go next

Quickstart

Install the SDK and compile your first Flow in five minutes.

Concepts

Flow structure, references, resource model, execution model.

Recipes

Copy-pasteable flows grouped by integrator type.