> ## 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. # Offer Tokenized Equities Without a Licensing Desk > Offer tokenized equities and permissioned assets without building a licensing desk or a compliance router. Adding tokenized real-world assets to a product usually stalls on two things you can't build your way past: the counterparty has to be licensed to trade the asset, and the asset itself decides who may hold it. LI.FI resolves both before it returns a route, so you can list the asset class as a product feature rather than a compliance project. ## What this changes for your product > **A new asset class you can offer** > > Onchain equities are quoted through the same API you already call, using the venues available for each asset, so offering them isn't gated on you standing up a trading desk. > **Failures that never reach the user** > > Eligibility resolves before a route is returned, so an ineligible user sees a reason instead of a reverted transaction and a support ticket. > **No second integration** > > Permissioned assets and open ones arrive through one API surface, which keeps a regulated product line from becoming a separate codebase. > **Users buy in from what they hold** > > A user funds a position from any supported asset on any supported chain, so the addressable buyer isn't limited to people already holding the settlement asset. ![An asset and the rule it enforces, resolved before a quote, returning either a route or a decline with a reason](https://mintcdn.com/lifi/PmU0d85L8IwCXHK-/images/use-cases/rwa-eligibility-gate.png?fit=max\&auto=format\&n=PmU0d85L8IwCXHK-\&q=85\&s=5e3516f4aeb9a16aee26e4df13ee1ed4) Eligibility is resolved before a route exists. ## Why ordinary routing breaks here Most cross-chain routing assumes any address can receive any token. Tokenized real-world assets break that assumption on purpose, and they break it in two different ways. > **Pricing** > > A tokenized equity can't trade through an open liquidity pool, because the counterparty has to be licensed to trade it. There is no pool depth to quote against, so the usual machinery for finding a price doesn't apply. > **Permission** > > A permissioned asset carries its own rule set: an allowlist, an identity registry, a jurisdiction check, a transfer-agent gate. The rule attaches to the receiving address, so the same pair is routable for one of your users and not for the next one. A router that ignores either one produces routes that revert. Your user pays gas for a failed transaction and then contacts you about it, which is the expensive version of a rule you could have checked first. > [!WARNING] > > A route that looks valid in a test with a placeholder address will fail in production against a real recipient. Eligibility is resolved against the address you pass, so pass the real one. ## How the two families resolve Onchain stocks are routed through the venues available for each asset and integration. Depending on the asset and current configuration, a quote can come from [LI.FI Intents](https://docs.li.fi/lifi-intents/introduction.md), the intent and solver marketplace, or from an exchange route, so coverage moves as venues and their permissions change. Don't assume a given quote came from a licensed solver. All of it arrives through the LI.FI API you already call, so there is no second integration to build. Permissioned assets resolve differently. **1. Detect the asset** LI.FI identifies the token and the rule set it enforces. **2. Run the eligibility check** The check runs with [Composer](https://docs.li.fi/composer/overview.md), either on-chain as a call against the token's allowlist or identity registry, or off-chain against the issuer's own eligibility source. **3. Return the route, or decline it** If the check passes, the route comes back and executes like any other route. If it doesn't, no route comes back and the response carries a message saying why. > [!NOTE] > > A declined route is an eligibility outcome, so show the user the returned message. A generic error screen turns a solvable problem, usually an incomplete onboarding step, into a support ticket. See [Real World Assets](https://docs.li.fi/enterprise/real-world-assets.md) for the supported issuers and the current asset coverage. > [!NOTE] > > Separately from per-asset eligibility, your company can set a policy in the Partner Portal that allows or blocks RWA-tagged tokens on your quotes. A declined policy drops every path that touches an `rwa`-tagged token. Send your `integrator` value on every quote so the policy can be applied. See [Partner RWA policy](https://docs.li.fi/enterprise/real-world-assets.md#partner-rwa-policy). ## What the compliance surface covers Intents lets you restrict quotes to specific solver addresses, which is how a regulated platform keeps its order flow inside a set of counterparties it has approved. LI.FI's solver network is built on verified legal entities rather than anonymous addresses, and screening is applied so only compliant wallets interact with your product. Use the restriction with care: narrowing the solver set too far reduces fill reliability, because fewer counterparties are quoting your flow. > [!WARNING] > > The boundary a compliance team asks about first is what LI.FI doesn't do. LI.FI routes within the rules the token enforces. It doesn't onboard users, run KYC or AML checks, or grant allowlist status. Those stay with the issuer, the transfer agent, and you. ## What to decide before launch > **Pass the real recipient on every quote** > > Eligibility is resolved against the receiving address, so a placeholder answers a question about the wrong person. This is the single most common cause of a route that works in staging and fails in production. > **Plan around issuer timing, not routing speed** > > Lock-ups, redemption windows, and settlement schedules are set by the issuer. Routing works inside them and can't shorten them, and an interface that implies otherwise will generate complaints you can't resolve. > **Treat coverage as a list you confirm** > > Assets are supported individually per asset and issuer, and which ones you can offer, and to whom, follows the issuer's own distribution rules. Confirm your specific assets and jurisdictions before you scope the feature, not after. ## If you are the issuer The same infrastructure runs in the other direction. LI.FI can add a tokenized asset as a supported asset and make it reachable from the wallets, exchanges, and fintech apps already integrated, with the asset's transfer rules enforced as part of routing. Users buy in with whatever they hold, on whatever chain they hold it, and no integrator has to do anything on their side. See [Issuers and New Chains](https://docs.li.fi/introduction/use-cases/issuers-and-chains.md). ## Where to start RWA routing is an enterprise feature, enabled per integrator and per asset, so the first step is a conversation rather than a call. From there the integration is the API you already use. > **[Real World Assets](https://docs.li.fi/enterprise/real-world-assets.md)** > > Supported issuers, permissioned-asset handling, and the eligibility flow in detail. > **[LI.FI Intents](https://docs.li.fi/lifi-intents/introduction.md)** > > How the solver marketplace matches an intent to a quote. > **[Enable RWA routing for your integrator key](https://li.fi/contact-us/)** > > Tell us which tokenized assets and issuers you work with, and the chains you need them on. We confirm coverage and enable it for your key. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.