Skip to main content
LI.FI integrates Hypernative’s token reputation API into the LI.FI Core backend to automatically detect and filter risky or unverified tokens from the LI.FI token universe. This integration is part of LI.FI’s Enterprise Readiness initiative and is designed to improve the safety of swaps, bridges, and on-chain interactions built on top of LI.FI.

What Hypernative does

Hypernative provides a token screening API that accepts token identifiers and returns a verdict on whether the token should be accepted or denied. 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: Accept or Deny.
  • A denied verdict does not necessarily mean a token is fraudulent. Hypernative may deny tokens based on certain market conditions or other risk signals.

How LI.FI uses Hypernative

LI.FI integrates Hypernative directly into the Core backend token validation stack, which underpins all token lists and routing decisions exposed via LI.FI’s APIs and SDKs. 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.
  • That metadata is exposed downstream so integrators can filter or annotate tokens based on Hypernative’s verdicts.

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.
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 will extend token metadata to include a field indicating Hypernative’s verdict for a given token. Initially, only the Accept/Deny verdict will be surfaced — the reasoning behind a denial is not yet available, as LI.FI does not currently have access to that data from Hypernative’s API. As Hypernative’s API capabilities expand, LI.FI expects to be able to expose the underlying reasoning in token metadata, giving integrators more context for making decisions about flagged tokens.

Behavior in LI.FI APIs and SDKs

Initially, LI.FI will not alter the behavior of its APIs or SDKs based on Hypernative’s screening results. The verdict is surfaced in token metadata and passed through to integrators as-is, so they can implement whatever custom business logic suits their use case — whether that means filtering tokens, displaying risk warnings, or blocking certain actions entirely.

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 token on every 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. LI.FI therefore maintains manual review workflows for critical cases.
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.