Skip to main content
LI.FI integrates Hypernative’s token reputation API into the LI.FI Core backend to classify tokens and provide an additional risk signal. Tokens are stored as verified, unverified, or flagged. Flagged tokens are omitted from wallet balance responses; other token endpoints can still return them with verification metadata.

​
What Hypernative does

Hypernative provides a token screening API that accepts token identifiers and returns a verdict on the token’s risk status. LI.FI uses this to augment its existing token validation pipeline with an additional layer of security. Key characteristics:
  • Tokens are screened via Hypernative’s token reputation API endpoint.
  • The primary output is a classification verdict, surfaced in LI.FI’s token metadata as one of three states: verified, unverified, or flagged.
  • A flagged verdict does not necessarily mean a token is fraudulent. Hypernative may flag tokens based on certain market conditions or other risk signals.
Hypernative’s provider result is mapped into LI.FI’s three-state model: accept becomes verified, deny becomes flagged, and an unavailable or unsupported screening result remains unverified.
A verified status reflects an accepted provider result. It is not a guarantee that a token is safe, liquid, or suitable for a transaction.

​
How LI.FI uses Hypernative

LI.FI integrates Hypernative directly into the Core backend token validation stack used by LI.FI’s token services. At a high level:
  • Tokens in LI.FI’s internal token collection are periodically screened via the Hypernative token reputation API.
  • The screening result is stored as part of each token’s metadata inside LI.FI’s backend as a verified / unverified / flagged status.
  • That metadata is exposed downstream so integrators can filter or annotate tokens based on Hypernative’s verdicts.

​
Operational impact

Hypernative screening is not purely informational, but the proven enforcement is narrow:
  • Wallet balance responses omit flagged tokens.
  • GET /tokens still returns flagged tokens, with verificationStatus and verificationStatusBreakdown on the token object so integrators can apply their own filters.
  • POST /v1/tokens/lookup reports status: "flagged" and omits the token body.
Do not infer from balance filtering that every routing surface rejects flagged source, destination, or intermediate tokens. Routing enforcement is not part of the public contract documented here. Verified and unverified tokens can continue to be surfaced normally. Unverified means LI.FI does not currently store a verified or flagged verdict; this can include pending, unavailable, or unsupported screening, and does not mean the token has been assessed as safe or risky.

​
Coverage

Actual screening coverage depends on LI.FI’s deployed configuration and Hypernative’s provider support. Tokens without a usable result remain unverified and continue through LI.FI’s other validation processes.

​
Rate limits and screening strategy

Not every token query results in an immediate live Hypernative lookup. LI.FI relies on cached screening results for known tokens. Newly discovered tokens may have a short delay before a Hypernative verdict becomes available — until a verdict is produced, a token is treated as unverified.
Treat Hypernative-related fields as “best effort” rather than guaranteed for every token at all times. Design your clients and backends accordingly.

​
Exposed metadata

LI.FI token metadata can include the aggregate verificationStatus and a provider breakdown. LI.FI currently exposes the normalized verdict, but does not expose a human-readable reason for a Hypernative decision.

​
Behavior in LI.FI APIs and SDKs

Flagged tokens are omitted from wallet balance responses, as described in Operational impact above. Other token endpoints may still return flagged assets with verification metadata. Where that metadata is present, integrators can use it as an additional signal in their own business logic.

​
Limitations and considerations

While Hypernative significantly improves token safety, it is not a replacement for full due diligence.
Hypernative’s reputation coverage may not include every supported chain or every token on a covered chain, especially newly deployed or illiquid assets.
There may be delays between token creation and the availability of a Hypernative verdict due to rate limits.
As with any reputation system, there is a non-zero risk of misclassification. Treat a flagged verdict as a risk signal, not a completed investigation.
Treat Hypernative metadata as one strong signal in a broader risk management strategy, alongside your own policies and any additional security tools.

​
Getting support

If you have questions about interpreting Hypernative-based metadata or want to understand how to integrate this into your existing LI.FI setup:
  • Reach out via your existing LI.FI partner channel or enterprise support contact.
  • Refer to the Hypernative documentation for details on the underlying token reputation API.
For issues relating to missing or unexpected screening results, share the token address, chain ID, and a timestamped example request so the LI.FI team can investigate how the Hypernative integration handled that asset.