Skip to main content
LI.FI routes tokenized real-world assets: onchain stocks, and permissioned assets whose token contracts govern who may hold and receive them.

​
Onchain Stocks

LI.FI supports tokenized equities from:
  • Ondo
  • xStocks
  • Robinhood
Support for further issuers is coming.

​
How quoting works

LI.FI routes each supported onchain stock through the venues available for that asset and integration. Depending on the asset and current configuration, a quote can use LI.FI Intents or an exchange route. The rwa tag controls the company-policy filter described below; it does not select a venue or guarantee that a quote uses a licensed solver. What this means for your integration:
  • Pricing and coverage are asset-specific. Availability depends on the venues, liquidity, asset rules, and integration configuration available at quote time.
  • Read the returned route. Inspect tool and includedSteps instead of assuming every onchain-stock quote uses the same execution venue.
  • Available directly via the LI.FI API. Onchain stocks use the same quote and route endpoints as other assets; LI.FI selects the available venue underneath. There’s no separate integration to build.

​
Permissioned RWAs

Some real-world assets enforce eligibility at the token level — an allowlist, an identity registry, a jurisdiction check, or a transfer-agent gate. LI.FI resolves that eligibility before returning a route.
1

Detect the asset

LI.FI identifies the token as a permissioned RWA and the rule set it enforces.
2

Run the eligibility check

LI.FI runs the check with LI.FI Composer — onchain, as a call against the token’s allowlist or identity registry, or offchain, against the issuer’s own eligibility source.
3

Return the route, or decline it

If the check passes, the route is returned and executes normally. If it doesn’t, no route is returned and the response carries a message stating why.
Because the rules apply to the receiving address, the same pair can be routable for one user and not another. Pass the actual recipient address on the quote request, not a placeholder.
LI.FI routes within the rules the token enforces. It doesn’t onboard users, perform KYC or AML checks, or grant allowlist status — those remain with the issuer or transfer agent, and with you as the integrator.

​
What you see as an integrator

  • The endpoints you already call. Both asset types are available directly through the LI.FI API. Onchain stocks are quoted through the venue available for that asset, and permissioned RWAs come back with the eligibility check already resolved.
  • A declined route is an eligibility outcome, not an error. Surface the returned message to the user rather than treating it as a failure. Partner policy blocks are a separate case — see Partner RWA policy.
  • Issuer timing still applies. Lock-ups, redemption windows, and settlement schedules are set by the issuer. Routing works within them and can’t shorten them.

​
Scope

  • Assets are supported individually. Coverage is a defined list per asset and issuer rather than open-ended.
  • Recipient address required. Quotes for permissioned assets need the real recipient to resolve eligibility.
  • Availability varies by asset and jurisdiction. Which assets you can offer, and to whom, follows the issuer’s own distribution rules.

​
Partner RWA policy

Separately from per-asset eligibility, a company can set a policy that allows or blocks RWA-tagged tokens on quotes for its integrators. This is compliance gating, not KYC: LI.FI does not onboard the user. It only applies the company’s policy to tokens already tagged rwa.

​
Configure the policy

An authorized company member sets the policy under Settings → Compliance in the LI.FI Partner Portal. New companies are also asked to choose when they first sign in. The choice is company-wide: changing it updates the policy used by all integrators that belong to that company. The Partner Portal may ask you to accept the policy again after its terms change. Until you make a choice, the status is pending; an earlier acceptance of an older policy version appears as accepted_stale.
Configure this policy in the Partner Portal. The underlying company-policy endpoints use Partner Portal authentication and are not part of the public integrator API.

​
How quoting applies the policy

When the quote or route request includes an integrator, LI.FI resolves an allow/block verdict for that integrator before path filtering. Only declined blocks RWA-tagged paths in the current behavior. pending and accepted_stale still allow them; accepted_stale means the company should review and accept the current policy in the Partner Portal. A declined policy does not remove non-RWA paths. Those still quote as usual.
Always send your assigned integrator value on quote and route requests. Without it, LI.FI cannot apply your company’s RWA policy. Do not omit integrator as a way to bypass a declined policy.
Verdicts are cached. A policy change may not apply to the next quote immediately.

​
Which tokens are gated

The filter keys off the token tags array, not a hardcoded address list. LI.FI tags tokens rwa from these CoinGecko categories:
  • ondo-tokenized-assets
  • xstocks-ecosystem
  • backpack-securities-ecosystem
  • robinhood-chain-stocks-ecosystem
Membership follows CoinGecko and can change. Do not infer policy coverage from an issuer name or a static token list. Before quoting, confirm a token is in scope with GET /v1/token and check whether its tags array contains rwa. Example: GET /v1/token?chain=1&token=0x3632dea96a953c11dac2f00b4a05a32cd1063fae returns "tags": ["rwa"] for CRCLon (Ondo tokenized stock). This tagging set is what the policy filter uses. It is not the same as the onchain-stock issuer list above, and it is not a promise that every tagged token is quoted through LI.FI Intents.

​
Responses when the policy blocks RWA

The filter reason is: Path contains RWA token(s) and integrator policy blocks RWA GET /v1/quote — HTTP 404, application code 1002:
POST /v1/advanced/routes — HTTP 200, empty routes, same reason on unavailableRoutes.filteredOut:
/v1/quote does not return a route object on this path. Diagnostics are on the error body’s errors field (filteredOut / failed), not a top-level unavailableRoutes. A successful quote that omitted integrator is not evidence that your company’s RWA policy was evaluated. Error code 1002 is the generic no-quote code, not an RWA-specific code. The filter reason is human-readable diagnostic text: surface or log it, but do not match the exact sentence programmatically. If your application needs a stable machine-readable RWA-policy error, contact the LI.FI team rather than treating this text as an enum.
Do not treat a policy block as a permissioned-asset eligibility failure. Eligibility is about the recipient address and the token’s own rules. A policy block is the integrator’s company declining RWA-tagged tokens.

​
Availability

RWA coverage and policy controls vary by asset and integration. A token carrying the rwa tag does not by itself guarantee that it is available to your integration or jurisdiction.

Contact the LI.FI team to enable

Tell us which tokenized assets and issuers you work with, and the chains you need them on. We confirm coverage and availability for your integration.

​
For RWA issuers

If you issue a tokenized asset, LI.FI can add it as a supported asset and make it reachable from the wallets, exchanges, and fintech apps already integrated with LI.FI. Users buy in with whatever they hold, on whatever chain they hold it, and your asset’s transfer rules are enforced as part of routing. Distribution is set up per asset. LI.FI’s team scopes it with you: the asset and its transfer rules, the chains it’s live on, and the jurisdictions you distribute into.

Talk to LI.FI sales

Get in touch about listing your asset. Share the asset, its transfer rules, and the chains it’s live on, and we’ll scope distribution across LI.FI’s integrator network.