Skip to main content
The /tokens endpoint returns LI.FI’s curated token list, updated daily from sources such as DeBank and CoinMarketCap. Tokens in this list may carry a verificationStatus of verified, unverified, or flagged; integrators should apply this metadata according to their own risk policies.To include a custom token, submit a pull request to: lifinance/customized-token-list
Yes. In addition to the curated sources above, LI.FI screens tokens with Hypernative’s token reputation API and stores each token as verified, unverified, or flagged. Flagged tokens are omitted from wallet balance responses, but they can still appear in /tokens with verificationStatus set. Do not assume this screening result defines routing eligibility.See Token risk screening with Hypernative for details on how this screening works and its coverage limitations.
LI.FI can discover many newly launched tokens on supported chains through two methods, subject to available liquidity and routing:
  • If requested by token address, LI.FI searches on-chain and finds available liquidity.
  • If listed in the default /tokens endpoint, the token becomes searchable by name on jumper.exchange.
To avoid filtering new tokens due to missing USD prices, set:
For best results, notify LI.FI in advance of token launches.
Not currently. The Jupiter API sends tokens to the same address used to initiate the swap.
To include tokens in your own integration, use the widget’s tokens option. See the widget documentation for details.To request a token listing across LI.FI’s API and Jumper globally, submit a pull request to: lifinance/customized-token-list
  • Token coverage: All tokens supported by Jupiter are available.
  • New token listings: Tokens added by Jupiter are typically available within one day.
  • Fee collection: Use the same fee parameter as for EVM chains. Fees are sent directly to your wallet.
LI.FI ships curated token lists from supported exchanges and bridges with spam filtering. Users can still paste any token address, but defaults avoid promoting spam tokens.
LI.FI does not treat every transfer tax as a hard block. On chains where tax data is available, quotes use deployment-configured thresholds:
  • Rejected: if the token’s buy tax or sell tax is at or above the configured upper limit, the token is rejected by this check. GET /v1/quote then returns HTTP 404 with application code 1002 (NoQuoteError). POST /v1/advanced/routes returns HTTP 200 with an empty routes array; failed-tool messages include Token has buy or sell tax above acceptable upper cap.
  • Quoted with tax in the amounts: a tax below the upper limit does not by itself block the token, but a quote still requires sufficient liquidity, a supported tool, and compliance with other routing checks. For taxes at or above 0.1%, the default adjustment reduces both estimate.toAmount and estimate.toAmountMin by the known buy/sell tax to account for the expected on-chain deduction. Quoted amounts can therefore look lower than a gross-of-tax aggregator even when the slippage parameter matches. Whether this adjustment is enabled depends on deployment configuration; always use the returned toAmount / toAmountMin rather than recomputing minReturn from slippage alone.
  • Negligible tax: below 0.1%, no separate tax adjustment is applied.
This amount adjustment assumes uniform transfer taxes. It does not fully account for dynamic or per-pool taxes, and unavailable or stale tax data may not be reflected in the quote. Tokens on chains without tax screening are not rejected by this gate. A tax-lookup outage fails open (no extra reduction) rather than failing every quote. Returned amounts are estimates based on the available tax data, not a guarantee that every transfer tax has been detected.See also Slippage and price impact.