HyperLeaf 如何工作

HyperLeaf 围绕一条简单流水线：

源资产 / 头寸
        ↓
 已验证托管或锁定
        ↓
  Leaf 表达
        ↓
HyperEVM 流动性
        ↓
 交易 / 抵押 / LP / 集成

步骤 1 — 识别经济 claim

发 Leaf 之前，先定义底层 claim 究竟是什么。

例如：

• 可转让质押凭证；
• 金库份额；
• 锁仓农场头寸；
• vote-escrow 仓位；
• 排队中的提款 claim。

第一条规则：仅有代币余额，不足以证明经济 backing。

系统区分授权、会计与偿付：

authorized message（授权消息）
      ≠
accounting truth（会计事实）
      ≠
solvency proof（偿付证明）

步骤 2 — 锁定或托管规范 backing

规范 backing 由相关 HyperLeaf 合约或原生协议集成持有/控制。

捐赠不会自动创造新 Leaf 供应。

Leaf 只相对明确的 backing 关系铸造。

步骤 3 — 铸造 Leaf

backing 条件满足后，在 HyperEVM 发行对应 Leaf。

该 listing 下 Leaf 含义固定。

例如：

1 hNEST
= 一单位 HyperLeaf hNEST claim

会计单位因资产而异。对按汇率计息的头寸，单位可能是份额而非原始代币余额。

步骤 4 — 让 claim 有用

Leaf 随后可以：

• 持有；
• 转让；
• 交易；
• 用在已集成协议里；
• 提供流动性；
• 在支持的场所作抵押。

HyperLeaf 不要求每个 listing 有相同的二级市场行为。

步骤 5 — 按底层拓扑退出

退出路径是 listing 的属性。

L — Liquid

底层是带立刻协议退出的可转让凭证。

Leaf → burn → 交回同一凭证

C1 — Closed

底层是长锁期或其它不可协议赎回的头寸。

Leaf → 二级市场

Leaf 可以有 backing、可交易，而协议不承诺立刻 peg-out。

C2 — Queued

底层有明确的解质押或提款流程。

Leaf → burn → 入队 → 等待 → claim

为什么必须区分

最危险的产品设计，是假装这三类一样。

HyperLeaf 在产品分类、代币名、UI 与风险披露里把差异写死。

Ticker 应告诉用户：你买的是哪种 claim。

源端奖励

奖励按底层经济模型处理。

有的奖励属于 Leaf 内在价值。

有的是可转成 HYPE 的副资产。

系统不默认「每个奖励都抬 NAV」，也不默认「每个奖励都发成 HYPE」。

会计决策在先，界面跟后。