Permissioned Products & Compliance

Some vaults only accept a deposit after their issuer or protocol has authorized it, for example through an allowlist, a compliance check, or a signed permission. Composer API supports deposits into these permissioned vaults. While preparing the transaction, Composer checks the product’s authorization requirements and, when needed, requests authorization data and includes it in the deposit call, so the product’s access controls are enforced rather than bypassed.

​

Availability

• Supported vaults are open to every integrator. The vaults listed in Supported permissioned vaults work through Composer API with no separate vault activation. The usual Composer API authentication requirements still apply; see Quickstart.
• Each new permissioned product is integrated by LI.FI first. Authorization mechanisms differ between products, so LI.FI integrates each product’s authorization service before deposits can route to it. To offer a permissioned vault that is not listed, contact the LI.FI team.

​

Who handles what

​

How the deposit flow works

1. Onboard the user, if required. Direct the user to the issuer’s onboarding process when the product requires it. Some products authorize based on wallet screening and need no separate onboarding step.
2. Request the deposit. Send the flow to POST /compose with the user’s real address, the funding asset, and the destination vault. See Build a Flow for the flow and input bindings. Do not use a placeholder address: Composer derives the user’s execution proxy from it, and authorization is evaluated for that address.
3. Composer checks eligibility and handles authorization. Composer checks whether the deposit is allowed and obtains any authorization data required to prepare it. If the product refuses the deposit, Composer returns an error. Where the product supports existing permissions, Composer can use a valid permission without requesting a new signature. The address whose permission is checked depends on the product; it can be the user’s execution proxy rather than the user’s wallet. The form of the authorization, such as a signature or a permission grant, is set by the product.
4. Composer prepares the transaction. Composer includes any required authorization data in the deposit call, combines it with the funding steps such as swaps, and simulates the result. An HTTP 200 response means the authorization requirements were satisfied during preparation, not necessarily that a new authorization was issued. There is no separate eligibility field to read.
5. Execute and show the outcome. The user signs and submits the transaction, the execution proxy runs the calls, and the protocol verifies the authorization as part of the deposit. For products with delayed settlement, track share delivery separately from the funding transaction.

See Execution Model for how execution proxies and the compile pipeline work.

​

Handling outcomes

Authorization runs while Composer prepares the transaction, so a refused or failed authorization is returned as a ComposeError on POST /compose and no calldata is produced. In the raw HTTP error response, read error.kind and error.message. The latter is human-readable: surface or log it, but do not match its text programmatically. An HTTP 206 response also has success: false and carries partial result data. See Allow-revert mode.

​

How this relates to RWA routing

Three separate layers can affect a deposit into a tokenized real-world asset: This is why outcomes differ between APIs. When the LI.FI quote API declines a permissioned asset, it returns no route together with a reason. Composer API returns a resolution_rejected error instead. See Real World Assets for eligibility checks and the partner RWA policy on the LI.FI API.

​

Supported permissioned vaults

The following permissioned vaults are supported through Composer API. Coverage changes as products are added. Check Supported Protocols & Chains for current routing coverage.

​

Nest

Nest vault share tokens use the same address on every chain listed.

​

Maple Syrup

Maple checks lender permission for the execution proxy, not the user’s wallet. If that proxy is already authorized, Composer uses the existing permission without requesting a new signature. Otherwise, Composer obtains a signature and prepares an authorize-and-deposit call; a single transaction can deposit into only one Syrup pool while the proxy is not yet authorized. Permission is checked again when preparing a later transaction because it can be revoked.

​

Add a permissioned vault