Hypernative 的作用
Hypernative 提供一个代币筛查 API,它接受代币标识符并返回一个关于该代币风险状态的裁决。LI.FI 使用它为其现有的代币验证流程增加一个额外的安全层。 关键特性:- 代币通过 Hypernative 的代币信誉 API 端点进行筛查。
- 主要输出是一个分类裁决,在 LI.FI 的代币元数据中呈现为以下三种状态之一:verified(已验证)、unverified(未验证)或 flagged(已标记)。
- flagged(已标记)裁决并不一定意味着代币存在欺诈。Hypernative 可能基于某些市场状况或其他风险信号标记代币。
Hypernative 的供应商结果会映射到 LI.FI 的三态模型:
accept 映射为 verified,deny 映射为 flagged,无法取得或不支持的筛查结果则保持为 unverified。LI.FI 如何使用 Hypernative
LI.FI 将 Hypernative 直接集成到 Core 后端供代币服务使用的验证栈中。 从高层次来看:- LI.FI 内部代币集合中的代币会定期通过 Hypernative 代币信誉 API 进行筛查。
- 筛查结果作为每个代币元数据的一部分,以 verified / unverified / flagged 状态存储在 LI.FI 的后端中。
- 该元数据会向下游暴露,以便集成商可以根据 Hypernative 的裁决过滤或标注代币。
运营影响
Hypernative 筛查不仅仅是提供信息,但目前可证明的强制执行范围较窄:- 钱包余额响应会省略 flagged(已标记)代币。
GET /tokens仍会返回 flagged 代币,并在代币对象上带有verificationStatus和verificationStatusBreakdown,供集成商自行过滤。POST /v1/tokens/lookup会报告status: "flagged",且不返回 token 主体。
覆盖范围
实际筛查覆盖取决于 LI.FI 的已部署配置和 Hypernative 的供应商支持;没有可用结果的代币会保持 unverified,并继续经过 LI.FI 的其他验证流程。速率限制和筛查策略
并非每次代币查询都会触发一次即时的实时 Hypernative 查询。LI.FI 对已知代币依赖于缓存的筛查结果。新发现的代币在 Hypernative 裁决可用之前可能会有短暂延迟——在裁决产生之前,代币会被视为 unverified(未验证)。暴露的元数据
LI.FI 的代币元数据可以包含聚合后的verificationStatus 和供应商明细。LI.FI 当前会暴露规范化裁决,但不会暴露 Hypernative 决策的可读原因。
在 LI.FI API 和 SDK 中的行为
如上文“运营影响”一节所述,flagged 代币会从钱包余额响应中被省略。其他代币接口仍可能返回 flagged 资产及其验证元数据。在代币响应包含验证元数据时,集成商可以将其作为自身业务逻辑中的额外信号。局限性和注意事项
虽然 Hypernative 显著提升了代币安全性,但它并不能替代全面的尽职调查。覆盖范围
覆盖范围
Hypernative 的信誉覆盖可能无法涵盖每条受支持链或已覆盖链上的每个代币,尤其是新部署或流动性不足的资产。
延迟
延迟
由于速率限制,代币创建与 Hypernative 裁决可用之间可能存在延迟。
误报和漏报
误报和漏报
与任何信誉系统一样,存在非零的误分类风险。请将 flagged 裁决视为风险信号,而不是已经完成的调查结论。
获取支持
如果您对如何解读基于 Hypernative 的元数据有疑问,或想了解如何将其集成到您现有的 LI.FI 设置中:- 通过您现有的 LI.FI 合作伙伴渠道或企业支持联系人与我们联系。
- 请参阅 Hypernative 文档,了解底层代币信誉 API 的详情。

